Всем привет,
Я последние несколько лет очень часто сталкиваюсь с проектами по адаптации под 152-ФЗ и он мне, честно, порядком надоел. Поэтому, прочитав опять весь закон, все комментарии различных ведомств и трактовки уважаемых людей, а также проанализировав ряд решений, которые прошли успешно аудит. Я, кажется, нашел простой технический вариант как сделать ваш web-site, API или приложение, соответствующее закону о персональных данных 152-ФЗ в разрезе требования о сборе пнд на территории России.
Я даже автоматизировал развертывание этой штуки и это занимает не больше 10-ти минут. Давайте обсудим применимость данного подхода!?
Чуть-чуть про сам закон, 152-ФЗ
Я уже и не помню зачем он на самом деле создавался, толи для того, что бы фейсбук и твиттер хранили данные о Российских граждан в РФ и таким образом к ним был бы более простой способ доступа у правоохранительных органов. Возможно, для того, чтобы они были в безопасности. Назначение самого закона оставим за скобками, а углубимся сразу в его требования. Сам закон обширный, но самый большой камень преткновения описан в статье 18, п.5:
"При сборе персональных данных, в том числе посредством информационно-телекоммуникационной сети "Интернет", оператор обязан обеспечить запись, систематизацию, накопление, хранение, уточнение (обновление, изменение), извлечение персональных данных граждан Российской Федерации с использованием баз данных, находящихся на территории Российской Федерации, за исключением случаев, указанных в пунктах 2, 3, 4, 8 части 1 статьи 6 настоящего Федерального закона."
Хочу обратить внимание именно на слова "при сборе персональных данных". Если попробовать перевести в простой язык, то его можно трактовать так, что собирать данные нужно используя базу данных в РФ и еще держать ее актуальной. Никаких ограничений для других операций в законе нет и ограничений, что можно делать дальше с этими данными так же нет. Это самый тонкий момент тут, так как пояснений, что такое база-данных или другие понятия закон не описывает, то это все трактуют очень по разному. Вот самые распространенные трактовки, которые я слышу:
Собирать персональные данные нужно в РФ, дальше можно их отправлять куда захочется.
Вообще нельзя отправлять персональные данные за пределы РФ.
Вообще ничего нельзя никуда отправлять и нельзя нигде ничего размещать за пределами РФ.
Но на основе того как уже реализуются системы и как проходят проверки, можно смело заявить, что первый вариант точно рабочий и валидный. Теперь разобравшись чуть-чуть с требованиями перейдем к тому как это можно реализовать и уже выдохнуть.
Варианты реализации
Ниже список вариантов как компании этот закон исполняют с технической стороны и что я встречал:
Вообще его игнорируют. Привет Facebook и Twitter.
Доказывают себе и другим, что у них нет персональных данных. Закон, кстати, так себе описывает, что такое персональные данные.
Арендуют сервер или виртуальную машину в РФ, кладут на него excel фаил - "персональные данные.xls" и отчитываются документально перед проверяющими органами.
Вносят руками данные локально в excel или в локальную систему перед тем как внести их в систему размещенную за пределами РФ.
Просто разворачивают копию системы в РФ и пользователей маршрутизируют на уровне DNS между площадками.
Выносят из приложения часть логики и размещают ее в РФ, где происходит сбор и хранение персональных данных. (Самый крутой вариант с моей точки зрения).
Вариантов я видел уже больше нескольких десятков, не буду браться за их оценку с точки зрения закона, а лучше сразу перейду, с моей точки зрения самому простому варианту, который кстати совсем не новый.
Описание реализации - Reverse Proxy
Концептуально выглядит он примерно как на архитектуре ниже.
Ничего сложного и логика работы следующая:
DNS на основе гео принадлежности пользователя маршрутизирует запросы. Если пользователь из РФ, то он идет по правой части картинки на прокси сервер. В данном случае на картинке Route53, но может быть и другой DNS сервис.
Reverse proxy, в данном случае это nginx принимает HTTP/HTTPS запрос и если он (POST, PUT, DELETE и тд), то кладет его локально в лог и в базу данных (PostgreSQL) с помощью плагина - rsyslog-pgsql в json формате.
Дальше запрос отсылается в первичную систему, получает ответ и отдает его пользователю.
Для пользователя процесс выглядит совершенно прозрачным и не нужно менять никакой логики у него, он как-будто взаимодействует с оригинальной системой.
"Постойте, так ведь это просто сбор логов HTTP/S запросов, разве это считается?" - спросите вы. С точки зрения закона он никак не регламентирует формат и структуру сбора и хранения данных и только говорит про использование базы-данных. Поэтому с логической точки зрения тут все по букве закона. Похоже, примерно так же SAP доработал свою систему, вот тут можно почитать более подробно в их блоге. Там очень часто упоминается, что пишется лог изменений в РФ.
В базе данных будут храниться HTTP/S логи запросов на создание и изменения, что-то вроде changefeed. Но это легко можно расширить если известна модель пересылаемых данных и встроить эту логику в виде python скрипта или просто сделать trigger в базе данных, которая будет схлопывать changefeed в нужную структуру, где запись об одном человеке будет одна.
Как развернуть это себе?
Я автоматизировал развертывания и настройки этого модуля и опубликовал его тут на Github как open source проект. Если кто-то хочет дополнить или расширить этот проект то смело пишите мне или создавайте pull request.
Краткое пояснения как развернуть:
Пропишите в вашей DNS записи A-record с айпи адресом на ваш сервер, который будет выступать reverse-proxy.
Зайдите на вашу виртуальную машину или свой сервер и сделайте:
git clone https://github.com/Gaploid/FZ-152-Reverse-ProxyСделайте файл executable: chmod +x install.sh
Запустите скрипт:
sudo ./install.sh <incoming_domain> <url_to_forward_traffic>Пример:sudo ./install.sh example.com http://example.comгде<incoming_domain>это домен на который пользователь будет заходить, он может быть существующим.<url_to_forward_traffic>это адрес первоначальной системы.Все, после этого если вы зайдете на
<incoming_domain>все запросы POST, DELETE, PUT буду складываться локально в лог фаил - /var/log/nginx/reverse-access.log и в базу: proxy_logs в таблицу: accesslog.
Если вы хотите добавить HTTPS, то это можно сделать несколькими способами:
Добавить свой существующий сертификат в nginx. Вот пример инструкции.
Добавить новый сертификат от let's encrypt. Я для этого сделал скрипт
./add_ssl.shвам нужно просто его будет запустить на этом же сервере. Сертификат получается с помощью бота от let's encrypt автоматически, но валидацию, что это действительно ваш домен он проводит путем проверки доступности по указанному домену <incoming_domain> вашего сервера, который вы указали на первом шаге.
Все на этом ваше мобильное приложение или даже веб-сайт если он работает через ваше API будет работать так как и работал и ничего в них не нужно менять.
Как еще это можно улучшить?
На nginx можно дополнительно выставить фильтр какие запросы перехватывать и вы можете указать, например, что нужно перехватывать если URL - myapp.com/profile/ в таком случае только запросы связанные с профилем будут сохраняться, что сильно уменьшит объем хранимых данных.
Как я писал выше можно добавить триггер в базу данных, которые будет парсить JSON запроса и класть уже в другую таблицу в структуру, когда на одного человека будет приходиться только одна запись.
Можно еще добавить веб интерфейс с поиском, который будет показывать все записи по поисковой строке, например по ФИО или айди человека.
Послесловие
Я ни в коем случае не претендую, что это решение является серебряной пулей для всех сценариев, а так же не берусь его оценивать с юридической стороны. Поэтому перед тем как использовать проконсультируйтесь с юристами в вашей компании или во внешних агентствах.
Причина по которой я написал эту статью - желание обсудить валидность и применимость данного варианта с комьюнити, поэтому смело пишите ваши мысли в комментариях.
