承認とは、認証されたパーティにアクションを実行するためのアクセス許可を付与する行為です。 アクセス制御の重要な原則は、ユーザーがジョブを実行するために必要なアクセスの量のみをユーザーに付与し、特定のスコープで特定のアクションのみを許可することです。 ロールベースのセキュリティは、アクセス制御に対応します。 多くの組織では、ロールベースのセキュリティを使用して、個々のユーザーではなく、定義されたロールまたはジョブ機能に基づいてアクセスを制御します。 ユーザーには 1 つ以上のセキュリティ ロールが割り当てられ、各ロールには特定のタスクを実行するための承認されたアクセス許可が付与されます。
Microsoft Entra ID は、Microsoft Entra ID に基づいて、ユーザーごとに、またはアプリケーションごとにデータ サービスとストレージにアクセスするための承認を付与する一元化された ID プロバイダーです。
データ サービスの承認
Azure ロールベースのアクセス制御 (RBAC) とアクセス制御リスト (ACL) は、アクセスの管理とセキュリティの確保において重要な役割を果たします。 Azure RBAC と ACL の両方で、ユーザーまたはアプリケーションに Microsoft Entra ID の ID が必要です。 クラウド規模の分析では、RBAC はデータベースと Azure Data Lake Storage に有効です。 ACL は主に Data Lake Storage で使用され、ファイル レベルとディレクトリ レベルできめ細かなアクセス制御を提供します。 ACL は、ストレージ階層内でより詳細なアクセス許可を提供することで、RBAC を補完します。
Azure RBAC には 、所有者、 共同作成者、 閲覧者などの組み込みロールが用意されていますが、特定のニーズに合わせてカスタム ロールを作成することもできます。 次の組み込みロールは、Azure データ サービスを含むすべての Azure リソースの種類の基本です。
| 役割 | 説明 |
|---|---|
| 所有者 | このロールは、リソースへのフル アクセス権を持ち、リソースへのアクセス権を付与する権限を含め、リソースに関するすべてのものを管理できます。 |
| 投稿者 | このロールはリソースを管理できますが、アクセス権を付与することはできません。 |
| 閲覧者 | このロールは、リソースに関するアクセス キーやシークレットなどの機密情報を除き、リソースと情報を表示できます。 リソースに変更を加えることはできません。 |
注
一部のサービスには 、ストレージ BLOB データ共同作成者 や Data Factory 共同作成者などの特定の RBAC ロールがあるため、これらのサービスにはこれらのロールを使用する必要があります。 RBAC は、ロールの割り当てを追加することがアクセス許可の一つとして機能する加算型モデルです。 RBAC では、ロールの割り当てよりも優先される拒否割り当てもサポートされます。
ヒント
アクセス制御戦略を計画するときは、ジョブを実行するために必要なアクセス権の量のみをユーザーに付与することをお勧めします。 また、特定のスコープでのみ特定のアクションを許可する必要があります。
Azure データベースでのアクセス制御
Azure データベースの RBAC は、ロール、スコープ、アクセス許可を中心に展開されています。 Azure には、データベース管理用の組み込みロールがいくつか用意されています。 これらのロールの 1 つは SQL Server 共同作成者であり、SQL サーバーとデータベースの管理を可能にします。 もう 1 つのロールは SQL DB 共同作成者です。SQL データベースの管理は許可されますが、サーバー自体の管理は許可されません。 さらに、固有の要件を満たす特定のアクセス許可を持つカスタム ロールを作成できます。
次のようなさまざまなスコープでロールを割り当てることができます。
- サブスクリプション レベルで、ロールがサブスクリプション内のすべてのリソースに適用されます。
- リソース グループ レベルで、ロールが指定されたリソース グループ内のすべてのリソースに適用されます。
- リソース レベルでは、個々のデータベースまたはサーバーにロールを直接割り当てることができます。 この方法では、正確な制御が提供されます。
アクセス許可は、読み取り、書き込み、削除、セキュリティ設定の管理など、ロールが実行できるアクションを定義します。 これらのアクセス許可は、管理を簡略化するためにロールにグループ化されます。
Azure SQL Database では、ユーザー、グループ、またはアプリケーションにロールを割り当ててアクセスを制御できます。 たとえば、データベース管理者には、サーバーとデータベースを管理するための SQL Server 共同作成者 ロールが割り当てられている場合があります。 SQL DB 共同作成者などのロールを使用すると、ユーザーはデータベースを作成、更新、削除できます。一方、SQL Security Manager ロールはセキュリティ構成に重点を置いています。
Azure Cosmos DB では、ロールを割り当てて、Azure Cosmos DB アカウント、データベース、コンテナーへのアクセスを管理できます。 Cosmos DB アカウント閲覧者や Cosmos DB アカウント共同作成者などの組み込みロールは、さまざまなレベルのアクセスを提供します。
Azure Database for MySQL と Azure Database for PostgreSQL では、ロールを割り当ててデータベース サーバーと個々のデータベースを管理できます。 共同作成者や閲覧者などのロールを使用してアクセスを制御できます。
詳細については、データベースの Azure 組み込みロールに関するページを参照してください。
Data Lake Storage でのアクセス制御
Azure RBAC を使用すると、すべてのストレージ アカウント データへの読み取りアクセスや書き込みアクセスなど、粒度の粗いアクセス権を付与できます。 ACL を使用すると、特定のディレクトリやファイルへの書き込みアクセスなど、きめ細かいアクセス権を付与できます。
多くのシナリオでは、RBAC と ACL を一緒に使用して、Data Lake Storage で包括的なアクセス制御を提供できます。 RBAC を使用してデータへの高レベルのアクセスを管理できます。これにより、承認されたユーザーのみがサービスにアクセスできるようになります。 その後、ストレージ アカウント内に ACL を適用して、特定のファイルとディレクトリへのアクセスを制御できるため、セキュリティが向上します。
Azure 属性ベースのアクセス制御は、特定のアクションのコンテキストで属性に基づいてロールの割り当て条件を追加することで、Azure RBAC 上に構築されます。 基本的に、条件を追加して RBAC ロールの割り当てを調整できます。 たとえば、特定のタグを持つ、ストレージ アカウント内のすべてのデータ オブジェクトへの読み取りまたは書き込みアクセス権を付与できます。
次のロールでは、セキュリティ プリンシパルがストレージ アカウント内のデータにアクセスすることが許可されます。
| 役割 | 説明 |
|---|---|
| ストレージ BLOB データ所有者 | このロールは、BLOB ストレージのコンテナーとデータへのフル アクセスを提供します。 このアクセスにより、セキュリティ プリンシパルはアイテムの所有者を設定し、すべてのアイテムの ACL を変更できます。 |
| ストレージ BLOB データ共同作成者 | このロールは、BLOB ストレージ コンテナーと BLOB への読み取り、書き込み、削除のアクセスを提供します。 このアクセスでは、セキュリティ プリンシパルがアイテムの所有権を設定することは許可されませんが、セキュリティ プリンシパルが所有する項目の ACL を変更できます。 |
| ストレージ BLOB データ閲覧者 | このロールは、BLOB ストレージのコンテナーと BLOB の読み取りと一覧表示を行うことができます。 |
所有者、共同作成者、閲覧者、ストレージ アカウント共同作成者などのロールでは、セキュリティ プリンシパルがストレージ アカウントを管理できますが、そのアカウント内のデータへのアクセスは提供されません。 ただし、 閲覧者を除くこれらのロールは、ストレージ キーへのアクセスを取得できます。ストレージ キーは、さまざまなクライアント ツールでデータにアクセスするために使用できます。 詳細については、「Data Lake Storageでのアクセス制御モデルの
Azure Databricks でのアクセス制御
Azure Databricks には、Azure Databricks 環境内でアクセスを管理するためのアクセス制御システムが用意されています。 これらのシステムは、セキュリティ保護可能なオブジェクトとデータ ガバナンスに焦点を当てています。 Azure Databricks 内の 3 つの主要なアクセス制御システムは次のとおりです。
- ACL。ノートブックなどのワークスペース オブジェクトにアクセスするためのアクセス許可を構成するために使用できます。 詳しくは、「アクセス制御の概要」をご覧ください。
- アカウント RBAC。サービス プリンシパルやグループなどのアカウント レベルのオブジェクトを使用するアクセス許可を構成するために使用できます。
- Unity カタログ。データ オブジェクトのセキュリティ保護と管理に使用できます。
Azure Databricks では、オブジェクトに対するアクセス制御に加えて、プラットフォームに組み込みのロールが用意されています。 ユーザー、サービス プリンシパル、およびグループにロールを割り当てることができます。 詳細については、「 管理者ロールとワークスペースの権利」を参照してください。
クラウド規模の分析での承認に関するベスト プラクティス
このガイドでは、クラウド規模の分析環境で RBAC を実装するためのベスト プラクティスについて説明します。 これには、セキュリティで保護された効率的なリソース管理を確保するために役立つ、一般的な RBAC 原則、データベース アクセス制御、および Data Lake アクセス制御のベスト プラクティスが含まれています。
クラウド規模の分析に関する一般的な RBAC のベスト プラクティス
次のベスト プラクティスは、RBAC の使用を開始するのに役立ちます。
サービスの管理と操作には RBAC ロールを使用し、データ アクセスとワークロード固有のタスクにはサービス固有のロールを使用します。 Azure リソースの RBAC ロールを使用して、リソース管理タスクと運用タスクを実行する必要があるセキュリティ プリンシパルにアクセス許可を付与します。 ストレージ内のデータにアクセスする必要があるセキュリティ プリンシパルでは、リソースを管理する必要がないため、リソースに対する RBAC ロールは必要ありません。 代わりに、データ オブジェクトに直接アクセス許可を付与します。 たとえば、Data Lake Storage 内のフォルダーへの読み取りアクセス権を付与したり、SQL Database のデータベースに対する包含データベース ユーザーとテーブルのアクセス許可を付与したりできます。
組み込みの RBAC ロールを使用します。 まず、組み込みの RBAC Azure リソース ロールを使用してサービスを管理し、操作ロールを割り当ててアクセスを制御します。 組み込みロールが特定のニーズを満たしていない場合にのみ、Azure リソースのカスタム ロールを作成して使用します。
グループを使用してアクセスを管理します。 Microsoft Entra グループへのアクセスを割り当て、継続的なアクセス管理のためにグループ メンバーシップを管理します。
サブスクリプションとリソース グループのスコープを検討してください。 非運用環境では、個々のリソースへのアクセスを許可するのではなく、リソース グループ スコープで個別のサービス管理と操作アクセスのニーズにアクセス権を付与します。 非運用環境では、開発者とテスト担当者がリソースを管理する必要があるため、この方法は理にかなっています。 たとえば、Azure Data Factory インジェスト パイプラインまたは Data Lake Storage 内のコンテナーを作成する必要がある場合があります。
ただし、運用環境では、Data Lake ファイル システムのサポートや操作などのワークロード固有のタスクに対して、個々のリソースへのアクセス権を付与できます。 この方法は、スケジュールされた Data Factory インジェスト パイプラインの状態の表示や Data Lake Storage でのデータ ファイルの読み取りなどのリソースのみを使用する必要があるため、運用環境では理にかなっています。
サブスクリプション スコープで不要なアクセス権を付与しないでください。 サブスクリプション スコープは、サブスクリプション内のすべてのリソースを対象とします。
最小特権アクセスを選択します。 ジョブに適した唯一のロールを選択します。
データベース アクセス制御のベスト プラクティス
効果的な RBAC の実装は、分析環境でセキュリティと管理容易性を維持するために重要です。 このセクションでは、Microsoft Entra グループと組み込みロールを使用するためのベスト プラクティスと、合理化された安全なアクセス管理プロセスを確保するために役立つ直接ユーザーアクセス許可を回避するためのベスト プラクティスについて説明します。
クラウド規模の分析環境には、通常、PostgreSQL、MySQL、SQL Database、Azure SQL Managed Instance など、複数の種類のストレージ ソリューションが含まれます。
個々のユーザー アカウントの代わりに Microsoft Entra グループを使用します。 個々の Microsoft Entra ユーザー アカウントではなく、Microsoft Entra グループを使用してデータベース オブジェクトをセキュリティで保護することをお勧めします。 Microsoft Entra グループを使用してユーザーを認証し、データベース オブジェクトを保護します。 Data Lake パターンと同様に、データ アプリケーションのオンボードを使用してこれらのグループを作成できます。
組み込みロールを使用してアクセスを管理します。 カスタム ロールを作成するのは、特定の要件を満たす必要がある場合、または組み込みロールで許可されるアクセス許可が多すぎる場合のみです。
個々のユーザーにアクセス許可を割り当てないようにします。 代わりに、データベースロールやサーバーロールなどのロールを一貫して使用してください。 ロールは、レポートとトラブルシューティングのアクセス許可に役立ちます。 Azure RBAC では、ロールを使用したアクセス許可の割り当てのみがサポートされます。
Data Lake Storage のアクセス制御のベスト プラクティス
最新のデータ環境では、セキュリティで保護された効率的なアクセス制御が最も重要です。 Data Lake Storage には、ACL を介してアクセスを管理するための堅牢なメカニズムが用意されています。 このセクションでは、Data Lake Storage に RBAC を実装し、ACL、Microsoft Entra セキュリティ グループ、およびより安全で管理しやすい Data Lake 環境を維持するための最小特権の原則を適用するためのベスト プラクティスについて説明します。 さらに、ACL をデータパーティション分割スキームに合わせ、Azure Databricks ユーザー向けの Unity カタログを使用して包括的なセキュリティとガバナンスを確保することの重要性を強調しています。
ACL を使用して、きめ細かいアクセス制御を行います。 ACL は、詳細なレベルでアクセスを定義する上で重要な役割を果たします。 Data Lake Storage では、ACL はセキュリティ プリンシパルと連携して、ファイルとディレクトリへのきめ細かいアクセスを管理します。
ファイル レベルとフォルダー レベルで ACL を適用します。 データ レイク内のデータへのアクセスを制御するには、ファイルとフォルダーのレベルで ACL を使用することをお勧めします。 Data Lake Storage には、ポータブル オペレーティング システム インターフェイス (POSIX) に似た ACL モデルも採用されています。 POSIX は、オペレーティング システムの標準のグループです。 1 つの標準では、ファイルやフォルダーにアクセスするためのシンプルで強力なアクセス許可構造が定義されています。 POSIX は、ネットワーク ファイル共有と Unix コンピューターに広く使用されています。
ACL エントリで割り当てられたプリンシパルとして Microsoft Entra セキュリティ グループを使用します。 個々のユーザーまたはサービス プリンシパルを直接割り当てる代わりに、このアプローチを使用して、ディレクトリ構造全体に ACL を再適用する必要なく、ユーザーまたはサービス プリンシパルを追加および削除します。 適切な Microsoft Entra セキュリティ グループに対してユーザーとサービス プリンシパルを追加または削除するだけです。
Microsoft Entra グループへのアクセスを割り当て、継続的なアクセス管理のためにグループのメンバーシップを管理します。 詳細については、「Data Lake Storageでのアクセス制御モデルの
」を参照してください。 ACL に最小特権の原則を適用します。 ほとんどの場合、ユーザーはデータ レイクで必要なファイルとフォルダーに対する 読み取 りアクセス許可のみを持つ必要があります。 データ ユーザーがストレージ アカウント コンテナーにアクセスできないようにする必要があります。
ACL をデータ パーティション分割スキームに合わせます。 ACL とデータ パーティションの設計は、効果的なデータ アクセス制御を確保するために調整する必要があります。 詳細については、「 Data Lake のパーティション分割」を参照してください。
Azure Databricks ユーザーの場合は、Unity カタログを使用してデータ オブジェクトへのアクセスを排他的に制御します。 Data Lake Storage の外部ロケーション ストレージに直接ストレージ レベルのアクセス権を付与しても、Unity カタログによって管理されるアクセス許可や監査は受け付けられません。 直接アクセスでは、監査、系列、およびアクセス制御やアクセス許可など、Unity カタログのその他のセキュリティおよび監視機能がバイパスされます。 そのため、Azure Databricks ユーザーに Unity カタログのマネージド テーブルとボリュームへの直接ストレージ レベルのアクセス権を付与しないでください。