152-ФЗ вступил в силу: разбираем с юристом технические меры для ИСПДн класса К2

26 января 2007 года 152-ФЗ «О персональных данных» официально вступил в силу. Мы, честно говоря, рассчитывали, что регулятор выпустит что-то конкретное раньше - какие-нибудь внятные приказы с техническими требованиями. Вместо этого Роскомнадзор начинает формировать методические рекомендации прямо сейчас, на ходу. Нормативная картина пока выглядит как пазл, у которого есть рамка, но внутри ещё пусто.

Тем не менее у нас есть клиент - производственная компания, около ста двадцати человек, CRM собственной разработки плюс 1С - и его юрист, который неожиданно разбирается в теме лучше среднего. Плюс есть ФСТЭК с проектом классификатора ИСПДн, который всё ещё в виде рабочего документа, но уже достаточно структурированный, чтобы с ним работать. Мы сели втроём - инженер, юрист клиента, руководитель ИТ-отдела - и разобрали, что конкретно нужно сделать для систем класса К2.

Откуда берётся К2

Предварительный классификатор ФСТЭК делит ИСПДн по двум осям: категория данных и количество субъектов. К2 получается, когда данные содержат сведения, позволяющие идентифицировать человека и создать его профиль, но не относятся к специальным категориям (здоровье, биометрия, судимости), и при этом субъектов от 1 000 до 100 000. Наш клиент попадает именно туда: CRM хранит данные сотрудников и контрагентов - ФИО, должность, контакты, ряд финансовых атрибутов.

К1 нас всех пугает больше - там идут спецкатегории, и требования, судя по черновикам, будут жёстче. К2 - это уже серьёзно, но технически подъёмно.

Что реально нужно сделать

Юрист со своей стороны закрыл организационную часть: приказы, регламенты, согласия субъектов, инструкции для пользователей. Наша часть - техническая. Мы разложили её на три блока.

Шифрование каналов. Всё, что ходит между офисом и серверной, между офисами и через интернет - только через зашифрованные каналы. У клиента уже стоит OpenVPN для удалённого доступа, который мы настраивали ранее. Расширяем его на все сайт-ту-сайт соединения, закрываем незашифрованный FTP, переводим внутренний трафик CRM на HTTPS - там самоподписанный сертификат, но это лучше, чем открытый HTTP. Требование ФСТЭК про сертифицированные СКЗИ для К2 в черновике есть, но пока не расшифровано до конкретного перечня. Берём то, что есть, и фиксируем факт применения.

Разграничение доступа. Здесь самая большая работа. В CRM исторически сложилась схема «у всех менеджеров одна учётка», что, строго говоря, не учётка, а катастрофа с точки зрения учёта. Переводим систему на персональные учётные записи, выстраиваем роли: оператор, старший менеджер, администратор, только чтение. В Active Directory создаём отдельные группы для пользователей ИСПДн - это нужно и для разграничения доступа к файловому серверу, где лежат выгрузки из 1С с персданными. Отдельно - принцип минимальных привилегий: никаких локальных администраторов на рабочих станциях у рядовых операторов.

Журналирование событий безопасности. Требование про аудит присутствует во всех черновиках регуляторов явно. Включаем аудит входа/выхода и изменений объектов в AD, настраиваем централизованный syslog для сетевого оборудования и серверов, включаем аудит доступа к файловым ресурсам с персданными. Логи - на отдельный сервер, к которому у операторов нет доступа на запись. Срок хранения пока не прописан нормативно, берём год как разумный минимум.

Что не сделали и почему

Антивирус и патч-менеджмент - уже есть, это базовая гигиена. Физическая защита серверной - отдельный проект, там замки и СКУД, не наша компетенция. Межсетевое экранирование - есть, но требует аудита правил, это следующий этап.

Сканер уязвимостей для ИСПДн тоже в планах - но это уже отдельный разговор про инструментарий.

Что получилось

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

Итоговый документ - «Технические меры защиты ИСПДн» - лежит у клиента как приложение к политике безопасности. Формально он написан под черновик ФСТЭК, то есть когда выйдет финальный приказ, его придётся сверять и, вероятно, дополнять. Но хоть что-то зафиксировано, и это лучше, чем ждать окончательного текста с нулём на руках.

Методические рекомендации Роскомнадзора пока не вышли. По нашим ощущениям, регулятор сам ещё разбирается, каким образом проверять соответствие технических мер. Это даёт время, но не означает, что его стоит тратить впустую. Тем более что на учёт в РКН клиент уже встал - дальше отступать некуда.

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