데이터베이스 엔진 권한 시작Getting Started with Database Engine Permissions

이 항목은 다음에 적용됩니다. 예SQL Server(2008부터)예Azure SQL Database예Azure SQL Data Warehouse 예병렬 데이터 웨어하우스 THIS TOPIC APPLIES TO: yesSQL Server (starting with 2008)yesAzure SQL DatabaseyesAzure SQL Data Warehouse yesParallel Data Warehouse

데이터베이스 엔진Database Engine 의 권한은 로그인 및 서버 역할을 통해 서버 수준에서 관리되고 데이터베이스 사용자 및 데이터베이스 역할을 통해 데이터베이스 수준에서 관리됩니다.Permissions in the 데이터베이스 엔진Database Engine are managed at the server level through logins and server roles, and at the database level through database users and database roles. SQL 데이터베이스SQL Database 에 대한 모델은 각 데이터베이스 내에서 동일한 시스템을 노출하지만 서버 수준 권한을 사용할 수 없습니다.The model for SQL 데이터베이스SQL 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 을 사용하며, 작업 수행 권한을 할당 받을 수 있는 ID의 공식 이름입니다.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 데이터베이스 엔진SQL Server Database Engine에 로그온하기 위한 개별 사용자 계정입니다.Logins are individual user accounts for logging on to the SQL Server 데이터베이스 엔진SQL Server Database Engine. SQL ServerSQL ServerSQL 데이터베이스SQL Database 는 Windows 인증 기반의 로그인 및 SQL ServerSQL Server 인증 기반의 로그인을 지원합니다. and SQL 데이터베이스SQL 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). SQL 데이터베이스SQL Database 는 고정 서버 역할을 지원하지 않지만 master 데이터베이스에 서버 역할처럼 작동하는 두 가지 역할(dbmanagerloginmanager)이 있습니다. 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). SQL 데이터베이스SQL 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 Directory에서 다음을 수행합니다.In 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 그룹에 대한 로그인을 만듭니다.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 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.

  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.

    이 시점에서 Windows 사용자는 일반적으로 Windows 그룹의 멤버입니다.The typical result at this point, is that a Windows user is a member of a Windows group. Windows 그룹에는 SQL ServerSQL Server 또는 SQL 데이터베이스SQL Database의 로그인이 있습니다.The Windows group has a login in SQL ServerSQL Server or SQL 데이터베이스SQL Database. 로그인은 사용자 데이터베이스에서 사용자 ID에 매핑됩니다.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;  
  • AUTHORIZATIONGRANT, REVOKE 또는 DENY여야 합니다.AUTHORIZATION must be GRANT, REVOKE or DENY.

  • PERMISSION 은 허용되거나 금지된 작업을 설정합니다.The PERMISSION establishes what action is allowed or prohibited. SQL Server 2016SQL Server 2016 에서는 230개의 권한을 지정할 수 있습니다. can specify 230 permissions. SQL 데이터베이스SQL Database 에는 일부 작업이 Azure에서 관련이 없기 때문에 더 적은 권한이 있습니다. has fewer permissions because some actions are not relevant in Azure. 사용 권한은 사용 권한(데이터베이스 엔진) 항목 및 아래에 참조된 차트에 나와 있습니다.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. Ted에게는 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;. 관리자가 Sales 역할에 대한 GRANT 를 제거하려고 한다고 가정해 보겠습니다.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; 를 잘못 실행한 경우 Sales 역할의 멤버인 Ted는 Sales에 대한 SELECT 가 자신의 개인적인 DENY 를 재정의하므로 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. Customers 스키마와 SalesDB 데이터베이스에 있는 Region 테이블을 예로 들어 보겠습니다.For example, let's take a table (Region), in a schema (Customers), in a database (SalesDB).

  • CONTROL 권한에는 ALTER, SELECT, INSERT, UPDATE, DELETE및 기타 권한을 포함하여 Region 테이블에 대한 다른 모든 권한이 포함됩니다.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 권한에는 Region 테이블에 대한 SELECT 권한이 포함됩니다.SELECT on the Customers schema that owns the Region table includes the SELECT permission on the Region table.

    따라서 Region 테이블에 대한 SELECT 권한은 다음 6개 문 중 하나를 통해 구현할 수 있습니다.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 2016SQL Server 2016 에는 230개의 권한이 있습니다. has 230 permissions. SQL Server 2014SQL Server 2014 에는 219개의 권한이 있습니다. has 219 permissions. SQL Server 2012SQL Server 2012 에는 214개의 권한이 있습니다. has 214 permissions. SQL Server 2008 R2SQL Server 2008 R2 에는 195개의 권한이 있습니다. has 195 permissions. SQL 데이터베이스SQL Database, SQL 데이터 웨어하우스SQL Data Warehouse분석 플랫폼 시스템Analytics Platform System 에는 각각 SQL ServerSQL Server에 적용되지 않는 일부 권한이 있지만 데이터베이스 엔진의 일부만 노출하기 때문에 권한 수가 적습니다., SQL 데이터 웨어하우스SQL Data Warehouse, 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 topic, the poster is far to small to read. 이미지를 클릭하여 데이터베이스 엔진 사용 권한 포스터를 pdf 형식으로 다운로드합니다.Click the image to download the Database Engine Permissions Poster in pdf format.

데이터베이스 사용 엔진 권한Database Engine Permissions

데이터베이스 엔진Database Engine 보안 주체와 서버 및 데이터베이스 개체 간의 관계를 보여 주는 그래픽은 사용 권한 계층 구조(데이터베이스 엔진)를 참조하세요.For a graphic showing the relationships among the 데이터베이스 엔진Database 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. 이 뷰는 SQL 데이터베이스SQL Database에서 사용할 수 없습니다.This view is not available in SQL 데이터베이스SQL 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. 이 뷰는 SQL 데이터베이스SQL Database에서 사용할 수 없습니다.This view is not available in SQL 데이터베이스SQL 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. 이 뷰는 SQL 데이터베이스SQL Database에서 사용할 수 없습니다.This view is not available in SQL 데이터베이스SQL Database.

  • 추가 보안 관련 뷰는 보안 카탈로그 뷰(Transact-SQL) 를 사용하여 보안 주체를 만들고 관리할 수 있습니다.For additional security related views, see Security Catalog Views (Transact-SQL) .

유용한 Transact-SQL 문Useful Transact-SQL Statements

다음 문은 권한에 대한 유용한 정보를 반환합니다.The following statements return useful information about permissions.

데이터베이스에서 부여되거나 거부된 명시적 권한( SQL ServerSQL ServerSQL 데이터베이스SQL Database)을 반환하려면 데이터베이스에서 다음 문을 실행합니다.To return the explicit permissions granted or denied in a database ( SQL ServerSQL Server and SQL 데이터베이스SQL 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 ServerSQL 데이터베이스SQL Database)를 반환하려면 데이터베이스에서 다음 문을 실행합니다.To return the members of the database roles ( SQL ServerSQL Server and SQL 데이터베이스SQL 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 Steps

시작하는 데 유용한 추가 항목은 다음을 참조하세요.For more topics to get you started, see:

참고 항목See Also

SQL Server 데이터베이스 엔진 및 Azure SQL 데이터베이스에 대한 보안 센터 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