Комментарии 24
- В современных реалиях всю эту установку можно заменить на 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.: Этот ФЗ не является смарт-контрактом, и РКН будет рассматривать выполнение закона по сути, а не по формальному [не]соблюдению каких-то отдельных условий
- Docker я намеряно не использовал, так как внутри база данных и придется тогда делать persistent volume, что несколько уже усложняет все это и от докера теряется смысл. Но ничего не мешает запустить скрипт внутри докера.
- Базу данных было несложно добавить, поэтому как дополнительная галочка, то не помешает. А так же с помощью нее можно еще хранить и трансформировать changefeed в справочник персон и их данных. Как хороший задел для расширения.
- «предусматривает удаление неактуальных данных» такого в законе нет, актуализация может быть произведена очень многими разными способами. Отзыв согласия как мне, кажется, есть в GDPR, а в ФЗ-152 такого я не помню.
- Про США нужно дополнительно уточнять, про требования о странах подписавших эту конвенцию для передачи персональных данных, я слышу если честно в первый раз.
- «не просто сохранять, но и ИЗВЛЕКАТЬ из БД на территории РФ», в законе явно сказано только:«При сборе персональных данных», а дальше уже перечислены операции в рамках этого процесса.
Часть 4:
При обработке персональных данных должны быть обеспечены точность персональных данных, их достаточность, а в необходимых случаях и актуальность по отношению к целям обработки персональных данных. Оператор должен принимать необходимые меры либо обеспечивать их принятие по удалению или уточнению неполных или неточных данных.
Хранение персональных данных должно осуществляться в форме, позволяющей определить субъекта персональных данных, не дольше, чем этого требуют цели обработки персональных данных, если срок хранения персональных данных не установлен федеральным законом, договором, стороной которого, выгодоприобретателем или поручителем по которому является субъект персональных данных. Обрабатываемые персональные данные подлежат уничтожению либо обезличиванию по достижении целей обработки или в случае утраты необходимости в достижении этих целей, если иное не предусмотрено федеральным законом.
Спасибо за попытку, но похоже что ваше решение не подходит
Но в решении действительно не хватает части для последующего управлениями и просмотром этих данных. Но как я сказал, эту идею и реализацию можно брать за основу и уже адаптировать под свое приложение и сервис.
SAP насколько мне известно поставили асинхронные апдейды в БД на территории РФ если паспорт субьекта персональных данных РФ. Далее все записывается и обрабатывается в глобальную базу также как обычно. Что то вроде
if (pasport=russia) then save to russia db
save to glabal db
и далее без поправок на рф работают как обычно...
Reverse proxy, в данном случае это nginx принимает HTTP/HTTPS запрос и если он (POST, PUT, DELETE и тд), то кладет его локально в лог и в базу данных (PostgreSQL) с помощью плагина — rsyslog-pgsql в json формате.
Я может чего не понимаю. Но какая связь типа запроса и персональных данных?
Тут нужно не перфекционистом быть а просто минимально разумным человеком.
А что, уже есть полный список того, что считается ПД?
А как без полного списка можно уверенно решить исключить отдельные url из лога? Вдруг именно через них передаются данные, которые органы внезапно решат назвать персональными? Я к тому, что для того, чтобы принимать решение исключить из БД часть данных нужно иметь уверенность, что они не являются ПД, а такой уверенности неоткуда взяться пока нет чёткого списка данных, которые (не) являются ПД.
Учитывая неопределённость понятия ПД тупое логирование всех действий гарантированно включит в "БД" все ПД. В то время как более "умный" подход может что-то упустить. У тупого логирования есть другие недостатки — избыточный объём (особенно если юзеры заливают файлы а мы логируем тело POST), пароли/токены в логах, полная история всех изменений. Но в плане решения "наотъебись" для формального соответствия требованиям закона — подход вполне любопытный. На окончательное решение он не очень тянет, слишком серьёзные недостатки, но как идея в целом — может из него что-то и получится. Например, при использовании честного REST вполне можно автоматизировать создание БД где все ресурсы обновляются автоматически из параметров запроса. Добавить исключение из БД полей со слишком большими значениями (залитые файлы) и полей с именами вроде пароль/токен — и мы получим ведение совершенно альтернативной БД на отдельном сервере, схема и содержимое которой автоматически формируется из параметров проксируемых запросов, и которая при этом имеет вменяемый размер и не содержит ни паролей ни избыточной истории изменения записей.
"персональные данные - любая информация, относящаяся к прямо или косвенно определенному или определяемому физическому лицу (субъекту персональных данных);" Другими словами это может быть и сведенья о ваших покупках в магазине, так как она относится к вам. Тут большая серая зона и поэтому в примере, который у меня намеряно сделан захват так широко. Разработчик или владелец системы может уже зная структуру запроса вычленять эти данные более гранулярно, но это уже будет конкретная имплементация.ЗЫ Насколько я понимаю сведения о покупках никак не подпадают под ПД. Как и график температуры тела например.
К сожалению, нет четкого понимания, что такое эти перс. данные. Их с точки зрения логики получается два: данные, которые идентифицируют человека (ФИО, паспортные данные), сведенья которые относятся к персоне (политические взгляды, мед. данные, количество детей и семейнное положени). По моему мнению закон затрагивает оба этих типа, но тут уже должны подключаться юристы.
1) Основная цель требования хранения на территории РФ — чтобы когда нас отключат от глобального интернета, оператор ПДн мог просто тупо продолжить работать. Под эту цель заточены формулировки закона. Очевидно, что для этого ему надо здесь иметь актуальную копию базы.
2) Надо обратить внимание, что крупняк, типа ФБ и твиттера вынуждают не просто локализовать ПДн (хранить здесь), но и хотят, чтобы они здесь открыли свои филиалы… А те сопротивляются не просто так, а понимают, чем дело пахнет… А именно, если они откроют тут филиалы, тогда им будет необходимо одно из двух:
а) Либо требовать согласия пользователей на трансграничную передачу данных. В текущих условиях с точки зрения 152-ФЗ трансграничная передача ПДн условно отсутствует:), т.к. оператор (условный ФБ) самостоятельно получает ПДн от субъекта ПДн и никому их не передает.
б) Полностью локализовать весь комплекс программного обеспечения здесь в России и не передавать в головную контору ничего.
Законно собрать со всех пользователей согласие на трансграничную передачу данных нереально. Отказ от предоставления публичной услуги считается «вынуждением». А согласие на обработку ПДн не может быть вынужденным, законным является только добровольное согласие.
По факту и крупняк вынуждают отделить часть себя для работы в закрытой, отделенной от мира российской части интернета.
3) Очень многие не понимают определения из 152-ФЗ про трансграничную передачу ПДн. Так вот это не просто передача через границу. По закону никто не запрещает хранить базу на сервере в Европе без упоминания такого хранения в согласии. Копию баз можно хранить где угодно, это не будет считаться трансграничной передачей. Трансграничная передача происходит только тогда, когда на другой стороне (за границей) обработкой этих ПДн будет заниматься уже другое лицо, зарегистрированное в другой стране. Но в России надо хранить актуальную базу.
Очевидно, что для этого ему надо здесь иметь актуальную копию базы.
Очевидно, что одной БД для этого мало. Поэтому странным является как раз Ваше прочтение закона, на мой взгляд — закон говорит только о данных, и польза от наличия именно данных сводится к возможности неограниченного доступа для товарища майора, и всё.
отделить часть себя для работы в закрытой, отделенной от мира российской части интернета
Одному мне кажется, что это абсолютно нереально? Такое можно проделать только с системой, которая изначально проектировалась для поддержки такого стиля работы — и я очень сомневаюсь, что есть хотя бы два действительно крупных и популярных проекта, готовых работать в таком стиле (скорее всего нет ни одного). А переделать систему, которая изначально не проектировалась для этого — будет крайне дорого, плюс, скорее всего, это либо сломает либо ухудшит работу некоторых фич.
То, что Вы описываете, по сути — это кластеризация проекта, с работой в нескольких ДЦ на разных континентах, с сохранением полной работоспособности всех частей при партиционировании кластера на продолжительное время (условно, месяц), с дальнейшим восстановлением связности и синхронизацией всех данных. Это ппц как сложно (обычно в таких случаях используют технический термин "невозможно") сделать для большого проекта с кучей функционала, который изначально под это не проектировался.
Очевидно, что одной БД для этого мало.
Ну при наличии базы интернет-магазин в состоянии хотя бы обработать поступившие заказы. Хотя и большинство других сервисов могут быть развернуты хоть в каком-то усеченном виде. Очевидно, что БЕЗ базы можно только констатировать: «Умерла, так умерла».
Одному мне кажется, что это абсолютно нереально?
Так я это и писывал в качестве причины, почему крупняк упирается руками и ногами, чтобы не делать полную локализацию. Очевидно, что тупо хранить данные в России не составляет особой проблемы. Проблемы то будут дальше. И вот на товарища майора бизнесу, в основной своей массе, глубоко насрать. Реальная юридическая казуистика — вот это проблема.
Например, гражданин России и Кипра проживает в ОАЭ и черт его дернул зарегистрироваться в сервисе. При этом сервис даже не подозревает, о том, что у него есть эти гражданства. Но… Законодательство России требует, чтобы его данные хранились в России. Законодательство ЕС требует, чтобы хранились в ЕС. По тонкостям ЕС точно сказать не могу, возможно (хотя я и с трудом верю), для таких случаев в законе прописаны исключения. В Российском законе точно исключений нет:). И вот как условному ФБ выполнить все законы сразу, встает очень большой вопрос. Есть подозрение, что в данном случае это теоретически нереально. И таких случаев просто вагон.
Так что свобода слова, товарищ майор — это просто прикрытие, чтобы не идти туда, где будут доить, ну или хотя бы максимально замедлить путь.
Публикации
ФЗ-152 надоел, простое решение c хранением персональных данных на nginx