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

В любой современной информационной системе большая часть данных хранится в реляционных базах данных, выступающих как ядро хранения данных, откуда они извлекаются приложениями различного уровня. Если учесть высокую долю участия инсайдеров в общем числе краж данных
(см. врезку «Внутренние угрозы»), то становится ясно — защита критичных данных организации должна начинаться с защиты ядра хранения этих данных и не ограничиваться традиционной защитой периметра.

УПРАВЛЕНИЕ СОБЫТИЯМИ

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

Первый тип таких систем — системы управления событиями информационной безопасности (Security Information and Event Management, SIEM). На рынке присутствуют предложения от таких вендоров, как ArcSight (весьма популярное решение в России), RSA/EMC, eIQnetworks, Q1 Labs, Symantec и пр. Кроме того, некоторые производители (CA, Cisco, IBM, NetIQ, Novell и пр.) предлагают системы, фокусирующиеся на защите собственных продуктов.

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

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

В больших и сложных инфраструктурах наличие системы SIEM может быть необходимым, но не достаточным для защиты данных, так как остаются нерешенными следующие задачи:

  • применение политики безопасности на уровне БД;
  • поиск и оценка уязвимостей СУБД;
  • распределение обязанностей (separation of duties), в частности, между системными администраторами и сотрудниками службы безопасности (поскольку администраторы контролируют системы, предоставляющие информацию для SIEM);
  • защита важных данных в БД;
  • управление доступом к БД;
  • мониторинг изменений в БД;
  • составление отчетов о соответствии законодательным нормам и т. д.

Последняя тема — соответствие различным стандартам и законам — становится все более актуальной в последнее время в связи с тем, что в западных странах были приняты SOX, PCI-DSS и другие законы и стандарты, а в Рос-сии — закон «О персональных данных». И каждый производитель решений по безопасности старается представить в своих решениях большое количество «красивых» отчетов для демонстрации выполнения требований подобных законов и стандартов.

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

МЕЖСЕТЕВЫЕ ЭКРАНЫ

Второй тип систем — межсетевые экраны для Web-приложений (Web Application Firewall, WAF). Это может быть устройство, серверное ПО или фильтр, который применяет набор правил к трафику HTTP (см. Рисунок 1). Обычно правила охватывают такие известные типы атак, как Cross-Site Scripting (XSS) или инъекции SQL. Среди производителей подобных систем — компании Cisco (ACE Web Application Firewall), Citrix (NetScaler Application Firewall), Imperva (SecureSphere), Barracuda Networks (Web Application Firewall), F5 (Application Security Manager) и другие.

Настроив правила под конкретные приложения, можно обнаружить и блокировать множество известных атак. Однако объем работ для выполнения этой настройки оказывается весьма существенным; кроме того, те же самые действия придется повторять при любом изменении приложений. Системы WAF часто называют брандмауэрами с глубоким анализом пакетов (Deep Packet Inspection Firewall), так как они анализируют каждый запрос и ответ на уровнях HTTP/HTTPS/SOAP/XML-RPC или Web-служб.

На развитие и появление систем WAF определенное влияние оказал стандарт PCI DSS, в соответствии с которым информация о кредитных картах в публичных Web-приложениях должна быть защищена, по крайней мере, одним из двух методов — посредством анализа кода Web-приложения либо установкой точки применения политики безопасности. Одно из назначений систем WAF — защита данных (например, в соответствии с PCI DSS) путем анали-за и блокирования входящих потенциально опасных сеансов.

Некоторые продукты (Imperva, Barracuda и пр.) способны анализировать исходящий трафик для обнаружения утечек данных и осуществлять его блокирование, для чего используются шаблоны нужных типов данных (номера кредитных карт и т. д.). Однако не все данные могут удовлетворять шаблонам (например, текстовые строки неопределенного вида и пр.). Таблицы, содержащие подобные данные, остаются незащищенными в БД. Нерешенными остаются и вопросы обеспечения целостности данных, что является одним из требований закона SOX. Кроме того, системы WAF не могут выполнять следующие важные функции:

  • обнаруживать злоупотребления правами, предоставленными для внутренних привилегированных пользователей;
  • выявлять неправомерные действия авторизованных пользователей;
  • отслеживать и защищать критичные объекты в БД;
  • фиксировать (lock-down) безопасную конфигурацию (на уровне БД и ОС);
  • контролировать изменения важных данных в БД;
  • представлять целостную картину (отчеты) по соответствию нормативным требованиям — WAF способны собрать только часть необходимой информации (использование данных внешними пользователями Web);
  • оценивать состояние окружения СУБД и оповещать о потенциальных уязвимостях;
  • «понимать» сложность СУБД и SQL (обычно функциональность WAF ограничена распознаванием некоторых типов данных по шаблонам).

Вывод таков: как и обычные МСЭ для защиты периметра, WAF могут быть необходимы, но далеко не всегда достаточны для обеспечения защиты данных.

СИСТЕМЫ ДЛЯ ПРЕДОТВРАЩЕНИЯ УТЕЧЕК

Следующий тип — решения по предотвращению утечек данных, (Data Leakаge Prevention, DLP). Эти системы обнаруживают, отслеживают и защищают критичные данные в конечных точках их использования, в хранилищах и при их перемещении по сети. Такие системы предназначены для обнаружения и предотвращения неавторизованного использования и передачи конфиденциальной информации. Таким образом, защита данных — главная функция решений DLP. На рынке систем DLP присутствуют предложения от Symantec, Websense, McAfee, EMC/RSA, CA и других производителей.

В таких системах поиск и отслеживание важных данных могут вестись путем удаленного сканирования (в хранилищах данных наподобие NAS, CFS/NFS и пр.) и локального наблюдения на хостах с помощью программных агентов, а также посредством пассивного наблюдения за сетевым трафиком (например, путем подключения аппаратуры DLP к порту SPAN в случае использования сетевого оборудования Cisco). Предотвращение несанкционированных попыток перемещения информации может осуществляться разными способами — встраиванием программных модулей агента DLP в различные системы обработки информации (серверы электронной почты и пр.) или установкой оборудования DLP в разрыв сетевого пути для принудительного блокирования сетевых сеансов.

Отличительной особенностью большинства систем DLP является их ориентированность на периметр — системы DLP отслеживают критичную информацию, покидающую пределы компании (через электронную почту, Web, системы обмена сообщениями, переносные устройства и пр.). Процессы же, происходящие с информацией, хранящейся в корпоративной базе данных, остаются, как правило, неохваченными.

МОНИТОРИНГ АКТИВНОСТИ СУБД

Для защиты информации непосредственно в ядре предназначены системы мониторинга активности СУБД (Database Activity Monitoring, DAM). Если систему DLP можно представить как охранника, проверяющего сумки на выходе из банка, то система DAM — это камера наблюдения в банковском хранилище. Обе занимают важное место в защите и дополняют одна другую. Более подробная информация о возможностях таких систем приведена в Таблице 1.

Решения DAM предлагают компании Guardium, Imperva, Tizor Systems, Application Security и пр. Их основные возможности, как правило, включают:

  • аудит всех сеансов СУБД (регистрация, код SQL, завершение сеанса и пр.);
  • аудит всех исключений СУБД (ошибки, неудачные попытки входа);
  • блокирование нежелательных сеансов в соответствии с различными критериями;
  • оповещение о различных событиях;
  • контроль уязвимостей СУБД;
  • предотвращение утечки данных из базы данных (проверка извлекаемой информации);
  • обнаружение аномалий в функционировании на основе базового состояния;
  • выявление критичных данных по заданным критериям;
  • отчеты по соответствию SOX, PCI DSS и прочим законам и стандартам.

Обычно системы DAM используются в нескольких вариантах — на Рисунке 2 приводятся примеры решения Guardium. Наблюдение за трафиком от/к СУБД может осуществляться на сетевом уровне в режиме сетевого сниффера, когда оборудование Guardium анализирует зеркалированный трафик СУБД (вариант коллектора). Другой, более продвинутый, подход — использование коллектора и программных агентов, функционирующих на хостах СУБД, — является предпочтительным, поскольку наличие в нем агентов позволяет отслеживать не выходящий в сеть локальный трафик СУБД (например, от локального клиента к серверу СУБД по протоколу Bequeath в случае СУБД Oracle).

Кроме того, при наличии агентов становится возможным наблюдение за трафиком СУБД, передаваемым по сети в зашифрованном виде (например, при использовании Oracle ASO). Агенты S-TAP позволяют следить за изменениями объектов окружения СУБД — файлами, выводами команд SQL и команд ОС, переменными окружения и значениями ключей реестра (в случае ОС семейства Microsoft Windows). Еще одно преимущество программного агента — возможность блокировки любых нежелательных сеансов СУБД, в том числе и локальных, осуществляемых с помощью механизмов межпроцессного взаимодействия. Наконец, третий вариант подключения оборудования DAM в инфраструктуру — установка в разрыв сетевого пути, что позволяет принудительно блокировать сетевые соединения СУБД (аналогично брандмауэру).

В системах DAM весь перехваченный код SQL подвергается тщательному анализу, что обеспечивает получение различной необходимой информации, например, о фактах обращения к контролируемым таблицам за предопределенный период, изменения данных в заданных таблицах, доступа с некоторых IP-адресов или клиентских программ, выполнения хранимых процедур, неудачных попыток входа, ошибочных команд и т. д. На основе любой информации можно сконфигурировать простые или корреляционные оповещения.

Управление защитой СУБД осуществляется на основе политики безопасности, состоящей из набора правил. Каждое правило представляет собой набор критериев срабатывания (к примеру, таковыми могут быть IP-адреса клиента и сервера, имя клиентской программы, учетная запись СУБД и ОС, время исполнения команды, используемый протокол, имя базы данных, параметры запроса SQL и пр.) и реакцию на них (оповещение, протоколирование, блокирование и пр.). В некоторых решениях, например, в Guardium, правила могут подразделяться на несколько типов: правило доступа (с анализом входящих запросов SQL), правило исключений (для выявления исключительных ситуаций в СУБД — ошибки и неудачные попытки входа) и правило извлечения (с изучением данных из базы данных). Правило извлечения позволяет задать реакцию на выгрузку данных, соответствующих заданному шаблону, без учета специфики запроса SQL.

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

Возможность фиксации и отслеживания базового состояния необходима для разделения нормальных бизнес-процессов и потенциально опасных действий (аномалий). Базовое состояние — это политика безопасности, создаваемая автоматически по результатам наблюдаемой активности базы данных за некоторый период времени. Сначала база данных переводится в максимально безопасное состояние, затем предложенная автоматическая политика при необходимости корректируется и принимается за основу. Все отклонения от нее в дальнейшем будут считаться аномалиями (таковыми могут быть, к примеру, инъекции SQL), а при их возникновении начнет выполняться заданная реакция. Поддержка подобной возможности в решении DAM очень важна, поскольку позволяет существенно упростить работу подразделения, отвечающего за защиту данных, и достаточно быстро обеспечить соответствие БД существующим стандартам и политике безопасности организации.

Многие решения DAM предусматривают автоматическое обнаружение, локализацию и классификацию информации в базе данных, содержащей конфиденциальные данные. Деление на классы может использоваться в политиках безопасности для автоматической защиты найденной критичной информации. Обнаружение может быть настроено в соответствии с заданными критериями и производиться регулярно, чтобы предотвратить появление в инфраструктуре серверов-клонов, созданных злоумышленниками, а также гарантировать контроль всей без исключения критичной информации (в том числе в составе работающих частей информационных систем, выведенных из эксплуатации, и пр.).

Наиболее продвинутые производители решений DAM представляют масштабируемые продукты, которые можно внедрять как в небольших организациях, так и в крупных, территориально распределенных компаниях с централизованной агрегацией и нормализацией собранной информации, а также централизованным управлением политиками безопасности через единую точку доступа. В таких решениях, как Guardium, отдельный тип устройств, агрегаторы, объединяют данные аудита, собранные со всех подчиненных коллекторов, и позволяют централизованно управлять политикой безопасности. Более того, агрегаторы сами могут располагаться на разных уровнях иерархической архитектуры и являться подчиненными по отношению к центральному агрегатору (см. Рисунок 3).

Внедрение решения DAM как средства защиты важных данных в корпоративных информационных системах позволит существенно снизить риск утечки этих данных в самом ядре их хранения (в базах данных), а также — риск нарушения целостности данных и самих систем, информировать о возникающих подозрительных ситуациях, блокировать их и, в конечном счете, повысить непрерывность и безопасность бизнес-процессов в компании.

Валерий Смирнов — независимый эксперт. С ним можно связаться по адресу: vs5smirnov@gmail.com.

Рисунок 1. Межсетевой экран для приложений Web.

Таблица 1. Сравнение DLP и DAM-решений.

Рисунок 2. Варианты включения решения DAM в инфраструктуру.

Рисунок 3. Масштабируемая архитектура DAM-решения Guardium.

Внутренние угрозы

По оценкам исследовательской компании Forrester, более 70% всех угроз базам данных исходит изнутри предприятия («Обзор рынка: безопасность БД», Noel Yuhanna, Forrester Research, февраль 2009). По данным некоммерческой организации Privacy Rights Clearinghouse, причиной приблизительно 64% потерь данных являются инциденты, случающиеся непосредственно на серверах СУБД и других серверах данных. Лишь около 26% потерь данных — результат утечек через переносные устройства или электронную почту (на долю последней приходится примерно 1%, а на переносные устройства — 25%).