Персональные данные: реализация системы обработки и аудит доступа. Комментируют эксперты

Максим Мамчиц
Консультант ООО "ИнфоТехноПроект"

После вступления в силу ФЗ "О персональных данных" (№ 152-ФЗ от 27 июля 2006 г.) у всех без исключения операторов персональных данных резко прибавилось головной боли в вопросе организации защиты ПД. На момент написания этой статьи в Россвязькомнадзоре было официально зарегистрировано 43 989 операторов ПД, в которых обрабатывается информация практически обо всех гражданах России.

Закон четко предписывает всем операторам ПД с 1 января 2010 г. привести в соответствие с требованиями данного закона свои информационные системы (ИС). Времени осталось катастрофически мало для столь сложной задачи, особенно в условиях отсутствия типовых схем и решений построения системы обработки ПД. Дабы восполнить этот пробел, предложен справочный вариант реализации архитектуры для централизованной системы обработки ПД (см. с. 14-15).

Плюсы:

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

Минусы:

1. Подсистема управления в данной иерархии оказалась "оторванной" от остальной сети, что резко снижает эффективность выполнения функций управления. Центр событийного протоколирования и мониторинга (13) не сможет в данном случае проводить сбор информации о работе всей системы. УЦ (15) не сможет оказывать услуги по оперативной проверке ЭЦП. Очевидно, что подсистема управления должна входить в основную сеть, но с применением таких средств защиты, которые бы исключали неправомерный доступ к данной подсистеме. Также в подсистему управления должны входить датчики системы обнаружения вторжений (11).
2. Данная архитектура имеет ярко выраженную централизованную, иерархическую структуру. Подразумевается, что все ПД находятся в одном месте на одном или нескольких серверах. Однако на практике встречается довольно много ИС, имеющих распределенную структуру, где несколько серверов работают на значительном удалении друг от друга. В этом случае необходимо организовывать защищенное межсерверное взаимодействие. Также не стоит забывать про тенденции развития IT, которые диктуют переход от централизованной к децентрализованной архитектуре (сервис-ориентированные архитектуры SOA).
3. К сожалению, системы ЭДО еще не очень широко распространены, в большинстве случаев результатом работы сотрудника по-прежнему является печатный документ. В связи с этим удаленное подразделение также необходимо обеспечить возможностью вывода информации на печать и принять меры по безопасному распространению и контролю напечатанных документов.
4. Согласно требованиям РД ФСТЭК, в составе ИСПДн должны быть средства от утечки информации по техническим каналам. Это могут быть системы постановки акустических и вибрационных помех, генераторы шума. Данные средства также должны иметь свое место в общей структуре системы.

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

Александр Андрущенко
Исполнительный директор ООО "ИНФОРИОН"

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

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

Обозначенная здесь проблема могла бы быть решена путем реализации функций аудита доступа к ПД на уровне приложения, осуществляющего работу с базой данных (стандартная архитектура современных ИС: Application + Application Server + DataBase) или на уровне аудита СУБД. Но и первый, и второй способы имеют свои ограничения: далеко не все приложения умеют вести аудит доступа к ПД (включая все операции - добавление, отбор, удаление, изменение), а современные СУБД не позволяют в полном объеме вести такой аудит (например, как выполнить протоколирование генерируемого приложением запроса select, возвращающего множество записей?). По нашему мнению, в ИС, обрабатывающих ПД, должны появиться соответствующие доработки. Сложнее вопрос с аудитом на уровне СУБД: или такой функционал предоставят разработчики СУБД, или на рынке появятся средства третьих разработчиков (имеющиеся средства аудита доступа к СУБД на уровне сети или программных агентов не позволяют вести эффективный аудит доступа к ПД).

Аудит доступа к ПД в ИС - мощная и эффективная мера безопасности, полезная как для субъекта ПД, так и для оператора. "Предупрежден - значит вооружен".