Система безопасности. Аутентификация. Учетные записи и роли. Планирование разрешений

Для доступа к данным в SQL Server имеются следующие уровни защиты: операционная система, SQL Server, база данных, объектов базы данных. Для доступа к объектам и данным пользователь проходит два уровня проверки безопасности – уровень аутентификации и уровень проверки разрешений. Аутентификация пользователя – процесс допуска или не допуска к соединению с SQL Server. В SQL Server существует два режима контроля проверки возможности подключения: на уровне с SQL Server с SQL Server (SQL Server authentication) и смешанная система на уровне SQL Server и Windows NT (Windows NT authentication). В первом случае задается имя пользователя для входа (учетная запись) и пароль во время соединения. Во время установки SQL Server создается только одна учетная запись- sa. Эта учетная запись имеет все права на доступ ко всем объектам всех баз данных. Добавить новую учетную карточку можно с помощью мастера создания нового пользователя SQL Server Security Wizard или New Login через Security дерева административной консоли, либо с помощью системной хранимой процедуры: Sp_addlogin. Удаление имен пользователей для входа: Sp_droplogin ‘имя пользователя для входа’. Изменение паролей:

Sp_password ‘старый пароль’,’новый пароль’,’учетная запись пользователя для входа’

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

Sp_grantlogin ‘учетная запись для входа’ или запретить подключение’:

Sp_denylogin ‘учетная запись для входа’

Роль – именованный набор прав в рамках сервера или конкретной базы данных. Существуют встроенные роли, пользовательские роли, роли приложений. Встроенные роля в свою очередь могут быть серверными или ролями базы данных. Встроенные серверные роли:

Sysadmin - системный администратор (может выполнять любые действия с SQL Server)

Securityadmin – администратор безопасности (управляет учетными записями сервера)

Serveradmin - администратор сервера (управляет настройками сервера)

Setupadmin – администратор установки (добавляет и удаляет связанные серверы)

Processadmin – администратор процессов (осуществляет управление процессами)

Diskadvin – администратор дисков (осуществляет управление файлами)

Dbcreator – создатель баз данных (создает и изменяет их параметры)

Присвоение встроенной роли можно осуществить с помощью визарда или системной хранимой процедурой: Sp_addsrvrolemember ‘учетная запись пользователя’,’роль’

Отмена роли: Sp_dropsrvrolemember ‘учетная запись пользователя’,’роль’

Просмотр информации о встроенных ролях: Sp_helpsrole, sp_helpsrvrolemember

Встроенные роли баз данных:

Db_owner – владелец базы данных (может выполнять любые операции с базой данных)

Db_accessadmin – администратор доступа к базе данных (добавляет и удаляет пользователей базы данных)

Db_securityadmin – администратор безопасности базы данных (управляет ролями в базе данных и разрешениями на запуск команд и на работу с объектами базы данных)

Db_ddladmin – администратор DLL (добавляет изменяет и удаляет объекты базы данных)

Db_backupoperator – администратор резервного копирования (осуществляет резервное копирование базы данных)

Db_datareader - лицо, имеющее право на просмотр базы данных

Db_datawriter – лицо, имеющее право изменять старые данные и вносить новые

Db_denydatareader – лицо, которому запрещен просмотр данных

Db_denydatawriter – лицо, которому запрещено изменение данных

Для добавления пользовательских ролей (добавить новую серверную роль нельзя), а не встроенных можно воспользоваться системной хранимой процедурой, для которых сделать впоследствии ряд разрешений:

Sp_addrole ‘роль’,’владелец’

Удаление пользовательской роли:

Sp_droprole ‘роль’

В каждой базе данных имеется специальная роль – роль public. Каждый пользователь базы данных – член этой роли. Она не может быть удалена, её нельзя присвоить вручную, ей можно присвоить определенные разрешения, которые затем автоматически передаются всем пользователям базы данных.

Кроме пользовательских ролей можно создавать роли приложений. Эти роли нельзя присвоить пользователям. Чтобы использовать предоставленные этой ролью разрешения, её вначале надо активизировать. Роли приложений создаются хранимой процедурой:

Sp_addapprole ‘роль’,’пароль’

После этого роль приложения активизируется хранимой процедурой:

Sp_setapprole ‘имя роли’, ‘пароль’

Применяя роль приложения (иногда говорят прикладную роль), приложение обязано передать пароль при активизации роля (это единственный тип роли, требующий пароль), область видимости прикладной роли – только текущая база данных, прикладную роль, активизированную хранимой процедурой нельзя отключить в текущей базе данных до отключения пользователя от сети. Удаление текущей роли: Sp_dropaprole. Изменение пароля для прикладной роли в текущей базе данных: sp_approlepassword

Предоставление разрешений (прав доступа к данным) можно выполнить для следующих объектов: таблиц, значений по умолчанию, правил, индексов, представлениям, триггеров, хранимых процедур. Разрешения представляются учетным записям пользователей пользовательским ролям, ролям приложений. Разрешения бывают объектные и командные. Объектные разрешения управляют доступом к таблицам, видам, хранимым процедурам. Для каждого объекта могут быть предоставлены различные типы разрешений: Select – таблица, вид (читать), Update– таблица, вид (изменять), INSERT– таблица, вид (добавлять), Delete– таблица, вид (разрешает удалять данные), References– таблица (дает возможность пользователю обращаться к таблице или виду посредством предложения where), EXECUTE–хранимая процедура (разрешает пользователю выполнять хранимую процедуру), ALL – предоставляет любые разрешения.

Типы разрешений Select, UPDATE, INSERT, Delete используются часто. Они определяют возможность пользователя выполнять команды, в опции FROM которых перечислены такие объекты, как таблицы или представления, к которым пользователь должен иметь доступ. Тип разрешения Reference управляет доступом пользователя к поддержке целостности данных. На практике это необходимо только в том случае, когда требуется установить отношение между двумя объектами, имеющими разных владельцев. Тип разрешения EXECUTE позволяет пользователю выполнять хранимые процедуры. Таким образом, пользователь может выполнять какие-либо действия, определяемые хранимыми процедурами, но не имеет доступа непосредственно к данным таблиц или представлений. Разрешить или запрещать доступ к объектам базы данных может владелец объекта.

Командные разрешения: возможность выполнять следующие команды: Create Database, Create Default, Create Procedure, Create Table, Create View, Backup Database, Backup Log, ALL. Командные разрешения могут представляться системным администратором или владельцем базы данных. Разрешение на создание временных таблиц не требуется. Наиболее простой путь – предоставление или запрещение действий группам пользователей. Рекомендуется следующая последовательность при предоставлении разрешений: предоставьте соответствующие разрешения группе public, предоставьте соответствующие разрешения другим группам, которые находятся в иерархии ниже системной группы public, предоставьте соответствующие разрешения отдельным пользователям. Предоставление прав осуществляется с помощью команды:

Grant ‘список_прав доступа’ |All

ON [‘таблица’| ‘вид’ [(‘столбец’, …)] | ‘хранимая процедура ’]

TO список_имен ролей или учетных записей | PUBLIC

Удаление прав осуществляется с помощью команды:

REVOKE список_прав_доступа

ON имя_объекта

TO список_имен

Здесь Список_прав_доступа – права через запятую или ALL.

Имя_объекта – таблица, вид или хранимая процедура, к которой предоставляется или уничтожается.

Запрещение доступа к объектам:

DENY { ALL | ‘список разрешений’} TO ‘учетная запись’

Ограничения на использование разрешений:

- только собственник объекта имеет по умолчанию к нему доступ,

- предоставляя разрешения можно указать столбцы,

- запрет доступа пользователю, группе или роли имеет приоритет над любым разрешением,

- владелец базы данных не может управлять разрешениями в других базах данных, если он не использует команду SETUSER,

- имена пользователей, имена ролей, паролей должны иметь размер от 1 до 128 символов не должны содержать обратных слэшей,

- имена пользователей, паролей, ролей не должны совпадать с ключевыми словами и встроенными именами пользователей SQL Server.

Дата добавления: 2014-10-15