Четверг, 11:40. Звонок от заказчика: «У нас внеплановая проверка Роскомнадзора после жалобы на утечку, приезжайте с документами по СЗПДн». Приезжаем - аттестат на ИСПДн выдан полтора года назад, техпроект подписан, модель угроз оформлена. Красиво. Начинаем проверять фактическое состояние: разграничение доступа к папке с ПДн клиентов -
Everyone:Full Control. Журнал событий безопасности на сервере переполнен и перезаписывается каждые двое суток, в SIEM события с этого хоста не поступают с момента миграции на новый сервер четыре месяца назад. Сертифицированный межсетевой экран стоит в режиме permit any/any - «временно включили для тестирования и забыли вернуть». С введением оборотных штрафов за утечки ПДн стоимость такого разрыва между бумагой и реальностью выросла с сотен тысяч до процентов от выручки.Эта статья - не пересказ текста приказа ФСТЭК №21. Здесь разобрано, как технические меры защиты персональных данных ФСТЭК реализуются в реальных ИСПДн: какие СЗИ ставить, какие события мониторить и что проверяющий видит первым при аттестации.
Уровни защищённости персональных данных: что определяет набор мер
Прежде чем выбирать средства защиты, оператор определяет уровень защищённости (УЗ) своей ИСПДн по Постановлению Правительства №1119. Три фактора: категория обрабатываемых ПДн, объём записей и тип актуальных угроз.| Уровень | Категория ПДн | Объём | Тип угроз | Типичная ИСПДн |
|---|---|---|---|---|
| УЗ-4 | Иные (общедоступные) | <100 000 | 3-й тип | Кадровый учёт компании до 500 человек |
| УЗ-3 | Иные (или биометрические при объёме <100 000) | Любой | 3-й тип | CRM с базой клиентов, СКУД с биометрией |
| УЗ-2 | Специальные (или иные >100 000 при 1-м типе) | >100 000 | 2-й тип (типичный) | Медицинская ИС региональной клиники |
| УЗ-1 | Специальные | >100 000 | 1-й тип | Федеральная ГИС с данными о здоровье |
Полная матрица определения УЗ - ПП-1119 от 01.11.2012, пп. 9–13.
Типичная ошибка при классификации - завышение типа угроз. Первый тип подразумевает наличие недекларированных возможностей (НДВ) в системном ПО. Если организация использует стандартные ОС с регулярными обновлениями и не пишет собственное системное ПО для обработки ПДн - третий тип обоснован. Указание первого типа «для перестраховки» автоматически поднимает УЗ, а вместе с ним и бюджет на СЗИ. Я видел случай, когда из-за такой перестраховки стоимость проекта выросла втрое - и половина бюджета ушла на закупку СЗИ, которые реально были не нужны.
Соответствие класса СЗИ уровню защищённости устанавливается совокупно приказом ФСТЭК №21 (п. 12) и приказом ФСТЭК №76 от 02.06.2020: для УЗ-1 - СЗИ не ниже 4 класса защиты, для УЗ-2 - не ниже 5, для УЗ-3 - не ниже 6; для УЗ-4 жёсткое требование к классу не установлено, но рекомендуется применять СЗИ не ниже 6 класса. Для государственных ИС по приказу ФСТЭК №17 привязка аналогичная по классам К1–К3.
Приказ ФСТЭК №21: базовый набор мер и алгоритм выбора
Приказ ФСТЭК 21 определяет 15 групп технических и организационных мер защиты ИСПДн. Каждая группа - от 2 до 20 конкретных мер. Для каждого УЗ в приложении к приказу указан базовый набор обязательных мер, остальные - компенсирующие.
Алгоритм выбора (пункт 9 приказа):
- Определить базовый набор для установленного УЗ из приложения к приказу.
- Адаптировать - выкинуть меры, связанные с неиспользуемыми технологиями (ЗСВ - защита виртуализации - не нужна, если виртуальной инфраструктуры нет).
- Уточнить - добавить меры из модели угроз, не вошедшие в базовый набор.
- Дополнить компенсирующими мерами, если базовая мера технически нереализуема.
| Код | Группа мер | Закрываемые техники 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) и получает легитимные учётные данные. Для директора, который подписывает бюджет, это куда убедительнее ссылки на пункт нормативного документа.
Реализация технических мер защиты ИСПДн: конкретные инструменты
Идентификация, аутентификация и управление доступом (ИАФ, УПД)
Для УЗ-3 обязательны: ИАФ.1 (идентификация и аутентификация пользователей), ИАФ.3 (управление идентификаторами), ИАФ.4 (управление средствами аутентификации), УПД.2 (реализация разграничения доступа).Что это означает при аттестации:
- Каждый пользователь ИСПДн - уникальная учётная запись. Общие логины «Бухгалтерия-1» или «Оператор-Касса» - прямое несоответствие.
- Парольная политика через GPO: минимум 8 символов, блокировка после 5 неуспешных попыток на 30 минут, смена не реже раза в 90 дней.
- Для УЗ-2 и выше базовый набор включает усиленную аутентификацию (ИАФ.5). Типичная реализация - двухфакторная аутентификация на сертификатах: токены JaCarta или Рутокен в связке с КриптоПро CSP (PKI). Допустимы также OTP и иные сертифицированные механизмы.
- Матрица доступа документирована, фактические ACL соответствуют матрице. Проверяющий открывает матрицу, затем смотрит реальные права - расхождение фиксируется как нарушение.
Ограничение: на 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 | Что фиксирует | Мера ФСТЭК |
|---|---|---|
| 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 - для канальной защиты.
Обнаружение вторжений (СОВ) обязательно для УЗ-1 и УЗ-2, для УЗ-3 - по результатам модели угроз. Сертифицированные решения: ViPNet IDS (сетевой сенсор), PT Network Attack Discovery.
Ограничение сетевых IDS, о котором часто забывают: зашифрованный внутренний трафик (TLS между компонентами ИСПДн) остаётся невидимым для сенсора. Решение - SSL-инспекция на МЭ или хостовые агенты IDS. Без этого IDS видит только заголовки, а полезная нагрузка проходит мимо.
Detection для ИСПДн: корреляционные правила в SIEM
Собирать логи мало - нужна корреляция, привязанная к конкретным мерам приказа ФСТЭК №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
Нумерованный список для передачи сисадмину или включения в акт обследования.- Каждый пользователь ИСПДн - уникальная учётная запись. Проверка:
Get-ADUser -Filter {Enabled -eq $true} | Measure-Object- сверить количество с реестром пользователей. - Парольная политика GPO: минимум 8 символов, сложность включена, блокировка 5 попыток / 30 минут, смена раз в 90 дней.
- Матрица доступа документирована. Фактические ACL на ресурсах ИСПДн соответствуют матрице - проверить
icacls \\server\share\PDn. - Аудит доступа включён: Advanced Audit Policy -> Object Access -> Audit File System: Success, Failure.
- Аудит входа включён: Account Logon -> Audit Logon: Success, Failure.
- Логи отправляются в SIEM или централизованное хранилище. Срок хранения - минимум 6 месяцев.
- Антивирус сертифицирован ФСТЭК, базы обновлены (давность не более 24 часов), управление через KSC.
- МЭ на периметре ИСПДн: сертифицирован ФСТЭК, политика deny all по умолчанию, открыты только документированные порты.
- VPN с сертифицированным СКЗИ для передачи ПДн через сети общего пользования.
- Резервное копирование БД ИСПДн - не реже 1 раза в сутки. Бэкапы на отдельном защищённом ресурсе.
- Контроль целостности СЗИ при загрузке - Secret Net / Dallas Lock выполняют автоматически.
- Документация в актуальном состоянии: модель угроз, техпроект СЗПДн, журнал учёта СЗИ, журнал учёта машинных носителей.
Компенсирующие меры: когда базовый набор не ложится на инфраструктуру
📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме
За восемь лет проектирования и аттестации ИСПДн по приказу ФСТЭК №21 я вижу одну устойчивую закономерность: организации, которые относятся к техническим мерам защиты персональных данных как к чеклисту для регулятора, платят дважды - сначала за аттестацию, потом за устранение последствий инцидента. Проблема не в приказе - набор мер в нём разумный и при грамотной реализации закрывает большинство практических угроз. Проблема в том, что между аттестацией и следующей проверкой проходят годы, за которые инфраструктура мигрирует, пароли перестают ротироваться, а SIEM-правила остаются настроенными на старую топологию. Формально система защиты ПДн существует, фактически - нет. С введением оборотных штрафов за утечки цена этого разрыва стала измеряться не предписаниями, а процентами от выручки. Операторам, которые уже прошли аттестацию, сейчас критичнее всего не новые СЗИ, а рабочий мониторинг: пять корреляционных правил из этой статьи закрывают самые частые атаки на учётные данные и файловые ресурсы ИСПДн. На yg140.servegame.com держим тред, где коллеги делятся конфигурациями корреляционных правил для ИСПДн под разные SIEM-стеки - если адаптируете detection под свою инфраструктуру, стоит сверить подход.
Последнее редактирование модератором: