ГОСЫ / Administrirovanie

запись sa и роль sysadmin использовать только тогда, когда действительно необходимо выполнить административные функции.

MS SQL Server имеет предопределенный набор ролей БД, которые подобны серверным ролям, но действуют на уровне конкретной БД:

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

db_owner Имеет все полномочия в базе данных - для администраторов БД

db_accessadmin Может удалять или добавлять идентификаторы пользователя - для администраторов БД

db_securityadmin Может управлять всеми полномочиями, объектами, ролями и элементами ролей пользователей в текущей БД - для администраторов БД

db_ddladmin Может выполнять операторы языка описания данных

Data Definition Language (DLL – CREATE DATABASE, CREATE TABLE), но не может выполнять операторы GRANT, REVOKE, DENY - для помощников администраторов БД или ответственных разработчиков db_backupoperator Может выполнять команды CHECKPOINT, BACKUP, не может выполнить RESTORE - для помощников администраторов БД или ответственных разработчиков db_datareader Может выбирать все данные из любой таблицы пользователя в базе данных в режиме чтения – для пользователей в случае необходимости

db_datawriter Может модифицировать данные из любой таблицы пользователя в базе данных – для пользователей в случае необходимости

db_denydatareader Запрет полномочия SELECT (чтения) для любых объектов базы данных – для пользователей в случае необходимости

11

	db_denydatawriter Запрет полномочия
	INSERT,	UPDATE и		DELETE
	(модификации данных) для любых
	объектов	базы	данных	– для
	пользователей		в	случае
	необходимости
В роль базы данных можно включать пользователей, которым предоставлен				доступ к

соответствующей БД, то есть они уже зарегистрированы в системе и имею право на подключение к кокретной БД.

MS SQL Server также предоставляет администратору возможность создавать новые роли БД. Наиболее простой и удобный способ создания новой роли предоставляет консольная служба Enterprise Manager . Или более сложный – при помощи хранимой процедуры sp_addrole.

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

Таким образом, роли упрощают администрирование – для большой группы равноправных пользователей удобнее сначала создать роль с соответствующим набором привилегий, затем создать учетные записи (с правами на уровне public – только доступ) и добавить их в роль. Все права роли автоматически передадутся учетным записям. Причем одна и та же учетная запись может обладать разным набором привилегий (согласно роли) для разных БД.

РОЛИ ПРИЛОЖЕНИЙ – application roles

MS SQL Server поддерживает возможность создания ролей для приложений. Особенность роли приложения заключается в том, что она не содержит пользователей баз данных. Назнваченные ей разрещения получает приложение, которое запросит доступ к SQL Server, указав имя роли и заданный для этой роли пароль. Преимущество ролей приложений перед обычными ролями пользователей заключается в том, что с их помощью администратор регулирует доступ к БД определенным пользователям в рамках конкретных приложений. В этом случае пользователи не смогут подключиться к серверу, например, посредством Query Analyzer (редактор и средство выполнения запросов) и выполнять SQL-команды. Разрешения роли приложения более приоритетны, чем разрешения пользователя БД.

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

Создать роль приложения так же просто, как и роль пользователя – при помощи Enterprise Manager (или хранимая процедура sp_addapprole).

НЕЯВНЫЕ СРЕДСТВА УСИЛЕНИЯ ЗАЩИТЫ БД

Чтобы максимально обезопасить данные от нежелательных изменений, можно применить технологию представлений (VIEWS – фактически хранимый запрос), ограничивающую не только доступ пользователя к конкретным таблицам БД, но и набор доступных для него столбцов и строк данных. Идея проста: если пользователю не требуется доступ к некоторым таблицам или столбцам таблицы БД, нужно создать представление (хранимый запрос), в котором исключить определенные таблицы или столбцы, а также наборы данных за счет логического условия. Затем пользователю предоставляются права на созданное представление, а не таблицы БД.

12