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

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

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

• Разрешения, относящиеся к конкретным защищаемым объектам

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

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

• Примеры

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

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

• CONTROL

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

• ALTER

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

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

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

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

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

• TAKE OWNERSHIP

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

• IMPERSONATE <Login>

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

• IMPERSONATE <User>

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

• CREATE <Server Securable>

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

• CREATE <Database Securable>

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

• Create <Schema-contained Securable>

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

• VIEW DEFINITION

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

• REFERENCES

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

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

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

Схему плакатного размера всех разрешений компонента Компонент Database Engine в формате PDF см. по ссылке https://github.com/microsoft/sql-server-samples/blob/master/samples/features/security/permissions-posters/Microsoft_SQL_Server_2017_and_Azure_SQL_Database_permissions_infographic.pdf.

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

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

SQL Server и разрешения базы данных SQL

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

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

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

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

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

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

Примеры

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

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

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

SELECT * FROM fn_builtin_permissions(default);  
GO  

Б. Получение разрешений на определенный класс объектов

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

SELECT * FROM fn_builtin_permissions('assembly');  
GO    

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

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

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

Г. Получение разрешений, применимых к конкретному объекту

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

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

См. также:

Иерархия разрешений (компонент Database Engine)
sys.database_permissions (Transact-SQL)