Рабочий стол аналитика с планшетом, отображающим матрицу соответствия приказу ФСТЭК №21. Рядом лежит перьевая ручка на бумаге с заметкой о правах доступа, мягкий дневной свет из окна.


Четверг, 11:40. Звонок от заказчика: «У нас внеплановая проверка Роскомнадзора после жалобы на утечку, приезжайте с документами по СЗПДн». Приезжаем - аттестат на ИСПДн выдан полтора года назад, техпроект подписан, модель угроз оформлена. Красиво. Начинаем проверять фактическое состояние: разграничение доступа к папке с ПДн клиентов - Everyone:Full Control. Журнал событий безопасности на сервере переполнен и перезаписывается каждые двое суток, в SIEM события с этого хоста не поступают с момента миграции на новый сервер четыре месяца назад. Сертифицированный межсетевой экран стоит в режиме permit any/any - «временно включили для тестирования и забыли вернуть». С введением оборотных штрафов за утечки ПДн стоимость такого разрыва между бумагой и реальностью выросла с сотен тысяч до процентов от выручки.

Эта статья - не пересказ текста приказа ФСТЭК №21. Здесь разобрано, как технические меры защиты персональных данных ФСТЭК реализуются в реальных ИСПДн: какие СЗИ ставить, какие события мониторить и что проверяющий видит первым при аттестации.

Уровни защищённости персональных данных: что определяет набор мер​

Прежде чем выбирать средства защиты, оператор определяет уровень защищённости (УЗ) своей ИСПДн по Постановлению Правительства №1119. Три фактора: категория обрабатываемых ПДн, объём записей и тип актуальных угроз.

УровеньКатегория ПДнОбъёмТип угрозТипичная ИСПДн
УЗ-4Иные (общедоступные)<100 0003-й типКадровый учёт компании до 500 человек
УЗ-3Иные (или биометрические при объёме <100 000)Любой3-й типCRM с базой клиентов, СКУД с биометрией
УЗ-2Специальные (или иные >100 000 при 1-м типе)>100 0002-й тип (типичный)Медицинская ИС региональной клиники
УЗ-1Специальные>100 0001-й типФедеральная ГИС с данными о здоровье

Полная матрица определения УЗ - ПП-1119 от 01.11.2012, пп. 9–13.

Типичная ошибка при классификации - завышение типа угроз. Первый тип подразумевает наличие недекларированных возможностей (НДВ) в системном ПО. Если организация использует стандартные ОС с регулярными обновлениями и не пишет собственное системное ПО для обработки ПДн - третий тип обоснован. Указание первого типа «для перестраховки» автоматически поднимает УЗ, а вместе с ним и бюджет на СЗИ. Я видел случай, когда из-за такой перестраховки стоимость проекта выросла втрое - и половина бюджета ушла на закупку СЗИ, которые реально были не нужны.

Соответствие класса СЗИ уровню защищённости устанавливается совокупно приказом ФСТЭК №21 (п. 12) и приказом ФСТЭК №76 от 02.06.2020: для УЗ-1 - СЗИ не ниже 4 класса защиты, для УЗ-2 - не ниже 5, для УЗ-3 - не ниже 6; для УЗ-4 жёсткое требование к классу не установлено, но рекомендуется применять СЗИ не ниже 6 класса. Для государственных ИС по приказу ФСТЭК №17 привязка аналогичная по классам К1–К3.

Приказ ФСТЭК №21: базовый набор мер и алгоритм выбора​

1780635828469.webp

Приказ ФСТЭК 21 определяет 15 групп технических и организационных мер защиты ИСПДн. Каждая группа - от 2 до 20 конкретных мер. Для каждого УЗ в приложении к приказу указан базовый набор обязательных мер, остальные - компенсирующие.

Алгоритм выбора (пункт 9 приказа):
  1. Определить базовый набор для установленного УЗ из приложения к приказу.
  2. Адаптировать - выкинуть меры, связанные с неиспользуемыми технологиями (ЗСВ - защита виртуализации - не нужна, если виртуальной инфраструктуры нет).
  3. Уточнить - добавить меры из модели угроз, не вошедшие в базовый набор.
  4. Дополнить компенсирующими мерами, если базовая мера технически нереализуема.
Тут есть момент, который большинство RU-гайдов по приказу пропускают: каждая мера ФСТЭК закрывает конкретную технику атакующего. Ниже - маппинг основных групп мер на матрицу MITRE ATT&CK. Он превращает формальное требование в понятную задачу для security-инженера.

КодГруппа мерЗакрываемые техники MITRE ATT&CKТипичное СЗИ
ИАФИдентификация и аутентификацияValid Accounts (T1078), Brute Force (T1110)Secret Net Studio, Dallas Lock 8.0-K
УПДУправление доступомValid Accounts (T1078), File and Directory Permissions Modification (T1222)GPO AD + Secret Net Studio
РСБРегистрация событий безопасностиImpair Defenses (T1562), Unsecured Credentials (T1552)MaxPatrol SIEM, RuSIEM
АВЗАнтивирусная защитаUser Execution (T1204), Command and Scripting Interpreter (T1059), Phishing (T1566)Kaspersky Endpoint Security
СОВОбнаружение вторженийExploit Public-Facing Application (T1190), Network Service Discovery (T1046), Application Layer Protocol (T1071)ViPNet IDS, PT NAD
ОДТОбеспечение доступностиData Encrypted for Impact (T1486)Резервное копирование
ЗИСЗащита ИС и передачи данныхUnsecured Credentials (T1552)ViPNet Coordinator, КриптоПро

Такой маппинг позволяет обосновать перед руководством, зачем конкретная мера нужна: не «потому что в приказе», а потому что без ИАФ.4 атакующий реализует Brute Force (T1110, Credential Access) и получает легитимные учётные данные. Для директора, который подписывает бюджет, это куда убедительнее ссылки на пункт нормативного документа.

Реализация технических мер защиты ИСПДн: конкретные инструменты​

1780637271437.webp

Идентификация, аутентификация и управление доступом (ИАФ, УПД)​

Для УЗ-3 обязательны: ИАФ.1 (идентификация и аутентификация пользователей), ИАФ.3 (управление идентификаторами), ИАФ.4 (управление средствами аутентификации), УПД.2 (реализация разграничения доступа).

Что это означает при аттестации:
  • Каждый пользователь ИСПДн - уникальная учётная запись. Общие логины «Бухгалтерия-1» или «Оператор-Касса» - прямое несоответствие.
  • Парольная политика через GPO: минимум 8 символов, блокировка после 5 неуспешных попыток на 30 минут, смена не реже раза в 90 дней.
  • Для УЗ-2 и выше базовый набор включает усиленную аутентификацию (ИАФ.5). Типичная реализация - двухфакторная аутентификация на сертификатах: токены JaCarta или Рутокен в связке с КриптоПро CSP (PKI). Допустимы также OTP и иные сертифицированные механизмы.
  • Матрица доступа документирована, фактические ACL соответствуют матрице. Проверяющий открывает матрицу, затем смотрит реальные права - расхождение фиксируется как нарушение.
Для аттестации нужно сертифицированное СЗИ от НСД. Реальный выбор для Windows-среды: Secret Net Studio (сертификат ФСТЭК, класс 5) или Dallas Lock 8.0-K (класс 5). Оба добавляют усиленную аутентификацию и мандатный контроль доступа поверх стандартных механизмов Windows, плюс ведут собственный защищённый журнал.

Ограничение: на GNU/Linux-серверах выбор значительно уже. Варианты - Astra Linux SE (имеет собственный сертификат ФСТЭК как ОС со встроенными СЗИ) или PAM-модули в связке с сертифицированными СКЗИ. Если у вас зоопарк из CentOS и Ubuntu - готовьтесь к боли с совместимостью.

Маппинг на международные стандарты: группа ИАФ соответствует семейству IA (Identification and Authentication) из NIST SP 800-53 Rev 5, а УПД - семейству AC (Access Control). Для организаций с мультинациональным compliance это упрощает аудит: одна мера закрывает требования и ФСТЭК, и NIST.

Регистрация событий безопасности и мониторинг (РСБ)​

РСБ - фундамент detection. Без него остальные меры - бумажные тигры. Приказ ФСТЭК №21 требует регистрировать: вход и выход пользователей, запуск и завершение процессов, доступ к объектам ПДн, изменение прав и полномочий, действия привилегированных учётных записей.

Минимальный стек для УЗ-3:
  • Windows Event Forwarding (WEF) или агент сбора логов для отправки событий с хостов ИСПДн.
  • MaxPatrol SIEM (сертификат ФСТЭК, класс 4) или RuSIEM для корреляции.
  • Хранение журналов не менее 6 месяцев (для УЗ-2 рекомендуется 12 месяцев).
Конкретные Event ID для мониторинга Windows-хостов ИСПДн:

Event IDЧто фиксируетМера ФСТЭК
4624 / 4625Успешный / неуспешный входИАФ.1, РСБ.2
4720 / 4726Создание / удаление учётной записиИАФ.3
4732 / 4733Добавление / удаление из группы безопасностиУПД.2
4663Доступ к объекту (файлу, папке)УПД.2, РСБ.2
7045Установка новой службыОПС.3
1102Очистка журнала безопасностиРСБ.7

Event ID 1102 (очистка Security-журнала) - красный флаг, прямой маппинг на технику Disable or Modify Tools (T1685, Defense Evasion). На сервере ИСПДн любое такое событие должно генерировать алерт Critical. Если кто-то чистит журнал безопасности на продуктивном сервере с ПДн - это либо инцидент, либо безумный админ. В обоих случаях надо разбираться немедленно.

Для работы аудита объектного доступа (4663) нужно включить соответствующую политику: в Advanced Audit Policy Configuration задать Object Access -> Audit File System: Success, Failure. Без этого события просто не генерируются - частая ошибка при настройке, которую я встречаю примерно в каждом третьем проекте.

Защита каналов связи и обнаружение вторжений (ЗИС, СОВ)​

Если ПДн передаются через сети общего пользования - обязательно шифрование с СКЗИ, сертифицированными ФСБ:
  • ViPNet Coordinator HW - криптошлюз класса КС2/КС3 для организации VPN между площадками.
  • Континент (Код Безопасности) - криптомаршрутизатор и МЭ в одном устройстве.
  • КриптоПро IPsec - для канальной защиты.
Межсетевой экран на периметре ИСПДн - сертифицированный по профилям защиты ФСТЭК. МЭ делятся на типы согласно профилям защиты ФСТЭК (информационное сообщение от 28.04.2016 №240/24/1986): тип А - уровень сети (периметр), тип Б - уровень логических границ сети (между сегментами), тип В - уровень узла (host-based), тип Г - уровень веб-сервера (WAF), тип Д - уровень промышленной сети (АСУ ТП). Для типичной ИСПДн нужен МЭ типа А или Б класса 5 (УЗ-2) или класса 6 (УЗ-3). Реальный выбор: UserGate, ViPNet Coordinator, Континент 4.

Обнаружение вторжений (СОВ) обязательно для УЗ-1 и УЗ-2, для УЗ-3 - по результатам модели угроз. Сертифицированные решения: ViPNet IDS (сетевой сенсор), PT Network Attack Discovery.

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

Detection для ИСПДн: корреляционные правила в SIEM​

1780637748713.webp

Собирать логи мало - нужна корреляция, привязанная к конкретным мерам приказа ФСТЭК №21 и техникам MITRE ATT&CK. Пять правил, которые стоит внедрить первыми.

Правило 1 - Brute Force учётных записей (T1110, ИАФ.4):
Условие: >10 событий 4625 за 5 минут с одного source IP на хост ИСПДн.
Приоритет: High.

Правило 2 - Привилегированный доступ в нерабочее время (T1078, УПД.5):
Условие: событие 4624 (Logon Type 2 или 10) с учёткой из группы «Администраторы ИСПДн» с 22:00 до 07:00 или в выходные.
Приоритет: Medium.

Правило 3 - Массовое чтение файлов ПДн (T1005, РСБ.5):
Условие: >50 событий 4663 на файловом ресурсе ИСПДн за 10 минут от одной учётной записи.
Приоритет: High.

Правило 4 - Остановка антивирусной защиты (T1685, АВЗ.2):
Условие: Event ID 7036 (source: Service Control Manager), где в XML-структуре EventData поле Data[@Name="param1"] содержит имя службы «Kaspersky Endpoint Security Service», а Data[@Name="param2"] - состояние «stopped», ИЛИ Event ID 7040 (изменение типа запуска службы), ИЛИ событие KSC/syslog категории «Самозащита нарушена» / «Защита остановлена», ИЛИ Sysmon Event ID 5 (Process Terminated) для avp.exe на хосте ИСПДн. Нюанс: из-за самозащиты KES событие 7036 может не появиться - рекомендуется комбинировать источники, приоритетно используя события самого KES через KSC SIEM-коннектор.
Приоритет: Critical.

Правило 5 - Обращение к LSASS (T1003, ИАФ.4):
Условие: Sysmon Event ID 10 с TargetImage lsass.exe и фильтром GrantedAccess ∈ {0x1010, 0x1410, 0x1438, 0x143A, 0x1FFFFF}, с дополнительной корреляцией по полю CallTrace (наличие неподписанных модулей, вызовов из dbghelp.dll/comsvcs.dll) и/или Sysmon Event ID 11 (создание .dmp-файла). Исключения: легитимные source images (svchost.exe, lsm.exe, wininit.exe, services.exe, csrss.exe, MsMpEng.exe) и подписанные AV/EDR-процессы (Defender, KES, EDR-агенты) на сервере ИСПДн. Без фильтрации по CallTrace правило генерирует массу false positives, особенно по маске 0x1010.
Приоритет: Critical.

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

Это соответствует подходу NIST CSF v2.0 DE.AE-01: «Baseline of network operations and expected data flows for users and systems is established and managed» - без baseline невозможно определить аномалию.

Чеклист технических мер защиты ПДн для УЗ-3​

Нумерованный список для передачи сисадмину или включения в акт обследования.
  1. Каждый пользователь ИСПДн - уникальная учётная запись. Проверка: Get-ADUser -Filter {Enabled -eq $true} | Measure-Object - сверить количество с реестром пользователей.
  2. Парольная политика GPO: минимум 8 символов, сложность включена, блокировка 5 попыток / 30 минут, смена раз в 90 дней.
  3. Матрица доступа документирована. Фактические ACL на ресурсах ИСПДн соответствуют матрице - проверить icacls \\server\share\PDn.
  4. Аудит доступа включён: Advanced Audit Policy -> Object Access -> Audit File System: Success, Failure.
  5. Аудит входа включён: Account Logon -> Audit Logon: Success, Failure.
  6. Логи отправляются в SIEM или централизованное хранилище. Срок хранения - минимум 6 месяцев.
  7. Антивирус сертифицирован ФСТЭК, базы обновлены (давность не более 24 часов), управление через KSC.
  8. МЭ на периметре ИСПДн: сертифицирован ФСТЭК, политика deny all по умолчанию, открыты только документированные порты.
  9. VPN с сертифицированным СКЗИ для передачи ПДн через сети общего пользования.
  10. Резервное копирование БД ИСПДн - не реже 1 раза в сутки. Бэкапы на отдельном защищённом ресурсе.
  11. Контроль целостности СЗИ при загрузке - Secret Net / Dallas Lock выполняют автоматически.
  12. Документация в актуальном состоянии: модель угроз, техпроект СЗПДн, журнал учёта СЗИ, журнал учёта машинных носителей.
Для УЗ-2 к базовому набору добавляются: двухфакторная аутентификация, IDS на периметре, контроль подключения съёмных носителей, защита среды виртуализации (при её использовании), срок хранения журналов - не менее 12 месяцев.

Компенсирующие меры: когда базовый набор не ложится на инфраструктуру​

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме


За восемь лет проектирования и аттестации ИСПДн по приказу ФСТЭК №21 я вижу одну устойчивую закономерность: организации, которые относятся к техническим мерам защиты персональных данных как к чеклисту для регулятора, платят дважды - сначала за аттестацию, потом за устранение последствий инцидента. Проблема не в приказе - набор мер в нём разумный и при грамотной реализации закрывает большинство практических угроз. Проблема в том, что между аттестацией и следующей проверкой проходят годы, за которые инфраструктура мигрирует, пароли перестают ротироваться, а SIEM-правила остаются настроенными на старую топологию. Формально система защиты ПДн существует, фактически - нет. С введением оборотных штрафов за утечки цена этого разрыва стала измеряться не предписаниями, а процентами от выручки. Операторам, которые уже прошли аттестацию, сейчас критичнее всего не новые СЗИ, а рабочий мониторинг: пять корреляционных правил из этой статьи закрывают самые частые атаки на учётные данные и файловые ресурсы ИСПДн. На yg140.servegame.com держим тред, где коллеги делятся конфигурациями корреляционных правил для ИСПДн под разные SIEM-стеки - если адаптируете detection под свою инфраструктуру, стоит сверить подход.
 
Последнее редактирование модератором:
Мы в соцсетях:

Взломай свой первый сервер и прокачай скилл — Начни игру на HackerLab

Похожие темы

🚀 Первый раз на Codeby?
Гайд для новичков: что делать в первые 15 минут, ключевые разделы, правила
Начать здесь →
🔴 Свежие CVE, 0-day и инциденты
То, о чём ChatGPT ещё не знает — обсуждаем в реальном времени
Threat Intel →
💼 Вакансии и заказы в ИБ
Pentest, SOC, DevSecOps, bug bounty — работа и проекты от проверенных компаний
Карьера в ИБ →

HackerLab