3. Структура документов по обеспечению информационной безопасности
3.1. Деятельность организации БС РФ по обеспечению ИБ осуществляется на основе следующих документов:
— действующих законодательных актов и нормативных документов Российской Федерации по обеспечению ИБ;
— нормативных актов Банка России;
— внутренних документов организации БС РФ по обеспечению ИБ.
3.2. В состав внутренних документов организаций БС РФ по обеспечению ИБ рекомендуется включать следующие виды документов (документированной информации), организованных в виде приведенной на рисунке 1 иерархической структуры:
— документы, содержащие положения корпоративной политики ИБ организации БС РФ (документы первого уровня), определяют высокоуровневые цели, содержание и основные направления деятельности по обеспечению ИБ, предназначенные для организации в целом;
— документы, содержащие положения частных политик (документы второго уровня), детализируют положения корпоративной политики ИБ применительно к одной или нескольким областям ИБ, видам и технологиям деятельности организации БС РФ;
— документы, содержащие положения ИБ, применяемые к процедурам (порядку выполнения действий или операций) обеспечения ИБ (документы третьего уровня), содержат правила и параметры, устанавливающие способ осуществления и выполнения конкретных действий, связанных с ИБ, в рамках технологических процессов, используемых в организации БС РФ, либо ограничения по выполнению отдельных действий, связанных с реализацией защитных мер, в используемых технологических процессах (технические задания, регламенты, порядки, инструкции);
— документы, содержащие свидетельства выполненной деятельности по обеспечению ИБ (документы четвертого уровня), отражают достигнутые результаты (промежуточные и окончательные), относящиеся к обеспечению ИБ организации БС РФ.
Рисунок 1. Структура внутренних документов организации БС РФ по обеспечению ИБ
3.3. Рекомендуется, чтобы положения документов по обеспечению ИБ организации БС РФ:
— носили не рекомендательный, а обязательный характер;
— были выполнимыми и контролируемыми. Не рекомендуется включать в состав этих документов положения, контроль реализации которых затруднен или невозможен;
— были адекватны требованиям и условиям ведения деятельности (включая угрозы и риски ИБ), в том числе в условиях их изменчивости;
— не противоречили друг другу.
3.4. В состав документов организации БС РФ рекомендуется включить документ (классификатор), содержащий перечень и назначение всех документов организации БС РФ (для каждого из вышеопределенных уровней иерархической структуры), регламентирующих деятельность по обеспечению ИБ организации БС РФ. Указанный классификатор может быть полезен при осуществлении менеджмента документов организации БС РФ, для повышения степени осведомленности сотрудников организации БС РФ, а также при выполнении аудита информационной безопасности организации БС РФ.
3.5. При наличии у организации БС РФ сети филиалов (территориальных учреждений) в каждом из филиалов (территориальном учреждении) рекомендуется иметь единый для организации БС РФ, утвержденный комплект документов по обеспечению ИБ. В случае возникновения необходимости учета специфики конкретных филиалов в них должны быть разработаны собственные документы, учитывающие эту специфику. Рекомендуется, чтобы документы по обеспечению ИБ филиала (территориального учреждения) организации БС РФ базировались на положениях документов по обеспечению ИБ, принятых головной организацией (центральным аппаратом) организации БС РФ, и не противоречили им.
3.6. Пример требований международного стандарта [1] к структуре (иерархии) и содержанию внутренних документов ИБ организации приведен в приложении А.
Подготовка организационно-
распорядительных документов
Организационно-распорядительная документация (ОРД) – многоуровневая система документов, закрепляющая цели, задачи, функции, а также права и обязанности сотрудников в вопросе обеспечения информационной безопасности в организации.
Как правило, разрабатываемая система ОРД представляет собой иерархическую структуру, состоящую
из четырех уровней:
- Первый уровень состоит из одного документа – Общей политики информационной безопасности, отражающей взгляды руководства на обеспечение информационной безопасности в организации, цели и задачи, общие принципы и подходы по защите информации.
- Второй уровень составляют Частные политики и Стандарты. Частные политики детализируют положения Общей политики информационной безопасности применительно к одной
или нескольким областям информационной безопасности (политика аудита, парольная политика, политика работы с электронной почтой и т. п.). Стандарты содержат обязательные действия или правила, принятые в организации, поддерживают и развивают политики
в определенных направлениях (использование ПО, беспроводной сети и т.п.). - Третий уровень составляют регламенты и инструкции. Регламенты определяют порядок реализации процессов, относящихся к той или иной области информационной безопасности (регламент предоставления доступа к информационной системе, регламент резервного копирования и т.п.). Инструкции содержат детальное описание выполнения той или иной задачи (регистрация новых пользователей, настройки средств защиты информации и т.п.).
- Четвертый уровень составляют различного рода формы, журналы, протоколы и прочие документы, содержащие свидетельства выполнения той или иной деятельности в рамках выполнения процедур обеспечения информационной безопасности (регистрационные журналы, формы заявок на предоставление доступа к информационному ресурсу и т.п.).
Целью формирования ОРД является формальное закрепление принятой в организации политики обеспечения информационной безопасности и установление организационно-правового режима безопасности информации.
Подготовка ОРД предполагает выполнение следующих видов работ:
- обследование объекта информатизации;
- анализ полученных сведений по результатам обследования;
- формирование плана работ и перечня документов;
- разработка организационно-распорядительной документации;
- внедрение организационно-распорядительной документации.
По результатам проведенных работ подготавливается индивидуальный пакет организационно-распорядительных документов, учитывающий специфику деятельности организации, а также требования федерального законодательства, подзаконных нормативно-правовых актов, отраслевых
и международных стандартов.
Общий порядок действий по созданию систем защиты информации
Система защиты информации (применительно к органу управления, организации, учреждению – это совокупность органов и (или) исполнителей, используемой ими техники защиты информации, а также объектов защиты, организованная и функционирующая по правилам и нормам, установленным соответствующими документами в области защиты информации (пункт 2.4.3. Национального стандарта Российской Федерации ГОСТ Р 50922-2006 «Защита информации. Основные термины и определения»).
В организационную структуру системы входят:
- руководитель – несет персональную ответственность за обеспечение информационной безопасности (устав организации, положение об органе);
- заместитель руководителя, курирующий вопросы информационно-технической безопасности (должностной регламент);
- постоянно действующий коллегиальный орган, вырабатывающий предложения по решению проблемных вопросов в области защиты информации; (положение о комиссии);
- подразделение или специалист, ответственные за реализацию мероприятий по технической защите информации (положение о подразделении, должностная инструкция или регламент специалиста).
Система защиты информации (применительно к объекту обработки информации) – это совокупность организационных мероприятий, технических, программных и программно-технических средств защиты информации и средств контроля эффективности защиты информации (пункт 3.3 Национального стандарта Российской Федерации ГОСТ Р 51583-2014 «Защита информации. Порядок создания автоматизированных систем в защищенном исполнении. Общие положения»).
Задачи, решаемые системой защиты информации:
- исключение неправомерных доступа, копирования, предоставления или распространения информации (обеспечение конфиденциальности информации);
- исключение неправомерных уничтожения или модифицирования информации (обеспечение целостности информации);
- исключение неправомерного блокирования информации (обеспечение доступности информации).
Жизненный цикл системы защиты информации (СЗИ) объекта обработки информации состоит из стадии создания системы и стадии эксплуатации.
Стадию создания осуществляет (организует) обладатель информации, заказчик; стадию эксплуатации СЗИ осуществляет оператор.
Жизненный цикл системы защиты информации объекта информатизации — совокупность взаимоувязанных процессов последовательного изменения состояния системы защиты информации конкретного объекта от принятия решения о необходимости защиты обрабатываемой на нем информации до окончания его эксплуатации.
Стадия (этап) жизненного цикла – часть жизненного цикла, характеризующаяся определенным состоянием системы защиты информации, совокупностью видов предусмотренных работ с их конечными результатами.
Обладатель информации – лицо, создавшее информацию и (или) имеющее право разрешать или ограничивать доступ к информации.
Заказчик – лицо, заключившее контракт на создание объекта обработки информации.
Оператор – лицо, эксплуатирующее объект, в том числе непосредственно осуществляющее обработку содержащейся в нем информации.
Уполномоченное лицо – лицо, осуществляющее на договорной основе с заказчиком или оператором обработку информационного ресурса и (или) предоставляющее для этих целей вычислительные ресурсы.
Поставщик информации – лицо, наделенное полномочиями по предоставлению сведений для их внесения в базу данных объекта.
Этапы стадии создания системы защиты информации
- Этап 1. Формирование требований к системе защиты информации (предпроектный этап).
- Этап 2. Разработка системы защиты информации (этап проектирования).
- Этап 3. Внедрение системы защиты информации (этап установки, настройки, испытаний).
- Этап 4. Подтверждение соответствия системы защиты информации (этап оценки).
Формирование требований к системе защиты информации
Этап 1 осуществляется обладателем информации (заказчиком).
Перечень работ на этапе 1:
- Принятие решения о необходимости защиты обрабатываемой информации.
- Классификация объекта по требованиям защиты информации (установление уровня защищенности обрабатываемой информации).
- Определение угроз безопасности информации, реализация которых может привести к нарушению безопасности обрабатываемой информации.
- 4. Определение требований к системе защиты информации.
Решение о необходимости создания системы защиты информации принимается на основе анализа стоящих задач, обрабатываемой информации и нормативной базы. В ходе анализа определяются структурно-функциональные характеристики объекта и режим обработки информации:
- статус (принадлежность) объекта (государственный, муниципальный, иной);
- структура объекта (локальный или распределенный);
- масштаб объекта (федеральный, региональный, объектовый);
- наличие подключений к сторонним сетям, в том числе сетям общего пользования (имеются или отсутствуют);
- режим обработки информации (одно или многопользовательский);
- уровень доступа (с разграничением или без разграничения);
- перечень технологических операций (чтение, поиск, запись, удаление, сортировка, модификация, передача, голосовой ввод,);
- используемые информационные технологии (беспроводный, удаленный доступ, виртуализация, мобильные объекты, туннелирование и пр.),
Категория информации, подлежащей защите, и свойства ее безопасности:
- информация ограниченного доступа (конфиденциальность, целостность, доступность);
- общедоступная информация (целостность, доступность),
Нормативная правовая база по информационно-технической безопасности выделяет разные задачи по защите информации:
- защита информации, составляющей государственную тайну;
- защита государственного информационного ресурса, не отнесенного к государственной тайне;
- обеспечение безопасности персональных данных в иных информационных системах;
- обеспечение безопасности критической информационной инфраструктуры;
- обеспечение безопасности информации в информационных системах общего пользования.
Более подробно правовое сопровождение защиты информации рассмотрено в разделе экономических и правовых аспектов защиты информации.
Актуальным на этом этапе видится формулирование целей и задач защиты информации.
Цель защиты информации — минимизировать (предотвратить) ущерб обладателю информации из-за возможных нарушений свойств ее безопасности.
Задача защиты информации — обеспечить необходимый уровень защищенности информации от нарушений ее целостности, доступности, конфиденциальности.
Решение оформляется локальным нормативным правовым актом, в котором отражаются цели и задачи защиты информации, этапы и сроки создания системы защиты информации, функционал и ответственность обладателя информации, заказчика и оператора.
Основные документы, формируемые по результатам исполнения работ на этапе формирования требований к системе защиты информации:
| Действие | Документ |
|---|---|
| 1. Принятие решения о необходимости защиты информации | Локальный нормативный правовой акт, определяющий необходимость создания системы защиты информации |
| 2. Классификация по требованиям защиты информации (по уровню защищенности информации) | Акт классификации по требованиям безопасности информации |
| 3.Определение актуальных угроз безопасности информации | Частная модель угроз безопасности информации |
| 4. Определение требований к системе защиты информации | ТЗ на создание системы защиты информации с указанием требований к мерам и средствам защиты информации |
Разработка системы защиты информации
Этап 2 — разработка системы защиты информации – организуется обладателем информации (заказчиком).
Перечень работ на этапе 2:
- Проектирование системы защиты информации.
- Разработка эксплуатационной документации на систему защиты информации.
Положением о лицензировании деятельности по технической защите конфиденциальной информации, утвержденном постановлением Правительства Российской Федерации от 3 февраля 2012 г. № 79 «О лицензировании деятельности по технической защите конфиденциальной информации» с учетом изменений, внесенных постановлением правительства российской федерации от 15 июня 2016 г. № 541 «О внесении изменений в некоторые акты Правительства Российской Федерации по вопросам лицензирования отдельных видов деятельности» определены виды работ и услуг по технической защите конфиденциальной информации, подлежащие обязательному лицензированию:
работы и услуги по аттестационным испытаниям и аттестации на соответствие требованиям по защите информации, а также работы и услуги по проектированию в защищенном исполнении:
- средств и систем информатизации;
- помещений со средствами (системами) информатизации, подлежащими защите;
- защищаемых помещений.
Согласно Федеральному закону от 27.12.2002 № 184 -ФЗ «О техническом регулировании», оценка соответствия средств (продукции) защиты информации, предназначенных для обеспечения безопасности государственного информационного ресурса ограниченного доступа и персональных данных, проводится в форме обязательной сертификации.
В зависимости от вида защищаемой информации, следует руководствоваться Постановлением Правительства Российской Федерации от 26 июня 1995 г. № 608 «Положение о сертификации средств защиты информации» — для информации ограниченного доступа, либо Постановлением Правительства Российской Федерации от 15 мая 2010 г. № 330 «Положение об особенностях оценки соответствия продукции. » — для государственных информационных ресурсов и персональных данных.
Основные документы, формируемые по результатам исполнения работ на этапе разработки системы защиты информации:
| Действие | Документ |
|---|---|
| 1.Проектирование системы защиты информации | Технический проект (рабочая документация) на создание системы защиты информации |
| 2.Разработка эксплуатационной документации на систему защиты информации | Описание структуры системы защиты информации. Технический паспорт с указанием наименования, состава и мест установки аппаратных и программных средств. Перечень параметров настройки средств защиты информации. Правила эксплуатации средств защиты информации. |
Примерный состав эксплуатационной документации, разрабатываемой на этапе проектирования системы защиты информации
- Технический паспорт с указанием состава и мест установки ее технических и программных средств.
- Описание технологического процесса обработки информации.
- Описание параметров и порядка настройки средств защиты информации.
- Описание организационной структуры системы защиты информации, с указанием функциональных обязанностей ее элементов.
- Ведомость и журнал учета применяемых машинных носителей информации.
- Правила эксплуатации системы защиты информации.
Внедрение системы защиты информации
Этап 3 — Внедрение системы защиты информации – организуется обладателем информации (заказчиком) с привлечением оператора. Перечень работ на этапе 3:
- Установка и настройка средств защиты информации.
- Внедрение организационных мер защиты информации, в том числе, разработка документов, определяющих правила и процедуры, реализуемые оператором для обеспечения защиты информации в ходе эксплуатации объекта.
- Выявление и анализ уязвимостей программных и технических средств, принятие мер по их устранению;
- Испытания и опытная эксплуатации системы защиты информации.
Основные документы, формируемые по результатам исполнения работ на этапе внедрения системы защиты информации:
| Действие | Документ |
|---|---|
| 1. Установка и настройка средств защиты информации | Акт установки средств защиты информации |
| 2.Внедрение организационных мер, разработка организационно-распорядительных документов | Документы по регламентации правил по эксплуатации и вывода из эксплуатации системы защиты информации |
| 3.Выявление и анализ уязвимостей | Протокол контроля уязвимостей программного обеспечения и технических средств |
| 4.Испытания и опытная эксплуатации системы защиты информации | Протоколы контроля оценки эффективности средств и оценки защищенности информации |
Состав обязательных организационно-распорядительных документов, разрабатываемых на этапе внедрения системы защиты информации:
- Порядок администрирования системой защиты информации.
- Порядок выявления инцидентов, которые могут привести к возникновению угроз безопасности информации и реагирования на них.
- Порядок управления конфигурацией объекта и его системы защиты информации.
- Порядок контроля за обеспечением уровня защиты обрабатываемой информации.
- Порядок защиты информации при выводе из эксплуатации объекта.
Подтверждение соответствия системы защиты информации
Этап 4 — подтверждение соответствия системы защиты информации – организуется обладателем информации (заказчиком) или оператором. Перечень работ на этапе 4 определяется в Программе и методиках аттестационных испытаний, разрабатываемой до их начала. Документ формируется исполнителем работ и согласовывается с заявителем.
Общие требования к структуре и содержанию программ и методик аттестационных испытаний на соответствие требованиям безопасности информации, выполнение которых позволяет защитить информацию от утечки по техническим каналам, от несанкционированного доступа и от специальных воздействий определяются национальным стандартом ГОСТ РО 0043-004-2013 «Защита информации. Аттестация объектов информатизации. Программа и методики аттестационных испытаний».
Аттестация – комплекс организационных и технических мероприятий, в результате которых подтверждается соответствие системы защиты информации объекта информатизации (информационной системы) требованиям безопасности информации.
Аттестация объектов информатизации делится на обязательную и добровольную.
Обязательная аттестация проводится в принятых законодательством случаях для определения соответствия системы защиты информации объекта исключительно требованиям, установленным федеральными нормативными правовыми актами.
Добровольная аттестация проводится по инициативе заявителя для определения соответствия системы защиты информации объекта требованиям, установленным национальными стандартами, владельцем информации или владельцем объекта.
Обязательной аттестации подлежат государственные (муниципальные) информационные системы и их сегменты, содержащие информацию ограниченного доступа, добровольной – все иные информационные системы.
Порядок проведения аттестации информационных систем по требованиям безопасности информации:
- Подача и рассмотрение заявки на аттестацию.
- Предварительное ознакомление с аттестуемым объектом (при необходимости).
- Разработка программы и методики аттестационных испытаний.
- Проведение аттестационных испытаний объекта.
- Оформление, регистрация и выдача аттестата соответствия.
Подача и рассмотрение заявки на аттестацию объекта информатизации:
- Заявителем выбирается исполнитель работ по аттестации объекта информатизации (организация-лицензиат по технической защите конфиденциальной информации).
- Заявителем направляется исполнителю заявка на проведение аттестации с исходными данными на аттестуемый объект.
- Исполнителем рассматривается заявка, принимается решение о порядке аттестации, готовятся договорные документы на оказание услуг по аттестации объекта информатизации.
При недостаточности исходных данных в порядок аттестации включаются работы исполнителя по предварительному ознакомлению с аттестуемым объектом.
Структура и содержание программы и методики аттестационных испытаний определяется Национальным стандартом ограниченного распространения ГОСТ РО 0043-004-2013 «Защита информации. Аттестация объектов информатизации. Программа и методики аттестационных испытаний»
Аттестуемая распределенная информационно-телекоммуникационная система
Основные документы, формируемые по результатам исполнения работ на этапе подтверждения соответствия системы защиты информации:
| Действие | Документ |
|---|---|
| 1.Аттестационные испытания системы защиты информации | Протоколы и заключение по результатам аттестационных испытаний |
| 2.Оформление результатов аттестационных испытаний | Рекомендации по обеспечению защищенности информации на аттестуемом объекте и Аттестат соответствия |
После подтверждения соответствия системы защиты информации осуществляется переход на другую стадию жизненного цикла – стадию эксплуатации.
Этапы стадии эксплуатации системы защиты информации
- Этап 5. Ввод системы защиты информации в постоянную эксплуатацию.
- Этап 6. Промышленная эксплуатация системы защиты информации.
- Этап 7. Вывод из эксплуатации системы защиты информации.
Этап 5 — ввод системы защиты информации в постоянную эксплуатацию – осуществляется оператором.
Решение о вводе оформляется локальным нормативным правовым актом, в котором определяются должностные лица, ответственные за эксплуатацию и сопровождение системы защиты информации: начальник объекта, системные администраторы, администраторы информационной безопасности.
Этап 6 — промышленная эксплуатация системы защиты информации – осуществляется оператором.
Также оператор осуществляет администрирование системы защиты информации, выявление инцидентов и реагирование на них, управление конфигурацией объекта и его системой защиты информации, контроль за обеспечение необходимого уровня защищенности информации.
- осуществляют эксплуатацию объекта информатизации в соответствии с требованиями безопасности информации, а также условиями и ограничениями, установленными эксплуатационной документацией на систему защиты информации, и аттестатом соответствия;
- извещают орган по аттестации (организацию), выдавший аттестат соответствия, о всех изменениях в информационных технологиях, составе и размещении средств и систем, условиях их эксплуатации, которые могут повлиять на эффективность системы защиты информации;
- предоставляют необходимые документы и условия для осуществления контроля и надзора за соблюдением порядка аттестации и за эксплуатацией аттестованного объекта информатизации.
Органы по аттестации:
- отменяют и приостанавливают действие выданных этим органом (организацией) аттестатов соответствия;
- проводят на договорной основе оценку эффективности средств защиты информации и оценку защищенности информации от несанкционированного доступа.
Повторная аттестация ГИС осуществляется вслучае окончания срока действия аттестата соответствия или повышения класса защищенности информационной системы.
При увеличении состава угроз безопасности информации или изменении проектных решений, реализованных при создании системы защиты информации ГИС, проводятся дополнительные аттестационные испытания в рамках действующего аттестата соответствия.
Продление срока действия сертификата организацией, эксплуатирующей СЗИ:
Организация, эксплуатирующая средство защиты информации, заблаговременно , но не позднее чем за три месяца до окончания срока действия сертификата соответствия, связывается с организацией – первичным заявителем, с целью получения информации о проводимых работах по продлению сроков действия сертификата соответствия и о порядке получения копии продленного сертификата.
В случае получения информации об отсутствии намерений первичного заявителя продлевать сроки действия сертификата соответствия эксплуатирующая организация самостоятельно направляет в Федеральный орган по сертификации (ФСТЭК России) соответствующую заявку установленного образца (не позднее, чем за один месяц до окончания срока действия сертификата).
Этап 7 — вывод системы защиты информации из эксплуатации — осуществляется оператором.
На этом этапе производится архивирование информации, уничтожение или стирание данных и остаточной информации с машинных носителей информации, уничтожение машинных носителей информации.
Гайд по внутренней документации по информационной безопасности. Что, как и зачем
В одной из наших предыдущих статей мы затронули вопрос формирования комплекта документов для проверяющих по вопросам защиты персональных данных. Мы дали ссылку на наши шаблоны документов, но остановились на теме документации по информационной безопасности весьма поверхностно.
В этой статье хотелось бы раскрыть эту тему подробнее как в контексте персональных данных в частности, так и защиты информации в целом. Какие документы должны быть у оператора, какие опциональны. Откуда берется требование того или иного документа. Что писать в документах, а чего не стоит. Под катом очень много букв на эту тему.
Пару слов в защиту «бумажной» безопасности
Поскольку речь в статье пойдет о так называемой «бумажной» безопасности, хотелось бы сразу обозначить нашу позицию об этой части инфобеза.
У многих технарей, работающих «руками» зачастую вызывает резкое отторжение и пренебрежение эта самая «бумажная» безопасность. Однако, как это ни странно, когда такой технарь получает в свое распоряжению новую железку или софт (а иногда и то и другое в одном продукте), он хочет в первую очередь ознакомиться с документацией на это чудо техники.
Самое частое обоснование такой пренебрежительной позиции – эти все документы делаются просто для галочки, чтобы выполнить требования законодательства, это пустая трата времени, документы нужно поддерживать, но никто заниматься этим не будет и т. д. и т. п.
К сожалению, такая позиция не беспочвенна. За многие годы как среди безопасников на местах, так и среди лицензиатов, интеграторов и прочих заинтересованных лиц сложилась печальная практика такого же отношения к документам по информационной безопасности. В итоге нарисовался порочный круг – документы делают бесполезными, потому что к ним пренебрежительно относятся, в свою очередь к ним пренебрежительно относятся, потому что они бесполезные.
Отчасти это еще усугубляется тем, что зачастую документы по информационной безопасности пишут люди, далекие от информационных технологий. Ведь как можно писать раздел про защиту средств виртуализации, не понимая как эта самая виртуализация работает?
Чтобы такую ситуацию переломить, необходимо делать хорошие, содержательные и полезные документы. В то же время эти документы должны удовлетворять действующему законодательству по защите информации. Давайте посмотрим, что же можно со всем этим сделать.
Пара уточнений
Для начала, чтобы исключить лишние вопросы и домыслы считаем необходимым прояснить несколько моментов.
- В статье мы рассмотрим только внутренние организационно-распорядительные документы (далее – ОРД) по защите информации. Проектные, аттестационные и прочие документы рассматриваться не будут.
- Модель угроз тоже рассматривать не будем, хотя ее шаблон и есть здесь. Разработка модели угроз это отдельная история. Напишите в комментариях – нужен ли на Хабре мануал по разработке модели угроз?
- В статье будем опираться на наш комплект шаблонов. Он не является каким-то стандартом или общепринятым набором. В этом комплекте отражен сугубо наш подход к разработке ОРД. Поскольку законодательство зачастую не предписывает в этом плане ничего конкретного, у вас может быть свое мнение насчет комплектности и содержания документов и это нормально!
- В шаблонах могут быть ошибки и опечатки. Мы сами постоянно улучшаем и дорабатываем их.
- В контексте выполнения требований будет затронута в основном тематика персональных данных (152-ФЗ и подзаконные акты) и государственных информационных систем (17 приказ ФСТЭК). Помимо этого есть еще отдельная история с финансовыми организациями (требования ЦБ РФ) и различные стандарты (ISO 2700х и другие) – их мы рассматривать здесь не будем.
Комплектность документов
Если опираться на законодательство по защите информации, то там мало где сказано — какие конкретно документы мы должны разрабатывать, поэтому приходится опираться на различные косвенные намеки.
Для примера приведем часть 2 статьи 19 закона №152-ФЗ «О персональных данных». Обычным текстом будет текст закона, курсивом – примечания автора.
2. Обеспечение безопасности персональных данных достигается, в частности:
1) определением угроз безопасности персональных данных при их обработке в информационных системах персональных данных; (нужна модель угроз)
2) применением организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных, необходимых для выполнения требований к защите персональных данных, исполнение которых обеспечивает установленные Правительством Российской Федерации уровни защищенности персональных данных; (организационные меры по большей части и есть наши документы, плюс здесь нас отправляют читать дальше подзаконные акты)
3) применением прошедших в установленном порядке процедуру оценки соответствия средств защиты информации;
4) оценкой эффективности принимаемых мер по обеспечению безопасности персональных данных до ввода в эксплуатацию информационной системы персональных данных;
5) учетом машинных носителей персональных данных; (очевидно нужен некий журнал учета и разработанные правила учета машинных носителей)
6) обнаружением фактов несанкционированного доступа к персональным данным и принятием мер; (необходимо разработать некие правила обнаружения инцидентов и устранения их последствий, возможно, необходимо назначить группу реагирования на инциденты)
7) восстановлением персональных данных, модифицированных или уничтоженных вследствие несанкционированного доступа к ним; (нужны правила резервирования и восстановления)
8) установлением правил доступа к персональным данным, обрабатываемым в информационной системе персональных данных, а также обеспечением регистрации и учета всех действий, совершаемых с персональными данными в информационной системе персональных данных; (разработка системы допуска к данным, можно сделать на основе ролей в системе, так же само программное обеспечение должно уметь вести логи кто когда и к каким данным обращался)
9) контролем за принимаемыми мерами по обеспечению безопасности персональных данных и уровня защищенности информационных систем персональных данных. (нужен некий план периодического контроля, плюс, наверное, журнал, в котором будут фиксироваться результаты такого контроля)
Данным примером нам хотелось показать разницу: как написан закон и что по факту он от нас требует. Здесь мы не видим прямого требования «оператор должен разработать модель угроз», но эта необходимость все равно следует из текста 152-ФЗ, так как выполнение любого требования подтверждается документально.
Более конкретно о комплектности и содержании ОРД нам говорит ФСТЭК. В 2014 году этот регулятор выпустил методический документ «Меры защиты информации в государственных информационных системах». Документ без сарказма отличный, если вам было что-то непонятно по порядку выполнения мер 17-го, 21-го или другого приказа ФСТЭК (да, хоть документ и предназначен для ГИС, но меры по большей части у ФСТЭКа совпадают), обратитесь к этому документу, возможно, станет сильно понятнее.
Так вот, в этом документе ФСТЭК более расширенно расписывает меры по обеспечению безопасности информации и очень часто можно встретить такой текст:
Правила и процедуры идентификации и аутентификации пользователей регламентируются в организационно-распорядительных документах по защите информации. (ИАФ.1)
Правила и процедуры управления учетными записями пользователей регламентируются в организационно-распорядительных документах оператора по защите информации. (УПД.1)
Правила и процедуры управления информационными потоками регламентируются в организационно-распорядительных документах оператора по защите информации. (УПД.3)
Отлично, уже что-то, но этих правил и процедур целый вагон.
В итоге пришлось запилить себе примерно такую табличку, в которую выписались все требования из всех документов и делались примечания и отметки о выполнении, невыполнении.
Главная мысль этого раздела – есть гора требований в законодательстве по защите информации, выполнение многих из них нужно подтвердить документально. Делать ли под каждое требование отдельный документ или слить все в одну большую «Политику ИБ» — решать каждому. Все дополнительное, что нам нужно в документах прописать не по требованиям, а исходя из практической необходимости, дописываем без каких-либо проблем.
Кстати, обратите внимание, что в таблице и в самих документах некоторые разделы или абзацы помечены «К1» или «К2+». Это означает что раздел или абзац необходим только для информационных систем 2 класса и выше или для первого (максимального класса). Все что не помечено – выполняется во всех государственных информационных системах и ИСПДн.
Также очевидно, что например некоторые разделы или даже целые документы могут быть упразднены, если этого требуют структурно-функциональные характеристики информационной системы или иные исходные условия. Например, убираем положение о видеонаблюдении, если его нет. Или убираем все разделы, связанные с защитой средств виртуализации, если она не применяется.
Наши шаблоны разбиты на 4 папки:
Общее – документы, которые необходимо разработать для всех систем (по мере применимости), будь то ИСПДн, ГИС, АСУ ТП или объект КИИ.
Только ГИС – документы для государственных информационных систем или муниципальных информационных систем, тут только уникальные документы, нужные для ГИС и МИС.
ПДн – документы по защите персональных данных и во исполнение законодательства по защите персональных данных. Если, например, у нас ГИС, в которой обрабатываются персональные данные, то мы должны сделать документы из всех папок.
СКЗИ – документы, связанные с использование криптографических средств, нужны для исполнения нормативных документов ФСБ, разрабатываются для всех систем, в которых применяются сертифицированные криптографические средства защиты информации.
Рассмотрим далее подробнее документы, откуда они появились и какие требования выполняют.
Общие
01 Приказ о назначении ответственных лиц и инструкции этим лицам
Этим приказом назначаются: ответственный за организацию обработки персональных данных и администратор безопасности.
Необходимость назначения первого обусловлена статьей 18.1 федерального закона:
1. Оператор обязан принимать меры… К таким мерам могут, в частности, относиться:
1) назначение оператором, являющимся юридическим лицом, ответственного за организацию обработки персональных данных;
Отличаются эти лица тем, что «ответственный» больше по бумажной части, а «администратор» по технической.
Для того чтобы ответственный и администратор понимали свои задачи и полномочия им полагаются инструкции.
02 Приказ о назначении группы реагирования на инциденты информационной безопасности (ГРИИБ) и инструкция по реагированию
Сокращение ГРИИБ хоть и немного смешное, но вполне себе официальное, введено ГОСТ Р ИСО/МЭК ТО 18044-2007 «Информационная технология. Методы и средства обеспечения безопасности. Менеджмент инцидентов информационной безопасности».
Необходимость документов необходима целым рядом нормативно-правовых документов. Например, той же статьей 19 закона «О персональных данных». Но более подробно реагирование на инциденты раскрывается в приказах ФСТЭК.
18.2. В ходе выявления инцидентов и реагирования на них осуществляются:
- определение лиц, ответственных за выявление инцидентов и реагирование на них;
- обнаружение и идентификация инцидентов, в том числе отказов в обслуживании, сбоев (перезагрузок) в работе технических средств, программного обеспечения и средств защиты информации, нарушений правил разграничения доступа, неправомерных действий по сбору информации, внедрений вредоносных компьютерных программ (вирусов) и иных событий, приводящих к возникновению инцидентов;
- своевременное информирование лиц, ответственных за выявление инцидентов и реагирование на них, о возникновении инцидентов в информационной системе пользователями и администраторами;
- анализ инцидентов, в том числе определение источников и причин возникновения инцидентов, а также оценка их последствий;
- планирование и принятие мер по устранению инцидентов, в том числе по восстановлению информационной системы и ее сегментов в случае отказа в обслуживании или после сбоев, устранению последствий нарушения правил разграничения доступа, неправомерных действий по сбору информации, внедрения вредоносных компьютерных программ (вирусов) и иных событий, приводящих к возникновению инцидентов;
- планирование и принятие мер по предотвращению повторного возникновения инцидентов.
Этими же документами закрывается ряд организационных мер, например РСБ.1 «Определение событий безопасности, подлежащих регистрации, и сроков их хранение» и РСБ.2 «Определение состава и содержания информации о событиях безопасности, подлежащих регистрации». Все эти вещи можно указать в инструкции по реагированию на инциденты, чтобы не плодить отдельные документы.
03 Инструкция пользователя
Косвенная необходимость такого документа – юридическое оформление ответственности пользователей за возможные инциденты информационной безопасности. Как показывает практика, в случаях когда таких инструкций не существует и (или) пользователь с ней не ознакомлен, пользователь, нарушивший требования ИБ скорее всего не будет привлечен к ответственности.
Что касается самого документа, здесь мы решили не грузить пользователей не нужной им ерундой, сделать документ не слишком сложным для восприятия и полезным не только в отношении ИБ на предприятии, но и в вопросах ИБ в личной жизни. Например, описали методы социальной инженерии с примерами.
05 Политика информационной безопасности
Наверное, один из наиболее объемных документов из всего набора. Помните выше мы писали о документе «Меры защиты информации в ГИС» и про большое количество «правил и процедур», которые необходимо прописать в ОРД? Собственно «Политика ИБ» это и есть, по сути, сборник всех таких правил и процедур.
Тут, пожалуй, стоит остановиться на слове «Политика». Нам часто говорят, что у нас «Политика» слишком целенаправленная, а на самом деле документ с таким названием должен быть более абстрактным и высокоуровневым. Может и так, но у нас как у безопасников все-таки в первую очередь с техническим бэкграундом слово «Политика» ассоциируется, например, с групповыми политиками домена, что уже в свою очередь ассоциируется с конкретными правилами и настройками.
На самом деле, как будет называться такой документ – не важно. Если не нравится слово «Политика» можно переименовать в «Правила и процедуры информационной безопасности». Это не главное. Главное, что в этом документе должны быть уже четко и конкретно прописаны эти самые правила и процедуры.
Здесь остановимся немного поподробнее.
Если открыть документ и начать с ним работать, можно заметить, что в некоторых местах нет конкретных заготовок текста, а вместо этого стоит сухое «Описать». Это потому, что некоторые вещи нельзя описать так, чтобы текст подходил одновременно хотя бы для половины конкретных информационных систем. Для каждого случая лучше эти разделы описывать отдельно. Вот почему мы до сих пор скептически относимся к различным автоматическим «заполняторам» документов.
По основному тексту должно быть в целом все понятно, хотелось бы немного остановиться на приложениях.
Заявка на внесение изменений в списки пользователей
Многим кажется такая процедура отслеживания пользователей и их полномочий в системе сильно бюрократизированной, однако мы часто встречались с ситуациями, когда именно такой подход помогал продвинуться в расследовании инцидентов информационной безопасности. Например, необходимо было установить — какие полномочия были выданы пользователю изначально. Когда были подняты заявки из приложения к политике ИБ, выяснилось, что у одной учетной записи было несанкционированное повышение полномочий.
В любом случае – делать такую процедуру регистрации пользователей или нет, решать каждому оператору самостоятельно. Здесь, наверное, сразу стоит оговориться, что явно делать именно так, как описано в нашем образце политики ИБ не требуется каким-либо законодательным актом. В шаблоне документа приведен скорее самый жесткий и депрессивный вариант. А далее каждый для себя решает сам – где ослабить гайки, а где подкрутить еще сильнее.
Положение о разграничении прав доступа и перечень лиц
Разграничение прав доступа пользователей – мера очевидная для любого системного администратора. Дополнительно ее необходимость подкреплена мерами из приказов ФСТЭК: УПД.2 «Реализация необходимых методов (дискреционный, мандатный, ролевой или иной метод), типов (чтение, запись, выполнение или иной тип) и правил разграничения доступа», УПД.4 «Разделение полномочий (ролей) пользователей, администраторов и лиц, обеспечивающих функционирование информационной системы» и некоторых других.
Поскольку в подавляющем количестве случаев оптимально использовать именно ролевую модель разграничения доступа, то и указанные приложения к политике ИБ заточены именно под этот случай.
Перечень лиц. Нас часто спрашивают, можно ли указывать здесь не конкретных людей, а должности. Особенно часто этот вопрос звучит от представителей больших организаций с большой текучкой кадров. Наш ответ – можете попробовать, но любой регулятор вам расскажет о принципе «персональной ответственности» и о том, что «главного бухгалтера» наказать нельзя, а «Марью Ивановну» можно.
Список разрешающих правил взаимодействия с внешними сетями
Правила создаются в основном во исполнение меры УПД.3 «Управление (фильтрация, маршрутизация, контроль соединений, однонаправленная передача и иные способы управления) информационными потоками между устройствами, сегментами информационной системы, а также между информационными системами».
Поскольку, как уже было сказано, шаблоны заточены под самый депрессивный вариант, здесь тоже часто таблица заполняется «белыми списками». Но можно вписывать любые другие правила, если «белые списки» не обусловлены каким-нибудь особым требованием законодательства. Форма таблицы тоже примерная, можно переделывать под своё видение как угодно.
Список разрешенного программного обеспечения
Список создается во исполнение меры ОПС.3 «Установка (инсталляция) только разрешенного к использованию программного обеспечения и (или) его компонентов». Соответственно, чтобы знать какое ПО у нас в системе разрешено, должен быть утвержден список.
Часто список применяется для того чтобы понять, не установил ли пользователь что-нибудь ненужное себе на рабочий компьютер. Хотя по-хорошему саму возможность что-то самостоятельно устанавливать рядовым пользователям нужно устранять.
Далее идут списки ПО и пользователей для удаленного доступа. Заполняются, если есть такой доступ и да, это тоже требования ФСТЭК.
Порядок резервирования
Здесь даже наверное требования ФСТЭК приводить не нужно. Все понимают важность бэкапов и все помнят поговорку «есть 2 типа сисадминов: те, которые делают бэкапы и те, которые будут делать бэкапы». Однако на практике при аудите информационных систем часто случается такое, что админы говорят, что бэкапы у них точно делаются, но вопросы «что именно, куда именно и как часто бэкапится» остаются без ответа.
Актуальная таблица из приложения 10 к политике ИБ поможет избежать таких ситуаций.
Что касается требований по резервированию (хотя на самом деле требования больше относятся к восстановлению), то их тоже немало. Например, часть 2 статьи 19 федерального закона «О персональных данных»:
Обеспечение безопасности персональных данных достигается, в частности:
7) восстановлением персональных данных, модифицированных или уничтоженных вследствие несанкционированного доступа к ним;
План обеспечения непрерывности функционирования информационной системы
Здесь мы постарались собрать заготовку различных вариантов факапов нештатных ситуаций и вариантов реагирования на них. Естественно, это примерный список, ненужное можно убирать, нужное добавлять.
Требование ФСТЭК, которое этим планом мы частично выполняем:
06 Приказ о контролируемой зоне и положение о контролируемой зоне
Необходимость этих документов обусловлена требованием ФСТЭК: ЗТС.2 «Организация контролируемой зоны, в пределах которой постоянно размещаются стационарные технические средства, обрабатывающие информацию, и средства защиты информации, а также средства обеспечения функционирования».
Здесь мы часто встречаемся с заблуждением, что контролируемой зоной можно считать только те помещения, которые оборудованы системами СКУД, видеонаблюдением и т. д., но это не так. Контролируемая зона, это территория, на которой исключается несанкционированный доступ к элементам информационной системы посторонними лицами. То есть по сути это может быть помещение и без видеонаблюдения и СКУД, но с проинструктированным единственным сотрудником, который «бдит», а когда уходит из кабинета, выгоняет всех посторонних и закрывает кабинет на ключ.
07 План мероприятий по обеспечению безопасности.
План мероприятий можно разбить на 2 части – список разовых мероприятий по ИБ и список периодических мероприятий. Раз есть 2 части, то есть и две основные цели.
Нам часто задают такой вопрос: «А вот мы бедная государственная организация, требований по ИБ много, денег на их выполнение нет, а на носу проверка, что нам делать?». Ну, если совсем все плохо – то хотя бы составить план мероприятий. Так можно показать проверяющим, что вы в курсе о том, какие шаги вам нужно предпринять, но по какой-то причине ещё не. Это о разовых мероприятиях.
Вторая часть – периодические мероприятия, это выполнение ряда требований по постоянному внутреннему контролю информационной безопасности. Например, часть 1 статьи 18.1 закона «О персональных данных»:
1. Оператор обязан принимать меры… К таким мерам могут, в частности, относиться:
4) осуществление внутреннего контроля и (или) аудита соответствия обработки персональных данных настоящему Федеральному закону и принятым в соответствии с ним нормативным правовым актам, требованиям к защите персональных данных, политике оператора в отношении обработки персональных данных, локальным актам оператора;
08-14 Журналы.
Журналы 08-10 это журналы учета носителей информации. По ФСТЭКу есть три вида таких носителей:
- жесткие диски в стационарных компьютерах, серверах, моноблоках и т. д.;
- носители информации в различных портативных устройствах (ноутбуки, нетбуки, планшеты, фотоаппараты и т. д.);
- съемные машинные носители (флешки, съемные HDD, карты памяти).
Остальные журналы появились скорее не из прямых требований, а по косвенным причинам. У нас есть план периодических мероприятий и проверяющие хотят видеть отметки о каждом проведенном мероприятии. Так появились и остальные журналы.
И последнее, что хотелось бы сказать о журналах. Мы посчитали важным добавить в каждый журнал инструкцию по его заполнению. Буквально по каждому столбцу описать, что туда вписывать, иногда даже с примерами. Это на самом деле избавило нас от огромного количества одинаковых вопросов по заполнению.
Только ГИС
01 Приказ необходимости защиты информации
Нас часто спрашивают, зачем вообще нужен такой приказ. Дело в том, что 17-м приказом ФСТЭК первым мероприятием по формированию требований к защите информации установлено некое «принятие решения о необходимости защиты информации, содержащейся в информационной системе». А как мы помним, исполнение таких требований нужно подтверждать документально, вот и появился такой приказ, которым мы «принимаем решение».
Обратите внимание, что для государственных и для муниципальных информационных систем шаблоны разные.
02-03 Приказ о классификации и акт классификации
Классификация государственной информационной системы очень важный этап формирования требований к системе защиты информации. От того какой мы класс установим, будет зависеть и количество требований, которые нам нужно выполнить.
Приказом мы назначаем комиссию по классификации, а актом эта комиссия фиксирует параметры информационной системы и на основе исходных данных присваивает первый, второй или третий класс защищенности.
Единственное на что необходимо обратить внимание – если в ГИС обрабатываются, в том числе персональные данные, то для них тоже необходимо в этом же акте определить их уровень защищенности.
04 Приказ о вводе в действие
В соответствии с 17-м приказом ФСТЭК, государственная (или муниципальная) информационная система может быть введена в действие только на основании аттестата соответствия требованиям по безопасности информации.
01 Положение о защите и обработке ПДн
Основной документ по защите персональных данных, где мы стараемся прописать максимум аспектов обработки ПДн, предусмотренных законодательством. Здесь мы прописываем, чьи данные, какие данные и с какими целями мы обрабатываем. Права и обязанности субъектов ПДн, права и обязанности оператора ПДн и так далее. В целом наполнение этого документа во многом основано на многочисленных пожеланиях проверяющих, а не на каких-то конкретных требованиях законодательства.
02 Правила рассмотрения запросов
Глава 3 закона «О персональных данных» полностью посвящена правам субъекта персональных данных. Субъект ПДн имеет право писать различные запросы оператору ПДн, например, уточнить какие его данные и с какой целью обрабатываются, попросить прекратить обработку его персональных данных и т. д. Законом так же обозначены максимальные сроки, в которые оператор ПДн должен уложиться с ответом.
Соответственно, неплохо было бы иметь под рукой внутренний документ, регламентирующий правила и сроки рассмотрения таких запросов, а также имеющий в своем составе шаблоны ответов субъектам (как положительных, так и отрицательных). Это сильно упростит жизнь ответственному за организацию обработки персональных данных.
03 Приказ об утверждении перечня лиц
Нам необходимо определить, кто и к каким персональным данным имеет доступ. Если по доступу в информационные системы у нас уже разработан такой же документ в составе политики ИБ, то дублировать одно и то же здесь не требуется. Но нужно обратить внимание на то, что здесь помимо лиц, допущенных к автоматизированной обработке ПДн в автоматизированных системах необходимо указывать и тех, кто допущен к неавтоматизированной обработке ПДн (например, к бумажным папкам с личными делами сотрудников). Здесь так же, как и в политике ИБ регуляторы хотят видеть именно пофамильные списки.
04 Политика в отношении обработки персональных данных
Не путать с политикой ИБ! Тут можно резонно спросить: «А зачем нам еще одна политика?».
Часть 2 статьи 18.1 Федерального закона «О персональных данных»:
Итак, это документ, который должен быть разработан и должен быть опубликован для всех желающих. Но мы не хотим особо много рассказывать о принимаемых мерах по защите персональных данных, поэтому для выполнения требований законодательства создаем отдельный документ, где максимально абстрактно описываем все, что только можно абстрактно описать.
05-06 Приказ об определении уровня защищенности персональных данных и соответствующий акт
Здесь все то же самое, что и с классификацией ГИС. Важно: если речи идет о ГИС с персональными данными, то эти два документа не нужны, так как определение уровня защищенности ПДн уже входит в акт классификации ГИС. На самом порядке определения уровня защищенности ПДн останавливаться не будем, на эту тему уже и так много написано.
07 Правила обработки ПДн без использования средств автоматизации
Так почему-то исторически сложилось, что в вопросах защиты персональных данных много внимания уделяется этому относительно информационных систем и часто операторы забывают, что есть еще требования и по защите ПДн, обрабатываемых без использования средств автоматизации.
Такой обработке ПДн посвящено целое постановление Правительства РФ. Рассматриваемый внутренний документ как раз призван выполнить требования этого постановления. Тут главное — внимательно смотреть какие положения относятся к реальной ситуации, а какие – нет. Например, если нет проходной, на которой вахтер записывает проходящих на территорию в журнал, то соответствующие положения, касающиеся таких журналов нужно убрать.
Здесь есть еще один важный момент, который нужно прояснить. Многих могут ввести в ступор следующие положения рассматриваемого здесь постановления Правительства:
1. Обработка персональных данных, содержащихся в информационной системе персональных данных либо извлеченных из такой системы (далее — персональные данные), считается осуществленной без использования средств автоматизации (неавтоматизированной), если такие действия с персональными данными, как использование, уточнение, распространение, уничтожение персональных данных в отношении каждого из субъектов персональных данных, осуществляются при непосредственном участии человека.
2. Обработка персональных данных не может быть признана осуществляемой с использованием средств автоматизации только на том основании, что персональные данные содержатся в информационной системе персональных данных либо были извлечены из нее.
Постановление Правительство не может противоречить Федеральному закону. В итоге, неавтоматизированная обработка ПДн – все, что вне информационных систем (в основном – бумажные носители).
08 Приказ о комиссии по уничтожению ПДн и форма акта уничтожения
Документ по большей части относится к неавтоматизированной обработке, то есть, например, к уничтожению личных дел сотрудников, срок хранения которых истек. Эти документы лучше утвердить, даже если вы еще ничего не уничтожали, т. к. проверяющие часто требуют их наличия.
09 Приказ об утверждении мест хранения ПДн
Еще один документ по неавтоматизированной обработке. Здесь нужно определить места хранения тех же личных дел сотрудников в бумажном виде и ответственного за это место хранения. Местом хранения может быть шкаф, сейф, стеллаж и т. д.
10 Форма согласия субъекта на обработку его ПДн
Для случаев, когда с субъектов ПДн необходимо получать согласие в письменной форме. Здесь при изменении шаблона главное помнить, что содержание письменного согласия на обработку ПДн строго регламентировано частью 4 статьи 9 Федерального закона «О персональных данных».
11 Положение о видеонаблюдении
Документ, который требуют проверяющие, если видят в помещениях видеокамеры. Какими-то явными положениями законодательства не регламентировано. Документ простой, определяем цели видеонаблюдения и прочие очевидные вещи. Единственное, что мы сюда важное вставили — это комментарий представителей Роскомнадзора о том, что видеоизображение не является биометрическими ПДн, а то у всех проверяющих разное мнение на этот счет.
12 Форма соглашения о неразглашении персональных данных
Подписывают наши сотрудники, допущенные к обработке ПДн (как к автоматизированной, так и неавтоматизированной).
13 Журнал учета обращений граждан
Работает в связке с правилами рассмотрения запросов субъектов ПДн. Все поступающие запросы регистрируем – здесь. Проверяющие требуют наличие журнала, даже если не было ни одного запроса.
Здесь представлены документы, учитывающие требования ФСБ по обращению с криптосредствами. Соответственно, они не нужны, если криптография не применяется. Поскольку многие требования довольно старые и достаточно жесткие (один из руководящих документов аж от 2001 года), мы постарались как-то сбалансировать внутренние документы, чтобы и вам и нам, как говорится. Но проверяющие от ФСБ у нас ребята самые непредсказуемые, поэтому эти документы у нас часто дополняются и изменяются.