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

Выполнение кода с минимальными привилегиями

Установки по умолчанию

Один из базовых принципов создания безопасных приложений — принцип предоставления минимальных привилегий, необходимых для решения поставленной задачи, — в SQL реализован в намного более строгих настройках по умолчанию, нежели в предыдущих версиях. Так, в новой версии SQL Server по умолчанию отключено значительное количество функций, таких как применение Microsoft .NET Framework в ядре СУБД, функции SQL Service Broker Network Connectivity, доступ к аналитическим службам с помощью протокола HTTP. Такие службы, как SQL Server Agent, Data Transformation Services и средства полнотекстового поиска, после установки сервера требуют ручного запуска.

Управление контекстом выполнения кода

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

Одно из новшеств SQL Server 2005, реализующее принцип минимальных привилегий, позволяет выполнять хранимые процедуры и функции, определяемые пользователем, с правами другого пользователя. Для этой цели имеется оператор EXECUTE AS. Он позволяет более гибко управлять правами, предоставляемыми исполняемому коду, и не связывать их с правами самого пользователя. Указанная функциональность может применяться для безопасного управления правами пользователей. Так, решение такой часто встречающейся задачи, как предоставление доступа к процедуре без предоставления доступа к таблице, которую использует данная процедура, решается с помощью оператора EXECUTE AS без необходимости предоставления пользователям процедуры дополнительных привилегий. Конструкция EXECUTE AS, указываемая при создании соответствующего объекта базы данных, задает пользовательскую учетную запись, которую SQL Server будет использовать для проверки прав доступа к объектам, используемым в коде хранимой процедуры или пользовательской функции. В результате код, выполнение которого инициировано пользователем, выполняется так, как если бы пользователь зарегистрировался под другой учетной записью. Использование конструкции EXECUTE AS позволяет исключить цикличное назначение и проверку прав доступа при выполнении конструкций SELECT, INSERT, UPDATE, DELETE и EXECUTE, а также открытия непосредственного доступа к ряду объектов базы данных.

Уровни безопасности выполнения кода

Выполнение .NET-кода в ядре СУБД, будучи средством расширения функциональности сервера, представляет собой потенциальную уязвимость. Поэтому при загрузке сборки оно требует указания одного из трех уровней безопасности: SAFE (доступ к внешним ресурсам не допускается), EXTERNAL_ACCESS (допускается доступ к файлам, сетевым ресурсам, реестру, переменным окружения), UNSAFE (доступ ко всем ресурсам, в том числе к неуправляемому коду). Если сборка в процессе работы выйдет за указанные при ее загрузке параметры безопасности, Common Language Runtime сгенерирует исключение, и выполнение кода сборки прекратится.

Некоторые рекомендации

Ниже мы обсудим способы обеспечения безопасности при использовании управляемого кода. В первую очередь, поддержка применения Microsoft .NET Framework в ядре СУБД должна быть включена только в тех случаях, когда использование управляемого кода в приложении действительно необходимо. Кроме того, с целью сохранения стабильности работы самой СУБД управляемому коду следует присваивать минимально необходимый уровень привилегий, а пользовательский код должен выполняться в контексте пользовательской сессии, которая его вызвала, и с привилегиями, необходимыми для данного контекста, — в противном случае из пользовательского кода возможен неавторизованный доступ к данным. Не стоит напоминать, что пользовательский код не должен обращаться к ресурсам за пределами сервера.

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

Встроенные средства шифрования и поддерживаемые алгоритмы

SQL Server 2005 содержит встроенные средства шифрования, цифровой подписи и верификации данных с помощью симметричных ключей (алгоритмы шифрования RC4, RC2, DES, AES) и асимметричных ключей (алгоритм RSA). Весь трафик между клиентом и сервером по умолчанию шифруется с применением протоколов IP Security (IP SEC) и Secure Sockets Layer (SSL), причем подобная функциональность доступна во всех редакциях продукта. SQL Server 2005 позволяет при необходимости определить политику безопасности, полностью запрещающую обмен незашифрованными данными между клиентом и сервером, что снижает риск утечки данных, полученных путем перехвата трафика.

Протокол SSL поддерживается с помощью интеграции со службами Internet Information Services (IIS) или с помощью сервера сертификатов, поддерживающего стандарт X. 509v3 и входящего в состав SQL Server 2005. Сгенерированные сертификаты не только используются для создания SSL-соединений — их применяет и SQL Service Broker.

Шифрование данных на уровне колонок

SQL Server 2005 позволяет осуществить защиту данных на уровне колонок за счет шифрования хранимой в них информации. Он поддерживает также шифрование самих хранимых данных, полностью интегрированное с инфраструктурой управления ключами. Для этой цели служат встроенные функции EncryptByCert, DecryptByCert, EncryptByKey, DecryptByKey, EncryptByAssym, DecryptByAssym, позволяющие использовать шифрование с помощью сертификата, симметричного и асимметричного ключей в коде Transact-SQL. Необходимо, тем не менее, помнить о том, что шифрование данных может привести к потере производительности, поэтому при создании решений рекомендуется шифровать только конфиденциальные данные и осуществлять тестирование производительности готового решения.

Осуществляя шифрование на уровне колонок, следует также понимать, что зашифрованные данные нельзя сортировать, фильтровать и индексировать, и независимо от того, каким был тип исходных (незашифрованных) данных, их зашифрованная версия должна храниться как VARBINARY ().

Шифрование данных в интеграционных службах

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

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

Шифрование данных в службах отчетов

При генерации отчета службы отчетов выполняют запросы к источникам данных, на основании которых отчет генерируется. При этом, естественно, они используют данные об учетной записи для доступа к этим источникам данных. Для защиты данных об учетной записи обычно рекомендуется использовать механизмы SSL, особенно в случае, когда используются механизмы нестандартной аутентификации (custom authentication), либо когда для генерации отчетов используется обращение к внешним источникам данных, требующее дополнительной аутентификации. При доступе к службам отчетов через Internet следует использовать SSL не только для защиты учетных данных, но и данных самих отчетов.

Настоятельно рекомендуется сделать резервные копии ключей шифрования. Поскольку такие ключи создаются во время установки или последующей конфигурации сервера отчетов, в случае его аварии и последующего восстановления они потребуются для доступа к зашифрованным данным. Отметим, что клиентские приложения, обращающиеся к службам отчетов, также в ряде случаев должны обеспечить шифрование данных, для чего может быть использован механизм Data Protection Application Programming Interface (DPAPI). Помимо этого рекомендуется использовать минимальный уровень привилегий для выполнения таких приложений.

Шифрование данных, доступных с помощью протокола HTTP

Предоставление HTTP-доступа к ядру базы данных, позволяющее сделать данные доступными практически неограниченному числу пользователей, является одним из наиболее интересных новшеств в SQL Server 2005 (рис. 7).

Однако это нововведение несет в себе и определенную угрозу безопасности — ведь атаки с применением протокола HTTP являются сегодня одним из самых распространенных видов атак. Поэтому для защиты сервера и данных при реализации web - служб средствами SQL Server 2005 применяются общие принципы обеспечения безопасности в webприложениях и web-службах. Так, если планируется использовать web-службы для обмена конфиденциальной информацией между SQL Server и клиентом, следует использовать механизм SSL для обеспечения необходимого уровня ее защиты.

В SQL Server 2005 существует возможность обращаться к web-службам, созданным средствами SQL Server 2005, с применением следующих аутентификационных механизмов: Basic, Digest, NTLM, Kerberos и Integrated (NTLM и Kerberos). Механизм аутентификации Kerberos является наиболее защищенным, так как в нем используются более мощные по сравнению с другими механизмами алгоритмы шифрования. Кроме того, он способен аутентифицировать и сервер, и клиента, что позволяет избежать фарминга — получения конфиденциальных данных клиента с применением поддельного сервера.

Шифрование кода хранимых процедур и представлений

При необходимости можно воспользоваться механизмами шифрования кода хранимых процедур, для чего в конструкциях CREATE PROCEDURE и ALTER PROCEDURE следует использовать ключевое слово WITH ENCRYPTION. Имеется возможность шифрования кода представлений — для этого в конструкции CREATE VIEW или ALTER VIEW следует использовать ключевое слово WITH ENCRYPTION. Подобный способ ограничения доступа к коду представлений и процедур применяется при внедрении решений на основе SQL Server с целью защиты от несанкционированного внесения в него изменений. При этом исходный код хранимой процедуры или представления обязательно следует сохранить в проекте SQL Server на случай необходимости его модификации в будущем.

Аудит и защита метаданных

Аудит данных и метаданных

Аудит — достаточно распространенный способ выявления некорректных или неавторизованных действий пользователей, особенно пользователей, имеющих избыточные привилегии. SQL Server 2005 поддерживает несколько способов поддержки аудита. Он может использовать Windows Security EventLog (механизм отслеживания обращений к объектам, использования прав, попыток аутентификации), SQL Profiler (средство осуществления детального аудита попыток доступа к объектам БД).

Для осуществления аудита полезным может оказаться еще один новый механизм, появившийся в SQL Server 2005, — триггеры, связанные с изменением метаданных (DDL-триггеры). Создание подобных триггеров может позволить как отслеживать попытки изменения метаданных пользователями, так и полностью их запретить.

Скрытие метаданных

В SQL Server 2005 cистемные объекты находятся в скрытой базе mssqlsystemresource, при этом пользователям доступны представления Catalog Views для обращения к системным таблицам. Данные из этих представлений фильтруются в зависимости от того, кто делает запрос. Имеется и специальное разрешение VIEW DEFINITION, позволяющее обойти сокрытие метаданных всей БД, схемы или конкретного объекта.

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