データベース エンジンの権限の概要Getting Started with Database Engine Permissions

適用対象: ○SQL Server ○Azure SQL Database ○Azure SQL Data Warehouse ○Parallel Data WarehouseAPPLIES TO: yesSQL Server yesAzure SQL Database yesAzure 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 DatabaseSQL Database のモデルでは各データベース内に同じシステムを公開していますが、サーバー レベルの権限を使用できません。The model for SQL DatabaseSQL 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.

LoginLogins
ログインとは、 SQL Server データベース エンジンSQL Server Database Engineにログオンするための個々のユーザー アカウントです。Logins are individual user accounts for logging on to the SQL Server データベース エンジンSQL Server Database Engine. SQL ServerSQL Server SQL DatabaseSQL Database は Windows 認証に基づくログインと、 SQL ServerSQL Server 認証に基づくログインをサポートします。and SQL DatabaseSQL Database support logins based on Windows authentication and logins based on SQL ServerSQL Server authentication. 2 種類のログインの詳細については、「 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 DatabaseSQL Database は固定サーバー ロールをサポートしていませんが、マスター データベースにサーバー ロールとして機能する 2 つのロール (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 DatabaseSQL 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. ログインはデータベース内の 1 つのユーザーにのみマッピングできますが、異なる複数のデータベースにデータベース ユーザーとしてマッピングできます。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. ユーザー データベースで、それぞれ類似した職務を表すユーザー定義データベース ロールを 1 つ以上作成します。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. データベース ユーザーを 1 つ以上のユーザー定義データベース ロールに追加します。Add the database users to one or more user-defined database roles.

  5. ユーザー定義データベース ロールに権限を付与します。Grant permissions to the user-defined database roles.

接続するユーザーが 1 つのデータベースにのみ接続する場合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. ユーザー データベースで、それぞれ類似した職務を表すユーザー定義データベース ロールを 1 つ以上作成します。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. データベース ユーザーを 1 つ以上のユーザー定義データベース ロールに追加します。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 DatabaseSQL Databaseにログインがあります。The Windows group has a login in SQL ServerSQL Server or SQL DatabaseSQL 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;  
  • 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. SQL DatabaseSQL Database の権限の数が少なくなっています。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. SELECT ステートメントを通じて、Ted にも 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 に対する SELECT によって Ted 個人の DENY がオーバーライドされるため、Sales ロールのメンバーである Ted の 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. たとえば、データベース (SalesDB) 内のスキーマ (Customers) にあるテーブル (Region) を見てみましょう。For example, let's take a table (Region), in a schema (Customers), in a database (SalesDB).

  • CONTROL 権限には、テーブル Region に対するその他のすべての権限 ( ALTERSELECTINSERTUPDATEDELETE、 and some other permissions.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 をスキーマ レベルで 1 回付与します。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. SQL DatabaseSQL DatabaseSQL データ ウェアハウス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 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 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. これらの 2 つのシステムは並行して運用されますが、互いに干渉することはほとんどありません。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 DatabaseSQL Databaseでは使用できません。This view is not available in SQL DatabaseSQL 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 DatabaseSQL Databaseでは使用できません。This view is not available in SQL DatabaseSQL 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 DatabaseSQL Databaseでは使用できません。This view is not available in SQL DatabaseSQL 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 DatabaseSQL Database) には、データベースで次のステートメントを実行します。To return the explicit permissions granted or denied in a database ( SQL ServerSQL Server and SQL DatabaseSQL 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 DatabaseSQL Database) には、データベースで次のステートメントを実行します。To return the members of the database roles ( SQL ServerSQL Server and SQL DatabaseSQL 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

SQL Server データベース エンジンと Azure SQL Database のセキュリティ センター 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