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: |

He said that since his platform does not have the capacity to check all channels, it may restrict some in Russia and Ukraine "for the duration of the conflict," but then reversed course hours later after many users complained that Telegram was an important source of information. Right now the digital security needs of Russians and Ukrainians are very different, and they lead to very different caveats about how to mitigate the risks associated with using Telegram. For Ukrainians in Ukraine, whose physical safety is at risk because they are in a war zone, digital security is probably not their highest priority. They may value access to news and communication with their loved ones over making sure that all of their communications are encrypted in such a manner that they are indecipherable to Telegram, its employees, or governments with court orders. However, the perpetrators of such frauds are now adopting new methods and technologies to defraud the investors. Continuing its crackdown against entities allegedly involved in a front-running scam using messaging app Telegram, Sebi on Thursday carried out search and seizure operations at the premises of eight entities in multiple locations across the country. The last couple days have exemplified that uncertainty. On Thursday, news emerged that talks in Turkey between the Russia and Ukraine yielded no positive result. But on Friday, Reuters reported that Russian President Vladimir Putin said there had been some “positive shifts” in talks between the two sides.
from us


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