Rambler's Top100
Статьи ИКС № 1 2009
Александр ДОДОХОВ  Алексей САБАНОВ  29 января 2009

Красный уровень: персональные данные в АСР

И до появления закона «О персональных данных» (ФЗ-152, принят 27 июля 2006 г.) операторы, конечно, понимали, что при хранении и обработке таких сведений в автоматизированных системах расчета их необходимо защищать. Но ФЗ-152 вывел это понимание на новый, «красный» уровень: безопасность персональных данных критически важна.

А.Л. Додохов, руководитель направления защиты баз, Аладдин Р.Д.А.Г.Сабанов, зам. гендиректора, Аладдин Р.Д.Что новенького?

В ст. 19.1 ФЗ-152 говорится: «Оператор при обработке персональных данных обязан принимать необходимые организационные и технические меры, в том числе использовать шифровальные (криптографические) средства для защиты персональных данных от неправомерного или случайного доступа к ним, уничтожения, изменения, блокирования, копирования, распространения персональных данных, а также от иных неправомерных действий». Отметим, что организационные меры обычно превалируют над техническими – их соотношение колеблется от 80:20 до 60:40.

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

Через полтора года после принятия ФЗ-152, в феврале 2008 г., появились подзаконные акты ФСТЭК и ФСБ, призванные разъяснить основные положения закона и дать методические указания по его исполнению. Увы, они лишь окончательно запутали (если не запугали) операторов связи. Вдобавок к многочисленным регулирующим постулатам отрасли на них свалилась обязанность выполнения федерального закона прямого действия, за нарушение требований которого в ст. 24 предусмотрена серьезная ответственность, вплоть до уголовной или приостановления их деятельности.

 …И прорубил окно в Европу

То, что Россия глубоко интегрирована в мировую экономику и в единое юридическое пространство, показал не только развивающийся кризис. Принятие закона ФЗ-152 России было необходимо и для окончательной ратификации Конвенции Совета Европы о защите личности (формально наша страна ратифицировала ее в 2001 г.). С точки зрения европейского законодательства этот закон необходим для начала легальной деятельности по трансграничному обмену информацией. В ст. 12 ФЗ-152 прямо указывается: «…до начала осуществления трансграничной передачи персональных данных оператор обязан убедиться в том, что иностранным государством, на территорию которого осуществляется передача персональных данных, обеспечивается адекватная защита прав субъектов персональных данных».
По мнению некоторых специалистов по ИБ, упомянутые нормативные документы нуждаются в доработке перед открытой публикацией. Внимательное изучение ФЗ и подзаконных актов заставляет сделать вывод, что каких-либо принципиально новых правил защиты конфиденциальной информации (по сравнению с уже применяемыми к некоторым ИС) они не добавили. Эти документы соответствуют действующей нормативной базе, только в сферу применения средств, обеспечивающих конфиденциальность информации, вошли информационные системы, которые обрабатывают ПД. Рекомендации по использованию тех или иных методов защиты зависят от масштаба ИС, категории обрабатываемых в системе персональных данных, пользовательских режимов доступа и т.д.

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

Как защитить систему биллинга

Стандартные функции  защиты информации в БД

Защита доступа – предоставление доступа к данным после успешного завершения процедур идентификации и аутентификации.

Разграничение доступа – предоставление доступа только к необходимой по работе и должности информации.

Шифрование данных – шифрование передаваемых по сети данных для защиты от перехвата и записываемых на носитель сведений для защиты при краже носителя и предотвращения их несанкционированного просмотра/изменения не средствами СУБД.

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

Снизить расходы на реорганизацию ИС позволяет выбор минимально достаточных технических средств защиты информации. Для этого нужно провести инвентаризацию всех данных, которые можно классифицировать как персональные. Затем следует правильно классифицировать ИСПД согласно Приказу ФСТЭК России, ФСБ России и Мининформсвязи России от 13.02.2008 № 55/86/20. Хорошо бы при этом вовремя уведомить Роскомсвязьнадзор в установленной форме о том, что в ИС будут обрабатываться персональные данные. Категория ПД, класс информационной системы, ее архитектура и условия работы как раз и определяют минимально достаточный набор средств технической защиты информации с точки зрения действующего законодательства.

Кажется, все просто, но здесь-то и начинается самое неприятное для оператора связи. Обычно основой его ИСПД является система биллинга, построенная уже несколько лет назад на базе СУБД. Такие системы, как правило, поставляются немногочисленными поставщиками или разрабатываются и поддерживаются силами собственных программистов. Специалисты ИБ-службы оператора связи заявляют, что в соответствии с классом ИСПД необходимо защитить ПД с помощью криптосредств и ссылаются на ст. 19 ФЗ «О персональных данных». При этом «операторы несут ответственность за соответствие проводимых ими мероприятий по организации и обеспечению безопасности обработки с использованием криптосредств персональных данных лицензионным требованиям…». Очевидно, что воспользоваться имеющимися встроенными средствами шифрования данных СУБД не удастся.

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

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

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

Такое специализированное СКЗИ должно удовлетворять всем требованиям ПКЗ-2005 к применению шифровальных средств для защиты конфиденциальной информации. Необходимо, чтобы в нем использовались стандартные процедуры, форматы и наборы данных, которые гарантируют полную совместимость с сертифицированными СКЗИ разных производителей (RFC 4357, RFC 4490). Наконец, желательно, чтобы выбранное решение не обусловливало изменения программного обеспечения действующих ИСПД.

«Парашют» для Oracle

Рассмотрим упрощенный алгоритм решения «ключевой» проблемы на примере взаимодействия СКЗИ с одной из самых распространенных СУБД – Oracle. Информация, подлежащая защите и хранящаяся в логической структуре БД (таблице), зашифровывается с помощью криптоалгоритма, который реализуется СКЗИ. При этом разная информация может быть защищена одним из N ключей шифрования. Процесс генерации, хранения и распределения ключей шифрования показан на рис. 1.

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

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

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

Так решается задача раздачи ключей пользователям. Но для выполнения требований к защите некоторых категорий ИСПД необходима и возможность разделения доступа. Рассматриваемое нами СКЗИ позволяет это сделать (рис. 2): можно «урезать» доступ к защищенным данным администраторов БД (обычно имеющих неограниченные права «на всё»). Права доступа к защищенным данным всегда определяются набором ключевых пар, записанных на смарт-карте (USB-ключе), а иными словами – успешно вычисленных ключей шифрования.

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

. . .


Закон требует защиты ПД, и биллинговые системы не исключение. Несомненное преимущество специального СКЗИ перед другими средствами защиты – отсутствие необходимости в переписывании кода уже используемых прикладных систем, в изменении структуры базы данных и т.д. Другими словами, сохраняются инвестиции оператора в программное обеспечение. К тому же не нарушается лицензионное соглашение с поставщиком СУБД, а требования ПКЗ-2005 удается удовлетворить. Так что чем раньше мы начнем защищать ПД, тем раньше выполним нормативные требования.
Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!