すべての分離アーキテクチャに関するベスト プラクティス
すべての分離構成に関する設計上の考慮事項を次に示します。 このコンテンツの全体を通して、多くのリンクがあります。 ここでは内容を複製するのではなく、コンテンツにリンクするようにしているため、常に最新の情報にアクセスできます。
Microsoft Entra テナント (分離されているかどうかにかかわらず) を構成する方法に関する一般的なガイダンスについては、Microsoft Entra 機能のデプロイ ガイドを参照してください。
Note
すべての分離されたテナントで、明確でかつ差別化されたブランド化を使用して、間違ったテナントでの作業の人的エラーの回避に役立てることをお勧めします。
分離セキュリティの原則
分離された環境を設計する場合は、次の原則を考慮することが重要です。
先進認証のみを使用する - 分離された環境にデプロイされたアプリケーションでは、フェデレーション、Microsoft Entra B2B コラボレーション、委任、同意フレームワークなどの機能を使用するために、要求ベースの先進認証 (SAML、* 認証、OAuth2、OpenID Connect など) を使用する必要があります。 これにより、NT LAN Manager (NTLM) などのレガシ認証方法に依存するレガシ アプリケーションが分離された環境に引き継がれなくなります。
強力な認証を適用する - 分離された環境サービスやインフラストラクチャにアクセスするときは、常に、強力な認証を使用する必要があります。 可能な場合は常に、パスワードレス認証 (Windows Hello for Business や FIDO2 セキュリティ キーなど) を使用する必要があります。
セキュリティで保護されたワークステーションをデプロイする - セキュリティで保護されたワークステーションには、プラットフォームとそのプラットフォームが表す ID が適切に証明され、悪用から保護されることを保証するためのメカニズムが用意されています。 考慮すべきその他の 2 つのアプローチは次のとおりです。
Microsoft Graph API で Windows 365 クラウド PC (クラウド PC) を使用します。
条件付きアクセスを使用し、条件としてデバイスをフィルター処理します。
従来の信頼メカニズムを排除する - 分離されたディレクトリやサービスでは、Active Directory の信頼などの従来のメカニズムを使用して他の環境との信頼関係を確立すべきではありません。 環境間のすべての信頼を、フェデレーションや要求ベースの ID などの最新の構造を使用して確立する必要があります。
サービスを分離する - 基になる ID とサービス インフラストラクチャを露出から保護することによって、攻撃対象領域を最小限に抑えます。 サービスに対する先進認証を通してのみアクセスを有効にし、インフラストラクチャへのリモート アクセスをセキュリティで保護します (先進認証でも保護します)。
ディレクトリ レベルのロールの割り当て - ディレクトリ レベルのロールの割り当て (AU スコープではなく、ディレクトリ スコープに基づくユーザー管理者) や、コントロール プレーン アクションを使用したサービス固有のディレクトリ ロール (セキュリティ グループ メンバーシップを管理するためのアクセス許可を持つ知識管理者) を回避するか、またはその数を減らします。
Microsoft Entra 一般的な運用ガイドのガイダンスに加えて、分離された環境に関する次の考慮事項もお勧めします。
人間の ID のプロビジョニング
特権アカウント
環境を運用する管理担当者と IT チームのために、分離された環境でアカウントをプロビジョニングします。 これにより、セキュリティで保護されたワークステーションに対するデバイス ベースのアクセス制御などの、より強力なセキュリティ ポリシーを追加できます。 前のセクションで説明したように、非運用環境では Microsoft Entra B2B コラボレーションを利用して、その運用環境内の特権アクセス用に設計された同じ体制およびセキュリティ制御を使用して特権アカウントを非運用テナントにオンボードする場合があります。
クラウドのみのアカウントは、Microsoft Entra テナントで人間の ID をプロビジョニングするための最も簡単な方法であり、グリーン フィールド環境に最適です。 ただし、分離された環境に対応する既存のオンプレミス インフラストラクチャ (実稼働前または管理 Active Directory フォレストなど) が存在する場合は、そこから ID を同期することも検討できます。 これは、特に、前述のオンプレミス インフラストラクチャが、ソリューション データ プレーンを管理するためにサーバー アクセスが必要な IaaS ソリューションにも使用される場合に当てはまります。 このシナリオの詳細については、「オンプレミスの攻撃から Microsoft 365 を保護する」を参照してください。 分離されたオンプレミス環境からの同期は、スマート カードのみの認証などの、特定の規制コンプライアンス要件がある場合にも必要になります。
Note
Microsoft Entra B2B アカウントの ID 証明を行うための技術的な制御はありません。 Microsoft Entra B2B でプロビジョニングされた外部 ID は 1 つの要因でブートストラップされます。 この軽減策は、B2B 招待が発行される前に、組織で必要な ID を証明するためのプロセスを用意することと、ライフサイクルを管理するための外部 ID の定期的なアクセス レビューです。 MFA 登録を制御するために、条件付きアクセス ポリシーを有効にすることを検討してください。
リスクの高いロールのアウトソーシング
内部の脅威を軽減するために、Azure B2B コラボレーションを使うか、CSP パートナーまたは Lighthouse 経由でアクセスを委任して、グローバル管理者と特権ロール管理者のロールへのアクセスをマネージド サービス プロバイダーにアウトソーシングできます。 このアクセスは、Azure Privileged Identity Management (PIM) の承認フローを使用して、社内スタッフが制御できます。 このアプローチにより、内部の脅威を大幅に軽減できます。 これは、不安を抱いている顧客のコンプライアンス要求を満たすために使用できるアプローチです。
人間以外の ID のプロビジョニング
緊急アクセス アカウント
Microsoft は、組織が全体管理者ロールが永続的に割り当てられる 2 つのクラウド専用緊急アクセス アカウントを作成することを推奨しています。 このようなアカウントは高い特権を持っており、特定のユーザーには割り当てられません。 これらのアカウントは、通常のアカウントを使用できない、または他のすべての管理者が誤ってロックアウトされたという緊急または "break glass" のシナリオに限定されます。これらのアカウントは、緊急アクセス アカウントに関する推奨事項に従って作成する必要があります。
Azure マネージド ID
サービス ID を必要とする Azure リソースには Azure マネージド ID を使用します。 Azure ソリューションを設計するときに、マネージド ID をサポートするサービスの一覧を確認してください。
マネージド ID がサポートされていないか、または使用できない場合は、サービス プリンシパル オブジェクトのプロビジョニングを検討してください。
ハイブリッド サービス アカウント
ハイブリッド ソリューションの中には、オンプレミス リソースとクラウド リソースの両方へのアクセスが必要なものがあります。 ユース ケースの例としては、オンプレミスのドメインに参加しているサーバーへのアクセスに AD DS のサービス アカウントを使用し、Microsoft Online Services へのアクセスが必要な Microsoft Entra ID のアカウントも含まれるアプリケーションがあります。
オンプレミスのサービス アカウントには通常、対話形式でサインインする機能はありません。つまり、クラウド シナリオでは、多要素認証などの強力な資格情報要件を満足できません。 このシナリオでは、オンプレミスから同期されたサービス アカウントは使用せず、代わりにマネージド ID \ サービス プリンシパルを使用します。 サービス プリンシパル (SP) では、資格情報として証明書を使用するか、または条件付きアクセスで SP を保護します。
これを実行できない技術的な制約があり、オンプレミスとクラウドの両方に同じアカウントを使用する必要がある場合は、ハイブリッド アカウントを特定のネットワークの場所から来るようにロックダウンするために、条件付きアクセスなどの補正制御を実装します。
リソースの割り当て
エンタープライズ ソリューションは複数の Azure リソースで構成される可能性があるため、そのアクセスは割り当ての論理ユニット、つまりリソース グループとして管理および制御する必要があります。 そのシナリオでは、Azure AD セキュリティ グループを作成し、すべてのソリューション リソースにまたがる適切なアクセス許可とロールの割り当てに関連付けることができます。それにより、これらのグループにユーザーを追加または削除すると、ソリューション全体へのアクセスが許可または拒否されます。
アクセスを提供する前に、ライセンス シートの割り当てを持つユーザーに依存する Microsoft サービスのグループベースのライセンスとセキュリティ グループを使用することをお勧めします (例えば、Dynamics 365、Power BI など)。
Microsoft Entra クラウド ネイティブ グループは、Microsoft Entra アクセス レビューおよび Microsoft Entra エンタイトルメント管理と組み合わせた場合、クラウドからネイティブに管理できます。
Microsoft Entra ID では、シングル サインオンと ID プロビジョニングのために、サードパーティの SaaS サービス (例えば、Salesforce、Service Now など) とオンプレミス アプリケーションへの直接ユーザー割り当てもサポートされています。 リソースへの直接割り当ては、Microsoft Entra アクセス レビューおよび Microsoft Entra エンタイトルメント管理と組み合わせた場合、クラウドからネイティブに管理できます。 直接割り当ては、エンドユーザー向けの割り当てに適している場合があります。
シナリオによっては、オンプレミスの Active Directory セキュリティ グループを使用してオンプレミス リソースへのアクセス権を付与することが必要な場合があります。 その場合は、プロセスの SLA を設計するときに、Microsoft Entra への同期サイクルを検討してください。
認証管理
このセクションでは、組織のセキュリティ体制に基づいて、資格情報の管理やアクセス ポリシーのために実行すべきチェックと取るべきアクションについて説明します。
資格情報の管理
強力な資格情報
分離された環境内の人間の ID (B2B コラボレーションを使用してプロビジョニングされたローカル アカウントや外部 ID) はすべて、多要素認証や FIDO キーなどの強力な認証資格情報でプロビジョニングする必要があります。 スマート カード認証などの強力な認証を使用している基になるオンプレミス インフラストラクチャを含む環境では、引き続きクラウドでスマート カード認証を使用できます。
パスワードレスの資格情報
パスワードレスのソリューションは、最も便利で、かつ安全な認証方法を保証するための最適なソリューションです。 特権ロールを持つ人間の ID には、FIDO セキュリティ キーや Windows Hello for Business などのパスワードレスの資格情報が推奨されます。
パスワード保護
環境がオンプレミスの Active Directory フォレストから同期されている場合は、組織内の脆弱なパスワードを排除するために、Microsoft Entra のパスワード保護をデプロイする必要があります。 ハイブリッドまたはクラウド専用の環境では、ユーザーのパスワードを推測するか、またはブルート フォース方法を使用して侵入しようとしている悪意のあるアクターをロックアウトするために、Microsoft Entra スマート ロックアウトも使用する必要があります。
セルフサービスによるパスワード管理
パスワードを変更またはリセットする必要があるユーザーは、ヘルプ デスクへの問い合わせの量とコストの最大の発生源の 1 つです。 コストに加え、ユーザーのリスクを軽減するためのツールとしてパスワードを変更することは、組織のセキュリティ体制を改善するための基本的な手順です。 少なくとも、ヘルプ デスクへの問い合わせをそらすために、パスワードがある人間のアカウントやテスト アカウントにはセルフサービスのパスワード管理をデプロイします。
外部 ID のパスワード
Microsoft Entra B2B コラボレーションを使用すると、招待と引き換えプロセスにより、パートナー、開発者、下請業者などの外部ユーザーは、独自の資格情報を使用して会社のリソースにアクセスできます。 これにより、分離されたテナントにより多くのパスワードを導入する必要性が軽減されます。
注意
一部のアプリケーション、インフラストラクチャ、またはワークフローには、ローカル資格情報が必要になることがあります。 これはケース バイ ケースで評価してください。
サービス プリンシパルの資格情報
サービス プリンシパルが必要なシナリオでは、サービス プリンシパルの証明書資格情報またはワークロード ID 用の条件付きアクセスを使用します。 必要に応じて、組織のポリシーの例外としてクライアント シークレットを使用します。
どちらの場合も、ランタイム環境 (Azure 関数など) でキー コンテナーから資格情報を取得できるように、Azure Key Vault を Azure マネージド ID と共に使用できます。
証明書資格情報を含むサービス プリンシパルの認証については、自己署名証明書を使用してサービス プリンシパルを作成するこの例を確認してください。
アクセス ポリシー
次のセクションでは、Azure ソリューションの推奨事項について説明します。 個々の環境の条件付きアクセス ポリシーに関する一般的なガイダンスについては、条件付きアクセスのベスト プラクティス、Microsoft Entra 運用ガイド、ゼロ トラストの条件付きアクセスを確認してください。
Azure Resource Manager にアクセスするときの ID セキュリティ体制を適用するために、Windows Azure Service Management API クラウド アプリに対して条件付きアクセス ポリシーを定義します。 これには、セキュリティで保護されたワークステーション経由のアクセスのみを有効にする MFA に対する制御とデバイス ベースの制御を含める必要があります (これについては、「Identity Governance」の下の「特権ロール」セクションで詳細に説明します)。 さらに、デバイスをフィルター処理するための条件付きアクセスを使用します。
分離された環境にオンボードされたすべてのアプリケーションには、オンボード プロセスの一部として明示的な条件付きアクセス ポリシーが適用されている必要があります。
オンプレミスにある信頼プロセスのセキュリティで保護されたルートが反映されたセキュリティ情報登録に対して条件付きアクセス ポリシーを定義します (たとえば、従業員が検証のために自分でアクセスする必要がある、IP アドレスで識別できる物理的な場所にあるワークステーションの場合)。
条件付きアクセスを使用してワークロード ID を制限することを検討してください。 場所またはその他の関連する状況に基づいてアクセスを制限するか、またはより適切に制御するためのポリシーを作成します。
認証の課題
Microsoft Entra B2B でプロビジョニングされた外部 ID では、リソース テナントに多要素認証資格情報を再プロビジョニングすることが必要になる場合があります。 これは、リソース テナントにテナント間アクセス ポリシーが設定されていない場合に必要になることがあります。 つまり、システムへのオンボードは 1 つの要因でブートストラップされます。 このアプローチでは、リスク軽減策は、B2B 招待が発行される前に、組織でユーザーと資格情報のリスク プロファイルを証明するためのプロセスを用意することです。 さらに、前に説明したように、登録プロセスに対して条件付きアクセスを定義します。
B2B コラボレーションと B2B 直接接続を使用して、他の Microsoft Entra 組織やその他の Microsoft Azure クラウドと共同作業する方法を管理するには、外部 ID テナント間アクセス設定を使用します。
特定のデバイスの構成と制御については、条件付きアクセス ポリシーのデバイス フィルターを使用して、特定のデバイスを対象または対象外とすることができます。 これにより、指定されたセキュリティで保護された管理ワークステーション (SAW) から Azure 管理ツールへのアクセスを制限できます。 実行できる他のアプローチには、Azure Virtual Desktop、Azure Bastion、またはクラウド PC の使用が含まれます。
Azure EA Portal や MCA 課金アカウントなどの課金管理アプリケーションは、条件付きアクセスのターゲット設定のためのクラウド アプリケーションとしては表されません。 補正制御として、別の管理アカウントを定義し、[すべてのアプリ] の条件を使用して、これらのアカウントに対して条件付きアクセス ポリシーを対象とします。
Identity Governance
特権ロール
分離のためにすべてのテナント構成にまたがって考慮すべき、いくつかの ID ガバナンスの原則を次に示します。
継続的なアクセスはなし - 人間の ID には、分離された環境で特権操作を実行するための継続的なアクセス権を付与するべきではありません。 Azure ロールベースのアクセス制御 (RBAC) は、Microsoft Entra Privileged Identity Management (PIM) と統合されます。 PIM は、多要素認証、承認ワークフロー、期間の制限などのセキュリティ ゲートによって決定される Just-In-Time アクティブ化を提供します。
管理者の数 - 組織は、ビジネス継続性のリスクを軽減するために、特権ロールを持つユーザーの最小数と最大数を定義する必要があります。 特権ロールの数が少なすぎると、タイム ゾーンを十分にカバーできない可能性があります。 最小特権の原則に従って、管理者の数をできるだけ少なくすることによってセキュリティ リスクを軽減します。
特権アクセスを制限する - 高い特権または機密性が高い特権のための、クラウド専用のロール割り当て可能なグループを作成します。 これにより、割り当てられたユーザーとグループ オブジェクトの保護が提供されます。
最小特権アクセス - ID には、組織内のそのロールに従った特権操作を実行するために必要なアクセス許可のみを付与する必要があります。
Azure RBAC カスタム ロールを使用すると、組織のニーズに基づいて最小特権ロールを設計できます。 カスタム ロールの定義は、専門のセキュリティ チームが作成またはレビューするようにして、意図しない過剰な特権のリスクを軽減することをお勧めします。 カスタム ロールの作成は、Azure Policy を使用して監査できます。
組織内でのより広範囲の使用が想定されていないロールの誤った使用を軽減するために、Azure Policy を使用して、アクセス権を割り当てるためにどのロール定義を使用できるかを明示的に定義します。 詳細については、この GitHub サンプルを参照してください。
セキュリティで保護されたワークステーションからの特権アクセス - すべての特権アクセスを、セキュリティで保護されたロックダウンされたデバイスから行う必要があります。 これらの機密性の高いタスクやアカウントを日常的に使用されるワークステーションやデバイスから分離すると、特権アカウントがフィッシング攻撃、アプリケーションと OS の脆弱性、さまざまな偽装攻撃のほか、キーボード操作のログ、Pass-the-Hash、Pass-the-Ticket などの資格情報窃盗攻撃から保護されます。
特権アクセス ストーリーの一部としてのセキュリティで保護されたデバイスの使用のために使用できるいくつかのアプローチには、特定のデバイスを対象または対象外とするための条件付きアクセス ポリシーの使用、Azure Virtual Desktop、Azure Bastion、またはクラウド PC の使用、Azure マネージド ワークステーションまたは特権アクセス ワークステーションの作成が含まれます。
特権ロール プロセスのガードレール - 組織は、規制要件に準拠しながら、必要な場合は常に特権操作を確実に実行できるようにするためのプロセスと技術的なガードレールを定義する必要があります。 ガードレールの基準の例には、次のものが含まれます。
特権ロールを持つユーザーの資格 (フルタイム従業員/ベンダー、クリアランス レベル、市民権など)
ロールの明示的な非互換性 (職務の分離とも呼ばれます)。 例として、Microsoft Entra ディレクトリ ロールを持つチームが Azure Resource Manager 特権ロールの管理を行うべきではない、などがあります。
直接のユーザーまたはグループの割り当てがどのロールに推奨されるか。
Microsoft Entra PIM の外部での IAM 割り当ての監視は、Azure ポリシーでは自動化されません。 この軽減策として、エンジニアリング チームにサブスクリプション所有者またはユーザー アクセス管理者ロールを付与しないようにします。 代わりに、共同作成者などの最小特権ロールに割り当てられたグループを作成し、それらのグループの管理をエンジニアリング チームに委任します。
リソース アクセス
構成証明 - メンバーシップを最新で、かつ正当化された状態に維持するために、特権ロールを持つ ID を定期的にレビューする必要があります。 Microsoft Entra アクセス レビューは、Azure RBAC ロール、グループ メンバーシップ、Microsoft Entra B2B 外部 ID と統合されます。
ライフサイクル - 特権操作には、基幹業務アプリケーション、SaaS アプリケーション、Azure リソース グループとサブスクリプションなどの複数のリソースへのアクセスが必要になることがあります。 Microsoft Entra エンタイトルメント管理を使用すると、ユーザーにユニットとして割り当てられたセット リソースを表すアクセス パッケージを定義し、有効期間や承認ワークフローなどを確立できます。
テナントとサブスクリプションのライフサイクル管理
テナントのライフサイクル
新しい企業 Microsoft Entra テナントを要求するためのプロセスを実装することをお勧めします。 このプロセスでは、次のことを考慮する必要があります。
それを作成するための業務上の正当な理由。 新しい Microsoft Entra テナントを作成すると、複雑さが大幅に増すため、新しいテナントが必要かどうかを確認することが重要です。
それが作成される必要がある Azure クラウド (商用クラウドや政府のクラウドなど)。
これが運用または非運用テナントのどちらであるか
ディレクトリのデータ所在地の要件
それを誰が管理するか
一般的なセキュリティ要件のトレーニングと理解。
承認されると、Microsoft Entra テナントが作成され、必要なベースライン制御が構成されて、課金プレーンや監視などにオンボードされます。
管理されたプロセスの外部でのテナント作成を検出するために、課金プレーン内の Microsoft Entra テナントの定期的なレビューを実装する必要があります。 詳細については、このドキュメントの「インベントリと可視性」セクションを参照してください。
Azure AD B2C テナントの作成は、Azure Policy を使用して制御できます。 このポリシーは、その B2C テナントに Azure サブスクリプションが関連付けられているときに実行されます (課金の前提条件)。 顧客は、Azure AD B2C テナントの作成を特定の管理グループに制限できます。
テナントの作成を組織に従属させるための技術的な制御はありません。 ただし、アクティビティは監査ログに記録されます。 課金プレーンへのオンボードはゲートでの補正制御です。 代わりに、これを監視とアラートで補完する必要があります。
サブスクリプションのライフサイクル
管理されたサブスクリプション ライフサイクル プロセスを設計する場合の、いくつかの考慮事項を次に示します。
Azure リソースが必要なアプリケーションとソリューションの分類を定義します。 サブスクリプションを要求するすべてのチームは、サブスクリプションを要求するときにその "製品識別子" を指定する必要があります。 この情報分類によって、次のものが決定されます。
サブスクリプションをプロビジョニングする Microsoft Entra テナント
サブスクリプションの作成に使用する Azure EA アカウント
名称に関する規則
管理グループの割り当て
タグ付け、クロス課金、製品ビューの使用などのその他の側面。
ポータルまたはその他の手段を使用したアドホック サブスクリプションの作成を許可しないでください。 代わりに、Azure Resource Manager を使用してプログラムでサブスクリプションを管理し、使用量レポートと課金レポートをプログラムでプルすることを検討してください。 これは、サブスクリプションのプロビジョニングを認可されたユーザーに制限し、ポリシーと分類の目標を適用するのに役立ちます。 AZOps の原則に従うことに関するガイダンスを使用すると、実用的なソリューションを作成するのに役立ちます。
サブスクリプションがプロビジョニングされたら、アプリケーション チームに必要な標準の Azure Resource Manager ロール (共同作成者、閲覧者、承認されたカスタム ロールなど) を持つ Microsoft Entra クラウド グループを作成します。 これにより、管理された特権アクセスを使用して Azure RBAC ロールの割り当てを大規模に管理できます。
Microsoft Entra PIM をアクティブ化ポリシー、アクセス レビュー、承認者などの対応する制御と共に使用して、Azure RBAC ロールの対象となるようにグループを構成します。
次に、ソリューション所有者にグループの管理を委任します。
ガードレールとして、Microsoft Entra PIM の外部でロールが誤って直接割り当てられることや、サブスクリプションが別のテナントに完全に変更される可能性を回避するために、製品所有者をユーザー アクセス管理者または所有者ロールに割り当てないでください。
Azure Lighthouse を使用して非運用テナントでテナント間のサブスクリプション管理を有効にすることを選択した顧客の場合は、サブスクリプションを管理するために認証するときに、運用特権アカウントの同じアクセス ポリシー (たとえば、セキュリティで保護され ワークステーションからのみの特権アクセス) が確実に適用されるようにしてください。
組織に事前に承認された参照アーキテクチャがある場合は、サブスクリプションのプロビジョニングを Azure Blueprints や Terraform などのリソース デプロイ ツールと統合できます。
Azure サブスクリプションへのテナント アフィニティを考慮すると、サブスクリプションのプロビジョニングでは、複数のテナントにまたがる同じ人間のアクターの複数の ID (従業員、パートナー、ベンダーなど) を認識し、それに応じてアクセス権を割り当てる必要があります。
EA ロールと MCA ロール
Azure Enterprise (Azure EA) Agreement ポータルは、Azure RBAC や条件付きアクセスとは統合されません。 この軽減策として、ポリシーや追加の監視の対象にできる専用の管理アカウントを使用します。
Azure EA Enterprise ポータルでは、監査ログは提供されません。 これを軽減するには、前に説明した考慮事項を使用してサブスクリプションをプロビジョニングし、専用の EA アカウントを使用して認証ログを監査するための自動化された管理されたプロセスを検討してください。
Microsoft 顧客契約 (MCA) ロールは、PIM とネイティブには統合されません。 これを軽減するには、専用の MCA アカウントを使用し、これらのアカウントの使用状況を監視します。
Azure AD B2C テナント
Azure AD B2C テナントでは、組み込みロールは PIM をサポートしていません。 セキュリティを強化するために、Microsoft Entra B2B コラボレーションを使用して、Azure テナントから顧客 ID アクセス管理 (CIAM) を管理するエンジニアリング チームをオンボードし、それらを Azure AD B2C 特権ロールに割り当て、これらの専用管理アカウントに条件付きアクセス ポリシーを適用することをお勧めします。
Azure AD B2C テナントの特権ロールは、Microsoft Entra アクセス レビューとは統合されません。 この軽減策として、組織の Microsoft Entra テナント内に専用アカウントを作成し、これらのアカウントをグループに追加して、このグループに対して定期的なアクセス レビューを実行します。
上記の Microsoft Entra の緊急アクセス ガイドラインに従って、前に説明した外部管理者に加え、同等の緊急アクセス用アカウントを作成することを検討してください。
B2C テナントの基になる Microsoft Entra サブスクリプションの論理所有権を、Azure サブスクリプションの残りの部分が B2C ソリューションに使用されるのと同じように、CIAM エンジニアリング チームに合わせることをお勧めします。
操作
複数の分離された環境に固有の Microsoft Entra に関する運用上の追加の考慮事項を次に示します。 個々の環境を運用するための詳細なガイダンスについては、Azure クラウド導入フレームワーク、Microsoft クラウド セキュリティ ベンチマーク、Microsoft Entra 運用ガイドを確認してください。
クロス環境のロールと責任
企業全体にわたる SecOps アーキテクチャ - 組織内のすべての環境の運用およびセキュリティ チームのメンバーが次のものを共同で定義する必要があります。
環境をいつ作成、統合、または非推奨化する必要があるかを定義するための原則。
各環境で管理グループ階層を定義するための原則。
課金プレーン (EA ポータル/MCA) のセキュリティ体制、運用体制、委任のアプローチ。
テナントの作成プロセス。
エンタープライズ アプリケーションの分類。
Azure サブスクリプションのプロビジョニング プロセス。
分離と管理の自律性の境界と、チームや環境にまたがるリスク評価。
すべての環境で使用される一般的なベースライン構成およびセキュリティ制御 (技術的および補完的) と運用ベースライン。
複数の環境にまたがる一般的な標準の運用手順およびツール (監視やプロビジョニングなど)。
複数の環境にまたがるロールの合意された委任。
環境にまたがる職務の分離。
特権ワークステーションに対する一般的なサプライ チェーン管理。
名前付け規則。
クロス環境の相関関係メカニズム。
テナントの作成 - 企業全体にわたる SecOps アーキテクチャによって定義されている標準化された手順に従って、特定のチームがテナントの作成を所有している必要があります。 これには次のものが含まれます
基になるライセンス プロビジョニング (Microsoft 365 など)。
企業の課金プランへのオンボード (Azure EA や MCA など)。
Azure 管理グループ階層の作成。
ID、データ保護、Azure などを含むさまざまな境界に対する管理ポリシーの構成。
診断設定、SIEM オンボード、CASB オンボード、PIM オンボードなどを含む、合意されたサイバーセキュリティ アーキテクチャごとのセキュリティ スタックのデプロイ。
合意された委任に基づいた Microsoft Entra ロールの構成。
初期の特権ワークステーションの構成と配布。
緊急アクセス用アカウントのプロビジョニング。
ID プロビジョニング スタックの構成。
クロス環境ツールのアーキテクチャ - ID プロビジョニングやソース管理パイプラインなどの一部のツールは、複数の環境にまたがって動作することが必要な場合があります。 これらのツールはインフラストラクチャにとって重要であると見なす必要があり、そのように設計、デザイン、実装、管理する必要があります。 そのため、クロス環境ツールを定義する必要がある場合は常に、すべての環境の設計者を関与させる必要があります。
インベントリと可視性
Azure サブスクリプションの検出 - 検出されたテナントごとに、Microsoft Entra グローバル管理者は、環境内のすべてのサブスクリプションを可視化するためにアクセス権限を昇格させることができます。 この昇格により、それらのユーザーには、ルート管理グループでのユーザー アクセス管理者の組み込みロールが割り当てられます。
Note
このアクションは高い特権を持つため、データが適切に分離されていない場合は、非常に機密性の高い情報を保持するサブスクリプションへのアクセス権が管理者に付与される可能性があります。
リソースを検出するための読み取りアクセスの有効化 - 管理グループにより、RBAC 割り当てが、複数のサブスクリプションにまたがって大規模に有効になります。 顧客は、ルート管理グループでロールの割り当てを構成することによって、一元化された IT チームに閲覧者ロールを付与できます。これは、環境内のすべてのサブスクリプションに伝達されます。
リソースの検出 - 環境内のリソースの読み取りアクセスを取得したら、Azure Resource Graph を使用して環境内のリソースにクエリを実行できます。
ログ記録と監視
セキュリティ ログの一元管理 - 環境にわたって一貫性のあるベスト プラクティス (診断設定、ログ保持期間、SIEM インジェストなど) に従って、一元的な方法で各環境からログを取り込みます。 Azure Monitor を使用すると、エンドポイント デバイス、ネットワーク、オペレーティング システムのセキュリティ ログなどのさまざまなソースからログを取り込むことができます。
自動または手動のプロセスやツールを使用して、セキュリティ運用の一部としてログを監視する方法に関する詳細情報は、Microsoft Entra セキュリティ運用ガイドで入手できます。
環境によっては、特定の環境から持ち出すことができるデータ (存在する場合) を制限する規制要件がある場合があります。 環境にまたがる一元的な監視が不可能な場合、チームには、クロス環境の横移動の試みなどの監査やフォレンジックスの目的のために、環境にまたがる ID のアクティビティを関連付ける運用手順が用意されている必要があります。 同じユーザーに属する一意識別子や人間の ID のオブジェクトを (場合によっては、ID プロビジョニング システムの一部として) 検出可能にすることをお勧めします。
ログ戦略には、組織で使うテナントごとに次の Microsoft Entra ログを含める必要があります。
サインイン アクティビティ
監査ログ
リスク イベント
Microsoft Entra ID により、サインイン アクティビティ ログと監査ログのための Azure Monitor の統合が提供されます。 リスク イベントは、Microsoft Graph API を使用して取り込むことができます。
次の図は、監視戦略の一部として組み込まれむ必要があるさまざまなデータ ソースを示しています。
Azure AD B2C テナントは、Azure Monitor と統合できます。 Microsoft Entra ID に対して前に説明したのと同じ条件を使用した Azure AD B2C の監視をお勧めします。
Azure Lighthouse を使用してテナント間の管理を有効にしているサブスクリプションでは、Azure Monitor によってログが収集されている場合、テナント間の監視を有効にすることができます。 対応する Log Analytics ワークスペースはリソース テナント内に存在することができ、Azure Monitor ブックを使用して管理テナントで一元的に分析できます。 詳細については、「委任されたリソースを大規模に監視する - Azure Lighthouse」を確認してください。
ハイブリッド インフラストラクチャの OS セキュリティ ログ
ハイブリッド ID インフラストラクチャの OS ログはすべて、外部からのアクセスの影響を考慮し、階層 0 システムとしてアーカイブして注意深く監視する必要があります。 これには次のものが含まれます
AD FS サーバーと Web アプリケーション プロキシ
Microsoft Entra Connect
アプリケーション プロキシ エージェント
パスワード ライトバック エージェント
パスワード保護ゲートウェイ マシン
Microsoft Entra 多要素認証 RADIUS 拡張機能を備えた NPS
すべての環境の ID 同期とフェデレーション (該当する場合) を監視するには、Microsoft Entra Connect Health をデプロイする必要があります。
ログ ストレージ保持期間 - 一貫性のあるツールセット (たとえば、Azure Sentinel などの SIEM システム)、一般的なクエリ、調査、フォレンジックス プレイブックを促進するには、すべての環境に凝集性のあるログ ストレージ保持期間の戦略、設計、実装が必要です。 Azure Policy を使用すると、診断設定を設定できます。
監視とログのレビュー - ID 監視に関する運用タスクは一貫性があり、各環境に所有者が存在する必要があります。 前に説明したように、規制コンプライアンスや分離の要件によって許容される範囲内で、これらの責任を環境にまたがって統合するように努力してください。
次のシナリオを明示的に監視および調査する必要があります。
疑わしいアクティビティ - すべての Microsoft Entra リスク イベントを、疑わしいアクティビティがないかどうか監視する必要があります。 場所ベースのシグナルで多くのノイズが検出されないように、すべてのテナントでネットワークのネームド ロケーションを定義する必要があります。 Microsoft Entra ID Protection は、Azure Security Center とネイティブに統合されています。 すべてのリスク検出調査に、ID がプロビジョニングされているすべての環境を含めることをお勧めします (たとえば、人間の ID で企業テナント内のアクティブなリスク検出が発生した場合、顧客向けのテナントを運用しているチームは、その環境内の対応するアカウントのアクティビティも調査する必要があります)。
ユーザー/エンティティ行動分析 (UEBA) のアラート - 異常検出に基づいて詳細な分析情報を取得するには、UEBA を使用する必要があります。 Microsoft 365 Defender for Cloud Apps は、クラウドでの UEBA を提供します。 顧客は、Microsoft 365 Defender for Identity からオンプレミスの UEBA を統合できます。 MCAS は、Microsoft Entra ID 保護から信号を読み取ります。
緊急アクセス用アカウントのアクティビティ - 緊急アクセス用アカウントを使用したすべてのアクセスを監視し、調査のためにアラートを作成する必要があります。 この監視には次のものを含める必要があります。
サインイン
資格情報の管理
グループ メンバーシップのすべての更新
アプリケーションの割り当て
課金管理アカウント - Azure EA または MCA の課金管理ロールを持つアカウントの機密性とその高い特権を考慮して、次のことを監視し、アラートを生成することをお勧めします。
課金ロールを持つアカウントによるサインインの試行。
EA ポータル以外のアプリケーションに対して認証しようとするすべての試み。
MCA 課金タスクに専用アカウントを使用している場合は、Azure Resource Management 以外のアプリケーションに対して認証しようとするすべての試み。
MCA 課金タスクの専用アカウントを使用した Azure リソースへの割り当て。
特権ロールのアクティビティ - Microsoft Entra PIM によって生成されるセキュリティ アラートを構成およびレビューします。 RBAC の直接割り当てのロックダウンを技術的な制御で完全には適用できない場合 (たとえば、ジョブを実行できるように製品チームに所有者ロールを付与する必要がある場合) は、Azure RBAC を使用してサブスクリプションにアクセスするためにユーザーが直接割り当てられるたびにアラートを生成することによって、PIM の外部での特権ロールの直接割り当てを監視します。
クラシック ロールの割り当て - 組織は、クラシック ロールの代わりに、最新の Azure RBAC ロール インフラストラクチャを使用する必要があります。 その結果、次のイベントを監視する必要があります。
- サブスクリプション レベルでのクラシック ロールへの割り当て
テナント全体の構成 - テナント全体の構成サービスでは、常にシステムでアラートを生成する必要があります。
カスタム ドメインの更新
ブランド化の更新
Microsoft Entra B2B の許可/ブロック リスト
Microsoft Entra B2B で許可された ID プロバイダー (直接フェデレーションまたはソーシャル ログインによる SAML IDP)
条件付きアクセス ポリシーの変更
アプリケーション オブジェクトとサービス プリンシパル オブジェクト
条件付きアクセス ポリシーを必要とする可能性がある新しいアプリケーション/サービス プリンシパル
アプリケーションの同意アクティビティ
管理グループのアクティビティ - 管理グループの次の ID の側面を監視する必要があります。
MG での RBAC ロールの割り当て
MG で適用された Azure ポリシー
MG 間で移動されたサブスクリプション
ルート MG に対するセキュリティ ポリシーへのすべての変更
カスタム ロール
カスタム ロールの定義の更新
作成された新しいカスタム ロール
職務規則のカスタム分離 - 組織が職務の分離規則を確立した場合、Microsoft Entra Entitlement Management の互換性のないアクセス パッケージを使用して職務の分離を強制し、アラートを作成するか、管理者による違反を検出するための定期的なレビューを構成します。
監視に関するその他の考慮事項 - ログ管理に使用されるリソースが含まれている Azure サブスクリプションは、重要なインフラストラクチャ (階層 0) と見なし、対応する環境のセキュリティ運用チームにロックダウンする必要があります。 Azure Policy などのツールを使用して、これらのサブスクリプションに追加の制御を適用することを検討してください。
運用ツール
クロス環境ツールの設計上の考慮事項:
可能な場合は常に、複数のテナントにまたがって使用される運用ツールは、各テナントで複数のインスタンスが再デプロイされないようにし、運用上の非効率性を回避するために、Microsoft Entra マルチテナント アプリケーションとして実行されるように設計する必要があります。 この実装には、ユーザーとデータの間の分離が確実に保持されるようにするための認可ロジックを含める必要があります。
クロス環境の自動化 (ID プロビジョニングなど) や、フェールセーフに対するしきい値の制限をすべて監視するためのアラートと検出を追加します。 たとえば、ユーザー アカウントのプロビジョニング解除が特定のレベルに達した場合は、それが広範囲に影響を与えるバグまたは運用エラーを示している可能性があるため、アラートを生成することもできます。
クロス環境タスクを調整するすべての自動化を、高い特権を持つシステムとして運用する必要があります。 このシステムは最も高いセキュリティ環境に配置し、他の環境のデータが必要な場合は外部ソースからプルする必要があります。 システムの整合性を維持するには、データ検証としきい値を適用する必要があります。 一般的なクロス環境タスクとして、解雇された従業員に関して、すべての環境から ID を削除するための ID ライフサイクル管理があります。
IT サービス管理ツール - ServiceNow などの IT Service Management (ITSM) システムを使用している組織は、アクティブ化の目的の一部としてチケット番号を要求するように Microsoft Entra PIM ロールのアクティブ化の設定を構成する必要があります。
同様に、IT Service Management Connector を使用して Azure Monitor を ITSM システムと統合できます。
運用プラクティス - 人間の ID での環境への直接アクセスを必要とする運用アクティビティを最小限に抑えます。 代わりに、それを一般的な操作 (PaaS ソリューションへの容量の追加や、実行の診断など) を実行する Azure Pipelines としてモデル化し、Azure Resource Manager インターフェイスへの直接アクセスを "非常時" のシナリオとしてモデル化します。
運用の課題
サービス プリンシパルの監視のアクティビティが一部のシナリオに制限されます。
Microsoft Entra PIM アラートには API がありません。 この軽減策として、これらの PIM アラートの定期的なレビューを実行します。
Azure EA Portal では、監視機能は提供されません。 この軽減策として、専用の管理アカウントを保有し、そのアカウントのアクティビティを監視します。
MCA では、課金タスクの監査ログは提供されません。 この軽減策として、専用の管理アカウントを保有し、そのアカウントのアクティビティを監視します。
環境を運用するために必要な Azure の一部のサービスはマルチテナントやマルチクラウドにできないため、再デプロイし、環境にまたがって再構成する必要があります。
コードとしてのインフラストラクチャを完全に実現するための Microsoft Online Services にまたがる完全な API カバレッジはありません。 この軽減策として、API をできる限り使用し、残りの部分にはポータルを使用します。 このオープンソースのイニシアティブは、環境で機能する可能性のあるアプローチを決定するのに役立ちます。
サブスクリプション アクセスを管理テナント内の ID に委任しているリソース テナントを検出するためのプログラムによる機能はありません。 たとえば、電子メール アドレスによって contoso.com テナント内のセキュリティ グループが fabrikam.com テナント内のサブスクリプションを管理できるようになった場合、contoso.com 内の管理者には、この委任が行われたことを検出するための API がありません。
特定のアカウント アクティビティ (緊急用アカウントや課金管理アカウントなど) の監視が標準で提供されません。 この軽減策として、顧客が独自のアラート ルールを作成します。
テナント全体の構成の監視が標準で提供されません。 この軽減策として、顧客が独自のアラート ルールを作成します。
次のステップ
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示