この記事では、ゼロ トラストに基づいて条件付きアクセス シナリオの設計原則と依存関係について説明します。
設計原則
まず、いくつかの設計原則から始めます。
ゼロ トラスト ポリシー エンジンとしての条件付きアクセス
Microsoft のゼロ トラストへのアプローチには、メイン ポリシー エンジンとしての条件付きアクセスが含まれます。 このアプローチの概要を次に示します。
このアーキテクチャの SVG ファイルをダウンロードします。
条件付きアクセスは、ポリシー定義とポリシーの適用の両方を網羅するゼロ トラスト アーキテクチャのポリシー エンジンとして使用されます。 次に示すように、さまざまなシグナルまたは条件に基づいて、条件付きアクセスによってリソースへのアクセスがブロックされたり、制限されたりすることがあります。
条件付きアクセスの要素とその内容について詳しく説明します。
この図は、非対話型または人間以外のアクセスではなく、リソースへのユーザーアクセスを保護するのに役立つ条件付きアクセスと関連要素を示しています。 次のダイアグラムでは、両種類の 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 では、これらの原則に基づいて、次のエンタープライズ アクセス モデルを作成しました。
エンタープライズ アクセス モデルは、オンプレミスの 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 エンドポイント マネージャーを使用してデバイスを管理します。
条件付きアクセスのより詳細な原則と推奨される方法を次に示します。
- 条件付きアクセスにゼロ トラスト原則を適用します。
- ポリシーを運用環境に配置する前に、レポート専用モードを使用します。
- ポジティブなシナリオとネガティブなシナリオ両方をテストします。
- 条件付きアクセス ポリシーで変更とリビジョン コントロールを使用します。
- Azure DevOps / GitHub や Azure Logic Apps などのツールを使用して、条件付きアクセス ポリシーの管理を自動化します。
- 一般的なアクセスには、必要に応じてブロック モードを使用します。
- すべてのアプリケーションとプラットフォームが保護されていることを確認します。 条件付きアクセスには暗黙的な "すべて拒否" はありません。
- すべての Microsoft 365 ロールベースのアクセス制御 (RBAC) システムで特権ユーザーを保護します。
- リスクの高いユーザーとサインインには、パスワードの変更と多要素認証が必要です (サインインの頻度によって適用)。
- リスクの高いデバイスからのアクセスを制限します。 条件付きアクセスのコンプライアンス チェックで Intune コンプライアンス ポリシーを使用します。
- Office 365、Azure、AWS、Google Cloud の管理者ポータルへのアクセスなど、特権システムを保護します。
- 管理者と信頼されていないデバイスでの永続的なブラウザー セッションを防止します。
- レガシ認証をブロックします。
- 不明またはサポートされていないデバイス プラットフォームからのアクセスを制限します。
- 可能な場合は、リソースへのアクセスに準拠しているデバイスが必要です。
- 強力な資格情報の登録を制限します。
- 停止する前に適切な条件が満たされていれば、停止が発生してもセッションを続行できる既定のセッション ポリシーを使用することを検討してください。
設計の依存関係と関連テクノロジ
次の図は、依存関係と関連テクノロジを示しています。 一部のテクノロジは、条件付きアクセスの前提条件です。 それ以外は条件付きアクセスに依存します。 このドキュメントで説明する設計では、主に、関連するテクノロジではなく、条件付きアクセスに焦点を当てています。
条件付きアクセスのガイダンス
詳細については、「ゼロトラストとペルソナに基づく条件付きアクセスの設計」を参照してください。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパル作成者:
- Claus Jespersen | プリンシパル コンサルタント ID と Sec
パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。