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

Сергей Рябко
К.ф.-м.н., президент группы компаний "С-Терра"

Ловкость рук - и никакого мошенничества!

В профессиональной среде как легальный прием защиты ПДн часто обсуждается вопрос об их "обезличивании". Логика сторонников этого организационно-технического мероприятия основывается на том, что, в соответствии с действующим регулированием, ИСПДн, оперирующая с обезличенными персональными данными, относится к классу К4, а идентификационная информация, лишенная содержательного контекста, тянет в самом худшем случае (большая размерность) на К3.

Итого имеем, например, ИСПДн класса К1. Реорганизуем ее, разделяя систему с обезличенной контекстной информацией и систему с лишенными контекста идентификационными данными (рис. 1). В результате мы получаем две системы с низкой классификацией. Выгоды очевидны:

Возросла безопасность: нарушитель, получивший доступ к одной из систем, не получает реальных ценностей.

Снизилась техническая сложность системы защиты: ИСПДн К4 с обезличенными данными вообще почти не нужно защищать, а ИСПДн К3 с идентификационными данными можно защитить лишь номинально.

Соответственно, снизив затраты на построение и эксплуатацию системы защиты, мы к сакральной дате 01.01.2010 г. "уместимся" в кризисный бюджет 2009 г. Казалось бы...

Теорема о сохранении требований по стойкости защиты

Прежде всего, следует понимать, что декомпозиция исходной системы на подсистемы обработки контекстной и идентификационной информации не меняет требования по уровню защиты системы в целом. Замена одной системы класса К1 на две системы (например, К3 и К4) недопустима.

Вообразите себе для определенности, что мы имеем дело с медицинскими данными. Мы отделили контекст, например рентгеновский снимок легкого, от имени его владельца. Сам по себе такой снимок годится разве что для записи рок-н-ролла, как это нам разрисовали в новомодном фильме. Но врачу ведь не патефон слушать... "Э-э-э, батенька, да у этого пациента саркома! Срочно на операцию!" - и далее по какому-то неясному нам, но ведомому ИСПДн индексу будет выяснено, что владелец легкого - Иван Иванович Иванов, заядлый курильщик, нестарый еще человек, который и поживет еще, если вовремя прооперировать. Дело в том, что между нашими ИСПДн К3 и К4 существует информационная связь, которая позволяет врачу на базе раздельной идентификационной и контекстной информации воссоздать данные класса К1: "У Ивана Ивановича - саркома!"

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

По сути, при этом наш злоумышленник атакует единую систему класса К1, выполняя двустадийную атаку на ее подсистемы. А сломать ему нужно подсистемы класса К4 (защита которой носит номинальный характер) и класса К3 (стойкость защиты которой весьма невысока). Поскольку двустадийная атака - уже давно повседневная практика хакера, то, по существу, путем обезличивания ПДн мы произвольно снизили защиту исходной системы К1 до уровня К3...

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

Но, возможно, обезличивание может принести нам полезную реконструкцию инфраструктуры информационной системы.

Подводные камни информационных инфраструктур

Идея обезличивания ПДн - вовсе не что-то новенькое. Тема выноса идентификационной информации в единую централизованную инфраструктуру очень не нова. Она восходит к 1984 г., когда в рабочей группе 4 в 21-м комитете МККТТ (ныне -МСЭ-Т) была начата работа над изданной в 1988 г. первой серией стандартов службы каталога.
Судьба этого протокола - одна из самых трудных. Первая его редакция была просто дохлой. Стандарт X.500 DAP, несмотря на довольно энергичные попытки внедрения, "не жил" до тех пор, пока IETF не очистил стандарт от ненужных наворотов, добавив к DAP букву "L" - Lightweight. Да и LDAP до версии 3 двигался туго.

Показательны усилия консалтинговой команды "The Burton group" (TBG), которая на границе тысячелетий под лозунгом "put i before e" пыталась придать вес и внедренческий импульс идее централизованной вокруг каталога информационной инфраструктуры.

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

Осознав раньше других все эти достоинства каталога, ребята из TBG постарались "проехаться" на волне этих преимуществ. Однако к 2002-2003 гг. лозунг каталога как-то утратил вес в их выступлениях, консультанты стали искать альтернативные темы. Почему - тем более что на подходе были реально работающие, по меньшей мере в инфраструктуре единого производителя, каталоги типа Microsoft Active Directory?

Дело в том, что внедрение централизованной инфраструктуры IAM несло в себе большие и практически всегда недооцениваемые "скрытые" затраты. Легко купить каталог. Относительно легко "перевесить" на него одно, пусть даже центральное, бизнес-приложение. Но вслед за этим мы начинаем привязывать и другие (их - десятки) приложения, асинхронно менять версии программных продуктов (и каталога!), распределять каталоги - и потом синхронизовать их содержание... Вал проблем с ростом уровня интеграции каталога в инфраструктуру прогрессивно растет. В какой-то момент почти каждый заказчик, купившийся на идею "put i before e", доходил познаменитой "кривой освоения технологии" до "ямы разочарования". Причем часто глубина "ямы" была такой, что хорошо, если заказчик не выкидывал каталог целиком, а оставлял для обслуживания одного, наиболее "directory friendly" приложения. Соответственно и консультанты, для которых успех заказчика, последовавшего их совету, - основа бизнеса, стали потихоньку "отруливать" от трудной темы.

Означает ли вышесказанное, что "обезличивание" - вязкая, технически бесперспективная тема? Не означает. И Microsoft, и ныне Oracle, только что приобретший в пакете с Sun Microsystems каталог, исторически восходящий еще к компании Netscape, доведут свои IAM-продукты до массового пользования при разумном уровне совместимости и стоимости владения. Однако наш визави на предприятии заказчика - офицер безопасности - должен четко понимать, что задача "обезличивания" в такой постановке - это никак не задача защиты данных, а задача радикальной и дорогостоящей реформы всей ИТ-инфраструктуры. И стоит задуматься - а нужно ли офицеру безопасности, выносящему инициативу по "обезличиванию ПДн", вылезать из зоны полномочий ИБ далеко в зону интересов службы ИТ, да еще при этом "подставляться" под ответственность за весьма вероятные внедренческие неудачи ИТ-шников?

Так есть ли сермяга в "обезличке ?

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

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

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

Такая "обезличка" не нова. Прототипные системы работают по всему миру десятки лет.

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

Такая система "диспергированных идентификационных данных" - дороже любого IAM обойдется. Хотя, отмечу, речь при этом идет о начальных инвестициях: удельные затраты на единицу защиты персональных данных в больших системах могут быть очень даже невелики.

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

Комментарий эксперта

В. Пинженин
Генеральный директор ООО "Сетевые решения"

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

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

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