(Возврат на основную страницу)

Содержание номера за Февраль 2007 год

База данных как крепость

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

Повышение уровня защиты Microsoft SQL Server 2000

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

•    защита сетевого обмена;

•    защита операционной системы;

•    защита компонентов БД;

•    защита приложений, использующих БД.

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

Защита сетевого обмена

Для повышения сетевой безопасности сервера SQL Server необходимо решить следующие задачи:

•    выбор и настройка сетевых библиотек сервера;

•    фильтрация трафика и разграничение сетевого доступа;

•    шифрование трафика.

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

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

И последний критерий — это возможности, поддер­живаемые теми или иными библиотеками. Так, биб­лиотека TCP/IP позволяет серверу задействовать SSL для шифрования трафика и протокола аутентификации Kerberos. Библиотека Named Pipes используется для поддержки протокола аутентификации NTLM при взаимодействии с устаревшими клиентами. Поддержка сервером библиотеки Multiprotocol (RPC) дает ему возможность защищать сетевой обмен средствами ОС.

Стандартно рекомендуется использовать сетевую библиотеку TCP/IP и удалить все остальные. Это связано с возможностью использования злоумышленником дополнительных сетевых библиотек для компрометации сервера. К примеру, если в сети используется TCP/IP и фильтрация трафика настроена таким образом, что соединение с портами SQL Server разрешено только с определенных компьютеров, злоумышленник сможет обойти это ограничение и соединиться с сервером, используя библиотеку Named Pipes через порты 137, 139, 445.

В настройках библиотеки TCP/IP для каждого экземпляра SQL Server можно указать номер TCP­порта, на котором работает экземпляр. Дополнительно можно «спрятать» экземпляр сервера, установив переключатель Hide server. После настройки этого режима экземпляр сервера автоматически настраивается на работу через порт 2433 и не публикуется через службу SQL Server Resolution Service (SRS UDP 1434). Использование данной настройки возможно только для одного экземпляра SQL Server на сервере.

Если задействована настройка Hide server, то при направлении клиентом широковещательного запроса с целью определения экземпляров SQL Server в данном сегменте экземпляр ему не ответит. Но если пользователь знает номер порта, на котором работает «спрятанный» экземпляр (т. е. порт 2433), он сумеет с ним соединиться.

Гораздо более эффективным методом сокрытия сервера является настройка библиотек TCP/IP на использование нетипичных номеров портов (например, в диапазоне выше 5000) с последующей фильтрацией трафика SQL SRS. Таким образом, соединиться с сервером можно будет, только зная используемый им номер порта. Для централизованной настройки клиентов можно задействовать административный ша­блон групповой политики, настраивающий клиентские библиотеки на работу с используемым сервером номером порта путем изменения значения параме­тра реестра HKLM\SOFTWARE\Microsoft\MSSQLServer\Client\SuperSocketNetLib\Tcp\DefaultPort. Однако следует понимать, что данные настройки являются элементом «политики запутывания» и не гарантируют защиты, если злоумышленник сумеет соединиться с сервером и применить эвристические методы определения служб специализированных утилит, таких как nmap или XSpider.

Фильтрация трафика Фильтрация трафика дает возможность заблокировать взаимодействие с SQL Server по неиспользуемым сетевым протоколам, что повышает уровень его защиты от атак через другие сетевые службы. Для фильтрации трафика и разграничения доступа можно воспользоваться политикой протокола IPSec или другими средствами фильтрации трафика уровня узла, например персональным межсетевым экраном Internet Connection Firewall.

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

Для более безопасного разграничения сетевого доступа можно задействовать механизмы взаимной аутентификации клиента и сервера с использованием общих ключей IPSec или в случае, если SQL Server работает на основе Windows Server 2003, права Access this computer from network для учетной записи компьютера.

В табл. 1 представлен пример таблицы фильтрации трафика при помощи IPSec.

Правило 1 разрешает взаимодействие со службой Server Resolution Service, необходимой для определения установленных экземпляров сервера. Если используется описанный выше метод настройки клиентских библиотек, это правило можно удалить.

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

Правило 3 требует установления с портом 2433 защищенного соединения. Этот порт используется экземпляром сервера, который является основой для веб­приложения. Соединение с ним возможно только с компьютеров, успешно прошедших аутентификацию IPSec и наделенных правом Access this computer from network. В нашем случае это веб­сервер и рабочие станции администраторов.

Правила 4, 5 и 6 разрешают взаимодействие с сервером по протоколам NetBIOS/CIFS, которые используются сетевой библиотекой Named Pipes. Если применяется аутентификация Kerberos или NTLMv2, эти правила можно исключить.

Правило 7 разрешает защищенное взаимодей­ствие по протоколу RDP, используемому сервером терминалов.

Правило 8 дает возможность взаимодействия с контроллером домена для аутентификации и применения групповых политик.

Шифрование трафика Для шифрования трафика сервера SQL можно задействовать протоколы IPSec и SSL v 3.0 (см. врезку «IPSec или SSL v 3.0?»).

Для использования SSL, согласно рекомендациям статьи базы знаний Microsoft KB276553, необходимо получить сертификат X.509v3, выданный для аутентификации сервера на его доменное имя, и установить его в локальное хранилище компьютера. После этого требуется включить шифрование трафика в сетевых утилитах сервера и проверить соединение со стороны клиента.

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

Driver=SQLServer;Server=ServerName;
Network=DBNETLIB.DLL;Encrypt=YES

Возможно использование шифрования не на всех клиентских компьютерах. Для этого настройка Force Protocol Encryption включается не на сервере SQL, а в настройках клиентской библиотеки.

Защита операционной системы

При повышении уровня защиты базовой операционной системы необходимо настроить:

•    системные службы;

•    права пользователей и разрешения файловой си­стемы;

•    шифрование файлов базы данных.

Настройка системных служб и прав пользователей Microsoft SQL Server устанавливается и функционирует как несколько системных служб. Для каждого экземпляра базы данных создается служба с именем, образованным по схеме MSSQL$<имя экземпляра>. Так же создаются экземпляры SQL Server Agent (SQL­Agent$< имя экземпляра>), отвечающие за выполнение периодических заданий, таких как автоматическая архивация, поддержка БД и т. д.

Кроме того, для сервера в целом создаются службы Microsoft Search (отвечает за индексирование и поиск документов в том случае, если включена поддержка полнотекстового поиска) и DTS (отвечает за поддер­жку распределенных транзакций).

Служба MSSQL может работать в контексте учетной записи Local System или от имени учетной записи пользователя (доменного или локального). Очень нежелательно применять для запуска служб учетную запись Local System, как и любую другую учетную запись с административными полномочиями. Это связано с тем, что в случае компрометации сервера все действия в системе будут производиться от имени этой записи, т. е. злоумышленник будет работать с админи­стративными привилегиями.

Рекомендуется запускать службы от имени учетной записи (локальной или доменной), имеющей ограниченные привилегии. Локальную учетную запись целесообразно использовать, если в задачи сервера SQL Server не входит сетевое взаимодействие с другими службами. В обратном случае применяется доменная учетная запись. На сервере желательно отключить службы, которые для работы SQL Server не нужны (табл. 2).

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

•    Act as part of operating system;

•    Lock pages in memory;

•    Bypass traverse checking;

•    Log on as service;

•    Increase quotas;

•    Replace a process level token;

•    Deny logon locally;

•    Deny log on through Terminal Services.

Запрет локальной регистрации в системе и соединения посредством сервера терминала ограничивают возможности злоумышленника в случае компрометации системы. Также необходимо удалить группу Domain Users у пользователей, имеющих право Logon Locally.

Желательно устанавливать SQL Server на раздел, отличный от раздела с ОС. Это уменьшит влияние сервера БД на ОС и облегчит настройку ряда параме­тров безопасности.

Настройка разрешений файловой системы и реестра При настройке разрешений файловой системы из списков контроля доступа сервера необходимо удалить учетную запись Everyone. Вместо нее можно использовать группу Users или Authenticated Users. Для нормального функционирования сервера необходимо установить разрешения на папки файловой системы и разделы реестра, описанные в табл. 3. Запись в другие папки системы, включая корневые разделы, должна быть доступна только для администраторов и учетной записи System.

Для ограничения возможностей злоумышленника в случае компрометации сервера БД необходимо либо удалить из системы, либо установить разрешение SQL Server — Deny Full Access на системные утилиты, такие как: explorer.exe, regedit.exe, poledit.exe, taskman.exe, at.exe, cacls.exe, cmd.exe, finger.exe, ftp.exe, nbstat.exe, net.exe, net1.exe, netsh.exe, rcp.exe, regedt32.exe, regini.exe, regsvr32.exe, rexec.exe, rsh.exe, runas.exe, runonce.exe, svrmgr.exe, sysedit.exe, telnet.exe, tftp.exe, tracert.exe, usrmgr.exe, wscript.exe, xcopy.exe.

Шифрование баз данных Для защиты файлов БД на физиче­ском уровне имеет смысл заши­фровать их. В Windows 2000/2003 предусмотрена возможность ши­фрования БД при помощи шифрующей файловой системы. En­cryp­ting File System — надстройка над NTFS, позволяющая в прозрачном для пользователя режиме шифровать и расшифровывать файлы на жестком диске компьютера.

Для использования этой возможности необходимо выполнить следующее.

1.  Настроить службу SQL Server на запуск от имени учетной записи пользователя.

2.  Войти в систему под данной учетной записью.

3.  В Проводнике открыть свойства папки Program Files\microsoft sql server\<имя экземпляра>\Data или другой, где сохранены базы данных.

4.  Установить для папки атрибут Properties\Advanced\Encrypt contents to secure data.

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

Шифрование при помощи Encrypting File System является эффективным средством защиты данных, но только при условии соблюдения всех рекомендаций по ее настройке. В частности, необходимо удалять из системы секретный ключ агента восстановления. Также желательно удалить все локальные учетные записи из базы пользователей сервера SQL Server (особенно это касается локального администратора), поскольку при физическом доступе пароли этих учетных записей легко могут быть переназначены.

Для повышения уровня защиты можно применить шифрование LSA при помощи утилиты Syskey. Лучше всего использовать в качестве ключа шифрования парольную фразу.

Защита компонентов базы данных

Первым этапом настройки безопасности SQL Server как приложения является выбор используемой модели аутентификации. Рекомендуется применять метод Windows в связи с изложенными выше проблемами метода SQL Server (пересылка пароля в закодированном виде).

Затем необходимо решить, будут ли члены группы локальных администраторов иметь доступ к серверу БД с привилегиями системных администраторов. Автоматически создаваемую серверную учетную запись Bultin/Administrators рекомендуется удалить. Это прежде всего связано с обязательным присутствием в данной группе учетной записи локального админи­стратора, чей пароль может быть моментально изменен в случае наличия у злоумышленника физического доступа или подбора по сети. После того как злоумышленник получит доступ к системе от имени этой учетной записи, он сможет обойти все защитные механизмы, включая шифрование БД при помощи EFS.

Перед удалением учетной записи Bultin/Ad­mi­ni­stra­tors необходимо создать серверную учетную запись на основе доменной группы и присвоить ей роль Sys­tem Administrator.

Следующим этапом является удаление стандартных БД, входящих в дистрибутив в качестве примеров. К ним относятся NorthWind и pubs. Данные базы содержат ряд ошибок, имеют слабые разрешения и часто используются злоумышленниками для атак.

Затем необходимо запретить выполнение запросов типа AdHoc. Такие запросы (OPENROWSET, OPENQUERY и OPENDATASOURCE) позволяют серверу устанавливать соединение с внешним сервером и сохранять на нем свои данные. Они очень редко используются в приложениях, но могут быть применены злоумышленником для удаленного получения информации из баз данных сервера. Примером применения подобной техники является программа Data Thief, использующая метод внедрения SQL­кода (SQL Injection) для выполнения запросов AdHoc.

Для отключения возможности выполнения запросов AdHoc необходимо установить значение параме­тра системного реестра DisallowAdhocAccess равным 1 для каждой сетевой библиотеки сервера. Ниже перечислены разделы реестра, в которых располагаются настройки сетевых библиотек:

•    HKLM\Software\Microsoft\MSSQLServer\Providers\MSDAORA;

•    HKLM\Software\Microsoft\MSSQLServer\Providers\ADSDSOObject;

•    HKLM\Software\Microsoft\MSSQLServer\Providers\DB2OLEDB;

•    HKLM\Software\Microsoft\MSSQLServer\Providers\MSIDXS;

•    HKLM\Software\Microsoft\MSSQLServer\Providers\MSQLImpProv;

•    HKLM\Software\Microsoft\MSSQLServer\Providers\MSSEARCHSQL;

•    HKLM\Software\Microsoft\MSSQLServer\Providers\MSDASQL.

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

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

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

Список расширенных хранимых процедур, доступ к которым необходимо ограничивать, можно взять из рекомендаций по настройке безопасности SQL Server, например из рекомендаций центра SNAC NSA (http://www.nsa.gov).

Выполнение описанных настроек можно автоматизировать при помощи сценариев на языке T­SQL. Пример подобного сценария приводится на сервере www.sqlsecurity.com . Как обычно, перед применением сценария в производственной среде его следует тщательно протестировать.

Аудит сервера SQL Server

Существует несколько разных методов настройки аудита в БД SQL Server. Лучшим решением является использование комбинаций данных методов в зависимости от решаемых задач. По умолчанию аудит на сервере не активизирован.

Аудит аутентификации сервера позволяет отслеживать попытки аутентификации на сервере SQL. Включить его можно через Enterprise Manager или путем модификации параметра реестра HKLM\Software\Microsoft\MSSQLServer\MSSQLServer\Audit Level. Возможные значения — 0...3.

Нулевое значение параметра означает отключение аудита, 1 — запись удачных попыток аутентификации, 2 — неудачных. При значении параметра 3 включается аудит всех попыток регистрации.

События сохраняются в журнале Application операционной системы. Дополнительные настройки позволяют сохранять события в журнале ошибок SQL Server. Настройка данного типа аудита предполагает включение отслеживания неудачных попыток аутентификации (значение 2) с последующим анализом на предмет выявления попыток несанкционированного доступа или подбора паролей.

Другой тип аудита относится к событиям сервера БД. Настраивать и отслеживать их можно при помощи утилиты SQL Profiler.

Включение любой из данных категорий событий аудита приведет к сохранению следующей информации о событиях:

•    дата и время события;

•    учетная запись пользователя;

•    тип события;

•    результат выполнения действия (успешно или нет);

•    место события (к примеру, имя компьютера);

•    имя объекта, к которому осуществлялся доступ;

•    текст SQL­запроса (за исключением паролей).

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

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

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

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

Если описание необходимых разрешений отсут­ствует (что весьма вероятно), можно воспользоваться журналом аудита. При отладке системы следует включить аудит доступа к объектам и некоторое время накапливать данные о событиях. Затем собранные события группируются по типам объектов, запросов, и определяется, какие разрешения использовались для работы с БД.

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

Заключение

Повышение уровня защиты приложений на основе Microsoft SQL Server 2000 является довольно сложной задачей и в значительной степени зависит от работающего на его базе приложения. Лучше всего здесь действовать по принципу «отключить все лишнее и понемногу включать, пока не заработает». Процесс этот довольно долгий и требует некоторой практики, однако настроенные таким образом серверы могут работать годами, не требуя дополнительного внимания.

Табл. 1. Пример таблицы фильтрации трафика при помощи IPSec

Табл. 2. Службы, которые не требуются для работы SQL Server

Табл. 3. Разрешения, необходимые для работы БД

Взламываем SQL Server. Часть 3*

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

*См. Джоэль Скэмбрэй и Стюарт Макклюр. Взламываем SQL Server. Часть 1–2 // SQL Server для профессионалов. 2006. № 10, 12.

Получение лучшего плана выполнения запроса в Microsoft SQL Server 2005

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

Планы выполнения запросов при использовании параметра привязки к схеме (SCHEMABINDING) у пользовательских функций T­SQL (T­SQL UDF)

В этой статье описывается, как указанный во время создания UDF параметр привязки к схеме (SCHEMABINDING) в SQL Server 2005 может повлиять на планы запросов, использующих данные UDF. Вооружившись этим знанием, вы обнаружите, что можно значительно повысить производительность ваших запросов совершенно бесплатно.

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

Одноранговая репликация в SQL Server 2005

Корпоративные веб­сайты Microsoft серьезно зависят от БД, которые поддерживают такие ресурсы с большим трафиком, как Microsoft Update, Download Center, Communities, TechNet и MSDN. Оперативность Microsoft.com поддерживается 17 инженерами, командой по работе c SQL Server, которая занимается этими системами БД. В целом, эта команда отвечает за более чем 2250 активных пользовательских баз, которые занимают до 55,15 Тб пространства на 291 рабочем сервере SQL Server.

Одна система, управляемая данной командой, содержит базы данных для внутренних поставщиков ассоциативных услуг. Эти поставщики представляют собой группы внутри Microsoft, которые публикуют материалы в Веб. Они расположены по всему миру, и все требуют наличия определенного функционала баз данных «за спиной» их веб­приложений, работающих с Интернетом.

Рабочая среда сменила несколько архитектур, пока изменялись БД, функциональные потребности и стратегии размещения. В настоящее время в этой среде соединено более 100 БД. Она построена на основе Windows Server 2003 SP1 Enterprise Edition и SQL Server 2000 SP4, работающих на шести серверах HP Proliant. Транзакционная репликация используется для перемещения данных от и к серверу­консолидатору, предоставляющему данные множеству рабочих серверов, к которым обращаются веб­приложения. Также задействован сценарий переноса журналов для обеспечения перехвата управления при отказе.

По мере приближения выпуска SQL Server 2005 мы все больше интересовались некоторыми его новыми возможностями и ощущали потребность в том, чтобы составить план действий по усовершенствованию нашей среды. В частности, одной из возможностей, заинтересовавшей нас, был новый вид транзакционной репликации, называющийся одноранговой (peer to peer) репликацией. При такой конфигурации все узлы в топологии равноправны. Каждый узел публикует и подписывается на одну и ту же схему и данные. Изменения (такие, как вставки, обновления и удаления) могут быть проведены на любом узле, а технология репликации позволит выявить, когда изменение было применено к данному узлу, предотвращая от цикли­чного повторения изменений на узлах.

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

Эта статья идет далее и объясняет, что SQL Server 2005 представил новую одноранговую модель, которая позволяет репликации протекать в топологии между идентичными участниками. Такая модель хорошо подходит пользователям, которые применяют конфигурацию «от сервера к серверу», а также нуждаются в динамическом перераспределении ролей между реплицируемыми узлами для осуще­ствления обслуживания или для поддержки в случае неполадок.

(Возврат на основную страницу)