Введение в дисциплину «Безопасность систем баз данных». Теоретические основы построения реляционных баз данных. Верификация баз данных и проведение аудита в СБД. Распределенные базы данных, страница 50


Продолжение таблицы 6.1

setupadmin

(Setup Administrators)

  • управление связанными серверами;
  • конфигурирование хранимых процедур, запускаемых при старте сервера автоматически;
  • добавление учетных записей в роль setupadmin.

serveradmin

(Server Administrators)

Администрирование сервера:

  • настройка параметров служб;
  • управление полнотекстовым поиском;
  • останов служб и т. д.

securityadmin

(Security Administrators)

Администрирование безопасности сервера:

  • создание новых учетных записей;
  • предоставление прав на создание БД и управление ими;
  • включение учетных записей в роль securityadmin;
  • чтение журнала ошибок.

Примечание. Данная роль не позволяет включать учетные записи в роль sysadmin и выполнять любые изменения учетных записей системного администратора.

processadmin

(Process Administrators)

Закрытие пользовательских подключений к серверу в случае крайней необходимости (например, при зависании).


diskadmin

(Disk Administrators)

Выполнение операций с файлами баз данных на диске.


dbcreator

(Database Creators)

  • создание и удаление БД;
  • восстановление резервных копий БД и журналов транзакций.

bulkadmin

(Bulk Insert Administrators)

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

Включение учетной записи в серверную роль

Включение учетной записи в серверную роль можно выполнить средствами Transact-SQL, используя системную хранимую процедуру sp_addsrvrolemember из системной БД Master. Данная процедура принимает два строковых параметра: имя учетной записи и имя роли. Заметим, что в качестве имени роли здесь должно использоваться сокращенное обозначение (см. табл. 6.1): sysadmin, serveradmin, dbcreator и т. п. Например, чтобы предоставить учетной записи IvanIvanov права на создание, модификацию и удаление БД, а также права на создание резервных копий, следует включить его в роль Database Creator с помощью данного скрипта:

EXEC sp_addsrvrolemember ‘IvanIvanov’, ‘dbcreator’

Исключение учетной записи из серверной роли

Для удаления учетной записи из серверной роли используется системная хранимая процедура sp_dropsrvrolemember. Так же, как и sp_addsrvrolemember, она принимает в качестве параметров имя учетной записи и имя роли. Например:

EXEC sp_ dropsrvrolemember ‘IvanIvanov’, ‘dbcreator’

Результатом выполнения данного скрипта будет исключение учетной записи IvanIvanov из роли Database Creator.

Задание учетным записям отдельных разрешений

Включение в серверную роль – не единственный способ задать разрешения для учетной записи. На практике часто требуется либо разрешать, либо, наоборот, запрещать учетным записям выполнение отдельных действий. Для задания разрешений/запрещений в стандарте SQL предусмотрены, соответственно, команды GRANT и DENY. Имеется также команда REVOKE, снимающая выданные ранее разрешения и запрещения, и переводящая связку «субъект-объект» в состояние неявного отклонения доступа. В SQL Server 2005 все три команды используются при работе как с пользователями БД, так и с учетными записями, т. е. на обоих уровнях защиты от НСД.

Все три команды имеют очень сложный синтаксис в Transact-SQL. Однако если говорить о выдаче разрешений/запрещений учетным записям, можно рассмотреть наиболее распространенные варианты вызова.

Выдача разрешений на уровне сервера чаще всего имеет следующий вид:

GRANT разрешение TO учетная_запись [WITH GRANT OPTION]

Опция WITH GRANT OPTION разрешает передачу данного разрешения от данной учетной записи другим учетным записям. В следующем примере учетной записи IvanIvanov выдается разрешение на модификацию любых баз данных на сервере:

GRANT ALTER ANY DATABASE TO IvanIvanov

Учетной записи BorisBorisov выдается такое же разрешение, но дополнительно она наделяется правом передачи данного разрешения другим учетным записям: