Всем привет, Я последние несколько лет очень часто сталкиваюсь с проектами по адаптации под 152-ФЗ и он мне, честно, порядком надоел. Поэтому, прочитав опять весь закон, все комментарии различных ведомств и трактовки уважаемых людей, а также проанализировав ряд решений, которые прошли успешно аудит. Я, кажется, нашел простой технический вариант как сделать ваш web-site, API или приложение, соответствующее закону о персональных данных 152-ФЗ в разрезе требования о сборе пнд на территории России. Я даже автоматизировал развертывание этой штуки и это занимает не больше 10-ти минут. Давайте обсудим применимость данного подхода!? Я уже и не помню зачем он на самом деле создавался, толи для того, что бы фейсбук и твиттер хранили данные о Российских граждан в РФ и таким образом к ним был бы более простой способ доступа у правоохранительных органов. Возможно, для того, чтобы они были в безопасности. Назначение самого закона оставим за скобками, а углубимся сразу в его требования. Сам закон обширный, но самый большой камень преткновения описан в статье 18, п.5:   "При сборе персональных данных, в том числе посредством информационно-телекоммуникационной сети "Интернет", оператор обязан обеспечить запись, систематизацию, накопление, хранение, уточнение (обновление, изменение), извлечение персональных данных граждан Российской Федерации с использованием баз данных, находящихся на территории Российской Федерации, за исключением случаев, указанных в пунктах 2, 3, 4, 8 части 1 статьи 6 настоящего Федерального закона." Хочу обратить внимание именно на слова "при сборе персональных данных". Если попробовать перевести в простой язык, то его можно трактовать так, что собирать данные нужно используя базу данных в РФ и еще держать ее актуальной. Никаких ограничений для других операций в законе нет и ограничений, что можно делать дальше с этими данными так же нет. Это самый тонкий момент тут, так как пояснений, что такое база-данных или другие понятия закон не описывает, то это все трактуют очень по разному. Вот самые распространенные трактовки, которые я слышу: Собирать персональные данные нужно в РФ, дальше можно их отправлять куда захочется. Вообще нельзя отправлять персональные данные за пределы РФ. Вообще ничего нельзя никуда отправлять и нельзя нигде ничего размещать за пределами РФ. Но на основе того как уже реализуются системы и как проходят проверки, можно смело заявить, что первый вариант точно рабочий и валидный. Теперь разобравшись чуть-чуть с требованиями перейдем к тому как это можно реализовать и уже выдохнуть. Ниже список вариантов как компании этот закон исполняют с технической стороны и что я встречал: Вообще его игнорируют. Привет Facebook и Twitter. Доказывают себе и другим, что у них нет персональных данных. Закон, кстати, так себе описывает, что такое персональные данные. Арендуют сервер или виртуальную машину в РФ, кладут на него excel фаил - "персональные данные.xls" и отчитываются документально перед проверяющими органами. Вносят руками данные локально в excel или в локальную систему перед тем как внести их в систему размещенную за пределами РФ. Просто разворачивают копию системы в РФ и пользователей маршрутизируют на уровне DNS между площадками. Выносят из приложения часть логики и размещают ее в РФ, где происходит сбор и хранение персональных данных. (Самый крутой вариант с моей точки зрения). Вариантов я видел уже больше нескольких десятков, не буду браться за их оценку с точки зрения закона, а лучше сразу перейду, с моей точки зрения самому простому варианту, который кстати совсем не новый. Концептуально выглядит он примерно как на архитектуре ниже.  Ничего сложного и логика работы следующая: 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 запроса и класть уже в другую таблицу в структуру, когда на одного человека будет приходиться только одна запись. Можно еще добавить веб интерфейс с поиском, который будет показывать все записи по поисковой строке, например по ФИО или айди человека. Я ни в коем случае не претендую, что это решение является серебряной пулей для всех сценариев, а так же не берусь его оценивать с юридической стороны. Поэтому перед тем как использовать проконсультируйтесь с юристами в вашей компании или во внешних агентствах. Причина по которой я написал эту статью - желание обсудить валидность и применимость данного варианта с комьюнити, поэтому смело пишите ваши мысли в комментариях.