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

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

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

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

Предыдущие части статьи:

Часть 1

4.2 Использование централизованных агентов

При покупке базы данных обычно поставщик предлагает два решения для мониторинга: централизованные (host-based) агенты и сетевой мониторинг. Агенты баз находятся на сервере и мониторят память и таблицы транзакций SQL. Некоторым агентам требуются отдельные функции собственного аудита, так что они могут получать данные аудита. Как говорилось ранее, включение некоторых или всех функций собственного аудита ухудшает производительность базы данных.

Агенты – программы, установленные на севере базы данных, которые запускаются в привилегированном режиме как служба или демон (в зависимости от платформы). У агентов обычно есть хуки внутри ядра, что позволяет им перехватывать SQL-трафик и пересылать его в программу мониторинга. Поскольку агенты работают на сервере базы, они могут фиксировать все действия, совершаемые с базой, включая деятельность со стороны пользователей, которые подключены напрямую к серверу. Большинству агентов необходимо установить правила, в которых отражены объекты, необходимые для отслеживания, что позволяет производить гибкую настройку политик, соответствующих нуждам бизнеса.

Решения для сетевого мониторинга могут сообщать только об активности, исходящей из сети. К тому же, если коммуникация происходит через зашифрованный канал, и у программы мониторинга нет секретного ключа, она не сможет расшифровать трафик и, соответственно, отследить активность. Централизованные же агенты могут отслеживать все процессы, происходящие в базе данных, поскольку являются резидентными программами, запущенными на сервере. На первых взгляд, кажется, что централизованные агенты – идеальное решение, однако и у них есть некоторые недостатки. Так как подобные агенты работают в привилегированном режиме и взаимодействуют напрямую с ресурсами ядра, из-за возможного наличия в агентах уязвимостей возникает дополнительный риск для сервера. Если у программы, запущенной в привилегированном режиме, имеются логические ошибки или ошибки в коде, работа сервера может быть нарушена при помощи DOS-атаки от приложения, защищающего ресурс. Звучит немного иронично. Централизованные агенты позволяют закрывать соединения, имеющие вредоносную природу, функционируя как централизованная IPS-система (Intrusion Prevention System, система предотвращения вторжений) для баз данных. Хотя возможность остановки вредоносного трафика, на первый взгляд, может казаться привлекательной, также существует вероятность закрытия легитимных соединений и превращение базы в систему, действующую против интересов бизнеса.

Логи, сгенерированные централизованным агентом, уступают по ценности логам сетевого мониторинга из-за отсутствия в них ответов на запросы. Такая информация плохо организована, поскольку все записи находятся в одном месте и могут быть трудны для восприятия. Главная проблема у агентов баз данных – требуется непрерывная их профилактика. Поскольку агенты завязаны на ядро и версию базы, изменения версии базы или операционной системы может потребовать и обновление агента. Если инфраструктура баз данных большая – может потребоваться много времени на обновление агентов на каждом сервере. Хотя некоторые решения позволяют обновлять агентов централизованно, однако для этого необходимо иметь расширенные привилегии на сервере из другого ресурса, что вносит дополнительный риск, поскольку добавляются дополнительные точки доступа к серверу базы данных. Команда администраторов может не согласиться с тем, что со стороннего ресурса можно получить доступ к базе с расширенными привилегиями. Обязанности по поддержки агента базы могут быть разделены на три группы, у каждой из которых свои компетенции и уровень ответственности. Группы, отвечающие за сервера, будут ответственны за поддержку, обновление и администрирование операционной системы. Администраторы базы данных будут ответственны за поддержку, обновление и администрирование программного обеспечения, связанного с базой. Группа безопасности будет ответственна за соответствие версии агента релизу операционной системы, разрядности ОС (32 или 64 бита), а также версии платформы базы данных. При таком разделении обязанностей необходимо более четкое взаимодействие и слаженность между командами. Если, к примеру, версия операционной системы или базы данных конфликтует с версией агента, то в лучшем случае сам агент может работать не корректно или, что еще хуже, могут возникнуть проблемы со стабильностью работы службы базы данных. Также агенты будут больше нагружать сервер, хотя эта нагрузка значительно меньше, чем при использовании собственного аудита. Если с сервером или базой данных возникают проблемы, агенты базы данных будут первыми подозреваемыми. Если ваш бизнес нуждается в использовании подобных агентов, критически важно провести стресс-тестирование и проверку на совместимость с используемыми технологиями.

4.3 Сетевой мониторинг

Мониторингу базы данных из сети (короткое название: DAM, Database Activity Monitoring) уже около десяти лет. Подобное решение позволяет корпорациям улучшить анализ трафика базы данных без создания дополнительной нагрузки на сервер. Для сетевого мониторинга необходимо использовать либо специальное оборудование, либо функцию SPAN (Switched Port Analyzer, анализатор коммутируемых портов) на коммутаторе. При использовании SPAN происходит отзеркаливание всего трафика на определенный порт, который затем можно проанализировать. Для сетевого мониторинга также можно использовать специальные устройства (например, от компании Gigamon), которые позволяют агрегировать, коммутировать, реплицировать и фильтровать сетевой трафик. Такой подход позволяет анализировать трафик без дополнительной нагрузки на сеть и влияния на работу пользователя. Существует множество преимуществ при использовании сетевого мониторинга. К примеру, мониторинг трафика позволяет находить новые (или злонамеренные) подключения к базе, что дает более тесную интеграцию с управлением корпоративными изменениями и политиками безопасности. Детектирование мошеннических соединений без использования сетевого мониторинга – довольно трудная задача. Весьма вероятно, что централизованный мониторинг с этой задачей не справится.

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

Большинство функций сетевого мониторинга могут выполняться в защищенном режиме, тем самым работая как IPS-система (Intrusion Protection System, система защиты от вторжений) для баз данных, хотя это довольно рискованно. Все дело в том, что в такой системе может сработать защитный механизм при обнаружении подозрительной активности, а затем послана соответствующая команда на отключение клиента по протоколу TCP. Если в приложении есть ошибки в архитектуре, это может спровоцировать DOS-атаку против пользователей этого приложения и создать проблемы при движении по карьерной лестнице. Однако существует одна проблема, которая может ограничить мониторинг и ведение журнала безопасности базы данных. В случае подключения к серверу посредством протоколов SSH и RDP происходит шифрование трафика. В этом случае сетевой мониторинг бесполезен, поскольку нельзя проанализировать содержимое трафика, если отсутствует копия секретного ключа.

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

4.4 Краткие выводы

Существует три метода мониторинга, о которых упоминалось выше: собственный, централизованный и сетевой. Собственный аудит возможен без использования сторонних приложений, потерь производительности и дополнительных требований к ресурсам (процессор/диск). Объем информации, доступный в логах, оправдывает использование собственного аудита при реализации программы по безопасности. Централизованные агенты – решение получше, хотя они более требовательны к ресурсам, что делает их использование менее предпочтительным. Бывают случаи, когда данные настолько важные, что использование централизованного агента и сетевого мониторинга крайне необходимо. Примером тому могут служить конфиденциальные финансовые транзакции (сделки с акциями или денежные перечисления). В большинстве организаций используется сетевой мониторинг. Этот вид мониторинга наиболее приемлем с точки зрения стоимости, затрат на обслуживание и соответствия стандартам. В качестве примера, предположим, что в гипотетической компании решили реализовать комплекс мер по сетевому мониторингу.

5. Рекомендации для Microsoft SQL Server

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

5.1 Мониторинг журналов событий в Windows

Регулярный просмотр журналов событий в Windows должен дополнять мониторинг и ведение журнала баз данных на SQL Server. Необходимо регулярно просматривать и мониторить журнал событий той операционной системы, где установлена база данных. Отслеживание журнала событий поможет выявить проблемы, связанные с наиболее распространенными угрозами: уязвимостями платформы баз данных, слабым аудитом, DOS-атаками, уязвимостями коммуникационных протоколов баз данных и слабой аутентификацией. Вывод таков: мониторинг журналов событий поможет определить следы атак на основе вышеперечисленных угроз. Для наиболее критических систем баз данных следует рассмотреть возможность мониторинга важных системных директорий, конфигурационных файлов баз данных, реестра и директорий с резервными копиями. Политика аудита операционной системы должна удовлетворять корпоративной политике и обеспечивать надлежащий аудит на сервере. Одна из настроек, которую следует включать с особой осторожностью, – «Аудит: немедленное отключение системы, если невозможно внести в журнал записи об аудите безопасности (Shut down system immediately if unable to log security audits)». Эта настройка позволяет пользователям реализовать DOS-атаку при помощи политики аудита. Перед изменениями настроек рабочей среды следует провести тщательное исследование и тестирование (Microsoft, 2005, см. Раздел Ссылки).

Прекрасный ресурс для исследования кодов событий в Windows и значений этих кодов – веб-сайт http://www.ultimatewindowssecurity.com/securitylog/encyclopedia/default.aspx?i=j. Этот веб-сайт содержит полный список кодов событий для различный версий ОС Windows вместе с тем, когда они появляются в журнале событий. Подобный список кодов событий очень важен для программы мониторинга, поскольку позволяет определить уровень важности каждого происходящего события.

5.2 Конфигурирование SQL Server для ведения журнала успешных и неуспешных авторизаций

По умолчанию SQL Server настроен для записи в журнал событий только неуспешных авторизаций. Добавление в этот журнал еще и успешных авторизаций поможет лучше понять, кто использует базу данных. Используя рекомендацию из предыдущего раздела по регулярному отслеживанию журналов событий, вы сможете проводить аудит и мониторинг локального доступа к базе данных. Если не изменить стандартную настройку, когда отмечаются только неуспешные авторизации, это приведет к тому, что не будут отмечаться те пользователи, которые соединяются с сервером напрямую при помощи утилит Dameware и RDP, а затем используют утилиту на сервере для доступа к базе данных. Инструменты типа Dameware и RDP используют протоколы шифрования при соединении пользователя с сервером, что делает использование сетевых снифферов бесполезным. Простое изменение этой настройки позволит отслеживать локальные события авторизации к базе данных, когда пользователи присоединяются с сервера посредством зашифрованного канала. Важно отметить, если не используется агент или дополнительные средства по ведению журнала, будет отслеживаться только сам факт авторизации. Без дополнительных компенсирующих элементов контроля совершаемые с базой действия останутся скрытыми. Ниже показан скриншот конфигурации SQL Server и журналы событий Windows, где показаны успешные и неуспешные авторизации (Chapman, 2011, см. Раздел Ссылки).

Конфигурация SQL Server для отслеживания успешных и неуспешных авторизаций

Событие успешной авторизации:

Event Source: MSSQLSERVER
Event Code: 18453
Type: Audit Success (4)
User Name: corporation\gooduser
String[%1]: corporation\gooduser
String[%2]: [CLIENT: 10.10.10.10]

Login Success:
Computer Name: SQLPROD
Event Source: MSSQLSERVER
Event Code: 18454
Type: Audit Success (4)
User Name: N/A
String[%1]: companylogs
String[%2]: [CLIENT: 10.10.10.20]

Успешная авторизация к SQL Server – журнал событий Windows

Событие неуспешной авторизации:

Computer Name: sqlserver1p.goodcompany.com
Event Source: MSSQLSERVER
Event Code: 18456
Type: Audit Success (4)
User Name: corporation\sqlagent
String[%1]: corporation\sqlagent
String[%2]: Reason: Failed to open the explicitly specified
database.
String[%3]: [CLIENT: ]

Неуспешная авторизация к SQL Server – журнал событий Windows

5.3 Отслеживайте аутентификации Active Directory и запросы служб

Наилучшая практика по безопасности – мониторинг текущих событий в журналах событий Windows, а также событий от систем безопасности. Многие компании недооценивают ценность мониторинга аутентификаций и запросов билетов по протоколу Kerberos службы Active Directory. Эти события могли быть весьма полезными при отслеживании активности на SQL Server и аутентификации к базе данных. В среде, где производится мониторинг SQL Server посредством сетевого сниффера и трафик зашифрован, отслеживание запросов Kerberos может помочь в аудите учетных записей и процессов, которые пытаются подсоединиться к SQL Server. Если есть проблемы с зашифрованными соединениями из-за использования аутентификации Kerberos, в этом случае для доступа к SQL Server при помощи Windows-аутентификации могут помочь выданные билеты Kerberos.

Выданные билеты аутентификации

Билеты аутентификации полезны для отслеживания первоначальных учетных записей. Эти события в ОС Windows возникают в результате взаимодействия пользователей с контроллером домена и запроса билета для получения билета (Ticket GrantingTicket, TGT). Если учетные записи в контроллере домена корректны и нет никаких ограничений, контроллер домена выдает билет для получения билета (TGT) и фиксирует событие 672 в журнале событий. В поле Пользователь всегда отражается имя SYSTEM, так что администратору необходимо сопоставлять IP-адреса и пользователя. Если после имени учетной записи компьютера стоит символ «$», это означает, что событие сгенерировано компьютером. Подобные события могут помочь в отслеживании пользователей, когда системы мониторинга не могут расшифровать пакеты при авторизации (login packets) из-за использования аутентификации Kerberos.

Пример события:

Jul 16 06:59:59 domaindc1p EvntSLog: Security,672,Mon Jul 16 13:59:59
2012,NT AUTHORITY\SYSTEM,9,MY_SERVER;FOOBAR;%{S-1-5-21-2130074997-
794050694-931750244-17949};krbtgt;%{S-1-5-21-2130074997-794050694-
931750244-502};0x40810010;-;0x17;2;10.10.10.10;;;;;;

Запрос билета службы

События, связанные с запросами билета службы (Service Ticket Request), - возникают, когда пользователь или компьютер получает доступ к серверу через сеть (код события 673). Это событие доступно только для контроллеров доменов, однако очень полезно в отслеживании тех, кто пытается получить доступ к серверу. Если злоумышленник пытается смонтировать накопитель, запрос к операционной системе доступен с этим билетом.

Пример события:

Jul 16 09:59:58 domaindc4p EvntSLog: Security,673,Mon Jul 16 13:59:58
2012,NT AUTHORITY\SYSTEM,9 ,jim@foobar.com; FOOBAR.COM;servername$; %{S-
1-5-21-2130074997-794050694-931750244-62310};0x40810000;
0x17;10.10.10.20;-;{eadc3444-d170-97d3-47ac-50b5350699a6};-;;;;;;

Выданные обновленные билеты

Этот билет может быть полезен лишь в небольшом количестве ситуаций и рабочих сред. У Kerberos есть ограничение на билет, который необходимо обновлять после истечения срока действия. В версиях Windows, идущих после Windows 2000, сервер автоматически соединяется с контроллером домена и обновляет билет, после чего создается запись (код события 674) в журнале событий.

Пример события:

Jul 16 09:59:44 domaindc2p EvntSLog: Security,674,Mon Jul 16 13:59:44
2012,NT AUTHORITY\SYSTEM,9 ,jim@foobar.com; foobar.com;krbtgt;%{S-1-5-
21-755119451-1620593998-612134452-502};0x2;0x17;10.10.10.10;;;;;;;;;

Неудачная попытка аутентификации

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

Пример события:

Jul 16 09:59:54 domaindc3p EvntSLog: Security,675,Mon Jul 16 13:59:54
2012,NT AUTHORITY\SYSTEM,9,jim;%{S-1-5-21-2130074997-794050694-
931750244-90060};krbtgt/foobar;0x0;0x19;10.10.10.10;;;;;;;;;;

(Microsoft, 2000, см. Раздел Ссылки)

5.4 Используйте сертификаты на SQL-серверах

На SQL-серверах, использующие Windows-аутентификацию, будут зашифрованы все пакеты, передаваемые при авторизации из-за наличия протокола Kerberos. Если мониторить базу данных через сеть, будет упущено большинство авторизаций, возникающих на сервере. Как правило, система мониторинга будет сообщать об огромном количестве завершений сеансов на SQL Server и лишь небольшом количестве авторизаций. Установка самоподписанных, либо PKI-сертификатов и совместное их использование с приложением, которое занимается мониторингом базы данных, может помочь в отслеживании пользовательских аутентификаций и расшифровке всего SQL-трафика. Перед началом работы SQL Server генерирует сертификат и разделяет публичный ключ со всеми контроллерами доменов. Приложения, использующие интегрированную Windows-аутентификацию, во время авторизации посылают зашифрованные пакеты из-за использования запросов Kerberos. Шифрование пакетов во время авторизации усиливает безопасность, однако создает проблемы при реализации программы по ведению журнала и мониторинга из-за невозможности отслеживать учетные записи во время авторизации. Ниже показан пример отчета об активности за день на SQL Server, который сформирован программой мониторинга базы данных.

Отчет об интенсивной ежедневной активности на SQL Server

В этом примере показано 906 завершений сеансов работы и не показаны попытки авторизации на сервер из-за того, что при сетевом мониторинге не учитываются шифрованные пакеты (Microsoft, 2010, см. Раздел Ссылки).

5.5 Используйте политику для ограничения привилегий администраторов баз данных

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

5.6 Используйте политику для ограничения RDP-доступа к хосту

Если использование RDP не отрегулировано политикой, то аудит может быть неполноценным. Желательно ограничить прямой доступ к SQL Server при помощи утилит наподобие Dameware или RDP. Также необходимо постоянно мониторить попытки RDP-доступа при помощи журналов событий Windows. Если администратору базы данных необходим прямой доступ к Windows-серверу, их следует наделить минимально необходимыми правами для выполнения обязанностей. Администраторов баз данных никогда не следует наделять полномочиями системных администраторов. Возможность подключения к серверу при помощи RDP следует дать только тем сотрудникам, которым это необходимо. RDP создает шифрованный туннель для безопасного доступа на сервер. Хотя использование RPD – хорошая тема для повышения безопасности, однако это может создать пробелы в аудите, когда пользователи соединяются напрямую с хостом и получают доступ к SQL Server. Если в базе есть строго конфиденциальная информация, возможно, потребуется установка агента базы данных. Дополнительные затраты на обслуживание и стоимость содержания агентов часто делает их использование невозможным. Мониторинг RDP-доступа через журнал событий в совокупности с концепцией запросов и выдачи RDP-доступа только в случае крайней необходимости может помочь оградить сервер от ненужных подключений и создаст лучшее представление о том, кто использует RDP.

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

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

5.8 Избегайте использовать агентов баз данных

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

5.9 Усиление безопасности баз данных и сохраненные процедуры

Усиление безопасности базы данных в совокупности с разумным использованием сохраненных процедур может защитить и смягчить последствия от атак при помощи SQL-инъекций. Приложениям, которые взаимодействуют с базой данных, при аутентификации следует использовать учетные записи с наименее необходимым уровнем привилегий. Также следует удалить стандартные учетные записи, являющиеся частью базовой версии продукта, но ненужные для решения задач бизнеса. Сюда же следует включать удаление ненужных сохраненных процедур, которые могут содержать дополнительные бреши и потенциально уязвимый код. Более подробные руководства по укреплению защиты доступны в интернете (например, на сайте организации The Center for Internet Security) (Chapman, 2005, см. Раздел Ссылки).

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

5. Шифрование базы данных

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

6.1 Шифрование хранилища в сравнении с транспортным шифрованием

Важно понимать отличия между шифрованием хранилища и транспортным шифрованием. В зависимости от способа реализации шифрования может быть обеспечена конфиденциальность и целостность данных, как во время передачи, так и во время хранения. К примеру, протокол SSL обеспечивает конфиденциальность при передаче информации, но не защищает во время ее хранения. Многие люди ошибочно полагают, что SSL защищает данные и во время передачи и во время хранения. Однако это не так. Шифрование данных при помощи SSL происходит на стороне приложения, в то время как механизм шифрования у базы данных защищает информацию перед тем, как передать ее конечному пользователю. Шифрование диска защищает от несанкционированного доступа и позволяет сохранить целостность данных. Цель шифрования базы данных – защитить хранимые данные. Шифрование базы не защищает данные от компрометирования или злоупотребления внутри приложения. Без использования шифрования, хранимые данные уязвимы к атакам, эксплоитам и злоупотреблениям привилегиями. Кроме того, злоумышленник, используя эксплоиты, может скомпрометировать службы, запущенные с высокими привилегиями, и, соответственно, получить доступ конфиденциальной информации, которая хранится на сервере. С другой стороны, при помощи эксплоитов может быть совершена атака на непривилегированные учетные записи, после чего будут повышены привилегии и также будет получен доступ к конфиденциальной информации. Еще одна угроза: злоупотребление привилегиями со стороны сотрудников, которые могут получить доступ к данным в злонамеренных целях. Подводя итоги, следует отметить, что шифрование, как во время передачи данных, так и во время их хранения не гарантирует стопроцентную защиту (Natan, 2005).

Ссылки

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, fromhttps://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-инъекция)

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

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