ID 管理とアクセス管理
この記事では、ID とアクセスの管理に対する設計上の考慮事項と推奨事項について説明します。 Microsoft Azure 上のクラウド規模の分析プラットフォームのデプロイに焦点を当てます。 クラウド規模の分析はミッション クリティカルな要素であるため、Azure ランディング ゾーンの設計領域に関するガイダンスも設計に含める必要があります。
この記事は、Azure ランディング ゾーンに関する考慮事項と推奨事項に基づいています。 詳細については、「ID 管理とアクセス管理」をご覧ください。
データ ランディング ゾーンの設計
クラウド規模の分析では、Microsoft Entra の ID を使用したアクセスの制御モデルがサポートされています。 このモデルでは、ロールベースのアクセス制御 (Azure RBAC) とアクセス制御リスト (ACL) が使用されます。
チームが実行する Azureの運営および管理アクティビティを確認します。 Azure でのクラウド規模の分析について考慮します。 組織内での役割の最適な配分を決定します。
ロールの割り当て
データ プラットフォーム内でデータ製品を自律的に開発、公開、提供するために、データ アプリケーション チームは Azure 環境内でのアクセス権をそれほど必要としません。 それぞれの RBAC 要件を説明する前に、次の点を強調しておく必要があります。それは、開発環境とそれより上位の環境とでは異なるアクセス モデルを使用する必要があるということです。 また、ロールの割り当ての数を減らし、RBAC 権限の管理とレビュー プロセスを簡素化するために、可能な限りセキュリティ グループを使用する必要があります。 これが重要なのは、サブスクリプションごとに作成できるロールの割り当ての数が限られているためです。
開発環境では、開発チームとそれぞれのユーザー ID によるアクセスを許可して、彼らが反復処理をより迅速に行い、Azure サービス内の特定の機能について学習し、問題を効果的にトラブルシューティングできるようにする必要があります。 開発環境へのアクセスは、コードとしてのインフラストラクチャ (IaC) やその他のコード成果物を開発または拡張するときに役立ちます。 開発環境内の実装が期待どおりに動作するようになったら、その実装をより上位の環境に継続的にロールアウトできます。 テスト環境や運用環境などのより上位の環境は、データ アプリケーション チームに対してロックオフされている必要があります。 これらの環境にはサービス プリンシパルのみがアクセスできるようにする必要があるため、すべてのデプロイは、CI/CD パイプラインを使用し、サービス プリンシパル ID を介して実行される必要があります。 要約すると、開発環境ではサービス プリンシパルとユーザー ID にアクセス権を提供する必要があり、より上位の環境ではサービス プリンシパル ID にのみアクセス権を提供する必要があります。
データ アプリケーション リソース グループ内のリソース間でリソースとロールの割り当てを作成できるようにするには、Contributor および User Access Administrator の権限を指定する必要があります。 これにより、チームは Azure Policy の境界内で、その環境内のサービスを作成および制御できるようになります。 クラウド規模の分析では、データ流出リスクを克服するためにプライベート エンドポイントを使用することをお勧めします。また、他の接続オプションはポリシーを使用して Azure プラットフォーム チームによってブロックされる必要があるため、データ アプリケーション チームには、使用する予定のサービスに必要なネットワーク接続を正常に設定できるようにするため、データ ランディング ゾーンの共有仮想ネットワークへのアクセス権が必要になります。 最小限の特権の原則に従い、さまざまなデータ アプリケーション チーム間の競合を克服し、チームを明確に分離するため、クラウド規模の分析では、データ アプリケーション チームごとに専用のサブネットを作成し、そのサブネット (子リソース スコープ) に対して Network Contributor ロールの割り当てを作成することが提案されています。 このロールの割り当てにより、チームはプライベート エンドポイントを使用してサブネットに参加できます。
これら 2 つの最初のロールの割り当てを使用することにより、これらの環境内でデータ サービスのセルフサービス デプロイを実現できます。 コスト管理の問題に対処するために、組織はリソース グループにコスト センター タグを追加して、クロスチャージと分散コストの所有権を有効にする必要があります。 そうすることで、チーム内の認識が高まり、必要な SKU とサービス レベルに関して適切な決定をするように促すことができます。
データ ランディング ゾーン内の他の共有リソースのセルフサービス使用も有効にするには、追加のロールの割り当てはほとんど必要ありません。 Databricks 環境へのアクセスが必要な場合、組織は Microsoft Entra ID から SCIM Synch を使用してアクセスを提供する必要があります。 これが重要なのは、このメカニズムは、Microsoft Entra ID から Databricks データ プレーンにユーザーとグループを自動的に同期し、個人が組織やビジネスを離れると自動的にアクセス権を削除するためです。 個別のユーザー アカウントが Azure Databricks で使用されていると、このようにはできません。 データ アプリケーション チームは、Databricks ワークスペースに shared-product-rg と shared-integration-rg で追加される必要があります。 Azure Databricks 内では、データ アプリケーション チームに定義済みのクラスターへの Can Restart アクセス権を付与して、そのワークスペース内でワークロードを実行できるようにする必要があります。
個々のチームには、それぞれのデータ ランディング ゾーン内のデータ資産を検出するために、中央の Purview アカウントへのアクセス権が必要になります。 したがって、チームは Purview の最上位コレクションに Data Reader として追加される必要があります。 ほとんどの場合、チームでは、データ所有者とエキスパートの連絡先の詳細に加えて、データセット内の列が何を説明するもので、それらの列にどんな情報が含まれているかに関するより詳細な情報を提供するために、所有しているカタログ化されたデータ資産を編集するオプションも必要になります。
ロールベースのアクセス制御要件の概要
データ ランディング ゾーンをデプロイする自動化の目的のため、次のロールが必要です。
ロール名
説明
Scope
すべてのデータ サービスのすべてのプライベート DNS ゾーンを 1 つのサブスクリプションとリソース グループにデプロイします。 サービス プリンシパルは、データ管理ランディング ゾーンのデプロイ中に作成されたグローバル DNS リソース グループ上の Private DNS Zone Contributor である必要があります。 このロールは、プライベート エンドポイントの A レコードをデプロイするために必要です。
(リソース グループのスコープ) /subscriptions/{{dataManagement}subscriptionId}/resourceGroups/{resourceGroupName}
データ ランディング ゾーン ネットワークとデータ管理ランディング ゾーン ネットワークの間に仮想ネットワーク ピアリングを設定するには、サービス プリンシパルに、リモート仮想ネットワークのリソース グループに対する Network Contributor アクセス権が必要です。
(リソース グループのスコープ) /subscriptions/{{dataManagement}subscriptionId}/resourceGroups/{resourceGroupName}
このアクセス許可は、integration-rg リソース グループにデプロイされるセルフホステッド統合ランタイムを他のデータ ファクトリと共有するために必要です。 また、各ストレージ アカウント ファイル システムで Azure Data Factory と Azure Synapse Analytics のマネージド ID を割り当てる必要があります。
(リソースのスコープ) /subscriptions/{{dataLandingZone}subscriptionId}
注意
実稼働シナリオでは、ロールの割り当ての数を減らすことができます。 Network Contributor ロールの割り当ては、データ管理ランディング ゾーンとデータ ランディング ゾーンの間の仮想ネットワーク ピアリングを設定するためにのみ必要です。 この点を考慮しないと、DNS 解決は機能しません。 Azure Firewall への見通し線がないため、受信および送信トラフィックが切断されます。
また、プライベート エンドポイントの DNS A レコードのデプロイが、deployIfNotExists 効果が定義された Azure ポリシーを介して自動化されている場合、Private DNS Zone Contributor は必要ありません。 deployIfNotExists ポリシーを使用してデプロイを自動化できるため、User Access Administrator についても同様です。
データ製品のロールの割り当て
データ ランディング ゾーン内にデータ製品をデプロイするには、次のロールの割り当てが必要です。
ロール名
説明
Scope
すべてのデータ サービスのすべてのプライベート DNS ゾーンを 1 つのサブスクリプションとリソース グループにデプロイします。 サービス プリンシパルは、データ管理ランディング ゾーンのデプロイ中に作成されたグローバル DNS リソース グループ上の Private DNS Zone Contributor である必要があります。 このロールは、それぞれのプライベート エンドポイントの A レコードをデプロイするために必要です。
(リソース グループのスコープ) /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}
すべてのデータ統合ストリーミング サービスを、データ ランディング ゾーン サブスクリプション内の 1 つのリソース グループにデプロイします。 サービス プリンシパルには、そのリソース グループで Contributor ロールの割り当てが必要です。
(リソース グループのスコープ) /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}
データ ランディング ゾーンのデプロイ中に作成された指定の Private Link サブネットにプライベート エンドポイントをデプロイするには、サービス プリンシパルで、そのサブネット上での Network Contributor アクセス権が必要です。
(子リソースのスコープ) /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName} /providers/Microsoft.Network/virtualNetworks/{virtualNetworkName}/subnets/{subnetName}"
他のリソースへのアクセス
Azure 外で、データ製品チームとデータ統合チームは、コード成果物を格納し、効果的に共同作業を行い、CI/CD を介してより上位の環境に更新プログラムと変更を一貫してロールアウトするために、リポジトリへのアクセスも必要になります。 さらに、アジャイル開発、スプリント計画、タスクの追跡、ユーザーのフィードバックや機能の要求を可能にするために、プロジェクト ボードを提供する必要もあります。
最後に、CI/CD オートメーションでは Azure への接続を設定する必要があります。この接続は、ほとんどのサービスでサービス プリンシパルを介して行われます。 したがって、チームには、プロジェクト内で自動化を実現するために、サービス プリンシパルへのアクセス権が必要になります。
データへのアクセスの管理
データへのアクセスの管理は、Microsoft Entra グループを使用して行う必要があります。 ユーザー プリンシパル名またはサービス プリンシパル名を Microsoft Entra グループに追加します。 サービスにグループを追加し、そのグループにアクセス許可を付与します。 この方法により、きめ細かなアクセス制御が可能になります。
Azure データ レイク内のデータ製品の場合は、アクセス制御リスト (ACL) の使用をご検討ください。 詳細については、「Azure Data Lake Storage Gen2 のアクセス制御モデル」を参照してください。 アクセス制御リストを使用した Microsoft Entra パススルーの使用は、Azure Machine Learning、Azure Synapse SQL サーバーレス、Apache Spark for Azure Synapse、Azure Databricks など、ネイティブの Azure サービスのほとんどでサポートされています。
その他のポリグロット ストレージは、クラウド規模の分析で使用される可能性があります。 たとえば、Azure Database for PostgreSQL、Azure Database for MySQL、Azure SQL Database、SQL Managed Instance、Azure Synapse SQL 専用プールなどがあります。 これらは、データ アプリケーション チームがデータ製品を格納するために使用できます。
- Azure Database for PostgreSQL での認証に Microsoft Entra ID を使用する
- Azure SQL Database、SQL Managed Instance、Azure Synapse Analytics で Microsoft Entra 認証を使用する
- Azure Database for MySQL での認証に Microsoft Entra ID を使用する
データベース オブジェクトをセキュリティで保護するには、個々の Microsoft Entra ユーザー アカウントではなく、Microsoft Entra グループを使用することをお勧めします。 これらの Microsoft Entra グループは、ユーザーの認証に使用され、データベース オブジェクトの保護に役立ちます。 データ レイク パターンと同様に、ドメインやデータ製品のオンボードを使用して、Microsoft Entra サービス内にこれらのグループを作成できます。
また、この方法により、単一の管理場所が提供され、Azure Graph 内のアクセス権を確認できます。
データ管理ランディング ゾーンとデータ資産を管理するデータ ランディング ゾーンのセキュリティを強化する方法の詳細については、「Azure でのクラウド規模の分析のためのセキュリティのプロビジョニング」を参照してください。