Rambler's Top100
Статьи ИКС № 9 2010
Артем Андреевич МЕДВЕДЕВ  14 сентября 2010

Защищаем базы данных

Критичную бизнес-информацию все компании сегодня хранят в базах данных. Поэтому их защита – последний рубеж обороны корпоративной сети.

Артем МЕДВЕДЕВ, руководитель направления безопасности БД компании «Инфосистемы Джет»Для обеспечения безопасности баз данных компании, как правило, используют стандартные меры (аутентификацию, авторизацию и контроль доступа), однако растущее число и сложность атак говорят о том, что эти меры более не являются достаточными для защиты критичной информации и персональных данных. Многие атаки на БД проходят незамеченными: ситуации, когда факт кражи данных обнаруживается спустя несколько недель после вторжения, отнюдь не редкость. Доступ к информации из баз данных злоумышленники в основном получают с помощью атак типа SQL-injection с использованием брешей безопасности, которые можно обнаружить на любом сервере СУБД, даже на том, где внедрены современные программные продукты. Другая серьезная угроза – внутренние пользователи, которых бывает сложно контролировать. Тем не менее на обеспечение безопасности СУБД администраторы баз данных (DBA), по некоторым оценкам, тратят менее 5% своего рабочего времени.


Внедряем процесс обеспечения безопасности БД


Ключевой фактор успешной защиты БД – знание того, какие данные нуждаются в защите (интеллектуальная собственность, финансовая информация, данные о кредитных картах, кадровые или персональные данные) и как наилучшим образом защитить их от всех типов угроз. Для разработки процесса обеспечения безопасности БД необходимо понимать действующие стандарты, такие как PCI DSS, СТО БР ИББС-1.0 – 2006, ФЗ «О персональных данных», закон Сарбейнса-Оксли, Basel II и др. Естественно, политики безопасности БД должны быть интегрированы с общим процессом обеспечения информационной безопасности корпоративной сети.


Процесс обеспечения безопасности баз данных можно разделить на три основные направления (см. рисунок):


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


2. Реализация ряда превентивных мер,

а именно:


• применение сетевого шифрования и шифрования архивных данных для сокрытия информации от любопытных глаз, имеющих доступ к внутренней сети компании;


• маскирование персональных данных в непродуктивных базах, используемых для разработки, тестирования и обучения, с целью предотвращения несанкционированного доступа привилегированных пользователей (разработчиков и тестировщиков ПО);


• внесение в структуру данных таких изменений, которые гарантируют, что в дальнейшем только подтвержденные и разрешенные изменения будут переноситься в продуктивную среду.


В общем случае выполнение этих мер носит рекомендательный характер, но для критичных БД является обязательным требованием.


3. Аудит, мониторинг и оценка уязвимостей для эффективного обнаружения вторжений. Необходимо обеспечить быстрое реагирование на незапланированные изменения критичных данных или подозрительную активность, связанную с доступом к данным. Аудит БД дает ответы на такие вопросы, как «кто изменил и какие данные?» и «когда было произведено изменение?». Мониторинг активности в базах данных позволяет оповещать о событиях информационной безопасности БД в режиме реального времени и защищать критичные данные. Отчеты с оценкой уязвимостей СУБД, таких как слабые пароли или превышение привилегий, должны дополнять данные мониторинга, которые предоставляют DBA или группа мониторинга безопасности компании.


Базовые элементы безопасности БД


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


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


Аутентификация и авторизация для контроля доступа к БД. Имя пользователя в БД может быть связано с LDAP или со службой каталогов Microsoft Active Directory. Таким образом, пользователям, если они уже прошли аутентификацию, не нужно вводить свои идентификационные данные повторно. Администраторы БД должны регулярно проверять все имена пользователей в базах данных и следить, чтобы только авторизованные пользователи осуществляли доступ, деактивируя неиспользуемые учетные записи. В идеале, для того чтобы усилить разделение ролей, создавать учетные записи должна группа, отличная от DBA. Даже если пользователь приложения прошел аутентификацию и авторизацию, администратор БД должен проверить, что только активные учетные записи обращаются к каждой базе данных. Администраторы БД также не должны использовать учетные записи DBA по умолчанию. Организации должны выделять администраторам индивидуальные учетные записи и отслеживать их действия с участием специалистов по безопасности и управлению рисками.


Контроль доступа для усиления защиты персональных данных. Администраторы БД должны создать роли для объединения пользователей на основании их привилегий и управлять этими группами, наделяя каждую роль необходимыми привилегиями. Веб-приложения, использующие для доступа к БД единую учетную запись с администраторскими привилегиями, представляют угрозу безопасности и должны находиться под постоянным контролем.


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


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


Дополнительные меры защиты


Для обеспечения безопасности самых критичных баз данных, как продуктивных, так и непродуктивных, необходимо принять дополнительные меры.


Шифрование баз данных, работающих в продуктивной среде. Шифрование можно применять на двух уровнях: 1) на уровне БД, т.е. шифровать сами данные, и 2) на сетевом уровне – защищать пакеты данных, которые передаются между СУБД и другими узлами, такими как пользователи или приложения. Сетевое шифрование защитит данные от злоумышленников, использующих сетевые сканеры и сниферы, а также от любопытных пользователей. Так как эти способы шифрования помогают защититься от различных типов угроз, их можно применять одновременно и независимо друг от друга.


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


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


Обнаружение аномалий и проведение регулярных проверок на уязвимости. Регулярные проверки СУБД на уязвимости и подозрительные аномалии – важный элемент стратегии обеспечения безопасности баз данных. Данные и метаданные в БД могут быть изменены, скопированы или удалены в течение нескольких секунд. Для выполнения требований регуляторов необходимо отслеживать все изменения и доступ к персональным данным в режиме реального времени. Аномалии в поведении пользователей могут обнаруживаться с помощью мониторинга активности, аудита СУБД и оповещения о подозрительной активности. Не все записи в БД нуждаются в непрерывном аудите, но в критичных базах данных необходимо регистрировать транзакции и доступ к персональным данным. Конечно, аудит отрицательно влияет на производительность СУБД и работу приложений, но за последние несколько лет появился ряд производителей, предлагающих решения для мониторинга и аудита сторонних баз данных (Database Activity Monitoring, DAM). В России наиболее известны такие производители и продукты, как IBM Infosphere Guardium, Imperva, Embarcadero DS Auditor. Эти решения поддерживают широкий перечень версий СУБД и позволяют избежать увеличения нагрузки на них. Также существует ряд продуктов от производителей СУБД, поддерживающих свои базы данных, например Oracle Database Vault, которые эффективно решают задачи мониторинга, обнаружения аномалий и оповещений о несанкционированных транзакциях.  

Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!