📜 152-ФЗ · ФСТЭК · ФСБ · 187-ФЗ КИИ

Compliance - это не «галочка».
Это часть архитектуры.

Соответствие 152-ФЗ, требованиям ФСТЭК и отраслевых регуляторов не должно быть последней главой проекта. Мы проектируем enterprise-системы так, чтобы compliance был встроен на уровне архитектуры - и аудит проходился без авралов, изменений интерфейсов и переноса дат релиза.

Регуляторный ландшафт РФ для enterprise-систем

Базовый набор регуляторики, который касается практически каждой enterprise-системы, обрабатывающей данные граждан РФ или поддерживающей критические бизнес-процессы.

152-ФЗ «О персональных данных»

Базовый закон. Обязателен для любой системы, в которой обрабатываются ПДн граждан РФ. Включает требование локализации (статья 18 часть 5), уведомление Роскомнадзора, права субъектов, обязанности оператора и требования к мерам защиты.

Приказ ФСТЭК № 21

Состав и содержание организационных и технических мер защиты ПДн в ИСПДн. Применяется в зависимости от уровня защищённости (УЗ-1 / УЗ-2 / УЗ-3 / УЗ-4), определённого по ПП РФ № 1119 с учётом категорий ПДн, объёмов и актуальных угроз.

187-ФЗ «О безопасности КИИ»

Касается критической информационной инфраструктуры: здравоохранение, транспорт, банковская сфера, связь, энергетика и др. Включает категорирование объектов КИИ, требования к мерам защиты, подключение к ГосСОПКА, взаимодействие с НКЦКИ при инцидентах.

Требования ФСБ к СКЗИ

Применение средств криптографической защиты. Сертифицированные ФСБ СКЗИ обязательны при защите каналов и хранилищ для ИСПДн УЗ-1 / УЗ-2 и большинства объектов КИИ. Алгоритмы - ГОСТ Р 34.10-2012, ГОСТ Р 34.11-2012, ГОСТ Р 34.12-2015.

Отраслевые требования

Здравоохранение (323-ФЗ, требования к ЕГИСЗ), банковская сфера (положения ЦБ № 683-П, № 716-П), финансовые организации (требования по защите информации при переводах), государственный сектор (приказ ФСТЭК № 17 для ГИС).

Сопровождающие документы

Постановления Правительства, методические документы ФСТЭК, рекомендации Роскомнадзора, разъяснения по практике применения. Регуляторная база живая - изменения требуют регулярного пересмотра политик и регламентов.

Методология подготовки enterprise-системы к compliance

Четырёхфазный подход, который мы применяем на проектах с регуляторной нагрузкой. Каждая фаза имеет конкретные результаты и привязана к этапам разработки, а не к концу проекта.

Фаза 1. Регуляторное обследование

Определяем применимый набор регуляторики для конкретной системы: 152-ФЗ, ФСТЭК № 21 или № 17, 187-ФЗ, отраслевые требования. Классифицируем ИСПДн по уровню защищённости (УЗ-1…УЗ-4). Категорируем объекты КИИ, если применимо. Фиксируем сроки уведомления Роскомнадзора и привязку к этапам проекта.
Результат: регуляторная карта системы - конкретный перечень требований и сроков.

Фаза 2. Модель угроз и архитектурные решения

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

Фаза 3. Документация и регламенты

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

Фаза 4. Внедрение, тестирование и аттестация

Развёртывание средств защиты, настройка журналирования, проведение испытаний. При необходимости - оценка соответствия или аттестация (для ИСПДн УЗ-1 и КИИ). Подготовка к выездным проверкам Роскомнадзора и ФСТЭК. Передача системы в эксплуатацию с полным комплектом документов.
Результат: система готова к проверкам - без авралов и доработок последней минуты.

Базовый аудит-чеклист (15 пунктов)

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

1. Уведомление Роскомнадзора

Зарегистрировано до начала обработки или в установленные сроки. Актуальное.

2. Политика обработки ПДн

Утверждённая, опубликованная, отражающая фактические процессы.

3. Назначение ответственных

Приказ о назначении ответственного за организацию обработки ПДн; ответственных за защиту.

4. Перечень обрабатываемых ПДн

Категории, источники, цели обработки, сроки хранения, основания.

5. Акт классификации ИСПДн

Документ определения уровня защищённости по ПП РФ № 1119.

6. Модель угроз и нарушителя

По методике ФСТЭК, актуальная на дату ввода в эксплуатацию.

7. Согласия субъектов

Где требуется по 152-ФЗ - формы и журналы получения согласий.

8. Регламент доступа

Матрица доступа, процедуры предоставления и отзыва прав, журналы.

9. Журналирование операций

Технические средства фиксации действий с ПДн, сроки хранения журналов.

10. Средства защиты ИСПДн

Сертифицированные ФСТЭК продукты, акты ввода в эксплуатацию.

11. СКЗИ

Применение сертифицированных ФСБ средств, эксплуатационная документация.

12. Локализация ПДн

Подтверждение хранения и обработки на территории РФ (статья 18 часть 5).

13. Регламент реагирования на инциденты

Процедура, ответственные, сроки уведомления (для КИИ - ГосСОПКА / НКЦКИ).

14. Резервное копирование и восстановление

Регламент, расписание, проверка восстанавливаемости, защита резервных копий.

15. Регулярная переоценка

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

Куда дальше

Регулируемые системы

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

Регулируемые системы

Кейсы

Реальные примеры enterprise-систем, в которых compliance был встроен на уровне архитектуры. Включая медицинскую федерацию (100,000+ врачей, 19 лет в эксплуатации).

Кейсы

SLA

Уровни сервиса, доступность, регламент реагирования на инциденты - операционная сторона enterprise-разработки.

Уровни SLA

Обсудим compliance-сценарий вашего проекта

За один разговор оцениваем: какая регуляторика применима, какой уровень защищённости требуется, что должно появиться в архитектуре и какой объём документации потребуется к моменту аудита.

Связаться с архитектором