Обзор механизмов защиты SQL Server 2008 для

Обзор механизмов защиты SQL Server 2008
для администраторов баз данных
Техническая описание SQL Server
Автор: Дон Кили (Don Kiely)
Автор дополнений: Джефф Элликс (Geoff Allix), Content Master
Технические редакторы: Сету Калавукар (Sethu Kalavukar), Самир Тежани
(Sameer Tejani), Эл Комо (Al Comeau), Роб Уолтерс (Rob Walters), Нирадж Награни
(Niraj Nagrani)
Дата публикации: октябрь 2007 г.
Тема: SQL Server 2008
Резюме. SQL Server 2008 имеет безопасную архитектуру, обеспечивает
безопасность стандартной конфигурации и безопасность при развертывании.
Майкрософт выступает за обмен информацией об угрозах, мерах противодействия и
усовершенствованиях защиты, поскольку это необходимо, чтобы как можно
надежнее защитить данные. В этой статье, адресованной администраторам баз
данных, рассматриваются некоторые наиболее важные механизмы защиты
SQL Server 2008. В ней объясняется, как выполнить безопасную установку
SQL Server и обеспечить защиту данных, когда с ними начнут работать приложения
и пользователи.
О защите авторских прав
Этот документ носит предварительный характер и может быть существенно изменен до выхода окончательной
коммерческой версии описанного в нем ПО.
В этом документе отражено мнение корпорации Майкрософт по обсуждаемым вопросам на момент его публикации.
Поскольку Майкрософт вынуждена реагировать на изменения конъюнктуры рынка, изложенное здесь не следует
рассматривать как обязательства со стороны Майкрософт. Майкрософт также не может гарантировать точность
представленной в документе информации после его публикации.
Данная официальная статья предназначена только для ознакомительных целей. МАЙКРОСОФТ НЕ ДАЕТ НИКАКИХ
ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ОТНОСИТЕЛЬНО ДАННОГО ДОКУМЕНТА.
Ответственность за соблюдение авторских прав возлагается на пользователя. Воспроизведение любой части
данного документа, ввод в системы хранения данных, хранение и передача в любом виде и любыми средствами
(механическими, электронными и пр.) без предварительного письменного разрешения корпорации Майкрософт
является нарушением авторских прав.
Майкрософт может владеть патентами, патентными заявками и другими правами на интеллекутальную
собственность, касающимися содержимого данного документа. Предоставление документа не дает права на
использование этих патентов, товарных знаков и других прав интеллектуальной собственности за исключением
явно оговоренных в письменном лицензионном соглашении с Майкрософт.
Если не сказано обратное, все названия компаний, организаций, товаров, доменные имена, почтовые адреса,
логотипы, имена людей, названия населенных пунктов и события, упоминающиеся в тексте, являются
вымышленными и не имеют отношения к реальным организациям, предметам, лицам и событиям, все совпадения
являются случайными.
© 2007 Корпорация Майкрософт. Все права защищены.
Microsoft и SQL Server являются зарегистрированными товарными знаками корпорации Майкрософт в США и/или
других странах.
Все остальные товарные знаки, упомянутые в данном документе, являются собственностью своих владельцев.
Содержание
Введение ..........................................................................................................1
Безопасная конфигурация ..............................................................................2
Windows Update ............................................................................................. 2
Конфигурация области атаки .......................................................................... 2
Аутентификация ..............................................................................................3
Введение в действие политик управления паролями ........................................ 4
Аутентификация конечных точек .................................................................... 6
Авторизация .....................................................................................................8
Тонкое управление разрешениями .................................................................. 8
Участники и объекты, для которых устанавливается защита ........................ 9
Роли и разрешения ................................................................................. 10
Защита метаданных ..................................................................................... 12
Прокси SQL Server Agent .............................................................................. 12
Контекст выполнения ................................................................................... 16
Разделение пользователя и схемы ................................................................ 18
Шифрование и управление ключами ...........................................................21
Шифрование данных .................................................................................... 21
Прозрачное шифрование данных ............................................................. 24
Расширяемое управление ключами .......................................................... 24
Подписание кодовых модулей .................................................................. 25
Аудит в SQL Server 2008 ................................................................................26
Аудит всех операций .................................................................................... 26
DDL-триггеры .............................................................................................. 28
Заключение ...................................................................................................29
SQL Server 2008 Security Overview for Database Administrators
1
Введение
Чем больше сетей объединяется между собой, тем важнее становятся вопросы
безопасности. Все активы вашей компании, особенно базы данных, содержащие
ценную информацию, должны быть защищены. Обеспечение безопасности — одна
из критически важных функций ядра баз данных, защищающая предприятие от
несметного числа угроз. При разработке средства защиты Microsoft SQL Server 2008
преследовалась цель сделать их более доступными и понятными специалистам,
которые занимаются защитой данных.
В течение последних нескольких лет в мире сложилось гораздо более глубокое
понимание того, какой должна быть безопасная компьютерная система.
Майкрософт играла ведущую роль в выработке этого понимания, а SQL Server —
один из первых серверных продуктов, которые полностью ему соответствуют. Он
реализует принцип наименьшей привилегии, согласно которому вы не должны
давать пользователям больше разрешений, чем требуют их должностные
обязанности. Он предоставляет всеобъемлющие средства, которые позволят вам
поставить в тупик даже самых изощренных злоумышленников.
О концепции Майкрософт Trustworthy Computing, на приниципах которой должа
основываться разработка ПО в компании, уже много написано и сказано.
Дополнительную информацию см. на Web-сайте Trustworthy Computing
(http://www.microsoft.com/mscorp/twc/default.mspx).
Эта коцепция состоит из четырех основных принципов.

Безопасная архитектура (secure by design). ПО должно иметь безопасную
архитектуру, являющуюся основой для борьбы со злоумышленниками и защиты
данных.

Безопасная стандартная конфигурация (secure by default). Системные
администраторы не должны тратить силы на то, чтобы сделать только что
установленную систему безопасной; это должно обеспечиваться по умолчанию.

Безопасное развертывание (secure in deployment). ПО должно помогать
администратору себя защищать, самостоятельно устанавливая последние
защитные «заплатки» и обеспечивая удобство поддержки.

Обмен информацией (communications). Обмен передовыми методиками и
информацией о постоянно появляющихся новых угрозах позволяет
администраторам заблаговременно защищать свои системы.
Эти основополагающие принципы отчетливо прослеживаются во всех аспектах
SQL Server 2008, предоставляющего все средства, необходимые для защиты баз
данных.
В статье рассматриваются наиболее важные для системных администраторов и
администраторов баз данных средства защиты. Сначала в ней показывается,
насколько проста безопасная установка и настройка SQL Server 2008. Затем
рассказывается о средствах аутентификации и авторизации, управляющих
доступом к серверу и определяющих, что вправе делать пользователь, прошедший
аутентификацию. Наконец, речь пойдет о средствах защиты баз данных, которыми
должен владеть администратор, чтобы создать безопасную среду для баз данных и
приложений, обращающихся к этим базам данных.
Microsoft Corporation ©2007
SQL Server 2008 Security Overview for Database Administrators
2
Безопасная конфигурация
Для безопасной установки SQL Server, прежде всего, необходима безопасная
среда. В требованиях к защите SQL Server 2008 от внешнего доступа ничего особо
не изменилось. Вы должны физически защитить сервер, регулярно резервировать
данные, защитить сервер одним или несколькими брандмауэрами (если он
подключен к внешней сети), не устанавливать SQL Server на компьютер, на
котором выполняются другие серверные приложения и активизировать только
минимально необходимый набор сетевых протоколов. Устанавливайте SQL Server
на компьютеры с Microsoft Windows Server 2003 или Microsoft Windows Server 2008,
чтобы в полной мере воспользоваться защитными механизмами уровня
операционной системы. Кроме того, безопаснее всего устанавливать SQL Server в
одном или нескольких разделах NTFS.
После подготовки безопасной среды крайне важно безопасно установить
SQL Server 2008. Установочная программа выполняет все, что обычно делается при
установке, и использует System Configuration Checker, чтобы уведомить вас о
недостатках, которые могут привести к проблемам. В стандартной конфигурации,
создаваемой при установке SQL Server 2008, не будут активизированы все
функции. Вмето этого устанавливаются базовые обязательные средства и средства,
которые часто используют. Другие функции, которые не обязательно понадобаятся
в производственной среде, по умолчанию отключены. Их можно активизировать с
помощью инструментальных средств SQL Server 2008.
Все это — требования принципа Trustworthy Computing «безопасная стандартная
конфигурация». Он означает, что SQL Server 2008 будет безопасен после того, как
вы его установите, и что его параметры по умолчанию безопасны. Средства,
которые не являются необходимыми для стандартного сервера баз данных,
остаются неустановленными, чтобы сократить «область атаки» (surface area). Не во
всех системах в стандартной конфигурации активизированы все функции, поэтому
установленные образы систем становятся гетерогенными. Поскольку в результате
сокращается количество систем, в которых имеются функции, уязвимые для
потенциальных атак, обеспечивается лучшая защита от крупномасштабных атак
или «червей».
Windows Update
Новые угрозы или уязвимости могут обнаружиться уже после развертывания SQL
Server на вашем предприятии. Windows Update — средство, разработанное, чтобы
своевременно скачивать и устанавливать «заплатки», что позволяет значительно
сократить количество проблем, связанных с безопасностью. С помощью Windows
Update можно автоматически устанавливать «заплатки» для SQL Server 2008 и,
таким образом, уменьшить опасность угроз, связанных с известными уязвимостями
ПО. В большинстве корпоративных сред следует управлять распространением
«заплаток» и обновлений по организации с помощью Windows Server Update
Service (WSUS).
Конфигурация области атаки
В SQL Server 2008 имеется много различных средств, многие из которых
устанавливаются в отключенном состоянии. Например, средства интеграции с CLR,
средства зеркалирования баз данных, отладки, Service Broker, средства обмена
Microsoft Corporation ©2007
SQL Server 2008 Security Overview for Database Administrators
3
электронной почтой устанавливаются, но не запускаются, если вы явно не
активизируете или не настроите их. Такая архитектура соответствует парадигме
соркащения области атаки, являющейся элементом философии «безопасная
конфигурация по умолчанию» и, в самом деле, сокращает область атаки. Если
средство недоступно или неактивно, то злоумышленник не сможет им
воспользоваться.
Платой за это является то, что придется потратить время на изучение
всевозможных операторов Transact-SQL, активизирующих те или иные функции.
Даже если вы обнаружите, что большую часть того, что вам нужно, делает
хранимая процедура sp_configure system, вам все равно придется писать не
понятный интуитивно код следующего вида:
sp_configure 'show advanced options', 1
reconfigure with override
sp_configure 'clr enabled', 1
Конфигурационных параметров слишком много для того, чтобы тратить время на
написание такого кода, особенно если у вас множество экземпляров SQL Server,
развернутых по всей организации. В SQL Server 2008 реализована технология,
управления, основанная на политиках, — Declarative Management Framework
(DMF). В DMF имеется несколько конфигурационных аспектов (Facets), каждый из
которых определяет набор взаимосвязанных параметров или свойств. С помощью
аспектов можно создавать условия (Conditions), задающие требуемые значения
конфигурационных параметров, а затем можно вводить эти условия в действие как
политики (Policies) на экземплярах SQL Server, установленных на предприятии.
Одини из аспектов, доступных в SQL Server 2008 — аспект Surface Area (область
атаки), с помощью которого можно определить политику, управляющую состоянием
различных средств SQL Server 2008. Создав политику, определяющую требуемую
область атаки для ваших серверов, вы можете без усилий задать минимальную
область атаки для всех экзмеляров SQL Server вашего предприятия, уменьшив
вероятность атаки злоумышленников.
Аутентификация
Майкрософт рарабатывала SQL Server 2000 во времена, когда данные и серверы
требовали защиты, но не должны были выдерживать град бешеных атак через
Интернет, как теперь. Основные вопросы, возникающие при аутентификации,
остались такими же: «кто вы?» и «как вы можете это подтвердить?», но
SQL Server 2008 предоставляет гораздо более надежные средства аутентификации,
лучше позволяющие определить защитные границы, внутрь которых допускаются
хорошие парни и не допускаются плохие.
SQL Server Authentication (аутентификация SQL Server) обеспечивает
аутентификацию клиентов, не использующих Windows, или приложений, которые
используют простые строки соединения, содержащие имена и пароли
пользователей. Хотя такой способ входа прост и популярен среди разработчиков
приложений, он не настолько безопасен как аутентификация Windows, и не
рекомендуется к использованию в качестве механизма аутентификации.
В SQL Server 2008 в аутентификацию SQL Server внесены усовершенствования. Вопервых, по умолчанию поддерживается шифрование канала с помощью
сертификатов, генерируемых SQL Server. Администраторам не требуется получать и
Microsoft Corporation ©2007
SQL Server 2008 Security Overview for Database Administrators
4
устанавливать допустимые SSL-сертификаты, чтобы обеспечить безопасность
канала, по которому передаются удостоверения SQL Server. SQL Server 2008
автоматически генерирует такие сертификаты SQL Server 2008 и по умолчанию
обеспечивает автоматическое шифрование пакетов с данными для входа,
передаваемых по каналу. Это происходит, если используется клиент от
SQL Server 2005 или более поздней версии.
Примечание «Родные» сертификаты, генерируемые SQL Server, защищают от
пассивной атаки посредника, когда злоумышленник прослушивает сеть. Чтобы
защитить сеть от активной атаки посредника, следует развернуть и
использовать сертификаты, которым доверяют и клиенты.
В SQL Server 2008 внесены дальнейшие усовершенствования в аутентификацию
SQL Server: теперь ядро баз данных использует Windows Group Policy для
управления сложностью и сроком действия паролей и блокировки учетных записей
SQL Server, если SQL Server установлен на сервере с Windows 2003 или более
поздней версии. Значит, можно применять политику управления паролями Windows
к учетным записям SQL Server.
Введение в действие политик управления
паролями
В SQL Server 2008 политика управления паролями встроена в сервер. С помощью
API NetValidatePasswordPolicy(), входящей в библиотеку NetAPI32 Windows
Server 2003, SQL Server проверяет пароль на допустимость при аутентификации и
во время задания и изменения пароля: в соответствии с политиками Windows
проверяются стойкость и срок действия, а также критерии блокировки учетной
записи. В табл. 3 перечислены параметры, определяющие политику.
Табл. 3. Компоненты политики управления паролями Windows Server 2003
Категория
Наименование
Описание
Password Policy
(политика
управления
требованиями к
паролям)
Enforce password history
(запоминать старые
пароли)
Не позволяет пользователям
повторно использовать старые
пароли, например, чередовать два
пароля
Minimum password length
(минимальная длина
пароля)
Password must meet
complexity requirements
(Пароль должен
удовлетворять
требованиям сложности)
См. ниже.
Store passwords using
reversible encryption
(получать пароли с
помощью обратимого
шифрования)
Позволяет получать пароли от
Windows. Никогда не
активизируйте этот режим, если
только требования приложения не
оказываются важнее, чем
Microsoft Corporation ©2007
SQL Server 2008 Security Overview for Database Administrators
5
необходимость использовать
безопасные пароли. (Этот
параметр не применим к
SQL Server.)
Password
Expiration (cрок
действия
паролей)
Maximum password age
(максимальный срок
действия)
Minimum password age
(минимальный срок
действия)
Account Lockout
Policy (политика
управления
блокировками
учетных записей)
Account lockout duration
(продолжительность
блокировки учетной
записи)
Продолжительность блокировки
учетной записи в минутах.
Windows позволяет задавать этот
параметр, если пороговое
значение, после которого учетная
запись блокируется, > 0.
Account lockout threshold
(пороговое значение,
после которого учетная
запись блокируется)
Максимальное количество
неудачных попыток входа
Reset account lockout
counter after (время, по
истечении которого
сбрасывается счетчик)
Время в минутах, по истечении
которого сбрасывается счетчик
неудачных попыток входа.
Windows позволяет задавать этот
параметр, если пороговое
значение, после которого учетная
запись блокируется, > 0.
Если вы не используете Windows Server 2003 или более поздней версии, SQL Server
тоже вводит в действия требования к стойкости пароля, не допуская следующие
пароли:

Null или пустая строка;

cовпадающие с именем компьютера или учетной записи;

пароли вида "password", "admin", "administrator", "sa", "sysadmin".
Одни и те же стандарты проверки сложности применяются ко всем паролям,
которые создаются и используются в SQL Server, в том числе паролям пользователя
sa, ролей приложений, мастер-ключей базы данных для шифрования и
симметричных ключей шифрования.
По умолчанию SQL Server всегда выполняет проверки политики управления
паролями, но вы можете приостановить ее применение для отдельных учетных
записей с помощью операторов CREATE LOGIN или ALTER LOGIN:
CREATE LOGIN bob WITH PASSWORD = 'S%V7Vlv3c9Es8',
CHECK_EXPIRATION = OFF, CHECK_POLICY = OFF
Microsoft Corporation ©2007
SQL Server 2008 Security Overview for Database Administrators
6
CHECK_EXPIRATION относится к части политики Windows Server 2003,
управляющей проверкой минимального и максимального срока действия пароля, а
CHECK_POLICY относится к остальным параметрам политики.
Кроме того, административные параметры позволяют включать и отключать
проверку соответствия паролей политике и требовать, чтобы пользователь сменил
пароль при первом входе. Параметр MUST_CHANGE в CREATE LOGIN указывает, что
пользователь должен сменить пароль при следующем входе. На стороне клиента он
позволяет сменить пароль при входе. Все новые технологии доступа к данным на
стороне клиента, в том числе OLE DB и ADO.NET, а также клиентские средства,
такие как Management Studio, будут поддерживать эту функцию.
Если пользователь совершил слишком много неудачных попыток входа и превысил
количество, разрешенное политикой, SQL Server блокирует учетную запись в
соответствии с параметрами политики Windows. Администратор может
разблокировать учетную запись оператором ALTER LOGIN:
ALTER LOGIN alice WITH PASSWORD = '3x1Tq#PO^YIAz' UNLOCK
Аутентификация конечных точек
При клиентском доступе к данным SQL Server 2008 поддерживает как
исподьзование традиционного двоичного Tabular Data Stream, так и «родной» для
Web-сервисов XML доступ через HTTP. Основное преимущестсво доступа через
HTTP — то, что клиентское ПО и средства разработки, поддерживающие протоколы
Web-сервисов, могут обращаться к данным, хранящимся в SQL Server. Это
означает, что SQL Server 2008 способен как реализовывать отдельные методы Webсервисов, так и быть полноценной конечной точкой в архитектуре,
ориентированной на сервисы (Service Oriented Architecture, SOA).
Чтобы использовать SQL Server 2008 как хост Web-сервиса, необходимо выполнить
две основных операции, у каждой из которых множество вариантов: определение
хранимых процедур и пользовательских функций, реализующих методы Webсервиса, и определение конечной точки HTTP, которая принимает вызовы методов
по протоколу HTTP и направляет их соответствующей процедуре. В этой статье
рассматриваются вопросы безопасности. Поднобные сведения о настройке и
использовании конечных точек HTTP см. по заголовку CREATE ENDPOINT (TransactSQL) в SQL Server Books Online.
Поскольку Web-сервисы XML в SQL Server используют HTTP и, по умолчанию
работают с портом 80, большинство брандмауэров пропускает трафик. Однако
незащищенная конечная точка — потенциальный объект атаки и вы должны ее
защитить, поэтому SQL Server поддерживает стойкие технологии аутентификации и
авторизации. По умолчанию у SQL Server нет никаких конечных точек, а для
создания, изменения и активизации конечных точек HTTP необходимо иметь
высокий уровень разрешений.
SQL Server 2008 поддерживает пять различных типов аутентификации,
аналогичных типам, используемым IIS при аутентификации на Web-сайтах.

Базовая аутентификация (basic authentication)
Базовая аутентификация описывается протоколом HTTP 1.1. Удостоверения для
входа передаются открытым текстом, зашифрованным по алгоритму base-64.
Удостоверения должны соответствовать учетной записи Windows, которая затем
используется SQL Server для предоставления доступа к ресурсам базы данных.
Microsoft Corporation ©2007
SQL Server 2008 Security Overview for Database Administrators
7
При выборе аутентификации Basic вы не сможете указывать значение CLEAR
для аргумента PORTS, но можно задать значение SSL и использовать цифровой
сертификат и SSL, чтобы шифровать данные, которыми сервер обменивается с
клиентским ПО.

Хэш-аутентификация (digest authentication)
Хэш-аутентификация также описывается протоколом HTTP 1.1. Удостоверения
хэшируются с помощью алгоритма MD5 перед отправкой на сервер, так что они
не передаются по сети, даже в зашифрованном виде. Удостоверения должны
соответствовать допустимой доменной учетной записи Windows; нельзя
использовать удостоверения локального пользователя.

Аутентификация NTLM (NTLM authentication)
В NTLM используется протокол «запрос-ответ», первоначально введенный в
Microsoft Windows NT и с тех пор поддерживаемый всеми клиентскими и
серверными версиями Windows. Он обеспечивает безопасную аутентификацию,
когда и клиент, и сервер — системы Windows, и требует указания допустимой
доменной учетной записи.

Аутентификация Kerberos (Kerberos authentication)
Аутентификация Kerberos доступна в Windows 2000 или более поздних версий,
основывается на протоколе, явяющемся отраслевым стандартом и доступным во
многих операционных системах. Поддерживается взаимная аутентификация,
при которой клиент и сервер достоверно идентифицируют друг друга,
обеспечивается высокая безопасность аутентификации. Чтобы использовать
Kerberos в Windows Server 2003 необходимо зарегистрировать Kerberos Service
Principal Name (SPN) в Http.sys с помощью утилиты SetSPN.exe, входящей в
Windows Support Tools.

Встроенная аутентификация (integrated authentication)
Встроенная аутентификация совмещает в себе лучшие черты аутентификаций
NTLM и Kerberos. Сервер выбирает тот из двух типов аутентификации, который
запрашивается клиентом, используя наиболее безопасный механизм
аутентификации из поддерживаемых клиентом и в то же время обеспечивая
доступность сервиса для старых версий Windows. В Windows 2003 можно
настроить Http.sys на согласование используемого протокола с клиентом.
Метод аутентификации, используемый конечной точкой, задается атрибутом
AUTHENTICATION оператора CREATE или ALTER ENDPOINT. Например, следующий
код создает конечную точку, использующую аутентификацию Kerberos:
CREATE ENDPOINT myEndpoint
STATE=STARTED
AS HTTP (PATH = '/MyHttpEndpoint',
AUTHENTICATION = (KERBEROS),
PORTS = (CLEAR),
SITE = 'MySqlServer')
FOR SOAP (WSDL = DEFAULT,
DATABASE = 'myDB',
NAMESPACE = 'http://example.com/MySqlServer/myDB/WebService')
SQL Server 2008 поддерживает конечные точки, поддерживающие как HTTP, так и
TCP-порты, определенные пользователем. Кроме того, можно поддерживать
Microsoft Corporation ©2007
SQL Server 2008 Security Overview for Database Administrators
8
различные форматы запросов: SOAP, Transact-SQL, формат, специфичный для
Service Broker или формат, используемый при зеркалировании баз данных. При
использовании SOAP можно выполнять аутентификацию учетных записей
SQL Server с помощью заголовков WS-Security.
Майкрософт реализовала аутентификацию конечных точек Web-сервисов, чтобы
поддерживать широкий круг протоколов и спецификаций, лишь слегка затронутых
в этой статье. Вам придется явно активизировать интересующий вас вариант
аутентификации и удостовериться, что клиенты способны предоставить требуемые
типы удостоверений. Когда SQL Server выполнит аутентификацию клиента, вы
сможете предоставить клиенту ресурсы, на доступ к которым у него имеются
полномочия. Об этом рассказывается в следующем разделе.
Авторизация
После аутентификации наступает время подумать о том, что вправе делать
пользователь, учетная запись которого прошла аутентификацию. SQL Server 2008 и
SQL Server 2005 более гибки в этом отношении, чем предыдущие версии.
Управление разрешениями стало гораздо более тонким: стало можно предоставлять
требуемое конкретное разрешение, а не задавать членство в фиксированной роли,
у которой, возможно, больше разрешений, чем необходимо. Стало гораздо больше
сущностей, объектов, которые можно защищать, а разрешения на доступ к этим
объектам стали более гибкими.
Усовершенствования защиты касаются не только пользовательских данных.
Информация о структуре и метаданные того или иного объекта теперь доступны
только участникам, имеющим разрешения на доступ к этому объекту.
Кроме того, стало можно создавать собственные наборы разрешений с помощью
механизма, позволяющего определить контекст защиты, в котором может
выполняться хранимая процедура.
Наконец, в SQL Agent используется гибкая прокси-схема, позволяющая выполнять
операции заданий и обеспечивать им доступ к требуемым ресурсам. Благодаря
всем этим возможностям SQL Server стал гораздо сложнее, но и гораздо
безопаснее.
Тонкое управление разрешениями
Одно из усовершенствований, благодаря которым SQL Server 2008 и SQL Server
2005 стали намного безопаснее, чем предыщие версии, — увеличение детальности
разрешений. Раньше администраторам приходилось предоставлять пользователям
членство в фиксированных ролях сервера или базы данных, чтобы пользователи
могли выполнять определенные операции. В большинстве случаев полномочия этих
ролей были слишком широкими для простых задач. Принцип наименьшей
привилегии требует, чтобы у пользователя был минимум разрешений,
необходимыцй для его работы, а предоставление пользователю роли с широкими
полномочиями для выполнения ограниченного набора операций нарушает этот
принцип.
Набор фиксированных ролей сервера и базы данных в основном не изменился по
сравнению с SQL Server 2000, так что по-прежнему можно использовать заранее
определенные наборы разрешений, когда пользователям или приложениям
необходимы все или почти все указанные в них разрешения. Пожалуй, самое
Microsoft Corporation ©2007
SQL Server 2008 Security Overview for Database Administrators
9
крупное изменение — добавление серверной роли public. Однако согласно
принципу наименьшей привилегии нельзя использовать роли, которые разрешают
больше, чем нужно участнику для выполнения своей работы. Хотя для
обнаружения и предоставления разрешений потребуется потратить больше усилий,
чем раньше, в результате среда базы данных станет гораздо безопаснее.
Участники и объекты, для которых
устанавливается защита
В SQL Server 2008 участник (principal) — это любой сотрудник, группа сотрудников
или процесс, котором может потребоваться доступ к защищенному ресурсу и
которому можно предоставить разрешение на такой доступ. Как и в предыдущих
версиях SQL Server, можно определить участника средствами Windows или можно
создать для него учетную запись SQL Server, которой не соответствует участник
Windows. В приведенном ниже списке показана иерархия участников
SQL Server 2008, за исключением фиксированных ролей сервера и базы данных, и
то, как можно сопоставить учетные записи и пользователей базы данных объектам,
применяемым для защиты. Сфера влияния участника зависит от области, в которой
он определен, например, участник уровня Windows определен в более широкой
области, чем участник уровня SQL Server, а тот, в свою очередь, — в более
широкой области, чем участник уровня базы данных. Каждый пользователь базы
данных автоматически относится к фиксированной роли public.
Участники уровня Windows

Доменная учетная запись

Локальная учетная запись Windows

Группа Windows
Участники уровня SQL Server

Учетная запись SQL Server

Учетная запись SQL Server, сопоставленная учетной записи Windows

Учетная запись SQL Server, сопоставленная сертификату

Учетная запись SQL Server, сопоставленная асимметричному ключу
Участники уровня базы данных

Пользователь базы данных

Пользователь базы данных, сопоставленный учетной записи SQL Server

Пользователь базы данных, сопоставленный учетной записи Windows

Пользователь базы данных, сопоставленный сертификату

Пользователь базы данных, сопоставленный асимметричному ключу

Роль базы данных

Роль приложения

Роль Public
Другой стороной авторизации являются объекты, на которые можно давать или
отбирать разрешения. На рис. 4 приведена иерархия объектов SQL Server 2008,
для которых можно устанавливать защиту. На уровне сервера можно защищать
конечные точки сети, чтобы управлять каналами передачи данных серверу и с
Microsoft Corporation ©2007
SQL Server 2008 Security Overview for Database Administrators
10
сервера, а также базы данных, привязки, роли и учетные записи. На уровне базы
данных и схемы вы можете защитить почти каждый объект, который вы можете
создать, в том числе те объекты, которые относятся к схеме.
Сервер
База данных
Конечная точка
Удаленная
привязка
Маршрут
Учетная запись
SQL Server
База данных
Схема
Роль приложения
Сборка
Асимметричный ключ
Сертификат
Пользователь базы данных
Фиксированная роль базы
данных
Каталог для
полнотекстового поиска
Тип сообщения
Сервис
Контракт сервиса
Симметричный ключ
Роль приложения
Схема
Значение по умолчанию
Функция
Процедура
Статистика запросов
Очередь
Правило
Синоним
Таблица
Триггер
Тип
Представление
Набор определений XML
Schema
Рис. 4. Иерархия объектов SQL Server 2008, для которых можно установить
защиту
Роли и разрешения
Чтобы почувствовать, сколько всевозможных разрешений доступно в SQL Server,
вызовите системную функцию fn_builtin_permissions:
SELECT * FROM sys.fn_builtin_permissions(default)
Вот новые типы разрешений, введенные в SQL Server 2005.

CONTROL. Предоставляет права, аналогичные правам владельца, по сути,
даются все разрешения, определенные для самого объекта и объектов, которые
ему принадлежат, в том числе возможность давать любые разрешения на них
другим участникам. CONTROL SERVER дает такие же привилегии, как sysadmin.

ALTER. Предоставляет права на изменение любых свойств объекта, за
исключением права на смену владельца. Кроме того, даются разрешения ALTER,
CREATE и DROP на объекты, принадлежащие этому объекту. Например, при
предоставлении разрешения ALTER на базу данных дается разрешение изменять
все ее таблицы.

ALTER ANY <тип объекта>. Дает разрешение изменять любой объект
заданного типа. Например, при предоставлении разрешения ALTER ANY
ASSEMBLY дается право на изменение любой .NET-сборки в базе данных, а при
предоставлении разрешения ALTER ANY LOGIN пользователь получает право
изменять любую учетную запись на данном сервере.

IMPERSONATE ON <учетная запись или пользоваотель>. Дает разрешение
действовать от имени данного пользователя или учетной записи. Как вы
увидите дальше, это разрешение необходимо для переключения контекста
выполнения хранимых процедур. Кроме того, оно нужно для подмены
пользователя при выполнении пакета.
Microsoft Corporation ©2007
SQL Server 2008 Security Overview for Database Administrators

11
TAKE OWNERSHIP. Дает разрешение брать объект во владение с помощью
оператора ALTER AUTHORIZATION.
В SQL Server 2008 для того, чтобы предоставлять разрешения участнику или
отбирать их, по-прежнему используется знакомая схема GRANT, DENY и REVOKE.
Оператор GRANT позволяет указывать все новые параметры разрешений, в том
числе область действия разрешения и то, может ли участник представлять
разрешение другим участникам. SQL Server не позволяет давать разрешения на
несколько баз данных. Чтобы предоставить такие разрешения, создают копию
пользователя в каждой базе данных и по отдельности назначают разрешение
каждой такой копии.
Как и в предыдущих версиях SQL Server, при активизации роли приложения
действие других разрешений приостанавливается на период, в течение которого
эта роль активна. Однако в SQL Server 2008 и SQL Server 2005 имеется
возможность деактивировать (unset) роль приложения. Еще одно отличие
SQL Server 2000 и более поздних версий заключается в том, что при активизации
роли приложения приостанавливается действие любых серверных привилегий, в
том числе public. Например, если вы дадите public разрешение VIEW ANY
DEFINITION, роль приложения не будет его учитывать. Это наиболее отчетливо
проявляется при доступе к метаданным серверного уровня в контексте роли
приложения.
Примечание Появилась новая лучшая альтернатива ролям приложения —
контекст выполнения модулей кода. Дополнительную информацию см. в
разделе «Контекст выполнения».
Предоставление того или иного разрешения может повлечь за собой
предоставление других разрешений. Например, разрешение ALTER на схему
«включает в себя» более тонкие и низкоуровневые разрешения, которые из него
«следуют». На рис. 5 показаны разрешения, вытекающие из разрешения ALTER
SCHEMA. См. в разделе SQL Server Books Online «Covering/Implied Permissions
(Database Engine)» код пользовательской функции ImplyingPermissions (на
Transact-SQL), который формирует иерархию по представлению каталога
sys.fn_builtin_permissions и идентифицирует глубину каждого представления
иерархии. После добавления ImplyingPermissions в базу данных master я выполнил
следующий код, в котором указал объект и тип разрешения, и получил вывод,
приведенный на рис. 5:
SELECT * FROM master.dbo.ImplyingPermissions('schema', 'alter')
ORDER BY height, rank
Это отличный способ исследовать иерархию разрешений в SQL Server 2008.
Microsoft Corporation ©2007
SQL Server 2008 Security Overview for Database Administrators
12
Рис. 5. Иерархия разрешений, которые следуют из ALTER SCHEMA
Когда вы подумаете о количестве доступных участников и их типов, о количестве
объектов сервера и типичной базы данных, доступом к которым можно управлять, и
о том, как много имеется доступных разрешений и разрешений, которые они
охватывают или из них следуют, сразу станет очевидно, насколько гибкое
управление разрешениями обеспечивает SQL Server 2008. Для создания базы
данных теперь требуются гораздо более детальный анализ ее требований к
безопасности и аккуратное управление разрешениями на все объекты. Тем не
менее, усилия, затрачиваемые на этот анализ, окупаются, и использование новых
возможностей SQL Server 2008 позволяет создавать более безопасные базы
данных.
Защита метаданных
Одно из преимуществ тонкого механизма управления разрешениями состоит в том,
что метаданные теперь защищены SQL Server так же хорошо, как данные. До
появления SQL Server 2005 пользователь с любым уровнем доступа к базе данных
мог видеть метаданные всех объектов, независимо от того, мог ли он обращаться к
данным объектов и выполнять хранимые процедуры.
SQL Server 2008 проверяет, какие разрешения на объекты базы данных имеет
участник и возвращает метаданные, только если участник является его владельцем
или имеет определенные разрешения на объект. Кроме того, имеется разрешение
VIEW DEFINITION, позволяющее просматривать метаданные, но не дающее никакие
другие разрешения на объект.
Такая защита распространяется и на сообщения об ошибках, возвращаемых при
попытки прочитать данные объекта, на который пользователь не имеет прав, или
изменить его. Теперь вместо сообщения, из которого следует, что действительно
существует таблица с именем Address, SQL Server выводит сообщение об ошибке,
подразумевающее различные варианты, чтобы не давать злоумышленникам
подтверждение существования этой таблицы. Например, если пользователь, не
имеющий разрешения ни на какие объекты базы данных, попытается удалить
таблицу Address, SQL Server выведет следующее сообщение об ошибке:
Msg 3701, Level 14, State 20, Line 1
Cannot drop the table 'Address', because it does not exist or you do not
have permission.
В результате злоумышленник не получит подтверждение того, что таблица Address
в самом деле существует. Однако это означает, что при отладке кода придется
рассматривать несколько вариантов.
Прокси SQL Server Agent
Один из лучших примеров модели авторизации, используемой SQL Server 2008, —
SQL Server Agent. Можно определить различные удостоверения (которые часто
связывают с учетными записями Windows), и связать их с пользователями,
имеющими разрешения, необходимые для выполнения одной или нескольких
операций SQL Server Agent. Прокси SQL Server Agent связывает удостоверение с
операцией задания, чтобы предоставить необходимые разрешения.
Microsoft Corporation ©2007
SQL Server 2008 Security Overview for Database Administrators
13
В результате администратор получает гибкие средства, позволяющие реализовать
принцип наименьшей привилегии: пользователь, выполняющий операцию задания,
получает разрешения, необходимые для этой операции, и ничего более. Можно
создать столько прокси, сколько вам требуется, и связать каждый из них с одной
или нескольким подсистемами SQL Server Agent. Такой подход отчетливо
контрастирует с использованием в SQL Server 2000 всемогущей учетной записи,
которая позволяла пользователю создавать операции заданий в любых
подсистемах SQL Server Agent.
Примечание Когда осуществляется обновление сервера с версии
SQL Server 2000, создается единственная учетная запись прокси и эта
единственная учетная запись прокси связывается со всеми подсистемами, чтобы
существующие задания остались работоспособными. После обновления
создайте удостоверения и учетные записи прокси, чтобы набор прокси были
более гибкими и безопасным и обеспечивал лучшую защиту ресурсов сервера.
На рис. 6 показано открытое в Management Studio окно Object Explorer, в котором
перечислены подсистемы, доступные в SQL Server Agent. С каждой подсистемой
можно связать один или несколько прокси, которым предоставлены разрешения,
необходимые для выполнения операций заданий. Единственное исключение из
этой схемы — то, что подсистемы Transact-SQL по-прежнему выполняются с
разрешениями владельца модуля, как это было в SQL Server 2000.
Рис. 6. Подсистемы SQL Server Agent, которые можно связать с прокси
В только что установленном SQL Server разрешение на определение заданий SQL
Server Agent имеет только роль System Administrator, а панель управления в
окне Object Explorer приложения Management Studio, доступна только членам роли
sysadmins. В SQL Server 2008 доступно несколько новых ролей, которым можно
давать различные уровнеи разрешений. Можно назначать пользователям роли
SQLAgentUser, SQLAgentReaderRole и SQLAgentOperator, каждая из которых
дает все больший уровень разрешений на создание, изменение и запуск заданий,
или роль MaintenanceUser, имеющая все разрешения SQLAgentUser и, кроме
того, право создавать планы обслуживания.
Microsoft Corporation ©2007
SQL Server 2008 Security Overview for Database Administrators
14
Члены роли sysadmin, конечно, могут делать все, что захотят, с любой
подсистемой. Чтобы дать права на работу с подсистемой любому другому
пользователю, необходимо создать хотя бы одну учетную запись прокси и
предоставить ей права на доступ к одной или нескольким подсистемам. На рис. 7
показана учетная запись прокси MyProxy, назначенная нескольким участникам,
среди которых пользователь и роль. Учетная запись прокси использует
удостоверение, связанное с учетной записью (обычно доменной учетной записью),
имеющей разрешения операционной системы на выполнение заданий в подсистеме.
С каждым прокси можно связать одну или несколько подсистем, и тогда участник
получит возможность выполнять эти подсистемы.
Подсистемы SQLAgent
Сценарий ActiveX
Команда операционной системы
MyProxy
Запрос Analysis Services
Пользователь/учетная
использует
запись: MyLogin
Выполнение DTS-пакета
MyCredential
Имя пользователя: MyDomain\user1
Пароль: ****************
Роль: MyRole
Рис. 7. Учетная запись прокси SQL Server Agent, связанная с несколькими
подсистемами
Ниже приведен код на Transact-SQL, необходимоый для реализации схемы,
показанной на рис. 7. Сначала создается удостоверение — объект базы данных,
связывающий учетную запись операционной системы с правами на выполнение
операций в подсистемах. Затем добавляется учетная запись прокси MyProxy,
которая на самом деле — не более чем удобочитаемое имя удостоверения. Затем
прокси связывается с двамя участниками — учетной записью SQL Server и ролью,
определенной пользователем. Наконец, прокси связывается с каждой из четерых
подсистем SQL Server Agent.
CREATE CREDENTIAL MyCredential WITH IDENTITY = 'MyDOMAIN\user1'
GO
msdb..sp_add_proxy @proxy_name = 'MyProxy',
@credential_name = 'MyCredential'
GO
msdb..sp_grant_login_to_proxy @login_name = 'MyLogin',
@proxy_name = 'MyProxy'
GO
Microsoft Corporation ©2007
SQL Server 2008 Security Overview for Database Administrators
15
msdb..sp_grant_login_to_proxy @login_name = 'MyRole',
@proxy_name = 'MyProxy'
GO
sp_grant_proxy_to_subsystem @proxy_name = 'MyProxy',
@subsystem_name = 'ActiveScripting'
GO
sp_grant_proxy_to_subsystem @proxy_name = 'MyProxy',
@subsystem_name = 'CmdExec'
GO
sp_grant_proxy_to_subsystem @proxy_name = 'MyProxy',
@subsystem_name = 'ANALYSISQUERY'
GO
sp_grant_proxy_to_subsystem @proxy_name = 'MyProxy',
@subsystem_name = 'DTS'
GO
SQL Server Management Studio полностью поддерживает создание удостоверений и
прокси (рис. 8). Создается точно такой же прокси, что и в вышеприведенном коде.
Microsoft Corporation ©2007
SQL Server 2008 Security Overview for Database Administrators
16
Рис. 8. Создание прокси SQL Server Agent в SQL Server Management Studio
Прокси не является лазейкой для обхода механизма защиты операционной
системы. Если удостоверение, используемое прокси, не имеет разрешение
Windows, например, право на запись в сетевой каталог, у прокси тоже не будет
такого разрешения. Кроме того, прокси позволяет предоставить права на
выполнение xp_cmdshell, но только ограниченные, поскольку это любимое
средство, используемое злоумышленниками, чтобы после взлома компьютера с
SQL Server добраться до остальных сетевых ресурсов. Прокси обеспечивает такую
защиту, поскольку даже если участник имеет неограниченные права на доступ к
сети, например, является администратором домена, команды выполняются через
прокси с ограниченными правами учетной записи, соответствующей
удостоверениям.
Контекст выполнения
SQL Server давно поддерживает концепцию цепочек владения, позволяющую
администраторам и разработчикам приложений проверять разрешения заранее, в
Microsoft Corporation ©2007
SQL Server 2008 Security Overview for Database Administrators
17
точках входа в базу данных, не проверяя разрешения на все объекты, к которым
осуществляется доступ. Когда пользователь вызывает модуль (хранимую процедуру
или функцию) или обращается к представлению, имея разрешения на выполнение
модуля или на выборку из представления, и владелец модуля или представления
является владельцем объектов, к которому он обращается (цепочка владения),
разрешения на используемые внутри объекты не проверяются, и вызывающий
получает запрашиваемые данные.
Если цепочка владения разорвана, поскольку владелец кода не владеет объектом,
к которому обращается код, то SQL Server проверяет разрешения в контексте
безопасности вызывающего. Если вызывающий имеет разрешение на доступ к
объекту, SQL Server возвращает данные. Если нет, то SQL Server генерирует
ошибку.
Цепочки владения имеют определенные ограничения; они применимы только к
операциям манипулирования данными, но не к динамическому SQL. Кроме того,
цепочки владения не работают, если вы обращаетсь к объектам через границы
владения. Следовательно, такая предварительная проверка разрешений работает
только в определенных случаях.
В SQL Server 2008 включена возможность помечать контекст выполнения модулей,
например, операторы модуля могут выполняться от имени заданного, а не
вызывающего пользователя. Таким образом, хотя вызывающему пользователю попрежнему необходимы разрешения на выполнение модуля, SQL Server проверяет
разрешения внутри модуля в соответствии с контекстом выполнения модуля. Вы
можете воспользоваться таким поведением, чтобы преодолеть некоторые
недостатки цепочек владения, связанные с тем, что они применяются ко всем
операторам модуля. Администраторы, которые желают проверять разрешения
заранее, могут использовать для этой цели контекст выполнения.
Теперь при определении пользовательских функций (за исключением
однооператорных табличных), хранимых процедур и триггеров можно указать
раздел EXECUTE AS, задающий, разрешения какого пользователя будет
использовать SQL Server при проверке прав доступа к объектам и данным,
используемым процедурой:
CREATE PROCEDURE GetData(@Table varchar(40))
WITH EXECUTE AS 'User1'
В SQL Server 2008 доступно четыре варианта EXECUTE AS.

EXECUTE AS CALLER указывает, что код выполняется в контекте защиты
вызывающего; подмены не происходит. Вызывающий должен иметь доступ ко
всем объектам, к которым обращается код. Однако SQL Server проверяет
разрешения только для разорванных цепочек владения, поэтому если владелец
кода владеет используемыми объектами, проверяется только разрешение на
выполнение модуля. Этот контекст выполнения используется по умолчанию в
целях обеспечения обратной совместимости.

EXECUTE AS 'имя_пользователя' указывает, что код, выполняется в
контексте защиты заданного пользователя. Этот вариант отлично подходит,
если вы не хотите полагаться на цепочки владения. Вместо этого создается
пользователь с разрешениями на выполнение кода, и создаются специальные
наборы разрешений.
Microsoft Corporation ©2007
SQL Server 2008 Security Overview for Database Administrators
18

EXECUTE AS SELF — сокращенная запись для указания контекста защиты
пользователя, создавшего или изменившего модуль. На самом деле, внутри SQL
Server хранится имя настоящее пользователя, связанное с модулем, а не "SELF."

EXECUTE AS OWNER задает, что контекст защиты — это контекст защиты
текущего владельца модуля на момент выполнения модуля. Если у модуля нет
владельца, то используется контекст владельца схемы, содержащей модуль. Это
отлично подходит для случая, когда нужна возможность изменить владельца
модуля, не изменяя сам модуль.
Всегда, когда с помощью EXECUTE AS меняется контекст пользователя, тот, кто
создал или изменил процедуру, должен иметь разрешения IMPERSONATE для
указанного пользователя. Этого пользователя нельзя удалить из базы данных до
тех пор, пока во всех модулях, где он указан, контекст выполнения не переключат
на других пользователей.
Разделение пользователя и схемы
В SQL Server 2000 не было понятия схемы, которая в спецификации ANSI SQL-99
определена как набор объектов базы данных, которыми владеет один или тот же
участник, и образующий единое пространство имен объектов. Схема — это
контейнер для объектов базы данных, таких как таблицы, представления,
хранимые процедуры, функции, типы и триггеры. Схема функционирует во многом
аналогично пространствам имен в .NET Framework и XML: служит средством
группирования объектов, благодаря которому в базе данных можно многократно
использовать имена объектов (например, в одной и той же базе данных могут
сосуществовать dbo.Customer и Fred.Customer) и группировать объекты,
принадлежащие различным владельцам.
Примечание Теперь вы будете должны использовать представления каталога,
такие как sys.database_sys.principals, sys.schemas, sys.objects и т.д.
Причина в том, что старая системная таблица sysobjects не поддерживала
схемы, поэтому она не поддерживает разделение пользователь/схема. Кроме
того, старые представления каталога выводятся из обращения и будут удалены
в будущей версии SQL Server.
Вверху на рис. 9 показано, как работают схемы в SQL Server 2000. Когда
администратор создает в базе данных пользователя Alice, SQL Server
автоматически создает схему Alice, скрытую за пользователем Alice. Если Alice
зайдет в SQL Server, не являясь владельцем базы данных, и создаст таблицу
Table1, настоящим именем таблицы будет Alice.Table1. Аналогичная ситуация будет
иметь место и с другими объектами, создаваемыми Alice, например:
Alice.StoredProcedure1 и Alice.View1. Если бы Alice была владельцем базы данных
или членом роли sysadmin, то создаваемые объекты стали бы частью схемы dbo.
Раньше мы говорили, что объектами владеет dbo, но это было равносильно тому,
что объекты входят в схему dbo.
Microsoft Corporation ©2007
SQL Server 2008 Security Overview for Database Administrators
19
Table1
владеет
StoredProcedure1
UserDefinedFunc1
Схема: Alice
Имя объекта: Alice.Table1
Table1
StoredProcedure1
владеет
Schema1
Имя объекта: Schema1.Table1
UserDefinedFunc1
содержит
Рис. 9. Пользователь/схема/объекты в SQL Server 2000 и 2008
Когда требуется внести изменения во владение объектами, в SQL Server 2000
возникают проблемы, связанные с тем, что в нем пользователи и схемы
неотделимы друг от друга. Предположим, что Alice увольняется из компании, и на
ее место приходит Lucinda. Системный администратор должен изменить владение
всеми объектами, принадлежащими Alice, передав их пользователю Lucinda. В
основном проблема связана с тем, что после того как Lucinda станет владельцем,
например, таблицы Table1, придется корректировать код на Transact-SQL или код
клиентских приложений, заменяя Alice на Lucinda. Если Alice владеет достаточно
большим количеством объектов и ее имя указано во многих приложениях, эта
работа будет весьма трудоемкой. Майкросфот настоятельно рекомендовала делать
владельцем всех объектов базы данных встроенного пользователя dbo, чтобы
обойти эту проблему. Было гораздо проще изменить владельца базы данных, чем
вносить изменения в многочисленные объекты и клиентские приложения.
Примечание Пусть вас не вводит в заблуждение оператор CREATE SCHEMA,
имеющийся в SQL Server 2000. Это всего лишь простой способ создать таблицы
и представления, принадлежащие определенному пользователю, и
предоставить разрешения на них. С помощью этого оператора можно задать имя
владельца схемы, но нельзя задать имя схемы. В этой версии SQL Server
пользователь и схема неотдельимы, из-за чего и возникают все эти проблемы со
сменой владельца.
SQL Server 2008 решает эту проблему, реализуя требования спецификации SQL-99.
Как показано в нижней части рис. 9, пользователь теперь отделен от схемы. Когда
вы создаете пользователя Alice с помощью нового DDL-оператора CREATE USER,
SQL Server больше не выполняет автоматическое создание схемы с таким же
именем. Вместо этого вы должны явно создать схему и сделать пользователя ее
владельцем. Поскольку все объекты базы данных, показанные на рисунке, теперь
входят в схему Schema1, которой первоначально владеет Alice, становится проще
сменить владельца всех объектов этой схемы, просто сменив владельца схемы на
Lucinda. Кроме того, каждому пользователю назначается схема по умолчанию, и
SQL Server полагает, что объекты, к которым обращаются по имени без указания
схемы, относятся к схеме по умолчанию. Если в примере на нижней части рис. 9
Schema1 является схемой по умолчанию для Alice, то она может обращаться к
Microsoft Corporation ©2007
SQL Server 2008 Security Overview for Database Administrators
20
таблице как к Schema1.Table1 или просто как к Table1. Пользователь Carol, у
которого, предположим, схема по умолчанию не задана, сможет обращаться к этой
таблице только как к Schema1.Table1. Для любого пользователя, для которого не
задана схема по умолчанию, в качестве такой схемы исползуется dbo.
Полностью определенные имена объектов в SQL Server 2008 состоят из четырех
частей, аналогично предыдущим версиям SQL Server:
сервер.база_данных.схема.объект
Как и в предыдущих версиях, можно опустить имя сервера, если объект
принадлежит тому серверу, на котором выполняется код. Можно опустить имя базы
данных, если установлено соединение с той же самой базой данных, и можно
опустить имя схемы, если используется схема по умолчанию для текущего
пользователя или если владельцем объекта является dbo, поскольку эта схема —
последнее средство, к которому прибегает SQL Server, пытаясь однозначно
определить разрешить имя объекта.
Для создания пользователей используйте оператор CREATE USER а не sp_adduser.
Эта системная хранимая процедура оставлена в целях обратной совместимости и
претерпела небольшие изменения, чтобы поддерживать отделение пользователей
от схем. sp_adduser создает схему с тем же именем, что и имя пользователя или
имя роли приложения и назначает эту схему схемой по умолчанию для нового
пользователя, имитируя поведение SQL Server 2000, но создавая отдельную схему.
Примечание
При использовании оператора ALTER AUTHORIZATION может
возникнуть ситуация, когда ВЫ владеете таблицей в МОЕЙ схеме (или
наоборот). В этом случае возникают серьезные вопросы. Например, кто владеет
триггером, созданным для этой таблицы, — вы или я? В конечном итоге может
оказаться, что выявить настоящего владельца объекта или типа,
принадлежащего схеме, очень сложно. Имеется два средства, решающих эту
проблему:

используйте OBJECTPROPERTY(id, 'OwnerId'), чтобы определить истинного
владельца объекта;

используйте TYPEPROPERTY(type,'OwnerId'), чтобы определить истинного
владельца типа.
SQL Server 2008 позволяет сэкономить время, затрачиваемое на ввод имен, с
помощью синонимов. Можно создать синоним для любого объекта, указав имя из
двух, трех или четырех частей. SQL Server использует синонимы для доступа к
соответствующему объекту. В приведенном ниже коде синоним History
представляет заданную таблицу (указано имя в формате схема.таблица) в базе
данных AdventureWorks. Оператор SELECT возвращает содержимое таблицы
EmployeeDepartmentHistory.
USE AdventureWorks
GO
CREATE SYNONYM History FOR HumanResources.EmployeeDepartmentHistory
SELECT * FROM History
Microsoft Corporation ©2007
SQL Server 2008 Security Overview for Database Administrators
21
Примечание Администратор или владелец должен предоставить разрешение
на синоним, если с ним будет работать кто-то другой. В случае синонимов
представлений, таблиц или табличных функций используют GRANT SELECT. В
случае процедур, скалярных функций и т.д. применяют GRANT EXECUTE.
Можно было бы определить синоним History для полного имени таблицы,
состоящего из четырех частей:
CREATE SYNONYM History
FOR MyServer.AdventureWorks.HumanResources.EmployeeDepartmentHistory
То, что при определении синонима указано полное имя, состоящее из четырех
частей, означает, что его можно использовать в контексте другой базы данных,
если другой пользователь имеет разрешения на использование синонима и чтение
данных из таблицы:
USE pubs
SELECT * FROM AdventureWorks..History
Кроме того, заметьте: если вы не указали в имени создаваемого синонима имя
схемы, то он войдет в схему по умолчанию.
Шифрование и управление ключами
Безопасность на уровне сервера — пожалуй, самая важная проблема для
системных администраторов, но местом, где происходят все операции по обработке
данных в производственной среде, все-таки является база данных. В большинстве
случае администратор базы данных может позволить разработчикам базы данных
заниматься подробностями ее реализации, поскольку они работают в рамках,
установленных средой. SQL Server 2008 предоставляет многочисленные
возможности по защите баз данных.
Шифрование данных
В SQL Server 2000 и более ранних версий не было встроенного механизма
шифрования данных, хранящихся в базе. Зачем нужно шифровать данные, которые
хранятся в отлично защищенной базе данных на безопасном сервере, который
спрятан за мастерски настроенными брандмауэрами? Из-за важного и проверенного
временем принципа многослойной защиты (defense in depth). Многослойная защита
означает, что сооружается несколько защитных уровней, и злоумышленнику, даже
если он пробъет внешний защитный барьер, придется преодолевать уровень за
уровнем, чтобы добраться до данных. В случае базы данных это означает, что если
злоумышленник преодолеет брандмауэр, средства защиты Windows, сервера и базы
данных, ему придется еще и дешифровать ваших данные по методу грубой силы.
Кроме того, в наше время, когда законодательство требует обеспечивать защиту
данных и конфиденциальность информации, необходимо хранить данные в
безопасности.
В SQL Server 2008 обеспечивается мощная поддержка различных типов
шифрования данных с помощью симметричных и ассимметричных ключей и
цифровых сертиикатов. Самое приятное, что он берет на себя управление ключами,
ведь управление ключами — наиболее сложная часть к шифрованию. Никогда не
было просто хранить в секрете ключ к секретной информации.
Microsoft Corporation ©2007
SQL Server 2008 Security Overview for Database Administrators
22
Как администратору, вам, вероятно, потребуется управлять хотя бы верхним
уровнем ключей в иерархии, показанной на рис. 10. Администраторы баз данных
должны знать мастер-ключ сервиса на уровне сервера и мастер-ключи баз данных
на уровне баз данных. Каждый ключ защищает дочерние ключи, которые, в свою
очередь, защищают свои дочерние ключ, и так далее вниз по дереву. Единственное
исключение — защита симметричных ключей или сертификатов паролем — таким
образом SQL Server позволяет пользователям управлять своими собственными
ключами и брать на себя заботу об обеспечении секретности ключей.
Мастер-ключ сервиса
(защищенный DPAPI)
Уровень сервера
Уровень базы данных
Мастер-ключ базы данных
сервера
Сертифиаты
пароль
Cимметричные ключи
Асимметричные ключи
пароль
Cимметричные ключи
пароль
данные
данные
Cимметричные ключи
данные
Рис. 10. Иерархия ключей шифрования в SQL Server 2008
Примечание Майкрософт рекомендует не использовать сертификаты или
асимметричные ключи при прямом шифровании данных. Асимметричные ключи
гораздо медленнее, а количество данных, которые можно защитить с помощью
этого механизма, ограничено и зависит от длины ключа. Сертификаты и
асимметричные ключи можно защитить паролем, а не мастер-ключом базы
данных.
Мастер-ключ сервиса (Service Master Key) — единственный ключ, управляющий
всеми остальными, т.е. всей иерархией ключей и сертификатов SQL Server. Это
симметричный ключ, который автоматически создается при установке SQL Server.
Очевидно, этот ключ — критически важная секретная информация: при его
раскрытии злоумышленник, в конечном счете, сможет расшифровать каждый ключ
сервера, на котором выполняется SQL Server. В Windows для защиты мастер-ключа
сервиса используется Data Protection API (DPAPI).
Microsoft Corporation ©2007
SQL Server 2008 Security Overview for Database Administrators
23
SQL Server управляет мастер-ключом сервиса, однако вы тоже можете заниматься
его поддержкой: cохранять его в файле, заново генерировать, восстанавливать из
файла. Однако в большинстве случаев у вас не возникнет ни желания, ни
необходимости каким-либо образом изменять этот ключ. Администраторам баз
данных рекомендуется создать резервную копию мастер ключа сервиса на случай
его повреждения.
В базе данных корневым объектом шифрования для всех ключей, сертификатов и
данных базы является мастер-ключ базы данных. У каждой базы данных имеется
единственный мастер-ключ; если вы попытаетесь создать второй ключ,
сгенерируется ошибка. Вы должны создать мастер-ключ базы данных перед его
использованием, выполнив оператор Transact-SQL CREATE MASTER KEY и указав
пароль пользователя:
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'EOhnDGS6!7JKv'
При шифровании ключа SQL Server использует ключ для шифрования по алгоритму
Triple DES, получаемый на основе пароля и мастер-ключа сервиса. Первая копия
сохраняется в базе данных, а вторая — в базе данных master. Поскольку мастерключ базы данных защищен мастер-ключом сервиса, при необходимости SQL Server
может автоматически расшифровать мастер-ключ базы данных. Конечным
пользователям или приложениям не требуется явно открывать мастер-ключ,
указывая пароль. Хранение защищенных ключей в иерархии является
существенным преимуществом.
При отсоединении базы данных, для которой существует мастер-ключ, и ее
переносе на другой сервер могут возникнуть проблемы. Причина в том, что мастерключ сервиса на новом сервере не такой, как на старом сервере. В результате
сервер не сможет автоматически расшифровать мастер-ключ базы данных. Эту
проблему можно решить следующим образом: открыть мастер-ключ базы данных с
паролем, который использовался при его шифровании, и с помощью оператора
ALTER MASTER KEY зашифровать ключ уже с новым мастер-ключом сервиса. В
противном случае, вам всегда придется открывать базу данных перед
использованием, указывая мастер-ключ базы данных.
После создания мастер-ключа базы данных разработчики могут использовать его
для того, чтобы создавать один из трех типов ключей, в зависимости от того, какой
тип шифрования требуется:

ассимметричные ключи — применяются при шифровании с открытым ключом,
когда используется пара открытый ключ/закрытый ключ;

cимметричные ключи — применяются при шифровании общих секретных
данных, когда один и тот же ключ используется при шифровании и
дешифровании;

сертификаты — в сущности, это оболочки для открытых ключей.
Благодаря разнообразным возможностям и глубокой интеграции с сервером и
базами данных шифрование целесообразно использовать для создания последнего
уровня защиты данных. Тем не менее, соблюдайте благоразумие при применении
шифрования, поскольку оно существенно увеличивает издержки при обработке
данных на сервере.
Microsoft Corporation ©2007
SQL Server 2008 Security Overview for Database Administrators
24
Прозрачное шифрование данных
В SQL Server 2005 можно зашифровать данные в базе, написав специальный на
Transact-SQL специальный код, использующий криптографические возможности
ядра баз данных. В SQL Server 2008 в этот механизм внесены дальнейшие
усовершенствования — введено прозраченое шифрование данных.
При прозрачном шифровании данных все криптографические операции
выполняются на уровне базы данных, благодаря чему исчезает необходимость в
написании кода для шифрования и дешифрования данных. Данные шифруются при
записи на диск и дешифруются при чтении с диска. При использовании SQL Server
для прозрачного шифрования и дешифрования данных можно защитить бизнесданные, хранящиеся в базе данных, не изменяя существующие приложения
(рис. 11).
SQL Server 2008
Зашифрованная страница данных
Клиентское приложение
Рис. 11. Прозрачное шифрование данных
При шифровании и дешифровании используется Database Encryption Key (ключ для
шифрования баз данных, DEK), который хранится в загрузочной записи базы
данных, чтоы быть доступным во всевозможных случаях восстановления. Для
защиты DEK можно использовать мастер-ключ или Hardware Security Module
(аппаратный модуль защиты, HSM). HSM — это, как правило, USB-устройства или
смарт-карты, поэтому их кража или утрата маловероятны.
Расширяемое управление ключами
С ростом требований к соблюдению законодательства и всеобщего внимания к
вопросам защиты данных, все больше организаций применяет шифрование как
один из механизмов многослойной защиты. Организации все шире используют
шифрование и ключи и вы должны задействовать систему хранения, удаления и
повторной генерации ключей. Кроме того, чтобы повысить безопасность, вы
должны хранить эти ключи отдельно от данных.
В SQL Server 2008 функции шифрования доступны для использования сторонними
производителями. Их решения, специально предназначенные для управления
ключами, поддерживают бесшовную интеграцию с базами данных SQL Server 2005
и SQL Server 2008. В результате нагрузка по управлению ключами переносится с
SQL Server на специальную систему управления ключами.
Microsoft Corporation ©2007
SQL Server 2008 Security Overview for Database Administrators
25
Кроме того, расширяемое управление ключами в SQL Server 2008 поддерживает
использование HSM, позволяющее отделить ключи от данных.
Подписание кодовых модулей
Одно из приятных преимуществ шифрования средствами SQL Server — то, что он
предоставляет возможность цифрового подписания кодовых модулей (хранимых
процедур, функций, триггеров и уведомлений о событиях) с помощью
сертификатов. Благодаря этому можно гораздо более гибко управлять доступом к
таблицам баз данных и другим объектам. Как и при шифровании данных, вы
подписываете код закрытым ключом, содержащимся в сертификате. В результате
таблицы, используемые в подписанном кодовом модуле, доступны только через
код, и не доступны вне модуля. Другими словами, доступ к таблицам становится
возможным только при указании сертификатов, использовавшихся при подписании
модуля.
Возникает тот же эффект, что и в случае хранимых процедур. Например, если
цепочка владения не разорвана, вы можете тщательно контролировать, какие
пользователи имеют разрешение EXECUTE на процедуру и запрещать прямой
доступ к соответствующим таблицам. Но это не помогает в случаях, когда цепочка
владения процедуры разорвана или когда выполняется динамический SQL — тогда
требуется, чтобы пользователь имел разрешение на соответствующие таблицы. Еще
один способ достичь такого же эффекта — использовать EXECUTE AS, но тогда
изменится контекст защиты, в котором выполняется процедура. Это может
оказаться нежелательным, например, если необходимо записывать в некую
таблицу информацию о том, какой пользователь на самом деле инициировал вызов
процедуры (останется разве что передавать имя пользователя как параметр
процедуры).
Подписание кодовых модулей обеспечивает дополнительное преимущество —
защиту от несанкционированных изменений модуля. Как в случае других
документов с цифровой подписью, сертификат становится недействительным при
изменении кода. Код не будет выполняться в контексте сертификата, поэтому
любые объекты, доступ к которым осуществляется через сертификат, станут
недоступными.
Чтобы подписать кодовый модуль, создайте сертификат, свяжите его с новым
пользователем и подпишите процедуру этим сертификатом. Предоставьте
пользователю разрешения на доступ к объектам, необходимые для выполнения
хранимой процедуры. В сущности, тем самым вы добавите этого прользователя в
контекст защиты хранимой процедуры как дополнительную идентификацию. Затем
предоставьте разрешения на выполнение тем пользователям или ролям, которым
требуется выполнять процедуру. В следующем коде показаны все эти операции.
Предположим, что требуется подписать процедуру the mySchema.GetSecretStuff и
что все объекты, к которым она обращается, уже существуют в базе данных:
CREATE CERTIFICATE certCodeSigning
ENCRYPTION BY PASSWORD = 'cJI%V4!axnJXfLC'
WITH SUBJECT = 'Code signing certificate'
GO
Microsoft Corporation ©2007
SQL Server 2008 Security Overview for Database Administrators
26
-- Подписываем хранимую процедуру
ADD SIGNATURE TO mySchema.GetSecretStuff BY CERTIFICATE certCodeSigning
WITH PASSWORD = 'cJI%V4!axnJXfLC'
GO
-- Сопоставляем пользователя сертификату
CREATE USER certUser FOR CERTIFICATE certCodeSigning
GO
-- Предоставляем разрешение SELECT новому пользователю certUser
GRANT SELECT ON SocialSecurity TO certUser
GO
-- Предоставляем разрешение на выполнения пользователю,
-- который будет выполнять код
GRANT EXECUTE ON mySchema.GetSecretStuff TO ProcedureUser
GO
Теперь доступ к данным таблицы будут иметь только те пользователи, которы
имеют разрешение EXECUTE на хранимую процедуру.
Аудит в SQL Server 2008
Важной частью любого решения по обеспечению безопасности является
возможность аудита операций, позволяющего вести учет и соблюдать нормативные
требования. В SQL Server 2008 имеется несколько средств, позволяющих вести
аудит операций.
Аудит всех операций
В SQL Server 2008 для поддержки аудита служит объект Audit, позволяющий
администраторам собирать данные об операциях, выполняемых на сервере баз
данных, и записывать их в журнал. В SQL Server 2008 можно записывать данные
аудита в следующие адресаты:

файл;

Windows Application Log;

Windows Security Log.
Чтобы выполнялась запись в Windows Security Log, необходимо настроить сервис
SQL Server на выполнение под учетной записью Local System, Local Service,
Network Service или доменной учетной записью, имеющей привилегию
SeAuditPrivilege и не принадлежащей интерактивному пользователю.
Чтобы создать объект Audit, выполните оператор CREATE SERVER AUDIT. Он
определяет объект Audit и связывает его с адресатом. Для настройки объекта Audit
в зависимости от адресата используются параметры, специфичные для адресата.
Microsoft Corporation ©2007
SQL Server 2008 Security Overview for Database Administrators
27
Например, следующий код на Transact-SQL создает два объекта Audit: один
выводит журнал операций в файл, а другой — в Windows Application Log.
CREATE SERVER AUDIT HIPAA_File_Audit
TO FILE ( FILEPATH=’\\SQLPROD_1\Audit\’ );
CREATE SERVER AUDIT HIPAA_AppLog_Audit
TO APPLICATION_LOG
WITH ( QUEUE_DELAY = 500,
ON_FAILURE = SHUTDOWN);
Заметьте: при выводе в файл в операторе CREATE SERVER AUDIT не указывается
имя файла. Файл аудита имеет вид AuditName_AuditGUID_nn_TS.sqlaudit , где AuditName
— имя объекта Audit, AuditGUID — уникальный идентификатор, связанный с объектом Audit,
nn — номер части, используемый для формирования наборов файлов, состоящих из
нескольких частей, а TS — временная метка. Например, объект Audit HIPAA_FILE_Audit,
созданный в предыдущем примере кода, может сгенерировать файл журнала, имя которого
имеет следующий вид:
HIPAA_File_Audit_{95A481F8-DEF3-40ad-B3C6-126B68257223}_00_29384.sqlaudit
Параметр аудита QUEUE_DELAY можно использовать, чтобы реализовать
асинхронный аудит для увеличения производительности, а параметр —
ON_FAILURE определяет, какие действия предпринимаются, если информацию
аудита не удастся записать в адресат. В показанном выше примере с объектом
HIPAA_AppLog_Audit, параметр ON_FAILURE задает, что, если не удастся
осуществить запись в журнал, то необходимо остановить экземпляр SQL Server; в
этом случае пользователь, выполняющий оператор CREATE SERVER AUDIT должен
иметь разрешение SHUTDOWN.
После создания объекта Audit можно добавить события, которые он будет
обрабатывать, операторами CREATE SERVER AUDIT SPECIFICATION и CREATE
DATABASE AUDIT SPECIFICATION. Оператор CREATE SERVER AUDIT SPECIFICATION
добавляет в Audit группы операций уровня сервера (т.е. заранее определенные
наборы взаимосвязанных операций, происходщих на уровне сервера). Например,
следующий код добавляет группу операций FAILED_LOGIN_GROUP (т.е. будет
записывать сведения о неудачных попытках входа) в объект HIPAA_File_Audit.
CREATE SERVER AUDIT SPECIFICATION Failed_Login_Spec
FOR SERVER AUDIT HIPAA_File_Audit
ADD (FAILED_LOGIN_GROUP);
Оператор CREATE DATABASE AUDIT SPECIFICATION добавляет в Audit группы
операций и отдельные события уровня базы данных. Добавление отдельных
операций позволяет фильтровать операции, сведения о которых выводятся в
журнал, на основе объектов и пользователей, участвующих в операциях.
Например, следующий фгагмент кода добавляет в объект Audit
HIPAA_AppLog_Audit группу операций DATABASE_OBJECT_CHANGE_GROUP (т.е.
ведется журнал любых операций CREATE, ALTER и DROP, выполняемых в базе
данных), а также задает, что в журнал заносятся сведения о выполнении
операторов INSERT, UPDATE и DELETE для объектов из схемы Sales пользователями
SalesUser и SalesAdmin.
Microsoft Corporation ©2007
SQL Server 2008 Security Overview for Database Administrators
28
CREATE DATABASE AUDIT SPECIFICATION Sales_Audit_Spec
FOR SERVER AUDIT HIPAA_AppLog_Audit
ADD (DATABASE_OBJECT_CHANGE_GROUP),
ADD (INSERT, UPDATE, DELETE
ON Schema::Sales
BY SalesUser, SalesAdmin);
Объект Audit реализует управляемую инфраструктуру аудита, позволяющую без
труда определить события, которые требуется отражать в журналах, и места, в
которых хранятся журналы. Это нововведение SQL Server помогает создавать
всеобъемлющие решения по аудиту, которые обеспечат безопасность вашей базы
данных и позволят выполнить нормативные требования.
DDL-триггеры
DDL-триггеры введены в SQL Server 2005. В отличие от DML-триггеров,
выполняющих код на Transact-SQL, когда меняются данные в таблице, DDL-триггер
срабатывает, когда меняется структура таблицы. Это отличный способ мониторинга
и аудита структурных изменений в схеме базы данных.
Синтаксис этих триггеров аналогичен синтаксису DML-триггеров. DDL-триггеры —
это триггеры AFTER, срабатывающие при событиях языка DDL; они не срабатывают
при выполнении системных хранимых процедур, выполняющих операции,
аналогичные DDL-операторам. Эти триггеры полностью поддерживают транзакции,
т.е. можно выполнить ROLLBACK и откатить DDL-изменение. В них можно
выполнять как код на Transact-SQL, так и CLR-код. Кроме того, DDL-триггеры, как и
другие модули, поддерживают раздел EXECUTE AS.
SQL Server предоставляет информацию о событии, по которому сработал триггер, в
виде нетипизированных XML-данных. Они доступны через новую встроенную
функцю EVENTDATA(), возвращающую XML-данные. Для разбора XML-данных,
возвращаемых EVENTDATA(), можно применять XQuery-выражения, позволяющие
получать атрибуты события, такие как имя схемы, имя целевого объекта, имя
пользователя, а также весь DDL-оператор, первоначально вызвавший
срабатывание триггера. Примеры разбора можно посмотреть в разделе EVENTDATA
(Transact-SQL) руководства SQL Server Books Online.
DDL-триггеры уровня базы данных срабатывают при событиях языка DDL на уровне
базы данных и более низких уровнях. Например, CREATE_TABLE, ALTER_USER и т.д.
DDL-триггеры уровня сервера, срабатывают при событиях языка DDL серверного
уровня, например, CREATE_DATABASE, ALTER_LOGIN и т.д. Для удобства
администрирования можно использовать группы событий наподобие
DDL_TABLE_EVENTS как сокращения, описывающие все события определенной
группы (в данном случае все события CREATE_TABLE, ALTER_TABLE и DROP_TABLE).
Различные группы DDL-событий и типы событий, а также XML-данные,
возвращаемые для них функцией EVENTDATA(), описываются в SQL Server Books
Online.
В отличие от имен DML-триггеров, областью действия которых является схема,
областью действия DDL-триггеров являются база данных или сервер.
Microsoft Corporation ©2007
SQL Server 2008 Security Overview for Database Administrators
29
Чтобы получить метаданные DML-триггеров и DDL-триггеров уровня базы данных,
воспользуйтесь новым представлением каталога:
SELECT * FROM sys.triggers ;
GO
Если поле parent_class_desc имеет значение 'DATABASE', то это DDL-триггер и его
областью действия является сама база данных. Тело триггера Transact-SQL можно
получить из представления каталога sys.sql_modules, связав его с sys.triggers
по полю object_id. Метаданные CLR-триггеров доступны из представления каталога
sys.assembly_modules, которое также следует связать с sys.triggers по полю.
Для получения метаданных о DDL-триггерах серверного уровня, воспользуйтесь
следующим представлением каталога:
SELECT * FROM sys.server_triggers ;
GO
Тело триггера серверного уровня на языке Transact-SQL можно получить из
представления каталога sys.server_sql_modules, связав его с
sys.server_triggers по полю object_id. Метаданные CLR-триггера серверного
уровня доступны в представлении каталога sys.server_assembly_modules,
которое также следует связать с sys.server_triggers по полю object_id.
DDL-триггеры можно применять для перехвата и аудита DDL-операций в базе
данных. Создайте таблицу аудита с полем, содержащим нетипизированные XMLданные. Создайте DDL-триггер с параметром EXECUTE AS SELF для DDL-событий
или групп событий, которые вас интересуют. Тело такого DDL-триггера может
просто выполнять вставку (INSERT) XML-данных, возвращаемых EVENTDATA(), в
таблицу аудита.
Еще одно интересное применение DDL-триггеров — связывать их с событием
CREATE_USER и выполнять в них код автоматического управления разрешениями.
Например, предположим, что необходимо предоставлять всем пользователям базы
данных разрешение GRANT EXECUTE на процедуры P1, P2 и P3. DDL-триггер может
извлекать имя пользователя из XML-данных, возвращаемых EVENTDATA(),
динамически формировать операторы вида 'GRANT EXECUTE ON P1 TO
<пользователь>' и выполнять его.
Заключение
В SQL Server 2008 имеются мощные средства защиты, обеспечивающие
безопасность данных и сетевых ресурсов. Стало гораздо проще выполнять
безопасную установку, поскольку все средства SQL Server 2008, за исключением
самых необходимых, либо не устанавливаются в стандартной конфигурации, либо
отключены. SQL Server содержит многочисленные средства конфигурирования
сервера, в частности, SQL Server Surface Area Configuration Tool. Его механизм
аутентификации стал надежнее, поскольку обеспечивается более тесная
интеграция с аутентификацией Windows и защита от нестойких или устаревших
паролей. Предоставление разрешений и определение того, что вправе делать
пользователь, прошедший аутентификацию, стало гораздо более гибким, благодаря
тонкому управлению разрешениями, прокси SQL Server Agent и контексту
выполнения. Даже метаданные стали более безопасными, поскольку системные
представления для метаданных возвращают информацию только о тех объектах, на
Microsoft Corporation ©2007
SQL Server 2008 Security Overview for Database Administrators
30
которые у пользователя имеются определенные разрешения. Поддерживается
шифрование на уровне базы данных, реализующее последний слой защиты, в то
же время благодаря разделению полеьзователй и схем упростилось управление
пользователями.
Дополнительная информация:
http://www.microsoft.com/sql
http://www.microsoft.com/sql/technologies/security/default.mspx
Microsoft Corporation ©2007
SQL Server 2008 Security Overview for Database Administrators
31
Была ли эта статья полезной для вас? Пожалуйста, сообщите нам свое мнение о
ней. Оцените статью по пятибалльной шкале от 1 (плохо) до 5 (отлично), поясните
свою оценку. Например:

За что статья удостоена высокой оценки: за хорошие примеры,
качественные иллюстрации, ясное изложение или по другой причине?

За что статья удостоена низкой оценки: за неудачные примеры, плохие
иллюстрации, путаный стиль?
Ваши отзывы помогут нам в повышении качества официальных статей. Отправить
отзыв.
Microsoft Corporation ©2007