ID およびアクセス管理
この記事では、ID とアクセスの管理に関する設計上の考慮事項と推奨事項について説明します。 Microsoft Azure 上のクラウド規模の分析プラットフォームのデプロイに焦点を当てます。 クラウド規模の分析はミッション クリティカルなコンポーネントであるため、ソリューションを設計するときは、Azure ランディング ゾーンの設計領域に関するガイダンスに従う必要があります。
この記事は、Azure ランディング ゾーンに関する考慮事項と推奨事項に基づいています。 詳細については、「ID およびアクセス管理の設計領域 を参照してください。
データ ランディング ゾーンの設計
クラウド規模の分析では、Microsoft Entra ID を使用したアクセス制御モデルがサポートされています。 このモデルでは、Azure ロールベースのアクセス制御 (Azure RBAC) とアクセス制御リストが使用されます。
チームが実行する Azure の管理および管理アクティビティを確認します。 Azure でクラウド規模の分析を評価します。 組織内での最適な責任配分を決定します。
ロールの割り当て
データ プラットフォーム内でデータ製品を自律的に開発、提供、提供するには、データ アプリケーション チームが Azure 環境内で複数のアクセス権を必要とします。 開発環境と上位環境では、異なるアクセス モデルを使用する必要があることに注意してください。 可能な場合はセキュリティ グループを使用して、ロールの割り当ての数を減らし、RBAC 権限の管理とレビュープロセスを簡略化します。 この手順は、サブスクリプション ごとに作成できるロールの割り当ての数が限られているため、非常に重要です。
開発環境は、開発チームとそれぞれのユーザー ID でアクセスできる必要があります。 このアクセスにより、ユーザーはより迅速に反復処理を行い、Azure サービス内の特定の機能について学習し、問題のトラブルシューティングを効果的に行うことができます。 開発環境へのアクセスは、コードやその他のコード成果物としてのインフラストラクチャの開発や強化に役立ちます。
開発環境で実装が期待どおりに動作することを確認した後、継続的に上位の環境に展開できます。 テストや運用環境などの上位環境は、データ アプリケーション チームのためにロックオフする必要があります。 これらの環境にアクセスできるのは、サービス プリンシパルだけです。 そのため、すべてのデプロイは、継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインを使用して、サービス プリンシパル ID を介して実行する必要があります。 開発環境で、サービス プリンシパルとユーザー ID の両方にアクセス権を付与します。 上位の環境では、サービス プリンシパル ID のみにアクセス権を制限します。
データ アプリケーション リソース グループ内のリソース間でリソースとロールの割り当てを作成するには、Contributor 権限と User Access Administrator 権限を指定する必要があります。 これらの権限により、チームは、Azure Policy の境界内で、環境内のサービスを作成および制御できます。
データ流出のリスクを軽減するために、プライベート エンドポイントを使用することがクラウド分析のベスト プラクティスです。 Azure プラットフォーム チームはポリシーを使用して他の接続オプションをブロックするため、データ アプリケーション チームはデータ ランディング ゾーンの共有仮想ネットワークへのアクセス権を必要とします。 このアクセスは、使用する予定のサービスに必要なネットワーク接続を設定するために不可欠です。
最小限の特権の原則に従うために、異なるデータ アプリケーション チーム間の競合を回避し、チームを明確に分離します。 クラウド規模の分析のベスト プラクティスとして、データ アプリケーション チームごとに専用のサブネットを作成し、そのサブネットまたは子リソース スコープに対する Network Contributor ロールの割り当てを作成します。 このロールの割り当てにより、チームはプライベート エンドポイントを使用してサブネットに参加できます。
これらの最初の 2 つのロールの割り当てにより、これらの環境内でのデータ サービスのセルフサービスデプロイが可能になります。 コスト管理の問題に対処するために、組織はコスト センター タグをリソース グループに追加して、クロス課金と分散コストの所有権を有効にする必要があります。 このアプローチにより、チーム内での認識が高まります。また、必要な SKU とサービス レベルに関する情報に基づいた意思決定を確実に行うことができます。
データ ランディング ゾーン内の他の共有リソースのセルフサービス使用を有効にするには、いくつかの追加のロールの割り当てが必要です。 Azure Databricks 環境へのアクセスが必要な場合、組織は Microsoft Entra ID から SCIM 同期 使用してアクセスを提供する必要があります。 この同期メカニズムは、Microsoft Entra ID から Azure Databricks データ プレーンにユーザーとグループを自動的に同期するため、重要です。 また、個人が組織またはビジネスを離れると、アクセス権も自動的に削除されます。 Azure Databricks では、ワークスペース内でワークロードを実行できるように、データ アプリケーション チームに定義済みのクラスターへのアクセス権を Can Restart 付与します。
個々のチームは、それぞれのデータ ランディング ゾーン内のデータ資産を検出するために、Microsoft Purview アカウントにアクセスする必要があります。 多くの場合、チームは、データ所有者やエキスパートの連絡先情報などの追加情報を提供するために、自分が所有するカタログデータ資産を編集する必要があります。 また、Teams では、データセット内の各列の説明と内容に関するより詳細な情報を提供する機能も必要です。
RBAC 要件の概要
データ ランディング ゾーンのデプロイを自動化するには、次のロールが必要です。
ロール名
説明
スコープ
すべてのデータ サービスのすべてのプライベート 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 ロールにも同じことが当てはまります。
データ製品のロールの割り当て
データランディングゾーン内にデータ製品をデプロイするには、次のロールの割り当てが必要です。
ロール名
説明
スコープ
すべてのデータ サービスのすべてのプライベート DNS ゾーンを 1 つのサブスクリプションとリソース グループにデプロイします。 サービス プリンシパルは、データ管理ランディング ゾーンのデプロイ中に作成されたグローバル DNS リソース グループで Private DNS Zone Contributor の権限を持つ必要があります。 このロールは、それぞれのプライベート エンドポイントの A レコードをデプロイするために必要です。
(リソース グループのスコープ) /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}
すべてのデータ統合ストリーミング サービスを、データ ランディング ゾーン サブスクリプション内の単一のリソース グループにデプロイします。 サービス プリンシパルには、そのリソース グループに対する Contributor ロールの割り当てが必要です。
(リソース グループのスコープ) /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}
データ ランディング ゾーンのデプロイ中に作成された指定された Azure 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 でのクラウドスケール分析の認証」を参照してください。