Всем известно требование нормативных документов ФСБ по персданным, согласно которому: "Для обеспечения безопасности персональных данных при их обработке в информационных системах должны использоваться сертифицированные в системе сертификации ФСБ России (имеющие положительное заключение экспертной организации о соответствии требованиям нормативных документов по безопасности информации) криптосредства". Выполнить это требование непросто, ввиду отсутствия сертифицированных решения для большого количества сценариев обработки ПДн. Но даже в том случае, если такое решение существует, немногие готовы его покупать. И из-за дороговизны, и из-за непонятности требования - ведь уровень защиты ПДн при этом не изменяется. Какая разница, чем зашифрованы ПДн - ГОСТом или AESом? Ни ФСБ, ни производитель, ни сертификационная лаборатория все равно никакой ответственности не несет. Так зачем, как говорилось в одной рекламе: "платить больше?"
Есть сценарий ухода от использования сертифицированных шифровальных средств при обработке ПДн. Но использовать его можно только в том случае, если вы готовы его обосновывать перед проверяющими (если таковые появятся на горизонте). Итак идея проста - вы не шифруете, вы обезличиваете ;-)
В приведенной выше формулировке ФСБ речь идет о защите ПДн. Обезличивание же никакого отношение к безопасности ПДн не имеет. Его цель - вывести данные из разряда персональных, тем самым снизив требования к оператору ПДн и его издержки. И шифрование по существующим международным документам (а также рекомендациям ЦБ и АРБ) является идеальным механизмом обезличивания. И ведь никто никогда не утверждал, что шифровальные средства ограничиваются только одной сферой применения - защитой. Их можно использовать для множества других задач - обеспечения целостности информации (и никто не требует сертификации средств, использующих CRC) или проверки подлинности информации. Почему нельзя использовать шифровальные средства для обезличивания информации? Запрет есть? Нет! Значит можно.
А что вытекает из этого? То, что для обезличивания вы можете использовать любые средства шифрования - даже, о, крамола, несертифицированные. Можно пойти дальше и спокойно применять IPSec на пограничных маршрутизаторах с целью не защиты данных, а их обезличивания. А для этого не надо ни сертификации шифровального средства, ни лицензии на его техобслуживание.
Подписаться на:
Комментарии к сообщению (Atom)
28 коммент.:
То есть, если я правильно понял, возможно шифровать(обезличивать) данные на местах, используя любой алгоритм шифрования, а после передавать их с использование несертифицированных СЗ?
Ну это моя версия исходя из чтения законодательства. Но подозреваю, что у регулятора будут к ней претензии - это же крамола ;-)
Гениальная и вместе с тем простая идея, и как она раньше не пришла в голову? :)
Идея очень нравиться! Остается так обосновать, чтобы, при необходимости, выиграть в суде.:)
Итак, представим картинку. ФСБ приходит к оператору с проверкой, тычет пальцем в Cisco ASA и говорит: это что у Вас такое? VPN сделали? Данные шифруете? Почему несертифицировано? И оператор проводит им шоу-представление: гаснет свет, включаются софиты, с лазерные лучи, дым, выезжает на постаменте черный ящик, с одной и с другой стороны в него включаются ноутбуки, и начинается: с одного ноута через черный ящик передаются паспортные данные в открытом виде, упакованные в TCP\IP, а на другой стороне ставится сниффер и... барабанная дробь... о чудо! Ползут кракозябры - данные обезличены! Что в черном ящике? Сексапильная красотка подходит к нему, но свет сконцентрирован на ящике: крышка открывается... и своими нежными руками красотка достает из него Cisco ASA! Фанфары! Конфети! Аплодисменты! Ну и конечно же, банкет.
Вот как-то так, наверное, и можно убедить регуляторов, что при помощи железки, на которой построен VPN, данные не шифруются, а обезличиваются.
Мне кажется "обезличенные" данные - это когда их невозможно восстановить до исходного состояния... А при шифровании само собой возможно.
Идея, бесспорно, красивая ;-)
А если я всю SQL-ную базу с ПДн'ами заRARю с паролем и шифрованием заголовков (авторы пишут, что AES-128 пользуют), а потом назову resource.rar?
Получится, что нету у меня ПДн'ов в пересылаемой информации?..
To Александр
Ст. 3 ФЗ-152:
8) обезличивание персональных данных - действия, в результате которых невозможно определить принадлежность персональных данных конкретному субъекту персональных данных;
> обезличивание персональных данных - действия, в результате которых невозможно определить принадлежность персональных данных конкретному субъекту персональных данных
А у нас получается, что невозможно определить что там - персональные данные или нет - степень обезличивания на порядок выше :)
Мне эта идея кажется сомнительной. Согласна с Александром. "Обезличивание персональных данных - действия, в результате которых невозможно определить
принадлежность персональных данных конкретному субъекту персональных данных". При шифровании определить принадлежность конкретному лицу можно. Путем дешифрования.
Не раз слышала утверждение, что обезличивание - это необратимый процесс, т.е. нельзя по исходным данным определить конкретного субъекта ни с помощью ID, ни с помощью расшифровки данных.
Это мое мнение. В любом случае оспорить в суде такую точку зрения мне представляется нереальным ;-)
ФЗ 152 даёт определение: "обезличивание персональных данных - действия, в результате которых невозможно определить принадлежность персональных данных конкретному субъекту персональных данных"
Можно ли обесличить ПДн с помощью такого действия: подмена ПДн некими кодами по таблице замены? (тривиальная кодировка).
Наверное нет, если эти таблицы не уничтожить сразу после кодирования (а где гарантия что они сразу будут уничтожен?). Иначе остаётся теоретическая возможность у злоумышленника выполнить обратную замену и установить принадлежность ПДн...)
Алексею Волкову: Я же не подменял обезличивание и шифрование. Я всего лишь заметил, что в России регулируется шифрование для ЗАЩИТЫ, а не для обезличивания.
Александру: Нигде не сказано, что обезличивание должно быть необратимым. Европейская практика говорит даже обратное. И документы Минздрава и ЦБ, согласованные с регуляторами, также.
Andy_AiF: Да. В том-то и фишка ;-)
Анна: Ни в одном нормативном акте не написано про необратимость. И есть ответ РКН, что механизмы обезличивания вообще определяет оператор самостоятельно.
Эта точка зрения не лучше и не хуже любой другой ;-)
Алексей, это лукавство =)
Такое же, как и
"Автоматизированные системы, в которых обрабатываются персональные данные, но целью работы которых не является обработка персональных данных, включаются в перечень систем, обрабатывающих персональные данные, но не классифицируются как ИСПДн."
Никакого лукавства. Раз регулятор не хочет идти на компромисс, операторы будут выискивать слабости в законодательстве. ФСБ уже проиграло несколько дел по требованию наличия лицензии ФСБ на деятельность в области шифрования. И тут при правильном подходе проиграет.
> что в России регулируется шифрование для ЗАЩИТЫ, а не для обезличивания.
Следуя этой логике, можно вообще представить ситуацию, когда ФСБ приходит с проверкой и видит, что на том месте, где по идее должен стоять VPN router, стоит забор из колючей проволоки, за ним - черный ящик, на нем - табличка, на котором белыми буквами написано: ОБЕЗЛИЧИВАТЕЛЬ ПДН - НЕ ВЛЕЗАЙ УБЪЕТ. А сотрудники обходят это место стороной...
> Раз регулятор не хочет идти на компромисс, операторы будут выискивать слабости в законодательстве
Подписываюсь
>и при правильном подходе регулятор проиграет
>Эта точка зрения не лучше и не хуже любой другой ;-)
Чем приведенный выше подход неправильный? Не хуже Вашего, Алексей :)
Думаю нужно учитывать еще 351 Указ президента.
http://document.kremlin.ru/doc.asp?ID=044662
Доказать, что шифрование - не обезличивание, довольно просто. Надо доказать факт восстановления зашифрованных данных. Надо доказать, что по "обесличенным" данным кто-то смог "определить принадлежность".
Вы же их будете шифровать не ради спортивного интереса, а для передачи кому-то с какой-то целью. Когда этот "кто-то" свою цель осуществит (например, разошлёт спам вашим клиентам), вот тут-то и будет доказательство, что данные не обезличены.
дык это будет обычное разглашение.
этот "кто-то" получит анальные данные на основании договора в котором есть пункт с требованием конфиденциальности и нераспространения.
нарушение будет на нем, а не на том от кого данные получены
Евгению Родыгину: А ПП-351 относится к госам ;-)
> этот "кто-то" получит анальные данные на основании договора в котором есть пункт с требованием конфиденциальности и нераспространения
а это будет еще одним доказательством того, что передаются не обезличенные данные, а самые что ни на есть ПДны.
у вас неправильные представления об обезличенных данных.
в момент передачи данные обезличены.
точно так же данные могут быть обезличены только при хранении например.
а при использовании они становятся необезличенными.
Вы же их будете шифровать не ради спортивного интереса, а для передачи кому-то с какой-то целью. Когда этот "кто-то" свою цель осуществит (например, разошлёт спам вашим клиентам), вот тут-то и будет доказательство, что данные не обезличены.
А почему обезличивание не может приследовать ту же цель, т.е. "для передачи кому-то с какой-то целью"? В таком случае и без "лукавого шифрования" "кто-то" получит данные вида: Id, проч., и восстановит недостающее по Id.
Ну и чем шифрование хуже?
pushkinist,
если данные обезличены, то нет необходимости обеспечивать их конфиденциальность по закону, а передающему оператору не имеет смысла ссылаться в этом случае на положения фз-152 при включении пункта о конфиденциальности в такой договор.
договор-то требует конфиденциальности в момент использования, а обезличены в момент передачи.
А передаются-то как вы говорите "обезличенные" данные. Какая тогда на вас ответственность? Никакой. Третье лицо само там как-то восстанавливает, или придумывает, к кому эти "обезличенные" ПДн относятся, так что ответственность и так на нем - без всяких условий по договору. А Вы же больше ничего им не сообщаете, только "обезличенные" данные.
бессмысленный спор.
считайте как хотите.
бессонница из-за того, что "в интернете кто-то не прав" меня мучить не будет.
Здравствуйте Алексей. Хотел у вас узнать насчет использования хэширования при обезличивание ПДн.
В одной из своих работ вы утверждаете: "Что идеальным вариантом для обезличивания является использование алгоритмов криптографического хэширования, но в России это относиться к криптографии и является лицензируемым видом деятельности, что связано с определенными трудностями".
Хотел уточнить, почему вместо хэширования ПДн нельзя, для уменьшения временных и денежных затрат, просто данные убрать, или заменить их некоторым идентификатором, показывающим, что данные были обезличены?
Я не представляю, как значение хэшированных обезличенных данных можно использовать для контроля целостности. Единственные преимущесва хеширования, которые я вижу:
1 Фиксированная длинна свертки хэш-функции дает удобство хранения данных в базе.
2 Возможно значение хэша показывает, что данные были обезличены, а не просто их нет.(Хотя можно было использовать один индентификатор обезличивания, например data_was_depers).
3 Проверка целостности хэшированных записей в БД, но остальная часть Бд не защищеня от модификации.
Моя почта: KukinAU@darklogic.ru
Господа, а не кажется ли вам, что вы забыли , в какой стране вы живете. И что если проверяющий захочет - ему будет плевать на ваши формулировки "обезличивания"
Использовать несертифицированный софт на предприятии очень и очень чревато. Я молчу про гос. структуры, которые шифруют ГОСТом и тупо не в состоянии применять никаких других программ, которые его не поддерживают. Они как раз и используют программы Крипто ПРО и CyberSafe поскольку обе имеют сертификаты и алгоритм шифрования ГОСТ им доступен.
Отправить комментарий