Построение защищенных Web-приложений на основе IIS и MS SQL Server

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

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

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

Например, допустим, что процедура GetSalesProjections подписана с помощью сертификата с именем C1. Сертификат C1 должен существовать в базе данных Sales, с сертификатом C1 должен быть сопоставлен пользователь, например CertUser1. Пользователь CertUser1 обладает разрешениями AUTHENTICATE в базе данных Sales.

При вызове процедуры проверяется  подлинность процедуры (не была ли она  подделана в момент подписания процедуры). Если подпись заверена, то для контекста, который устанавливается в модуле предложением EXECUTE AS, в качестве средства проверки подлинности используется C1. Если подпись не проходит проверку, то средство проверки подлинности не добавляется в лексему и попытка доступа к внешним ресурсам завершается неуспешно.

В следующем примере показано управление доступом к ресурсам вне области исходной базы данных с помощью подписанного модуля (рисунок 40). Процедура GetSalesProjections в базе данных Marketing подписана с помощью сертификата C1. Сертификат C1 существует в базе данных Sales, с ним сопоставлен пользователь CertUser. Пользователь CertUser1 обладает разрешениями AUTHENTICATE в базе данных Sales.

 

Рисунок 40 – Управление доступом с помощью подписанного модуля

 

Доверие этому средству проверки подлинности  проверяется аналогично проверке, выполняемой, когда владелец базы данных является средством проверки подлинности. Таким образом, это проверка разрешений AUTHENTICATE SERVER или AUTHENTICATE. Однако поскольку доверие устанавливается на гранулярном уровне и модуль нельзя изменить без изменения подписи, то нет необходимости проверять свойство TRUSTWORTHY в базе данных.

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

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

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

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

1. Подход к установлению доверия, основанный на владельце базы данных. Достоинства и недостатки этого подхода:

• не требует вникать в суть таких криптографических понятий, как сертификаты или подписи;
• не дает такой же гранулярности, как подход, основанный на подписях;
• при подключении базы данных к экземпляру SQL Server свойство TRUSTWORTHY в базе данных принимает значение OFF. Модули, которым доверяет владелец базы данных, не будут действительны до тех пор, пока администратор явно не задаст для свойства TRUSTWORTHY значение ON. Из этого неявно следует, что, для того чтобы подключенная база данных могла функционировать должным образом и обращаться к другим базам данных, предполагается некоторое вмешательство системного администратора.

2. Подход к установлению доверия с помощью подписей. Достоинства и недостатки этого подхода:

• обеспечивает гранулярный уровень доверия, но применяется только к контекстным переключениям внутри подписанных модулей;
• подпись нельзя применять к контекстным переключениям, которые устанавливаются отдельными инструкциями EXECUTE AS USER и EXECUTE AS LOGIN. Чтобы расширить область доверия с помощью этих инструкций, следует воспользоваться первым подходом, основанным на владельце базы данных;
• производители или разработчики приложений могут подписывать модули закрытым ключом, но перед поставкой модуля или базы данных закрытый ключ нужно удалить. Это работает, поскольку закрытые ключи используются только для подписи модулей. Для проверки подписей достаточно открытых ключей, связанных с модулями;
• подключение базы данных не влияет на модули, доверие к которым основано на их подписях. Они будут работать без дополнительных требований.

 

 

 

 

2.4 Безопасное взаимодействие клиента с базой данных MS SQL Server 2008

 

Необходимо обеспечить безопасность потокового взаимодействия между клиентами  и экземпляром служб Microsoft SQL Server Analysis Services. Во время процесса установки устанавливаются параметры безопасности по умолчанию, управляющие потоковым взаимодействием. Эти настройки задаются в файле конфигурации msmdsrv.ini для экземпляра служб Analysis Services, и они видны как свойства экземпляра служб Analysis Services в среде SQL Server Management Studio. (Файл конфигурации msmdsrv.ini расположен в папке Bin.)

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

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

 

 

 

 

2.4.1 Шифрование данных

 

 

По умолчанию службы Microsoft SQL ServerAnalysis Services отвечают только на зашифрованные клиентские запросы и возвращают клиенту только зашифрованный поток данных. Несмотря на то, что шифрование требует дополнительных ресурсов процессора и может повлиять на общую производительность запросов, дополнительная безопасность, обеспечиваемая шифрованием, обычно перевешивает эти проблемы производительности.

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

Чтобы изменить настройки шифрования по умолчанию на уровне сервера, измените следующие свойства конфигурации служб Analysis Services в среде SQL Server Management Studio. Чтобы получить доступ к этим свойствам, щелкните правой кнопкой мыши экземпляр служб Analysis Services, выберите пункт «Свойства», а затем найдите необходимые свойства на странице «Безопасность».

• Security \ AdministrativeDataProtection \ RequiredProtectionLevel

Если значение настройки по умолчанию  равно 1, то требуется, чтобы все административные данные были зашифрованы. Настройка 0 обеспечивает поддержку открытого текста, а настройка 2 — поддержку открытого текста с подписями (что является менее надежным, чем шифрование).

• Security \ AdministrativeDataProtection \ RequiredWebProtectionLevel

Если значение настройки по умолчанию  равно 1, то требуется, чтобы все административные данные, получаемые через веб-клиента, были зашифрованы. Настройка 0 обеспечивает поддержку открытого текста, а настройка 2 — поддержку открытого текста с подписями (что является менее надежным, чем шифрование).

• Security \ DataProtection \ RequiredProtectionLevel

Если значение настройки по умолчанию  равно 1, то требуется, чтобы все данные были зашифрованы. Настройка 0 обеспечивает поддержку открытого текста, а настройка 2 — поддержку открытого текста с подписями (что является менее надежным, чем шифрование).

• Security \ DataProtection \ RequiredWebProtectionLevel

Если значение настройки по умолчанию  равно 1, то требуется, чтобы все данные, получаемые через веб-клиента, были зашифрованы. Настройка 0 обеспечивает поддержку открытого текста, а настройка 2 — поддержку открытого текста с подписями (что является менее надежным, чем шифрование).

 

 

 

 

2. Проверка подлинности клиента

 

 

По умолчанию в службах Microsoft SQL Server Analysis Services клиенты должны пройти проверку подлинности Microsoft Windows, чтобы установить соединение со службой. По умолчанию службы Microsoft SQL Server Analysis Services отклоняют все запросы, поступающие от клиентов, не прошедших проверку подлинности.

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

Чтобы получить доступ к этому свойству из среды SQL Server Management Studio, щелкните правой кнопкой мыши экземпляр служб Analysis Services, выберите пункт Свойства, а затем найдите нужное свойство на странице Безопасность. Далее показаны возможные значения данного свойства:

1 – клиенты должны пройти проверку подлинности в операционной системе Microsoft Windows. Это значение данного свойства по умолчанию;

0 – клиенты не должны проходить проверку подлинности в операционной системе Microsoft Windows.

Чтобы установить соединение со службой  Microsoft SQL Server Analysis Services, проверка подлинности не требуется.

 

 

 

 

2.4.3 Особые пакеты безопасности

 

 

По умолчанию службы Microsoft SQL Server Analysis Services настроены на прием всех пакетов безопасности поставщика поддержки безопасности (SSP), который поддерживается операционной системой Microsoft Windows для клиентов, прошедших проверку подлинности. Начиная с ОС Windows 2000, Майкрософт также предоставляет поддержку пакета безопасности протоколов Microsoft Kerberos. Кроме того, можно выбрать установку пакета безопасности протокола защиты информации (SSL) или любого другого интерфейса поставщика поддержки безопасности (SSPI), совместимого с SSP.

Можно ограничить пакеты безопасности, которые службы Analysis Services допускают для повышения безопасности экземпляра служб Analysis Services. Например, для повышения безопасности можно ограничить пакеты безопасности, которые службы Analysis Services допускают для пакета безопасности протокола Microsoft Kerberos.

Чтобы службы Analysis Services допускали только определенные пакеты безопасности, добавьте такие пакеты к свойству конфигурации сервера Security \ SecurityPackageList. По умолчанию пакеты безопасности не заданы, то есть допустимы все пакеты безопасности. Для доступа к этому свойству щелкните правой кнопкой мыши экземпляр служб Analysis Services, выберите пункт «Свойства» и найдите нужное свойство на странице «Безопасность».

 

 

 

 

2.4.4 Указание частоты обновления кэша ролей

 

 

По умолчанию службы Microsoft SQL Server Analysis Services обновляют членство пользователей и групп Microsoft Windows в ролях базы данных каждые 10 минут. Хотя установленное по умолчанию значение 10 минут и подходит для большинства сред, частоту обновления кэша роли можно увеличить, если членство роли часто изменяется.

Чтобы изменить установленный по умолчанию  параметр обновления кэша ролей, необходимо изменить свойство конфигурации сервера Security \ RoleCacheExpirationInterval. Чтобы получить доступ к этому свойству, щелкните правой кнопкой мыши экземпляр служб Analysis Services, выберите Свойства, а затем найдите нужное свойство на странице Безопасность.

 

 

 

 

2.5 Атаки на MS SQL Server

 

 

 

 

2.5.1 Взлом SQL сервера

 

 

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

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

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

Макс был осведомлен о многих политиках внутренней безопасности компании X, но поскольку он был лишь программистом по контракту, а не инженером безопасности или администратором NT, он не знал всех подробностей внутренней инфраструктуры, конфигураций брандмауэров или другой полезной информации, которая помогла бы совершить возмездие. Чтобы не вызывать подозрений, Макс воспользовался услугами общедоступного Internet-провайдера и провел полное сканирование портов граничных маршрутизаторов компании X. Чтобы определить диапазон IP-адресов компании, он сначала обратился к базам данных ARIN и Network Solutions, а затем просканировал их все с помощью программы f scan, используя для доступа в Internet только что созданную учетную. В результате сканирования Макс обнаружил около четырех Web-серверов, сервер SMTP/POP3 и какую-то программу, ожидающую подключения к ТСР-порту 1433. Все серверы точно находятся в домене компании X.