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

Elsewhere, version 8.6 of Telegram integrates the in-app camera option into the gallery, while a new navigation bar gives quick access to photos, files, location sharing, and more. Crude oil prices edged higher after tumbling on Thursday, when U.S. West Texas intermediate slid back below $110 per barrel after topping as much as $130 a barrel in recent sessions. Still, gas prices at the pump rose to fresh highs. In view of this, the regulator has cautioned investors not to rely on such investment tips / advice received through social media platforms. It has also said investors should exercise utmost caution while taking investment decisions while dealing in the securities market. The SC urges the public to refer to the SC’s I nvestor Alert List before investing. The list contains details of unauthorised websites, investment products, companies and individuals. Members of the public who suspect that they have been approached by unauthorised firms or individuals offering schemes that promise unrealistic returns This provided opportunity to their linked entities to offload their shares at higher prices and make significant profits at the cost of unsuspecting retail investors.
from br


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