DDL_admin против разрешений db_owner

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

Одним из разрешений, которые в настоящее время ограничены, являются разрешения db_owner
Это разрешение пересматривается в каждом конкретном случае, но общим изменением является замена разрешений db_owner следующим:

• db_datareader
• db_datawriter
• db_ddladmin
• db_executor

Я хотел бы определить точную разницу между ними (для информирования клиентов).
Однако, насколько я могу судить, разница между ними должна быть:

• разрешения 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 четырьмя ролями выше?
На самом ли деле это служит целям безопасности?

db_ddladmin vs db_owner

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

Запрещено только с DDLADMIN:

[ALTER ANY USER]

[BACKUP DATABASE], [BACKUP LOG],[CHECKPOINT]

[ALTER ANY APPLICATION ROLE], [ALTER ANY ROLE]

[DROP DATABASE]

Отмечая, что. , ,

1. db_datareaderразрешит SELECTдоступ ко всем таблицам
2. db_datarwriterпозволит INSERT, UPDATEи DELETEдоступ ко всем таблицам
3. db_executorразрешит EXECUTEдоступ ко всем исполняемым объектам

Кроме того, могут иметься разрешения на роль db_ddladmin. , ,

Примечание. Поскольку у вас так много разных версий SQL Server с 2005 по 2014 год, может быть лучше, чтобы небольшой набор пользователей сначала проверил это, чтобы увидеть, кто кричит, чтобы сгладить любые изгибы и т. Д.

• Объекты, которыми они владеют с этой ролью, не будут принадлежать DBO, поэтому вам, возможно, придется иметь дело с проблемами изменения владельца, если когда-нибудь возникнут проблемы с чем-либо на этом уровне. Я не уверен на 100%, что это будет проблемой, но стоит упомянуть на всякий случай.

  Источник: Цепочки собственности

• С этой ролью (может варьироваться в зависимости от версии SQL Server) они могут добавлять принципы безопасности SQL, определенные в текущей БД, к принадлежащим им объектам, но не ко всем объектам (принадлежащим им). а также добавлять новый сервер -уровень, определенный принципалом к ​​уровню БД.

Кроме того, может не иметь разрешения роли DBO. , ,

Примечание. Поскольку у вас так много разных версий SQL Server с 2005 по 2014 год, может быть лучше, чтобы небольшой набор пользователей сначала проверил это, чтобы увидеть, кто кричит, чтобы сгладить любые изгибы и т. Д.

• Отсутствие роли DBO может помешать некоторым интерфейсам графического интерфейса конструктора SSMS (в зависимости от версии SQL Server) заполняться или открываться без ошибок (например, при изменении таблиц или столбцов через графический интерфейс) даже если это выполняется с помощью T-SQL, и разрешения имеются. , В некоторых версиях SQL Server это может быть решено путем разрешения GRANT VIEW DEFINITIONпроблемы, а также может быть предупреждением только в определенных версиях SQL Server.

  Ресурсы

  • Вы не вошли как владелец базы данных или как пользователь, который является членом роли db_owner. Вы не сможете сохранить изменения в таблицах, которые вам не принадлежат.

  • db_ddladmin Роль не позволяет использовать функции "дизайн" в SSMS

    _{«Мы стараемся не давать пользователям / разработчикам dbo в своих базах данных QA столько, сколько мы можем. Одна из проблем в этом заключается в том, что им все еще нужно иметь возможность создавать и изменять объекты базы данных, такие как пользовательские таблицы. Многие разработчики являются новыми для MS SQL и, следовательно, склонны придерживаться GUI (SSMS) для такого рода работы. Проблема возникает, когда мы даем им db_ddladmin (не dbo), и они больше не могут изменять таблицы или столбцы через графический интерфейс конструктора таблиц. им нужно дополнительное время, чтобы изучить команды TSQL и их синтаксис (который им больше никогда не понадобится) или привлечь команду DBA, которая отнимает время у других наших действий.}

    _{Я не знаю, является ли это ошибкой или запросом функции, но я считаю это ошибкой, поскольку у пользователя есть достаточные права для изменения таблицы с помощью TSQL, но графический интерфейс выдает им сообщения о том, что:}

    _{« Вы не вошли в систему как владелец базы данных или системный администратор. Возможно, вы не сможете сохранить изменения в таблицах, которые вам не принадлежат». И «Таблица [schema].[table]настроена только для чтения, у пользователя недостаточно прав на эту таблицу ».}

    _{Похоже, трассировка указывает на то, что проверка является is_member ('db_owner'), который исключает членов db_ddladmin, даже если у них действительно есть разрешения на изменение объекта. Microsoft SQL Server Management Studio "}

    ---

    _{Написал агент DBA 25.01.2010 в 7:06}

    _{У меня была похожая проблема, и мне удалось решить ее, выполнив следующий грант}

    GRANT view definition on schema:: <schemaname> to <username>

Другие соображения

Поскольку вы заявляете, что это рассматривается в каждом конкретном случае

Одним из разрешений, которые в настоящее время ограничены, являются разрешения db_owner.

Это разрешение пересматривается в каждом конкретном случае, но общим изменением является замена разрешений db_owner следующим:

• db_datareader
• db_datawriter
• db_ddladmin
• db_executor

Рассматривали ли вы создание дополнительных пользовательских ролей для более широкого доступа на уровне базы данных «все объекты», в котором нуждается каждый человек, вместо предоставления им db_ddladmin роль, поскольку это, вероятно, даст им больше, чем им фактически нужно для объектов уровня БД.

Я обычно даю то, что нужно точно, и больше ничего для них, чтобы выполнить свою работу, и, если есть «обычная» или «стандартная» потребность в доступе объекта уровня БД ко всем объектам в БД, я создаю собственную роль БД, подобную db_executorно посмотрите мой пример ниже. Таким образом, вы можете предоставить людям то, что им действительно нужно, для ВСЕХ объектов БД в конкретной БД, если вы не получаете явного уровня объекта в ваших БД для обеспечения их безопасности.

----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

Я также хотел поделиться ролью db_DDLAdmin_Restriction, которую вы, возможно, захотите рассмотреть, чтобы создать иначе с явным DENYограничением db_ddladminдоступа, чтобы вы могли по крайней мере создать это в тех БД, где вы предоставили им эту роль, и установить явное DENYдля реальных типов объектов. и т. д. вы не хотите, чтобы они имели доступ к.

Например, если вы знаете , что они, безусловно , будет создавать хранимые процедуры и функции, вы можете исключить DENY CREATE FUNCTION, DENY CREATE PROCEDURE, DENY ALTER ANY SCHEMA.

---Create ddladmin restriction custom DB role
DENY ALTER ANY ASSEMBLY                    TO db_DDLAdmin_Restriction
DENY ALTER ANY ASYMMETRIC KEY              TO db_DDLAdmin_Restriction
DENY ALTER ANY CERTIFICATE                 TO db_DDLAdmin_Restriction
DENY ALTER ANY CONTRACT                    TO db_DDLAdmin_Restriction
DENY ALTER ANY DATABASE DDL TRIGGER        TO db_DDLAdmin_Restriction
DENY ALTER ANY DATABASE EVENT NOTIFICATION TO db_DDLAdmin_Restriction
DENY ALTER ANY DATASPACE                   TO db_DDLAdmin_Restriction
DENY ALTER ANY FULLTEXT CATALOG            TO db_DDLAdmin_Restriction
DENY ALTER ANY MESSAGE TYPE                TO db_DDLAdmin_Restriction
DENY ALTER ANY REMOTE SERVICE BINDING      TO db_DDLAdmin_Restriction
DENY ALTER ANY ROUTE                       TO db_DDLAdmin_Restriction
DENY ALTER ANY SCHEMA                      TO db_DDLAdmin_Restriction
DENY ALTER ANY SERVICE                     TO db_DDLAdmin_Restriction
DENY ALTER ANY SYMMETRIC KEY               TO db_DDLAdmin_Restriction
DENY CHECKPOINT                            TO db_DDLAdmin_Restriction
DENY CREATE AGGREGATE                      TO db_DDLAdmin_Restriction
DENY CREATE DEFAULT                        TO db_DDLAdmin_Restriction
DENY CREATE FUNCTION                       TO db_DDLAdmin_Restriction
DENY CREATE PROCEDURE                      TO db_DDLAdmin_Restriction
DENY CREATE QUEUE                          TO db_DDLAdmin_Restriction
DENY CREATE RULE                           TO db_DDLAdmin_Restriction
DENY CREATE SYNONYM                        TO db_DDLAdmin_Restriction
DENY CREATE TABLE                          TO db_DDLAdmin_Restriction
DENY CREATE TYPE                           TO db_DDLAdmin_Restriction
DENY CREATE VIEW                           TO db_DDLAdmin_Restriction
DENY CREATE XML SCHEMA COLLECTION          TO db_DDLAdmin_Restriction
DENY REFERENCES                            TO db_DDLAdmin_Restriction
GO

Используя SQL Script для перечисления всех разрешений, я пошел и создал пользователей для каждого случая.

EXECUTE AS USER = 'test_user'
SELECT 
    permission_name 
FROM fn_my_permissions(null, 'DATABASE')
ORDER BY subentity_name, permission_name
REVERT;

Затем я сравнил результаты и пришел к следующему списку с документацией в основном из msdn (любые кавычки, на которые нет конкретных ссылок, относятся к ссылке msdn).
Ниже приведена часть документации, которую я использовал для информирования людей, которые будут терять разрешения dbo, что именно они теряли.

ALTER

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

ИЗМЕНИТЬ ЛЮБУЮ РОЛЬ ПРИЛОЖЕНИЯ
ИЗМЕНИТЬ ЛЮБУЮ АУДИТ БАЗЫ ДАННЫХ
ИЗМЕНИТЬ ЛЮБУЮ РОЛЬ
ИЗМЕНИТЬ ЛЮБОГО ПОЛЬЗОВАТЕЛЯ

Предоставляет возможность CREATE, ALTER или DROP отдельных экземпляров базы данных Securable. Например, ALTER ANY SCHEMA предоставляет возможность создавать, изменять или удалять любую схему в базе данных.

Роли приложения - это субъекты базы данных, которые позволяют приложению запускаться с собственными пользовательскими разрешениями.

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

Роли базы данных используются для простого управления разрешениями в ваших базах данных. SQL Server предоставляет несколько ролей, которые являются участниками безопасности, объединяющими других участников. Они похожи на группы в операционной системе Microsoft Windows. Роли уровня базы данных являются общими для всей базы данных в их области полномочий.

AUTHENTICATE
Найдено в MSDN.

Разрешения AUTHENTICATE & AUTHENTICATE SERVER используются только при использовании EXECUTE AS в сценариях кросс-базы данных и доступа к серверу (соответственно).

BACKUP DATABASE
BACKUP LOG

ПОДКЛЮЧИТЬ РЕПЛИКАЦИЮ

Используется для разрешения репликации базы данных .

КОНТРОЛЬ

Предоставляет правообладателю возможности, подобные владению. Получатель фактически имеет все определенные разрешения на защищаемый объект. Принципал, которому был предоставлен КОНТРОЛЬ, может также предоставлять разрешения на защищаемый объект.

СОЗДАТЬ РОЛЬ

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

SHOWPLAN

Разрешения Showplan используются для различных параметров оператора Showplan SET, когда они используются с пакетами Transact-SQL .

ПОДПИШИТЕСЬ НА ЗАПРОСЫ УВЕДОМЛЕНИЙ

Документация о запросе уведомлений.

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

ВЗЯТЬ НА СЕБЯ ОТВЕТСТВЕННОСТЬ

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

ПОСМОТРЕТЬ БАЗУ ДАННЫХ

Используется для просмотра представлений и функций динамического управления (Transact-SQL) .

ПОСМОТРЕТЬ ОПРЕДЕЛЕНИЕ

Документация о разрешениях на просмотр.

Разрешение VIEW DEFINITION позволяет пользователю просматривать метаданные защищаемого объекта, для которого предоставлено разрешение. Однако разрешение VIEW DEFINITION не предоставляет доступ к самому защищаемому объекту. Например, пользователь, которому предоставлено только разрешение VIEW DEFINITION для таблицы, может видеть метаданные, связанные с таблицей, в представлении каталога sys.objects. Однако без дополнительных разрешений, таких как SELECT или CONTROL, пользователь не может читать данные из таблицы.