Аналитическая записка о защите персональных данных в системе «Первая Форма»

Аналитическая записка
о соответствии программной платформы «Первая Форма» требованиям нормативно-правовых актов Российской Федерации в области безопасности персональных данных
I. Введение. Краткое описание проблемы и предлагаемое решение

Проблема и цель

Настоящая записка описывает проблематику соответствия программной платформы «Первая форма» (далее – Приложение) нормативно-правовым актам Российской Федерации в области безопасности персональных данных (далее – ПД).


Проблема соответствия рассматривается как в общих чертах, регламентированных Федеральным законом от 27.07.2006 N 152-ФЗ «О персональных данных», так и с точки зрения внедрения Приложения в инфраструктуру конкретного заказчика, в соответствии с требованиями профильных регуляторов в области информационной безопасности (ФСТЭК[1], ФСБ[2]). В записке развернуто описан алгоритм выполнения требований подзаконных нормативно-правовых актов, в т.ч. методология моделирования угроз (анализа рисков), позволяющая организации-пользователю Приложения корректно внедрить Приложение в свою инфраструктуру (соблюсти все требования регуляторов).


Дополнительно, в формате вопрос-ответ, приводятся разъяснения по наиболее популярным вопросам организаций-пользователей.


Настоящий документ может быть использован как работниками компании-разработчика Приложения, так и сотрудниками организаций-пользователей (операторов ПД), которые испытывают затруднения с пониманием требований законодательства о безопасности ПД или его практической реализацией. Документ можно читать последовательно, либо сразу переходить к интересующему фрагменту.



Структура документа 

Раздел I формулирует ключевую проблему и цель, а также содержит справочную информацию по содержанию записки.


Раздел II описывает существующую нормативно-правовую базу в области безопасности ПД, положения которой могут применяться к Приложению. Описан порядок работы с законодательством. Рассмотрены некоторые нюансы, в т.ч. необходимость поиска недекларированных возможностей в Приложении организациями-пользователями.


Раздел III рассказывает о подходе к моделированию угроз информационной безопасности и корректном, с точки зрения правовых требований, внедрении Приложения в инфраструктуру организаций-пользователей.


В разделе IV приводятся ссылки на примеры, иллюстрирующие предлагаемый подход к моделированию угроз.


Раздел V содержит ответы на популярные вопросы клиентов.



Базовые нормативы и сокращения

В тексте документа упоминаются следующие нормативно-правовые акты:

  1. Федеральный закон от 27.07.2006 N 152-ФЗ «О персональных данных» (далее –ФЗ 152);
  2. Постановление Правительства РФ от 01.11.2012 N 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных» (далее – ПП 1119);
  3. Приказ ФСТЭК России от 11 февраля 2013 г. N 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» (далее – Пр ФСТЭК 17);
  4. Приказ ФСТЭК России от 18 февраля 2013 № 21 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных» (далее – Пр ФСТЭК 21);
  5. Постановление Правительства РФ от 15.09.2008 N 687 «Об утверждении Положения об особенностях обработки персональных данных, осуществляемой без использования средств автоматизации» (далее – ПП 687);
  6. Приказ ФСБ России от 10.07.2014 N 378 «Об утверждении Состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации требований к защите персональных данных для каждого из уровней защищенности» (далее – Пр ФСБ 387);
  7. The General Data Protection Regulation (EU) 2016/679 (далее — GDPR);
  8. Кодекс об административных правонарушениях (далее – КоАП);
  9. Трудовой кодекс (далее – ТК).
II. Нормативная база в области безопасности персональных данных

Основные требования к безопасности ПД на территории Российской Федерации устанавливает ФЗ 152. ФЗ 152 распространяется на любые типы персональных данных, которые понимаются законом как «любая информация, относящаяся к прямо или косвенно определенному или определяемому физическому лицу (субъекту персональных данных)» [3]. Таким образом, любая информация, которая позволяет однозначно идентифицировать субъекта – это ПД. Такая ситуация вызывает множество спорных вопросов и трактовок, но в конечном итоге организация-пользователь (оператор ПД в терминологии ФЗ 152) должна решить, какая именно информация относится к ПД в её случае. Для лучшего понимания рассмотрим пример ниже.


Из судебной практики: «Представитель истца {Роскомнадзора, здесь и далее прим. автора} отмечает и то, что ответчик и третьи лица используют сервисы Гугл Аналитикс и Яндекс Метрика, предназначенные для оценки посещаемости веб-сайтов и анализа поведения пользователей, их серверы также расположены на территории США, использование сервисов является действиями по сбору и обработке персональных данных, в Политике конфиденциальности интернет-ресурса https://2019.vote/ об использовании сервисов при обработке персональных данных, сведений не содержится, что также является нарушением ФЗ № 152».


Источник: https://zakon.ru/blog/2019/1/21/roskomnadzor_dobilsya_blokirovki_sajta_za_ispolzovanie_google_analytics_pri_obrabotke_personalnyh_da



Применительно к Приложению это означает, что в зависимости от состава бизнес-процессов, которые организация-пользователь реализует с помощью Приложения, в нем могут обрабатываться как минимум следующие категории ПД:

  1. Сотрудников;
  2. Клиентов (например, покупателей, пользователей услуг и т.п.);
  3. Контрагентов (например, представителей юридических лиц, с которыми устанавливаются договорные отношения, в частности паспортные данные подписантов).


Т.к. архитектурно Приложение включает в себя программную оболочку и базу данных, и в нем ведется сбор, обработка и хранение ПД, его можно отнести к информационной системе персональных данных (далее – ИСПД). По определению к таким системам относится «совокупность содержащихся в базах данных персональных данных и обеспечивающих их обработку информационных технологий и технических средств»[4].


Таким образом, в случае обработки Приложением ПД (персональных данных) – оно становится ИСПД (информационной системой персональных данных). При этом, организация-пользователь Приложения автоматически становится оператором ПД, обрабатываемых Приложением[5]. Само понятие «обработки ПД» дано в законе максимально растяжимо — согласно ФЗ 152 под обработкой понимается «любое действие (операция) или совокупность действий (операций), совершаемых с использованием средств автоматизации или без использования таких средств с персональными данными, включая сбор, запись, систематизацию, накопление, хранение, уточнение (обновление, изменение), извлечение, использование, передачу (распространение, предоставление, доступ), обезличивание, блокирование, удаление, уничтожение персональных данных». Такое определение позволяет однозначно идентифицировать работу Приложения и штатную работу пользователей с Приложением как обработку ПД.


Что же должна делать организация (оператор ПД), использующая Приложение в своей инфраструктуре? Рассмотрим совокупность применимых к Приложению нормативно-правовых актов, последовательность работы с ними и их иерархию на следующих рисунках.

Рис. 1 Алгоритм работы с нормативно правовыми актами в области ПД[6]
Рис. 2 Иерархия нормативно-правовых актов Российской Федерации в области защиты ПД

В общем виде основные применимые к организации-пользователю Приложения (как к оператору ПД[7]) требования по информационной безопасности отражены в Главах 2 и 4 ФЗ 152.



Ниже перечень наиболее важных, на наш взгляд, требований к информационной безопасности[8]:


1) Ст. 18.1 ФЗ 152: «Меры, направленные на обеспечение выполнения оператором обязанностей, предусмотренных настоящим Федеральным законом» — эти требования можно назвать организационно-правовыми, и именно их проверяет главный регулятор в области безопасности ПД Роскомнадзор;


2) Статья 19 ФЗ 152: «Меры по обеспечению безопасности персональных данных при их обработке» — эти требования можно назвать организационно-техническими, и их уполномочены проверять лишь ФСТЭК и ФСБ[9]. Роскомнадзор не имеет такого права (а именно Роскомнадзор проводит проверки в коммерческих, негосударственных организациях), что существенно снижает риски несоответствия данным требованиям (р. III и IV данного документа описывает реализацию именно этой части требований);


3) Приложение к ПП 1119: «Требования к защите персональных данных при их обработке в информационных системах персональных данных»;


4) Приложение к Пр ФСТЭК 21: «Состав и содержание организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных».



На основании содержании приведенных выше нормативно-правовых актов можно задать следующий алгоритм действий для ИСПД (и Приложения, в частности):

1. Определение ответственных за обеспечение безопасности ПД в ИСПД (назначение организатора обработки ПД в организации и назначение ответственного за техническую защиту, определение лиц, имеющих доступ к ПД);

2. Подготовка (обучение) должностных лиц, ответственных за обеспечение безопасности ПД в ИСПД;

3. Сбор и анализ исходных данных по информационной системе с формированием перечня обрабатываемых ПД и выделением ИСПД в информационно-технологической инфраструктуре организации;

4. Классификация ИСПД с определением необходимого уровня защищенности;

5. Построение (формирование) частной модели угроз и модели нарушителей;

6. Разработка (проектирование) системы защиты персональных данных в ИСПД;

7. Разработка документов, регламентирующих вопросы организации обеспечения безопасности ПД и эксплуатации системы защиты персональных данных (например, частных политик информационной безопасности, инструкций администраторов безопасности и т.п.);

8. Развертывание, настройка и ввод в опытную эксплуатацию системы защиты;

9. Испытание системы защиты в процессе опытной эксплуатации;

10. Получение лицензий (если необходимо, например, в случае если внедрение происходит внутри группы компаний и одно юрлицо будет оказывать другим юрлицам услуги в области информационной безопасности, в т.ч. настраивать и администрировать средства защиты информации);

11. Уведомление уполномоченного органа о начале обработке ПД (или изменениях в существующих процессах обработки в связи с внедрением новой ИСПД) – делается на портале Роскомнадзора по адресу: https://pd.rkn.gov.ru/ , а затем дублируется в письменном виде[10];

12. Организация внутреннего контроля за соблюдением условий использования средств защиты информации и выполнения требований законодательства о безопасности ПД.



Рассмотрим подробнее ключевые требования, которые необходимо соблюсти при внедрении очередной ИСПД, в т.ч. Приложения:


1. На основании ФЗ 152 в обязанности организации-пользователя Приложения входит:

a) П. 3 ч. 1 ст. 18.1 «применение правовых, организационных и технических мер по обеспечению безопасности персональных данных в соответствии со статьей 19 настоящего Федерального закона»;

b) П. 5 ч. 1 ст. 18.1 «оценка вреда, который может быть причинен субъектам персональных данных в случае нарушения настоящего Федерального закона, соотношение указанного вреда и принимаемых оператором мер, направленных на обеспечение выполнения обязанностей, предусмотренных настоящим Федеральным законом»;

c) П. 1-4 ч. 2 ст. 19

«1) определение угроз безопасности персональных данных при их обработке в информационных системах персональных данных;

2) применение организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных, необходимых для выполнения требований к защите персональных данных, исполнение которых обеспечивает установленные Правительством Российской Федерации уровни защищенности персональных данных;

3) применение прошедших в установленном порядке процедуру оценки соответствия средств защиты информации;

4) оценка эффективности принимаемых мер по обеспечению безопасности персональных данных до ввода в эксплуатацию информационной системы персональных данных».



2. На основании ПП 1119 организация-пользователь должна:

a) Построить систему безопасности персональных данных, см. П. 2 Приложения. Там использована следующая формулировка: «Безопасность персональных данных при их обработке в информационной системе обеспечивается с помощью системы защиты персональных данных, нейтрализующей актуальные угрозы, определенные в соответствии с частью 5 статьи 19 Федерального закона «О персональных данных». Система защиты персональных данных включает в себя организационные и (или) технические меры, определенные с учетом актуальных угроз безопасности персональных данных и информационных технологий, используемых в информационных системах;

b) Выбрать защитные меры на основании документов ФСТЭК (Пр ФСТЭК 21) и ФСБ (Пр ФСБ 378), в соответствии с актуальными угрозами и требованиями для ИСПД, зависящих от типа ИСПД (см. рис. 2 ниже), см. П. 4 Приложения. Там использована следующая формулировка: «Выбор средств защиты информации для системы защиты персональных данных осуществляется оператором в соответствии с нормативными правовыми актами, принятыми Федеральной службой безопасности Российской Федерации и Федеральной службой по техническому и экспортному контролю во исполнение части 4 статьи 19 Федерального закона «О персональных данных».

Рис. 3 Классификаций уровней защищенности ИСПД (в зависимости от типа ИСПД, в соответствии с требованиями ПП 1119).[11]

Определение актуальных угроз находится в зоне ответственности организации-пользователя (оператора ИСПД), которая в соответствии с ФЗ 152 организует работу внутренних экспертов или нанимает сторонние организации для проведения анализа актуальных для данной организации угроз и выбора необходимых защитных мер. Подробнее этот вопрос рассматривается в разделе III настоящего документа.


Важно отметить, что ни сертификация на отсутствие недекларированных возможностей, ни какой-то иной способ анализа уязвимостей[12] в прикладном программном обеспечении не является обязательным для внедряемого в компании прикладного программного обеспечения. В настоящий момент подобные меры установлены лишь для средств защиты информации, которые используются в государственных информационных системах. Для прикладного программного обеспечения, вне зависимости от места использования, такие требования не установлены. Подробнее этот вопрос разобран в разделе V данного документа.


Рассмотрим некоторые вопросы подробнее.

II.1 Форма собственности организации пользователя

Первый вопрос, который необходимо выяснить – форма собственности организации, осуществляющей внедрение Приложения: государственная (муниципальная) или частная (коммерческая)?



К информационным системам государственных и муниципальных органов, на основании Пр ФСТЭК 17[13], применимы дополнительные требования законодательства[14]. Давайте рассмотрим их:

1. Согласно п. 13 Приложения к Пр ФСТЭК 17: «Для обеспечения защиты информации, содержащейся в информационной системе, проводятся следующие мероприятия: ……. аттестация информационной системы по требованиям защиты информации (далее — аттестация информационной системы) и ввод ее в действие;», т.о. из документа следует, что для государственной информационной системы оператор ПД должен организовать проведение аттестационных испытаний.


2. П. 17 (п. 17.1 – п. 17.6) того же документа детализирует требования к аттестации, в т.ч. декларирует, что : «В качестве исходных данных, необходимых для аттестации информационной системы, используются модель угроз безопасности информации, акт классификации информационной системы, техническое задание на создание информационной системы и (или) техническое задание (частное техническое задание) на создание системы защиты информации информационной системы, проектная и эксплуатационная документация на систему защиты информации информационной системы, организационно-распорядительные документы по защите информации, результаты анализа уязвимостей информационной системы, материалы предварительных и приемочных испытаний системы защиты информации информационной системы, а также иные документы, разрабатываемые в соответствии с настоящими Требованиями», а также уточняет, что аттестация производится в отношении «сегментов информационной системы», и т.о. образом затрагивает не только Приложение, но и конкретную среду функционирования, уникальную для организации-пользователя.


На выходе имеем, что при использовании Приложения в государственных (муниципальных) органах Приложение следует рассматривать как государственную информационную систему и необходимо соблюдать требования к корректному внедрению ИСПД и ее аттестации (либо переаттестации уже существующей информационной системы, если Приложения описывается как составной элемент более крупной системы, например государственной информационной системы «Локальная сеть ФОИВ»). При этом, разработчик Приложения не обязан и не может участвовать в организации аттестации – для этого нужна специальная компания-лицензиат ФСТЭК, которая проведет необходимые работы. В этой ситуации роль разработчика сводима к оказанию технической поддержки в процессе интеграции Приложения в инфраструктуру заказчика и консультациям по возникающим вопросам. Важно отметить, что при проведении работ с государственными и муниципальными информационными системами достаточно использовать только Пр ФСТЭК 17 и можно (нужно) игнорировать содержимое Пр ФСТЭК 21[15].



Дополнительные требования, применимые к этому типу организаций сформулированы в двух документах:

1. Постановлении Правительства от 21 марта 2012 г. № 211 «Об утверждении перечня мер, направленных на обеспечение выполнения обязанностей, предусмотренных Федеральным законом «О персональных данных» и принятыми в соответствии с ним нормативными правовыми актами, операторами, являющимися государственными или муниципальными органами»;


2. Постановлении Правительства от 6 июля 2015 г. № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации».



Данные требования лишь уточняют вышеупомянутый алгоритм и приводятся в качестве дополнительных сведений для организаций-пользователей, которые захотят в полной мере реализовать все применимые к государственным и муниципальным органам требования.

За рамками данного исследования остаются требования, применяемые к системам, используемым для обработки государственной тайны, что обусловлено действующим режимом ограниченного доступа к таким требованиям.


Напоследок рассмотрим случай регулирования для частных (коммерческих) организаций. В этом случае, согласно Пр ФСТЭК 21: «…Для выполнения работ по обеспечению безопасности персональных данных при их обработке в информационной системе в соответствии с законодательством Российской Федерации могут привлекаться на договорной основе юридическое лицо или индивидуальный предприниматель, имеющие лицензию на деятельность по технической защите конфиденциальной информации»[16], «…Меры по обеспечению безопасности персональных данных реализуются в рамках системы защиты персональных данных, создаваемой в соответствии с Требованиями к защите персональных данных при их обработке в информационных системах персональных данных, утвержденными постановлением Правительства Российской Федерации от 1 ноября 2012 г. N 1119, и должны быть направлены на нейтрализацию актуальных угроз безопасности персональных данных[17]» и «…Меры по обеспечению безопасности персональных данных реализуются в том числе посредством применения в информационной системе средств защиты информации, прошедших в установленном порядке процедуру оценки соответствия, в случаях, когда применение таких средств необходимо для нейтрализации актуальных угроз безопасности персональных данных[18]».



Т.о. для частных (коммерческих) организаций порядок внедрения Приложения выглядит значительно проще, чем для государственных. Для них не установлены требования по аттестации ИСПД, нет необходимости защищать ИСПД наложенными поверх сертифицированными средствами защиты[19] (формулировка «прошедшие в установленном порядке процедуру оценки соответствия» позволяет выносить соответствующие заключение о любом средстве защиты на основании программы и методики испытаний, без обязательной сертификации средства защиты в системе ФСТЭК – что могут организовать многие системные интеграторы или дистрибьюторы, осуществившие поставку используемых в организации средств защиты информации[20], либо это возможно сделать собственными силами организации).

II.2 Применимые дополнительные или отраслевые требования

Второй вопрос – это наличие каких-то дополнительных, отраслевых требований. Организации-пользователю необходимо самостоятельно ответить на следующие вопросы:

1. Существует ли какой-то курирующий орган власти или головная организация, которая устанавливает отраслевые, корпоративные или иные стандарты в области информационной безопасности (например, министерство для государственных органов; или центральный офис для территориально распределенных компаний)?


2. Есть ли какие-то дополнительные договоры или обязательства, вызывающие дополнительные требования к безопасности (например, организация является частью индустрии платежных карт и обрабатывает в Приложении их PAN, что делает применимым к приложению нормы стандарта PCI DSS; альтернативные ветки законодательства, в частности безопасность КИИ)?



На основании полученного анализа рекомендуется провести сопоставление требований законодательства в области ПД и иных применимых требований, чтобы максимально гармонизировать реализуемые меры защиты: попытаться одновременно удовлетворить всем требованиям ценой минимальных усилий. В противном случае может возникнуть проблема с усложнением системы управления информационной безопасности, в т.ч. с существованием множества параллельных документов (политик, регламентов, инструкций) и разными системами защиты информации, что будет причиной снижения управляемости, прозрачности и может привести к реальным инцидентам информационной безопасности[21].

Рис. 4 Пример дополнительных требований Банка России для финансовых организаций в области информационной безопасности [22] (П – Положения Банка России; У – Указания Банка России).
II.3 Общие требования к ИСПД

Наконец третий вопрос – это соблюдение универсальных требований к ИСПД при внедрении Приложения в инфраструктуру организации-клиента в качестве одной из ИСПД. В преамбуле к настоящему разделу был приведен краткий алгоритм действий. Детализируем и уточним этот алгоритм, оставляя за скобками неприменимые требования, в т.ч. к бумажной обработке или криптографической защите.


Все начинается с классификации ИСПД и выбора уровня защищенности. От классификации зависит сложность необходимых требований, а, следовательно, цена и время создания системы защиты. Здесь важно соблюсти баланс – не занизить класс или уровень системы, так как это приведет к тому, что не все угрозы будут нейтрализованы, но и не завысить класс или уровень – это приведет к росту стоимости внедрения и обслуживания. Следует стараться оценивать систему объективно.


Работы по классификации проводятся организацией-пользователем самостоятельно или с привлечением подрядчика и включают:

1. Создание комиссии по классификации ИС (например, председатель и члены комиссии).

2. Классификацию ИС. Класс определяется согласно положениям ПП 1119 для ИСПД и Пр ФСТЭК 17 для государственных информационных систем[23] (см. рис. 3 данного документа).

3. Утверждение актов классификации[24].



Далее в рамках классификации определяется уровень защищенности ИСПД. Уровень защищенности ПД устанавливается на основании ПП 1119. Всего существует четыре уровня:

1. УЗ-1;

2. УЗ-2;

3. УЗ-3;

4. УЗ-4.


Самый высокий уровень защищенности УЗ-1, к нему предъявляются максимальные требования, самый низкий — УЗ-4.



На уровень защищенности влияют:

1. Актуальный тип угроз – на усмотрение эксперта, исходя из модели угроз — ни в одном документе не указано четко, какой тип угроз к кому применяется, поэтому организация должна выбрать тип угроз под свою ответственность (например, с помощью создания комиссии, которая утверждает актуальный тип либо для всей организации, либо для конкретной ИСПД);

2. Категории персональных данных – общедоступные, специальные, биометрические, иные. Категории определяются комиссией, нужно учитывать определения ФЗ 152 и разъяснения Роскомнадзора[25].

3. Принадлежность ПД – данные сотрудников/других лиц.

4. Объем базы – измеряется в субъектах, градация – больше/меньше 100.000.



Для государственных (муниципальных) информационных систем понятие «уровень защищенности» заменяется на идентичное «класс защищенности» (особенность различий в терминологии Пр ФСТЭК 17 и Пр ФСТЭК 21). Как было упомянуто в разделе II.1 если ПД обрабатываются в ГИС, то классификацию нужно проводить по Пр ФСТЭК 17. Существует три класса:

1. К1;

2. К2;

3. К3.


Самый высокий класс — К1, к нему предъявляются максимальные требования, самый низкий — К3. На класс влияют уровень значимости информации и масштаб системы. Уровень значимости в свою очередь определяется степенью возможного ущерба от нарушения конфиденциальности, целостности и доступности. Масштаб чаще всего определяется однозначно и его сложно изменить, а возможный ущерб остается на усмотрение экспертов.

II.4 Иные требования к ПД

Четвертый вопрос – это обоснованность обработки. С точки зрения ФЗ 152 любая обработка должна быть обоснована, поэтому в рамках классификации ИСПД рекомендуется провести инвентаризацию бизнес-процессов, в ходе которой установить основания обработки для каждого типа ПД (договор, соглашение, нормативно-правовой акт и т.п.). Даже при выполнении всех остальных требований законодательства и обеспечении сохранности ПД в Приложении, сбор и обработка ПД без согласия субъекта – может являться нарушением и повлечь за собой штрафы и иные наказания регуляторов. Аналогично должны прорабатываться вопросы сроков хранения, удаления, уточнения или изменения ПД. Все эти процессы должны быть обоснованы и соответствовать всем применимым нормам ФЗ 152.

III. Подход к моделированию угроз безопасности персональных данных

Для ИСПД уровень защищенности определяется исходя из типа актуальных угроз. Давайте разберемся, как это происходит.


Модель угроз – это ключевой документ, от того, что в нем написано зависят применимые организационные и технические меры, что было обосновано в преамбуле к разделу II.


Обычно разделяют модели угроз по требованиям ФСТЭК и ФСБ, либо делают общую модель угроз и нарушителя[26]. Требования ФСБ к Приложению не применимы, т.к. оно не использует в своем составе средств криптографической защиты информации (т.н. СКЗИ).



Для моделирования по требованиям ФСТЭК России можно использовать следующие ресурсы:

1. Методика определения актуальных угроз безопасности персональных данных при их обработке в информационных системах персональных данных[27];

2. Базовая модель угроз безопасности персональных данных при их обработке в информационных системах персональных данных;

3. Проект «Методики моделирования угроз безопасности информации», 2020 года (не принят официально по состоянию на май 2020);

4. База данных угроз и уязвимостей ФСТЭК — https://bdu.fstec.ru/.



До официального утверждения новой Методики действующая Методика определения актуальных угроз является костяком модели, из базовой модели и базы данных угроз и уязвимостей берутся угрозы с описаниями. Основой являются Методические рекомендации по разработке нормативных правовых актов, определяющих угрозы безопасности персональных данных, актуальные при обработке персональных данных в информационных системах персональных данных, эксплуатируемых при осуществлении соответствующих видов деятельности[28].



После того, как модель или модели угроз (и нарушителя) построены мы переходим к применимым требованиям.


Актуальные требования берутся из всех применимых нормативов, список которых у вас получился на основании проработки раздела II.


Исходя из уровня защищенности персональных данных (или класса защищенности для государственных информационных систем), согласно применимым к нашей ИСПД нормативно-правовым актам, определяются требования к системе защиты ПД.



Необходимую работу можно представить в виде алгоритма:

1. Выбираем из документов все требования, в соответствии с уровнем защищенности ПД (классом для государственных (муниципальных) информационных систем).[29]

2. Ищем одинаковые или похожие требования. Например, в Пр ФСБ 378 есть прямое цитирование п. 13 из ПП 1119.

3. Убираем дублирование, похожие требования объединяем.

4. Убираем все, что для нас неактуально (неприменимо): неиспользуемые технологии, неактуальные угрозы.



В итоге получается файл с требованиями. Теперь необходимо выбрать защитные меры.

Для определения необходимых мер защиты составляем следующую таблицу:

Таблица 1. Требования, меры и документы

Важно осознавать, что поле «Документ» Таблицы 1 не может быть пустым. Меры всегда должны отражаться в документах. Как составить список необходимой для разработки документации? Названия документов можно взять из ФЗ «О персональных данных». Но там они присутствуют в неявном виде. Точного списка необходимых документов нигде нет, но можно ориентироваться на материалы проверок Роскомнадзора и их типовые запросы[30], а также на Постановление Правительства от 21 марта 2012 г. № 211[31].


Техническая мера – это, в основном, установка и настройка средств защиты информации. Сертифицированные средства защиты в ИСПД применяются для обеспечения 1 и 2 уровней защищенности персональных данных, а также для обеспечения 3 уровня защищенности персональных данных в информационных системах, для которых к актуальным отнесены угрозы 2-го типа. Для государственных (муниципальных) информационных систем всегда применяются сертифицированные СЗИ[32]. Именно поэтому в разделе II.3 такое внимание было уделено вопросам определения уровня защищенности (класса защиты).



По итогам проведенных работ необходимо закрепить результаты, иначе внедрение будет неполноценным и нарушит требования регуляторов. Возможны два варианта такого закрепления:

1. Аттестация (обязательно для государственных информационных систем);

2. Декларирование соответствия (допустимо для коммерческих организаций, вместо обременительной аттестации).



Согласно требованиям ФСТЭК аттестация обязательна для государственных (муниципальных) информационных систем и является добровольной мерой для ИСПД[33] коммерческих (частных) организаций. Т.о. для государственных информационных систем используется Пр ФСТЭК 17 с учетом ГОСТ РО 0043-003-2012 Защита информации. Аттестация объектов информатизации. Общие положения и ГОСТ РО 0043-004-2013 «Защита информации. Аттестация объектов информатизации», при этом:

1. Аттестационные испытания не могут проводиться должностными лицами, осуществляющими проектирование и (или) внедрение системы защиты информации информационной системы.

2. Аттестат выдается на весь срок эксплуатации информационной системы.



Для негосударственных ИСПД оценка эффективности мер проводится самостоятельно или с привлечением организации, имеющей лицензию по ТЗКИ[34] (техническую защиту конфиденциальной информации). При этом форма оценки эффективности, а также форма и содержание документов, разрабатываемых по результатам оценки, не установлены. Такую аттестацию можно проводить в соответствии с вышеупомянутыми ГОСТ, по содержанию Пр ФСТЭК 21.


Оценка эффективности реализованных в рамках системы защиты персональных данных мер по обеспечению безопасности персональных проводится не реже одного раза в 3 года. Для негосударственных ИСПД рекомендуется ограничиться декларированием и выпустить документ «Оценка эффективности реализованных в рамках системы защиты персональных данных мер по обеспечению безопасности персональных».


По окончании работы важно помнить, что работа не заканчивается и теперь нужно контролировать защищенность персональных данных. ФЗ 152 устанавливает обязанность оператора ИСПД осуществлять внутренний контроль и (или) аудит соответствия обработки персональных данных требованиям законодательства, политике оператора в отношении обработки персональных данных, локальным актам оператора, а также осуществлять контроль за принимаемыми мерами по обеспечению безопасности персональных данных и уровня защищенности информационных систем персональных данных. Организовать это должно лицо, ответственное за организацию обработки персональных данных. Соответственно, от организации-пользователя Приложения требуются подтверждения проведения такого контроля (например, акты), которые устанавливают:

1. Законность обработки персональных данных;

2. Соответствие принимаемых мер требованиям безопасности персональных данных;

3. Соответствие обработки ПД локальным актам оператора, в первую очередь, политике оператора в отношении обработки ПД;

4. Своевременное обучение и ознакомление работников оператора, непосредственно осуществляющих обработку персональных данных, с положениями законодательства и локальными актами по вопросам обработки персональных данных.



Все это необходимо и будет проверяться Роскомнадзором в рамках их прав и обязанностей, установленных Постановлением Правительства РФ от 13 февраля 2019 г. № 146 «Об утверждении Правил организации и осуществления государственного контроля и надзора за обработкой персональных данных», важно помнить, что на основании данного постановления Роскомнадзор не может проверять технические меры защиты, регламентируемые Пр ФСБ 378 и Пр ФСТЭК 21, ограничиваясь содержанием ст. 18.1 ФЗ 152 и не затрагивая содержимое ст. 19. Проверки технических мер защиты по указанным требованиям ФСБ и ФСТЭК могут проводиться данными регуляторами самостоятельно лишь в отношении организаций-лицензиатов ФСБ (лицензии на работу со средствами криптографической защиты информации) и ФСТЭК (лицензии на техническую защиту конфиденциальной информации), которые отсутствуют у большинства проверяемых на соответствие законодательству о ПД организаций. Т.о. масштаб проверки обычно ограничен сферой ответственности Роскомнадзора, хотя это и не исключает погружения проверяющих в особенности технической реализации ИСПД[35].

IV. Примеры реализации

В качестве примеров реализации предложенного в разделе III подхода рекомендуется самостоятельно проработать материалы вебинара «Межблогерский вебинар. Угрозы БДУ vs Меры защиты»: https://www.youtube.com/watch?v=uPslOOBmesc, по ссылкам к которому приведены примеры документов, которые можно использовать в качестве дополнительных источников к упомянутым выше материалам ФСТЭК. Сам вебинар является практической иллюстрацией работы экспертного метода, упомянутого в разделе III настоящего документа. Приведенные ссылки могут послужить дополнительным авторитетным источником для обоснования экспертной комиссией принятия того или иного решения в отношении классификации ИСПД (например, выбора более низкого типа угрозы и снижения требований к защитным мерам).

V. Популярные вопросы и ответы на них

1). Есть ли обязательные требования по сертификации Приложения на отсутствие недекларированных возможностей, в рамках требований ФСТЭК?

Короткий ответ: нет, такие требования отсутствуют. Подобные требования существовали раньше исключительно для средств защиты информации. В настоящий момент требования по контролю отсутствия недекларированных возможностей не применяются ФСТЭК, уступив место концепции оценочных уровней доверия[36]. Действующие требования по сертификации средств защиты по уровням доверия не применимы к Приложению, т.к. оно не является средством защиты.



Длинный ответ: Требований ФСТЭК к сертификации прикладного программного обеспечения никогда не существовало. Но может быть имеет смысл провести подобную оценку, например по оценочным уровням доверия? У такого решения есть два аспекта:

1. Правовой – провести исследование, чтобы в случае вопросов регуляторов показать результат отчета или сертификат, и сказать, что ПО соответствует всем требованиям, а потому безопасно;

2. Практический – убедиться в отсутствии уязвимостей или внести доработки, чтобы надежно защитить информационную систему, и т.о. предотвратить реальные инциденты информационной безопасности.


Рассмотрим эти аспекты. Начнем с правового.

Вспомним, что в нормативно-правовых актах (см. разделы II и III данного документа) многократно подчеркивается, что выбор конкретных организационных или технических мер защиты – прерогатива организации-пользователя[37] (оператора ПД в терминологии ФЗ 152), а любые недочеты (уязвимости) ИСПД могут компенсироваться наложенными «сверху» мерами защиты (в т.ч. специальными техническими средствами: межсетевыми экранами, средствами обнаружения вторжений, модулями доверенной загрузки и т.д.). При этом, в профильных приказах регуляторов (ФСТЭК, ФСБ) нет мер защиты, устанавливающих анализ уязвимостей или поиск недекларированных возможностей схожих с аналогичными подходами при сертификации средств защиты. Упомянутая в Пр ФСТЭК 17 и 21 мера «АНЗ.1 Выявление, анализ уязвимостей информационной системы и оперативное устранение вновь выявленных уязвимостей», как видно из текста документов, относится не к поиску недекларированных возможностей или аудиту исходного кода, а к обыкновенному анализу защищенности информационной системы, в т.ч. с использованием сканеров уязвимостей и сторонних источников информации[38]. Т.о. никаких правовых требований к проведению данного вида работ нет, а значит и санкций за их невыполнение быть не может. Кроме того, Роскомнадзор, который приходит на проверки в коммерческие организации в принципе не проверяет технические меры защиты, т.к. не уполномочен этого делать[39], а ФСБ и ФСТЭК может прийти лишь к своим лицензиатам, либо в государственные (муниципальные) органы[40]. Т.о. с точки зрения соответствия требованиям регулятора подобное решение (поиск недекларированных возможностей, анализ защищенности, аудит исходного кода и т.п.) – не имеет смысла.


Теперь рассмотрим практический аспект – реальную безопасность ПД.

С точки зрения реальной безопасности необходимо признать, что недекларированные возможности могут находиться, где угодно в рамках сегмента сети, в который внедряется ИСПД. Начиная от офисных приложений на компьютерах пользователей, заканчивая серверными приложениями, реализующими функции систем управления базами данных, веб-серверов, операционных систем (и это, не говоря о потенциальных уязвимостях аппаратуры, в т.ч. сетевой, в т.ч. доступной из интернет). Поэтому с точки зрения возможности реальной атаки и потенциального риска – непонятно, почему нужно тратить ресурсы на анализ именно Приложения силами специализированной организации? Почему такие работы не должны проводится в отношении любого прикладного программного обеспечения в выбранном сегменте сети? Здесь мы упираемся в нехватку временных и финансовых ресурсов, а также в тот факт, что из-за регулярного обновления приложений результаты проведенных работ становятся недействительными[41] (как де-юре, если речь идет о сертификации; так и де-факто – любое обновление может содержать в себе уязвимость, бэкдор и т.п. прелести). Поэтому в рамках реализации защитных мер и построения эффективной системы защиты рекомендуется использовать общий, универсальный подход — в рамках гипотетического инцидента нет большой разницы, как именно была скомпрометирована сеть и обрабатываемые ПД, важен сам факт компрометации и полученный ущерб, поэтому если мера защиты не может быть последовательно реализована – лучше отказаться от нее и использовать более эффективные альтернативы, которые можно реализовать без ограничений и полумер. Дополнительная возможность компании-разработчика предоставить организациям-пользователям Приложения свидетельства, подтверждающие ответственный подход разработчика к безопасности своего продукта и соблюдение им принципов безопасной разработки в рамках жизненного цикла продукта (например, отчеты с результатами пентеста; результаты аудита исходного кода; описания изменений, в т.ч. исправляющих аспекты безопасности) – является дополнительным подтверждением реальной безопасности продукта, и не требует от пользователей приложения организации дорогостоящих сертификаций по формальным требованиям ФСТЭК. Сама же организация-пользователь, желающая получить надежную ИСПД, может организовать тестирование на проникновение и анализ защищенности всей локальной сети, или сегмента, в котором функционирует Приложение.



Такое решение представляется гораздо более рациональным, нежели избыточные траты ресурсов на отдельное выбранное Приложение. При этом, если Приложение внедряется в государственном (муниципальном) органе, нельзя забывать о необходимости выполнение действий, описанных в р. II.1 данного документа.



2). Наша компания использует Приложение для автоматизации различных «несовместимых» бизнес-процессов, например, работы с клиентами (заказчиками) и взаимодействия с контрагентами (поставщиками). Не приводит ли это к нарушению требований 152-ФЗ о совместимости целей обработки (согласно ч. 3 ст. 5 ФЗ 152)?

Понятие «совместимости целей обработки» ПД не определено четко законом, оставляя пространство для трактовок со стороны регуляторов. Но в общем случае вы всегда можете рассмотреть свою организацию, с различными бизнес-процессами и подразделениями, как единое целое. Например, у вас есть отдел работы с клиентами (заключает договора о продаже услуг) и кадровый отдел (обрабатывает документы по сотрудникам). Оба отдела работают в Приложении, соответственно в одной базе данных обрабатываются ПД от разных бизнес-процессов, и тут возникает вопрос о совместимости целей обработки.


В такой ситуации можно сказать, что оба эти процесса «осуществляются для реализации уставных задач организации, в том числе предоставление услуг контрагентам и обеспечения операционной деятельности», а после поставить двоеточие и описать все частные процессы. В качестве источника вдохновения можно использовать Реестр операторов персональных данных: https://rkn.gov.ru/personal-data/register/?id=08-0003937, а в качестве наиболее авторитетного примера – информацию, которую главный регулятор – Роскомнадзор – указал в отношении себя[42].


Главное не забыть отразить это во всех сопутствующих документах, в т.ч. согласиях и политики безопасности персональных данных.


[1] Говоря упрощенно ФСТЭК занимается всеми вопросами информационной безопасности, кроме криптографической защиты и реагирования на инциденты. Подробнее о полномочиях службы можно прочитать на официальном сайте регулятора: https://fstec.ru/obshchaya-informatsiya/polnomochiya;


[2] ФСБ отвечает за вопросы криптографической защиты информации (в т.ч. шифрование персональных данных при их передаче по сети интернет) и реагирование на инциденты информационной безопасности (в рамках законодательства о критической информационной инфраструктуре, не относящегося напрямую к вопросам безопасности ПДн.). Подробности о деятельности службы можно уточнить на официальном сайте: http://www.fsb.ru/fsb/supplement.htm


[3] П. 1 ст. 3 упомянутого закона.


[4] П. 10 ст. 3 там же.


[5] Важно понимать, что исходя из формулировок ФЗ 152 – любое юрлицо или индивидуальный предприниматель автоматически становятся оператором ПД в момент своего создания, т.к. как минимум ведут обработку ПД своих учредителей и работников. Ответ на закономерно возникающий вопрос о несоответствии числа зарегистрированных операторов ПД (чуть более 400 тыс.) числу существующих юрлиц и индивидуальных предпринимателей (более 3 млн.) остается за рамками настоящего документа – читатель может самостоятельно сделать выводы о соблюдении требований законодательства в области ПД на территории Российской Федерации.


[6] Источник алгоритма — семинар К. Шудровой «Персональные данные 2019: практические вопросы», представленный на конференции Payment Security. Рекомендуется для изучения ответственным за ПД: https://www.youtube.com/watch?v=qGqUkSXi1xI&t=4229s , https://paymentsecurity.ru/paymentsecurity-2019/


[7] Обоснование отнесения организации-пользователя Приложения к числу операторов ПД было дано выше.


[8] Если ранее читатель не знакомился с оригиналом ФЗ 152, рекомендуется прочитать данный закон полностью, в последней актуальной на момент чтения редакции. Для нужд документа (описание соответствия Приложения требованиям к безопасности ПД) из рассмотрения записки исключен ряд статей, которые тем не менее могут быть важны и полезны для оператора ПД, в т.ч. сбор согласий на обработку ПД с субъектов (ст. 9), локализация сбора ПД в России (ч. 5 ст. 18), уведомление об обработке (ст. 22) Роскомнадзора и другие моменты. Важно помнить, что любая обработка ПД – должна быть обоснована и согласована с субъектом ПД в установленном порядке.


[9] Теоретически такую проверку может инициировать прокуратура или правительство, привлекая к подобной проверке экспертов ФСТЭК и ФСБ, но на практике такие случаи являются редчайшим исключением из правил и статистика по ним у автора отсутствует. Важно понимать, что данную статью не уполномочен проверять главный регулятор – Роскомнадзор, и что он не имеет права, даже при желании, привлекать к проверкам ФСТЭК и ФСБ. Полномочия Роскомнадзора установлены в Постановлении Правительства РФ от 13 февраля 2019 г. № 146 «Об утверждении Правил организации и осуществления государственного контроля и надзора за обработкой персональных данных»


[10] С подробностями процесса можно ознакомиться в документации регулятора о порядке уведомления об обработке ПД, которая опубликована по адресу: https://pd.rkn.gov.ru/library/p193/p199/ .


[11] Источник изображения: семинар К. Шудровой «Персональные данные 2019: практические вопросы», представленный на конференции Payment Security.


[12] Например, в рамках ГОСТ 15408 и концепции оценочных уровней доверия.


[13] См. п. 2 и 3 указанного документа.


[14] Подробное содержание понятия «государственная информационная система» приводится в ст. 14 Федерального закона от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации», там же приведены критерии отнесения ИСПД к категории «государственной», что делает необходимым соблюдение требований 17 Пр ФСТЭК.


[15] Помимо информационного письма ФСТЭК от 15 июля 2013 г. N 240/22/2637 с разъяснениями по этому вопросу (см. https://fstec.ru/component/content/article/64-deyatelnost/tekushchaya/informatsionnye-i-analiticheskie-materialy/716-informatsionnoe-soobshchenie-fstek-rossii-1) в последней редакции 17 Пр ФСТЭК в п. 27 Приложения явно указано соотношение между нормами 17 Пр ФСТЭК и требованиями к безопасности ПД.


[16] П. 2 Приложения к указанному документу.


[17] П. 3 Приложения к указанному документу.


[18] П. 4 там же.


[19] Есть важный нюанс, согласно п. 12 Приложения к 21 Пр ФСТЭК: «Для обеспечения 1 и 2 уровней защищенности персональных данных, а также для обеспечения 3 уровня защищенности персональных данных в информационных системах, для которых к актуальным отнесены угрозы 2-го типа, применяются сертифицированные средства защиты информации, программное обеспечение которых прошло проверку не ниже чем по 4 уровню контроля отсутствия недекларированных возможностей.», т.е. использовать несертифицированные средства защиты можно лишь при условии соответствующего моделирования угроз (см. р. III настоящего документа).


[20] Данная позиция аргументируется отечественным методологом информационной безопасности А. Лукацким. С развернутым обоснованием этой позиции и альтернативным мнением можно ознакомиться здесь: https://lukatsky.blogspot.com/2018/09/blog-post_27.html , но важно понимать, что де-юре позиция верна. Кроме того, по аналогии права, можно ссылаться на п. 28 Приложения к Приказу ФСТЭК от 25 декабря 2017 г. N 239 «Об утверждении требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры российской федерации» (в ред. приказа ФСТЭК России от 26 марта 2019 г. № 60), где прямо прописана возможность проведения оценки соответствия юрлицом самостоятельно, в форме приемки и испытаний.


[21] Подробный разбор проблемы и предлагаемого решения приводится в вебинаре автора «Как пережить комплаенс», ссылка: https://www.youtube.com/watch?v=gVhvqJx1CxI


[22] Источник: А. Лукацкий: https://lukatsky.blogspot.com/


[23] См. р. II.1 настоящего документа.


[24] Здесь и далее: образцы сопутствующих документов легко находятся в сети интернет (например, акт классификации ИСПД: http://www.ispdn.info/articles/akt-klassifikatsii-ispdn/), многие документы опубликованы в открытом доступе самими операторами ПД (например, «Модель угроз и нарушителя безопасности персональных данных при их обработке в информационной системе персональных данных центрального аппарата ФНС России»: http://base.garant.ru/70112476/3e22e51c74db8e0b182fad67b502e640/).


[25] См. Разъяснения Роскомнадзора по вопросам, касающимся обработки персональных данных работников, соискателей на замещение вакантных должностей, а также лиц, находящихся в кадровом резерве. 14 декабря 2012 года и Разъяснения Роскомнадзора по вопросам отнесения фото-, видеоизображений, дактилоскопических данных и иной информации к биометрическим персональным данным и особенностей их обработки. 02 сентября 2013 года, опубликованные на портале https://pd.rkn.gov.ru/.


[26] Есть любопытная особенность – угрозы лучше прописаны в документации ФСТЭК, а типы нарушителей – в документации ФСБ.


[27] Доступно для скачивания на сайте ФСТЭК: https://fstec.ru/normotvorcheskaya/poisk-po-dokumentam/114-tekhnicheskaya-zashchita-informatsii/dokumenty/spetsialnye-normativnye-dokumenty/380-metodika-opredeleniya-aktualnykh-ugroz-bezopasnosti-personalnykh-dannykh-pri-ikh-obrabotke-v-informatsionnykh-sistemakh-personalnykh-dannykh-fstek-rossii-2008-god


[28] Доступно для скачивания на сайте ФСБ: http://www.fsb.ru/files/PDF/Metodicheskie_recomendacii.pdf


[29] Важный совет: при создании чек-листа требований лучше полностью копировать текст требования в один файл. Например, сначала копируем 2 и 4 главу 152 ФЗ, затем добавляем в файл нужные требования из 1119 ПП, затем спускаемся к 21 Пр ФСТЭК и т.д.


[30] Подробные сведения об этом можно почерпнуть из выступлений регулятора и экспертов, см.: https://www.youtube.com/watch?v=qzBpD5nr8gMhttps://www.youtube.com/watch?v=95_U_LzWAAEhttps://www.youtube.com/watch?v=OpZ6ZRwdkJ8


[31] Оно обязательно лишь для государственных (муниципальных) информационных систем, но может служить справочным пособием для коммерческий организаций.


[32] На основании 17 Пр ФСТЭК.


[33] См. Раздел II.1 настоящего документа.


[34] Подробнее см. в Постановлении Правительства Российской Федерации от 3 февраля 2012 г. N 79 «О лицензировании деятельности по технической защите конфиденциальной информации».


[35] Роскомнадзор в любом случае уполномочен проверять корректность локализации баз данных ПД на территории Российской Федерации, а также изучать фактические процессы обработки персональных данных, вплоть до написания запросов к базам данных для сбора мета-информации об их функционировании и размещении.


[36] Подробнее см. информационное сообщение ФСТЭК от 29 марта 2019 г. N 240/24/1525 «О требованиях по безопасности информации, устанавливающих уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий», оригинал: https://fstec.ru/normotvorcheskaya/informatsionnye-i-analiticheskie-materialy/1812-informatsionnoe-soobshchenie-fstek-rossii-ot-29-marta-2019-g-n-240-24-1525


[37] П. 5 ч. 1 ст. 18.1 ФЗ 152, п. 1 и 2 ч. 2 ст. 19 там же.


[38] См. п. 16.6 17 Пр ФСТЭК, для 21 Пр ФСТЭК подобная детализация вообще отсутствует, ровно, как и любые упоминания «сертификации по требованиям ФСТЭК».


[39] Подробности полномочий регулятора описаны в ранее упомянутом Постановлении Правительства РФ от 13 февраля 2019 г. № 146 «Об утверждении Правил организации и осуществления государственного контроля и надзора за обработкой персональных данных».


[40] Теоретически возможны их подключения к проверки прокуратурой, либо распоряжение правительства о проведении подобной проверки, но на практике такие экзотические ситуации не распространены.


[41] Здесь нужно отметить, что сертификация приложения на отсутствие НДВ не является 100% гарантией их отсутствия, кроме того чисто формально такая сертификация теряет актуальность после любого значительного обновления приложения (как классифицировать значительность обновлений – отдельный вопрос).

[42] Она легко ищется по ИНН Роскомнадзора: 7705846236

Запишитесь на онлайн-презентацию

Нажимая на кнопку, вы даете согласие на обработку персональных данных и соглашаетесь c политикой конфиденциальности
Покажем возможности системы и ответим на ваши вопросы
© 2024 «Первая Форма»
Идеально для компаний от 100 человек