Azure Synapse サーバーレス SQL プールでユーザー アクセス許可を管理する
データをセキュリティで保護するために、Azure Storage では、Azure のロールベースのアクセス制御 (Azure RBAC) と、Portable Operating System Interface for Unix (POSIX) のようなアクセス制御リスト (ACL) の両方をサポートするアクセス制御モデルが実装されています。
セキュリティ プリンシパルをファイルおよびディレクトリに対するアクセス レベルと関連付けることができます。 これらの関連付けは、"アクセス制御リスト (ACL) " でキャプチャされます。 ストレージ アカウント内の各ファイルおよびディレクトリは、アクセス制御リストを持っています。 セキュリティ プリンシパルがファイルまたはディレクトリに対して操作を実行しようとすると、ACL チェックによって、そのセキュリティ プリンシパル (ユーザー、グループ、サービス プリンシパル、またはマネージド ID) が、その操作を実行するための適切なアクセス許可レベルを持っているかどうかが判断されます。
アクセス制御リストには次の 2 種類があります。
アクセス ACL
オブジェクトへのアクセスを制御します。 ファイルとディレクトリの両方がアクセス ACL を持っています。
既定の ACL
ディレクトリに関連付けられた ACL のテンプレートです。これにより、そのディレクトリの下に作成されるすべての子項目のアクセス ACL が決まります。 ファイルには既定の ACL がありません。
アクセス ACL と既定の ACL はどちらも同じ構造です。
コンテナー オブジェクトに対するアクセス許可は、読み取り、書き込み、実行であり、次の表に示すように、ファイルとディレクトリに対して使用できます。
アクセス許可のレベル
| 権限 | ファイル | ディレクトリ |
|---|---|---|
| 読み取り (R) | ファイルの内容を読み取ることができる | ディレクトリの内容を一覧表示するには、読み取りと実行が必要です。 |
| 書き込み (W) | ファイルへの書き込みまたは追加を実行できる | ディレクトリに子項目を作成するには、書き込みと実行が必要です。 |
| 実行 (X) | Data Lake Storage Gen2 のコンテキストでは、何も意味しない | ディレクトリの子項目をスキャンするために必要です。 |
ACL の設定に関するガイドライン
ACL エントリでの割り当て済みのプリンシパルとして、常に Microsoft Entra セキュリティ グループを使用します。 個々のユーザーまたはサービス プリンシパルを直接割り当てることを抑止します。 この構造体を使用すると、ユーザーまたはサービス プリンシパルを追加したり削除したりすることができます。ACL をディレクトリ構造全体に再適用する必要はありません。 代わりに、適切な Microsoft Entra セキュリティ グループからユーザーとサービス プリンシパルを追加または削除することができます。
グループを設定するさまざまな方法があります。 たとえば、サーバーによって生成されたログ データを保持する /LogData という名前のディレクトリがあるとします。 Azure Data Factory (ADF) により、そのフォルダーにデータが取り込まれます。 サービス エンジニアリング チームの特定のユーザーは、ログをアップロードし、このフォルダーの他のユーザーを管理します。また、さまざまな Databricks クラスターによって、そのフォルダーのログが分析されます。
これらのアクティビティを有効にするために、LogsWriter グループと LogsReader グループを作成できます。 その後、次のようにアクセス許可を割り当てることができます。
- LogsWriter グループを、rwx というアクセス許可で /LogData ディレクトリの ACL に追加します。
- LogsReader グループを、r-x というアクセス許可で /LogData ディレクトリの ACL に追加します。
- ADF に対するサービス プリンシパル オブジェクトまたはマネージド サービス ID (MSI) を、LogsWriter グループに追加します。
- サービス エンジニアリング チームのユーザーを、LogsWriter グループに追加します。
- Databricks に対するサービス プリンシパル オブジェクトまたは MSI を、LogsReader グループに追加します。
サービス エンジニアリング チームのユーザーが退職した場合は、LogsWriter グループから削除するだけで済みます。 そのユーザーをグループに追加せず、代わりにそのユーザーに専用の ACL エントリを追加した場合は、その ACL エントリを /LogData ディレクトリから削除する必要があります。 また、 /LogData ディレクトリのディレクトリ階層全体のすべてのサブディレクトリとファイルからも、エントリを削除する必要があります。
サーバーレス SQL プール ユーザーに必要なロール
読み取り専用アクセス権が必要なユーザーには、ストレージ BLOB データ閲覧者という名前のロールを割り当てる必要があります。
読み取り/書き込みアクセス権が必要なユーザーには、ストレージ BLOB データ共同作成者という名前のロールを割り当てる必要があります。 読み取り/書き込みアクセス権は、ユーザーが create external table as select (CETAS) のアクセス権が必要な場合に必要となります。
注意
ユーザーのロールが所有者や共同作成者である場合、そのロールは十分ではありません。 Azure Data Lake Storage Gen 2 では、スーパーロールを割り当てる必要があります。
データベース レベルのアクセス許可
ユーザーにより詳細なアクセスを提供するには、Transact-SQL 構文を使用してログインとユーザーを作成する必要があります。
ユーザーに単一のサーバーレス SQL プール データベースへのアクセスを許可するには、次の例の手順に従います。
ログインを作成します
use master CREATE LOGIN [alias@domain.com] FROM EXTERNAL PROVIDER;ユーザーを作成します
use yourdb -- Use your DB name CREATE USER alias FROM LOGIN [alias@domain.com];指定したロールのメンバーにユーザーを追加します
use yourdb -- Use your DB name alter role db_datareader Add member alias -- Type USER name from step 2 -- You can use any Database Role which exists -- (examples: db_owner, db_datareader, db_datawriter) -- Replace alias with alias of the user you would like to give access and domain with the company domain you are using.
サーバー レベルのアクセス許可
すべてのサーバーレス SQL プール データベースへのフル アクセス許可をユーザーに付与するには、次の例の手順に従います。
CREATE LOGIN [alias@domain.com] FROM EXTERNAL PROVIDER; ALTER SERVER ROLE sysadmin ADD MEMBER [alias@domain.com];