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

В документации Microsoft для описания политики безопасности SQL Server 2005 используется понятие принципала (principal)¹. Данное понятие включает в себя и индивидуального пользователя, и группу пользователей, и приложение, которые претендуют на доступ к каким-либо ресурсам SQL Server. Можно определить принципалы трех уровней:

· локальные пользователи (Windows Local Logins) Windows и пользователи доменов (Windows Domain Logins). Уровень Windows;

· пользователи SQL Server или учетные записи (logins). Уровень SQL Server;

· пользователи (users), роли пользователей, роли приложений. Уровень базы данных.

Доступ к ресурсам SQL Server осуществляется в три этапа.

1. На первом этапе пользователь проходит проверку операционной системы на предмет принадлежности его к локальным пользователям Windows или пользователям домена.

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

· SQL Server доверяет операционной системе (аутентификация Windows) — учетные записи пользователей (logins) соответствуют локальным учетным записям Windows или учетным записям домена;

· учетные записи SQL Server не соответствуют учетным записям Windows (смешанная аутентификация), поэтому пользователь проходит дополнительную проверку, согласно данным (имя и пароль), хранящимся в разделе Security | Logins Object Explorer.

3. На третьем этапе происходит авторизация пользователя— определение
его прав в конкретных базах данных. Для этого в базах данных должны
существовать пользователи (users), связанные с конкретной учетной

записью SQL Server, которая была использована для аутентификации.

Пользователи

Для того чтобы получить доступ к какой-либо из баз данных, следует вначале создать учетную запись. В случае аутентификации Windows учетная запись берется из списка локальных пользователей компьютера или списка пользователей домена. Причем учетной записью может быть и группа пользователей. Это бывает очень удобно для администратора SQL Server, если он к тому же является еще администратором сети, т. к. одним действием предоставляется доступ к серверу целой группе пользователей. Если предполагается смешанная аутентификация, то следует указать имя учетной записи и ее пароль. Для учетной записи можно указать, что она является членом одной из девяти встроенных ролей (см. следующий подраздел), которые определяют возможность выполнять определенный набор действий на уровне сервера.

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

Роли

Роль в SQL Server фактически является синонимом группы пользователей. Однако термин "роль" более точен, поскольку указывает на определенный набор действий, которые могут выполнять пользователи. Роль позволяет объединять пользователей, выполняющих одинаковые функции (играющие одинаковые роли), для упрощения администрирования системы безопасности SQL Server. Роли существуют на уровне сервера и на уровне базы данных. При установке сервера на уровне сервера создается 9 фиксированных ролей. При создании базы данных также создается 10 фиксированных ролей. Кроме того, на уровне базы данных вы можете определять и свои роли. Кратко рассмотрим фиксированные роли. На уровне сервера:

О sysadmin — разрешено выполнять любые действия в SQL Server;

О setupadmin — управление связанными серверами;

О serveradmin — доступно конфигурирование и выключение сервера;

□ securityadmin— управляет учетными записями и правами на создание
базы данных;

· processadmin — может управлять процессами, запущенными в SQL Server;

· diskadmin — управляет файлами SQL Server;

· dbcreator — разрешено создавать и модифицировать базы данных;

О buikadmin — может управлять процессом массовой вставки (bulk insert).

Фиксированные роли базы данных:

О db_accessadmin — может удалять или добавлять пользователей базы данных;

· db_backupoperator — может выполнять операцию резервного копирования;

· db_datareader — может просматривать содержимое таблиц базы данных;

db_datawriter — может модифицировать данные таблиц;

О db_ddiadmin — может выполнять команды DDL;

О db_denydatareader — запрещается просматривать данные в любой таблице;

О db_denydatawriter — запрещается модифицировать данные в любой таблице;

· db_owner — обладает всеми правами в базе данных (собственник);

· db_securityadmin— может управлять ролями и разрешениями на уровне базы данных;

D public — любой пользователь базы данных автоматически становится членом этой роли. Данную роль используют для предоставления минимальных прав пользователю.

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

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

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

Схемы

В SQL Server 2005 введено еще одно новшество — схемы. Схема в базе данных представляет собой логическое образование, объединяющее несколько объектов базы данных.

Запомним следующее:

· для каждого пользователя определяется своя схема по умолчанию. При создании пользователем объекта базы данных этот объект по умолчанию помещается в данную схему;

· каждый объект базы (исключая объекты безопасности) относится к какой-либо схеме. В Object Explorer имя каждого объекта предваряется именем схемы, в которой находится. Например, dbo.tabiei (схема dbo ), zet.proc (схема zet);

· при создании объекта можно явно указать схему, в которую его нужно поместить. В базе данных могут существовать объекты с одинаковыми именами, но принадлежащие различным схемам. Одинаковые имена в одной схеме не допускаются;

П с введением схем исчезает понятие "собственник объекта", существовавшее в ранних версиях SQL Server. Объекты теперь отделены от пользователя;

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