Содержание
Немного о фиксированных ролях
По материалам статьи Энди Уоррен на SWYNK.COM «SQL Permissions: More about the Fixed Roles»
В предыдущих своих статьях Энди уже рассмотрел применимость ролей Public и DataReader/DataWriter, а также те сложности, которые могут у Вас возникнуть при их применении. В этой статье автор обсуждает фиксированные роли.
Роли баз данных SQL Server 2005, public, db_owner, dbo_accessadmin, dbo_securityadmin , db_backupoperator , db_ddladmin , db_datareader, db_datawriter, db_denydatareader, db_denydatawriter, CREATE ROLE
Обычно после создания логина и пользователя базы данных следующее, что нужно сделать, — предоставить пользователю разрешения в базе данных. Один из способов сделать это — воспользоваться ролями базы данных.
Роли базы данных — это специальные объекты, которые используются для упрощения предоставления разрешений в базах данных. В отличие от серверных ролей, которые могут быть только встроенными, роли баз данных могут быть как встроенными, так и пользовательскими. Встроенные роли баз данных обладают предопределенным набором разрешений, а пользовательские роли можно использовать для группировки пользователей при предоставлении разрешений. Обычно пользовательские роли используются только для логинов SQL Server (хотя им можно назначать любых пользователей баз данных, в том числе созданных на основе логинов Windows ). Для группировки логинов Windows обычно удобнее и проще использовать группы Windows .
Еще одна специальная разновидность ролей баз данных — роли приложений ( application roles ). Речь о них пойдет в разд. 5.4.
Вначале перечислим встроенные роли баз данных, которые "готовы к использованию" для предоставления разрешений:
q public — эта специальная роль предназначена для предоставления разрешений сразу всем пользователям базы данных. Обратите внимание на то, что она выполняет другие функции по сравнению со специальным пользователем g uest . Пользователь g uest используется для предоставления разрешений логинам, для которых не создано пользователей в базе данных, а public — только существующим пользователям.
Специально сделать пользователя членом этой роли или лишить его членства невозможно. Все пользователи базы данных получают права этой роли автоматически. Интересно, что при добавлении пользователя этой роли никакой ошибки не возникнет, но при следующем открытии ее свойств пользователь исчезнет из списка;
q db_owner — этой роли автоматически предоставляются полные права на базу данных. Изначально права этой роли предоставляются только специальному пользователю dbo , а через него — логину, который создал эту базу данных;
q dbo_accessadmin — роль для сотрудника, ответственного за пользователей базы данных. Этот сотрудник получит возможность создавать, изменять и удалять объекты пользователей баз данных, а также создавать схемы. Других прав в базе данных у него нет;
q dbo_securityadmin — эта роль дополняет роль dbo _ accessadmin . Сотрудник с правами этой роли получает возможность назначать разрешения на объекты базы данных и изменять членство во встроенных и пользовательских ролях. Прав на создание и изменение объектов пользователей у этой роли нет;
q db_backupoperator — эта роль дает право, как понятно из ее названия, выполнять резервное копирование базы данных;
q db_ddladmin — эта роль применяется в редких ситуациях, когда пользователю необходимо дать право создавать, изменять и удалять любые объекты в базе данных, не предоставляя прав на информацию, которая содержится в существующих объектах;
q db_datareader и db_datawriter — эти встроенные роли дают право просматривать и изменять соответственно (в том числе добавлять и удалять) любую информацию в базе данных. Очень часто пользователю необходимо дать права на чтение и запись информации во всех таблицах базы данных, не предоставляя ему лишних административных разрешений (на создание и удаление объектов, изменение прав и т. п.). Самый простой вариант в этой ситуации (о котором забывают некоторые администраторы) — воспользоваться этими двумя ролями.
q db_denydatareader и db_denydatawriter — эти роли, как понятно из названий, противоположны ролям db_datareader и db_datawriter . Роль db_denydatareader явно запрещает просматривать какие-либо данные, а db_denydatawriter запрещает внесение изменений. Явный запрет всегда имеет приоритет перед явно предоставленными разрешениями. Обычно эти роли используются в ситуации, когда "разрешаем всем, а потом некоторым запрещаем".
Как уже говорилось ранее, в отличие от серверных ролей роли баз данных вы можете создавать самостоятельно. Это можно сделать из контекстного меню для контейнера Имя_базы_данных | Security | Roles | Database Roles или при помощи команды CREATE ROLE , например:
CREATE ROLE DBRole1 ;
Кроме имени роли, при создании можно также указать ее владельца (если это не указано, владельцем роли автоматически станет создавший ее пользователь базы данных). Если вы создаете роль при помощи графического интерфейса, вы можете сразу назначить роль владельцем схемы в базе данных и назначить пользователей, которые будут обладать правами этой роли.
Встроенным ролям назначены предопределенные права, изменить которые невозможно. Предоставление прав пользовательским ролям производится точно так же, как и обычным пользователям базы данных.
Я беру на себя проект, который включает удаление и ограничение разрешений для всех пользователей базы данных на нашей ферме серверов. (веселое время)
Одно из разрешений, которые в настоящее время ограничены, — разрешения db_owner.
Это разрешение пересматривается в каждом конкретном случае, но общее изменение заключается в замене разрешений db_owner следующим образом:
Я хотел бы определить точную разницу между ними (для информирования клиентов).
Однако, насколько я могу судить, разница между ними должна быть:
- Разрешения db_accessadmin
- Разрешения db_backupoperator
- Разрешения db_securityadmin
Таким образом, они потеряли бы:
[ALTER ANY USER]
[CREATE SCHEMA]
[BACKUP DATABASE] , [BACKUP LOG] , [CHECKPOINT]
[ALTER ANY APPLICATION ROLE] , [ALTER ANY ROLE]
[DROP DATABASE]
Есть ли что-нибудь еще, что пользователь потеряет после того, как db_owner будет заменен четырьмя ролями выше?
Значит ли это на самом деле служит важной цели безопасности?
2 ответа
db_ddladmin vs db_owner
Из того, что я могу сказать по тому, что я тестировал и читал, по большей части ваш список выглядит точным, кроме db_ddladmin вы в CREATE SCHEMA . Я действительно подтвердил, что другие разрешенные вами права доступа действительно лишены.
Отказано только в DDLADMIN:
[BACKUP DATABASE] , [BACKUP LOG] , —- +: = 5 = + —-
[CHECKPOINT] , [ALTER ANY APPLICATION ROLE]
Отмечая, что. , .
1. [DROP DATABASE] позволит db_datareader доступ ко всем таблицам
2. SELECT позволит db_datarwriter , INSERT и UPDATE доступ ко всем таблицам
3. DELETE позволит db_executor доступ ко всем исполняемым объектам
В дополнение, может иметься разрешение на роль db_ddladmin. , .
(Поскольку у вас так много разных версий SQL Server с 2005 по 2014 год, может быть, лучше всего, чтобы небольшой набор пользователей сначала тестировал это, чтобы увидеть, кто кричит, чтобы сгладить любые изломы и т. д.)
Объекты, которыми они владеют с этой ролью, не будут принадлежать DBO, поэтому вам, возможно, придется иметь дело с проблемами chaning, если когда-либо возникнет проблема с чем-то на этом уровне. Я не уверен на 100%, что это будет проблемой, но на всякий случай стоит упомянуть. ( https://msdn.microsoft .com /EN-US /библиотека /ms188676 (v = SQL.100) .aspx )
С этой ролью (может отличаться в зависимости от версии SQL Server) они могут добавить в систему безопасности SQL принципы безопасности, определенные в текущей базе данных, к объектам, которые у них есть, но не все объекты (те, для которых они не принадлежат) и не добавлять на уровне DB нового уровня на уровне уровня сервера.
Кроме того, не могут иметь разрешения на роль DBO. , .
(Поскольку у вас так много разных версий SQL Server с 2005 по 2014 год, может быть, лучше всего, чтобы небольшой набор пользователей сначала тестировал это, чтобы увидеть, кто кричит, чтобы сгладить любые изломы и т. д.)
Отсутствие роли DBO может помешать определенным интерфейсам GUI-дизайнера SSMS (изменение версии SQL Server) от заселения или открытия без ошибки (например, при изменении таблиц или столбцов через графический интерфейс) даже при том, что это делается с помощью T-SQL, и разрешения на месте. В некоторых версиях SQL Server это можно решить, разрешив EXECUTE , где это проблема, и это может быть просто предупреждение только на определенных версии SQL Server.
РЕСУРСЫ:
ДРУГИЕ СООБРАЖЕНИЯ
(Поскольку вы заявляете, что это рассматривается в каждом конкретном случае)
Одно из разрешений, которые в настоящее время ограничены, — разрешения db_owner.
Это разрешение просматривается в каждом конкретном случае, но общее изменение заключается в замене разрешений db_owner следующим образом:
Рассматривали ли вы создание дополнительных пользовательских ролейдля более доступного доступа на уровне «всего объекта», который требуется каждому человеку, а не предоставления им роли GRANT VIEW DEFINITION , поскольку это, вероятно, даст им больше, чем им также необходимы объекты уровня DB.
Я обычно даю то, что нужно точно, и ничего больше для того, чтобы они выполняли свою работу, и если существует обычная или стандартная потребность в доступе к объекту уровня БД всем объектам в БД, я создаю собственную роль роли БД как db_ddladmin , но см. мой пример ниже. Таким образом, вы можете предоставить людям то, что им действительно нужно для ВСЕГО объекта БД в конкретной БД, если вы не получаете явный уровень объектов в своих БД для их безопасности.
Я также хотел бы поделиться ролью db_DDLAdmin_Restriction, которую вы, возможно, захотите рассмотреть, чтобы рассмотреть возможность создания в противном случае с явным —-Custom Database Roles /* CREATE A NEW ROLE — Execute to all stored procs including newly created ones*/ — Database specific CREATE ROLE db_All_StoredProc_Execute GRANT EXECUTE TO db_All_StoredProc_Execute /* CREATE A NEW ROLE — Alter to all stored procs including newly created ones*/ — Database specific CREATE ROLE db_All_StoredProc_Alter GRANT ALTER ANY SCHEMA TO db_All_StoredProc_Alter /* CREATE A NEW ROLE — View Definition to all stored procs including newly created ones*/ — Database specific CREATE ROLE db_All_StoredProc_View GRANT VIEW DEFINITION TO db_All_StoredProc_View /* CREATE A NEW ROLE — Any schema alter and create procedure permissions */ — Database specific CREATE ROLE db_All_CreateProc_AlterSchema GRANT ALTER ANY SCHEMA TO db_All_CreateProc_AlterSchema GRANT CREATE PROCEDURE TO db_All_CreateProc_AlterSchema GO /* CREATE A NEW ROLE — Any schema alter and create table permissions */ — Database specific CREATE ROLE db_All_CreateTable_AlterSchema GRANT ALTER ANY SCHEMA TO db_All_CreateTable_AlterSchema GRANT CREATE TABLE TO db_All_CreateTable_AlterSchema /* CREATE A NEW ROLE — Any schema alter and create function permissions */ — Database specific CREATE ROLE db_All_CreateFunction_AlterSchema GRANT ALTER ANY SCHEMA TO db_All_CreateFunction_AlterSchema GRANT CREATE FUNCTION TO db_All_CreateFunction_AlterSchema /* CREATE A NEW ROLE — Any schema alter and create aggregate permissions */ — Database specific CREATE ROLE db_All_CreateAggregate_AlterSchema GRANT ALTER ANY SCHEMA TO db_All_CreateAggregate_AlterSchema GRANT CREATE AGGREGATE TO db_All_CreateAggregate_AlterSchema /* CREATE A NEW ROLE — Any schema alter and create view permissions */ — Database specific CREATE ROLE db_All_CreateView_AlterSchema GRANT ALTER ANY SCHEMA TO db_All_CreateView_AlterSchema GRANT CREATE VIEW TO db_All_CreateView_AlterSchema /* CREATE A NEW ROLE — Any schema alter and create schema permissions */ — Database specific CREATE ROLE db_All_CreateSchema_AlterSchema GRANT ALTER ANY SCHEMA TO db_All_CreateSchema_AlterSchema GRANT CREATE SCHEMA TO db_All_CreateSchema_AlterSchema , чтобы ограничить, что DENY предоставить доступ, чтобы вы могли, по крайней мере, создать это в БД, где вы предоставите им эту роль, и установите явный код db_ddladmin для фактических типов объектов и т. Д. Вы не хотите, чтобы у них был доступ.
Например, если вы знаете, что они определенно будут создавать хранимые процедуры и функции, вы можете исключить DENY , DENY CREATE FUNCTION , DENY CREATE PROCEDURE .
Используя SQL-скрипт для отображения всех разрешений, я пошел и создал пользователей для каждого случая.
Затем я сравнил результаты и перешел к следующему списку с документацией, в основном с msdn (любые кавычки, которые не указаны конкретно, относятся к ссылке msdn).
Ниже приведена некоторая документация, которую я использовал для информирования людей, которые теряют разрешения dbo , что именно они теряют.
ALTER
Позволяет изменять свойства, кроме права собственности, особый защищаемый. Когда он предоставлен по сфере действия, ALTER также предоставляет способность изменять, создавать или удалять любые защищаемые, которые содержатся в пределах этого объема. Например, разрешение ALTER для схемы включает возможность создавать, изменять и удалять объекты из схемы.
ALTER ANY ARPLINGATION
ALTER ANY DATABASE AUDIT
ALTER ANY ROLE
ALTER ANY ANER
Предоставляет возможность CREATE, ALTER или DROP отдельных экземпляров защищенная база данных. Например, ALTER ANY SCHEMA предоставляет возможность создавать, изменять или удалять любую схему в базе данных.
роли приложения — это принципы баз данных, которые позволяют приложение для запуска со своими собственными пользовательскими разрешениями.
Аудит — экземпляр SQL Server или базы данных SQL Server включает в себя отслеживание и регистрацию событий, которые происходят в системе. Объект проверки уровня базы данных относится к аудиту. Ты можешь создать одну спецификацию аудита базы данных для каждой базы данных SQL Server за аудит.
Роли базы данных используются для простого управления разрешениями в вашем базы данных, SQL Server предоставляет несколько ролей, которые обеспечивают безопасность директоров, которые группируют других директоров. Они похожи на группы в Операционная система Microsoft Windows. Роли на уровне базы данных базы данных в области разрешений.
AUTHENTICATE & Разрешения AUTHENTICATE SERVER используются только тогда, когда используя EXECUTE AS в кросс-базе данных и сервере (соответственно) сценарии.
РЕЗЕРВНАЯ БАЗА ДАННЫХ
BACKUP LOG
ПОДТВЕРЖДЕНИЕ ЗАЯВКИ
CONTROL
Устанавливает права собственности на получателя. Грантополучатель эффективно имеет все определенные разрешения на обеспечение безопасности. Директор который был предоставлен CONTROL, также может предоставлять разрешения на защищаемый.
СОЗДАТЬ РОЛЬ
Предоставляет грантополучателю возможность создания Защищенной базы данных.
SHOWPLAN
ПОДТВЕРЖДЕНИЕ ПОДТВЕРЖДЕНИЙ ЗАПРОСА
Встроенная инфраструктура Service Broker, уведомления о запросах разрешить уведомления приложений при изменении данных. Эта особенность особенно полезен для приложений, которые предоставляют кеш информацию из базы данных, такую как веб-приложение, и должны быть уведомляется при изменении исходных данных.
ВЗЯТЬ СОБСТВЕННОСТЬ
Позволяет получателю право владеть защищаемым, на котором оно само собой разумеющееся.
ПРОСМОТР БАЗЫ БАЗЫ ДАННЫХ