← Блог

Персональные данные в своей системе — что решается при проектировании

Не юридический разбор, а список решений, которые принимаются до разработки, потому что потом стоят дороже

Персональные данные есть почти в любой системе. Как только в базе появились ФИО клиента, телефон сотрудника или адрес объекта, компания становится оператором персональных данных со всеми обязанностями, которые из этого следуют.

Разберем это с точки зрения того, кто проектирует и заказывает систему. Не юридический разбор закона, а список решений, которые принимаются до разработки, потому что потом они стоят дороже.

Что нельзя выпускать за границу контура

Что можно и нельзя передавать во внешние сервисы Слева система в российском контуре с персональными данными. Справа внешние сервисы. Передача обезличенных данных разрешена, передача ФИО, телефонов и адресов во внешний сервис без оснований — нет. ваша система серверы в РФ ФИО, телефон, адрес паспорт, СНИЛС номер заказа, объем, дата текст без имен внешний сервис облачная модель, аналитика, рассылки, хранилище возможно, за пределами РФ граница контура обезличенное уходит свободно, персональное — только с основанием и в нужной юрисдикции
Большинство задач решается обезличиванием: во внешний сервис уходит номер заказа и объем, а имя и телефон остаются в вашей системе.

Что решается при проектировании

  1. Где физически лежит база. Первичная запись и обновление персональных данных россиян должны происходить в базах на территории РФ. Это определяет выбор хостинга и, если продукт международный, архитектуру целиком.
  2. Какие данные вообще собираем. Лишнее поле в форме — это лишние обязанности. Если данные не нужны для конкретной цели, их лучше не собирать.
  3. Согласие и его хранение. Где, когда и на что человек согласился, с фиксацией версии текста. Скриншот формы через год ничего не докажет.
  4. Разграничение доступа. Кто из сотрудников видит персональные данные. Менеджеру нужен телефон клиента, аналитику — нет.
  5. Журнал действий. Кто смотрел, кто менял, кто выгружал. Выгрузка базы — событие, которое должно быть видно.
  6. Удаление. Человек имеет право попросить удалить его данные. Система должна это уметь, а не только помечать флажком.

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

Обезличивание как рабочий прием

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

Аналитика

Для отчетов и прогнозов имя клиента не нужно. Достаточно идентификатора, который вне вашей системы ничего не значит.

Языковые модели

Перед отправкой текста имена, телефоны и адреса заменяются метками, после ответа подставляются обратно. Работает почти для всех сценариев разбора обращений.

Тестовые среды

На тестовом контуре не должно быть боевых персональных данных. Их заменяют сгенерированными. Это же избавляет от целого класса инцидентов.

Подрядчики

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

Что часто упускают

  • Резервные копии. Удалили данные из базы, а они остались в бэкапах за полгода. Порядок удаления из копий должен быть описан.
  • Логи. Телефоны и адреса попадают в технические журналы и живут там годами. Персональные данные из логов нужно вычищать на уровне кода.
  • Выгрузки в таблицы. Сотрудник выгрузил базу в файл и отправил себе на почту. Это самый частый канал утечки, и он закрывается ограничением на выгрузку плюс журналом.
  • Уведомление регулятора. Оператор персональных данных должен подать уведомление в Роскомнадзор. Это формальность, но ее отсутствие — самое простое нарушение для проверки.
  • Иностранные сервисы в стеке. Рассылки, аналитика, чаты на сайте, облачные хранилища. Каждый такой сервис — это передача данных, и она должна быть осознанной.

Где здесь ИИ

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

Варианты решения три, и они не исключают друг друга.

Обезличивание перед отправкой. Подходит для большинства сценариев разбора текста. Имена и контакты заменяются метками автоматически.

Российский провайдер. Модели, работающие в РФ, снимают вопрос трансграничной передачи. Остаются вопросы к договору и к тому, используются ли данные для обучения.

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

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

Минимальный набор документов

Техническая часть — половина дела. Вторая половина оформляется на бумаге, и без нее любая проверка заканчивается одинаково.

  • Политика обработки персональных данных. Опубликована на сайте, доступна по прямой ссылке.
  • Уведомление в Роскомнадзор. Подается один раз, обновляется при изменении состава данных или целей.
  • Согласия. Форма согласия, момент его получения и хранение факта с датой и версией текста.
  • Приказ о лицах, допущенных к обработке. Кто именно из сотрудников имеет доступ.
  • Поручения на обработку. Для каждого подрядчика и сервиса, который обрабатывает данные от вашего имени.
  • Перечень обрабатываемых данных и мест хранения. Тот же документ, который полезен и для проектирования.

Если что-то утекло

Вероятность утечки не нулевая ни у кого, поэтому порядок действий стоит продумать заранее.

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

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

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

Частые вопросы

Мы маленькая компания, нас это касается?

Касается. Обязанности оператора не зависят от размера. При этом объем требований разный: система для пятнадцати сотрудников и сервис с данными миллиона клиентов защищаются по-разному.

Нужна ли аттестация и сертифицированные средства защиты

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

Можно ли хранить копию за границей

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

Заложим требования к данным в архитектуру сразу

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

Обсудить задачу

Это проектное решение, а не юридическая консультация: по спорным вопросам подключается профильный юрист.

Дальше по теме