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

Применимо к:SQL ServerБаза данных Azure SQLУправляемый экземпляр Azure SQLAzure Synapse AnalyticsСистема платформы аналитики (PDW)Конечная точка SQL аналитики в Microsoft FabricХранилище в Microsoft FabricБаза данных SQL в Microsoft Fabric

Каждый защищаемый объект 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 указывается, какие разрешения являются новыми в последних версиях.

В базе данных SQL в Microsoft Fabric поддерживаются только пользователи и роли уровня базы данных. На уровне сервера имена входа, роли и учетная запись sa недоступны. В базе данных SQL в Microsoft Fabric идентификатор Microsoft Entra для пользователей базы данных является единственным поддерживаемым методом проверки подлинности. Дополнительные сведения см. в разделе "Авторизация в базе данных SQL" в Microsoft Fabric.

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

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

Советы по планированию системы разрешений см. в статье "Начало работы с разрешениями ядра СУБД".

Правила именования разрешений

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

• CONTROL

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

• ALTER

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

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

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

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

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

• ВОЗЬМИТЕ ОТВЕТСТВЕННОСТЬ

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

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

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

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

  Позволяет получателю выдавать себя за пользователя.

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

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

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

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

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

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

• VIEW ОПРЕДЕЛЕНИЕ

  Предоставляет получателю прав доступ к метаданным.

• REFERENCES

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

  Для объекта требуется разрешение REFERENCES, чтобы создать FUNCTION или VIEW с предложением WITH SCHEMABINDING, ссылающимся на этот объект.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• СОЗДАЙТЕ ЛЮБОЙ EVENT SESSION
• Перетащите любой EVENT SESSION
• Изменение любого параметра EVENT SESSION
• ALTER ANY EVENT SESSION ADD EVENT
• ALTER ANY EVENT SESSION DROP EVENT
• ВКЛЮЧИТЬ ИЗМЕНЕНИЕ ЛЮБОГО EVENT SESSION
• ИЗМЕНЯТЬ ЛЮБОЕ EVENT SESSION ОТКЛЮЧЕНИЕ
• ИЗМЕНИТЬ ЛЮБОЙ EVENT SESSION ДОБАВИТЬ ЦЕЛЬ
• Изменение любой цели удаления EVENT SESSION

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

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

• СОЗДАЙТЕ ЛЮБОЙ DATABASEEVENT SESSION
• СБРОСЬТЕ ЛЮБОЙ DATABASEEVENT SESSION
• ALTER ЛЮБОЙ DATABASEEVENT SESSION ПАРАМЕТР
• ИЗМЕНЕНИЕ ЛЮБОГО DATABASEEVENT SESSION ДОБАВЛЕНИЯ СОБЫТИЙ
• ИЗМЕНЕНИЕ ЛЮБОГО DATABASEEVENT SESSION УДАЛЕНИЯ СОБЫТИЙ
• ALTER ANY DATABASEEVENT SESSION ВКЛЮЧЕНИЕ
• ИЗМЕНЕНИЕ ЛЮБОГО DATABASEEVENT SESSION ОТКЛЮЧЕНИЕ
• ALTER ANY DATABASEEVENT SESSION ADD TARGET
• ИЗМЕНЕНИЕ ЛЮБОЙ DATABASEEVENT SESSION ЦЕЛИ УДАЛЕНИЯ

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

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

• УПРАВЛЕНИЕ (CREDENTIAL)
• CREATE LOGIN
• CREATE USER
• ССЫЛКИ (CREDENTIAL)
• РАЗМАСКИРОВАТЬ (ОБЪЕКТ)
• UNMASK (SCHEMA)
• VIEW ЛЮБОЙ ЖУРНАЛ ОШИБОК
• VIEW АУДИТ БЕЗОПАСНОСТИ СЕРВЕРА
• VIEW DATABASE АУДИТ БЕЗОПАСНОСТИ

Разрешения бухгалтерской книги

• ALTER LEDGER
• Изменить конфигурацию регистра
• ВКЛЮЧЕНИЕ РЕЕСТРА
• VIEW СОДЕРЖИМОЕ РЕЕСТРА

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

• ИЗМЕНЕНИЕ ЛЮБОЙ ВНЕШНЕЙ ЗАДАЧИ
• ИЗМЕНИТЬ ЛЮБОЙ ВНЕШНИЙ ПОТОК
• ВЫПОЛНИТЬ ЛЮБЫЕ ВНЕШНИЕ ENDPOINT

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

Проверка разрешений может оказаться сложной задачей. Алгоритм проверки разрешений учитывает перекрывающееся членство в группах и цепочки владения, явные и неявные разрешения. На его работу могут влиять разрешения на защищаемые классы, содержащие защищаемые сущности. Общая процедура алгоритма состоит в сборе всех применимых разрешений. Если блокировка 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 С GRANT или DENY; либо разрешения могут быть подразумеваемыми или охватывающими: GRANT или DENY. Например, разрешение CONTROL на схему подразумевает разрешение CONTROL на таблицу. Право CONTROL на таблицу подразумевает право SELECT. Таким образом, если на схему предоставлено разрешение CONTROL, то на таблицу предоставляется разрешение SELECT. Если для таблицы было запрещено разрешение CONTROL, то для таблицы запрещается и разрешение SELECT.

   Note

   Разрешение GRANT на уровне столбца переопределяет DENY на уровне объекта. Дополнительные сведения см. в разделе DENY "Разрешения объектов".

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

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

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

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

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

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

DENY, заданный для таблицы, переопределяется GRANT, заданным для столбца. Однако последующее действие DENY в таблице приведёт к удалению столбца GRANT.

Examples

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

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

Следующая инструкция возвращает все разрешения компонента ядро СУБД с помощью функции fn_builtin_permissions. Для получения дополнительной информации см. sys.fn_builtin_permissions.

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.

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)