Создание успешной стратегии аудита для ваших баз данных SQL Server

1. Важность аудита
2. Стратегия аудита
3. Что проводить аудит
4. Аудит вашей аудиторской реализации
5. Выборочный аудит
6. Архивирование аудиторской информации
7. Функции SQL Server, доступные для облегчения аудита безопасности
8. С2 Аудит
9. Общие критерии соответствия
10. Аудит SQL Server
11. Трассировка SQL
12. Расширенные события
13. Изменить захват данных
14. DML, DDL и триггеры входа в систему
15. Заключение
16. Рекомендации

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

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

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

Важность аудита

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

Правительство и другие регулирующие органы конкретных отраслей промышленности предписали требования, которые должны соблюдаться, чтобы считаться соответствующими требованиям или избегать штрафов и других наказаний, таких как PCI, HIPAA, SOX и т. Д. В некоторых случаях единственные правила могут быть навязанными самим бизнесом.

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

Наличие аудита на месте позволяет проводить судебный анализ после выявления инцидента. Это, в свою очередь, позволит вам принять соответствующие контрмеры и привлечь сотрудников к ответственности за свои действия.

Стратегия аудита

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

• Переизбыток данных, что затруднит выявление проблем.
• Требуется большое количество места для хранения.
• Влияет на производительность отрицательно.

Перед внедрением каких-либо аудиторских решений необходимо учитывать следующее:

1. Что вы юридически обязаны для аудита?
2. Как долго вы по закону обязаны хранить данные аудита?
3. Сколько места для хранения у вас есть?
4. Какова цель проверенных данных, это просто для соответствия, или кто-то будет активно просматривать накопленные данные для выявления уязвимостей?
5. Насколько критично, что одитинг происходит?

Что проводить аудит

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

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

• Данные, которые могут быть использованы для идентификации личности, такие как номер паспорта или номер социального страхования.
• Данные, которые предоставляют личную информацию о человеке, такую ​​как его волосы и цвет глаз или даже что-то столь же простое как тип фильмов, которые он любит смотреть.
• Данные, которые можно считать конфиденциальными. Это в основном относится к информации, которая может негативно или в некоторых случаях благоприятно повлиять на тех, кто занимается, если она попадет в чужие руки. Обычно это включает в себя такую ​​информацию, как медицинская карта человека или финансовую информацию, такую ​​как финансовая информация, относящаяся к компании или лицу.

С точки зрения базы данных, это действия, которые следует учитывать для аудита:

• Logons
• конфигурация
• Конфигурация аудита
• Модификация схемы
• Модификации данных

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

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

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

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

Аудит вашей аудиторской реализации

Администраторы БД нередко отключают аудит, если сервер неожиданно начинает работать плохо.

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

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

Выборочный аудит

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

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

Архивирование аудиторской информации

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

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

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

Функции SQL Server, доступные для облегчения аудита безопасности

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

С2 Аудит

SQL Server предлагает аудит C2 начиная с SQL Server 2000, чтобы классифицировать его в соответствии с критериями аудита C2, предписанными Министерством обороны.

Аудиторские события включают в себя выполнение хранимых процедур, создание или удаление объектов, а также действия по входу и выходу пользователя из системы. В случае аудита C2 невозможно выбрать, что проверять. Это в основном проверяет все или ничего.

Данные аудита C2 сохраняются в файле журнала в каталоге MSSQL \ DATA. Размер каждого файла ограничен 200 МБ, и каждый раз при достижении предела создается новый файл, пока в каталоге не останется свободного места или аудит не будет отключен.

Включить аудит C2 вы можете

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

Когда это происходит, есть только 2 решения проблемы.

1. Вам нужно освободить место на сервере, чтобы аудит мог продолжаться до перезапуска сервера или
2. Вам нужно перезапустить SQL Server с флагом -f, чтобы обойти аудит.

Аудит C2 будет объявлен устаревшим в следующей версии и будет заменен Общим критерием соответствия.

Общие критерии соответствия

Соответствие общим критериям было введено в SQL Server 2005 с пакетом обновления 1 (SP1), но, к сожалению, доступно только в выпусках SQL Server для предприятий, разработки и оценки.

Группа наций разработала общие критерии соответствия для достижения следующего:

• Повышение доступности защищенных ИТ-продуктов
• Чтобы помочь пользователям оценить ИТ-продукты
• Повысить доверие потребителей к безопасности ИТ-продуктов.

Международный орган, признанный Международной организацией по стандартизации (ISO), отвечает за поддержание общих критериев соответствия.

Когда вы включите общие опции, включающие соответствие, вот что произойдет:

• Защита остаточной информации будет иметь место. Это означает, что выделения памяти будут перезаписаны с помощью известного шаблона битов, прежде чем он будет выделен новому ресурсу.
• Логины будут проверены. Это включает в себя успешные и неудачные входы.
• Таблица DENY будет иметь приоритет над уровнем столбца GRANT.

Чтобы включить опцию включения общих критериев, вы можете

Аудит SQL Server

Аудит SQL Server впервые был выпущен в SQL Server 2008 как функция только для предприятий. В SQL Server 2012 аудит уровня сервера теперь также доступен для пользователей Standard Edition.

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

Для использования аудита SQL можно настроить 3 компонента:

• Аудит сервера (обязательно)
  Аудит сервера находится в базе данных master и используется для определения того, где будет храниться информация аудита, должен ли аудит быть синхронным или асинхронным, как должны обрабатываться файлы и что происходит, если событие аудита не может быть зарегистрировано.
  Это доступно для всех выпусков SQL Server начиная с 2012 года.
• Спецификация аудита сервера (необязательно)
  Это где события уровня сервера могут быть проверены. Чтобы создать спецификацию аудита сервера, сначала необходимо создать аудит сервера. Спецификация аудита зависит от аудита сервера, и может быть только одна спецификация аудита сервера на аудит сервера. Спецификации аудита сервера позволяют проверять такие вещи, как успешный вход на сервер, действия DBCC и т. Д.
  Это также доступно во всех выпусках SQL Server начиная с 2012 года.
• Спецификация аудита базы данных (необязательно)
  Спецификация аудита базы данных также зависит от аудита сервера. Это позволяет проводить более детальный аудит в базе данных, включая действия, выполняемые с конкретными объектами, например, какой пользователь выполнил выборку на определенной таблице. Несколько спецификаций аудита базы данных могут быть связаны с одним аудитом сервера.

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

SELECT * FROM fn_get_audit_file ('D: \ Audits \ *', по умолчанию, по умолчанию)

Трассировка SQL

В настоящее время SQL Trace по-прежнему является предпочтительным методом для проведения аудита на SQL Server, он существует с SQL 2000, и большинство администраторов баз данных знакомы с ним или, по крайней мере, с использованием Profiler.

В трассировке SQL используется набор или хранимые процедуры, которые записывают события, которые были определены в определении трассировки. Трассировки легко настраиваются и могут обеспечить очень мелкозернистый аудит.

SQL Server предоставляет Profiler в качестве внешнего интерфейса для SQL Trace, что позволяет легко создавать трассировки и запускать их. К сожалению, профилировщик имеет некоторые потери производительности, и поэтому не всегда хорошая идея запускать его на вашем производственном сервере.

Если вам нужно запустить трассировку на вашем производственном сервере, сделайте это с помощью инструкций Transact-SQL для управления и запуска трассировок. Ниже приведены процедуры, которые можно использовать для создания и чтения информации трассировки:

• sp_trace_create
  Эта процедура используется для создания определения трассировки. Здесь также можно указать параметры трассировки, такие как перенос файлов или отключение сервера, а также расположение файлов трассировки.
• sp_trace_setevent
  Эта процедура используется для определения того, какие события трассировки вы хотите записать и какие столбцы каждого события записать.
• sp_trace_setstatus
  Поскольку все трассы создаются в остановленном состоянии, эта процедура необходима для запуска трассировки, а затем ее остановки. Это может также использоваться, чтобы удалить след полностью.

Следует отметить, что следы не являются постоянными. Если ваш экземпляр будет перезапущен, трассировка не будет автоматически воссоздана.

Трассировка SQL будет объявлена ​​устаревшей в будущих версиях SQL Server и будет заменена расширенными событиями.

Расширенные события

Расширенные события были введены в SQL 2008, это настраиваемая среда событий, которая в конечном итоге заменит SQL Trace. В SQL 2008 события, доступные в расширенном обработчике событий, были ограничены, но в SQL Server 2012 все события, которые были доступны в SQL Trace, теперь также доступны в расширенных событиях.

Механизм расширенных событий имеет очень низкую производительность, что делает его предпочтительным по сравнению с SQL Trace. Движок управляет только пакетами, которые содержат информацию о событии, что делает его чрезвычайно гибким. Также возможно соотнести дату между приложениями, сервером SQL и Windows, используя расширенные события.

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



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

В качестве альтернативы вы можете использовать Transact-SQL для создания трассировок. Ниже приведены три основные команды для создания и управления расширенными сеансами событий:

• СОЗДАТЬ СОБЫТИЕ
  Эта команда создает и сеанс событий и позволяет указать события, действия и цели, которые должны быть связаны с сеансом. Вы можете увидеть доступные события, действия и цели, выбрав из sys.dm_ xe_objects типы объектов события, действия и цели соответственно.
• ПОСЛЕДНИЕ СОБЫТИЯ
  Эта команда используется для изменения конфигурации сеансов событий и для запуска или остановки сеанса событий.
• СОБЫТЬ СОБЫТИЕ
  Эта команда используется для удаления сеанса события, когда он больше не требуется.

Изменить захват данных

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

Эта функция собирает журнал транзакций SQL Server как часть процесса sp_replcmds для внесения изменений в данные таблиц, для которых он был включен. CDC зависит от агента SQL Server, который должен работать постоянно, чтобы обеспечить сбор данных. При реализации CDC создаются два задания: одно используется для сбора данных и заполнения соответствующих таблиц, а другое - для очистки.

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

Следующие команды могут использоваться для реализации CDC:

• sys.sp_cdc_enable_db
  Эта команда включает CDC для использования в конкретной базе данных и требуется, прежде чем любые таблицы могут быть включены для CDC
• sys.sp_cdc_enable_table
  Эта команда включает CDC для определенной таблицы. Это создает связанный экземпляр захвата таблицы, включая таблицу изменений и функции запросов. Первые 5 столбцов в таблице изменений содержат метаданные, которые будут использоваться процессом CDC, а остальные столбцы основаны на столбцах в исходной таблице, которые должны быть получены.

DML, DDL и триггеры входа в систему

Триггеры могут быть использованы для входа в систему или изменения объектов и данных в вашей базе данных.

Триггеры DML срабатывают в ответ на операторы INSERT, UPDATE и DELETE, а триггеры DDL срабатывают в ответ на изменения, внесенные в определение данных, такие как CREATE, DROP, ALTER и т. Д. Триггеры входа в систему запускаются каждый раз, когда пользователь входит в SQL Server, который можно использовать. провести аудит доступа к вашему серверу. К сожалению, триггер не срабатывает, если пользователь не аутентифицирован, и поэтому будет полезен только для аудита успешных входов в систему.

Чтобы использовать триггеры DML для аудита изменений данных, необходимо добавить триггеры в каждую таблицу, которую вы хотите проверять. Это может быть обременительно и трудно поддерживать. Приложения, разработанные на SQL Server, часто используют триггеры DML для внутреннего аудита.

Таким же образом могут быть реализованы триггеры DDL для записи любых изменений в объектах базы данных. Триггеры DDL создаются на уровне базы данных или сервера и запускаются при возникновении специально настроенного события.

Следующие инструкции Transact-SQL могут использоваться для создания или поддержки триггеров DML или DDL:

• СОЗДАТЬ ТРИГГЕР
  Этот оператор может быть использован для создания DML, DDL или триггера входа в систему. При создании триггера DDL необходимо указать область действия триггера: ON ALL SERVER или ON DATABASE.
• ENABLE / DISABLE TRIGGER
  Триггеры включены по умолчанию при создании. Эти команды помогают отключить триггер, не удаляя его из базы данных, а затем повторно включить его позже. Вы также можете отключить триггеры DML с помощью команды ALTER TABLE.

Заключение

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

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

Благодаря множеству функций, предоставляемых SQL Server, которые помогут вам реализовать совершенную стратегию аудита, защита конфиденциальных данных вашего бизнеса и ваших клиентов стала еще проще. Хотя некоторые функции, такие как SQL Audit, все еще довольно молоды и еще не полностью разработаны, правильная комбинация функций поможет вам преодолеть соответствие требованиям, производительности, требованиям к хранилищу и безопасности.

Рекомендации

Узнать больше

Для аудита базы данных SQL и действий по безопасности рассмотрите Аудит ApexSQL инструмент аудита SQL Server уровня предприятия.






Минетт Стейнберг

Минетт Стейнберг имеет более чем 15-летний опыт работы с данными в различных ИТ-ролях, включая разработчика SQL и администратора баз данных SQL Server. Минетт любит быть активным членом сообщества SQL Server, когда пишет статьи и время от времени общается в группах пользователей SQL.
В настоящее время Minette работает архитектором Data Platform Solution в Microsoft в Южной Африке.
Посмотреть все сообщения от Минетт Стейнберг

Последние сообщения от Минетт Стейнберг ( увидеть все )

Похожие

Комментарии