Система безопасности и администрирование SQL Server .

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

Управление базами данных

Для создания базы данных средствами TSQL используется команда CREATE DATABASE, однако обычно для этой цели используются возможности Enterprise Manager. В SQL сервер определено достаточно много операций с базами данных: увеличение (уменьшение) размеров файлов, изменение конфигурации (команда ALTER), присоединение и отсоединение, передача прав владения, изменение имени, просмотр свойств и, наконец, удаление (DROP DATABASE).

Как и в большинстве серверов баз данных, в SQL Server существует пользователь, наделенный всеми административными полномочиями - это System Administrator или ‘ sa '. После начальной установки сервера пароль sa пуст. Пользователь, создающий новую базу данных, автоматически становится её владельцем (‘ dbo ' – Data Base Owner). В момент создания базы определяется и пользователь ' guest '. Если учётная запись пользователя явно не отображается в пользователя конкретной базы данных, пользователю предоставляется неявный доступ с использованием гостевого имени guest. Обычно guest запрещают.

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

Роль позволяет объединить пользователей, выполняющих одинаковые функции, для упрощения администрирования. Роли бывают встроенные и пользовательские. Встроенные роли реализуются на уровне сервера и на уровне баз данных. Ниже приведена таблица встроенных ролей для базы данных:

Db_owner	Имеет все права в базе данных
Db_accessadmin	Может добавлять или удалять пользователей
Db_securityadmin	Управляет всеми разрешениями, объектами, ролями и пользователями
Db_ddladmin	Может выполнять все команды DDL, кроме GRANT, DENY, REVOKE
Db_backupoperator	Может выполнять команды архивирования данных
Db_datareader	Может просматривать любые данные в любой таблице
Db_datawriter	Может модифицировать любые данные в любой таблице
Db_denydatareader	Запрещается просматривать любые данные в любой таблице
Db_denydatawriter	Запрещается модифицировать любые данные в любой таблице

• Назначение прав пользователям

Основой системы безопасности SQL Server являются (1) учётные записи (accounts); (2) пользователи (users); (3) роли (roles); (4) группы (groups).

Когда пользователь подключается к SQL Server, действия, которые он может выполнять, определяются правами, выданными ему как пользователю и члену роли. Права выдаются администратором СУБД, владельцем базы данных или владельцем конкретного объекта базы данных. Права в базе данных можно разделить на три категории: (1) права на доступ к объектам баз данных; (2) права на выполнение команд TSQL; (3) неявные права. Сервер позволяет передавать права владения от одного пользователя другому.

Для управления разрешениями пользователя на доступ к объектам базы данных используются следующие команды:

GRANT { ALL [PRIVILEGES] | < вид действия >,…}

{

ON {<имя таблицы или представления>} [(<имя столбца>,…)]

| ON {< имя хранимой процедуры >}

| ON {< имя пользовательской функции >}

}

TO { PUBLIC | <имя объекта системы безопасности>,…}

[WITH GRANT OPTION]

[ AS <имя группы> | <имя роли>]

– назначение прав пользователям, где

ALL – пользователю предоставляются все возможные разрешения, иначе указать

<вид действия> – права на доступные для пользователя действия, а именно:

SELECT – на просмотр, для столбца таблицы и для таблицы (представления)

INSERT – на добавление, для таблицы (представления) в целом

UPDATE – на изменение, для столбца таблицы и для таблицы (представления)

DELETE – на удаление, для таблицы (представления) в целом

EXECUTE – на выполнение хранимых процедур

REFERENCES – возможность ссылаться на указанный объект (вводить в состав внешнего ключа).

<имя объекта системы безопасности> – учётные записи SQL Server, пользователи домена Windows; PUBLIC – для всех пользователей.

WITH GRANT OPTION – позволяет пользователю, которому сейчас предоставляются права, самому назначать права на доступ к объекту другим пользователям.

AS <имя группы> | <имя роли> – участие пользователя в роли, которой предоставлена возможность предоставлять права другим пользователям.

Примеры:

GRANT SELECT ON authors TO public

GRANT INSERT, UPDATE, DELETE ON authors TO Mary, John, Tom

GO

GRANT SELECT ON Plan_Data TO Accounting WITH GRANT OPTION

GRANT SELECT ON Plan_Data TO Jack AS Accounting

-- Джек не входит в роль Accounting, но кто-нибудь из этой роли может предоставить право

DENY { ALL [PRIVILEGES] | < вид действия >,…}

{

ON {<имя таблицы или представления>} [(<имя столбца>,…)]

| ON {<имя хранимой процедуры>}

| ON {<имя пользовательской функции>}

}

TO { PUBLIC | <имя объекта системы безопасности>,…}

[CASCADE]

[AS < имя группы > | < имя роли >]

– запрещение доступа пользователям к объектам базы данных. CASCADE отзывает права не только у данного пользователя, но также и у всех, кому он права предоставлял.

Пример (на запрещение выполнения команды TSQL):

DENY CREATE TABLE TO Jack CASCADE

Команда REVOKE используется для неявного отклонения доступ к объектам базы данных. Синтаксис аналогичен команде DENY. Неявное отклонение подобно запрещению доступа с тем отличием, что оно действует только на том уровне, на котором определено. Пример: пользователю Jack, который является участником роли GoodUsers, предоставлены права на доступ к таблице XFiles. Если при помощи REVOKE для роли GoodUsers отклоняются права на доступ к этой таблице, пользователь Jack всё равно может обращаться к этой таблице, поскольку права для него определены явно. Если же применить REVOKE персонально для него, он потеряет право на доступ к XFiles.

Разрешения, предоставленные роли, наследуются их членами. Если пользователю предоставлен доступ к объекту через членство в одной роли, но запрещён в другой, то конфликт доступа всегда решается в пользу запрещения.