Telegram Group & Telegram Channel
Privacy-мнение от Comply продолжаем говорить об уничтожении ПД. Часть 2.

Что еще за журналирование такое? 🤔

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

Пункт 2 Приказа РКН № 179 гласит: если уничтожаются ПД из информационной системы, то такое уничтожение должно подтверждаться (1) соответствующим актом, а также (2) выгрузкой из журнала регистрации событий в информационной системе (в одной из первых редакций приказа именовавшейся «лог-файлом»). И если с актом еще более-менее понятно, то с логами — непонятно многое. Давайте разбираться.

Что такое лог-файл?

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

Что нужно логировать?

▪️ФИО или иной ID субъекта в системе, по которому его можно идентифицировать или найти
▪️перечень уничтоженных категорий ПД
▪️наименование информационной системы
▪️причину уничтожения
▪️дату уничтожения

В чем сложности?

Даже неспециалисту в информационных системах видно, что, скорее всего, логирование не будет работать так, как этого желает РКН.

Часть из этих полей вовсе сомнительна — например, откуда системе знать причину уничтожения ПД, чтобы записать это в лог? А если мы уничтожили ФИО, какой смысл переписывать их в лог? О каком уничтожении может идти речь, если мы намеренно оставляем уникальные идентификаторы субъекты для выгрузки? Какая из систем будет писать собственное название в лог операций? А по каким правилам хранить такие ПД, если они как бы уничтожены (например, ограничить доступ только для DPO?). Пока вопросов больше, чем ответов.

Единственное, к чему нет вопросов — это дата уничтожения, тут все просто 🙂

Как с этим быть? Ответ есть в Приказе. Если какую-то информацию не получается фиксировать логами, ее нужно переносить в акт. Но смысл логов, конечно, тогда теряется полностью…

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

Что еще?

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

А еще в этих логах нужно ориентироваться и искать для выгрузки информации по конкретному факту уничтожения. В условиях большого объема это и само по себе непросто. А ведь нужно еще и продумать, по каким признакам будет находиться операция — особенно, если в лог не пишется ФИО субъекта…

Выходы из ситуации?

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

Даже если у вас получилось заставить систему автоматически контролировать сроки хранения данных и удалять их по алгоритму — далеко не факт, что у вас получится «прикрутить» к этому корректное логирование уничтожение. В зависимости от класса систем это может быть вообще невозможно, т.к. не во всех предусмотрена такая глубина логирования.

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

А еще есть способ оптимизировать регулярность уничтожения ПД и, соответственно, составления актов и журналов. Но об этом расскажем в следующем посте!

Stay tuned 🙂

#мнение
Please open Telegram to view this post
VIEW IN TELEGRAM



group-telegram.com/comply_ru/323
Create:
Last Update:

Privacy-мнение от Comply продолжаем говорить об уничтожении ПД. Часть 2.

Что еще за журналирование такое? 🤔

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

Пункт 2 Приказа РКН № 179 гласит: если уничтожаются ПД из информационной системы, то такое уничтожение должно подтверждаться (1) соответствующим актом, а также (2) выгрузкой из журнала регистрации событий в информационной системе (в одной из первых редакций приказа именовавшейся «лог-файлом»). И если с актом еще более-менее понятно, то с логами — непонятно многое. Давайте разбираться.

Что такое лог-файл?

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

Что нужно логировать?

▪️ФИО или иной ID субъекта в системе, по которому его можно идентифицировать или найти
▪️перечень уничтоженных категорий ПД
▪️наименование информационной системы
▪️причину уничтожения
▪️дату уничтожения

В чем сложности?

Даже неспециалисту в информационных системах видно, что, скорее всего, логирование не будет работать так, как этого желает РКН.

Часть из этих полей вовсе сомнительна — например, откуда системе знать причину уничтожения ПД, чтобы записать это в лог? А если мы уничтожили ФИО, какой смысл переписывать их в лог? О каком уничтожении может идти речь, если мы намеренно оставляем уникальные идентификаторы субъекты для выгрузки? Какая из систем будет писать собственное название в лог операций? А по каким правилам хранить такие ПД, если они как бы уничтожены (например, ограничить доступ только для DPO?). Пока вопросов больше, чем ответов.

Единственное, к чему нет вопросов — это дата уничтожения, тут все просто 🙂

Как с этим быть? Ответ есть в Приказе. Если какую-то информацию не получается фиксировать логами, ее нужно переносить в акт. Но смысл логов, конечно, тогда теряется полностью…

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

Что еще?

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

А еще в этих логах нужно ориентироваться и искать для выгрузки информации по конкретному факту уничтожения. В условиях большого объема это и само по себе непросто. А ведь нужно еще и продумать, по каким признакам будет находиться операция — особенно, если в лог не пишется ФИО субъекта…

Выходы из ситуации?

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

Даже если у вас получилось заставить систему автоматически контролировать сроки хранения данных и удалять их по алгоритму — далеко не факт, что у вас получится «прикрутить» к этому корректное логирование уничтожение. В зависимости от класса систем это может быть вообще невозможно, т.к. не во всех предусмотрена такая глубина логирования.

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

А еще есть способ оптимизировать регулярность уничтожения ПД и, соответственно, составления актов и журналов. Но об этом расскажем в следующем посте!

Stay tuned 🙂

#мнение

BY Comply. | Комплаенс-бутик


Warning: Undefined variable $i in /var/www/group-telegram/post.php on line 260

Share with your friend now:
group-telegram.com/comply_ru/323

View MORE
Open in Telegram


Telegram | DID YOU KNOW?

Date: |

Telegram was founded in 2013 by two Russian brothers, Nikolai and Pavel Durov. Stocks closed in the red Friday as investors weighed upbeat remarks from Russian President Vladimir Putin about diplomatic discussions with Ukraine against a weaker-than-expected print on U.S. consumer sentiment. After fleeing Russia, the brothers founded Telegram as a way to communicate outside the Kremlin's orbit. They now run it from Dubai, and Pavel Durov says it has more than 500 million monthly active users. Oh no. There’s a certain degree of myth-making around what exactly went on, so take everything that follows lightly. Telegram was originally launched as a side project by the Durov brothers, with Nikolai handling the coding and Pavel as CEO, while both were at VK. In February 2014, the Ukrainian people ousted pro-Russian president Viktor Yanukovych, prompting Russia to invade and annex the Crimean peninsula. By the start of April, Pavel Durov had given his notice, with TechCrunch saying at the time that the CEO had resisted pressure to suppress pages criticizing the Russian government.
from ye


Telegram Comply. | Комплаенс-бутик
FROM American