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

GRANT ALTER ANY DATABASE TO BorisBorisov WITH GRANT OPTION

Теперь рассмотрим пример вызова команды DENY. Запретим учетной записи PetrSergeev устанавливать соединение с сервером:

DENY CONNECT SQL TO PetrSergeev

В команде DENY часто используется опция CASCADE – для каскадирования запрещения. О каскадировании уже говорилось в начале параграфа 6.1. Рассмотрим конкретный пример. Некоей учетной записи ViktorKorolev было дано разрешение ALTER ANY CREDENTIAL с опцией WITH GRANT. Конечный пользователь успел передать данное разрешение от имени ViktorKorolev учетным записям Login1, …, LoginN. В результате выполнения следующей команды ViktorKorolev получит явное запрещение на управление объектами Credential, и это запрещение каскадно распространится на учетные записи Login1, …, LoginN:

DENY ALTER ANY CREDENTIAL To ViktorKorolev CASCADE

Команда REVOKE снимает выданные разрешения и запрещения. Чтобы снять разрешение ALTER ANY DATABASE с учетной записи IvanIvanov, необходимо записать и выполнить команду в следующем виде:

REVOKE ALTER ANY DATABASE FROM IvanIvanov

Если же требуется каскадное снятие разрешения (процесс, аналогичный каскадированию запрещения, с той разницей, что в данном случае просто аннулируется выполнение предшествовавшей команды GRANT, доступ явно не запрещается), то в вызове команды используются сразу две дополнительные конструкции: GRANT OPTION FOR (сразу после ключевого слова REVOKE) и CASCADE (в конце вызова). В следующем примере снимается ранее предоставленное разрешение ALTER ANY DATABASE с учетной записи BorisBorisov, а также – каскадно – с других учетных записей, которым BorisBorisov передавал данное разрешение:

REVOKE GRANT OPTION FOR ALTER ANY DATABASE FROM BorisBorisov CASCADE

6.1.2.3. Пользователи и роли баз данных

Для любой БД в SQL Server существует определенный набор пользователей. Каждый пользователь связывается с одной из имеющихся учетных записей и наделяется правами доступа к объектам БД. Во многих случаях целой группе пользователей предоставляются одинаковые права. При этом в качестве механизма группирования используются роли БД, которые классифицируются следующим образом:

·  фиксированные роли БД;

·  пользовательские роли БД;

·  роли приложений.

Фиксированные роли БД стандартны, не могут быть удалены или добавлены, невозможно повлиять на права доступа фиксированных ролей к объектам БД.

В табл. 6.2 приведены имена фиксированных ролей БД и их краткие описания.

Таблица 6.2 – Фиксированные роли БД

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

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

Роли приложения были унаследованы из предшествующих версий SQL Server. Идея их использования состоит в следующем. Предположим, имеется некое программное приложение на клиентской рабочей станции, которое взаимодействует с БД под управлением SQL Server. В принципе, оно может взаимодействовать с БД от имени определенного пользователя, с его правами доступа. Однако имеется и другая возможность: клиентская программа во время установки соединения с БД проходит идентификацию под именем некоего пользователя, но для выполнения конкретных действий в БД пользуется разрешениями не этого пользователя, а специальной роли – роли приложения.