Поправки к 152-ФЗ, принятые в июле, сняли часть прежней неопределённости, но добавили работы операторам персональных данных. Срок, к которому системы нужно было привести в соответствие, формально истёк ещё 1 июля. На практике большинство компаний и ведомств только сейчас разбираются, что именно требуется от их информационных систем. Разберём это по существу – без ссылок на «комплексные решения под ключ», которыми пугают рынок.

Что закон требует от ИСПДн

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

Конкретику задают подзаконные акты ФСТЭК и ФСБ, а также «приказ трёх» № 55/86/20. Системы классифицируются по объёму данных и категориям субъектов – от К4 (минимальный риск) до К1 (специальные категории: здоровье, судимости, политические взгляды). Класс определяет глубину защиты. Для медицинской системы или базы кадрового резерва требования будут жёстче, чем для списка рассылки.

Ключевой документ оператора – модель угроз. Без неё нельзя обосновать выбор мер, и именно её первой запрашивает проверяющий. Модель угроз описывает, кто и как может добраться до данных: внешний нарушитель через интернет, инсайдер с легальным доступом, утечка через резервные копии или логи.

Организационные меры идут первыми

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

Отдельно – уведомление в Роскомнадзор о намерении обрабатывать персональные данные. Часть операторов про него забывает, хотя это первое, что проверяется на бумаге.

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

Технические меры и автоматизация

Со стороны систем закон и приказы ФСТЭК требуют управления доступом, регистрации событий (кто, когда, к каким данным обращался), антивирусной защиты, контроля целостности и защиты каналов передачи. Для высоких классов добавляется криптография по линии ФСБ и контроль съёмных носителей.

На что обратить внимание разработчикам:

  • Логирование и аудит. Журнал доступа к персональным данным – не опция. Стройте его на этапе проектирования, а не прикручивайте задним числом.
  • Изоляция данных. Разнесите контуры обработки персональных данных и публичные сервисы. Хранилище ИСПДн не должно торчать наружу. Если используете гибкие хранилища вроде описанных в материале про NoSQL для веба, помните: schema-less не освобождает от разграничения доступа и шифрования полей.
  • Воспроизводимость конфигурации. Защищённость системы – это её настройки. Когда настройки расползаются по серверам вручную, доказать соответствие невозможно. Управление конфигурациями через Puppet или Chef даёт единый описанный эталон, а непрерывная интеграция ловит отступления от него до выката в продакшн.

Аттестация системы по требованиям ФСТЭК подтверждает соответствие официально. Для государственных информационных систем она обязательна, для коммерческих – сильный аргумент при проверке.

Вывод

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