GDPR/152-ФЗ compliance: шифрование, логирование, доступ

152-ФЗ compliance: где ломается защита персональных данных

Типовая проверка 152-ФЗ compliance начинается не с документов, а с инфраструктуры — и там находится одно и то же. Журналы доступа пишутся, но без сроков хранения и без защиты от правки: запись можно изменить или удалить, а доказать, кто и когда читал базу, нечем. Права на базы выданы широким группам — «на время», «для отладки» — и остаются действовать годами.

Резервные копии лежат в том же хранилище, что и рабочие данные, часто без шифрования, а ключи шифрования данных — рядом с самими данными: восстановление удобно, но шифрование перестаёт что-либо защищать. Любая утечка данных в такой схеме не расследуется — подтвердить, читал ли кто-то копию, нечем.

Причина обычно одна: инфраструктура растёт быстрее, чем политики. Доступ выдаётся под задачу и не отзывается, журналы включаются без ротации, копии складываются туда, где быстрее, а ключи — туда, где проще достать при аварии. Разграничение доступа и защита персональных данных остаются на уровне устных договорённостей.

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

Что даёт выстроенный контур защиты данных на практике

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

Шифрование: где закрывается канал утечки

Данные шифруются в трёх состояниях: на диске, в резервных копиях и в канале между сервисами. Ключи хранятся в отдельном хранилище с ротацией, доступ к ним получают сервисы по ролям, а не люди — доля данных под шифрованием доводится до 100%, и копия базы, оказавшаяся не там, где нужно, остаётся бесполезным набором блоков.

Логирование: из чего собирается доказательная база

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

Контроль доступа описывается ролями и подтверждается регулярной сверкой: отчёт о том, у кого какие права, собирается за часы вместо недель ручного обхода систем. Восстановление после сбоя идёт по проверенному сценарию — время возврата сервиса измеряется десятками минут, а класс отказов «резервная копия есть, но не восстанавливается» уходит после учений на отдельном контуре.

Режимы шифрования и хранения: сравнение подходов

Выбор режима шифрования определяет не стойкость алгоритма, а граница доверия: где лежит ключ и кто к нему допущен. Ниже — четыре варианта, между которыми выбирают при обработке персональных данных.

Где хранить ключи и кто ими управляет

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

Разделение данных по уровням чувствительности

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

Внедрение 152-ФЗ compliance: этапы инженерной работы

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

Инвентаризация: карта данных и потоков

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

1. Инвентаризация данных и потоков — реестр систем, категорий данных и точек передачи.
2. Схема размещения и шифрование — где данные лежат физически, шифрование при хранении и в канале, порядок работы с ключами.
3. Разграничение доступа — роли по принципу минимально необходимого, отдельные сервисные учётные записи, отзыв доступа при увольнении.
4. Настройка журналирования — события доступа к персональным данным в отдельное хранилище, защищённое от правки и удаления.
5. Проверка сценариев восстановления — учебное развёртывание из резервной копии на чистый контур.
6. Регламент реагирования — кто, что и в какой срок делает при инциденте, кому и как сообщает; передача документации вашей команде.

Проверка: как убеждаемся, что меры работают

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

Политики доступа, схемы шифрования и регламенты логирования

Регламенты — это то, что остаётся у заказчика после внедрения: не настроенный сервер, а письменные процедуры, по которым проверяющий видит, что доступ, шифрование и журналирование управляются, а не сложились стихийно. Ниже — комплект артефактов, который мы передаём в составе проекта: каждый закрывает свой пункт 152-ФЗ и GDPR.

Матрица доступа и служебные учётные записи

• Матрица ролей и прав: кто из сотрудников и подрядчиков к каким системам и данным имеет доступ — с обоснованием каждой роли.
• Политика доступа: единая точка входа, двухфакторная аутентификация, минимально необходимые права, порядок согласования и отзыва при смене роли или увольнении.
• Служебные учётные записи: для каждой — владелец, назначение, срок жизни, хранение секрета в защищённом хранилище и запрет входа по паролю.
• Схема потоков персональных данных и политика хранения ключей шифрования: где данные лежат, где обрабатываются, кто может использовать ключ и с какой периодичностью он ротируется.

Журналы: состав, сроки, защита от изменения

• Правила и сроки хранения журналов: перечень событий, обязательных к записи, срок хранения и порядок ротации.
• Защита от изменения: хранилище только на добавление, раздельные права на чтение и запись, контроль целостности, вынос журналов в отдельный контур.
• Регламент ответа на инцидент: обнаружение, классификация, сроки уведомления регулятора и субъектов данных, разбор причин и правка прав доступа.

Комплект согласуем с вашим отделом информационной безопасности и приводим к виду, пригодному для внутреннего аудита.

Кейс: закрыли замечания аудита по защите персональных данных

Заказчик — сервис с персональными данными десятков тысяч пользователей. Перед плановой проверкой регулятора внутренний аудит нашёл расхождение между политикой доступа и тем, как права выданы на практике. Кейс внедрения начинался с инвентаризации учётных записей, а не с покупки новых средств защиты.

Что было до: узкие места

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

Резервные копии шифровались не везде: часть копий с персональными данными лежала на общем хранилище, доступ к которому был шире круга допущенных лиц. Журналы велись, но не сводились в одно место, поэтому восстановить, кто читал конкретную запись, было нельзя.

Что стало после: измеримые сдвиги

Учётные записи перевели в Keycloak как единый источник ролей: права выдаём под роль и на срок, а не «на всякий случай». Избыточные права сократили у 68% учётных записей, закрытие доступа при увольнении или переводе занимает часы вместо недель.

Отчёт по доступам собирается за 10 минут одной выгрузкой — видно, у кого какие права и на каком основании. Защита резервных копий закрыта шифрованием на стороне источника, ключи вынесены в отдельное хранилище, журналы доступа сведены в общий контур с неизменяемым сроком хранения.

Прохождение проверки — без замечаний по доступам и защите копий; остался плановый список улучшений, который закрываем по обычному процессу сопровождения.

Что делать, если инфраструктура уже развёрнута?

Перестраивать работающий контур целиком не нужно: основная часть требований 152-ФЗ закрывается надстройкой. Шифрование каналов и носителей, разграничение ролей, журналирование операций с персональными данными и регламент их хранения включаются поверх существующих сервисов, без переписывания приложений.

Поэтапное внедрение начинается с инвентаризации: где физически лежат данные, какие сервисы и внешние обмены к ним обращаются, у кого есть прямой доступ к СУБД и резервным копиям. Дальше приоритет по риску — сначала изолируются хранилища с наибольшим объёмом записей и внешние интеграции.

По частям придётся менять схему аутентификации, сетевую сегментацию и обращение с ключами. Здесь помогает переходный период: новый контур поднимается рядом со старым, сервисы переводятся группами, прежние учётные записи живут до полного переноса прав. Секреты и ротацию ключей берёт на себя HashiCorp Vault — сервисы получают доступ через короткоживущие учётные данные вместо статичных строк подключения в конфигурации, и утечка файла настроек перестаёт открывать базу.

Минимизация изменений достигается тем, что приложения остаются нетронутыми: меняется слой доступа, поэтому переход идёт без остановки сервисов. Сессии не сбрасываются, права выдаются группами, каждое изменение фиксируется в журнале — аудитор видит, кто, когда и к каким записям получил доступ.

Технические сомнения: шифрование, журналы, доступы

Перед стартом проекта по 152-ФЗ всплывают одни и те же вопросы: придётся ли переписывать сервисы, где лежат ключи, что делать с данными вне периметра и как удержать соответствие при изменениях. Ниже — ответы, чтобы вы сверили их со своей архитектурой.

Кто владеет ключами?

Ключи остаются в вашем контуре: мы настраиваем управление ими, но не становимся держателем. Ротация по расписанию и разделение ролей — расшифровать и выдать доступ не может один человек. Границы ответственности фиксируем письменно, включая проверку подрядчика.

Что делать с данными вне периметра?

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

Как удержать соответствие при изменениях?

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

Обсудим задачу: что прислать для оценки контура

Чтобы вернуться с оценкой работ и планом внедрения, а не с общими формулировками, нужен минимальный состав исходных данных. Чем точнее вводные, тем меньше допущений в смете и реалистичнее сроки этапов: правки на середине проекта обходятся дороже, чем полчаса на разбор схемы в начале.

• Схема сервисов и потоков данных: где хранятся записи, куда уходят копии и выгрузки, есть ли резервные площадки и передача за пределы контура.
• Перечень обрабатываемых данных и категории субъектов: обычные персональные, специальные категории, обезличенные наборы — от этого зависит объём шифрования и порядок работы с согласиями.
• Текущие политики доступа и модель ролей: как выдаются права, кто обладает расширенными полномочиями, остались ли общие учётные записи без персональной ответственности.
• Состав журналов: какие события уже фиксируются, где лежат, сколько хранятся и защищены ли от изменения задним числом.
• Требования проверяющих или внутреннего аудита: предписание, перечень замечаний, опросный лист — под них выстраиваем приоритет этапов.
• Ограничения: регламентные окна, заморозка релизов, требования по размещению данных на территории страны.

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

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