ФЗ-152 надоел, простое решение c хранением персональных данных на nginx

    Всем привет,

    Я последние несколько лет очень часто сталкиваюсь с проектами по адаптации под 152-ФЗ и он мне, честно, порядком надоел. Поэтому, прочитав опять весь закон, все комментарии различных ведомств и трактовки уважаемых людей, а также проанализировав ряд решений, которые прошли успешно аудит. Я, кажется, нашел простой технический вариант как сделать ваш web-site, API или приложение, соответствующее закону о персональных данных 152-ФЗ в разрезе требования о сборе пнд на территории России.

    Я даже автоматизировал развертывание этой штуки и это занимает не больше 10-ти минут. Давайте обсудим применимость данного подхода!?

    Чуть-чуть про сам закон, 152-ФЗ

    Я уже и не помню зачем он на самом деле создавался, толи для того, что бы фейсбук и твиттер хранили данные о Российских граждан в РФ и таким образом к ним был бы более простой способ доступа у правоохранительных органов. Возможно, для того, чтобы они были в безопасности. Назначение самого закона оставим за скобками, а углубимся сразу в его требования. Сам закон обширный, но самый большой камень преткновения описан в статье 18, п.5:

    "При сборе персональных данных, в том числе посредством информационно-телекоммуникационной сети "Интернет", оператор обязан обеспечить запись, систематизацию, накопление, хранение, уточнение (обновление, изменение), извлечение персональных данных граждан Российской Федерации с использованием баз данных, находящихся на территории Российской Федерации, за исключением случаев, указанных в пунктах 2348 части 1 статьи 6 настоящего Федерального закона."

    Хочу обратить внимание именно на слова "при сборе персональных данных". Если попробовать перевести в простой язык, то его можно трактовать так, что собирать данные нужно используя базу данных в РФ и еще держать ее актуальной. Никаких ограничений для других операций в законе нет и ограничений, что можно делать дальше с этими данными так же нет. Это самый тонкий момент тут, так как пояснений, что такое база-данных или другие понятия закон не описывает, то это все трактуют очень по разному. Вот самые распространенные трактовки, которые я слышу:

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

    • Вообще нельзя отправлять персональные данные за пределы РФ.

    • Вообще ничего нельзя никуда отправлять и нельзя нигде ничего размещать за пределами РФ.

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

    Варианты реализации

    Ниже список вариантов как компании этот закон исполняют с технической стороны и что я встречал:

    1. Вообще его игнорируют. Привет Facebook и Twitter.

    2. Доказывают себе и другим, что у них нет персональных данных. Закон, кстати, так себе описывает, что такое персональные данные.

    3. Арендуют сервер или виртуальную машину в РФ, кладут на него excel фаил - "персональные данные.xls" и отчитываются документально перед проверяющими органами.

    4. Вносят руками данные локально в excel или в локальную систему перед тем как внести их в систему размещенную за пределами РФ.

    5. Просто разворачивают копию системы в РФ и пользователей маршрутизируют на уровне DNS между площадками.

    6. Выносят из приложения часть логики и размещают ее в РФ, где происходит сбор и хранение персональных данных. (Самый крутой вариант с моей точки зрения).

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

    Описание реализации - Reverse Proxy

    Концептуально выглядит он примерно как на архитектуре ниже.

    Ничего сложного и логика работы следующая:

    1. DNS на основе гео принадлежности пользователя маршрутизирует запросы. Если пользователь из РФ, то он идет по правой части картинки на прокси сервер. В данном случае на картинке Route53, но может быть и другой DNS сервис.

    2. Reverse proxy, в данном случае это nginx принимает HTTP/HTTPS запрос и если он (POST, PUT, DELETE и тд), то кладет его локально в лог и в базу данных (PostgreSQL) с помощью плагина - rsyslog-pgsql в json формате.

    3. Дальше запрос отсылается в первичную систему, получает ответ и отдает его пользователю.

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

    "Постойте, так ведь это просто сбор логов HTTP/S запросов, разве это считается?" - спросите вы. С точки зрения закона он никак не регламентирует формат и структуру сбора и хранения данных и только говорит про использование базы-данных. Поэтому с логической точки зрения тут все по букве закона. Похоже, примерно так же SAP доработал свою систему, вот тут можно почитать более подробно в их блоге. Там очень часто упоминается, что пишется лог изменений в РФ.

    В базе данных будут храниться HTTP/S логи запросов на создание и изменения, что-то вроде changefeed. Но это легко можно расширить если известна модель пересылаемых данных и встроить эту логику в виде python скрипта или просто сделать trigger в базе данных, которая будет схлопывать changefeed в нужную структуру, где запись об одном человеке будет одна.

    Как развернуть это себе?

    Я автоматизировал развертывания и настройки этого модуля и опубликовал его тут на Github как open source проект. Если кто-то хочет дополнить или расширить этот проект то смело пишите мне или создавайте pull request.

    Краткое пояснения как развернуть:

    1. Пропишите в вашей DNS записи A-record с айпи адресом на ваш сервер, который будет выступать reverse-proxy.

    2. Зайдите на вашу виртуальную машину или свой сервер и сделайте: git clone https://github.com/Gaploid/FZ-152-Reverse-Proxy

    3. Сделайте файл executable: chmod +x install.sh

    4. Запустите скрипт: sudo ./install.sh <incoming_domain> <url_to_forward_traffic> Пример: sudo ./install.sh example.com http://example.com где <incoming_domain>это домен на который пользователь будет заходить, он может быть существующим. <url_to_forward_traffic> это адрес первоначальной системы.

    5. Все, после этого если вы зайдете на <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 будет работать так как и работал и ничего в них не нужно менять.

    Как еще это можно улучшить?

    1. На nginx можно дополнительно выставить фильтр какие запросы перехватывать и вы можете указать, например, что нужно перехватывать если URL - myapp.com/profile/ в таком случае только запросы связанные с профилем будут сохраняться, что сильно уменьшит объем хранимых данных.

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

    3. Можно еще добавить веб интерфейс с поиском, который будет показывать все записи по поисковой строке, например по ФИО или айди человека.

    Послесловие

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

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

    Комментарии 24

      +3
      • В современных реалиях всю эту установку можно заменить на docker run nginx с конфигом из десяти строк. В нем логично бы передавать proxy_set_header X-Forwarded-For $remote_addr; а на стороне принимающего сервера настроить set_real_ip_from
      • if с request_method не нужен. Если не хочется логгировать какие-то методы, сделайте map $request_method $loggable { PUT 1; POST 1; DELETE 1; default 0;} и access_log… if=$loggable; Если вы среди прочего передаете логины и пароли, они будут в логе в открытом виде.
      • Понятие база данных в ФЗ не уточнено, согласно разъяснению РКН это может быть Эксель, а следовательно и csv, и, видимо, json. Поэтому засовывать логи в БД и считать что этим выполняется закон — несколько странно. Храните структурированные логи, хотя вопрос упорядоченности данных там довольно неоднозначный.
      • Законом устанавливается достаточное количество дополнительных требований, который такой формат хранения логов даже в базе данных удовлетворить не может, в частности актуализация предусматривает удаление неактуальных данных, отзыв согласия — вообще полное удаление, и т.п.
      • Законом предусматривается упрощенная передача ПД в страны, обеспечивающие свои стандарты по работе с ПД, явно упомянута конвенция Совета Европы, и среди подписавших ее стран нет США, нет их и в дополнительном списке РКН, то есть субъект ПД должен явно дать свое согласие на трансграничную передачу ПД. Кстати, по GDPR трансграничная передача ПД в ненадежные страны вообще запрещена.
      • Ну и самое главное, тот самый п 18.5 предполагает, что данные граждан РФ вы будете не просто сохранять, но и ИЗВЛЕКАТЬ из БД на территории РФ

      P.S.: Этот ФЗ не является смарт-контрактом, и РКН будет рассматривать выполнение закона по сути, а не по формальному [не]соблюдению каких-то отдельных условий

        +1

        У нас недавно был трейнинг по GDPR.


        по GDPR трансграничная передача ПД в ненадежные страны вообще запрещена.

        Не совсем так. Передавать можно, но нужно с партнёром заключать договор, который будет строго соответствовать GDPR. Я не помню, должен ли там быть ещё независимый аудит или нет...

        0
        Спасибо за комментарий, попробую прокомментировать его:
        • Docker я намеряно не использовал, так как внутри база данных и придется тогда делать persistent volume, что несколько уже усложняет все это и от докера теряется смысл. Но ничего не мешает запустить скрипт внутри докера.
        • Базу данных было несложно добавить, поэтому как дополнительная галочка, то не помешает. А так же с помощью нее можно еще хранить и трансформировать changefeed в справочник персон и их данных. Как хороший задел для расширения.
        • «предусматривает удаление неактуальных данных» такого в законе нет, актуализация может быть произведена очень многими разными способами. Отзыв согласия как мне, кажется, есть в GDPR, а в ФЗ-152 такого я не помню.
        • Про США нужно дополнительно уточнять, про требования о странах подписавших эту конвенцию для передачи персональных данных, я слышу если честно в первый раз.
        • «не просто сохранять, но и ИЗВЛЕКАТЬ из БД на территории РФ», в законе явно сказано только:«При сборе персональных данных», а дальше уже перечислены операции в рамках этого процесса.
          0

          Часть 4:


          1. При обработке персональных данных должны быть обеспечены точность персональных данных, их достаточность, а в необходимых случаях и актуальность по отношению к целям обработки персональных данных. Оператор должен принимать необходимые меры либо обеспечивать их принятие по удалению или уточнению неполных или неточных данных.


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



          Спасибо за попытку, но похоже что ваше решение не подходит

            0
            А в чем тут противоречие? 1) Данные всегда актуальны и записываются все изменения. 2) Если есть срок хранения, то можно сделать автоматическое удаление. Сделать это можно по дате записи лога в PostgreSQL, лог фаил приэтом просто будет временным буфером.

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

              SAP насколько мне известно поставили асинхронные апдейды в БД на территории РФ если паспорт субьекта персональных данных РФ. Далее все записывается и обрабатывается в глобальную базу также как обычно. Что то вроде
              if (pasport=russia) then save to russia db
              save to glabal db
              и далее без поправок на рф работают как обычно...

            0
            А если я гражданин РФ, но регистрируюсь не из РФ?
              0
              Reverse proxy, в данном случае это nginx принимает HTTP/HTTPS запрос и если он (POST, PUT, DELETE и тд), то кладет его локально в лог и в базу данных (PostgreSQL) с помощью плагина — rsyslog-pgsql в json формате.

              Я может чего не понимаю. Но какая связь типа запроса и персональных данных?
                +1
                Тот кто изменяет данные GET запросами определенно делает что-то не так :))
                  0
                  Так речь то не о том. Тип запроса это просто тип запроса, не более. С чего уверенность что он меняет именно персональные данные?
                    0
                    Ну там же написано, что перфекционисты могут добавить фильтр по URL.
                      0
                      Понимаете в нормальном проекте количество запросов касающихся ПД пренебрежимо мало по сравнению с прочими другими.
                      Тут нужно не перфекционистом быть а просто минимально разумным человеком.
                        0

                        А что, уже есть полный список того, что считается ПД?

                          0
                          А зачем для этого полный список?
                            0

                            А как без полного списка можно уверенно решить исключить отдельные url из лога? Вдруг именно через них передаются данные, которые органы внезапно решат назвать персональными? Я к тому, что для того, чтобы принимать решение исключить из БД часть данных нужно иметь уверенность, что они не являются ПД, а такой уверенности неоткуда взяться пока нет чёткого списка данных, которые (не) являются ПД.

                              0
                              Тогда речь идет не о хранении ПД а о тупом логировании всех действий пользователя.
                                +1

                                Учитывая неопределённость понятия ПД тупое логирование всех действий гарантированно включит в "БД" все ПД. В то время как более "умный" подход может что-то упустить. У тупого логирования есть другие недостатки — избыточный объём (особенно если юзеры заливают файлы а мы логируем тело POST), пароли/токены в логах, полная история всех изменений. Но в плане решения "наотъебись" для формального соответствия требованиям закона — подход вполне любопытный. На окончательное решение он не очень тянет, слишком серьёзные недостатки, но как идея в целом — может из него что-то и получится. Например, при использовании честного REST вполне можно автоматизировать создание БД где все ресурсы обновляются автоматически из параметров запроса. Добавить исключение из БД полей со слишком большими значениями (залитые файлы) и полей с именами вроде пароль/токен — и мы получим ведение совершенно альтернативной БД на отдельном сервере, схема и содержимое которой автоматически формируется из параметров проксируемых запросов, и которая при этом имеет вменяемый размер и не содержит ни паролей ни избыточной истории изменения записей.

                                  0
                                  Да, я именно хотел задать этим примером конву решения, дальше его уже можно и нужно улучшать.
                  0
                  Так как в этих запросах может передаваться персональные данные и вы правы, что может и не передаваться эта информация. Но закон вот так говорит, что такое персональные данные: "персональные данные - любая информация, относящаяся к прямо или косвенно определенному или определяемому физическому лицу (субъекту персональных данных);" Другими словами это может быть и сведенья о ваших покупках в магазине, так как она относится к вам. Тут большая серая зона и поэтому в примере, который у меня намеряно сделан захват так широко. Разработчик или владелец системы может уже зная структуру запроса вычленять эти данные более гранулярно, но это уже будет конкретная имплементация.
                    +1
                    Я воспринял статью как конкретную имплементацию.
                    ЗЫ Насколько я понимаю сведения о покупках никак не подпадают под ПД. Как и график температуры тела например.
                      0
                      Для каких-то сценариев и каких-то систем это может быть решение as-is, а для кого-то нужно будет его менять, как написали выше и исключать еще доп. информацию.
                      К сожалению, нет четкого понимания, что такое эти перс. данные. Их с точки зрения логики получается два: данные, которые идентифицируют человека (ФИО, паспортные данные), сведенья которые относятся к персоне (политические взгляды, мед. данные, количество детей и семейнное положени). По моему мнению закон затрагивает оба этих типа, но тут уже должны подключаться юристы.
                  0
                  Странное прочтение 152-ФЗ… Очень странное…

                  1) Основная цель требования хранения на территории РФ — чтобы когда нас отключат от глобального интернета, оператор ПДн мог просто тупо продолжить работать. Под эту цель заточены формулировки закона. Очевидно, что для этого ему надо здесь иметь актуальную копию базы.

                  2) Надо обратить внимание, что крупняк, типа ФБ и твиттера вынуждают не просто локализовать ПДн (хранить здесь), но и хотят, чтобы они здесь открыли свои филиалы… А те сопротивляются не просто так, а понимают, чем дело пахнет… А именно, если они откроют тут филиалы, тогда им будет необходимо одно из двух:

                  а) Либо требовать согласия пользователей на трансграничную передачу данных. В текущих условиях с точки зрения 152-ФЗ трансграничная передача ПДн условно отсутствует:), т.к. оператор (условный ФБ) самостоятельно получает ПДн от субъекта ПДн и никому их не передает.

                  б) Полностью локализовать весь комплекс программного обеспечения здесь в России и не передавать в головную контору ничего.

                  Законно собрать со всех пользователей согласие на трансграничную передачу данных нереально. Отказ от предоставления публичной услуги считается «вынуждением». А согласие на обработку ПДн не может быть вынужденным, законным является только добровольное согласие.

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

                  3) Очень многие не понимают определения из 152-ФЗ про трансграничную передачу ПДн. Так вот это не просто передача через границу. По закону никто не запрещает хранить базу на сервере в Европе без упоминания такого хранения в согласии. Копию баз можно хранить где угодно, это не будет считаться трансграничной передачей. Трансграничная передача происходит только тогда, когда на другой стороне (за границей) обработкой этих ПДн будет заниматься уже другое лицо, зарегистрированное в другой стране. Но в России надо хранить актуальную базу.
                    +1
                    Очевидно, что для этого ему надо здесь иметь актуальную копию базы.

                    Очевидно, что одной БД для этого мало. Поэтому странным является как раз Ваше прочтение закона, на мой взгляд — закон говорит только о данных, и польза от наличия именно данных сводится к возможности неограниченного доступа для товарища майора, и всё.


                    отделить часть себя для работы в закрытой, отделенной от мира российской части интернета

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


                    То, что Вы описываете, по сути — это кластеризация проекта, с работой в нескольких ДЦ на разных континентах, с сохранением полной работоспособности всех частей при партиционировании кластера на продолжительное время (условно, месяц), с дальнейшим восстановлением связности и синхронизацией всех данных. Это ппц как сложно (обычно в таких случаях используют технический термин "невозможно") сделать для большого проекта с кучей функционала, который изначально под это не проектировался.

                      0
                      Очевидно, что одной БД для этого мало.

                      Ну при наличии базы интернет-магазин в состоянии хотя бы обработать поступившие заказы. Хотя и большинство других сервисов могут быть развернуты хоть в каком-то усеченном виде. Очевидно, что БЕЗ базы можно только констатировать: «Умерла, так умерла».

                      Одному мне кажется, что это абсолютно нереально?

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

                      Например, гражданин России и Кипра проживает в ОАЭ и черт его дернул зарегистрироваться в сервисе. При этом сервис даже не подозревает, о том, что у него есть эти гражданства. Но… Законодательство России требует, чтобы его данные хранились в России. Законодательство ЕС требует, чтобы хранились в ЕС. По тонкостям ЕС точно сказать не могу, возможно (хотя я и с трудом верю), для таких случаев в законе прописаны исключения. В Российском законе точно исключений нет:). И вот как условному ФБ выполнить все законы сразу, встает очень большой вопрос. Есть подозрение, что в данном случае это теоретически нереально. И таких случаев просто вагон.

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

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

                  Самое читаемое