Приступая к работе с разрешениями Database EngineGetting Started with Database Engine Permissions

Применимо к:Applies to: даSQL ServerSQL Server (все поддерживаемые версии) yesSQL ServerSQL Server (all supported versions) ДаБаза данных SQL AzureAzure SQL DatabaseYesБаза данных SQL AzureAzure SQL Database ДаУправляемый экземпляр SQL AzureAzure SQL Managed InstanceYesУправляемый экземпляр SQL AzureAzure SQL Managed Instance даAzure Synapse AnalyticsAzure Synapse AnalyticsyesAzure Synapse AnalyticsAzure Synapse Analytics даПараллельное хранилище данныхParallel Data WarehouseyesПараллельное хранилище данныхParallel Data WarehouseПрименимо к:Applies to: даSQL ServerSQL Server (все поддерживаемые версии) yesSQL ServerSQL Server (all supported versions) ДаБаза данных SQL AzureAzure SQL DatabaseYesБаза данных SQL AzureAzure SQL Database ДаУправляемый экземпляр SQL AzureAzure SQL Managed InstanceYesУправляемый экземпляр SQL AzureAzure SQL Managed Instance даAzure Synapse AnalyticsAzure Synapse AnalyticsyesAzure Synapse AnalyticsAzure Synapse Analytics даПараллельное хранилище данныхParallel Data WarehouseyesПараллельное хранилище данныхParallel Data Warehouse

Управление разрешениями в Компонент Database EngineDatabase Engine осуществляется на уровне сервера с помощью имен входа и ролей сервера и на уровне базы данных с помощью пользователей и ролей базы данных.Permissions in the Компонент Database EngineDatabase Engine are managed at the server level through logins and server roles, and at the database level through database users and database roles. Модель для База данных SQLSQL Database предоставляет ту же систему в каждой базе данных, однако разрешения на уровне сервера недоступны.The model for База данных SQLSQL Database exposes the same system within each database, but the server level permissions are not available. В этом разделе рассматриваются некоторые основные понятия безопасности, а затем описывается типичная реализация разрешений.This topic reviews some basic security concepts and then describes a typical implementation of the permissions.

Субъекты безопасностиSecurity Principals

Субъект безопасности — это официальное название удостоверений, которые используют SQL ServerSQL Server и которым можно назначать разрешения для выполнения действий.Security principal is the official name of the identities that use SQL ServerSQL Server and that can be assigned permission to take actions. Обычно это пользователи или группы пользователей, однако субъектами безопасности могут быть и другие сущности, олицетворяющие пользователей.They are usually people or groups of people, but can be other entities that pretend to be people. Создавать субъекты безопасности и управлять ими можно с помощью списков Transact-SQLTransact-SQL или SQL Server Management StudioSQL Server Management Studio.The security principals can be created and managed using the Transact-SQLTransact-SQL listed, or by using SQL Server Management StudioSQL Server Management Studio.

Имена входаLogins

Имена входа — это учетные записи отдельных пользователей для входа в Компонент SQL Server Database EngineSQL Server Database Engine.Logins are individual user accounts for logging on to the Компонент SQL Server Database EngineSQL Server Database Engine. SQL ServerSQL Server и База данных SQLSQL Database поддерживают имена входа на основе проверки подлинности Windows и на основе проверки подлинности SQL ServerSQL Server .and База данных SQLSQL Database support logins based on Windows authentication and logins based on SQL ServerSQL Server authentication. Дополнительные сведения об этих двух типах имен входа см. в разделе Choose an Authentication Mode.For information about the two types of logins, see Choose an Authentication Mode.

Предопределенные роли сервераFixed Server Roles

В SQL ServerSQL Serverпредопределенные роли сервера — это набор предварительно настроенных ролей, который представляет собой удобную группу разрешений на уровне сервера.In SQL ServerSQL Server, fixed server roles are a set of pre-configured roles that provide convenient group of server-level permissions. Имена входа можно добавить в роли, используя инструкцию ALTER SERVER ROLE ... ADD MEMBER .Logins can be added to the roles using the ALTER SERVER ROLE ... ADD MEMBER statement. Дополнительные сведения см. в разделе ALTER SERVER ROLE (Transact-SQL).For more information, see ALTER SERVER ROLE (Transact-SQL). База данных SQLSQL Database не поддерживает предопределенные роли сервера, однако включает две роли в базе данных master (dbmanager и loginmanager), которые выполняют аналогичные функции.does not support the fixed server roles, but has two roles in the master database (dbmanager and loginmanager) that act like server roles.

Определяемые пользователем роли сервераUser-defined Server Roles

В SQL ServerSQL Serverможно создавать собственные роли сервера и назначать им разрешения на уровне сервера.In SQL ServerSQL Server, you can create your own server roles and assign server-level permissions to them. Имена входа можно добавить в роли сервера, используя инструкцию ALTER SERVER ROLE ... ADD MEMBER .Logins can be added to the server roles using the ALTER SERVER ROLE ... ADD MEMBER statement. Дополнительные сведения см. в разделе ALTER SERVER ROLE (Transact-SQL).For more information, see ALTER SERVER ROLE (Transact-SQL). База данных SQLSQL Database не поддерживает определяемые пользователем роли сервера.does not support the user-defined server roles.

Пользователи базы данныхDatabase Users

Именам входа доступ к базе данных предоставляется путем создания пользователя базы данных в базе данных и сопоставления этого пользователя базы данных с именем входа.Logins are granted access to a database by creating a database user in a database and mapping that database user to login. Как правило, имя пользователя базы данных совпадает с именем входа, хотя это и необязательно.Typically the database user name is the same as the login name, though it does not have to be the same. Один пользователь базы данных сопоставляется с одним именем входа.Each database user maps to a single login. Имя входа может быть сопоставлено только с одним пользователем в базе данных, однако может сопоставляться как пользователь базы данных в нескольких базах данных.A login can be mapped to only one user in a database, but can be mapped as a database user in several different databases.

Кроме того, можно создать пользователей базы данных без соответствующих имен входа.Database users can also be created that do not have a corresponding login. Они называются пользователями автономной базы данных.These are called contained database users. MicrosoftMicrosoft рекомендуют использовать пользователей автономной базы данных, поскольку это упрощает перенос базы данных на другой сервер.encourages the use of contained database users because it makes it easier to move your database to a different server. Как и для имен входа, для пользователей автономной базы данных можно использовать проверку подлинности Windows или проверку подлинности SQL ServerSQL Server .Like a login, a contained database user can use either Windows authentication or SQL ServerSQL Server authentication. Дополнительные сведения см. в разделе Пользователи автономной базы данных — создание переносимой базы данных.For more information, see Contained Database Users - Making Your Database Portable.

Существует 12 типов пользователей с незначительными различиями в способах проверки подлинности и представляемых сущностях.There are 12 types of users with slight differences in how they authenticate, and who they represent. Список пользователей см. в разделе CREATE USER (Transact-SQL).To see a list of users, see CREATE USER (Transact-SQL).

Предопределенные роли базы данныхFixed Database Roles

Предопределенные роли базы данных — это набор предварительно настроенных ролей, который представляет собой удобную группу разрешений на уровне базы данных.Fixed database roles are a set of pre-configured roles that provide convenient group of database-level permissions. Пользователей базы данных и определяемые пользователем роли базы данных можно добавить в предопределенные роли базы данных с помощью инструкции ALTER ROLE ... ADD MEMBER.Database users and user-defined database roles can be added to the fixed database roles using the ALTER ROLE ... ADD MEMBER statement. Дополнительные сведения см. в разделе ALTER ROLE (Transact-SQL).For more information, see ALTER ROLE (Transact-SQL).

Определяемые пользователем роли базы данныхUser-defined Database Roles

Пользователи с разрешением CREATE ROLE могут создавать определяемые пользователем роли базы данных для представления групп пользователей с общими разрешениями.Users with the CREATE ROLE permission can create new user-defined database roles to represent groups of users with common permissions. Обычно разрешения предоставляются или отклоняются для всей роли, что упрощает управление разрешениями и мониторинг.Typically permissions are granted or denied to the entire role, simplifying permissions management and monitoring. Пользователей базы данных можно добавлять в роли базы данных с помощью инструкции ALTER ROLE ... ADD MEMBER .Database users can be added to the database roles by using the ALTER ROLE ... ADD MEMBER statement. Дополнительные сведения см. в разделе ALTER ROLE (Transact-SQL).For more information, see ALTER ROLE (Transact-SQL).

Другие субъектыOther principals

В данной статье не рассматриваются дополнительные субъекты безопасности, такие как роли приложений и имена входа и пользователи, основанные на сертификатах или асимметричных ключах.Additional security principals not discussed here include application roles, and logins and users based on certificates or asymmetric keys.

График, отображающий связи между пользователями Windows, группами Windows, именами входа и пользователями базы данных, см. в разделе Create a Database User.For a graphic showing the relationships between Windows users, Windows groups, logins, and database users, see Create a Database User.

Типичный сценарийTypical Scenario

В следующем примере представлен типичный и рекомендуемый способ настройки разрешений.The following example represents a common and recommended method of configuring permissions.

В Active Directory или Azure Active DirectoryIn Active Directory or Azure Active Directory:

  1. Создайте пользователя Windows для каждого пользователя.Create a Windows user for each person.

  2. Создайте группы Windows, представляющие рабочие единицы и рабочие функции.Create Windows groups that represent the work units and the work functions.

  3. Добавьте пользователей Windows в группы Windows.Add the Windows users to the Windows groups.

Если пользователь будет подключаться к нескольким базам данныхIf the person connecting will be connecting to many databases

  1. Создайте имя входа для групп Windows.Create a login for the Windows groups. (При использовании проверки подлинности SQL ServerSQL Server пропустите шаги, относящиеся к Active Directory, и создайте имена входа для проверки подлинности SQL ServerSQL Server .)(If using SQL ServerSQL Server authentication, skip the Active Directory steps, and create SQL ServerSQL Server authentication logins here.)

  2. В базе данных пользователей создайте пользователя базы данных для имени входа, представляющего группы Windows.In the user database, create a database user for the login representing the Windows groups.

  3. В базе данных пользователей создайте одну или несколько определяемых пользователем ролей базы данных, представляющих аналогичные функции.In the user database, create one or more user-defined database roles, each representing a similar function. Например, финансовый аналитик и аналитик продаж.For example financial analyst, and sales analyst.

  4. Добавьте пользователей базы данных в одну или несколько определяемых пользователем ролей базы данных.Add the database users to one or more user-defined database roles.

  5. Предоставьте разрешения для определяемых пользователем ролей базы данных.Grant permissions to the user-defined database roles.

Если пользователь будет подключаться к только к одной базе данныхIf the person connecting will be connecting to only one database

  1. В базе данных пользователей создайте пользователя автономной базы данных для группы Windows.In the user database, create a contained database user for the Windows group. (При использовании проверки подлинности SQL ServerSQL Server пропустите шаги, относящиеся к Active Directory, и создайте проверку подлинности SQL ServerSQL Server для пользователя автономной базы данных.)(If using SQL ServerSQL Server authentication, skip the Active Directory steps, and create contained database user SQL ServerSQL Server authentication here.

  2. В базе данных пользователей создайте одну или несколько определяемых пользователем ролей базы данных, представляющих аналогичные функции.In the user database, create one or more user-defined database roles, each representing a similar function. Например, финансовый аналитик и аналитик продаж.For example financial analyst, and sales analyst.

  3. Добавьте пользователей базы данных в одну или несколько определяемых пользователем ролей базы данных.Add the database users to one or more user-defined database roles.

  4. Предоставьте разрешения для определяемых пользователем ролей базы данных.Grant permissions to the user-defined database roles.

Как правило, результатом на этом этапе является пользователь Windows, являющийся членом группы Windows.The typical result at this point, is that a Windows user is a member of a Windows group. Группа Windows имеет имя входа в SQL ServerSQL Server или База данных SQLSQL Database.The Windows group has a login in SQL ServerSQL Server or База данных SQLSQL Database. Имя входа сопоставляется с удостоверением пользователя в базе данных пользователей.The login is mapped to a user identity in the user-database. Пользователь является членом роли базы данных.The user is a member of a database role. Теперь необходимо добавить разрешения для роли.Now you need to add permissions to the role.

Назначение разрешенийAssigning Permissions

Большинство инструкций назначения разрешений имеет следующий формат:Most permission statements have the format:

AUTHORIZATION  PERMISSION  ON  SECURABLE::NAME  TO  PRINCIPAL;  
  • AUTHORIZATION должен быть равен GRANT, REVOKE или DENY.AUTHORIZATION must be GRANT, REVOKE or DENY.

  • Предложение PERMISSION определяет, какое действие разрешено или запрещено.The PERMISSION establishes what action is allowed or prohibited. SQL Server 2016 (13.x);SQL Server 2016 (13.x) можно указать 230 разрешений.can specify 230 permissions. База данных SQLSQL Database предусмотрено меньше разрешений, так как некоторые действия не относятся к Azure.has fewer permissions because some actions are not relevant in Azure. Разрешения перечисляются в разделе Разрешения (компонент Database Engine) и на схеме, упоминаемой ниже.The permissions are listed in the topic Permissions (Database Engine) and in the chart referenced below.

  • ON SECURABLE::NAME представляет тип защищаемого объекта (сервер, объект сервера, база данных или объект базы данных) и его имя.ON SECURABLE::NAME is the type of securable (server, server object, database, or database object) and its name. Некоторые разрешения не требуют указания ON SECURABLE::NAME , так как оно может быть однозначным или недопустимым в контексте.Some permissions do not require ON SECURABLE::NAME because it is unambiguous or inappropriate in the context. Например, для разрешения CREATE TABLE не требуется предложение ON SECURABLE::NAME.For example the CREATE TABLE permission doesn't require the ON SECURABLE::NAME clause. (Инструкция GRANT CREATE TABLE TO Mary; позволяет пользователю Mary создавать таблицы.)(For example GRANT CREATE TABLE TO Mary; allows Mary to create tables.)

  • PRINCIPAL представляет субъект безопасности (имя входа, пользователя или роль), который получает или утрачивает разрешение.PRINCIPAL is the security principal (login, user, or role) which receives or loses the permission. Рекомендуется по возможности предоставлять разрешения для ролей.Grant permissions to roles whenever possible.

В следующем примере инструкция grant предоставляет разрешение UPDATE для представления или таблицы Parts , которая содержится в схеме Production , роли с именем PartsTeam:The following example grant statement, grants the UPDATE permission on the Parts table or view which is contained in the Production schema to the role named PartsTeam:

GRANT UPDATE ON OBJECT::Production.Parts TO PartsTeam;  

Разрешения предоставляются субъектам безопасности (именам входа, пользователям и ролям) с помощью инструкции GRANT .Permissions are granted to security principals (logins, users, and roles) by using the GRANT statement. Разрешения явно отклоняются с помощью команды DENY .Permissions are explicitly denied by using the DENY command. Для удаления ранее предоставленного или отклоненного разрешения используется инструкция REVOKE .A previously granted or denied permission is removed by using the REVOKE statement. Разрешения накапливаются, то есть пользователь получает все разрешения, предоставленные пользователю, имени входа и любой группе, членом которой он является. При этом отклонение разрешения отменяет все предоставленные ранее разрешения.Permissions are cumulative, with the user receiving all the permissions granted to the user, login, and any group memberships; however any permission denial overrides all grants.

Совет

Распространенная ошибка — попытка удалить GRANT с помощью команды DENY вместо REVOKE.A common mistake is to attempt to remove a GRANT by using DENY instead of REVOKE. Это может повлечь за собой проблемы, если пользователь получает разрешения из нескольких источников, что довольно распространено.This can cause problems when a user receives permissions from multiple sources; which is quite common. Этот принцип демонстрируется в следующем примере.The following example demonstrates the principal.

Группа Sales получает разрешения SELECT для доступа к таблице OrderStatus посредством инструкции GRANT SELECT ON OBJECT::OrderStatus TO Sales;.The Sales group receives SELECT permissions on the OrderStatus table through the statement GRANT SELECT ON OBJECT::OrderStatus TO Sales;. Пользователь Ted является членом роли Sales.User Ted is a member of the Sales role. Кроме того, ему предоставлено разрешение SELECT для таблицы OrderStatus по его собственному имени пользователя посредством инструкции GRANT SELECT ON OBJECT::OrderStatus TO Ted;.Ted has also been granted SELECT permission to the OrderStatus table under his own user name through the statement GRANT SELECT ON OBJECT::OrderStatus TO Ted;. Предположим, администратор хочет удалить разрешение GRANT для роли Sales.Presume the administer wishes to remove the GRANT to the Sales role.

  • Если администратор правильно выполняет инструкцию REVOKE SELECT ON OBJECT::OrderStatus TO Sales;, то пользователь Ted не утрачивает доступ SELECT к таблице OrderStatus по своей собственной инструкции GRANT .If the administrator correctly executes REVOKE SELECT ON OBJECT::OrderStatus TO Sales;, then Ted will retain SELECT access to the OrderStatus table through his individual GRANT statement.

  • Если администратор неправильно выполняет DENY SELECT ON OBJECT::OrderStatus TO Sales; , то пользователь Ted, как член роли Sales, утрачивает разрешение SELECT , так как команда DENY для роли Sales переопределяет его собственную инструкцию GRANT.If the administrator incorrectly executes DENY SELECT ON OBJECT::OrderStatus TO Sales; then Ted, as a member of the Sales role, will be denied the SELECT permission because the DENY to Sales overrides his individual GRANT.

Примечание

Разрешения можно настроить с помощью Среда Management StudioManagement Studio.Permissions can be configured using Среда Management StudioManagement Studio. В обозревателе объектов найдите защищаемый объект, щелкните его правой кнопкой мыши и выберите пункт Свойства.Find the securable in Object Explorer, right-click the securable, and then click Properties. Перейдите на страницу Разрешения .Select the Permissions page. Справочные сведения о странице разрешений см. в разделе Permissions or Securables Page.For help on using the permission page, see Permissions or Securables Page.

Иерархия разрешенийPermission Hierarchy

К разрешениям применяется иерархия "родители — потомки".Permissions have a parent/child hierarchy. То есть при предоставлении разрешения SELECT для базы данных оно включает разрешение SELECT для всех (дочерних) схем в базе данных.That is, if you grant SELECT permission on a database, that permission includes SELECT permission on all (child) schemas in the database. При предоставлении разрешения SELECT для схемы оно включает разрешение SELECT для всех (дочерних) таблиц и представлений в схеме.If you grant SELECT permission on a schema, it includes SELECT permission on all the (child) tables and views in the schema. Разрешения являются транзитивными; то есть при предоставлении разрешения SELECT для базы данных оно включает разрешение SELECT для всех (дочерних) схем и всех (внучатых) таблиц и представлений.The permissions are transitive; that is, if you grant SELECT permission on a database, it includes SELECT permission on all (child) schemas, and all (grandchild) tables and views.

Кроме того, предусмотрены покрывающие разрешения.Permissions also have covering permissions. Разрешение CONTROL для объекта, как правило, предоставляет все прочие разрешения для этого объекта.The CONTROL permission on an object, normally gives you all other permissions on the object.

Поскольку иерархия "родители — потомки" и иерархия покрытия могут применяться к одному разрешению, с течением времени система разрешений может усложняться.Because both the parent/child hierarchy and the covering hierarchy can act on the same permission, the permission system can get complicated. Например, рассмотрим таблицу (Region) в схеме (Customers) в базе данных (SalesDB).For example, let's take a table (Region), in a schema (Customers), in a database (SalesDB).

  • CONTROL для таблицы Region включает все остальные разрешения для таблицы Region, в том числе ALTER, SELECT, INSERT, UPDATE, DELETEи некоторые другие разрешения.CONTROL permission on table Region includes all the other permissions on the table Region, including ALTER, SELECT, INSERT, UPDATE, DELETE, and some other permissions.

  • SELECT для схемы Customers, к которой принадлежит таблица Region, включает разрешение SELECT для таблицы Region.SELECT on the Customers schema that owns the Region table includes the SELECT permission on the Region table.

Таким образом, разрешение SELECT для таблицы Region можно предоставить с помощью любой из этих шести инструкций:So SELECT permission on the Region table can be achieved through any of these six statements:

GRANT SELECT ON OBJECT::Region TO Ted;   
  
GRANT CONTROL ON OBJECT::Region TO Ted;   
  
GRANT SELECT ON SCHEMA::Customers TO Ted;   
  
GRANT CONTROL ON SCHEMA::Customers TO Ted;   
  
GRANT SELECT ON DATABASE::SalesDB TO Ted;   
  
GRANT CONTROL ON DATABASE::SalesDB TO Ted;  

Предоставление минимального разрешенияGrant the Least Permission

Первое указанное выше разрешение (GRANT SELECT ON OBJECT::Region TO Ted;) — наиболее гранулярное, то есть эта инструкция предоставляет минимально возможное разрешение SELECT.The first permission listed above (GRANT SELECT ON OBJECT::Region TO Ted;) is the most granular, that is, that statement is the least permission possible that grants the SELECT. Вместе с ним не предоставляются разрешения для каких-либо вложенных объектов.No permissions to subordinate objects come with it. Рекомендуется всегда предоставлять минимально возможное разрешение, однако (напротив) на более высоких уровнях для упрощения системы предоставления разрешений.It's a good principal to always grant the least permission possible, but (contradicting that) grant at higher levels in order to simplify the granting system. Таким образом, если пользователю Ted нужны разрешения для всей схемы, предоставьте разрешение SELECT один раз на уровне схемы, вместо того чтобы предоставлять SELECT на уровне таблицы или представления несколько раз.So if Ted needs permissions to the entire schema, grant SELECT once at the schema level, instead of granting SELECT at the table or view level many times. Структура базы данных имеет большое влияние на успешность применения этой стратегии.The design of the database has a great deal of impact on how successful this strategy can be. Стратегия наиболее эффективна, когда объекты в базе данных, которым требуются одинаковые разрешения, включаются в одну схему.This strategy will work best when your database is designed so that objects needing identical permissions are included in a single schema.

Список разрешенийList of Permissions

SQL Server 2016 (13.x);SQL Server 2016 (13.x) предусмотрено 230 разрешений.has 230 permissions. SQL Server 2014 (12.x)SQL Server 2014 (12.x) предусмотрено 219 разрешений.has 219 permissions. SQL Server 2012 (11.x)SQL Server 2012 (11.x) предусмотрено 214 разрешений.has 214 permissions. SQL Server 2008 R2SQL Server 2008 R2 предусмотрено 195 разрешений.has 195 permissions. База данных SQLSQL Database, Microsoft Azure Synapse AnalyticsMicrosoft Azure Synapse Analyticsи Система платформы аналитикиAnalytics Platform System разрешений меньше, так как они определяют только часть ядра СУБД, тогда как отдельные их разрешения не применяются к SQL ServerSQL Server., Microsoft Azure Synapse AnalyticsMicrosoft Azure Synapse Analytics, and Система платформы аналитикиAnalytics Platform System have fewer permissions because they expose only a portion of the database engine, though each have some permissions that do not apply to SQL ServerSQL Server.

На следующей схеме показаны разрешения и их связи друг с другом.The following graphic shows the permissions and their relationships to each other. Некоторые из разрешений более высокого уровня (например, CONTROL SERVER) указаны несколько раз.Some of the higher level permissions (such as CONTROL SERVER) are listed many times. Рисунок в этой статье слишком мал для чтения.In this article, the poster is far too small to read. Щелкните изображение, чтобы скачать плакат разрешений для ядра СУБД в формате PDF.Click the image to download the Database Engine Permissions Poster in pdf format.

Разрешения для ядра СУБДDatabase Engine Permissions

Схему связей между субъектами Компонент Database EngineDatabase Engine и объектами сервера и базы данных см. в разделе Иерархия разрешений (компонент Database Engine).For a graphic showing the relationships among the Компонент Database EngineDatabase Engine principals and server and database objects, see Permissions Hierarchy (Database Engine).

Различия разрешений и предопределенных ролей сервера и базы данныхPermissions vs. Fixed Server and Fixed Database Roles

Разрешения предопределенных ролей сервера и базы данных схожи с гранулярными разрешениями, но все же отличаются от них.The permissions of the fixed server roles and fixed database roles are similar but not exactly the same as the granular permissions. Например, члены предопределенной роли сервера sysadmin имеют все разрешения для экземпляра SQL ServerSQL Server, как и имена входа с разрешением CONTROL SERVER .For example, members of the sysadmin fixed server role have all permissions on the instance of SQL ServerSQL Server, as do logins with the CONTROL SERVER permission. Но предоставление разрешения CONTROL SERVER не делает имя входа членом предопределенной роли сервера sysadmin, а добавление имени входа в предопределенную роль сервера sysadmin не подразумевает явного предоставления ему разрешения CONTROL SERVER.But granting the CONTROL SERVER permission does not make a login a member of the sysadmin fixed server role, and adding a login to the sysadmin fixed server role does not explicitly grant the login the CONTROL SERVER permission. Иногда хранимая процедура выполняет проверку разрешений путем проверки предопределенной роли, а не гранулярного разрешения.Sometimes a stored procedure will check permissions by checking the fixed role and not checking the granular permission. Например, для отключения базы данных требуется членство в предопределенной роли базы данных db_owner .For example detaching a database requires membership in the db_owner fixed database role. Эквивалентного разрешения CONTROL DATABASE недостаточно.The equivalent CONTROL DATABASE permission is not enough. Эти две системы работают параллельно, но редко взаимодействуют друг с другом.These two systems operate in parallel but rarely interact with each other. Специалисты Майкрософт рекомендуют по возможности использовать более новую систему гранулярных разрешений вместо предопределенных ролей.Microsoft recommends using the newer, granular permission system instead of the fixed roles whenever possible.

Отслеживание разрешенийMonitoring Permissions

В следующих представлениях отображаются сведения о безопасности.The following views return security information.

  • Имена входа и определяемые пользователем роли сервера на сервере можно просмотреть в представлении sys.server_principals .The logins and user-defined server roles on a server can be examined by using the sys.server_principals view. Это представление недоступно в База данных SQLSQL Database.This view is not available in База данных SQLSQL Database.

  • Пользователей и определяемые пользователями роли в базе данных можно просмотреть в представлении sys.database_principals .The users and user-defined roles in a database can be examined by using the sys.database_principals view.

  • Разрешения, предоставленные именам входа и определяемым пользователями предопределенным ролям сервера, можно просмотреть в представлении sys.server_permissions .The permissions granted to logins and user-defined fixed server roles can be examined by using the sys.server_permissions view. Это представление недоступно в База данных SQLSQL Database.This view is not available in База данных SQLSQL Database.

  • Разрешения, предоставленные пользователям и определяемым пользователем предопределенным ролям базы данных, можно просмотреть в представлении sys.database_permissions .The permissions granted to users and user-defined fixed database roles can be examined by using the sys.database_permissions view.

  • Членство в роли базы данных можно проверить с помощью представления sys. sys.database_role_members .Database role membership can be examined by using the sys. sys.database_role_members view.

  • Членство в роли сервера можно проверить с помощью представления sys.server_role_members .Server role membership can be examined by using the sys.server_role_members view. Это представление недоступно в База данных SQLSQL Database.This view is not available in База данных SQLSQL Database.

  • Другие представления, связанные с безопасностью, описываются в разделе Представления каталога безопасности (Transact-SQL) .For additional security related views, see Security Catalog Views (Transact-SQL) .

Полезные инструкции Transact-SQLUseful Transact-SQL Statements

Следующие инструкции возвращают полезные сведения о разрешениях.The following statements return useful information about permissions.

Чтобы получить список явных разрешений, предоставленных или отклоненных в базе данных (SQL ServerSQL Server и База данных SQLSQL Database), выполните приведенную ниже инструкцию в базе данных.To return the explicit permissions granted or denied in a database ( SQL ServerSQL Server and База данных SQLSQL Database), execute the following statement in the database.

SELECT   
    perms.state_desc AS State,   
    permission_name AS [Permission],   
    obj.name AS [on Object],   
    dPrinc.name AS [to User Name]  
FROM sys.database_permissions AS perms  
JOIN sys.database_principals AS dPrinc  
    ON perms.grantee_principal_id = dPrinc.principal_id  
JOIN sys.objects AS obj  
    ON perms.major_id = obj.object_id;  

Чтобы получить список членов ролей сервера (только SQL ServerSQL Server), выполните приведенную ниже инструкцию.To return the members of the server roles ( SQL ServerSQL Server only), execute the following statement.

SELECT sRole.name AS [Server Role Name] , sPrinc.name AS [Members]  
FROM sys.server_role_members AS sRo  
JOIN sys.server_principals AS sPrinc  
    ON sRo.member_principal_id = sPrinc.principal_id  
JOIN sys.server_principals AS sRole  
    ON sRo.role_principal_id = sRole.principal_id;  

Чтобы получить список членов ролей базы данных (SQL ServerSQL Server и База данных SQLSQL Database), выполните приведенную ниже инструкцию в базе данных.To return the members of the database roles ( SQL ServerSQL Server and База данных SQLSQL Database), execute the following statement in the database.

SELECT dRole.name AS [Database Role Name], dPrinc.name AS [Members]  
FROM sys.database_role_members AS dRo  
JOIN sys.database_principals AS dPrinc  
    ON dRo.member_principal_id = dPrinc.principal_id  
JOIN sys.database_principals AS dRole  
    ON dRo.role_principal_id = dRole.principal_id;  

Next StepsNext Steps

Другие разделы, посвященные началу работы:For more topics to get you started, see:

См. также:See Also

Центр обеспечения безопасности для базы данных Azure SQL и SQL Server Database Engine Security Center for SQL Server Database Engine and Azure SQL Database
Функции безопасности (Transact-SQL) Security Functions (Transact-SQL)
Динамические административные представления и функции, связанные с безопасностью (Transact-SQL) Security-Related Dynamic Management Views and Functions (Transact-SQL)
Представления каталога безопасности (Transact-SQL) Security Catalog Views (Transact-SQL)
sys.fn_builtin_permissions (Transact-SQL) sys.fn_builtin_permissions (Transact-SQL)
Определение действующих разрешений для ядра СУБДDetermining Effective Database Engine Permissions