2.1. Безопасная
инсталляция
2.2. Установка
Microsoft SQL Server 2000 Desktop
Engine
2.3. Уровень
безопасности C2
2.4. Kerberos
и делегирование в среде Windows
2000
2.5. Аудит
безопасности
2.5.1. SQL
trace
2.5.2. SQL
Profiler
2.5.3. Режим
аудита C2
2.6. Исключение
SQLAgentCmdExec Proxy
Account
2.7. Расширение
набора серверных ролей
2.7.1. Bulkadmin
2.7.2.
Securityadmin
2.7.3.
Serveradmin
2.8.
Шифрация
2.8.1.
Шифрация
трафика с использованием SSL/TLS
2.8.2. Login
Packet Encryption
2.8.3. Client-Requested
Encryption
2.8.4. Server-Requested
Encryption
2.8.5. Поддержка
Encrypted File System на Windows
2000
2.8.6. Server-Based
Encryption Enhanced
2.8.7. DTS
Package Encryption
2.9.
Пароли
2.9.1.
Резервирование
и Backup Media Sets
2.9.2. SQL
Server Enterprise Manager
2.9.3. Изменение
учётной записи сервиса с использованием SQL Server Enterprise
Manager
2.9.4. В
системных таблицах убран столбец
SUID
2.10. Модель
безопасности SQL Server 2000
2.11. Режимы
аутентификации
2.11.1. Windows
Authentication Mode
2.11.2. Смешанный
режим
2.12. Поддержка
Security Identification Numbers
2.13.
Роли
2.13.1.
Роль
public
2.13.2. Предопределенные
Роли
2.13.3. Фиксированные
серверные роли
2.13.4. Фиксированные
роли базы данных
2.13.5. Определяемые
пользователем роли
2.13.6. Роли
приложений
2.14. Обеспечение
доступа к серверу
2.14.1. Уровень
Windows
2.14.2. Уровень
SQL Server
2.15. Обеспечение
доступа к базе данных
2.15.1. Обеспечение
доступа к объектам базы данных
2.15.2. Определяемые
пользователем роли базы данных
2.15.3. Система
разрешений
2.15.4. Предоставление
и отрицание разрешений для пользователей и
ролей
2.15.5. Цепочки
владения
2. Новшества безопасности SQL Server 2000
Первая часть этой главы исследует новые возможности обеспечения безопасности SQL Server 2000, и даёт краткий обзор того, что нового появилось в последней версии сервера баз данных.
Процесс инсталляции SQL Server 2000 теперь позволяет сразу
выбрать режим аутентификации (Authentication
Mode), предлагая по умолчанию более защищённый режим
Windows Authentication Mode. Специальное окно мастера
установки Вы увидите во всех издания СУБД, кроме Microsoft SQL
Server, Desktop Engine. В этом окне Вы должны выбрать один из
возможных режимов аутентификации: Windows или смешанный режим
(Mixed Mode).
Если Вы выбираете смешанный режим, не
забудьте установить пароль для логина системного
администратора SQL Server (sa). Вы можете оставить пароль
пустым, но это не рекомендуется, т.к. ваша система будет
уязвима. В SQL Server 7.0 по умолчанию был смешанный режим и
пустой пароль для sa.
Если инсталляция осуществляется на
Windows NT 4.0 или на Windows 2000, использующие файловую
систему NTFS, инсталлятор даст права к каталогам, в которые
будут помещены файлы SQL Server только учетным записям,
выбранным для запуска сервисов SQL Server и локальной группе
built-in administrators. По умолчанию, файлы размещаются в
каталоге:
C:\Program Files\Microsoft SQL Server\MSSql
Кроме того, доступ к ключам SQL Server в системном реестре, которые располагаются в ветке:
HKLM\Software\Microsoft\MSSQLServer
или
HKLM\Software\Microsoft\Microsoft SQL Server\MSSQL$InstanceName
для именованного экземпляра, также будет разрешён только указанным учетным записям.
2.2. Установка Microsoft SQL Server 2000 Desktop Engine
Программа установки Microsoft SQL Server 2000 Desktop
Engine по умолчанию позволяет инсталлировать MSDE на
операционные системы Windows NT 4.0 и Windows 2000 в Windows
Authentication Mode. Для операционных системы Windows 98 или
Windows Millennium (Windows Me), режим Windows Authentication
не доступен, так что будет выбран смешанный режим
аутентификации. Чтобы изменять режим по умолчанию, используйте
опцию SECURITYMODE=SQL в командной строке запуска программы
установки (или в .ini файле), как это описано в главе SQL
Server 2000 Books Online: "SQL Server 2000 Desktop Engine
Setup".
Как отмечено в readme.txt для SQL Server 2000:
разделы SQL Server Books Online "Merging the Desktop Engine
into Windows Installer" и "SQL Server 2000 Desktop Engine
Setup" документируют два параметра, которые игнорируются
программой установки Desktop Engine: USEDEFAULTSAPWD и
SAPASSWORD. Поэтому, пароль sa после установки Desktop Engine,
когда задан смешанной режим аутентификации, останется пустым,
и должен быть изменен немедленно после инсталляции.
SQL Server 2000 был признан правительственной комиссией Соединенных Штатов удовлетворяющим требованиям безопасности по уровню C2. Для получения дополнительной информации о конфигурации безопасности по уровню C2, ознакомьтесь со следующими статьями:
http://www.microsoft.com/technet/security/prodtech/sqlsec.asp
Для получения информации о сертификате на уровень C2, ознакомьтесь с этой статьёй:
http://www.radium.ncsc.mil/tpep/epl/entries/TTAP-CSC-EPL-00-001.html
2.4. Kerberos и делегирование в среде Windows 2000
Kerberos - основной механизм аутентификации в сетях Windows 2000. Делегирование - способность передавать мандаты безопасности между компьютерами и прикладными программами. Для каждого перехода (hop) между компьютерами, сохраняются соответствующий мандат пользователя. SQL Server 2000 полностью поддерживает Kerberos, включая способность принимать делегированные билеты Kerberos, а также делегировать эти билеты далее (для Windows 2000), задействовав контроллеры домена Windows 2000 и Active Directory. Билет - это набор идентификационных данных для системы безопасности, выданных контроллером домена с целью проверки подлинности пользователя. В Windows 2000 используются билеты двух типов: билеты TGT и билеты службы. Билеты Kerberos применяются при удалённом вызове хранимых процедур и в распределенных запросах. Для получения дополнительной информации о Kerberos и безопасности Windows 2000, см. следующую статью: Windows 2000 Security Services
Чтобы делегирование работало, все серверы, с которыми поддерживается соединение, должны быть под Windows 2000 с включённой поддержкой Kerberos, и должны использовать Active Directory. Кроме того, в Active Directory должны быть выполнены соответствующие установки для делегирования, чтобы это всё заработало:
· Account is sensitive and cannot be delegated. Эта опция
не должна быть включена для делегирования запросов
пользователя.
· Account is trusted for delegation. Эта
опция должна быть включена для сервисной учетной записи SQL
Server.
· Computer is trusted for delegation. Эта опция
должна быть включена для сервера, выполняющего экземпляр
Microsoft SQL Server.
Чтобы использовать делегирование учетной записи, SQL Server должен иметь Service Principal Name (SPN), назначенный администратором домена учетной записи Windows 2000. SPN должен быть назначен для учетной записи службы SQL Server для конкретного компьютера. Делегирование подразумевает взаимную идентификацию. SPN необходим, что бы доказать подлинность SQL Server конкретного компьютера, работающего через конкретный сокет, и присвоенный администратором домена учетной записи Windows 2000. Устанавливать SPN для SQL Server должен администратор домена. Для получения дополнительной информации об утилите setspn, см. документацию по Windows 2000 Resource Kit.
Что бы создать SPN для SQL Server 2000, выполните следующую команду:
setspn -A MSSQLSvc/Host:port serviceaccount
Например:
setspn -A MSSQLSvc/server1.redmond.microsoft.com sqlaccountДля делегирования Вы должны использовать сокеты сетевой библиотеки TCP/IP. Вы не можете использовать именованные каналы потому, что адреса SPN есть только у сокета TCP/IP. Если Вы используете несколько портов, Вы должны завести SPN для каждого порта.
Вы также можете включить делегирование и для учётной записи Localsystem. SQL Server 2000 сам регистрируется при запуске сервиса и автоматически получает SPN. Эта опция проще, чем предоставление делегирования при использовании учетной записи пользователя домена; однако, когда SQL Server 2000 будет остановлен, для учетной записи Localsystem SPN будет потерян.
Как уже отмечалось выше в этой статье, сертификация по уровню безопасности C2 подразумевает наличие у SQL Server 2000 встроенной, развитой системы аудита, которая состоит из нескольких компонент, описанных ниже. Совместно, эти компоненты позволяют отслеживать попытки применения любых прав в рамках SQL Server 2000.
SQL trace - это серверные компоненты обеспечения аудита.
Аудит был добавлен к аналогичному механизму SQL Server 7.0,
предоставляющему информацию об эффективности SQL Server.
Информация об эффективности по прежнему доступна, но в SQL
Server 2000 этот интерфейс был полностью пересмотрен. Все
соответствующие хранимые процедуры SQL Server 7.0 были
изменены.
Сообщения аудита безопасности обслуживаются на
уровне реляционного ядра или движка базы данных SQL Server, с
уведомлением механизма трассировки (SQL trace). При запущенном
механизме трассировки, происходит фиксация имеющихся сообщений
в соответствующий файл трассировки.
Для получения
дополнительной информации о новых хранимых процедурах,
используемых для аудита безопасности, о запуске трассировки и
включении режима C2 - см. SQL Server 2000 Books Online.
SQL Profiler является утилитой с графическим интерфейсом, которая позволяет просматривать файлы трассировки аудита безопасности, и совершать с этими файлами, посредством пользовательского интерфейса, такие операции, как: поиск по файлу, сохранение трассы в файл или в таблицу, а также можно создавать и настраивать описатель трассы. По сути, SQL Profiler является клиентом SQL trace, и не обязательно иметь запущенным SQL Profiler, чтобы аудит безопасности был работоспособен, он работает автономно от SQL Profiler.
Режим аудита C2 предопределяет набор отслеживаемых событий (все события безопасности), которые фиксируют данные (всё, что несёт информацию об этих событиях), и другие установленные параметры настройки. Каждый из возможных режимов описан в SQL Server Books Online.
2.6. Исключение SQLAgentCmdExec Proxy Account
В SQL Server 2000 учетная записи SQLAgentCmdExec не
создаётся, в отличие от SQL Server 7.0 и более ранних версий,
где эта учётная запись применялась для заданий по расписанию
SQL Server Agent, запускаемых из контекста безопасности
логина, не имеющего привилегий системного администратора, для
получения доступа к ресурсам Windows. Это была локальная
учетная запись пользователя Windows NT 4.0 и Windows 2000,
созданная при установке SQL Server.
По умолчанию, для не
системных администраторов, способность обращаться к внешним,
по отношению к SQL Server, ресурсам заблокирована. Однако, в
SQL Server 2000 можно предоставить такому логину возможность
работы с внешними ресурсами через контекст безопасности
представительской учётной записи пользователя домена. Это
позволит логинам, не являющимися членами серверной роли
системных администраторов, обращаться к ресурсам сети, причём
преимущественно по отношению к локальным ресурсам компьютера,
на котором установлен SQL Server.
2.7. Расширение набора серверных ролей
В SQL Server 2000 был расширен набор фиксированных серверных ролей. Для получения более полной информации о фиксированных серверных ролях, см. раздел "Предопределенные роли", который будет ниже в этой статье.
BulkAdmin - это новая роль SQL Server 2000. Логины, включенные в эту роль, могут выполнять команду BULK INSERT. Пользователи, являющиеся членами этой группы, будут иметь возможность загружать данные из любого файла в сети и с любого компьютера, находясь в контексте безопасности учетной записи запускающей сервис MSSQLServer. Следует очень ответственно относиться к включению логинов в эту серверную роль. Для того, что бы члены этой роли могли выполнить команду BULK INSERT в какую-либо таблицу, им требуется иметь право на INSERT для этой таблицы. Членство в этой фиксированной серверной роли предоставляет права только на исполнение инструкции BULK INSERT и на обращение к файлам в течении исполнения команды.
Роль SecurityAdmin даёт право на изменение паролей логинов в режиме аутентификации SQL Server Authentication. Исключение из этого составляют только пароли членов фиксированной серверной роли sysadmin, которые не могут быть сброшены.
Роль ServerAdmin была расширена для обеспечения возможности управления серверными сообщениями. Членство в этой роли позволяет теперь логину исполнять хранимые процедуры: sp_addmessage, sp_dropmessage и sp_altermessage.
2.8.1. Шифрация трафика с использованием SSL/TLS
SQL Server 2000 поддерживает автоматическую шифрацию данных
и другого сетевого трафика, передаваемого между клиентом и
сервером через сеть. Сила шифрации зависит от сертификата,
установленного для SQL Server, а также от криптографических
возможностей клиента и сервера.
Сертификату, выбранному для
SQL Server, должно быть назначено имя сервера, в виде
полностью квалифицированного DNS имени. Например:
SQLServer.Redmond.corp.Microsoft.com. Сертификат должен быть
допустимым для режима аутентификации сервера.
Зарегистрировавшись на SQL Server под учетной записью сервиса
MSSQLServer, нужно получить сертификат (от внутренней службы
сертификатов или от доверенного стороннего провайдера,
например: Verisign), а затем установить его на сервере в том
месте, куда будет предложено его импортировать.
2.8.2. Login Packet Encryption
При любых попытках регистрации на сервере, если сертификат для сервера установлен и задействован (допустим для режима аутентификации и имеет правильное DNS имя компьютера в сертификате), все связанные с этим логином пакеты будут зашифрованы. Это произойдёт автоматически, без необходимости дополнительной настройки сервера, кроме установки непосредственно сертификата.
2.8.3. Client-Requested Encryption
Клиент может шифровать весь трафик данных на/от SQL Server.
Для этого необходимо установить в Client Network Utility опцию
Force Protocol Encryption, которая будет воздействовать на все
внешние подключения этого компьютера. Опция Client-Requested
Encryption также предотвращает доступ к SQL Server 7.0 и раним
версиям, и к любому серверу SQL Server 2000, который не имеет
правильного сертификата.
Вы также можете установить эту
опцию программно, указав "Encrypt=yes" в OLE DB или ODBC
строке подключения к серверу базы данных.
2.8.4. Server-Requested Encryption
Администратор базы данных может установить требование по шифрации трафика сервера. Для этого в SQL Server Network Utility устанавливается опция Force Protocol Encryption. Установка опции Server-Requested Encryption гарантирует, что весь сетевой трафик к/от SQL Server будет зашифрован. Если клиент не поддерживает шифрацию трафика с SQL Server, его подключение будет отвергнуто.
2.8.5. Поддержка Encrypted File System на Windows 2000
SQL Server 2000 поддерживает Encrypted File System, которая
встроена в операционную систему Windows 2000. Файлы баз данных
должны быть зашифрованы под сервисной учетной записью SQL
Server.
При изменении учетной записи, от имени которой
стартует SQL Server, Вы должны предварительно расшифровать
файлы.
2.8.6. Server-Based Encryption Enhanced
Для достижения наиболее полной возможности шифрации данных на стороне сервера (пароли, зашифрованные хранимые процедуры и так далее), в SQL Server 2000 были расширены возможности использования Windows Crypto API. Это гарантирует более гибкую и безопасную стратегию хранения данных и других объектов SQL Server.
Data Transformation Services (DTS) пакеты в SQL Server 2000
также могут быть зашифрованы с использованием Windows Crypto
API.
В SQL Server 7.0, если Вы вводили пароль для DTS
пакета, он шифровался, а пароль использовался как ключ. Если
Вы не введёте пароль, пакет не будет защищен. В SQL Server
2000 все пакеты шифруются, даже если пароль не был введён.
2.9.1. Резервирование и Backup Media Sets
SQL Server 2000 позволяет определять пароли для отдельной
резервной копии или для целого резервного набора (Backup Media
Sets). Без этого пароля невозможно восстановить резервную
копию. Это позволяет защищать резервные копии от
несанкционированного восстановления.
Сами данные не
шифруются, так что если программа восстановления не
выдерживает Microsoft Tape Format и может игнорировать пароль,
она сможет получить доступ к данным в резервной копии. Все
механизмы восстановления SQL Server используют пароль.
2.9.2. SQL Server Enterprise Manager
В SQL Server 2000 пароли для авторизованных логинов всегда шифруются с использованием Windows Crypto API. В SQL Server 7.0 эти пароли хранились в системном реестре компьютера клиента в незащищенном виде.
2.9.3. Изменение учётной записи сервиса с использованием SQL Server Enterprise Manager
При изменении учётной записи, от имени которой стартует SQL Server (SQL Server или SQL Server Agent) через SQL Server Enterprise Manager, права на файлы и каталоги (если данные хранятся в файловой системе NTFS) будут предоставлены новой учётной записи автоматически. Enterprise Manager также установит необходимые права к ключам системного реестра (новые разрешения будут добавлены, но и останутся у предыдущей сервисной учётной записи, также как и у группы built-in administrator's). Пароль будет изменён в базе данных сервисов (также, как если бы Вы поменяли его через Control Panel/ Services), и после этого соответствующие права Windows NT или Windows 2000 будут предоставлены новой сервисной учетной записи. Наконец, новая сервисная учетная запись будет добавлена в серверную роль SQL Server sysadmin.
2.9.4. В системных таблицах убран столбец SUID
В более ранних версиях столбец SUID присутствовал в следующих системных таблицах:
- Sysdatabases
- Syslogins
- Sysremotelogins
-
Sysusers
- Sysprocesses
- sysalternates
Этот столбец не использовался в SQL Server 7.0 (он был заменён столбцом SID) но сохранялся для обратной совместимости. В SQL Server 2000 этот столбец был удален. Также была удалена таблица sysalternates, т.к. она содержала только отношения между SUID.
2.10. Модель безопасности SQL Server 2000
Чтобы наиболее практичным способом обеспечить безопасность
SQL Server 2000, важно понять, что разработчики собирались
реализовать в модели безопасности, которая была внедрена в
СУБД. Те из вас, кто знаком с системой обеспечения
безопасности Windows, наверняка заметят возможность
использования мощного механизма групп и пользователей Windows,
привнесённых в SQL Server 2000.
Безопасность SQL Server
2000 должна строиться так, как показано на рисунке 1.
Рисунок 1. Использование пользователей и групп Windows позволяет администратору SQL Server создать мощную и гибкую модель безопасности.
Пронумерованные на рисунке шаги отображают следующее:
Шаг 1. Пользователи в каждом домене назначаются в
глобальные группы Windows.
Шаг 2. Глобальные группы Windows
разных доменов помещены в локальные группы Windows.
Шаг 3.
Локальной группе Windows предоставляются права на вход в SQL
Server 2000.
Шаг 4. Локальной группе Windows
предоставляются права доступа к соответствующим базам данных.
Эта локальная группа Windows не может быть той же самой, что и
используемая для предоставления прав логинам на Шаге 3.
Поэтому, Шаги 1 и 2 часто повторяются, чтобы сгруппировать
пользователей в соответствии с требуемыми разрешениями
доступа.
Шаг 5. Локальной группе Windows назначаются
разрешения на определенные объекты базы данных.
Другой подход к обеспечению безопасности основан на использовании ролей, и обычно осуществляется следующим образом (см. рисунок 2).
Рисунок 3. Безопасность на основе ролей SQL Server 2000.
При использовании ролей, для того, чтобы назначить разрешения объектам, учётной записи должны быть предоставлены разрешения на сервере и в базе данных, используя представленный ниже подход.
Шаги с 1 по 4 те же самые, что и на предыдущем рисунке, за исключением того, что множество глобальных и локальных группы Windows может не использоваться. Универсальные группы Windows 2000 также полностью поддерживаются в рамках этой модели. Шаг 5. Учётные записи и группы Windows помещаются в роли. Шаг 6. Разрешения объектов назначаются для роли.
Роли уменьшают необходимость группировки пользователей в Windows, группируя пользователей в SQL Server 2000.
Для обеспечения доступа, Microsoft SQL Server 2000 поддерживает два режима аутентификации: Windows Authentication Mode и смешанный режим - Mixed Mode. Обратите внимание, что режим аутентификации Standard, который был в SQL Server 6.5, начиная с SQL Server 7.0 больше не поддерживается.
2.11.1. Windows Authentication Mode
Windows Authentication Mode - в SQL Server 2000 режим аутентификации по умолчанию. В этом режиме для предоставления доступа пользователей или групп Windows к серверу баз данных, SQL Server 2000 полагается исключительно на Windows аутентификацию. SQL Server 2000 подтверждает подлинность пользователей почти таким же способом как другие прикладные программы, используя доверительные подключения. Когда используется Windows Authentication Mode, администратор базы данных предоставляет пользователям право подключаться к компьютеру, на котором запущен SQL Server, предоставляя, таким образом, им право подключится к SQL Server 2000. Чтобы отслеживать вход в систему Windows, применяются идентификаторы безопасности SID. Поскольку в Windows используются SID, администратор базы данных может предоставлять доступ для входа в систему непосредственно пользователям или группам.
В смешанном режиме, достоверность пользователей может быть обеспечена Windows аутентификацией или собственной аутентификацией SQL Server. Пользователи, заверенные аутентификацией SQL Server, имеют имя и пароль, обслуживаемые сервером баз данных самостоятельно. Если SQL Server 2000 используется в смешанном режиме, а клиент и сервер могут использовать для входа в систему протоколы аутентификации NTLM или Kerberos, при подтверждении подлинности пользователей сервер баз данных полностью полагается на Windows. Если клиент не способен использовать стандартный вход в систему Windows, SQL Server требует ввода имени пользователя и пароля, и сравнивает их с тем, что хранит в своих системных таблицах. Подключения, которые полагаются на ввод имени пользователя и пароля, называются, не доверенными (non-trusted connections). Смешанный режим оставлен по двум причинам: обратная совместимость и для обеспечения возможности установки SQL Server 2000 на операционных системах Windows 98 или Windows Me. Доверенные подключения не поддерживаются компьютерами с Windows 98 или Windows Me, когда они используются в роли сервера.
2.12. Поддержка Security Identification Numbers
SQL Server 2000 использует Security Identification Numbers (SID). Пользователям и группам Windows может быть предоставлен доступ непосредственно к базам данных или их определенным объектам. Например, Jane является в Windows членом групп SALES и MARKETING. Группе SALES было предоставлено разрешение на вход в SQL Server, и также возможность обращения к базе данных pubs. Администратор мог предоставить доступ к таблице authors для Jane через её имя в Windows, REDMOND\Jane. Учетная запись Windows должна быть указана в виде имени домена и пользователя. В таком случае, SID пользователя Jane будет сохранён в системных таблицах базы данных pubs. SQL Server 2000 не поддерживает User Principal Names (UPN). Например, если мы имеем логин: домен - SALES, пользователь - SOMEONE, то логин к SQL Server должен быть SALES\SOMEONE, и нельзя использовать логин в форме SOMEONE@MYCOMPANY.COM, как это поддерживается в Windows 2000 Active Directory.
Использование ролей очень похоже на использование групп
Windows. Роли позволяют собирать пользователей в модули, для
которых могут применяться разрешения. Предоставление
(granted), отклонение (denied) или отмена (revoked) разрешения
для роли также будут действительны для любого члена этой роли.
Образно говоря, роли похожи на однотипные задачи, выполняемые
рабочими одной профессии в организации. В таком случае,
разрешения можно предоставлять для роли, а не для каждого
отдельного рабочего. Поскольку рабочий относится к этой
профессии, он является членом роли; когда он перестаёт
относиться к ней, он автоматически удаляется из роли. Такой
алгоритм позволяет упростить и сделать более надёжным процесс
многократного предоставления, отклонения и отмены разрешений
для пользователей, когда они включаются в типовой набор задач
или наоборот, этот набор задач должен стать для них
недоступным.
Есть ряд ключевых моментов, которые делают
роли очень мощным инструментом. Прежде всего, за исключением
фиксированных серверных ролей, они существуют внутри базы
данных. Это означает, что администратор базы данных имеет
возможность не полагаться полностью на администратора Windows,
который группирует пользователей. Во вторых, роли могут быть
вложенными. Вложенность не ограничена уровнями, но по
очевидным причинам не допускает рекурсивности. В третьих, в
отличие от групп в SQL Server 6.5 и более ранних версиях,
пользователь базы данных может быть одновременно членом более
чем одной роли.
Роль public существует в каждой базе данных, включая системные базы данных master, msdb, tempdb и model. Роль public включает заданные по умолчанию разрешения для пользователей базы данных и не может быть удалена. Функционально, это похоже на группу Everyone в Windows NT 4.0. Каждый пользователь базы данных автоматически становится членом этой роли; поэтому, пользователи не могут быть добавлены или удален из неё.
SQL Server 2000 имеет несколько предопределенных ролей. Эти роли подразумевают наборы разрешений, которые нельзя предоставлять учетным записям пользователя по-другому. Есть два типа предопределенных ролей: фиксированные серверные роли и фиксированные роли базы данных.
2.13.3. Фиксированные серверные роли
Фиксированные серверные роли действуют в контексте всего сервера. Они существуют вне баз данных. Каждый член фиксированной серверной роли может добавлять другие логины в эту роль. Обратите внимание на то, что все члены группы Windows BUILTIN\Administrators (группа локальных администраторов) - по умолчанию включаются в роль sysadmin.
Фиксированные серверные роли SQL Server 2000:
Sysadmin - Исполняет любые действия с SQL Server.Serveradmin - Настраивает любые параметры серверной конфигурации, останавливает сервер.
Setupadmin - Управляет прилинкованными серверами и процедурами запуска.
Securityadmin - Управляет в рамках всего сервера параметрами настройки безопасности, включая прилинкованные сервера и разрешения CREATE DATABASE. Сбрасывает пароли для логинов с SQL Server аутентификацией.
Processadmin - Завершает процессы, выполняющиеся на SQL Server.
DBcreator - Создает, изменяет, удаляет и восстанавливает любую базу данных.
Diskadmin - Управляет дисками и файлами.
Bulkadmin - Позволяет не являющемуся членом sysadmin пользователю выполнять операции массовой загрузки.
Чтобы добавить пользователей в фиксированную серверную роль, используйте следующую инструкцию Transact-SQL:
/* Add Bob to the sysadmin server role */ exec sp_addsrvrolemember "REDMOND\Bob", "sysadmin"
Пользователи и группы Windows могут быть добавлены в
серверные роли.
Следующий пример кода показывает, как
добавить пользователя в серверную роль, используя SQL-DMO:
' Declare variables
Dim oServer As SQLDMO.SQLServer
' Create a server object and connect
Set oServer = CreateObject("SQLDMO.SQLServer")
oServer.Connect ("ServerNAME")
' Add Bob to the sysadmin server role
oServer.ServerRoles("sysadmin").AddMember ("REDMOND\Bob")
Для получения дополнительной информации об использовании фиксированных серверных ролей, см. SQL Server Books Online для SQL Server 2000.
2.13.4. Фиксированные роли базы данных
Фиксированные роли базы данных существуют на уровне базы и
есть в каждой базе. Члены административных ролей DB_owner и
DB_security могут управлять членством ролей базы данных;
однако, только DB_owner может добавлять других в фиксированную
роль базы данных DB_owner.
Фиксированные роли базы данных
SQL Server 2000:
DB_owner - Выполняет все виды обслуживания и любые действия
по настройке базы данных.
DB_accessadmin - Разрешает или
запрещает доступ для пользователей, групп Windows и логинов
SQL Server.
DB_DataReader - Читает все данные во всех
пользовательских таблицах.
DB_DataWriter -Добавляет,
удаляет или изменяет данные во всех пользовательских
таблицах.
DB_ddladmin - Выполняет любые команды языка
определения данных (DDL) для базы данных.
DB_securityadmin
- Управляет членами ролей и разрешениями.
DB_backupoperator
- Резервирует базу данных.
DB_denydatareader - Не может
читать никакие данные в пользовательских таблицах базы
данных.
DB_denydatawriter - Не может добавлять, изменять
или удалять данные в любых пользовательских таблицах или
представлениях.
Для получения дополнительной информации об использовании фиксированных ролей баз данных, см. SQL Server Books Online для SQL Server 2000.
2.13.5. Определяемые пользователем роли
Определяемые пользователем роли предоставляют простой
способ управления разрешениями в базе данных, когда группа
пользователей исполняет фиксированный набор действий в
пределах SQL Server 2000, и нет никакой возможности применить
группы Microsoft Windows или если администратор базы данных не
имеет права управлять учетными записями пользователя Windows.
В таких случаях, определяемые пользователем роли обеспечивают
администратору базы данных ту же самую гибкостью, как и группы
Windows.
Определяемые пользователем роли применяются только
на уровне базы данных, и являются локальными для базы данных,
в которой они были созданы.
Роли приложений позволяют администратору базы данных
ограничивать пользовательский доступ к данным, осуществляемый
через приложение, которое использует пользователь. Роли
приложений позволяют приложению самому заниматься
аутентификацией пользователей.
Когда приложение
подключается к SQL Server 2000, оно выполняет хранимую
процедуру sp_setapprole, которая принимает два параметра: имя
пользователя и пароль (эти параметры могут быть зашифрованы).
Установленные ранее разрешения, назначенные пользователю,
отбрасываются и применяется контекст безопасности роли
приложения.
После того, как роли приложений активизированы,
они не могут быть дезактивированы. Единственный способ
возврата к первоначальному контексту безопасности пользователя
состоит в том, чтобы отсоединиться и повторно соединиться с
SQL Server.
Роли приложений работают с обоими режимами
аутентификации, и не могут иметь членов таких ролей.
Пользователи не могут быть включены в роли приложений,
поскольку приложение запрашивает контекст безопасности своей
роли, используя хранимую процедуру sp_setapprole.
Так же,
как определяемые пользователем роли, роли приложений
существуют только внутри базы данных. Если, в то время как
приложение находится в контексте безопасности роли приложения,
обращаются к другой базе данных, доступ к этой базе будет
осуществляться с учётом разрешений, предоставленных учетной
записи guest в этой базе данных. Если учетной записи guest не
был явно предоставлен доступ к данным или она не существует, к
объектам базы обращаться низя. Другая ключевая концепция в
использовании ролей приложений это то, что ревизия действий
пользователя, который использует приложение, всё равно
осуществляется SQL Server 2000. Другими словами, роли
приложений обеспечивают контекст безопасности, в пределах
которого разрешения на объекты базы данных проверяются, но
тождественность операций по отношению к фактическому
пользователю не утрачивается.
Рассмотрим пример
использования роли приложения. Если Джейн является членом
группы ACCOUNTING, а членам группы ACCOUNTING разрешен доступ
к данным SQL Server только через программный пакет, для этой
программы может быть создана роль приложения. Роли приложения
ACCOUNTING может быть предоставлен доступ к данным, в то время
как группа Windows ACCOUNTING будет лишена доступа к этим
данным. Таким образом, когда Джейн пытается обращаться к
данным, используя SQL Query Analyzer, она не получит доступ;
но если Джейн использует программу, она сможет получить такой
доступ.
Этот пример показывает, как программа может
использовать роль приложения. Чтобы использовать роли
приложений, повторите следующие шаги:
· Создайте роль приложения.
· Назначьте разрешения для
роли приложения.
· Убедитесь, что клиентское приложение
соединяется с SQL Server 2000.
· Убедитесь, что клиентское
приложение активизирует роль приложения.
Первые два шага этого процесса обычно отделяются от последних двух шагов. Поэтому, два представленных ниже фрагмента кода будут на Transact-SQL и Visual Basic соответственно.
Скрипт Transact-SQL содержит следующие:
/* Create the application role. */ EXEC sp_addapprole "AccAppRole", "ABC" /* Grant permissions to SELECT. */ GRANT SELECT ON authors TO AccAppRole GO
Этот код активизирует роль:
/* Activate the role. */
EXEC sp_setapprole "AccAppRole", {ENCRYPT N "ABC"}
Шифрация пароля не обязательна, но она гарантирует большую безопасность, когда пароль должен передаваться через WAN сеть.
Код на Visual Basic:
' Declare variables.
Dim oServer As SQLDMO.SQLServer
Dim oDbRole As SQLDMO.DatabaseRole
' Create a server object and connect.
Set oServer = CreateObject("SQLDMO.SQLServer")
oServer.Connect ("ServerNAME")
' Create the Role object.
Set oDbRole = CreateObject("SQLDMO.DatabaseRole")
' Set the appropriate properties.
oDbRole.Name = "AccAppRole"
oDbRole.AppRole = True
oDbRole.Password = "ABC"
' Add the Role object to the servers Role collection.
oServer.Databases("pubs").DatabaseRoles.Add oDbRole
Использовать роль:
' Declare variables.
Dim oConnection As ADODB.Connection
' Create the connection object and connect.
Set oConnection = CreateObject("ADODB.Connection")
oConnection.Provider = "sqloledb"
oConnection.Open "Server=ServerNAME;Database=pubs;Trusted_Connection=yes"
' Activate the application role. There is no error handling for this sample.
oConnection.Execute "EXEC sp_setapprole 'AccAppRole', {ENCRYPT N 'ABC'}, 'ODBC'"
Стиль шифрации (последний параметр) должен быть установлен
для OLE DB и ODBC источники данных. Все другие источники
данных не могут явно шифровать пароль. В таких случаях, Вы
должны использовать шифрованный протокол связи с
сервером.
Роли приложений действенны во время сеансов. Если
ваше приложение открывает много сеансов, и все сеансы
используют одну роль, каждый сеанс должен её сначала
активизировать.
Применение ролей приложений может
использоваться для того, чтобы обеспечить более
детализированную безопасность чем без них. Например,
клиентское приложение может для одних подключений использовать
контекст безопасности пользователя, а для других контекст
безопасности роль приложения.
Если Вы применяете роли
приложений, выполнение SELECT USER возвращает имя роли
приложения, используемой в настоящее время. Если требуется имя
зарегистрировавшегося пользователя, используйте следующую
инструкцию T-SQL: SELECT System_USER.
2.14. Обеспечение доступа к серверу
Доступ к серверу контролируется двумя разными способами, в зависимости от текущего режима аутентификации SQL Server 2000. Однако, после того как пользователь получит доступ к серверу, оба режима работают одинаково. Значением по умолчанию для системы безопасности SQL Server 2000 является режим Windows Authentication, когда он не изменён при установке или при настройке безопасности.
Для обеспечения доступа на уровне Windows, администратор
должен создать логин для каждого пользователя, который будет
обращаться к SQL Server (если пользователь ещё не имеет
учетной записи). В каждом домене для учетных записей
пользователей должны быть созданы глобальные группы, куда
помещаются пользователи в соответствии с требованиями бизнес
логики. Пользователи должны быть помещены в соответствующие
глобальные группы в их домене.
На компьютере, где запущен
SQL Server 2000, должны быть созданы локальные группы согласно
различным требованиям к решаемым ими задачам, и через которые
им будет предоставлен доступ к SQL Server. Необходимые
глобальные группы из разных доверенных доменов должны быть
помещены в соответствующие локальные группы на компьютере, где
запущен SQL Server.
Требования к глобальным и локальным
группам, которые были представлены ранее, похожи на множество
маленьких, отдельных доменов сети; однако, практика
показывает, что такой подход имеет существенно большее
значение и выгоды при его реализации.
Основное требование
заключается в том, что необходимо собрать всех пользователей с
одинаковыми требованиями безопасности в одном модуле, который
может использоваться администратором базы данных для
предоставления доступа к SQL Server 2000. Предоставление
доступа к SQL Server через группы не исключает возможность
идентификации каждого отдельного пользователя при работе с
базой данных.
Хотя эти рекомендации важны, администратор
базы данных может назначать права на объекты для универсальных
групп Windows, глобальных групп, локальных групп и для
отдельных учетных записей пользователей. Обратите внимание,
что создание учетных записей пользователей и групп программно
в среде Windows выходит за рамки этого документа. Это может
быть достигнуто с использованием объектов ADSI model в
Microsoft Visual Basic или непосредственно с помощью
интерфейса Win32 API в Microsoft Visual C ++.
На уровне SQL Server 2000, разрешения нужно предоставлять
для созданной локальной группы Windows, через которую будут
предоставляться права подключения к SQL Server. Разрешение на
подключение к SQL Server также можно предоставлять
непосредственно пользователям, но не в качестве повседневной
практики управления не маленькой средой.
Разрешение на
подключение к серверу можно предоставлять через интерфейс
пользователя или программно, используя Microsoft Visual Basic
или Transact-SQL.
Были добавлены новые хранимые процедуры,
которые позволяют предоставлять доступ для пользователей и
групп Windows. Эти процедуры перечислены ниже:
sp_addalias sp_droprole sp_addapprole sp_droprolemember sp_addgroup sp_dropserver sp_addlinkedsrvlogin sp_dropsrvrolemember sp_addlogin sp_dropuser sp_addremotelogin sp_grantdbaccess sp_addrole sp_grantlogin sp_addrolemember sp_helpdbfixedrole sp_addserver sp_helpgroup sp_addsrvrolemember sp_helplinkedsrvlogin sp_adduser sp_helplogins sp_approlepassword sp_helpntgroup sp_change_users_login sp_helpremotelogin sp_changedbowner sp_helprole sp_changegroup sp_helprolemember sp_changeobjectowner sp_helprotect sp_dbfixedrolepermission sp_helpsrvrole sp_defaultdb sp_helpsrvrolemember sp_defaultlanguage sp_helpuser sp_denylogin sp_password sp_dropalias sp_remoteoption sp_dropapprole sp_revokedbaccess sp_dropgroup sp_revokelogin sp_droplinkedsrvlogin sp_setapprole sp_droplogin sp_srvrolepermission sp_dropremotelogin sp_validatelogins
Представленная ниже инструкция Transact-SQL предоставляет право подключения для локальной группы SALESLG:
/* Grant login. */ exec sp_grantlogin 'REDMOND\SALESLG'
По другому, право на подключение можно предоставлять с помощью кода на Visual Basic:
' Declare variables.
Dim oServer As SQLDMO.SQLServer
Dim oLogin As SQLDMO.Login
' Create a server object and connect.
Set oServer = CreateObject("SQLDMO.SQLServer")
oServer.Connect ("ServerNAME")
' Create the Login object.
Set oLogin = CreateObject("SQLDMO.Login")
' Set the appropriate properties.
oLogin.Name = "REDMOND\SALESLG"
oLogin.Type = SQLDMOLogin_NTGroup
' Add the Login object to the server's Logins collection.
oServer.Logins.Add oLogin
Чтобы разрешить пользовательский доступ к SQL Server 2000,
используя не доверительные подключения, учетная записи
пользователя должна быть создана на SQL Server.
Обратите
внимание, когда SQL Server 2000 установлен на Windows и
настроен на использование смешанного режима, имеющие такую
возможность клиенты всё ещё могут осуществлять доверительные
подключения. Следующий Transact-SQL скрипт создает логин для
не доверительного подключения:
/* Add a login. */ exec sp_addlogin 'Bob', 'password', 'pubs'
Эта инструкция добавляет пользователя по имени Bob и
устанавливает ему пароль: password. Заданной по умолчанию
базой данных для этого пользователя становится pubs. Заданная
по умолчанию база данных - это база, к которой пользователь
переключается при попытке входа. Для логина пользователя по
прежнему необходимо создавать учетную запись (пользователя) в
заданной по умолчанию базе данных, чтобы он мог с ней
работать; sp_addlogin не добавляет пользователя в упомянутую
базу данных.
То же самое можно сделать, используя Visual
Basic:
' Declare variables.
Dim oServer As SQLDMO.SQLServer
Dim oLogin As SQLDMO.Login
' Create a server object and connect.
Set oServer = CreateObject("SQLDMO.SQLServer")
oServer.Connect ("ServerNAME")
' Create the Login object.
Set oLogin = CreateObject("SQLDMO.Login")
' Set the appropriate properties.
oLogin.Name = "Bob"
oLogin.Type = SQLDMOLogin_Standard
oLogin.SetPassword "","password"
' Add the Login object to the server's Logins collection.
oServer.Logins.Add oLogin
2.15. Обеспечение доступа к базе данных
Успешная регистрация на SQL Server 2000 не даёт
пользователю автоматически доступ ко всем базам данных. Что бы
пользователь мог работать с базой данных, ему нужно
предоставить на это соответствующие разрешения.
В этом
разделе, мы не будем делать различий между не доверенными
пользователями, пользователями Windows и группами Windows.
Когда ссылка указывает на пользователя или группу Windows, они
могут быть пользователями или глобальными группами в
доверенных доменах или располагаться в доменах того же дерева
или леса.
В каждой базе данных, создается пользователь и
привязывается к логину SQL Server, пользователю или группе
Windows. SQL Server Enterprise Manager, который основан на
Microsoft Management Console (MMC), является основным
инструментом управления SQL Server 2000, и не позволяет
создавать пользователей, которые не имеют разрешений на вход в
систему. MMC создает список всех учетных записей, которым
предоставлено разрешение входа на сервер, и может работать
только с ними. Тот же самое происходит и при использовании
SQL-DMO.
Средствами Transact-SQL можно предоставлять права
доступа к базе данных любым логинам SQL Server, пользователям
или группам Windows, если они существуют в таблице sysxlogins
базы данных master.
Обратите внимание, хотя это и не
является техническим требованием, если Вы используете
доверительное подключение, настоятельно рекомендуется, чтобы в
каждой базе данных Вы создавали пользователей с теми же
именами, как и у соответствующих логинов.
Ниже представлены
примеры инструкций Transact-SQL, предоставляющих разрешения на
доступ к базе данных:
/* Grant access to Bob. */ exec sp_grantdbaccess 'REDMOND\Bob' /* Grant access to Wendy, referring to her by first name within this database. */ exec sp_grantdbaccess 'REDMOND\WendyH', 'Wendy'
Требуется внести только одно изменение в этот скрипт, чтобы
дать права для не доверительного подключения клиента. Вместо
имени пользователя и домена, используйте имя пользователя,
которое использует SQL Server 2000 для подтверждения его
подлинности.
При использовании SQL-DMO, аналогичные
операции можно сделать следующим образом:
' Declare variables.
Dim oServer As SQLDMO.SQLServer
Dim oUser As SQLDMO.User
' Create a server object and connect.
Set oServer = CreateObject("SQLDMO.SQLServer")
oServer.Connect ("ServerNAME")
' Create the User object.
Set oUser = CreateObject("SQLDMO.User")
' Set the appropriate properties.
oUser.Name = "Bob"
oUser.Login = "REDMOND\Bob"
' Add the User object to the servers Users collection.
oServer.Databases("pubs").Users.Add oUser
2.15.1. Обеспечение доступа к объектам базы данных
Разрешения можно предоставлять ролям и пользователям и они могут быть назначены для предоставления права пользователям выполнять инструкции и для обеспечения возможности обращения к объектам базы данных. Разрешения для операторов ограничивают возможность исполнения инструкций: CREATE DATABASE, CREATE TABLE или CREATE FUNCTION. Разрешения на объекты ограничивают доступ к таблицам, представлениям, определяемым пользователем функциям или хранимым процедурам. Они зависят от типа объекта, например, для таблиц могут быть установлены разрешения на SELECT, INSERT, UPDATE, DELETE и REFERENCES, в то время как для хранимых процедур устанавливается разрешения EXECUTE.
2.15.2. Определяемые пользователем роли базы данных
В идеале, в ролях нет необходимости. Это возможно в такой
среде, где все пользователи подключаются посредством Windows
Authentication Mode к SQL Server 2000, работающему под
управлением Windows NT 4.0 или Windows 2000. Администратор
базы данных может попросить администратора Windows разместить
всех пользователей с определёнными требованием доступа к
данным (роль) в одну группу Windows, и тогда он предоставит
необходимые разрешения непосредственно для этой группы
Windows.
Однако, в большинстве реализаций дело обстоит не
так, создание групп Windows не всегда возможно. Например, при
установке SQL Server 2000 на операционную систему Windows 98,
группы Windows создать технически не возможно. В этом случае
могут использоваться пользовательские роли, группирующие их в
соответствии с требованиями на разрешения. Любой пользователь
или группа Windows могут быть назначены роли, а уже ей могут
быть назначены разрешения на объекты базы данных, подобно
тому, как назначаются разрешения для пользователей
базы.
Обратите внимание, что определяемые пользователем
роли могут быть созданы только в базе данных. Фиксированные
серверные роли и фиксированные роли базы данных предопределены
и не могут быть изменены. Роли могут быть созданы средствами
Transact-SQL:
/* Add role for Telephone Operators. */ exec sp_addrole "TelephoneOperators"
Следующий пример показывает, как роли могут быть созданы в коде Visual Basic:
' Declare variables.
Dim oServer As SQLDMO.SQLServer
Dim oDbRole As SQLDMO.DatabaseRole
' Create a server object and connect.
Set oServer = CreateObject("SQLDMO.SQLServer")
oServer.Connect ("ServerNAME")
' Create the Database Role object.
Set oDbRole = CreateObject("SQLDMO.DatabaseRole")
' Set the appropriate properties.
oDbRole.Name = "TelephoneOperators"
' Add the Role object to the servers Role collection.
oServer.Databases("pubs").DatabaseRoles.Add oDbRole
После того, как создана определяемая пользователем роль
базы данных, в неё могут быть добавлены пользователи, группы
или другие роли. Роли могут быть вложенными, хотя рекурсия не
допускается.
Следующий пример на Transact-SQL добавляет
пользователя Windows, группу Windows и роль базы данных в
недавно созданную роль:
/* Add a Windows user to the TelephoneOperators role. */ exec sp_addrolemember "TelephoneOperators", "REDMOND\Bob" /* Add a Windows group to the TelephoneOperators role. */ exec sp_addrolemember "TelephoneOperators", "REDMOND\Sales" /* Add HelpDeskOperators role to TelephoneOperators role. */ exec sp_addrolemember "TelephoneOperators", "HelpDeskOperators"
И снова с SQL-DMO:
' Declare variables.
Dim oServer As SQLDMO.SQLServer
' Create a server object and connect.
Set oServer = CreateObject("SQLDMO.SQLServer")
oServer.Connect ("MSNZBENTHOM")
' Use with statement for code legibility.
With oServer.Databases("pubs").DatabaseRoles("TelephoneOperators")
' Add the Windows user to the TelehoneOperators role collection.
.AddMember ("REDMOND\Bob")
' Add the Windows group to the TelehoneOperator's role collection
.AddMember ("REDMOND \Sales")
' Add the HelpDeskOperators role to TelehoneOperators role collection.
.AddMember ("HelpDeskOperators")
End With
Система разрешения SQL Server 2000 основана на такой же модели, которая формирует разрешения в Windows. Если пользователь является членом ролей sales, marketing и research (теперь возможны множественные членства в группах), пользователь получает сумму соответствующих разрешений от каждой роли. Например, если sales имеют на таблицы разрешение SELECT, marketing имеет разрешение INSERT, а research имеет разрешение UPDATE; пользователь получит сумму разрешений: SELECT, INSERT и UPDATE. Однако, как и с Windows, если для одной из ролей, членом которой пользователь является, было отклонено какое-нибудь разрешение на объекты (например SELECT), пользователь будет неспособен осуществлять такие операции над объектами. Наиболее приоритетным ограничительным разрешением является Deny.
2.15.4. Предоставление и отрицание разрешений для пользователей и ролей
Разрешения в базе данных всегда предоставляются
пользователям базы, ролям и пользователям или группам Windows,
но они никогда не предоставляются логинам SQL Server 2000. Для
предоставления разрешений пользователям или ролям базы данных
используются методы: Grant - предоставление разрешений, Deny -
отрицающие разрешение и Revoke - отменяющее
разрешение.
Deny позволяет администратору запрещать
пользователю или роли работать с объектами или инструкциями.
Как в случае разграничения прав Windows, Deny имеет приоритет
по отношению ко всем другим разрешениям.
Например, если бы
некоторые пользователи базы данных позволяли себе фривольно
изменять данные, было бы не справедливо удалить эти разрешения
для всех пользователей, поскольку большинство пользователей
использует данные вполне ответственно. Можно создать новую
роль с именем, например, trouble_makers, а затем установить
для неё Deny для операций INSERT, UPDATE и DELETE на все
блокируемые таблицы. Если пользователи плохо себя ведут, они
помещаются в роль trouble_makers, но это не повлияет на работу
другого персонала, групп или на разрешения ролей. Отменяющие
разрешение Revoke, по своей сути, отличается от отрицающего
разрешения Deny. Revoke удаляет предыдущие предоставление
разрешений Grant или Deny, а разрешение Deny запрещает доступ
даже тогда, когда было предоставлено разрешение на
доступ.
В представленных ниже примерах, каждый из этих
методов будет продемонстрирован на Visual Basic и на
Transact-SQL. Инструкция Transact-SQL предоставляет Бобу и
Джейн разрешение на SELECT в таблице authors, и предоставляет
Джейн разрешение на INSERT в таблицу titles:
/* Grant permissions to SELECT. */ GRANT SELECT ON authors TO Bob, [REDMOND\Jane] GO /* Grant permissions to INSERT. */ GRANT INSERT ON titles TO [REDMOND\Jane] GO
Предыдущий пример показывает, как работает инструкция Grant
при предоставлении разрешения пользователю базы данных (Боб) и
при предоставлении разрешения пользователю Windows
(Джейн).
Вот - тот же самый пример на Visual Basic:
' Declare variables.
Dim oServer As SQLDMO.SQLServer
' Create a server object and connect.
Set oServer = CreateObject("SQLDMO.SQLServer")
oServer.Connect ("ServerNAME")
' Grant Jane and Bob permissions to select from the authors table.
oServer.Databases("pubs").Tables("authors").Grant SQLDMOPriv_Select, "Bob"
oServer.Databases("pubs").Tables("authors").Grant SQLDMOPriv_Select, _
"[REDMOND\Jane]
' Grant Jane permissions to select from the authors table.
oServer.Databases("pubs").Tables("authors").Grant SQLDMOPriv_Select, _
"[REDMOND\Jane]"
В предыдущих примерах, есть небольшое различие между предоставлением доступа пользователю с полностью квалифицированным именем домена, и предоставлением доступа пользователю, который уже имеет разрешение на непосредственный доступ к базе данных. Следующие примеры используют только существующих в базе данных пользователей. Представленный ниже пример на Transact-SQL показывает, как пользователю может быть отклонено разрешение SELECT:
/* Deny permissions to SELECT. */ DENY SELECT ON authors TO Bob GO
И снова Visual Basic:
' Declare variables.
Dim oServer As SQLDMO.SQLServer
' Create a server object and connect.
Set oServer = CreateObject("SQLDMO.SQLServer")
oServer.Connect ("ServerNAME")
' Deny Bob permissions to select from authors table.
oServer.Databases("pubs").Tables("authors").Deny SQLDMOPriv_Select, "Bob"
Пример на Transact-SQL, который показывает отмену разрешения для пользователя:
/* Revoke permissions to SELECT. */
REVOKE SELECT
ON authors
FROM Bob
GO
Here is the Visual Basic code:
' Declare variables.
Dim oServer As SQLDMO.SQLServer
' Create a server object and connect.
Set oServer = CreateObject("SQLDMO.SQLServer")
oServer.Connect ("ServerNAME")
' Revoke Bob permissions to select from the authors table.
oServer.Databases("pubs").Tables("authors").Revoke SQLDMOPriv_Select, "Bob"
Правильное понимание функционирования цепочек владения
является критически важным для реализации безопасности SQL
Server 2000. Концепция цепочек владения вступает в силу, когда
проверены разрешения на объекты. Например, когда пользователь
обращается к представлению, разрешение на представление должно
быть проверено, но возникает вопрос: должны ли проверятся
разрешения на исходные для представления таблицы?
SQL
Server 2000 всегда проверяет разрешения на объекты, когда
цепочка владения разорвана. Разорванная цепочка владения - это
когда объект не имеет того же самого владельца как у его
образующих объектов. Например, если Боб создает таблицу, а
Мэри создаёт представление, основанное на этой таблице,
получается разорванная цепочка владения.
С точки зрения
безопасности, наличие разорванных цепочек владения определяет,
что разрешения должны быть проверены до уровня первоначального
объекта, к которому последует обращение.
Концепцию цепочек
владения лучшие объяснять на примере. Принимаем, что владелец
таблицы Боб. Он даёт к ней доступ Мэри, предоставляя ей
разрешение на SELECT для этой таблицы. Мэри создает
представление на таблице Боба, которое удовлетворяет её
потребностям. Их коллега Сью видит, что Мэри использует своё
представление, и у неё возникает желание также им
пользоваться. Мэри соглашается дать Сью доступу к
представлению. Однако, в намерения Боба не входило то, что Сью
сможет видеть данные в его таблице. К счастью, есть
разорванная цепочка владения, так как владелец таблицы Боб, а
владелец представления Мэри. Владелец представления не
является владельцем объекта - таблицы, которая лежит в основе
представления. В таком случае, когда Сью, попытается
использовать представление, SQL Server проверит разрешения на
представление, что бы убедиться в том, что Сью, был
предоставлен к нему доступ. После этого, также будут проверены
разрешения на таблицу Боба. Если Сью не был предоставлен
доступ к таблице, она не сможет использовать представление.
Это произойдёт из-за того, что цепочка владения разорвана.
Таким образом, концепция разорванных цепочек владения
позволяет принимать меры против получения несанкционированного
доступа к данным. Наоборот, если Боб решит создать
представление, и запретить Сью доступу к его таблице, но
предоставит доступ к представлению, тогда Сью сможет
обращаться к представлению. В этом случае, разрешения будут
проверятся только когда Сью будет осуществлять доступу к
представлению. Тут не будет никакой разорванные цепочки
владения, так что разрешения для основной таблицы не будут
проверятся. Поскольку Боб создал оба объекта, он должен
понимать, что предоставление доступа к представлению потребует
неявного доступа к основным объектам.
В качестве ещё одного
примера мы можем рассмотреть то, как SQL Server 2000
использует концепцию цепочек владения при вводе паролей
пользователей. Пользователям нельзя непосредственно обновлять
системные таблицы, особенно в базе данных master. При
использовании SQL Server 2000 смешанного режима
аутентификации, комбинация имени и пароля сохраняется в
системной таблице sysxlogins. Пользователям нужно дать
легальную возможность изменить их пароли. SQL Server 2000
делает это вызывая хранимую процедуру, которую может исполнить
любой пользователь, чтобы изменить свой пароль. Доступ к
таблице sysxlogins отключён, но разрешено выполнять
sp_password, эта хранимая процедура доступна всем
пользователям. Поскольку хранимая процедура sp_password и
системная таблица sysxlogins имеют одного владельца, не
получается разрыва цепочки владения, и разрешения проверяются
только на хранимую процедуру.
Цепочки владения позволяют
SQL Server 2000 поддерживать такую схему безопасности, при
которой владелец данных может контролировать, кто будет с ними
работать. В то же время, повышается эффективность, потому что
не требуется проверять разрешения, если цепочка владения не
разорвана.