Меры защиты персональных данных в ИТ

«Защита персональных данных в российском IT — это не простановка галочек в чек-листе Роскомнадзора. Это про создание среды, где каждый инженерный выбор, от выбора ОС до регламента удаления логов, определяется категорией обрабатываемых данных и тем, откуда ждать следующую атаку. Закон 152-ФЗ и подзаконные акты задают лишь уровень необходимой паранойи. Как именно его достичь — уже задача архитектора системы защиты.»

Уровни защищенности персональных данных

Уровень защищенности (УЗ) — это не абстрактная оценка, а формальный показатель, который задает строгость требований ко всей системе. Он определяется по методике из Постановления Правительства №1119 на основе трех параметров: тип актуальных угроз, категория данных и их объем. Ошибиться на этом этапе — значит заложить несоответствие в основу всей дальнейшей работы.

Как определяется уровень

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

Уровень защищенности	Тип актуальных угроз	Категория ПДн	Объем / Статус субъектов
УЗ 1 (наиболее высокий)	1-й тип	Специальные, биометрические	Любой объем
УЗ 2	2-й тип	Специальные	Более 100 000 субъектов, не являющихся сотрудниками
УЗ 3	3-й тип	Специальные	Более 100 000 субъектов, не являющихся сотрудниками
УЗ 4	3-й тип	Общедоступные, иные	Сотрудники или менее 100 000 субъектов

Типы угроз безопасности ПДн

Термин «актуальные угрозы» в контексте 152-ФЗ имеет четкое юридическое и техническое определение. ФСТЭК России публикует базовые модели угроз (БМУ) — каталоги конкретных сценариев. Для классификации в целях определения УЗ все угрозы делятся на три типа.

Угрозы 1-го типа

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

• Бэкдоры в ядре операционной системы, микрокоде процессоров или загрузчиках (UEFI/BIOS).
• Уязвимости, позволяющие привилегированному пользователю (например, администратору) выполнять команды ядра.
• Скрытые механизмы удаленного управления, встроенные в системные библиотеки.

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

Угрозы 2-го типа

Связаны с наличием недекларированных возможностей в прикладном программном обеспечении. Риск локализован на уровне служб и приложений, но масштаб последствий может быть колоссальным.

• Уязвимости нулевого дня в веб-серверах, системах управления базами данных (СУБД), CRM.
• Уязвимости в сторонних библиотеках, приводящие к компрометации приложения (supply-chain атаки).
• Скрытые функции в коммерческом ПО для сбора и передачи аналитики.

Ключевое следствие: Требуется внедрение систем контроля целостности приложений (HIPS), строгий патч-менеджмент и, где возможно, использование ПО из реестра отечественного ПО.

Угрозы 3-го типа

Не связаны с недекларированными возможностями в ПО. Это угрозы, реализуемые через человеческий фактор, ошибки конфигурации или физический доступ. Статистически на них приходится большинство успешных инцидентов.

• Социальная инженерия (фишинг, целевые письма).
• Кража или подбор учетных данных (слабые пароли, повторное использование).
• Несанкционированный физический доступ к рабочим станциям или серверам.
• Утечки по неосторожности (отправка файла не тому адресату, потеря незашифрованного носителя).

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

Организационные меры защиты

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

Фундаментальные политики и процедуры

• Политика информационной безопасности: Не формальная отписка для проверяющих, а живой документ, закрепляющий подход организации, распределение ролей (кто отвечает за шифрование носителей, кто за анализ логов) и базовые принципы (например, запрет на хранение ПДн в публичных облаках без сертификации).
• Регламент обработки ПДн: Пошаговые инструкции на каждый сценарий: сбор, верификация, передача внутри организации и контрагентам, хранение, обезличивание, уничтожение. Включает физические правила вроде «чистого стола» и автоматической блокировки экрана.
• Политика управления доступом: Процедуры, основанные на принципе минимальных привилегий. Ключевой момент — автоматизированный или строго контролируемый процесс отзыва прав при увольнении или смене должности. Задержка в сутки — это уже риск.

Работа с персоналом и носителями

• Обучение и аттестация: Регулярные инструктажи с разборами реальных кейсов утечек из открытых источников. Практическое тестирование на восприимчивость к фишингу с последующим разбором ошибок.
• Контроль съемных носителей: Полный технический запрет или строгий контроль через DLP-системы, разрешающие запись только на шифрованные носители с авторизацией.
• Процедура реагирования на инциденты: Четкий playbook: кто оповещается (внутренний ответственный, возможно, Роскомнадзор), как изолируется система (отключение от сети, не удаление!), как собираются и хранятся доказательства для расследования.

Технические меры защиты

Технические меры реализуются средствами защиты информации (СЗИ). Важно понимать, что для разных уровней защищенности закон предписывает использовать СЗИ определенного класса и уровня доверия. Использование неподходящего средства — прямое нарушение.

Уровень защищенности ИСПДн	Класс СЗИ (не ниже)	Уровень доверия СЗИ (не ниже)	Класс СВТ* (не ниже)
УЗ 1	4	4	5
УЗ 2	5	5	5
УЗ 3	6	6	5
УЗ 4	6	6	6

*СВТ — средства вычислительной техники (серверы, рабочие станции).

Ключевые группы технических мер по приказу ФСТЭК №21

Приказ №21 группирует меры. Важно не просто поставить галочку, а понять, как они взаимодействуют.

Управление доступом (Меры 8.1-8.3)

• Идентификация и аутентификация (8.1): Не просто логин-пароль. Для УЗ 2 и выше почти всегда требуется двухфакторная аутентификация. Учетные записи по умолчанию (admin, root) должны быть переименованы или отключены.
• Управление доступом (8.2): RBAC (ролевая модель) — это минимум. Для сложных систем рассматривают ABAC (атрибутивный), где доступ зависит от множества параметров (роль, время, IP-адрес).
• Ограничение программной среды (8.3): Запуск только ПО из белых списков. Это не только про вредоносный софт, но и про блокировку утилит для дампа памяти или обхода политик.

Защита целостности и мониторинг (Меры 8.4-8.9)

• Защита машинных носителей (8.4): Полнодисковое шифрование (например, на основе российских ГОСТ-алгоритмов) для ноутбуков и серверов. Без ключа данные на украденном диске должны быть нечитаемы.
• Регистрация событий безопасности (8.5): Не просто сбор логов, а их централизованный анализ в SIEM-системе. Корреляция событий с разных узлов позволяет выявить атаку, которая по отдельности выглядит как легитимная активность.
• Обнаружение вторжений (8.7): Сетевые (NIDS) и хостовые (HIDS) системы. Современные HIDS умеют отслеживать не только изменения в файлах, но и подозрительные системные вызовы (syscalls).
• Контроль целостности (8.9): Системы контроля целостности файлов (FIM) следят за критичными файлами (исполняемые файлы, конфигурации). Любое изменение без санкции — инцидент.

Защита инфраструктуры (Меры 8.10-8.13)

• Защита среды виртуализации (8.11): Изоляция виртуальных машин, контроль доступа к гипервизору. Критично предотвращение атак типа «VM escape», когда злоумышленник из виртуальной машины вырывается на уровень гипервизора.
• Защита систем связи (8.13): Сегментация сети (например, выделение отдельного VLAN для сегмента с ПДн). Передача ПДн за пределы защищенного сегмента — только по VPN с использованием сертифицированных СКЗИ.

Важный нюанс: Криптографические средства (СКЗИ) регулируются отдельно 63-ФЗ и требованиями ФСБ. Их сертификация проходит по другой схеме, но применение для шифрования каналов связи и данных на носителях часто обязательно.

Процесс построения системы защиты: итеративный подход

Выбор мер по приказу №21 — это не случайный набор, а алгоритм, который обеспечивает полноту защиты.

1. Базовый набор. Определяется стандартный перечень мер из приложения к приказу, строго соответствующий вашему уровню защищенности (УЗ).
2. Адаптация. Из этого набора исключаются меры, не связанные с вашими технологиями. Нет мобильных клиентов — убираем меры для мобильных ОС.
3. Уточнение. Получившийся набор проверяется на соответствие базовой модели угроз (БМУ). Все ли угрозы из БМУ для вашего УЗ перекрываются выбранными мерами? Если нет — добавляем недостающие меры из приложения.
4. Дополнение. Учитываются отраслевые требования (например, стандарты Банка России для финансового сектора или приказы Минздрава). Они накладываются поверх требований ФСТЭК.

Компенсирующие меры

Если стандартную меру реализовать невозможно (например, физический контроль доступа в публичном облаке), разрабатывается компенсирующая мера. Пример: невозможность установки традиционного сетевого межсетевого экрана компенсируется строгой микросегментацией на уровне хостовых файрволов (host-based firewall) и системой обнаружения вторжений на каждой виртуальной машине. Любое такое решение требует письменного обоснования с оценкой остаточного риска.

Особые требования для угроз 1-го и 2-го типа

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

• Проверка ПО на отсутствие недекларированных возможностей (НДВ) в аккредитованных лабораториях.
• Регулярное тестирование на проникновение (пентест) не реже раза в год.
• Внедрение практик безопасной разработки (secure SDLC) для собственного ПО, включая статический и динамический анализ кода.

Ответственность и оценка эффективности

Оператор ПДн несет полную административную и уголовную ответственность. Внутри организации приказом должен быть назначен ответственный за безопасность ПДн. Для УЗ 1 это обязательно отдельное структурное подразделение. Оценка эффективности — не формальность, а обязательная процедура не реже раза в 3 года. Она включает:

• Аудит конфигураций средств защиты на соответствие паспортам и политикам.
• Анализ логов SIEM на предмет пропущенных инцидентов.
• Тестирование процедур реагирования (например, учебная «утечка»).
• Моделирование атак (красные команды) для проверки реальной устойчивости.

Адаптация к новым технологиям

Традиционные меры могут не работать в современных средах. Защита системы машинного обучения, обрабатывающей ПДн, потребует мер против poisoning-атак (подмена тренировочных данных) и adversarial examples (ввод специально сконструированных данных для обмана модели). В контейнеризированных средах контроль целостности смещается с виртуальной машины на образы контейнеров (container image scanning) и runtime-среду. Архитектура защиты должна быть модульной, чтобы позволять встраивать такие специфические модули без перепроектирования всей системы.

Итоговая система защиты ПДн — это не статичный набор инструментов, а живой организм. Цикл «оценка рисков — проектирование мер — внедрение — мониторинг — адаптация» должен быть встроен в процессы разработки и эксплуатации. Формальное выполнение требований создает лишь иллюзию защищенности и не спасает при реальном инциденте или проверке. Реальную безопасность дает только системное мышление, где каждый технический контроль подкреплен ясной организационной процедурой, а каждый сотрудник понимает свою роль в защите данных.