Реализация программы по ведению журнала безопасности и мониторингу базы данных (часть 1)

Сертификация GIAC (GCIA) Gold

Автор: Джим Хорват (Jim Horwath), jim.horwath@rcn.com

Консультант: Родни Кодл (Rodney Caudle)

Аннотация

Многие компании в основном концентрируются на защите сетей и часто пренебрегают защитой наиболее важного и критического ресурса – баз данных. В результате этого получается нечто похожее на шоколадную конфету в твердой оболочке, хрупко выглядящей снаружи и уязвимой изнутри. Базы данных содержат наиболее ценные данные компании: информацию о покупателях и сотрудниках, финансовую отчетность, интеллектуальную собственность и другие важные сведения. Защита, ведение журнала и мониторинг баз данных должны быть неотъемлемой частью деятельности любого бизнеса. К сожалению, многие компании не уделяют должного внимания вышеупомянутым действиям и не в состоянии надежно защитить свои данные. В этой статье будет рассказано о реализации программы, целью которой является увеличение уровня защиты баз данных.

1. Введение

В настоящем документе рассказывается о реализации программы по ведению журнала безопасности и мониторингу базы данных для улучшения защиты корпоративной инфраструктуры. Базы данных внутри этой инфраструктуры занимают особое место из-за объема и непрерывного изменения хранимой в них информации, часто являющейся для компании наиболее ценным и жизненно важным ресурсом. К такой информации чаще всего относятся данные, касающиеся покупателей, сотрудников и деловых партнеров. Часто подобная информация подпадает под федеральное и индустриальное регулирование, что означает наложение денежного штрафа или потерю репутации в случае получения доступа к этой информации со стороны посторонних лиц. Все это может привести к полному уничтожению компании. В основе реализации программы по ведению журнала безопасности и мониторингу базы данных лежит треугольник из трех сущностей: процессы и процедуры, компенсирующие элементы контроля и образование. Это не какое-то чудодейственное средство, которое, будучи реализованным однажды, удовлетворит все потребности бизнеса. Для реализации успешной программы необходима совокупность всех составляющих треугольника. Если одна составляющая упущена (процессы и процедуры, компенсирующие элементы контроля и образование) – реализованная программа может не решить возложенную на нее задачу по надежной защите информации.

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

Попытка охватить все существующие уязвимости – дело, конечно, хорошее, однако может привести к тому, что указанные ранее цели достигнуты не будут. В этой статье основной упор будет сделан на рассмотрении наиболее распространенных уязвимостей и угроз безопасности баз данных, защита от которых поможет компаниям защитить конфиденциальные данные. Политика безопасности очень важна при реализации любой программы по обеспечению безопасности. Если компания не имеет представления об объекте защиты, то не может эффективно его защитить. В качестве примера в настоящем документе будет рассматриваться SQL Server из-за его популярности среди компаний. Основной упор будет сделан на рассмотрении наиболее распространенных угроз безопасности и использовании комбинации коммерческих инструментов, стратегий и конфигураций для защиты базы от угроз безопасности. Даже если сконцентрироваться на защите от наиболее распространенных уязвимостей и угроз, безопасность баз данных существенно возрастет. Коммерческие инструменты рассматриваются в таком ракурсе, чтобы концепцию можно применить к любому другому инструменту, представленному на рынке.

Эта статья была бы не полной, если бы не рассматривались вопросы ведения журнала и мониторинга баз данных. Материалы статьи помогут вам принять решение о том, какие методы подходят наилучшим образом для решения проблем и удовлетворения нужд бизнеса. Также обсуждаются вопросы шифрования баз данных, поскольку многие разработчики считают это «золотой пулей» при решении проблем. Данная область довольно сложна и требует глубокого знания предметной области перед реализацией подобных решений. В конце статьи приводятся несколько конкретных случаев наличия наиболее распространенных уязвимостей в базах данных и реализованных компенсирующих методов контроля для удовлетворения нужд бизнеса (Ottman, 2010, см. Раздел Ссылки).

2. Список наиболее распространенных уязвимостей в базах данных

В настоящем документе основное внимание будет уделено наиболее распространенным уязвимостям. В Интернете существует множество списков уязвимостей баз данных; список, показанный в этой статье, - кажется, хорошая смесь из популярных уязвимостей, найденных в ходе исследования. Цельная программа по ведению журнала безопасности и мониторинга баз данных затрагивает наиболее распространенные уязвимости и использует их как факторы, возникающие во время бизнес-процессов. Решение наиболее распространенных проблем баз данных поможет защитить конфиденциальные данные и организацию от наиболее распространенных уязвимостей. Как только в рабочей среде будут реализованы меры по защите от подобных уязвимостей, существенно возрастет уровень безопасности всей рабочей среды. В этом разделе показан список наиболее распространенных уязвимостей вместе с потенциальным риском, который они несут для компании. Незнание того, что, отчего и как необходимо защищать – прямой путь к провалу. Список наиболее распространенных уязвимостей баз данных показан ниже (Shulman, 2006, см. Раздел Ссылки).

Наиболее распространенные угрозы безопасности баз данных

• Злоупотребление чрезмерными привилегиями доступа (Excessive Privilege Abuse)
• Злоупотребление легитимными привилегиями доступа (Legitimate Privilege Abuse)
• Превышение привилегий доступа (Privilege Elevation)
• Внедрение SQL-кода (SQL Injection)
• Слабый аудит (Weak Audit Trail)
• DOS-атаки
• Уязвимости коммуникационных протоколов баз данных (Database Communication Protocol Vulnerabilities)
• Слабая аутентификация
• Незащищенность резервных копий (Backup Data Exposure)

2.1 Злоупотребление чрезмерными привилегиями доступа (Excessive Privilege Abuse)

Один из принципов безопасности – принцип наименее необходимых привилегий; у пользователей должны быть лишь те привилегии, которые необходимы им для работы. Наделение пользователя привилегиями сверх необходимости – распространенная практика и может привести к злоупотреблению расширенными полномочиями. К примеру, помощник по административным вопросам может нуждаться в привилегиях для проверки платежей от покупателей или деловых партнеров. Однако если у него/нее есть привилегии по утверждению и создания платежей, то тут появляется возможность для злоупотребления привилегиями, поскольку у помощника есть полномочия, выходящие за рамки его обязанностей. Часто пользователи баз данных состоят в группе с максимально расширенными привилегиями. Это приводит к тому, что некоторых пользователей есть привилегии сверх того, что необходимо им в повседневной работе. Наделение пользователей только теми привилегиями, которые им нужны, и обнаружение расширенных привилегий может занять определенное время, однако увеличит уровень безопасности компании (Ottman, 2010, см. Раздел Ссылки).

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

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

2.2 Злоупотребление легитимными привилегиями доступа

Вторая форма злоупотребления привилегиями доступа относится к пользователям, которым вполне законно требуются расширенные привилегии для выполнения задач, однако эти пользователи злоупотребляют своими привилегиями для несанкционированных действий. Служебные обязанности персонала по администрированию инфраструктуры зависят от расширенных полномочий, необходимых для выполнения работы. Кроме того, персоналу, работающему с приложениями и конфиденциальной информацией, требуются особые привилегии доступа. Сотрудники, находящиеся на высоких руководящих позициях в компании, могут злоупотреблять своими полномочиями для несанкционированного доступа к данным или совершать деяния, выходящие далеко за рамки их ежедневных рабочих обязанностей. Пример: использование привилегированных или служебных учетных записей для выполнения определенных служебных обязанностей. Использование учетных записей с высокими привилегиями для выполнения ежедневных задач приводит к появлению дополнительных уязвимостей, что очень критично в случае работы с конфиденциальными данными. Существует дополнительная проблема выявления инициатора события, связанная с использованием служебных учетных записей отдельно взятым лицом. Если есть сотрудник, просматривающий персональные данные счетов высокопоставленных лиц, - важно знать, кто обращается к этим данным и почему. Если пользователь, работающий под привилегированной учетной записью, становится жертвой вредоносной программы, злоумышленник легко и быстро может получить доступ к конфиденциальным данным и защищенным областям, минуя системы безопасности. Мониторинг и отчетность по злоупотреблениям привилегиями – непростая задача, однако это должно быть неотъемлемой частью любой программы, направленной на повышение уровня безопасности баз данных (Ottman, 2010, см. Раздел Ссылки).

2.3 Превышение привилегий доступа

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

Для корпорации эксплоиты представляют собой угрозу, зависимую от времени. Компания должна внедрить компенсирующие элементы контроля до тех пор, пока не будет установлено исправление, защищающее от эксплоита, или изменена конфигурация. Установка исправления в рабочую среду – часто очень длительный процесс, который необходимо согласовывать с владельцами бизнеса. Простои из-за исправления и тестирования критических бизнес-циклов может привести к потере прибыли; и, наоборот, оставление уязвимости может привести к потере данных и репутации или перебоях в работе. Это классический случай, когда группа службы безопасности или группа управления рисками, после тщательного анализа всех за и против, выносит рекомендации по дальнейшим действиям. Сотрудникам службы безопасности следует отслеживать появление новых бюллетеней по безопасности (например, в SANS Internet Storm Center) и мониторить журналы на предмет появления признаков превышения привилегий. Если существуют бюллетени по безопасности для вертикального рынка (финансы, торговля, охрана правопорядка), сотрудникам службы безопасности следует подписаться и отслеживать их (Ottman, 2010).

2.4 Внедрение SQL-кода (SQL Injection)

Внедрение SQL-кода старо как мир, однако остается наиболее распространенным видом атак, совершаемых злоумышленниками для эксплуатации веб-приложений. Во втором квартале 2012 количество подобных атак возросло на 69%. По статистике сегодня SQL-инъекции популярны также как и несколько лет назад (Ashford, 2012, см. Раздел Ссылки). SQL-инъекция позволяет злоумышленнику влиять на SQL-выражение, которое некорректно обрабатывается входным фильтром, и выполняется внутри приложения к базе данных. Когда атакующий использует SQL-инъекцию, он пытается использовать синтаксис и возможности языка SQL для эксплуатации уязвимостей с целью получения доступа к базе данных и хранимой в ней информации. Внедрение SQL-кода становится возможным из-за плохой фильтрации входных данных, вводимых пользователем и использование непреднамеренной интерпретации метасимволов базой данных. Наиболее распространенные цели при SQL-инъекции – сохраненные процедуры и входные параметры. Внедрение SQL-кода позволяет злоумышленнику получить несанкционированный (и во многих случаях неограниченный) доступ к базе данных. Используя SQL-инъекцию, атакующий может украсть, порушить или модифицировать данные, находящиеся в базе данных. Возможность совершения SQL-инъекции – результат либо плохо спроектированного приложения, либо плохой работы команды администраторов баз данных. Приложения могут быть защищены от риска, связанного с использованием SQL-инъекции, путем качественной фильтрации входных параметров и реализации хорошо продуманного SDLC (Software Development Life Cycle, Жизненный Цикл Разработки Приложения) (Clarke, 2009, см. Раздел Ссылки).

Основные последствия от использования SQL-инъекции – нарушения конфиденциальности, авторизации и целостности информации. SQL-инъекция может нарушить конфиденциальность данных, поскольку информация, хранящаяся в базе, как правило, конфиденциальна. SQL-инъекция может стать причиной проблем с авторизацией, если SQL-выражения уязвимы к SQL-инъекциям при авторизации пользователей. Злоумышленник может работать от имени пользователя, не зная его пароля. SQL-инъекция ставит под угрозу целостность данных. Многие SQL-атаки позволяют несанкционированную манипуляцию информацией (OWASP, 2012, см. Раздел Ссылки).

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

2.5 Слабый аудит

В базе данных хранится конфиденциальная информация, и аудит критичных, нестандартных и привилегированных транзакций должен быть критически важным компонентом любой среды. Отсутствие надежного аудита – серьезная угроза для любой организации. Стоимость обработки каждой взломанной записи примерно 200$ (McKendrick n.d., см. Раздел Ссылки). В случае нарушения конфиденциальности данных возможность нахождения той информации, которая попала в руки злоумышленников, может сэкономить компании миллионы долларов и поможет предотвратить потерю бренда и репутации. Отсутствие аудита данных может поставить под угрозу соответствие программ правительственным нормативным требованиям. Механизм аудита должен отлеживать пользователей, выполняемые запросы и ответы на эти запросы. Во время жизненного цикла разработки программного обеспечения, компания следует установить конфиденциальные данные, транзакции и привилегированные учетные записи. Журналы аудита могут быть последним рубежом защиты в случае, если злоумышленник может обойти другие элементы контроля. Хотя журналы аудита не смогут предотвратить саму атаку, они являются критическим элементом во время расследования инцидентов. К тому же, журналы аудита могут помочь в разрешение сложных проблем, когда необходима более детальная отладка приложения (Shulman, 2006, см. Раздел Ссылки).

2.6 DOS-атаки

DOS-атаки (или атаки, связанные с отказом в обслуживании), которые, кажется, всегда будут в моде, - стары как мир и остаются серьезной угрозой для компании. Цель подобных атак – сделать так, чтобы сервер или целая сеть были недоступны другим пользователям. DOS-атаки могут возникать на разных уровнях (например, на уровне сети, приложения, базы данных и операционной системы). В случае с базами данных DOS-атаки, к примеру, могут быть связаны с нарушением работы служб, повреждением данных или тратой ресурсов (дисковая память, процессор или сетевые порты). Многие DOS-атаки связаны с наличием уязвимостей в операционной системе или протоколе, который использует приложение. Существует много причин для реализации подобных атак: вымогательство, порча репутации, завоевание авторитета, соревнование или форма досуга. Вне зависимости от намерений злоумышленника угроза DOS-атаки вполне серьезна, полностью избавиться от которой вряд ли возможно в ближайшем будущем. DOS-атаки могут возникать и по вине сотрудников организации, когда происходит нарушения работы службы из-за ошибок в настройках. К примеру, если из-за ошибки администратора количество допустимых соединений мало, и некоторые пользователи не смогут получить доступ к базе данных. Успешная DOS-атака может повлиять на уровень прибыли и репутацию компании. Если DOS-атака происходит внутри жизненно важного бизнес-цикла, это может привести к разорению компании (Shulman, 2006, см. Раздел Ссылки).

2.7 Уязвимости коммуникационных протоколов баз данных

Одна из причин для беспокойства – рост количества уязвимостей в коммуникационных протоколах баз данных. Одна из наиболее знаменитых атак: червь SQL Slammer. SQL Slammer использует уязвимость в протоколе SQL Server, в результате чего служба перестает работать. Подобные атаки вызывают много хлопот, поскольку не отражены в журналах аудита, привязанных к базам данных. Подобные журналы не отражают операции, связанные с протоколами. Механизм отслеживания атак, связанных с протоколами, может быть весьма мудреным и часто требует мониторинга процессов, напрямую не связанных с базами данных. Ни один поставщик не застрахован от наличия уязвимостей в коммуникационных протоколах. Само же исправление этих уязвимостей может быть весьма затруднительным из-за возможных остановок деятельности бизнеса для тестирования и установки патчей. Такие атаки очень опасны, так как могут обходить отдельные уровни защиты и оставаться незамеченными (Shulman, 2006).

2.8 Слабая аутентификация / Подбор пароля

Многие компании реализуют сложные и эффективные механизмы безопасности для защиты среды вокруг базы данных и при этом не уделяют должного внимания механизмам аутентификации баз данных. Там где пароль – единственные элемент, защищающий данные, - уровень безопасности информации зависит от длины пароля. Случаев, когда рабочие учетные записи содержат стандартные или слабые пароли, легко избежать. Существует несколько распространенных способов для получения учетных записей для доступа к базе данных. Во-первых, злоумышленник может осуществить простой брутфорс в надежде на подбор наиболее распространенных комбинаций. При этом обычно используются инструменты для автоматизации и ускорения процесса (например, радужные таблицы). Во-вторых, пользователи часто оставляют логины и пароли в местах, доступных третьим лицам (например, на своих рабочих местах). Это позволяет злоумышленнику заполучить учетные записи без каких-либо серьезных телодвижений. К тому же, администраторы создают скрипты для автоматизации рутинных задач. Подобные скрипты содержат пароли или конфигурационные файлы, которые выявляются в таблице процессов во время запуска скрипта. Другой вариант: пароли содержатся в файлах с недостаточным уровнем защищенности. Социальная инженерия – распространенная техника, направленная на подбор пароля, часто – весьма успешна. Здесь упор делается на знания человеческой психологии. Классический случай: телефонный звонок от службы поддержки с просьбой сообщить информацию об учетной записи для устранения критической проблемы. Подобные атаки являются классическими, однако все равно крайне эффективны. И, наконец, есть масса примеров, когда от поставщика остаются привилегированные учетные записи со стандартными или вообще пустыми паролями. К примеру, SQL Server поставлялся с учетной записью «sa» и пустым паролем. В Интернете есть множество списков, которые содержат стандартные комбинации имя пользователя/пароль. В случае оставления стандартной учетной записи (например, «sa») вместе со слабым механизмом аутентификации злоумышленник может легко подключиться к базе данных и завладеть ей (Natan, 2006, см. Раздел Ссылки).

2.9 Незащищенность резервных копий

Многие компании забывают о критичности резервных копий до тех пор, пока не встает необходимость восстановления данных. Из-за того, что в базе данных хранится конфиденциальная информация, компаниям следует предпринять соответствующие шаги по защите резервных копий. Весьма распространено, но неразумно, оставление незащищенным и уязвимым к краже носителя резервных копий. В случае утери или кражи ленты с резервной копией, незашифрованные данные на носителе уязвимы. Если в компании заведено правило хранения резервных копий за пределами офиса и используется служба доставки, то нет никакого контроля над носителем или данными, когда они находятся в распоряжении перевозчика. Защита «данных в хранении» (data at rest) актуальна как для резервных копий, так и данных на серверах. Если конкурент смог получить доступ к набору резервных копий, компания может потерять интеллектуальную собственность и конфиденциальные данные, что ставит под угрозу ее существование. Следует разработать корпоративные правила по шифрованию конфиденциальных данных на носителя с резервными копиями и процесс внедрения этих правил (Shulman, 2006, см. Раздел Ссылки).

3. Разработка политики безопасности

Политика безопасности представляет собой набор правил для защиты компаний, сотрудников покупателей и информации. Разработка политики – критически важный шаг и часто упускается при разработке программы по обеспечению безопасности. Многие индустрии подпадают под действие федеральных, местных или отраслевых законов и правил. Подобные законы и правила будут регулировать операционную деятельность и деятельность, направленную на соблюдение требований, во многих организациях, а также являются критической точкой отсчета при разработке корпоративной политики. Инженерный персонал любит работать с технологиями, часто упуская из вида реализацию политики, которая должна сопровождать внедрение самой технологии. Политики могут существовать на самых разных уровнях в компании; существуют правила, законы, корпоративные политики, служебные политики, локальные политики, проблемно-ориентированные политики и процедуры. Политики и процедуры должны удовлетворять пяти требованиям: конкретность, измеряемость, достижимость, обоснованность и иметь четкие сроки. Политики отвечают на вопросы «кто?», «что?» и «почему?». Процедуры отвечают на вопросы «как?», «где?» и «когда?» (Northcutt, 2010, см. Раздел Ссылки).

Будут существовать технические ограничения, которые могут воспрепятствовать сбору критически важной информации; политика поможет нам реализовать компенсирующие элементы контроля и сбор критически важной информации будет возможен. Хороший пример: запрет на использование серверных инструментов, например, SQL Server Management Studio, напрямую на сервере. Конечно, могут возникать ситуации, когда прямой доступ необходим; подобные ситуации следует прописать в политике безопасности. Такие действия помогут собирать SQL-данные через сеть при помощи инструмента мониторинга баз данных и представлять соответствующие отчеты. RDP использует шифрование и представляет собой мертвую зону для утилит мониторинга баз данных.

Наличие политики безопасности поможет управлять бизнес-процессами, очертит объекты, нуждающиеся в защите, и заложит прочную основу для реализации компенсирующих элементов контроля. Успех программы по ведению журнала безопасности и мониторингу базы данных зависит от целей и имеющихся нормативов. Во-первых, понимание задач бизнеса, законов, правил и ресурсов, необходимых для защиты компании поможет разработать эффективную политику безопасности, а также базовые бизнес-процессы на основе все этой информации. Как упоминалось ранее, эта предварительная работа имеет критически важное значение, но часто упускается многими компаниями. Однако закладка фундамента не гарантирует успешности всей кампании, а только подготовит организацию к работе по построению успешной программы. Чтобы помочь вам в создании политики, в Приложении А представлен пример политики безопасности базы данных, где показан опыт использования лучших практик. Та политика, которая представлена в приложении, служит лишь примером и предметом дальнейших дискуссий (Ottman, 2010, см. Раздел Ссылки).

4. Методы мониторинга баз данных

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

4.1 Собственный аудит

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

Существуют дополнительные проблемы с логами собственного аудита, когда из-за падения производительности собственный аудит становится малопригодным для использования. Все дело в том, что в крупных масштабах использовать и контролировать собственный аудит весьма проблематично. Наконец, логи собственного аудита не предоставляют столь полезной информации, как логи сетевого мониторинга. Как следствие, отследить взаимосвязь между базой данных и остальной инфраструктурой очень трудоемко. Если по логам видно, что совершена сетевая атака, весьма трудно отследить ответ и содержимое запросов по логам собственного аудита. Во время расследования инцидента, информация об ответе на запрос может помочь определить масштабы взлома и объем финансовых обязательств компания за последствия взлома (Ottman, 2010). Если компания докажет нарушение конфиденциальности лишь определенного количества записей, то сможет более точно оценить финансовый ущерб от атаки. Как говорилось ранее, каждая взломанная записи будет оцениваться около 200$ (McKendrick, n.d., см. Раздел Ссылки).

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

Ссылки

Encryption Hierarchy. (n.d.). MSDN – Explore Windows, Web, Cloud, and Windows Phone Software Development. Retrieved July 1, 2012, from http://msdn.microsoft.com/en-us/library/ms189586%28v=sql.100%29

Ashford, W. (2012, July 26). SQL injection attacks rise sharply in second quarter of

2012. ComputerWeekly.com | Information Technology (IT) News, UK IT Jobs,

Industry News. Retrieved August 1, 2012, from http://www.computerweekly.com/news/2240160266/SQL-injection-attacks-risesharply-in-second-quarter-of-2012

Auditing Security Events Best practices: Auditing. (2005, January 25). Resources and Tools for IT Professionals | TechNet. Retrieved July 15, 2012, from http://technet.microsoft.com/en-us/library/cc778162%28v=ws.10%29.aspx

Auditing Security Events Best practices: Auditing. (2005, January 25). Resources and Tools for IT Professionals | TechNet. Retrieved July 15, 2012, from http://technet.microsoft.com/en-us/library/cc778162%28v=ws.10%29.aspx

B, D. (2012, March 14). â€oeThe SQL Guy†Post #20: Using Cell Level Encryption in SQL Server - Canadian IT Professionals - Site Home – TechNet Blogs. TechNet Blogs - TechNet Blogs. Retrieved July 1, 2012, from http://blogs.technet.com/b/canitpro/archive/2012/03/14/the-sql-guy-post-20-using-cell-level-encryption-in-sql-server.aspx

Chapman, T. (n.d.). Center for Internet Security :: Security Benchmarks Division :: CIS SQL Server 2005 Benchmark v2.0.0. Center for Internet Security :: Security Benchmarks Division :: Home. Retrieved June 27, 2012, from http://benchmarks.cisecurity.org/enus/?route=downloads.show.single.sql2005.200

Choose an Authentication Mode. (n.d.). MSDN. Retrieved May 20, 2012, from msdn.microsoft.com/en-us/library/ms144284.aspx

Clarke, J. (2009). SQL injection attacks and defense. Burlington, MA: Syngress Pub..

Cristofor, L. (2007, October 3). SQL Server 2008: Transparent data encryption feature - a quick overview - Laurentiu Cristofor's blog @microsoft.com – Site Home - MSDN Blogs. MSDN Blogs - MSDN Blogs. Retrieved July 2, 2012, from http://blogs.msdn.com/b/lcris/archive/2007/10/03/sql-server-2008-transparent-data-encryption-feature-a-quick-overview.aspx

Kerberos Explained. (n.d.). Resources and Tools for IT Professionals | TechNet. Retrieved July 15, 2012, from http://technet.microsoft.com/enus/library/bb742516.aspx

Kiely, D. (n.d.). Protect Sensitive Data Using Encryption in SQL Server 2005. SQL Encryption - Microsoft. Retrieved June 22, 2012, from download.microsoft.com/download/4/7/a/.../SQLEncryption.doc

McKendrick, J. (n.d.). Cost of a data breach: $194 per record | SmartPlanet. SmartPlanet- Innovative Ideas That Impact Your World. Retrieved June 8, 2012, from

http://www.smartplanet.com/blog/business-brains/cost-of-a-data-breach-194-perrecord/22913

McKendrick, J. (n.d.). Cost of a data breach: $194 per record | SmartPlanet. SmartPlanet

- Innovative Ideas That Impact Your World. Retrieved June 8, 2012, from http://www.smartplanet.com/blog/business-brains/cost-of-a-data-breach-194-per-record/22913

Northcutt, S. (2010). Management 404 - Fundamentals of Information Security Policy. Bethesda, Maryland: The SANS Institute.

SQL Injection Prevention Cheat Sheet. (2012, July 9). OWASP The Open Web Application Security Project. Retrieved September 1, 2012, from https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet

SQL Injecttion. (2012, July 8). OWASP The Open Web Application Security Project. Retrieved September 1, 2012, from https://www.owasp.org/index.php/SQL_Injection success, a., & category, f. e. (n.d.).

Auditing Security Events Best practices: Auditing. Resources and Tools for IT Professionals | TechNet. Retrieved July 15, 2012, from http://technet.microsoft.com/en-us/library/cc778162%28v=ws.10%29.aspx

Приложение А

Требования к ведению журнала и мониторингу базы данных от 20 мая 2012 года

Компания Х

Адрес

Город, Штат XXXX-XXXX

Корпоративная безопасность Компании Х

Политика: Ведение журнала и мониторинг базы данных

Требования к ведению журнала и мониторингу базы данных

Аудитоспособность относится к функциям приложения, при помощи которых осуществляется отслеживание активности. Аудит должен предоставлять достоверную информацию для расследования случаев несанкционированных действий, из-за которых возник инцидент в системе безопасности. Полученная информация позволит персоналу предпринять необходимые мероприятия по ликвидации инцидента. На данный момент в компании Х имеются общие стандарты и руководства для аудитоспособности приложения. Эти стандарты и руководства, относятся к ведению журналов, и их следует рассматривать как справочник для базовых требований по ведению журнала для баз данных. Более подробную информацию можно узнать в разделе 3.4 «Ведение журнала» в корпоративной политике компании.

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

Ведение журнала базы данных должно осуществляться по следующим видам деятельности:

• Добавление, изменение, приостановка действия и удаление учетных записей пользователей
• Изменение прав у учетных записей пользователей (права доступа учетной записи)
• Повышение привилегий
• Изменения владельца объектов
• Начало/окончание сеанса, неудачные попытки авторизации под учетными записями администратора (учетными записями администраторов баз данных), учетными записями приложений и учетными записями, используемыми для прямого доступа к базе
• Изменение паролей
• Изменение политики безопасности базы данных / изменение настроек
• i. Режимы аутентификации
• ii. Управление паролями
• iii. Запрет/разрешение удаленного доступа
• iv. Запрет/разрешение собственного аудита
• Изменение настоек системы аудита и попытки изменения или удаления логов аудита или логов баз данных
• Транзакции, связанные с конфиденциальными данными, на основе требований владельца данных
• Санкционированный доступ к конфиденциальным ресурсам, на основе требований владельца ресурсов
• Неудачные попытки доступа к конфиденциальным ресурсам, на основе требований владельца ресурсов
• Неудачное выполнение SQL-запросов (из-за отсутствия объекта или недостаточности привилегий)
• Внесение изменений в схему базы данных (Команды DDL (Data Definition Language, язык описания данных))
• Создание/восстановление резервных копий
• Запуск/остановка базы данных
• Попытки использования средств операционной системе через базу данных (выполнение команд, чтение/изменение файлов и настроек)
• В журнале должно быть достаточно информации для того, чтобы была возможность выяснить, какие произошли события, и кто был их инициатором:
• i. Тип события
• ii. Когда произошло событие
• iii. Учетная запись, связанная с событием
• iv. Программа или команда, ставшая инициатором события (точное SQL-выражение)
• v. Имена таблиц, к которым осуществлялся доступ (если возможно)
• vi. Имя хоста или IP-адрес, с которого произошло соединение пользователя
• vii. Статус попытки (успех/неудача)

Команды, зависимые от платформы:

• ORACLE: команды прослушивателя журнала (log listener): SERVICE, STATUS, VERSION, STOP
• MS SQL: команды DBCC

Мониторинг должен сработать при наступлении следующих событий:

• Несогласованные добавления и изменения учетных записей пользователей
• Случаи многократных неудачных попыток ввода паролей по множеству учетных записей за короткий промежуток времени (что может свидетельствовать о реализации хакерских намерений)
• Случаи попыток неудачного доступа к базе данных от имени учетной записи, у которой нет прав доступа
• Попытки получить список пользователей и паролей
• Все попытки прямого доступа к базе данных от имени учетных записей, доступ которым разрешен только из приложения
• Использование нестандартных утилит (например, Excel, Access) для прямого доступа к СУБД
• Использование «служебных программ» (например, Toad) для прямого доступа к СУБД
• Использование Application ID (ApplID) из источника отличного от того, который закреплен за владельцем приложения (на основе имени хоста или IP-адреса)
• Неудачные входы в систему, попытки остановить ведение журнала и уничтожить логи
• Попытки доступа к средствам ОС через базу данных
• Обнаружение известных видов атак (например, переполнение буфера, отказ в обслуживании, SQL-инъекция)

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

Продолжение следует ...