14.4.09

Об обезличивании персданных

Сегодня многие компании говорят о том, как привести в себя в соответствие с требованиями ФЗ-152, как получать согласие субъекта ПДн, как уведомлять Роскомнадзор, какие средства защиты использовать и т.п. Но мало кто рассматривает вопросы оптимизации своих усилий в области соответствия.

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

Как осуществить обезличивание? Анализ проекта документа NIST SP800-122 и собственные размышления позволил сформировать следующий список действий, приводящих к обезличиванию:
  • Абстрагирование ПДн – сделать их менее точными, например, путем группирования общих характеристик
  • Скрытие ПДн – удалить всю или часть записи ПДн
  • Внесение шума в ПДн – добавить небольшое количество посторонней информации в ПДн
  • Замена ПДн – переставить поля одной записи ПДн с теми же самыми полями другой аналогичной записи
  • Замена данных средним значением – заменить выбранные данные средним значением для группы ПДн
  • Разделение ПДн на части – использование таблиц перекрестных ссылок.
  • Маскирование ПДн - замена одним символов в ПДн другими
Собственно для этого надо сделать немногое - внедрить в ИСПДн специальные обработчики (например, повесить на таблицу БД с ПДн триггер с соответствующей функциональностью), которые и будут преобразовывать ПДн при поступлении в/из БД.

ЗЫ. Мне кажется, что такая доработка ИСПДн обойдется дешевле выполнения перечисленных выше трех требований.

67 коммент.:

Ригель комментирует...

Тут прикольчик есть. Обезличенные персональные данные - это, по воле законописателей, тоже персональные данные. А они должны быть... точными.

Анонимный комментирует...

Алексей, вы не сможете обезличить данные в кадровой системе. Такие данные нельзя будет использовать ;-)
А вот если кадровая система не работает и разработчики требуют предоставить для тестирования базу данных, в которой есть ПД, то перед отправкой базы разработчикам надо ее обезличить.

Unknown комментирует...

# Замена ПДн – переставить поля одной записи ПДн с теми же самыми полями другой аналогичной записи

- но ведь тогда надо в тайне держать способ этой перестановки.

Алексей Лукацкий комментирует...

Анонимному: Почему не смогу? Смогу. Я же это делаю внутри системы и хранит/передает она их обезличенно. А вот вносить и отображать данные надо в обычной форме. Но это как раз просто реализуется.

VSB: Ну да. Используется специальный алгоритм, который известен разработчикам и все.

Ригелю: С чего ты это взял? В ФЗ термин "обезличенные ПДн" вообще не встречается, в отличие от "обезличивание", как процесс. И поэтому произведя эту замечательную вещь, ПДн перестают таковыми быть, т.к. не могут идентифицировать субъекта.

Анонимный комментирует...

Алексей Лукацкий пишет:
Почему не смогу? Смогу. Я же это делаю внутри системы и хранит/передает она их обезличенно. А вот вносить и отображать данные надо в обычной форме.

Т.е. производить необезличенное распространение ПД. И как результат - не удается уйти на обезличивание ПД ;)

Алексей Лукацкий комментирует...

toparenko: Нет. Распространение тут не причем, т.к. это передача, а ее можно делать обезличенно. Вот отображать и собирать придется обычные ПДн. Но и эта проблема решается. ИСПДн сбора и отображения классифицируется отдельно от ИСПДн хранения, обработки, передачи и т.д. Соответственно в ИСПДн, где есть реальные ПДн, будет входить не так уж и много АРМов, для которых выполнить остальные требования законодательства (если не использовать другие методы оптимизации) гораздо проще, чем для всей ИСПДн.

Анонимный комментирует...

Вопрос обезличивания сродни шифрованию и относиться к этому вопросу можно так же...

ПДн это ПДн
обезличенные ПДн - ПДн уже не являются по определению!

По сути обезличенные ПДн уже никак нельзя использовать... разве что для статистики.

Для того чтобы обезличенные ПДн (ОПДн)можно было использовать не для статистики а применительно к субъекту необходим АЛГОРИТМ превращения ОПДн в ПДн. Тогда обезличивание тем круче, чем сложнее повторить такой алгоритм и тут можно говорить о стойкости такого алгоритма.

Какая тогда разница между обезличиванием и шифрованием?!

В рамках одной АС обезличивание бессмысленно потому что либо в АС обрабатывают ПДн - значитв рамках АС они открыты, или не обрабатываются - потому что в рамках АС они обезличены - тоесть бесполезны )))

Анонимный комментирует...

Боюсь придется все же доказывать, что такое обезличивание безопасно. А это повлечет требования к обезличиванию... Действительно, почти шифрование.

Алексей Лукацкий комментирует...

swan'у: Разница в том, что обезличивание не входит в компетенцию ФСБ и не требует лицензирования, сертификации и надхора с контролем.

И использовать обезличенные ПДн можно без проблем. Например, если в ФИО "Лукацкий Алексей Викторович" использовать алгоритм замены каждой второй буквы фамилии на следущую в алфавите, то мы получаем "Лфкбцлик Алексей Викторович". Можно ли работать с этими данными? Безусловно. Являются ли они персональными? Ни в коей мере.

Анонимному: Что значит придется и кому придется? В законе прописано условие, когда данные считаются обезличенными. В примере выше я привел пример, когда из ПДн получены обезличенные данные, из которых нельзя идентифицировать субъекта ПДн. В законе нет требований доказывать кому-то стойкость или надежность или безопасность механизма обезличивания. Это вам не криптография. Не надо усложнять себе жизнь ;-)

Ригель комментирует...

Проще заходить с другой стороны: ПДн не должны быть избыточными относительно цели.
То, что не нужно для (доставки заказа, оформления полиса, перечисления гонорара и т.п.) должно просто не обрабатываться, а не хитрым образом портиться.
Вот и все.

Алексей Лукацкий комментирует...

Особенно учитывая точку зрения Петрова, что оператор не имеет права выбирать себе цель обработки и это должен делать за него федеральный закон ;-)

Анонимный комментирует...

_Лукацкий _Алексей _Викторович :)) Извините, что обращаюсь к обезличенному человеку... алгоритм такой...

Тогда любые данные обезличены.. ведь они хранятся в компьютере в виде набора 1 и 0...

Анонимный комментирует...

Шутки шутками, но специально задавал этот вопрос про обезличивание начальнику отдела сертификации ФСТЭК России Шевцову... Они над этим думают... Вот посмотрим что получится... Тем более есть конкретный проект.

Опять на усмотрение ИЛ повесят ))

Ригель комментирует...

Для Алексея:
логика там у него немножко не такая, имхо, но это отрадно, что ты так серьезно к пятнице готовишься.

Алексей Лукацкий комментирует...

Ригелю: Я стараюсь ко всем мероприятиям серьезно готовиться. Особенно когда за это люди еще и деньги платят, т.е. не хотят, чтобы им рекламу своих продуктов и услуг впаривали ;-)

Анонимный комментирует...

2swan:
+100
Стеганографией Алексей собирается заниматься. Ну-ну. А мы посмотрим, как на это посмотрит Госкомнадзор и ФСТЭК. Обезличивание можно использовать только в том случае, если это безопасно для персональных данных.

2Алексей:
Представьте себе, что данные о Вашем здоровье "обезличивают" путем перестановки букв в имени, а потом выкладывают это в интернет. Лоху понятно, что это "мертвому припарка". Но следуя Вашей логике, Вам от этого легче.

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

Алексей Лукацкий комментирует...

Анонимному:1. Если вы читали документы ФСТЭК, то должны знать, что ФСТЭК сама рекомендует использовать средства стеганографии.

Как посмотрит Роскомнадзор и ФСТЭК меня, как оператора, волнует мало. Закон дает мне такую возможность, а регуляторы ни в одном документе не описывают как это делать. Поэтому я это буду делать так, как считаю нужным. Это мое право, как оператора ПДн. И ни в одном документе не даны требования к обезличиванию, т.ч. о безопасности этого метода ни ФСТЭК, ни РКН судить не могут.

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

3. Что касается "дешево и безопасно" я с вами согласен на все 100%. Вот регуляторы почему-то об этом не подумали. Да еще и нарушили европейские требования по безопасности ПДн.

4. Ну а про профессионализм говорить надо не мне, а тем, кто разработал такие законы и подзаконные акты. Моя задача - показать, что не надо тупо бежать по первому свистку выполнять тупые и ОЧЕНЬ дорогие требования. Можно обойтись малой кровью и не менее эффективно решить поставленную задачу. В этом и заключается профессионализм.

ЗЫ. Не говоря уже о том, что я выступаю в т.ч. и как оператор ПДн (не говоря уже про роли субъекта, интегратора и разработчика средств защиты).

Анонимный комментирует...

Алексей...
"Как посмотрит Роскомнадзор и ФСТЭК меня, как оператора, волнует мало. Закон дает мне такую возможность, а регуляторы ни в одном документе не описывают как это делать. Поэтому я это буду делать так, как считаю нужным. Это мое право, как оператора ПДн. И ни в одном документе не даны требования к обезличиванию, т.ч. о безопасности этого метода ни ФСТЭК, ни РКН судить не могут."

У нас принято считать раз требование на бумаге не изложено - значит это на усмотрение ФСТЭК )))
Возьмем пример...

Есть некая АС... в которой обрабатывается К1...
Обязательна к аттестации а СрЗИ к сертификации.

Что происходит далее...
Владелец АС или Разработчик АС разрабатывает средства защиты... ему нужно время и деньги в том числе на сертификацию и аттестацию.
Он хочет сэкономить...
Для этого ему нужно минимизировать средства защиты. Хороший ход - обезличивание ПДн. При этом сразу проблема - вся АС должна перейти с К1 на К4? или это невозможно в рамках целой АС ??? Возможно поделить АС на две ? Ну предположим поделили АС на сегменты. Решили что нужно мало СрЗИ разрабатывать и стратифицировать.

После этого Разработчик посылает Заявку в ФСТЭК на проведение сертификации разработанных СрЗИ... так как эти средства несколько специфичны, то они не в полной мере соответствуют требованиям РД СВТ. И Разработчик принимает решение сертифицировать на соответствие ТУ которое сам и разрабатывает.

Данное ТУ необходимо согласовать с ФСТЭК и тут выясняется что все прекрасно, но в ТУ слова про то, что какой то сегмент не подвергается защите, потому что защищаемая информация (ПДн) обезличена.
И вот тут вспывает мой первый пост ))) "кто принимает решение достаточно СрЗИ или нет" Согласует такое ТУ ФСТЭК или нет!!! Нужно ли проверять действительно обезличено или нет. Например ФСТЭК ставит задачу такой проверке для испытательной лаборатории.
ИЛ разрабатывает методику проверки. Но методика тоже согласовывается с ФСТЭК.

Такая же проблема у аттестаторов !!!

По сути ФСТЭК решит что "плохо" обезличено и СрЗИ недостаточно ссылаясь на материалы ИЛ или органа по аттестации.

Та же каша с Аттестаторами в случае если Оператор использует уже сертифицированные СрЗИ. Нет критериев оценки. Критерии оценки заставят разрабатывать аттестаторов в каждом конкретном случае...

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

Анонимный комментирует...

Дополняю...
Вообще закон интересный...))

Обеспечения конфиденциальности персональных данных не требуется:
1) в случае обезличивания персональных данных;

не ОБЕЗЛИЧЕННЫХ а обезличивания (процесса)

Что такое (процесс обезличивание) это "3) обработка персональных данных - действия (операции) с персональными данными, включая сбор, систематизацию, накопление, хранение, уточнение (обновление, изменение), использование, распространение (в том числе передачу), обезличивание, блокирование, уничтожение персональных данных;"

Тоесть в случае процесса обезличивания Обеспечение конфиденциальности персональных данных не требуется )))

ну и наконец:
обезличивание персональных данных - действия, в результате которых НЕВОЗМОЖНО определить принадлежность персональных данных конкретному субъекту персональных данных;
Тоесть такие данные уже не являются ПДн. А если в АС есть механизм обратный то это уже не обезличивание так как ВОЗМОЖНО определить принадлежность персональных данных конкретному субъекту персональных данных...

НЕВОЗМОЖНО значит НЕОБРАТИМО...

таким образом Обезличенные ПДн могут использоваться только для статистики и извиняюсь "обналичить" их уже нельзя !!!

Если "НЕВОЗМОЖНО" ослабить на "ОЧЕНЬ СЛОЖНО" получается как раз шифрование или дайте критерии оценки этого "ОЧЕНЬ СЛОЖНО"...))

Ух дебри...

Алексей Лукацкий комментирует...

swan'у: Ну полезли в дебри ;-)

1. Во-первых, ты исходишь из того, что решать будет ФСТЭК? Почему? Я до требований ФСТЭК вообще не дойду. Обезличил и все - требования по обеспечению безопасности мне уже не грозят, т.к. у меня нет ПДн.

2. Усмотрение ФСТЭК - это вещь конечно правильная, ведь они большие эксперты в деле безопасности современных ИС. Только вот обезличивание - это процесс обработки ПДн и в сферу компетенции уважаемой ФСТЭК не входит.

3. Если я выбрал К4, то почему я должен что-то там защищать? Это мое право, как оператора. И ФСТЭК так и говорит в своих документах, легитимность которых под сомнением.

4. Когда я что-то сертифицирую, я вообще не должен писать в заявке про обезличивание и т.д. Я просто подаю продукт на сертификацию. И ФСТЭК его сертифицирует. И я выполняю требование использование сертифицированных решений.

5. Что касается аттестации, то это вообще отдельная тема. Ни в одном законе или подзаконном акте такого процесса, как аттестация просто нет ;-)

6. А никто и не успокаивает операторов. Я просто показываю, что смотреть на проблему с точки зрения регулятора или интегратора или поставщика средств защиты. конечно, интересно, но есть и другие точки зрения. Того же оператора. И пусть он уже сам принимает решение, видя все альтернативы.

7. Если у меня данные обезличены, то я вообще средства их обработки не отношу к ИСПДн и не применяю к ним требования сертификации и аттестации.

8. Ну и последнее. Ты трактуешь слово "НЕВОЗМОЖНО" буквально. Такая трактовка имеет право на жизнь. А я вот предпочитаю другую трактовку - из европейской директивы по ПДн, которая имеет юридическую силу для стран, ратифицировавших Конвенцию (т.е. для нас). Там написано "Для определения того, является ли лицо идентифицируемым, следует принимать в расчет все средства, в равной мере могущие быть реально использованы либо оператором, либо любым иным лицом для идентификации указанного лица". Ключевое слово "реально" ;-) И это дает повод для маневра грамотному юристу ;-)

Анонимный комментирует...

1. Во-первых, ты исходишь из того, что решать будет ФСТЭК? Почему? Я до требований ФСТЭК вообще не дойду. Обезличил и все - требования по обеспечению безопасности мне уже не грозят, т.к. у меня нет ПДн.
(А пока не обезличил ? чтоб обезличить их сначала надо поиметь ?)

2. Усмотрение ФСТЭК - это вещь конечно правильная, ведь они большие эксперты в деле безопасности современных ИС. Только вот обезличивание - это процесс обработки ПДн и в сферу компетенции уважаемой ФСТЭК не входит.
(Имеется в виду сертификация и аттестация для высоких классов... и гибридные системы)

3. Если я выбрал К4, то почему я должен что-то там защищать? Это мое право, как оператора. И ФСТЭК так и говорит в своих документах, легитимность которых под сомнением.
(сейчас все под сомнением...)

4. Когда я что-то сертифицирую, я вообще не должен писать в заявке про обезличивание и т.д. Я просто подаю продукт на сертификацию. И ФСТЭК его сертифицирует. И я выполняю требование использование сертифицированных решений.
(Все всплывет в процессе сертификации...)

5. Что касается аттестации, то это вообще отдельная тема. Ни в одном законе или подзаконном акте такого процесса, как аттестация просто нет ;-)
(4 книжие хотябы...)

6. А никто и не успокаивает операторов. Я просто показываю, что смотреть на проблему с точки зрения регулятора или интегратора или поставщика средств защиты. конечно, интересно, но есть и другие точки зрения. Того же оператора. И пусть он уже сам принимает решение, видя все альтернативы.
(Оператор воспринимается или пиарится как БУРЖУЙ который о гражданах информацию сдает криминалу... )

7. Если у меня данные обезличены, то я вообще средства их обработки не отношу к ИСПДн и не применяю к ним требования сертификации и аттестации.
(согласен если обезличено то это и не ПДн вовсе. предмета разговора нет тогда )))

8. Ну и последнее. Ты трактуешь слово "НЕВОЗМОЖНО" буквально. Такая трактовка имеет право на жизнь. А я вот предпочитаю другую трактовку - из европейской директивы по ПДн, которая имеет юридическую силу для стран, ратифицировавших Конвенцию (т.е. для нас). Там написано "Для определения того, является ли лицо идентифицируемым, следует принимать в расчет все средства, в равной мере могущие быть реально использованы либо оператором, либо любым иным лицом для идентификации указанного лица". Ключевое слово "реально" ;-) И это дает повод для маневра грамотному юристу ;-)
(По видимому РЕАЛЬНОСТЬ можно только доказать демонстрацией... на чьей стороне только будет маневрировать грамотный юрист...)

По моему неплохая получилась дискуссия...

Алексей Лукацкий комментирует...

swan'у:

0. Используй цитирование, а то сложно вычленять твои слова ;-)

1. Ну поимел и что? И сразу обезличил. Что ж я буду уведомлять ФСТЭК о том, что у меня появились ПДн? Не обязан ;-)

2. Ну так все равно обезличивание не касается ФСТЭК.

3. Это точно ;-)

4. Не всплывет. Я же не говорю, что я буду защищать. Это же не АС. Это а-ля СВТ - средство, не имеющее отношение к конкретной информации. Просто подал средство защиты и просто получил сертификат. А уж какую информацию из разряда конфиденциальной я буду защищать, это мое право. Главное в ГТ не лезть.

5. Нелигитимное ;-) В ФЗ и ПП есть понятие "оценка соответствия". Аттестация в него не входит. По закону только сертификация служит подтверждением соответствия. А аттестация - это вообще из области ГТ.

6. Вот пойдут запросы в РКН по поводу интеграторов, производителей средств защиты, регуляторов ;-) в нарушении прав в области ПДн ;-) Вот тогда они и изменят свое отношение.

7. И к этому надо стремиться ;-) И думать в этом направлении, а не о том, как выполнить 4 документа, на смену которым скоро придут другие 4 документа ;-) А потом еще и РКН чего-нибудь слабает ;-)

8. Вот именно! А кто же даст регулятору демонстрацию проводить на реальной системе? ;-) Не говоря уже о том, что им вообще запрещено иметь доступ к ПДн во время контроля и надзора ;-)

Отличная дискуссия. Надо и других подключать ;-)

Анонимный комментирует...

Самый главный пункт - 3. кстати "3" если сбоку посмотреть как раз ассоциируется с положением дел в области защиты ПДн :)

пункт 4 - доложу отдельно по случившемуся факту.

пункт 5 - видел в интернете ))) "Оценка соответствия ИСПДн по требованиям безопасности ПДн проводится:
для ИСПДн 1 и 2 классов - обязательная сертификация (аттестация) по требованиям безопасности информации;" (показываю язык чтоб веселее было)

По остальным пунктам согласен на все 99% )))
Третий раз намекаю "форум нужон" ;)

Алексей Лукацкий комментирует...

5. Не ссылайся на документы, легитимность которых под сомнением и которые не должны противоречить федеральному законодательству.

ЗЫ. Форум нужен ;-) Времени нет сайт доделать.

Ригель комментирует...

> Отличная дискуссия.
> Надо и других подключать

Была.
Обезличены ли ПД (осталось ли лицо идентифицируемым) - компетенция РКНа, а не ФСТЭКа.

Алексей Лукацкий комментирует...

Это из чего следует? И как проверить качество обезличивания?

Ригель комментирует...

Нет у ОПДн понятия качества (тут как со свежестью осетрины): если можно определить, к кому конкретно относятся, то это не ОПДн. Потому и глубины защитной меры нет, а чисто упирается в трактование ФЗ, каковое за РКН. Ты с самого начала этот ключ не взял, судя по "менее точными" и "количество шума".

Алексей Лукацкий комментирует...

Хорошо. Как они определяют или будут определять? Вот есть после обезличивания следующая запись "Лфкбцлик Алексей Викторович". Ты можешь идентифицировать субъекта?

Ригель комментирует...

Странный пример, т.к. даже нормальные ФИО не идентифицируют физика, если они в одиночестве.

Ладно, поиграем.
Нет, я не могу. Он из Харькова?

Unknown комментирует...

А почему ты считаешь, что недостаточно только первую букву менять? Скажем А на Б, Б на В, Я на А. Будет Мукацкий. Или хранить, переставив буквы наоборот. Скажешь, что это сверхсложное секретное преобразование - и всё? Всё обезличено? Ты же на своё усмотрение определяешь достаточность принятых мер?

Анонимный комментирует...

У меня есть предположение... версия... что тема обезличивания изначально связана не с тем, как спрятать или хранить ПДн или как их в скрытом режиме обрабатывать...
А с тем чтобы можно было обрабатывать массу статистических данных и т.п. и при этом никак не задевать субъектов ПДн.

А мы сползаем на тему - что такое сделать с ПДн чтоб и обезличить и обрабатывать в рамках 1 ИСПДН...

Алексей Лукацкий комментирует...

Ригелю: Ну я для примера же привел. Добавь туда еще какие-нибудь данные по доходам, жилплощади, телефону, адрес и т.д., где я тоже произвел определенные модификации. Обезличил? Мне кажется да. Следовательно уже не ПДн.

VSB: Ну достаточно мер по защите определяют ФСТЭК и ФСБ в рамках своей компетенции. А вот обезличивание не относится к мерам по защите - это элемент обработки. И поменять можно как угодно. Сейчас спор не о том, как, а о том, что будет потом.

swan'у: Возможно такое предположение верно в отношении России ;-) Но в США обезличивание изначально предназначали для оптимизации затрат на защиту. В NIST SP800-122 прямо сказано, что нефига заниматься ерундой и вместо защиты по максимуму, лучше обезличить ПДн.

Анонимный комментирует...

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

Путанно? Ну, если охота автоматизированно обрабатывать, пересчитайте клиентов и храните их ФИО отдельно на выделенном сервере с соблюдением требований ФСТЭК/ФСБ. А с остальной информацией, делайте, что хотите, где хотите.

При этом нужно быть готовым доказывать, что оставшаяся ОПДн действительно является таковой. И не надо косить под то, что никто не должен ничего доказывать. Нужно быть готовым (ВСЕГДА). Ну, практика, правила игры ... таковы. Можно плевать, но если Вы кому-то не понравитесь, то Вас достанут.

Анонимный комментирует...

2 Анонимный...
Попробуйте абстрагироваться от серверов и разделения...

Возьмем 1 АРМ (ноутбук)...
По сути такое разделение уже происходит... логическая схема такая...

Оператор<->обработка ПДн<->алгоритм обезличивания<->ОПДн.

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

Вся это схема прекрасно работает и так.
ОПДн хранятся на ЖМД в виде намагниченных областей пластин диска (попробуй прочитать без алгоритма)

алгоритм обезличивания - все действия ОС, драйверов и контроллеров которые преобразуют данные из понятной для оператора формы в непонятную на ЖМД...

Мне потому и кажется что самое слабое место в цепочке - "алгоритм обезличивания"...

у меня в связи с этим 2 вопроса:
1. Должен ли быть алгоритм обезличивания необратимым ?
2. возможно ли в рамках 1 ИСПДН и обезличивать и переводить обратно ?

Unknown комментирует...

Просто в моём понимании ответ на вопрос "как обезличить" (взяв твоё преобразование) неминуемо приведёт нас к криптографии, где нет "безопасности через неясность".
Ну вот приходу я к тебе со своими ПД, как, спрашиваю, защитишь? А ты мне ответишь: мол туда-сюда кручу верчу по собственному уникальному алгоритму так, что никто тебя там не определит даже получив всю БД? Не уверен, что доверил бы тебе хоть что-то...

Анонимный комментирует...

2VSN:
И прежде всего, он свои данные доверил бы себе после такого "замусоливания"?

2SWAN:
А вот, если выполнить "разделение", то можно действительно чувствительную часть ПДн защитить по идиотским требованиям, но на куда меньшем "участке", причем доказательно, а не "помахххав руками".

Вдогонку к примерам с перестановками/заменами букв, но куда более реалистично: является ли номер автомобиля ПДн? Ведь для идентификации личности необходима база ГАИ, а она, я "верю", защищена от зловредня. Мне кажется такая информация хотя бы похожа на обезличенную. Тут хоть есть ссылка на факт, который оспаривать проверяющим сложно. А игры типа стеганографии без ключа в этом смысле выглядят смешно.

Алексей Лукацкий комментирует...

VSB: Ну не является обезличивание средством защиты. И когда ты ко мне придешь и спросишь, как защищаю - я тебе отвечу про всяческие средства и механизмы защиты и т.д.

Анонимному: Смешно - не смешно, но это тоже вариант. И если захотят достать, то достанут по любому. Даже при наличии аттестата ;-)

Анонимный комментирует...

Я согласен со swan-ом. Вы тут какую-то игру затеяли со словами и произвели подмену понятий. Настоящее обезличивание - необратимое. Иначе это не обезличивание, а кодирование информации. И шифрование родилось как такое кодирование, которое устойчиво к тому, что известен алгоритм кодирования, но не известен только ключ.

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

Анонимный комментирует...

Кстати, насчет форумов для обсуждения.

Есть такой - it2b-forum.ru. А там есть раздел, где эта тема вполне уместна ;-)

Ригель комментирует...

> произвели подмену понятий
> обезличивание/кодирование

В точку! Это у кодирования есть качество, у обезличивания его нет.

Алексей Лукацкий комментирует...

Анонимному: Термин в студию, пожалуйста. Что такое кодирование? И чем оно отличается от обезличивания? А то все такие знатоки собрались, что просто диву даешься. И все так и норовят заставить бедного оператора по максимуму влезть в выполнение ФЗ-152 и всех подзаконных актов.

Если уж мы коснулись Конвенции, то там как раз есть такое понятие как "непропорциональные усилия". И применение криптоаналитиков для доказательство обратимости обезличивания из этой области. Реально никто не будет использовать этот метод для обратной идентификации субъекта. Если следовать вашей логике, то безопасность ПДн вы вообще не в состоянии обеспечить, т.к. 100%-ой защиты быть не может. Не говоря уже о том, что вы должны соблюдать принцип адекватности затрат на защиту ущербу. И в Конвенции это тоже четко прописано. В отличие от документов ФСТЭК, которые даже эшелонированную оборону запретили.

Анонимный комментирует...

Есичо, насчет слов всяких умных :o))

Lingvo
"кодировать I Преобразовывать сообщение в код I; передавать информацию при помощи специального кода."
"обезличиваться 1. Делаться безличным; терять своеобразие, самостоятельность. 2. Становиться обезличенным, не закрепленным за кем-либо лично."

Яндекс-словари
http://slovari.yandex.ru/dict/bse/article/00035/52600.htm?text=%D0%BA%D0%BE%D0%B4%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20%D0%B8%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%86%D0%B8%D1%8E

http://slovari.yandex.ru/dict/ushakov/article/ushakov/15/us262711.htm?text=%D0%BE%D0%B1%D0%B5%D0%B7%D0%BB%D0%B8%D1%87%D0%B8%D0%B2%D0%B0%D1%82%D1%8C

Так что Алексей в чем-то прав... :o))

Слово одно, а смысл в него каждый вкладывает разный (или какой ему удобнее o)) )

Алексей Лукацкий комментирует...

Вот именно

Анонимный комментирует...

Ребята, вы о чем? Стеганография, кодирование,... Может вернемся в начало дискуссии? В первую очередь следует определиться с критериями. Я опять предлагаю примерить все на себе (условно хотя бы).

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

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

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

Алексей Лукацкий комментирует...

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

И мы никого тут не консультируем, в отличие от некоторых компаний, которые за свои "консультации" берут миллионы рублей, а выливается все не в то, что надо субъекту или оператору, а в то, что надо регулятору. Мы в дискуссии ищем решение.

А логика простая. Регулируйте то, в чем понимаете. А в остальное лезть не надо. Если лезете, то сначала проекты документов на обсуждение общественности выложите, как это делают, например, в США или Великобритании. Не сделали по уму, получайте отмазки со стороны тех, кого пытаются нагнуть.

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

ЗЫ. И публичное обсуждение в среде специалистов - это гораздо профессиональнее, чем "впаривать" клиентам всякую тиражируемую чушь под видом индивидуального подхода. И уж гораздо профессиональнее поведения некоторых игроков рынка, которые на тех, кто мешает им "впаривать", писать подметные письма.

Анонимный комментирует...

Как я Вас раззадорил. Только следует заметить, что я на личности не переходил, а потому использовал "вы", а не "Вы", как если бы обращался к конкретному собеседнику. Потому не берите на свой счет.

А ЗЫ я не беру на свой счет, потому что на этом рынке ни тем, ни другим не занимаюсь.

Так я опять все о том же. Если вернуться, например, к Вашему корневому предложению о триггере в БД? Может есть смысл, исходя из интересов всех сторон, построить схему обезличивания? Я уже упоминал, что тогда нам придется сформулировать критерии выбора нужных преобразований, допустимые обеими сторонами. Т.е. давайте оставим регуляторов в стороне, и будем честными перед операторами и субъектами. И тогда нам придется доказывать безопасность, действенность обезличивания перед самими нами, а не искать отмазку. (Ну не хочу я этими отмазками заниматься!)

И вот тут: триггер должен исполняться на платформе БД? Значит уже по сети пошли ПДн? Значит сеть следует защищать и сервер БД тоже? Данные-то в базе (допустим) обезличены, но ПДн присутствуют на сервере.

Если же "триггер" исполняется на платформе, где происходит только обработка ПДн, то эту-то платформу нам придется таки защищать. Или при обработке тоже ПДн МОГУТ быть обезличенными? Но тогда это уже не ПДн. И не о чем разговаривать: не берите больше чем надо.

В любом случае защищать оконечную платформу проще, чем всю сеть. (Хотя, Вы правы, у нас не проще!)

Вопрос остается: критерии допустимости преобразований обезличивания, исходя из интересов обеих сторон? А обсуждение, по-моему, примерно с этого и началось. Ну не банальное же кодирование, действительно. Тогда что конкретно? И чем это отличается от кодирования? Критерии! Критерии!

А Вы говорите, не надо никому доказывать. Мы-то с Вами перед собой как специалисты должны доказывать, что это на самом деле работает.

Анонимный комментирует...

Критерий Алексей процитировал вначале
из европейских документов - "Для определения того, является ли лицо идентифицируемым, следует принимать в расчет все средства, в равной мере могущие быть реально использованы либо оператором, либо любым иным лицом для идентификации указанного лица". Поэтому я по жизни меняю в столбце записи таблицы БД "Иванов Иван Иваночи" на "Клиент N370" или его реальный адрес на "Адрес клиента N370".
в этом случае по информации из БД в общем случае не восстановишь.

С другой стороны где-то читал, что в штатах провели исследование и обнаружили, что по дате рождения и городу рождения можно с 30% точностью установить личность человека. Так что по жизни могут существовать обходные способы ;-(

Анонимный комментирует...

Алексею и Анониму...

"А теперь и за оператора, и за субъекта все решили, не спросив ни того, ни другого. А против привилегированного пользователя все эти предложенные методы все равно бессмысленны - он и так унесет то, что надо, требования этому не помешают."
+100

"ЗЫ. И публичное обсуждение в среде специалистов - это гораздо профессиональнее, чем "впаривать" клиентам всякую тиражируемую чушь под видом индивидуального подхода. И уж гораздо профессиональнее поведения некоторых игроков рынка, которые на тех, кто мешает им "впаривать", писать подметные письма."
+1000

По сути у нас классический треугольник интересов
Регуляторы, Операторы, Субъекты...
у каждого свои интересы...
Каковы они?
У Субъекта - чтоб без его ведома не использовались ПДн.
У Оператора - обрабатывать ПДн, чтоб его не трогали, чтоб не тратить ресурсов.
У Регулятора - какой интерес???

Разрулить этот самый треугольник ??? По сути Регулятором выступает Государство в лице...регуляторов поменьше... Подняли престиж ратифицировав европейскую конвенцию?

На сей час ситуация простая и Анониму нужно понимать, что Регуляторы не способны выполнять свои функции по различным ОБЪЕКТИВНЫМ причинам. И МЫ тут не просто болталогией занимаемся... мы готовимся участовать в реальных проектах и сглаживать недостатки ситемы как бы громко это не звучало...

Прошу так же учесть некоторую ПРОВОКАЦИОННОСТЬ мнений которая как правило высказывается авторами СПЕЦИАЛЬНО как метод...

Алексей Лукацкий комментирует...

Анонимному: Ну отмазку нас заставляют придумывать регуляторы со своими требованиями. Вот что им мешало просто написать, для защиты ПДн на Endpoint используйте СЗИ от НСД или HIPS вкупе с антивирусами; для защиты во время передачи - VPN. Ну и т.д. И все встало бы на свои места. Мы это и так всегда использовали. И для защиты банковской тайны, и коммерческой, и для выполнения требований PCI DSS и СТО БР ИББС и т.д. Т.е. регуляторы были бы мудры и учли, что в одной и тоже ИС обрабатываются РАЗНЫЕ виды тайн, а не только ПДн.

Так нет же. Они меня заставляют выполнять просто тупые требования типа сохранения неудачных паролей. Они меня заставляют использовать сертифицированные ловушки (honeypot), которых в России не существует. Они меня заставляют в поликлинике использовать средства защиты от ПЭМИН, не зная как это скажется на работе рентгена или приборов холитеровского мониторирования. Они меня заставляют использовать только сертифицированные средства защиты Sybase, которых в природе не существует. Они меня заставляют аттестовать ИСПДн, не взирая на то, что после установки патча аттестат теряет свою "силу". Они меня заставляют получать лицензию на ТЗКИ, забывая, что лицензия - это специальное разрешение на вид деятельности, который мне уже вменен в обязанность федеральным законом. Ну и как я должен реагировать на эти требования нашего главного регулятора?

Алексей Лукацкий комментирует...

Анонимному: (еще одному?) Вероятность идентификации в 30% - это для ФЗ ноль. Потому что если следовать вообще букве закона и мнению комментаторов, то речь идеть об однозначной идентификации. А какая же при 30% однозначность?

Ригель комментирует...

> Ребята, вы о чем? Я опять
> предлагаю примерить все на себе
> может быть тогда вы будете
> придумывать методы обезличивания
> которые начнут устраивать еще и
> владельцев ПДн, а не только
> операторов. О владельцах-то ПДн
> почему постоянно забываете?

Попробуйте ветку почитать: от имени "владельцев" выступает РКН, этот защитник прав субъектов здесь раз пять фигурирует именно в роли оценщика обезличенности.

Unknown комментирует...

Ещё в голову мысль пришла про обезличенность.

Вот допустим есть субъект № 57. В БД записано где он живёт, какая машина, какие земельные участки, сколько квартир, счетов в банках. Далее преступному элементу неинтересно ФИО, при достаточной на его взгляд благосостоятельности субъекта - преступник идёт в гости просто по месту регистрации.

Анонимный комментирует...

2 VSB
... Именно так !!!

Анонимный комментирует...

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

Про 30% идентификацию просьба не упоминать. Если противник МОЖЕТ доперебрать, то это уже опасно. Другой вопрос, что значит МОЖЕТ?

Давайте воспользуемся предложением "Для определения того, является ли лицо идентифицируемым, следует принимать в расчет все средства, в равной мере могущие быть реально использованы либо оператором, либо любым иным лицом для идентификации указанного лица". И что? Как будем определять, какое "замусоливание" лишает "иное лицо" возможности идентификации? Боюсь опять попадем в "модель противника". А она "регуляторами" не пахнет? Если это не смущает, то можно выстроить свою модель, попробовать вычислительно оценивать возможность идентификации, например, теоретико-сложностной подход, с учетом вероятности успеха...

Анонимный комментирует...

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

Хотя, что-то мне подсказывает, что в сием топике мне не рады. Кажется я понял вашу цель: снижение издержек операторов любой ценой. Тогда, Алексей, есть идея: на РусКрипто Сухинин из Эшелона раскладывал на косточки нормативные акты по ПДн (да и Вы это все умеете) и пришел к юридическому пути решения проблемы. Я к тому, что проще привлечь юристов и оспаривать все в судах. Регуляторы подставились по-полной, что смущаться-то.

Жаль только, что ПДн наши все так же будут оставаться "голенькими". Но это уже тема для другого разговора.

Что-то топик раздулся, пора сворачиваться.

"Покедова, маманька"

Анонимный комментирует...

Может все-таки куда-нибудь перенесем ветку - вон уже 55 комментариев нафлудили. Чего на том же Банкире тему Алексею не организовать? ;-)

Алексей Лукацкий комментирует...

VSB: А место жительства, участки, квартиры - это тоже ПДн ;-)

Анонимному: Задача любой коммерческой организации - увеличение прибыли и снижение издержек. Что же тут удивительного, что я предлагаю варианты этого снижения. Если бы доблестные интеграторы, которые предлагают свои услуги, попробовали бы все, что они предлагают примерить на себя, то они бы заговорили по другому.

Ну а что касается юридического пути решения проблемы, то именно за это я и ратую. Сегодня провел семинар в ИБД АРБ и основной мой тезис - привлекайте юристов для оптимизации затрат. А если готовы дойти до суда, то идите и выиграете при текущем положении дел.

А Информзащита (присутствовавшая в качестве слушателя) в лице М.Ю.Емельянникова на этом семинаре вообще заявила, что можно в договоре с субъектом вообще прописать, что вы, как оператор, ничего делать не будете и принимаете на себя все риски и готовы возмещать понесенный субъектом ущерб по решению суда. Вот вам и весь подход.

Анонимный комментирует...

А как же в таком случае быть с санкциями за невыполнение ФЗ?

Олег Кузьмин комментирует...

Не надо ничего обезличивать, на то что вы будете считать обезличенным у подготовленного проверяющего будет другая точка зрения.
Не надо искать спасения в юридических аспектах, инициируя судебные разбирательства. Да, это возможно потребуется, но должно быть заключительным аккордом отношений оператора ПД с контрольным органом(ами), но никак не основным. Что делать тогда?
Поскольку в существующих документах в явном виде не прописано, что конкретно требуется сделать в плане технической защиты ПД (а также, как и с применением чего конкретно). Можно пойти другим путем. Внимательно читаем все документы и делаем системы защиты в своих ИСПДн так, как их можно понимать, но с точки зрения разумной достаточности, а не избыточности. Сделали, пришел поверяющий, посмотрел. И далее, самое интересное, пусть он САМ доказывает, что СЗПД в вашей ИСПДн не соответствует чему либо. А "чего либо", как раз и не определено, а следовательно и не доказуемо. Предупредите его о возможном дальнейшем разбирательстве в суде. Он напишет акт, подавайте в суд на конкретного инспектора Иванова (Петрова или Сидорова) который пришел к вам. Это быстро отучит людей писать непродуманные вещи в актах. Понятно, что даже в вашем понимании СЗПД в минимальном наполнении, потребуется невероятно большое количестов средств для выполнения требований ФЗ в банках или страховых компаниях. Но поскольку почти все они будут специальные. Для этого надо предварительно грамотно сделать классификацию ИСПДН, сделать все возможное для снижения с К1 на К2, а с К2 на К3. И, кстати, есть интеграторы (их правда сейчас очень мало), которые действительно думают о своих клиентах, их затратах и пр.важных для оператора вещах. Но самое главное, они думают и о том, что после 1 января 10 года им придется отстаивать построенные СЗПД вместе со своими заказчиками. А это обстоятельство уже важно само по себе.

Алексей Лукацкий комментирует...

Олегу: Т.е. вам документы ФСТЭК с конкретными требованиями не указ?.. ;-)

Олег Кузьмин комментирует...

Алексей, где вы там увидели конкретные требования, имеющие однозначное толкование в вопросах ЗИ? :) Все достаточно размыто и не определено для того, что бы грамотно отстаивать свою точку зрения на СЗПДн. Даже конкретную статью в действующем РД, определяющем порядок защиты гос. тайны два разных эксперта могут трактовать по разному, если в ней явно не прописано, что конкретно нужно взять и как конкретно сделать. Оба кстати, рассуждая как эксперты, в итоге будут правы. Можно сделать двумя или более разными способами и все они будут формально отвечать требованиям.
Повторюсь, обязанность доказывать, что что-то в ИСПДн не соответствует документам - относится к проверяющему. Проверяемый, в случае, если его не убедили доводы поверяющего может оспорить их в суде подав иск на конкретного человека, а не на ведомство его направившее. Хотя тут тоже могут быть варианты.

Анонимный комментирует...

Пример обезличивания:ссылко. Не злого умысла для,а токмо шутки ради ;))

Алексей Лукацкий комментирует...

Весело

Анатолий комментирует...

А как вам такие мысли:
Регуляторы прописали очень жесткие меры по технической защите информации, грозящие огромными затратами для операторов, прописали всякие ПЭМИНы и другую параноидальную чушь, но вот никак не учли, что наш преступный элемент помимо всего еще и неплохой собственник, и вряд ли будет кидать на ветер деньги для приобретения спецоборудования (замечу очень даже не дешевого) для снятия персональных данных. Со стороны регуляторов думать так - это показать свою полную профессиональную непригодность, так как наши преступные элементы далеко не дураки. Они знаю, что проще, дешевле и надежнее всего лишь навсего припугнуть кадровика (или бухгалтера или медика...) или дать ему от щедрот на лапу (при наших Российских зарплатах соблазн довольно велик) и получить любую информацию. Какие там ПЭМИНы, зачем ему (преступнику) вообще знать какие там стоят CPB& Но наши регуляторы от чего-то этого не понимают и пишут свою белиберду в нарушение всех установленных стандартов (ГОСТ Р ИСО/МЭК 17799 - меры по защите информации должны быть адекватными возможному ущербу, то есть ниже возможного ущерба, и, кроме того, не должны нарушать удобство в работе - написал общий смысл). Во всем мире подход к защите информации именно такой (я, конечно, не имею ввиду защиту госсекретов, там для защиты некоторой информации никакие меры не будут лишними), но наши регуляторы совсем не думают об этой стороне вопроса, витают где-то в облаках, наверное.
Надо учитывать человеческий фактрр, а он-то и есть самая огромная дырка в защите информации. Вот если бы регуляторы прописали бы обязанность оператору выплачивать такие же оклады как и у высшего руководства тому лицу, которому оператор поручил осуществлять обработку ПД, тогда можно было бы говорить и о ПЭМИНах и т.д., потому что подкупить или припугнуть совсем неголодного работника кадров (бухгалтерии и т.д.) стало бы значительно тяжелее. Но опять таки, это по внешним нарушителям, а если такой работник пожелает такую базу для себя (может быть заботясь о своем будущем в надежде, что если уволят, то он сможет заработать на продаже такой базы), и как тут защищаться будем? Мы хоть какие технические меры будем применять, но они будут абсолютно не действенными, чрезмерно затратными и вносить кучу неудобств, а то и проблем похлеще. Так что я целиком и полностью за то, чтобы обезличивать ПД, причем так, чтобы и сами работники, которые занимаются их обработкой тоже получали только обезличенные, а к необезличенным данным могли получать доступ два - от силы три человека (если организация большая) или вообще один. Вот тогда мы сможем обеспечить необходимый уровень защиты ПД и при этом особых затрат не понесем.
А как быть с тем, что наличие определенного пакета документов тоже нигде (разве что в СТР-К) не прописано? А ведь СТР-К это обязателен для выполнения только государственными учреждениями при защите конфиденциальной информации, буде она у них там обрабатывается, а для негосударственных и коммерческих организаций этот документ лишь рекомендательный по характеру. То есть получается, что бизнесмен не обязан на своем объекте иметь такие документы.

Unknown комментирует...

Добрый день. Помогите, извините, девушке. Можно на простых конкретных примерах... Что делать, если в БД должны попасть несколько десятков тысяч физических лиц. И при работе (ежедневной) сотрудник (да и не один) организации должен видеть и понимать, что перед ним именно стоит и улыбается именно то лицо, данные о котором находятся в БД. Кстати, поиск - это тоже обработка? Если я ищу Иванова - то должна найти именно конкретного Иванова, если ищу по номеру удостоверения, то я точно увижу экранную форму с персональными данными его любимого + фото. Да, в БД все хранится с применением некоего шифрования, но... даже мне понятно, как всё это можно собрать в полные данные. Какое тут может быть обезличивание, если задачей службы контроля является сличение? Со общей статистикой все понятно - там и так обработка обезличенная, а вот статистика по конкретному лицу. Сколько раз приходил за месяц на работу, во сколько туда и во сколько обратно и сколько раз бегал за проходную. Можно, конечно, в выходных формах выводить ID, но начальник либо листочек заведет (с соотношением), либо скажет "Вы, что, издеваетесь?". В любом случае соответствие будет установлено.
В общем стандартный женский вопрос - что делать то?

+ вопрос законности функционирования таких баз в 100% ГОСУДАРСТВЕННОМ учреждении федерального уровня. Сейчас там простая БД на SQL Server. Раньше не заморачивались, а сейчас грядет переделка... Должна ли быть эта новая БД зарегистирована, сертифицирована и т.д. (не коммерческая разработка, действовать будет исключительно в стенах данного учреждения) и чьи это обязанности - разработчика или владельца?

+ опа! Данные из старой базы должны будут попасть в новую... А это передача?

Спасибо.

Алексей Лукацкий комментирует...

Обезличивание нужно не для того, чтобы ВСЕ данные вывести из разряда ПДн, а для того, что уменьшить число узлов, на которых данные в виде ПДн. На ПК, где осуществляется сверка/сличение данные будут персональными - их надо защищать. А в остальных местах (в БД, в канале связи) их можно будет защищать не так, как требуют документы ФСТЭК.

Анонимный комментирует...

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

Если не ошибаюсь, у Вас грядет "переделка" системы... Единственное, что я могу посоветовать в блоге Алексея не отбирая его хлеб ;-) - пригласите специалиста по ИБ при проектировании/переделке системы.