Разрешения (ядро СУБД)

Применимо: SQL Server База данных SQL Azure Управляемый экземпляр SQL Azure azure Synapse Analytics Analytics Platform System (PDW)

Каждая защищаемая среда SQL Server имеет связанные разрешения, которые можно предоставить субъекту. Разрешения в ядро СУБД управляются на уровне сервера, назначенном ролям входа и серверам, а также на уровне базы данных, назначенной пользователям базы данных и ролям базы данных. Модель для База данных SQL Azure имеет ту же систему для разрешений базы данных, но разрешения на уровне сервера недоступны. В этой статье содержится полный список разрешений. Советы по проектированию системы разрешений см. в статье Начало работы с разрешениями ядра СУБД.

Общее количество разрешений для SQL Server 2022 (16.x) — 292. База данных SQL Azure предоставляет 292 разрешения. Большинство разрешений применяются ко всем платформам, но некоторые не применяются. Например, большинство разрешений на уровне сервера не могут быть предоставлены в База данных SQL Azure, а для База данных SQL Azure имеет смысл только несколько разрешений. Новые разрешения вводятся постепенно с новыми выпусками. SQL Server 2019 (15.x) предоставляет 248 разрешений. SQL Server 2017 (14.x) предоставил 238 разрешений. SQL Server 2016 (13.x) предоставляет 230 разрешений. SQL Server 2014 (12.x) предоставил 219 разрешений. SQL Server 2012 (11.x) предоставляет 214 разрешений. SQL Server 2008 R2 (10.50.x) предоставляет разрешения 195. В статье sys.fn_builtin_permissions указывается, какие разрешения являются новыми в последних версиях.

После понимания необходимых разрешений можно применить разрешения на уровне сервера для входа или ролей сервера, а также разрешения на уровне базы данных для пользователей или ролей базы данных с помощью инструкций GRANT, REVOKE и DENY. Например:

GRANT SELECT ON SCHEMA::HumanResources TO role_HumanResourcesDept;
REVOKE SELECT ON SCHEMA::HumanResources TO role_HumanResourcesDept;

Советы по проектированию системы разрешений см. в разделе Приступая к работе с разрешениями Database Engine.

Соглашения об именовании разрешений

Ниже описаны общие соглашения, которые соблюдаются при задании имен разрешениям.

• ПРОИЗВОДИТЕЛЬНОСТИ

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

• ИЗМЕНИТЬ

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

• ALTER ANY <Server Securable, где защищаемый> сервер может быть любым защищаемым сервером.

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

• ALTER ANY <Database Securable, где защищаемая> база данных может быть любой защищаемой на уровне базы данных.

  Предоставляет возможность СОЗДАВАТЬ, ИЗМЕНЯТЬ и УДАЛЯТЬ отдельные экземпляры Защищаемой сущности базы данных. Например, разрешение ALTER ANY SCHEMA предоставляет возможность создания, изменения и удаления любой схемы в базе данных.

• TAKE OWNERSHIP

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

• IMPERSONATE <Имя_для_входа>

  Позволяет олицетворять имя входа.

• IMPERSONATE <Пользователь>

  Позволяет олицетворять пользователя.

• CREATE <Защищаемый объект сервера>

  Предоставляет возможность создавать Защищаемую сущность сервера.

• CREATE <Защищаемый объект базы данных>

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

• CREATE <Защищаемый объект, содержащийся в схеме>

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

• VIEW DEFINITION

  Разрешает доступ к метаданным.

• ССЫЛКИ

  Разрешение REFERENCES для таблицы необходимо для создания ограничения FOREIGN KEY, которое ссылается на эту таблицу.

  Разрешение REFERENCES для объекта необходимо для создания FUNCTION или VIEW с предложением 2 WITH SCHEMABINDING , которое ссылается на этот объект.

Диаграмма разрешений SQL Server

На следующем рисунке показаны разрешения и их связи друг с другом. Некоторые из разрешений более высокого уровня (например, CONTROL SERVER) указаны несколько раз. Рисунок в этой статье слишком мал для чтения. Вы можете скачать полноразмерный ядро СУБД плакат разрешений в формате PDF.

Разрешения, применимые к определенным защищаемым компонентам

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

Разрешения SQL Server

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

Новые детализированные разрешения, добавленные в SQL Server 2022

В SQL Server 2022 добавляются следующие разрешения:

• Добавлены 10 новых разрешений, чтобы разрешить доступ к системным метаданным.

• Добавлены 18 новых разрешений для расширенных событий.

• Добавлены 9 новых разрешений в отношении объектов, связанных с безопасностью.

• Для реестра добавлены 4 разрешения.

• 3 дополнительные разрешения базы данных.

Дополнительные сведения см. в статье "Новые детализированные разрешения для SQL Server 2022 и Azure SQL для улучшения соответствия с помощью PoLP".

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

Уровень сервера:

• ПРОСМОТР ВСЕХ ОПРЕДЕЛЕНИЙ БЕЗОПАСНОСТИ
• ПРОСМОТР ЛЮБОГО ОПРЕДЕЛЕНИЯ ПРОИЗВОДИТЕЛЬНОСТИ
• ПРОСМОТР СОСТОЯНИЯ БЕЗОПАСНОСТИ СЕРВЕРА
• ПРОСМОТР СОСТОЯНИЯ ПРОИЗВОДИТЕЛЬНОСТИ СЕРВЕРА
• ПРОСМОТР ЛЮБОГО КРИПТОГРАФИЧЕСКИ ЗАЩИЩЕННОГО ОПРЕДЕЛЕНИЯ

Уровень базы данных:

• ПРОСМОТР СОСТОЯНИЯ БЕЗОПАСНОСТИ БАЗЫ ДАННЫХ
• ПРОСМОТР СОСТОЯНИЯ ПРОИЗВОДИТЕЛЬНОСТИ БАЗЫ ДАННЫХ
• ПРОСМОТР ОПРЕДЕЛЕНИЯ БЕЗОПАСНОСТИ
• ПРОСМОТР ОПРЕДЕЛЕНИЯ ПРОИЗВОДИТЕЛЬНОСТИ
• ПРОСМОТР КРИПТОГРАФИЧЕСКИ ЗАЩИЩЕННОГО ОПРЕДЕЛЕНИЯ

Разрешения расширенных событий

Уровень сервера:

• СОЗДАНИЕ ЛЮБОГО СЕАНСА СОБЫТИЙ
• УДАЛЕНИЕ ЛЮБОГО СЕАНСА СОБЫТИЙ
• ALTER ANY EVENT SESSION OPTION
• ALTER ANY EVENT SESSION ADD EVENT
• ALTER ANY EVENT SESSION DROP EVENT
• ALTER ANY EVENT SESSION ENABLE
• ALTER ANY EVENT SESSION DISABLE
• ALTER ANY EVENT SESSION ADD TARGET
• ALTER ANY EVENT SESSION DROP TARGET

Все эти разрешения находятся под одинаковым родительским разрешением: ALTER ANY EVENT SESSION

Уровень базы данных:

• СОЗДАНИЕ СЕАНСА СОБЫТИЙ БАЗЫ ДАННЫХ
• УДАЛЕНИЕ СЕАНСА СОБЫТИЙ БАЗЫ ДАННЫХ
• ALTER ANY DATABASE EVENT SESSION OPTION
• ALTER ANY DATABASE EVENT SESSION ADD EVENT
• ALTER ANY DATABASE EVENT SESSION DROP EVENT
• ALTER ANY DATABASE EVENT SESSION ENABLE
• ALTER ANY DATABASE EVENT SESSION DISABLE
• ALTER ANY DATABASE EVENT SESSION ADD TARGET
• ALTER ANY DATABASE EVENT SESSION DROP TARGET

Все эти разрешения находятся под одинаковым родительским разрешением: ALTER ANY DATABASE EVENT SESSION

Разрешения объекта, связанные с безопасностью

• CONTROL (CREDENTIAL)
• CREATE LOGIN
• СОЗДАНИЕ ПОЛЬЗОВАТЕЛЯ
• ССЫЛКИ (УЧЕТНЫЕ ДАННЫЕ)
• UNMASK (OBJECT)
• UNMASK (SCHEMA)
• ПРОСМОТР ЛЮБОГО ЖУРНАЛА ОШИБОК
• ПРОСМОТР АУДИТА БЕЗОПАСНОСТИ СЕРВЕРА
• ПРОСМОТР АУДИТА БЕЗОПАСНОСТИ БАЗЫ ДАННЫХ

Разрешения реестра

• ALTER LEDGER
• ALTER LEDGER CONFIGURATION
• ENABLE LEDGER
• VIEW LEDGER CONTENT

Другие разрешения базы данных

• ALTER ANY EXTERNAL JOB
• ALTER ANY EXTERNAL STREAM
• ВЫПОЛНЕНИЕ ЛЮБОЙ ВНЕШНЕЙ КОНЕЧНОЙ ТОЧКИ

Сводка алгоритма проверки разрешений

Проверка разрешений может оказаться сложной задачей. Алгоритм проверки разрешений учитывает перекрывающееся членство в группах и цепочки владения, явные и неявные разрешения. На его работу могут влиять разрешения на защищаемые классы, содержащие защищаемые сущности. Общая процедура алгоритма состоит в сборе всех применимых разрешений. Если не обнаружена блокирующая инструкция DENY, алгоритм выполняет поиск инструкции GRANT, которая предоставляет достаточные права доступа. Алгоритм содержит три необходимых элемента: контекст безопасности, область разрешенияи требуемое разрешение.

• Контекст безопасности

  Это группа участников, разрешения которых используются в проверке доступа. Сюда входят разрешения, связанные с текущим именем входа или пользователем, если контекст безопасности не изменился на другое имя входа или другого пользователя с помощью инструкции EXECUTE AS. В контекст безопасности входят следующие участники.

  • Имя входа.

  • Пользователь

  • Членство в ролях.

  • Членство в группах Windows.

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

• Область разрешения

  Это защищаемая сущность и все защищаемые классы, содержащие защищаемый объект. Например, таблица (защищаемая сущность) содержится в защищаемом классе схемы и в защищаемом классе базы данных. На доступ могут влиять разрешения на уровне таблицы, схемы, базы данных и сервера. Дополнительные сведения см. в разделе "Иерархия разрешений" (ядро СУБД).

• Требуемое разрешение

  Тип требуемого разрешения. Например, INSERT, UPDATE, DELETE, SELECT, EXECUTE, ALTER, CONTROL и т. д.

  Для доступа может требоваться несколько разрешений, как в следующих примерах.

  • Хранимой процедуре может быть необходимо разрешение EXECUTE на хранимую процедуру и разрешение INSERT на несколько таблиц, на которые ссылается хранимая процедура.

  • Для динамического административного представления могут быть одновременно необходимы разрешения VIEW SERVER STATE и SELECT на представление.

Общие шаги алгоритма

Когда алгоритм определяет, следует ли предоставлять доступ к защищаемому объекту, конкретные используемые шаги могут различаться в зависимости от того, какие участники и защищаемые объекты вовлечены в процесс. Однако в любом случае алгоритм выполняет следующие общие шаги.

1. Пропустить проверку разрешений, если имя входа является членом предопределенной роли сервера sysadmin или если пользователь является пользователем dbo в текущей базе данных.

2. Разрешить доступ, если применима цепочка владения и проверка доступа к объекту, расположенному ранее в цепочке, завершилась успешно.

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

4. Собрать для полученного контекста безопасностивсе разрешения, которые предоставлены или запрещены в области разрешения. Разрешение может задаваться в явном виде в составе инструкций GRANT, GRANT WITH GRANT или DENY (либо быть неявным или покрывающим разрешением GRANT или DENY). Например, из разрешения CONTROL на схему следует разрешение CONTROL на таблицу, а из разрешения CONTROL на таблицу следует разрешение SELECT. Таким образом, если предоставлено разрешение CONTROL на схему, то неявно предоставляется разрешение SELECT на таблицу. Если разрешение CONTROL на таблицу запрещается, то неявно запрещается разрешение SELECT на таблицу.

   Примечание.

   Инструкция GRANT для разрешения на уровне столбцов имеет приоритет над инструкцией DENY на уровне объектов. Дополнительные сведения см. здесь: DENY Object Permissions (Transact-SQL).

5. Определить требуемое разрешение.

6. Завершить проверку разрешений с отрицательным результатом, если требуемое разрешение явно или неявно запрещено в любом из удостоверений из контекста безопасности для объектов в области разрешения.

7. Передайте проверку разрешения, если требуемое разрешение не было отклонено, а требуемое разрешение содержит разрешение GRANT или GRANT WITH GRANT либо непосредственно, либо неявно любому из удостоверений в контексте безопасности для любого объекта в пространстве разрешений.

Особые замечания относительно разрешений на уровне столбца

Разрешения на уровне столбцов предоставляются с помощью синтаксиса table_name(столбец _name>).<>< Например:

GRANT SELECT ON OBJECT::Customer(CustomerName) TO UserJoe;

Разрешение GRANT на столбец переопределяет разрешение DENY на таблицу. При этом последующее разрешение DENY на таблицу удалит разрешение GRANT на столбец.

Примеры

В примерах этого раздела показано, как получить сведения о разрешениях.

А. Возвращает полный список предоставленных разрешений

Следующая инструкция возвращает все разрешения ядро СУБД с помощью fn_builtin_permissions функции. Дополнительные сведения см. в разделе sys.fn_builtin_permissions (Transact-SQL).

SELECT * FROM fn_builtin_permissions(default);
GO

B. Возврат разрешений для определенного класса объектов

В следующем примере функция fn_builtin_permissions используется для просмотра всех разрешений, доступных для категории защищаемых объектов. В примере возвращаются разрешения на сборки.

SELECT * FROM fn_builtin_permissions('assembly');
GO

C. Возврат разрешений, предоставленных выполняющей субъекту объекта

В следующем примере функция fn_my_permissions возвращает список действующих разрешений вызывающего участника в отношении указанного защищаемого объекта. В примере возвращаются разрешения на объект с именем Orders55. Дополнительные сведения см. в разделе sys.fn_my_permissions (Transact-SQL).

SELECT * FROM fn_my_permissions('Orders55', 'object');
GO

D. Возврат разрешений, применимых к указанному объекту

В следующем примере возвращаются применимые разрешения на объект с именем Yttrium. Встроенная функция OBJECT_ID используется для получения идентификатора объекта Yttrium.

SELECT * FROM sys.database_permissions
    WHERE major_id = OBJECT_ID('Yttrium');
GO

Связанный контент

• Иерархия разрешений (ядро СУБД)
• sys.database_permissions (Transact-SQL)