ランディングゾーンのIDとアクセスの管理

  • [アーティクル]

IDアーキテクチャを特定したら、アプリケーションとプラットフォームのランディングゾーン内のリソースの承認とアクセスを管理する必要があります。 認証された各プリンシパルがアクセスできるリソースとアクセスする必要があるリソース、およびリソースへの不正アクセスのリスクを軽減する方法を検討します。 詳細については、 「電源管理の使用」 を参照してください。

概要

IDおよびアクセス管理の設計領域では、Azureにエンタープライズアクセスモデルを実装し、コントロールプレーンを実装してセキュリティで保護するのに役立つガイダンスを提供します。 サブスクリプションの民主化の設計原則を組み込むと、アプリケーションチームは、プラットフォームチームが設定したポリシーガードレール内で独自のワークロードを管理できます。 このアプローチは、ポリシー主導のガバナンス原則にも従います。

プラットフォームチームは、新しいアプリケーションランディングゾーンまたはサブスクリプションのプロビジョニングを担当します。 アプリケーション所有者のランディングゾーンをプロビジョニングする場合、プラットフォームチームは、アプリケーション所有者が独自のリソースを管理できるように、適切なアクセス制御を使用してランディングゾーンを構成する必要があります。 アプリケーション所有者は、Microsoft Entra ID内でユーザーとグループを作成および管理し、それらのユーザーとグループにロールを割り当てることができる必要があります。 アプリケーション所有者は、独自のリソースへのアクセスを管理し、必要に応じて他のユーザーやグループにアクセスを委任できます。 ランディングゾーンには、アプリケーションの要件に応じて、Microsoft IDプラットフォームサブスクリプションのActive Directory Domain Services (AD DS) またはMicrosoft Entra Domain Servicesへのオプションのネットワーク接続も必要です。

Azureリソースへの管理アクセスを管理するには、Azureロールベースのアクセス制御 (RBAC) を使用します。 ユーザーが1つのアプリケーションの管理者などの狭いスコープでアクセス許可を必要とするか、複数のアプリケーションワークロードにわたるネットワーク管理者などの広いスコープでアクセス許可を必要とするかを検討します。 どちらの場合も、十分なアクセスの原則に従い、ユーザーが通常のアクティビティに必要なロールのみを持つようにします。 必要に応じてカスタムロールとMicrosoft Entra Privileged Identity Management (PIM) を使用して、Just-In-Time (JIT) アクセスを適用します。 プラットフォームチームはIDとアクセスの管理基盤を担当しますが、プラットフォームチームとアプリケーションチームはどちらもサービスの消費者であり、同じ原則に従う必要があります。

IDとアクセスの管理は、ランディングゾーンを別のランディングゾーンから適切に分離し、組織内のワークロードを分離するために重要です。 これは、プラットフォームとアプリケーションの両方のランディングゾーンにとって重要な設計領域です。

組織でサブスクリプション販売プロセスを使用している場合は、アプリケーションランディングゾーンのIDとアクセスの構成の多くを自動化できます。 サブスクリプション販売を実装して、ランディングゾーンの作成を標準化し、アプリケーションチームが独自のリソースを管理できるようにします。

設計上の考慮事項

組織によっては、複数のアプリケーション間でサービスを共有することがあります。 たとえば、複数の独立したアプリケーションによって使用される集中統合サービスが存在する場合があります。 そのシナリオでは、どのサービスが集中管理され、どのサービスがアプリケーション チームに委任されるかを検討し、どこにセキュリティ境界を適用する必要があるかを理解します。 アプリケーション チームに共有サービスへの管理アクセスを与えると、開発者の生産性には役立つ場合がありますが、必要以上のアクセスが提供される可能性があります。

セキュリティ境界を越えないアプリケーション リソースの管理は、アプリケーション チームに委任できます。 セキュリティとコンプライアンスを維持するために必要な他の側面も委任を検討してください。 安全に管理された環境内でユーザーがリソースをプロビジョニングできるようにすると、組織はクラウドのアジャイルな性質を活用し、さらに重要なセキュリティやガバナンスの境界の違反を防ぐことができます。

絵付

重要

クラシックリソースとクラシック管理者は、2024年8月31日に廃止されます。 不要な共同管理者を削除し、Azure RBACを使用してきめ細かなアクセス制御を行います。

Microsoft Entra IDロールとAzure RBACロールの違いを理解します。

  • Microsoft Entra ID ロールは、Microsoft Entra ID などのテナント全体のサービスや、Microsoft Teams、Microsoft Exchange Online、Microsoft Intune などの他の Microsoft サービスに対する管理特権を制御します。

  • Azure RBAC ロールは、仮想マシン、サブスクリプション、リソース グループなどの Azure リソースに対する管理特権を制御します。

  • Azure RBAC所有者ロールとユーザーアクセス管理者ロールは、Azureリソースに対するロールの割り当てを変更できます。 既定では、Microsoft Entraグローバル管理者ロールには、Azureリソースへのアクセスを管理するためのアクセス許可がありません。 それは明示的に有効にする必要があります。 詳細については、「Azure のすべてのサブスクリプションと管理グループを管理する目的でアクセス権限を昇格させる」を参照してください。

次の図は、Microsoft Entra IDロールとAzure RBACロールの関係を示しています。

Diagram showing the relationship between Microsoft Entra ID and Azure RBAC roles.

  • isAssignableToRoleプロパティをtrueに設定すると、ロール割り当て可能なグループを作成し、Microsoft Entraロールをグループに割り当てることができます。 このプロパティが設定されているグループのみが保護されます。 グループのメンバーシップを変更できるロールは、全体管理者、特権ロール管理者、またはグループの所有者のみです。

  • 一部のロールのみが、別の管理者のパスワードまたは多要素認証 (MFA) の設定をリセットできます。 この制限により、承認されていない管理者がより高い特権を持つアカウントの資格情報をリセットして、より多くのアクセス許可を取得することを防ぐことができます。

  • Azure の組み込みロールが組織の特定のニーズを満たさない場合は、独自のカスタム ロールを作成することができます。 組み込みロールと同様に、テナント、管理グループ、サブスクリプション、リソースグループのスコープで、ユーザー、グループ、サービスプリンシパルにカスタムロールを割り当てることができます。 可能な限りAzureの組み込みロールを使用し、必要な場合にのみカスタムロールを作成するようにしてください。

  • アクセス制御戦略を設計するときは、ロール、ロールの割り当て、およびカスタムロールのサービス制限を把握しておいてください。

  • 一部のAzure RBACロールでは、属性ベースのアクセス制御 (ABAC) またはロールの割り当て条件がサポートされています。 条件を使用すると、管理者はリソースの属性に基づいてロールを動的に割り当てることができます。 たとえば、ストレージBLOBデータ共同作成者ロールは、コンテナー内のすべてのBLOBではなく、特定のインデックスタグを持つBLOBに対してのみ割り当てることができます。

設計の推奨事項

一般的な推奨事項

  • プラットフォームサブスクリプション、アプリケーションサブスクリプション、Microsoft Entra IDテナントなど、Azure環境に対する権限を持つユーザーに対してMicrosoft Entra多要素認証 (MFA) を適用します。 多くのコンプライアンスフレームワークでは、MFAの適用が必要です。 MFAは、資格情報の盗難や不正アクセスのリスクを軽減するのに役立ちます。 機密情報への不正アクセスを防ぐには、閲覧者ロールを持つユーザーをMFAポリシーに含めるようにします。

  • Azure環境に対する権限を持つユーザーに対してMicrosoft Entra条件付きアクセスポリシーを使用します。 条件付きアクセスは、制御されたAzure環境を不正アクセスから保護するのに役立つもう1つの機能です。 アプリケーション管理者とプラットフォーム管理者は、ロールのリスクプロファイルを反映した条件付きアクセスポリシーを持つ必要があります。 たとえば、特定の場所または特定のワークステーションからのみ管理アクティビティを実行する必要がある場合があります。 または、Azureリソースへの管理アクセス権を持つユーザーのサインインリスク許容度が、標準のMicrosoft Entra IDユーザーよりも低くなる場合があります。

  • Microsoft Defender for Identityを有効にして、ユーザーIDを保護し、ユーザー資格情報をセキュリティで保護します。 Defender for Identityは、Microsoft Defender XDRの一部です。 Defender for Identityを使用して、疑わしいユーザーアクティビティを特定し、インシデントのタイムラインを取得することができます。 また、条件付きアクセスと共に使用して、リスクの高い認証の試行を拒否することもできます。 Defender for IdentityセンサーをオンプレミスのドメインコントローラーとAzure idサブスクリプションのドメインコントローラーに展開します。

  • Microsoft Sentinelを使用して、脅威インテリジェンスと調査機能を提供します。 Sentinelは、Azure Monitor Logs 、Microsoft Entra ID、Microsoft 365、およびその他のサービスからのログを使用して、プロアクティブな脅威の検出、調査、対応を提供します。

  • 管理アクセスを、Web閲覧や電子メールアクセスなどの非管理的な日常的なアクセスから分離します。 Webと電子メールは、一般的な攻撃ベクターです。 ユーザーアカウントが侵害された場合、そのアカウントが管理アクセスに使用されていなければ、セキュリティ侵害が発生する可能性は低くなります。

    • 特権ロールには、個別のクラウド専用アカウントを使用します。 特権管理と同じアカウントを日常的に使用しないでください。 特権を持つMicrosoft Entra IDロールとAzure RBACロールは、Azure portalとドキュメントでPRIVILEGEDとしてマークされます。

    • Azureアプリケーションリソースを管理できる特権のないジョブ機能ロールについては、別の管理アカウントが必要か、Microsoft Entra PIMを使用して管理アクセスを制御するかを検討してください。 PIMでは、必要な場合にのみアカウントに必要なアクセス許可が付与され、タスクの完了時にアクセス許可が削除されます (ジャストインタイムアクセスとも呼ばれます)。

  • ロールの割り当てを管理しやすくするには、ユーザーにロールを直接割り当てないでください。 代わりに、グループにロールを割り当てて、サブスクリプションごとに制限があるロールの割り当て数を最小限に抑えます。

    • グループにMicrosoft Entra PIMを使用して、特権ユーザーにジャストインタイムの管理アクセス制御を適用します。 エンタイトルメント管理を使用してグループメンバーシップを制御することを検討してください。 資格管理機能を使用すると、承認および監査のワークフローをグループ メンバーシップの操作に追加し、管理グループ メンバーが不必要に追加または削除されないようにすることができます。
    • リソースへのアクセスを許可するときは、Azure コントロール プレーン リソースに対して Microsoft Entra 専用グループを使用します。 Entra 専用のユーザーとグループ、および Microsoft Entra Connect を使用してオンプレミスから同期されたユーザーとグループの両方を、Entra 専用のグループに追加できます。 グループ管理システムが既に導入されている場合は、オンプレミス グループを Microsoft Entra のみのグループに追加します。 Entra 専用グループを使用すると、オンプレミスのディレクトリ サービスの不正な変更からクラウド コントロール プレーンを保護できます。 Microsoft Entra 専用は、クラウドのみとも呼ばれます。

  • Microsoft Entra ID組織から誤ってロックアウトされないように、緊急アクセスアカウントまたは非常用アカウントを作成します。 緊急アクセス アカウントには高い特権が与えられ、特定の個人にのみ割り当てられます。 アカウントの資格情報を安全に保存し、その使用を監視し、定期的にテストして、障害が発生した場合に使用できるようにします。

    詳細については、 「Microsoft Entra IDの管理者向けのセキュリティで保護されたアクセスプラクティス」 を参照してください。

Microsoft Entra IDの推奨事項

  • Microsoft Entra ID を Azure Monitor と統合すると、サインイン アクティビティとテナント内の変更の監査証跡を分析できるようになります。 管理サブスクリプションのプラットフォーム中央の Azure Monitor Logs ワークスペースにサインインログと監査ログを送信するように診断設定を構成します。

  • Microsoft Entra ID Governanceのエンタイトルメント管理機能を使用して、特権グループメンバーの自動承認プロセスと定期的なアクセスレビューによってグループメンバーシップを制御するアクセスパッケージを作成します。

  • Microsoft Entraの組み込みロールを使用して、テナントレベルから次のID設定を管理します。

    ロール 説明 メモ
    グローバル管理者 Microsoft Entra IDとMicrosoft Entra IDを使用するMicrosoftサービスのすべての側面を管理します。 このロールには 5 人を超えるユーザーを割り当てないでください。
    ハイブリッド ID の管理者 Active DirectoryからMicrosoft Entra IDへのクラウドプロビジョニングを管理し、Microsoft Entra Connect、Microsoft Entraパススルー認証、Microsoft Entraパスワードハッシュ同期、Microsoft Entraシームレスシングルサインオン (SSO) 、フェデレーション設定も管理します。
    セキュリティ管理者 セキュリティ情報とレポートを読み取り、Microsoft Entra IDとMicrosoft 365の構成を管理します。
    アプリケーション管理者 アプリ登録とエンタープライズアプリのすべての側面を作成および管理します。 テナント全体の管理者の同意を付与することはできません。

  • 低い特権の役割が実行できるタスクに高い特権の役割を割り当てないでください。 たとえば、ユーザーを管理するには、グローバル管理者ロールではなく、ユーザー管理者ロールを割り当てます。 詳細については、 「Microsoft Entra組み込みロールのアクセス許可」 を参照してください。

  • 管理単位を使用して、テナント内の特定のオブジェクトのみを管理できるように管理者のセットを制限します。 管理単位を使用して、ディレクトリのサブセットの管理を委任できます。 たとえば、より広範な組織内の単一の事業単位にサービスデスクの管理を委任できます。

    管理単位は、セキュリティ境界として別個の Microsoft Entra ID テナントを設ける必要性を排除するのにも役立ちます。これにより、別個のチームが同じ組織内の Microsoft 365 プラットフォームと Azure プラットフォームを管理します。 たとえば、管理単位を使用して、Microsoft Entra IDテナント全体に対する特権を付与せずに、Azureアプリケーションセキュリティプリンシパルの管理をアプリケーションチームに委任できます。

  • 制限された管理単位を使用して、保護を強化します。 指定した特定の管理者セット以外のユーザーが特定のオブジェクトを変更できないようにします。 たとえば、職務分掌ポリシーでは、ユーザー管理者ロールを持つユーザーであっても、特定のユーザーアカウントを変更できないようにするために、この機能を使用する必要がある場合があります。 この制限は、アプリケーションで使用され、管理者であっても変更する必要がないサービスアカウントに役立ちます。 また、プラットフォームまたはランディングゾーンの管理特権を持つユーザーアカウントまたはグループが変更された場合など、特権の昇格を防ぐこともできます。

Azure RBAC に関する推奨事項

  • 管理を簡素化し、構成ミスのリスクを軽減するには、すべてのアプリケーションランディングゾーンでロールとロールの割り当てを標準化します。 たとえば、仮想マシンの管理をユーザーに委任するロールがある場合は、すべてのアプリケーションランディングゾーンで同じロールを使用します。 このアプローチにより、ランディングゾーン間でリソースを移動するプロセスも簡素化されます。

  • 可能な限り、Azure RBAC を使用してリソースへのデータ プレーン アクセスを管理します。 データプレーンエンドポイントの例としては、Azure Key Vault、ストレージアカウント、SQLデータベースなどがあります。

  • Azure Monitor Logs ワークスペースが適切なアクセス許可モデルで構成されていることを確認します。 一元化されたAzure Monitor Logs ワークスペースを使用する場合は、リソースのアクセス許可を使用して、アプリケーションチームが他のチームのログにはアクセスできないようにします。

組み込みのロール

  • 組み込みロールが要件に適しているかどうかを検討してください。 多くの場合、セキュリティグループに複数の組み込みロールを割り当てて、ユーザーに適切なアクセス権を提供できます。 ただし、組み込みロールにユーザーが必要とするアクセス許可を超えるアクセス許可が含まれている可能性があるため、組み込みロールを使用できず、最小特権アクセスにも準拠できない場合があります。 より細かく制御するには、ジョブ機能の実行に必要な特定のアクセス許可を反映するカスタムロールを作成することを検討してください。 詳細については、 「ロールベースの承認を提供する」 を参照してください。

  • 多くのAzure組み込みロールには、プラットフォームレベルとリソースレベルで定義済みのロール割り当てが用意されています。 複数の役割の割り当てを組み合わせる場合は、全体的な影響を考慮してください。

  • Azureランディングゾーンアクセラレータには、一般的な管理機能用のカスタムロールがいくつか含まれています。 これらのロールは、Azure組み込みロールと共に使用できます。 次の表では、Azureランディングゾーンアクセラレータのカスタム管理ロールまたは領域について説明します。

    管理ロールまたは領域 説明 アクション セロビオース
    Azureプラットフォーム所有者 (組み込みの所有者ロールなど) 管理グループとサブスクリプションのライフサイクルを管理します *
    サブスクリプションの所有者 サブスクリプション所有者の委任されたロール * Microsoft.Authorization/*/write, Microsoft.Network/vpnGateways/*,
    Microsoft.Network/expressRouteCircuits/*,
    Microsoft.Network/routeTables/write,
    Microsoft.Network/vpnSites/*
    アプリケーション所有者(DevOps、アプリ運用) サブスクリプションスコープでのアプリケーションまたは運用チームの共同作成者ロール * Microsoft.Authorization/*/write, Microsoft.Network/publicIPAddresses/write,
    Microsoft.Network/virtualNetworks/write,
    Microsoft.KeyVault/locations/deletedVaults/purge/action
    ネットワーク管理 (NetOps) 仮想ネットワーク、UDR、NSG、NVA、VPN、Azure ExpressRouteなど、プラットフォーム全体のグローバル接続を管理します */read,
    Microsoft.Network/*,
    Microsoft.Resources/deployments/*,
    Microsoft.Support/*
    セキュリティ操作 (SecOps) Azure資産全体とKey Vaultパージポリシーを水平方向に表示するセキュリティ管理者ロール */read,
    */register/action,
    Microsoft.KeyVault/locations/deletedVaults/purge/action,
    Microsoft.PolicyInsights/*,
    Microsoft.Authorization/policyAssignments/*,
    Microsoft.Authorization/policyDefinitions/*,
    Microsoft.Authorization/policyExemptions/*,
    Microsoft.Authorization/policySetDefinitions/*,
    Microsoft.Insights/alertRules/*,
    Microsoft.Resources/deployments/*,
    Microsoft.Security/*,
    Microsoft.Support/*

    責任モデルによっては、これらのロールにより多くの権限が必要になる場合があります。 たとえば、組織によっては、NetOps ロールで必要とされるのはグローバル接続の管理と構成のみである場合があります。 より一元化されたアプローチが必要な組織では、ハブとそのスポーク間のピアリングの作成など、許可されるアクションを増やして NetOps の役割を強化できます。

役割の割り当てとグループ

  • プラットフォームチームは、アプリケーションランディングゾーンをプロビジョニングするときに、セキュリティグループ、標準ロールの割り当て、ユーザー割り当てマネージドIDなど、必要なすべてのIDおよびアクセス管理オブジェクトが作成されていることを確認する必要があります。

  • サブスクリプションまたはリソースグループのスコープでランディングゾーンのロールの割り当てを作成します。 Azure Policyの割り当ては管理グループのスコープで行われるため、より低いスコープでランディングゾーンのロールの割り当てをプロビジョニングする必要があります。 このアプローチを使用して、ランディングゾーン管理者がリソースに対して完全な自律性を持ち、ランディングゾーンを制御するAzure Policyの割り当てを変更できないようにします。

  • 各アプリケーションのランディングゾーンには、独自のグループとロールの割り当てが必要です。 汎用グループを作成して複数のランディングゾーンに割り当てないでください。 このアプローチは、構成ミスやセキュリティ侵害につながる可能性があり、大規模な管理が困難です。 1人のユーザーが複数のランディングゾーンへのアクセスを必要とする場合は、各ランディングゾーンの適切なグループに割り当てます。 IDガバナンスを使用して、グループメンバーシップを管理します。

  • ユーザーではなくグループにロールを割り当てます。 このアプローチは、ユーザーが組織に参加または脱退するときに適切なアクセス許可を持っていることを確認するのに役立ちます。 また、ユーザーがチーム間を移動するときに適切なアクセス許可を持っていることを確認するのにも役立ちます。 たとえば、ユーザーがネットワークチームからセキュリティチームに移動する場合は、そのユーザーをネットワークグループから削除し、セキュリティグループに追加する必要があります。 ロールをユーザーに直接割り当てた場合、ユーザーは別のチームに移動した後もロールを保持します。 グループメンバーを手動で追加および削除するのではなく、IDガバナンスを使用してグループメンバーシップを管理します。

  • 開発/テストと運用など、同じアプリケーションの異なる環境に対して個別のセキュリティ構成を維持します。 環境ごとに個別のグループとロールの割り当てを作成します。 マネージドIDまたはサービスプリンシパルを環境間で共有しないでください。 各環境を個別のランディングゾーンとして扱います。 このアプローチは、開発/テストと運用の間の分離を確保し、環境間でアプリケーションのデプロイを移動するプロセスを標準化するのに役立ちます。 同じユーザーが複数のランディングゾーンへのアクセスを必要とする場合は、各ランディングゾーンの適切なグループに割り当てる必要があります。

  • プラットフォーム管理者がアプリケーションのランディングゾーンに対するアクセス許可を必要とするかどうかを検討します。 必要な場合は、Microsoft Entra PIMを使用してそれらのリソースへのアクセスを制御し、必要な最小限の特権のアクセス許可を割り当てます。 たとえば、プラットフォーム管理者は、問題のトラブルシューティングを行うために特定のアプリケーションのランディングゾーンへのアクセスを必要とする場合がありますが、アプリケーションのデータやコードへの日常的なアクセスは必要ありません。 この場合、プラットフォーム管理者はアプリケーションへのアクセスを要求できます。 特権ロール管理者が要求を承認すると、プラットフォーム管理者には指定された期間、必要なアクセス許可が付与されます。 このアプローチは、職務の分離を強制し、偶発的または悪意のある構成ミスからアプリケーションのランディングゾーンを保護するのに役立ちます。

  • アプリケーションチームなどの他のユーザーに管理責任を委任する場合は、特権の完全なセットが必要なのか、一部のみが必要なのかを検討してください。 最小限の特権の原則に従います。 たとえば、Azureリソースへのアクセスを管理する必要があるが、リソース自体は管理しないユーザーに、ユーザーアクセス管理者ロールまたはRBAC管理者ロールを割り当てることができます。 Azure RBAC割り当てを委任して割り当てることができるID、IDの種類、ロールを制限するには、条件付きの委任されたロール割り当てを使用します。 条件を使用すると、アプリケーションチームは、プラットフォームチームが設定した制約内で独自のセキュリティプリンシパルを管理できます。 特権ロールの割り当てを増やすには、プラットフォームチームへのエスカレーションが必要です。

  • 次の表は、Azureランディングゾーン環境のロール割り当て構造の例を示しています。 セキュリティと管理のしやすさのバランスが取れています。 組織の要件に合わせて構造を調整できます。 組織内の役割に応じて、同じ個人を複数のグループに割り当てることができます。 ただし、RBAC割り当ては、特定のランディングゾーン内の特定のグループに適用する必要があります。

    リソース User ロール割り当て 割り当て先 鉄板焼き料理文化が
    アプリケーションXランディングゾーン アプリケーションX 所有者 アプリケーション所有者 (カスタム、Azure ランディング ゾーン アクセラレータに含まれる) Application X Admins セキュリティグループ アプリケーションXの運用および開発/テストサブスクリプション
    アプリケーションXランディングゾーン アプリケーションX 所有者 アプリケーションアクセス管理者(独自のアプリケーションへのアクセスを管理するロール割り当て条件を使用したカスタム) Application X Admins セキュリティグループ アプリケーションXの運用および開発/テストサブスクリプション
    アプリケーションXランディングゾーン アプリケーションXデータ管理者 データ管理者(カスタム、必要なデータリソースに対するアクセス許可) Application X Data Team セキュリティグループ アプリケーションXの運用および開発/テストサブスクリプション
    アプリケーションYランディングゾーン アプリケーションY owners アプリケーション所有者 (カスタム、Azure ランディング ゾーン アクセラレータに含まれる) Application Y Admins セキュリティグループ アプリケーションY実稼働および開発/テストのサブスクリプション
    アプリケーションYランディングゾーン アプリケーションYのテストチーム テスト共同作成者(カスタム、アプリケーションのテストに必要な権限) Application Y Test Team セキュリティグループ アプリケーションY開発/テストサブスクリプション
    サンドボックス アプリケーションZ開発チーム 所有者 (組み込み) Application Z developers セキュリティグループ サンドボックスサブスクリプションのアプリケーションZリソースグループ
    プラットフォームリソース プラットフォーム管理チーム 共同作成者 (組み込み) Platform AdminsPIM グループ Platform 管理グループ
    プラットフォームランディングゾーン プラットフォーム管理チーム 閲覧者 (組み込み) Platform Team セキュリティグループ 組織の最上位レベルの管理グループ
    テナント全体 セキュリティ チーム セキュリティ操作(カスタム、Azureランディングゾーンアクセラレータに含まれます) Security Ops セキュリティグループ 組織の最上位レベルの管理グループ
    テナント全体 セキュリティ チーム Conditional Access Administrator (組み込み、保護されたアクションが有効) Security administrators セキュリティグループ Microsoft Entra ID テナント
    テナント全体 ネットワーク チーム ネットワーク操作(カスタム (Azureランディングゾーンアクセラレータに含まれる)) Network Ops セキュリティグループ すべてのサブスクリプション
    テナント全体 FinOpsチーム 課金リーダー (組み込み) FinOps Team セキュリティグループ 組織の最上位レベルの管理グループ

  • DeployIfNotExists効果のあるAzure Policyの割り当てには、準拠していないリソースを修復するためのマネージドIDが必要です。 Azure Policyの割り当てプロセスの一部としてシステム割り当てマネージドIDを使用する場合、必要なアクセス許可がAzureによって自動的に付与されます。 ユーザー割り当てマネージドIDを使用する場合は、アクセス許可を手動で付与する必要があります。 マネージドIDロールの割り当ては、最小限の特権の原則に従う必要があり、ターゲットスコープでポリシー修復を実行するために必要なアクセス許可のみを許可する必要があります。 ポリシー修復マネージドIDでは、カスタムロールの定義はサポートされていません。 グループではなく、マネージドIDにロールの割り当てを直接適用します。

Microsoft Entra PIMの推奨事項

  • Microsoft Entra PIMを使用して、0 Trustモデルと最小特権アクセスに準拠します。 組織の役割を必要な最小限のアクセス レベルに関連付けます。 Microsoft Entra PIMでは、Azureネイティブツールを使用したり、既存のツールとプロセスを拡張したり、必要に応じて既存のツールとネイティブツールの両方を使用したりできます。

  • Microsoft Entra PIMアクセスレビューを使用して、リソースの権利を定期的に検証します。 アクセス レビューは、多くのコンプライアンス フレームワークの一部であるため、多くの組織では、アクセス レビュー プロセスが既に配置されています。

  • 特権IDは、昇格されたアクセス許可を必要とするAutomation Runbookまたは特権デプロイパイプラインに使用します。 同等の特権を持つユーザーを管理するために使用するのと同じツールとポリシーを使用して、重要なセキュリティ境界にアクセスする自動化されたワークフローを管理できます。 アプリケーションチームのAutomationパイプラインとデプロイパイプラインには、アプリケーション所有者が自身の特権をエスカレートできないようにするロールを割り当てる必要があります。

  • サブスクリプションまたは管理グループのプラットフォームまたはアプリケーションランディングゾーンチームメンバーに割り当てられている所有者やユーザーアクセス管理者など、高い特権を持つAzure RBACロールを制御します。 グループにMicrosoft Entra PIMを使用してAzure RBACロールを構成し、Microsoft Entra IDロールと同じ昇格プロセスが必要になるようにします。

    たとえば、ユーザーがアプリケーションランディングゾーン内のリソースへの制限付き管理アクセスを日常的に必要とする場合があります。 場合によっては、所有者ロールが必要になることがあります。 2 つのセキュリティ グループを作成できます。アプリケーション管理者とアプリケーション所有者。 最小特権ロールをアプリケーション管理者グループに割り当て、所有者ロールをアプリケーション所有者ロールに割り当てます。 PIMグループを使用して、ユーザーが必要に応じて所有者ロールを要求できるようにします。 それ以外の場合、ユーザーは通常のアクティビティを実行するために必要なアクセス許可のみを持ちます。

  • Microsoft Entra PIMで保護されたアクションを使用して、保護レイヤーを追加します。 Microsoft Entra IDでは、保護されたアクションは、条件付きアクセスポリシーが割り当てられたアクセス許可です。 ユーザーが保護されたアクションを実行しようとすると、まず、必要なアクセス許可に割り当てられている条件付きアクセスポリシーを満たす必要があります。 たとえば、管理者がテナント間のアクセス設定を更新できるようにするには、まずフィッシング対策MFAポリシーを満たすように要求できます。

Azure ランディング ゾーン アクセラレータでの ID とアクセスの管理

IDとアクセス管理は、Azureランディングゾーンアクセラレータ実装の主要な機能です。 デプロイにはID専用のサブスクリプションが含まれ、組織はAD DSドメインコントローラーや、環境に必要なMicrosoft Entra Connectサーバーなどの他のIDサービスをデプロイできます。 すべての組織がサブスクリプションのサービスを必要とするわけではありません。 たとえば、一部の組織には、既にMicrosoft Entra IDと完全に統合されているアプリケーションがある場合があります。

IDサブスクリプションには、プラットフォームサブスクリプションのハブ仮想ネットワークにピアリングされた仮想ネットワークがあります。 この構成では、プラットフォームチームがIDサブスクリプションを管理でき、アプリケーション所有者は必要に応じてIDサービスにアクセスできます。 IDサービスを不正アクセスから保護するには、IDサブスクリプションと仮想ネットワークをセキュリティで保護する必要があります。

Azureランディングゾーンアクセラレータの実装には、次のオプションも含まれます。

  • ID およびドメイン コントローラーを管理するために推奨されるポリシーを割り当てます。
  • 仮想ネットワークを作成し、仮想ネットワーク ピアリングを使用してハブに接続します。

次のステップ

アプリケーションIDとアクセス管理