編集

次の方法で共有

条件付きアクセスの設計原則と依存関係

Microsoft Entra ID
Microsoft Endpoint Manager

この記事では、ゼロ トラストに基づく条件付きアクセス シナリオの設計原則と依存関係について説明します。

設計の原則

いくつかの設計原則から始めます。

ゼロ トラスト ポリシー エンジンとしての条件付きアクセス

ゼロ トラストに対する Microsoft のアプローチには、メイン ポリシー エンジンとして条件付きアクセスが含まれます。 このアプローチの概要を次に示します。

ゼロ トラスト モデルの概要を示す図。

このアーキテクチャの SVG ファイル ダウンロードします。

条件付きアクセスは、ポリシー定義とポリシー適用の両方をカバーするゼロ トラスト アーキテクチャのポリシー エンジンとして使用されます。 次に示すように、条件付きアクセスは、さまざまなシグナルまたは条件に基づいて、リソースへのアクセスをブロックまたは制限できます。

条件付きアクセスシグナル、決定、適用パスの概要を示す図。

条件付きアクセスの要素とその内容の詳細なビューを次に示します。

条件付きアクセスのより詳細なビューを示す図。

この図は、非対話型アクセスまたは非人間アクセスではなく、リソースへのユーザー アクセスを保護するのに役立つ条件付きアクセスと関連する要素を示しています。 次の図では、両方の種類の ID について説明します。

条件付きアクセス ID の種類を説明する図。

条件付きアクセスは、主に対話型の人間からリソースへのアクセスを保護することに重点を置いてきました。 人間以外の ID の数が増えるにつれて、これらの ID からのアクセスも考慮する必要があります。 Microsoft では、ワークロード ID との間のアクセスの保護に関連する 2 つの機能を提供しています。

  • Microsoft Entra 条件付きアクセス ポータルで選択できないワークロード ID によって表されるアプリケーションへのアクセスの保護。 このオプションは、セキュリティ属性を使用してサポートされます。 ワークロード ID にセキュリティ属性を割り当て、Microsoft Entra 条件付きアクセス ポータルでセキュリティ属性を選択することは、Microsoft Entra ID P1 ライセンスの一部です。
  • ワークロード ID (サービス プリンシパル) によって開始されるリソースへのアクセスの保護。 このシナリオをサポートする別のライセンスで、新しい機能 "Microsoft Entra ワークロード ID" が提供されます。 これには、条件付きアクセスを使用したリソースへのアクセスの保護など、ワークロード ID のライフサイクル管理が含まれます。

エンタープライズ アクセス モデル

Microsoft は以前、階層化モデルに基づいてオンプレミス リソースにアクセスするためのガイダンスと原則を提供してきました。

  • 階層 0: ドメイン コントローラー、公開キー 基盤 (PKI)、Active Directory フェデレーション サービス (AD FS) サーバー、およびこれらのサーバーを管理する管理ソリューション
  • 階層 1: アプリケーションをホストするサーバー
  • 階層 2: クライアント デバイス

このモデルは、引き続きオンプレミス のリソースに関連しています。 クラウド内のリソースへのアクセスを保護するために、Microsoft は次のようなアクセス制御戦略を推奨しています。

  • 包括的で一貫性があります。
  • テクノロジ スタック全体にセキュリティ原則を厳密に適用します。
  • 組織のニーズを満たすのに十分な柔軟性があります。

これらの原則に基づいて、Microsoft は次のエンタープライズ アクセス モデルを作成しました。

エンタープライズ アクセス モデルの概要を示す図。

エンタープライズ アクセス モデルは、オンプレミスの Windows Server Active Directory 環境で権限の承認されていないエスカレーションを含めるという点に重点を置いたレガシ層モデルに代わるものです。 新しいモデルでは、階層 0 がコントロール プレーンに拡張され、階層 1 は管理とデータ プレーンで構成され、階層 2 はユーザーとアプリのアクセスを対象とします。

Microsoft では、制御と管理を、メインコントロール プレーンとポリシー エンジンとして条件付きアクセスを使用するクラウド サービスに移行し、アクセスを定義して適用することをお勧めします。

Microsoft Entra 条件付きアクセス ポリシー エンジンを、次のような他のポリシー適用ポイントに拡張できます。

  • 最新のアプリケーション: 先進認証プロトコルを使用するアプリケーション。
  • レガシ アプリケーション: Microsoft Entra アプリケーション プロキシ経由。
  • VPN およびリモート アクセス ソリューション: Microsoft Always On VPN、Cisco AnyConnect、Palo Alto Networks、F5、Fortinet、Citrix、Zscaler などのソリューション。
  • ドキュメント、電子メール、その他のファイル: Microsoft Information Protection 経由。
  • SaaS アプリケーション。
  • AWS や Google Cloud などの他のクラウドで実行されているアプリケーション (フェデレーションに基づく)。

ゼロトラストの原則

Microsoft が定義する 3 つの主要なゼロ トラスト原則は、特にセキュリティ部門によって理解されているようです。 ただし、ゼロ トラスト ソリューションの設計時に使いやすさの重要性が見落とされる場合があります。

使いやすさは常に暗黙的な原則と見なす必要があります。

条件付きアクセスの原則

上記の情報に基づいて、推奨される原則の概要を次に示します。 Microsoft では、次の 3 つの主要な Microsoft ゼロ トラスト原則に沿った条件付きアクセスに基づいてアクセス モデルを作成することをお勧めします。

明示的に を確認する

  • コントロール プレーンをクラウドに移動します。 アプリを Microsoft Entra ID と統合し、条件付きアクセスを使用して保護します。
  • すべてのクライアントを外部と見なします。

最小限の特権アクセス を使用する

  • ユーザー リスク、サインイン リスク、デバイス リスクなど、コンプライアンスとリスクに基づいてアクセスを評価します。
  • 次のアクセスの優先順位を使用します。
    • 保護のために条件付きアクセスを使用して、リソースに直接アクセスします。
    • 保護に条件付きアクセスを使用して、Microsoft Entra アプリケーション プロキシを使用してリソースへのアクセスを公開します。
    • 条件付きアクセスベースの VPN を使用してリソースにアクセスします。 アプリまたは DNS 名のレベルへのアクセスを制限します。

侵害 を想定する

  • ネットワーク インフラストラクチャをセグメント化します。
  • エンタープライズ PKI の使用を最小限に抑えます。
  • シングル サインオン (SSO) を AD FS からパスワード ハッシュ同期 (PHS) に移行します。
  • Microsoft Entra ID で Kerberos KDC を使用して、DC への依存関係を最小限に抑えます。
  • 管理プレーンをクラウドに移動します。 Microsoft Endpoint Manager を使用してデバイスを管理します。

条件付きアクセスのより詳細な原則と推奨されるプラクティスを次に示します。

  • 条件付きアクセスにゼロ トラスト原則を適用します。
  • ポリシーを運用環境に配置する前に、レポート専用モードを使用します。
  • 正と負の両方のシナリオをテストします。
  • 条件付きアクセス ポリシーで変更とリビジョンの制御を使用します。
  • Azure DevOps/GitHub や Azure Logic Apps などのツールを使用して、条件付きアクセス ポリシーの管理を自動化します。
  • 必要な場合にのみ、一般的なアクセスにはブロック モードを使用します。
  • すべてのアプリケーションとプラットフォームが保護されていることを確認します。 条件付きアクセスには、暗黙的な "すべて拒否" はありません。
  • すべての Microsoft 365 ロールベースのアクセス制御 (RBAC) システムで特権ユーザーを保護します。
  • リスクの高いユーザーとサインイン (サインイン頻度によって適用) に対してパスワードの変更と多要素認証が必要です。
  • 危険度の高いデバイスからのアクセスを制限します。 条件付きアクセスのコンプライアンス チェックで Intune コンプライアンス ポリシーを使用します。
  • Office 365、Azure、AWS、Google Cloud の管理者ポータルへのアクセスなど、特権システムを保護します。
  • 管理者と信頼されていないデバイスでの永続的なブラウザー セッションを禁止します。
  • レガシ認証をブロックします。
  • 不明またはサポートされていないデバイス プラットフォームからのアクセスを制限します。
  • 可能な場合は、リソースへのアクセスに準拠しているデバイスが必要です。
  • 強力な資格情報の登録を制限します。
  • 停止前に適切な条件が満たされた場合は、停止が発生した場合にセッションを続行できるようにする既定のセッション ポリシーを使用することを検討してください。

次の図は、依存関係と関連テクノロジを示しています。 一部のテクノロジは、条件付きアクセスの前提条件です。 他のユーザーは条件付きアクセスに依存します。 このドキュメントで説明する設計は、主に条件付きアクセスに焦点を当てており、関連するテクノロジに焦点を当てています。

条件付きアクセスの依存関係を示す図。

条件付きアクセスのガイダンス

詳細については、「ゼロ トラストとペルソナ に基づく条件付きアクセスの設計」を参照してください。

貢献

この記事は Microsoft によって管理されています。 もともとは次の共同作成者によって作成されました。

プリンシパルの作成者:

非公開の LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次の手順

  • 条件付きアクセスの概要
  • ゼロ トラストとペルソナに基づく条件付きアクセスの設計
  • 条件付きアクセス フレームワークとポリシー を する