データオブジェクトに対する権限の設定 Set Permissions on a Data Object

注意

アクセス制御にはAzure Databricks Premium プランが必要です。Access control requires the Azure Databricks Premium Plan.

Azure Databricks ビューベースのデータガバナンスモデルを使用すると、Spark SQL API からのデータへのアクセスをプログラムで許可、拒否、および取り消すことができます。The Azure Databricks view-based data governance model lets you programmatically grant, deny, and revoke access to your data from the Spark SQL API.

このデータガバナンスモデルを使用すると、テーブル、データベース、ビュー、関数などのセキュリティ保護可能なオブジェクトへのアクセスを制御できます。This data governance model lets you control access to securable objects like tables, databases, views, and functions. また、任意のクエリから作成された派生ビューに対する権限を設定することにより、(たとえば、テーブルの特定のサブセットに対する) きめ細かなアクセス制御を可能にします。It also allows for fine-grained access control (to a particular subset of a table, for example) by setting permissions on derived views created from arbitrary queries. Azure Databricks SQL クエリアナライザーでは、テーブルのアクセス制御が有効になっているクラスターで、実行時にこれらのアクセス制御ポリシーが適用されます。The Azure Databricks SQL query analyzer enforces these access control policies at runtime on clusters with table access control enabled.

このトピックでは、Azure Databricks ビューベースのデータアクセス制御モデルを構成する特権、オブジェクト、および所有権の規則について説明します。This topic describes the privileges, objects, and ownership rules that make up the Azure Databricks view-based data access control model. また、オブジェクトの権限を許可、拒否、および取り消す方法についても説明します。It also describes how to grant, deny, and revoke object privileges.

前提条件Requirements

データオブジェクトに対する権限を許可、拒否、または取り消すには、管理者がクラスターのテーブルアクセス制御を有効にする必要があります。Before you can grant, deny, or revoke privileges on data objects, an administrator must enable table access control for the cluster. このセキュリティモデルに従うクラスターを作成する方法の詳細については、「 Enable Table Access Control」を参照してください。For information about how to create a cluster that follows this security model, see Enable Table Access Control.

ビューベースのアクセス制御モデル View-based access control model

このセクションでは、Azure Databricks ビューベースのデータアクセス制御モデルについて説明します。This section describes the Azure Databricks view-based data access control model.

特権Privileges

  • SELECT –オブジェクトへの読み取りアクセス権を付与します。SELECT – gives read access to an object
  • CREATE –オブジェクト (たとえば、データベース内のテーブル) を作成する機能を提供します。CREATE – gives ability to create an object (for example, a table in a database)
  • MODIFY –オブジェクトとの間でデータの追加/削除/変更を行う機能を提供します。MODIFY – gives ability to add/delete/modify data to/from an object
  • READ_METADATA –オブジェクトとそのメタデータを表示する機能を提供します。READ_METADATA – gives ability to view an object and its metadata
  • CREATE_NAMED_FUNCTION –既存のカタログまたはデータベースに名前付き UDF を作成する機能を提供します。CREATE_NAMED_FUNCTION – gives ability to create a named UDF in an existing catalog or database
  • ALL PRIVILEGES –すべての特権を付与します (上記のすべての特権に変換されます)。ALL PRIVILEGES – gives all privileges (gets translated into all the above privileges)

ObjectsObjects

上記の特権は、次のオブジェクトのクラスに適用できます。The privileges above can apply to the following classes of objects:

  • CATALOG-データカタログ全体へのアクセスを制御します。CATALOG - controls access to the entire data catalog.
  • DATABASE-データベースへのアクセスを制御します。DATABASE - controls access to a database.
  • TABLE-マネージテーブルまたは外部テーブルへのアクセスを制御します。TABLE - controls access to a managed or external table.
  • VIEW-SQL ビューへのアクセスを制御します。VIEW - controls access to SQL views.
  • FUNCTION-名前付き関数へのアクセスを制御します。FUNCTION - controls access to a named function.
  • ANONYMOUS FUNCTION-匿名関数または一時関数へのアクセスを制御します。ANONYMOUS FUNCTION - controls access to anonymous or temporary functions.
  • ANY FILE-基になるファイルシステムへのアクセスを制御します。ANY FILE - controls access to the underlying filesystem.

オブジェクトの所有権Object ownership

アクションによっては、オブジェクト (テーブル、ビュー、またはデータベース) の所有権によって、アクションを実行する権限があるかどうかが決まります。For some actions, the ownership of the object (table, view, or database) determines if you are authorized to perform the action. テーブル、ビュー、またはデータベースを作成したユーザーが所有者になります。The user who creates the table, view, or database becomes its owner. テーブルとビューの場合、所有者にはすべての特権が付与され、他のユーザーに権限を与えることができます。In the case of tables and views, the owner is granted all privileges, and can grant those privileges to other users.

たとえば、所有権によって、派生オブジェクトに対する権限を他のユーザーに許可できるかどうかが決まります。For example, ownership determines whether or not you can grant permissions on derived objects to other users. ユーザー A がテーブル T を所有していて、テーブル T に対する SELECT 権限をユーザー B に付与しているとします。これで、ユーザー B はテーブル T から選択できるようになりましたが、ユーザー B はテーブル t の SELECT 権限をユーザー C に付与できません。これは、ユーザー A が依然として基になるテーブル T の所有者であるためです。Suppose User A owns Table T and grants User B SELECT permission on Table T. Now, even though User B can select from Table T, User B cannot grant SELECT permission on Table T to User C, because User A is still the owner of the underlying Table T.

さらに、ユーザー B はテーブル T にビュー V を作成し、_その_ビューに対する権限をユーザー C に付与するだけで、この制限を回避することはできません。Databricks は、View V にアクセスするためのアクセス許可をユーザー C に確認するときに、V と基になるテーブル T の所有者が同じであることも確認します。Furthermore, User B cannot circumvent this restriction simply by creating a View V on Table T and granting permissions on that view to User C. When Databricks checks for permissions for User C to access View V, it also checks that the owner of V and underlying Table T are the same. 所有者が同じでない場合は、ユーザー C も基になるテーブル T に対する select 権限を持っている必要があります。If the owners are not the same, User C must also have select permissions on underlying Table T.

要約すると、オブジェクトの所有者は、そのオブジェクトへのアクセスを制御します。To summarize, the owner of an object controls access to that object. これは、テーブルへの詳細なアクセスに使用されるビューだけでなく、テーブルにも適用されます。This applies to tables as well as to views that are used for fine-grained access to tables.

ユーザーとグループUsers and groups

権限は、groups API を使用して作成されたユーザーまたはグループに付与できます。Privileges can be granted to users or groups that are created via the groups API. 各ユーザーは、Azure Databricks のユーザー名 (通常は電子メールアドレスにマップされます) によって一意に識別されます。Each user is uniquely identified by their username (which typically maps to their email address) in Azure Databricks. Databricks のワークスペース管理者であるユーザーは、特別な admin ロールに属しており、明示的にアクセス権が付与されていないオブジェクトにアクセスすることもできます。Users who are workspace administrators in Databricks belong to a special admin role and can also access objects that they haven’t been given explicit access to.

特権階層Privilege hierarchy

オブジェクトの特権は階層的です。Privileges on objects are hierarchical. つまり、すべてのデータベースに対して特権を許可または拒否すると、すべてのデータベース (およびすべてのテーブルとビュー) に CATALOG 対して権限が自動的に付与または拒否されます。This means that granting or denying a privilege on the entire CATALOG automatically grants or denies the privilege to all of the databases (as well as all tables and views). 同様に、特定の DATABASE に対して権限を許可または拒否すると、そのデータベース内のすべてのテーブルとビューに対する権限が自動的に付与または拒否されます。Similarly, granting or denying a privilege to a given DATABASE automatically grants or denies the privilege to all tables and views in that database.

ユーザーが指定したオブジェクトの管理者または所有者である場合は、常にすべてのアクションを実行できます。If a user is an admin or an owner of the specified object they will always be able to perform all actions. そうしないと、操作が拒否されても、実行できなくなります。Otherwise if the action is denied they will never be able to perform it. 上記のいずれの規則も適用されない場合、ユーザーは許可されている場合にのみアクションを実行できます。If none of the preceding rules apply then a user can only perform the action if it is granted.

オブジェクト権限の許可、拒否、および取り消しGrant, deny, and revoke object privileges

commandCommands

オブジェクトの特権を管理するには、次のコマンドを使用します。You use the following commands to manage object privileges:

GRANT

オブジェクトに対する特定の権限をユーザーまたはプリンシパルに付与します。Grant a specific permission on an object to a user or principal. データベースに対する権限の許可 (たとえば、SELECT 権限) は、そのデータベース内のすべてのオブジェクトに対して権限を暗黙的に許可するという効果があります。Granting a permission on a database (for example a SELECT permission) has the effect of implicitly granting that permission on all objects in that database. カタログに対する特定の権限を許可すると、カタログ内のすべてのデータベースに対してその権限が暗黙的に許可されます。Granting a specific permission on the catalog has the effect of implicitly granting that permission on all databases in the catalog.

GRANT
  privilege_type [, privilege_type ] ...
  ON (CATALOG | DATABASE db_name | [TABLE] table_name | [VIEW] view_name | [FUNCTION] function_name | ANONYMOUS FUNCTION | ANY FILE)
  TO user

privilege_type
  : SELECT | CREATE | MODIFY | READ_METADATA | CREATE_NAMED_FUNCTION | ALL PRIVILEGES

DENY

オブジェクトに対する特定の権限をユーザーまたはプリンシパルに対して拒否します。Deny a specific permission on an object to a user or principal. データベースに対する権限 (たとえば SELECT 権限) を拒否すると、そのデータベース内のすべてのオブジェクトに対する権限が暗黙的に拒否されるという効果があります。Denying a permission on a database (for example a SELECT permission) has the effect of implicitly denying that permission on all objects in that database. カタログに対する特定の権限を拒否すると、カタログ内のすべてのデータベースに対する権限が暗黙的に拒否されることになります。Denying a specific permission on the catalog has the effect of implicitly denying that permission on all databases in the catalog.

DENY を使用すると、暗黙的または明示的な GRANTs にかかわらず、指定されたオブジェクトにユーザーまたはプリンシパルがアクセス_できない_ようにすることができます。DENY can be used to ensure that a user or principal cannot access the specified object, despite any implicit or explicit GRANTs. オブジェクトにアクセスするとき、Databricks は、明示的または暗黙的な GRANTs があるかどうかを確認する前に、そのオブジェクトに明示的または暗黙的な DENYs があるかどうかを確認します。When an object is accessed, Databricks first checks if there are any explicit or implicit DENYs on the object before checking if there are any explicit or implicit GRANTs.

たとえば、テーブル t1t2 のデータベース db があるとします。For example, suppose there is a database db with tables t1 and t2. ユーザーには、最初に db に対する SELECT の特権が付与されます。A user is initially granted SELECT privileges on db. ユーザーは、データベース dbGRANT によって t1およびt2 にアクセスできます。The user can access t1 and t2 due to the GRANT on the database db.

これで、管理者がテーブル t1DENY を発行した場合、ユーザーは t1 にアクセスできなくなります。Now if the administrator issues a DENY on table t1, the user will no longer be able to access t1. 管理者がデータベース dbDENY を発行した場合、これらのテーブルに明示的な GRANT がある_場合でも_、ユーザーは db 内のテーブルにアクセスできなくなります。If the administrator issues a DENY on database db, the user will not be able to access any tables in db even if there is an explicit GRANT on these tables. つまり、DENY は常に GRANT よりも優先されます。That is, the DENY always supersedes the GRANT.

DENY
  privilege_type [, privilege_type ] ...
  ON (CATALOG | DATABASE db_name | [TABLE] table_name | [VIEW] view_name | [FUNCTION] function_name | ANONYMOUS FUNCTION | ANY FILE)
  TO user

privilege_type
  : SELECT | CREATE | MODIFY | READ_METADATA | CREATE_NAMED_FUNCTION | ALL PRIVILEGES

REVOKE

オブジェクトに対して_明示的_に許可または拒否された権限をユーザーから取り消します。Revoke an explicitly granted or denied permission on an object from a user. REVOKE は、厳密にはコマンドで指定されたオブジェクトに限定されており、包含オブジェクトにはカスケードされません。A REVOKE is strictly scoped to the object specified in the command and does not cascade to contained objects.

たとえば、テーブル t1t2 のデータベース db があるとします。For example, suppose there is a database db with tables t1 and t2. ユーザーには、最初に dbt1 に対する SELECT の特権が付与されます。A user is initially granted SELECT privileges on db and on t1. ユーザーは、データベース dbGRANT のために t2 にアクセスできます。The user can access t2 due to the GRANT on the database db.

管理者が dbSELECT 特権を取り消すと、ユーザーは t2にアクセスできなくなりますが、テーブル GRANT に明示的な t1があるため、t1 にアクセスすることはできます。If the administrator revokes the SELECT privilege on db, the user will no longer be able to access t2, but will still be able to access t1 since there is an explicit GRANT on table t1.

代わりに、管理者がテーブル t1SELECT を取り消しても、データベースの dbSELECT を保持している場合でも、データベースの t1SELECT テーブルに対して暗黙的に権限を与えるため、ユーザーは db にアクセスできます。If the administrator instead revokes the SELECT on table t1 but still keeps the SELECT on database db, the user can still access t1 because the SELECT on the database db implicitly confers privileges on the table t1.

REVOKE
  privilege_type [, privilege_type ] ...
  ON (CATALOG | DATABASE db_name | [TABLE] table_name | [VIEW] view_name | [FUNCTION] function_name | ANONYMOUS FUNCTION | ANY FILE)
  FROM user

privilege_type
  : SELECT | CREATE | MODIFY | READ_METADATA | CREATE_NAMED_FUNCTION | ALL PRIVILEGES

Examples

GRANT SELECT ON DATABASE database_name to `user1@databricks.com`;
DENY SELECT ON table_name to `user2@databricks.com`;
GRANT SELECT ON ANONYMOUS FUNCTION to `user3@databricks.com`;
GRANT SELECT ON ANY FILE to `user4@databricks.com`;
REVOKE ALL PRIVILEGES ON DATABASE default FROM `user1@databricks.com`
REVOKE SELECT ON table_name default FROM `user2@databricks.com`

SHOW GRANT

指定されたオブジェクトに影響するすべてのアクセス許可 (継承、拒否、許可など) を表示します。Display all permissions (including inherited, denied, and granted) that affect the specified object.

SHOW GRANT [user] ON (CATALOG | DATABASE db_name | [TABLE] table_name | [VIEW] view_name | [FUNCTION] function_name | ANONYMOUS FUNCTION | ANY FILE)

Example

SHOW GRANT `user1@databricks.com` ON DATABASE default

ビューベースのアクセス制御View-based access control

任意のクエリを含む派生ビューへのアクセスを許可することで、きめ細かなアクセス制御を (特定の条件に一致する行と列に) 構成できます。You can configure fine-grained access control (to rows and columns matching specific conditions, for example) by granting access to derived views that contain arbitrary queries.

Example

CREATE OR REPLACE VIEW view_name AS SELECT columnA, columnB FROM table_name WHERE columnC > 1000;
GRANT SELECT ON VIEW view_name to `user1@databricks.com`;

SQL 操作に必要な特権Privileges required for SQL operations

次の表は、特権を SQL 操作にマップしています。The following table maps privileges to SQL operations:

操作/特権Operations / Privilege SELECTSELECT 生成CREATE 更新MODIFY READ_METADATAREAD_METADATA CREATE_NAMED_FUNCTIONCREATE_NAMED_FUNCTION 所有権Ownership [Admin]Admin
CREATE TABLE xx xx xx
DESCRIBE TABLE xx xx xx
ALTER TABLE xx xx xx
DROP TABLE xx xx
CREATE VIEW xx xx xx
DROP VIEW xx xx
SELECT xx xx xx
CREATE FUNCTION xx xx xx
MSCK xx xx
CREATE DATABASE xx xx xx
EXPLAIN xx xx xx
DROP DATABASE xx xx
GRANT xx xx
REVOKE xx xx

よく寄せられる質問 (FAQ)Frequently asked questions (FAQ)

テーブルまたはビューを作成しましたが、これをクエリ、削除、または変更することはできません。I created a table or view but now I can’t query, drop, or modify it.

このエラーは、テーブル Acl が有効になっていないクラスターでそのテーブルを作成したことが原因で発生する可能性があります。This error can occur because you created that table on a cluster without Table ACLs enabled. テーブル Acl がクラスターで無効になっている場合、テーブル、ビュー、またはデータベースの作成時に所有者は登録されません。When Table ACLs are disabled on a cluster, owners are not registered when a table, view, or database is created. この問題を軽減するには、管理者は次のコマンドを使用してテーブルに所有者を割り当てる必要があります。To mitigate this problem an admin must assign an owner to the table using the following command:

ALTER TABLE <table-name> OWNER TO `<user-name>@<user-domain>.com`;

新しい所有者でない場合は、所有者または管理者が次のコマンドを使用して SELECT アクセス許可を付与する必要があります。If you are not the new owner, the owner or an admin must provide SELECT permission to you using the following command:

GRANT SELECT ON TABLE <table-name> to `<user-name>@<user-domain>.com`;

グローバルおよびローカルの一時ビューに対してアクセス許可を付与操作方法にはHow do I grant permissions on global and local temporary views?

残念ながら、グローバルおよびローカルの一時ビューに対する権限はサポートされていません。Unfortunately permissions on global and local temporary views are not supported. ローカル一時ビューは同じセッション内でのみ表示され、global_temp データベースで作成されたビューは、クラスターを共有するすべてのユーザーに表示されます。Local temporary views are visible only within the same session, and views created in the global_temp database are visible to all users sharing a cluster. ただし、すべての一時ビューで参照される基になるテーブルとビューに対する権限が適用されます。However, permissions on the underlying tables and views referenced by any temporary views are enforced.

複数のテーブルに対するユーザーまたはグループのアクセス許可を一度に付与操作方法にはHow do I grant a user or group permissions on multiple tables at once?

Grant、deny、または revoke ステートメントは、一度に1つのオブジェクトにのみ適用できます。A grant, deny, or revoke statement can be applied to only one object at a time. 1つのプリンシパルに対して複数のテーブルに対する権限を編成し、許可する方法としては、データベースを使用することをお勧めします。The recommended way to organize and grant permissions on multiple tables to a principal is via databases. プリンシパル SELECT 権限をデータベースに付与すると、そのデータベース内のすべてのテーブルおよびビューに対するプリンシパル SELECT 権限が暗黙的に付与されます。Granting a principal SELECT permission on a database implicitly grants that principal SELECT permissions on all tables and views in that database. たとえば、データベース D に T1 と T2 のテーブルがある場合、管理者は次の GRANT コマンドを発行します。For example, if a database D has tables T1 and T2, and an admin issues the following GRANT command:

GRANT SELECT ON DATABASE D to `<user>@databricks.com`

プリンシパル <user>@databricks.com では、テーブル T1 と T2、および将来のデータベース D で作成されたすべてのテーブルとビューから選択できます。The principal <user>@databricks.com can select from tables T1 and T2, as well as any tables and views created in database D in the future.

1つを除くすべてのテーブルに対するアクセス許可をユーザーに付与操作方法How do I grant a user permissions on all tables except one?

SELECT 権限をデータベースに付与した後、アクセスを制限する特定のテーブルの SELECT 権限を拒否します。You grant SELECT permission to the database and then deny SELECT permission for the specific table you want to restrict access to.

GRANT SELECT ON DATABASE D to `<user>@databricks.com`
DENY SELECT ON TABLE D.T to `<user>@databricks.com`

D.T. を除くすべてのテーブルから選択できるプリンシパル <user>@databricks.comThe principal <user>@databricks.com can select from all tables in D except D.T.

ビューに対するユーザー選択アクセス許可を付与しましたが、そのユーザーがそのビューから SELECT しようとすると、エラー User does not have permission SELECT on table が表示されます。I granted a user SELECT permissions on a view, but when that user tries to SELECT from that view, they get the error User does not have permission SELECT on table.

この一般的なエラーは、オブジェクトの所有権がアクセス許可の付与機能に与える影響が原因で発生します。This common error is caused by the way object ownership affects the ability to grant permissions. 次のいずれかの理由により、テーブル T の所有者ではないため、この動作が表示されます。You see this behavior because you are not the owner of Table T, for one of the following reasons:

  • 他の人が作成したテーブル T はテーブル T の所有者です。Someone else created Table T and is the owner of Table T.
  • テーブル T には、テーブル ACL が無効になっているクラスターを使用して作成されたため、登録された所有者がありません。Table T has no registered owner because it was created using a cluster for which Table ACL is disabled.

テーブル T にビュー V があり、ユーザー U がビュー V から選択しようとしたとします。 Azure Databricks は次のことを確認します。Suppose there is a View V on Table T and User U tries to select from View V. Azure Databricks checks that:

  • ユーザー U はテーブル T に対する SELECT 権限を持っています。User U has SELECT permission on Table T.
  • 次のいずれかが当てはまります。One of the following is true:
    • ビュー V とテーブル T は同じ所有者を持っています。View V and Table T have the same owner. この場合、テーブル T の所有者は、ユーザー U への詳細なアクセスを許可されています。In this case the owner of Table T has granted fine-grained access to user U.
    • ユーザーは、テーブル T から直接選択できます。テーブル t の所有者が、テーブル t のすべてから選択できるユーザーを許可している場合、ユーザーはテーブル T の任意のビューから選択できます。User U can select directly from Table T. If the owner of Table T has allowed User U to select from all of Table T, User U can select from any view on Table T.

オブジェクトの所有権」セクションで説明したように、これらの条件により、オブジェクトの所有者だけが、そのオブジェクトへのアクセスを他のユーザーに許可できるようになります。As described in the Object ownership section, these conditions ensure that only the owner of an object can grant other users access to that object.

SHOW GRANT ON <table-name>を使用して、テーブルに所有者があるかどうかをテストできます。You can test if a table has an owner by using SHOW GRANT ON <table-name>. ActionType OWNのエントリが表示されない場合、テーブルには所有者がありません。If you do not see an entry with ActionType OWN, then the table does not have an owner. この場合、管理者ユーザーは次を実行してテーブル所有者を設定できます。If this is the case, an admin user can set the table owner by running the following:

ALTER TABLE <table-name> OWNER TO `<user-name>@<user-domain>.com`;

テーブル Acl が有効になっているクラスターで sc.parallelize を実行しようとしましたが、機能しません。I tried to run sc.parallelize on a cluster with Table ACLs enabled and it doesn’t work.

テーブル Acl が有効になっているクラスターでは、Spark SQL Api と Python データフレーム Api のみを使用できます。On clusters with Table ACLs enabled you can use only the Spark SQL and Python DataFrame APIs. RDD API はセキュリティ上の理由で許可されていません。これは、Azure Databricks が RDD 内のコードを検査して承認する機能がないためです。The RDD API is disallowed for security reasons, since Azure Databricks does not have the ability to inspect and authorize code within an RDD.