24.03.2017

Криптография как метод обезличивания ПДн и решения проблем с ФЗ-242

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



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

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

В любом случае презентация есть - может кому будет полезно.

10 коммент.:

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

Не очень понятно как шифрование передаваемых данных поможет решить вопрос с 242-ФЗ. Ну зашифровали мы данные или их часть - обезличили. В итоге как бы и не ПДн передаем. ОК, допустим. А дальше данные прилетели в головной офис Зимбабве и там что? Правильно - там их расшифровали и занесли в БД для обработки (иначе какой смысл им их вообще собирать?!). И что в результате получается? Имеем БД с ПДн граждан РФ на территории иностранного государства. Если мы не осуществляем сбор данных и хранение в БД на территории РФ, то получается нарушение ФЗ - см 6 стр презы. Если осуществляем сбор и хранение на территории РФ, а потом передаем данные (или часть) в наш офис в Зимбабве, то в чем профит свистопляски? Обычно адекватные конторы и так подключены через VPN. Да и про требования регуляторов о передаче ПДн по защищенным каналам не забываем.
И непонятно с чего сделан вывод о фактическом запрете хранения ПДн зарубежом. Нет такого - собирайте и храните в БД на территории РФ, а потом реализуйте трансграничку с выполнением соответствующих требований. В чем сложность-то? Другой вопрос, что многие конторы не хотят новый ЦОД строить или арендовать серверы на территории РФ из-за этих требований. Но предложенный подход эту проблему не решает.

Dmitry Osipov комментирует...

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

Евгений комментирует...

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

В общем, игра слов ради обоснования не обязательности сертификации СКЗИ...

ЗЫ. Тут даже спор не с РКН вырисовывается, а с ФСБ. Многие операторы у нас готовы с ними спорить?

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

Евгений, в России сертифицируются СКЗИ, то есть средства для ЗАЩИТЫ ИНФОРМАЦИИ. Обезличивание не является инструментом/методом/средством защиты информации и не имеет к ней никакого отношения. Если вы найдете в определении термина "обезличивание" хоть что-нибудь про защиту информации, то буду рад вашему объяснению

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

Ronin: да, этот вопрос задавали на конференции. Тут все зависит от цели обработки. Например, вы можете хешировать только ФИО, а остальные данные оставить в открытом виде. По сути мы тогда имеем дело с методом введения идентификатора из приказа РКН. Вы также можете хранить резервную копию на Dropbox в зашифрованном виде. Наконец, вы можете производить расшифрование на хосте с помощью плагина в браузере. При этом сами данные у вас хранятся за пределами РФ в зашифрованном виде. По таком пути, например, пошел salesforce.com.

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

Dmitry: поэтому я упомянул в заметке этот нюанс. Иногда такой вариант единственный для решения проблемы и тогда остается только судиться с РКН. Если оператор не готов, то тут и говорить не о чем.

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

Алексей,
"вы можете хешировать только ФИО, а остальные данные оставить в открытом виде. По сути мы тогда имеем дело с методом введения идентификатора из приказа РКН."

А зачем тогда вообще передавать хэш? Введите просто идентификаторы и все, раз просто статистику передаем. Можно даже сразу обобщение статистическое передавать, а не весь массив. Какой смысл в такой обработке?


"Вы также можете хранить резервную копию на Dropbox в зашифрованном виде."

Ок, но поставленные вопросы не сняло - трансграница и так разрешена, а локальный сервер остался нужен.

"вы можете производить расшифрование на хосте с помощью плагина в браузере. При этом сами данные у вас хранятся за пределами РФ в зашифрованном виде."

Опять же не снимает необходимости заведения полной БД на территории РФ со всеми сопутствующими - какой тогда смысл городить огород?


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

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

Алексей, все так и не так. Согласен с тем, что шифрование ЧАСТИ (наверное, идентификационных)данных в массиве ПДн приведет к обезличиванию. Но это не КРИПТОГРАФИЧЕСКИЙ метод обезличивания, а метод введения идентификатора. По сути, криптография здесь - это метод формирования идентификатора. Это первое. Второе, читай внимательно, например, ПП-313. Там говорится не СРЕДСВАХ КРИПТОГРАФИЧЕСКОЙ ЗАЩИТЫ ИНФОРМАЦИИ. Там говорится о ШИФРОВАЛЬНЫХ (КРИПТОГРАФИЧЕСКИХ) средствах (см. п.1) без привязки к средствам защиты. И под такими средствами понимается в том числе и устройства и их компоненты, в том числе содержащие ключевую информацию, обеспечивающие возможность преобразования информации в соответствии с алгоритмами криптографического преобразования информации. И без привязки к средствам защиты.

Dmitry Osipov комментирует...

Вот сижу изучаю акт проверки и предписание РКН (выпросил у коллег). Могу сказать, что такие тонкости как шифрование и криптография РКН при проверках не интересуют. У них чисто формальные замечания - нет согласия, не перечислены действия, нет политики, и т.д. По большей части претензии дебильные, но суть не в этом. В РКН никто не будет вникать в методы обезличивания и применяемые для этого программы. И вообще, лучше избегать такой конкретики, тогда и дебильных вопросов к оператору не будет.

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

vsv: ПП-313 касается лицензирования, а не сертификации.

Dmitry: согласен, не надо вообще писать об обезличивании - не требуется же