次の方法で共有


Azure でのクラウド規模の分析のためのデータ管理とロールベースのアクセス制御

認可は、認証された利用者に対し、アクションを実行する権限を付与する行為です。 アクセス制御の重要な原則は、ユーザーが自分のジョブを実行するために必要なアクセス権のみをユーザーに付与し、特定のスコープで特定のアクションのみを許可する、ということです。 ロールベースのセキュリティおよびロールベースのアクセス制御 (RBAC) は、アクセス制御に対応しており、多くの組織で、個々のユーザーではなく、定義されたロールまたはジョブの機能に基づいてアクセスを制御するために使用されます。 その場合、ユーザーには 1 つまたは複数のセキュリティ ロールが割り当てられ、それぞれに特定のタスクを実行するための認可されたアクセス許可が付与されます。

一元化された ID プロバイダーとして Microsoft Entra ID を使用する場合、データ サービスとストレージにアクセスするための認可は、Microsoft Entra の ID に基づいて、ユーザーごとまたはアプリケーションごとに付与できます。 認可により、ストレージ内のファイル、フォルダー、またはオブジェクト レベルで、サービスとアクセス制御リストに対する RBAC がカバーされます。

データ サービスの認可

Microsoft Azure に含まれる標準と組み込みの RBAC は、Azure リソースに対する詳細なアクセス管理を提供する Azure Resource Manager 上に構築された認可システムです。 RBAC の役割は、リソースへのアクセス レベル (セキュリティ プリンシパル、ユーザー、グループ、サービス、またはアプリケーションがアクセス権を持つリソースと領域に対してできること) を制御するのに役立ちます。 アクセス制御戦略を計画するときは、ユーザーが自分のジョブを実行するために必要なアクセス権のみを付与し、特定のスコープで特定のアクションのみを許可することをお勧めします。

次の組み込みロールは、Azure データ サービスを含むすべての Azure リソースの種類の基本です。

説明
所有者: このロールは、リソースへのフル アクセス権を持ち、それへのアクセス権を付与する権限など、リソースに関するすべてのものを管理できます。
共同作成者: このロールは、リソースを管理できますが、それへのアクセス権を付与することはできません。
閲覧者: このロールは、リソースとそれに関する情報 (アクセス キーやシークレットなどの機密情報を除く) を表示できますが、リソースを変更することはできません。

ストレージ BLOB データ共同作成者や Data Factory 共同作成者など、一部のサービスには特定の RBAC の役割があり、これらのサービスには特定の RBAC の役割を使用する必要があることを意味します。 RBAC は、ロールの割り当ての追加がアクティブなアクセス許可である加法モデルです。 また、RBAC では "拒否" 割り当てもサポートされ、"ロール" の割り当てより優先されます。

Azure でのクラウド規模の分析に関する RBAC の一般的なプラクティス

次のベスト プラクティスは、RBAC を使い始めるときに役立ちます。

  • サービスの管理と操作には RBAC の役割を使用し、データ アクセスとワークロード固有のタスクにはサービス固有のロールを使用する: Azure リソースでリソース管理と操作のタスクを実行する必要があるセキュリティ プリンシパルにアクセス許可を付与するには、RBAC の役割を使用します。 ストレージ内のデータにアクセスする必要があるセキュリティ プリンシパルの場合は、それを管理する必要がないため、リソースに対する RBAC の役割は必要ありません。 代わりに、データ オブジェクトに対するアクセス許可を直接付与します。 たとえば、Azure Data Lake Storage Gen2 内のフォルダーへの読み取りアクセスや、Azure SQL Database のデータベースに対する包含データベース ユーザーおよびテーブルのアクセス許可を付与します。

  • 組み込みの RBAC の役割を使用する: まず、サービスの管理には Azure 組み込み RBAC のリソース ロールを使用し、アクセスを制御するには操作ロールを割り当てます。 組み込みのロールが特定のニーズを満たしていない場合にのみ、Azure リソースのカスタム ロールを作成して使用します。

  • アクセスの管理にはグループを使用する: Microsoft Entra グループにアクセス権を割り当て、継続的なアクセス管理のためにグループ メンバーシップを管理します。

  • サブスクリプションとリソース グループのスコープ: 個々のリソースへのアクセス権を付与するのではなく、リソース グループのスコープでアクセス権を付与して、サービス管理と操作アクセスのニーズを分離することは理にかなっていますが (特に非運用環境の場合)、データ レイク ファイル システムのサポートと操作のようなワークロード固有のタスクの場合は、代わりに、個々のリソースへのアクセス権を付与することができます (特に運用環境の場合)。 これは、非運用環境では、開発者とテスト担当者が、Azure Data Factory インジェスト パイプラインの作成や、Data Lake Storage Gen2 でのコンテナーの作成などのリソースを管理する必要があるためです。 一方、運用環境では、ユーザーは、スケジュールされた Data Factory インジェスト パイプラインの状態の表示や、Data Lake Storage Gen2 内のデータ ファイルの読み取りなど、リソースを使用することだけが必要です。

  • サブスクリプション スコープで不要なアクセス権を付与しない: このスコープでは、サブスクリプション内のすべてのリソースがカバーされます。

  • 最小特権のアクセスを選択する: ジョブのためだけの権限とロールを選択します。

次の手順

Azure でのクラウド規模の分析のためのセキュリティのプロビジョニング