条件付きアクセスのフレームワークとポリシー
この記事では、「条件付きアクセスのゼロ トラスト アーキテクチャ」で説明されているような、ペルソナ ベースの条件付きアクセス アーキテクチャを実装するためのフレームワークについて説明します。 この記事では、条件付きアクセス ポリシーを作成して名前を指定する方法について詳しく説明します。 ポリシーを作成するための出発点も示します。
ここで提供するようなフレームワーク (名前付け標準を含む) を使用しない場合、ポリシーは時間の経過と共に異なるユーザーによってアドホックな方法で作成される傾向があります。 これにより、ポリシーが重複するようになる可能性があります。 ポリシーを作成したユーザーがいなくなった場合、他のユーザーがそのポリシーの目的を把握することが困難になることがあります。
構造化されたフレームワークに従うことで、ポリシーを簡単に理解できるようになります。 また、すべてのシナリオに対応し、トラブルシューティングが困難なポリシーの競合を回避することもできます。
名前付け規則
適切に定義された名前付け規則を使用すると、同僚がポリシーの目的を理解するのに役立ち、ポリシーの管理とトラブルシューティングが容易になります。 命名規則は、ポリシーの作成に使うフレームワークに適合している必要があります。
推奨される名前付けポリシーは、ペルソナ、ポリシーの種類、アプリに基づいています。 これは、次のような内容です。
<CANumber>-<Persona>-<PolicyType>-<App>-<Platform>-<GrantControl>-<OptionalDescription>
以下では、この名前のコンポーネントについて説明します。
| 名前付けコンポーネント | 説明/例 |
|---|---|
| CA 番号 | ポリシーの種類のスコープと順序をすばやく識別するために使われます。 例: CA001 - CA099。 |
| ペルソナ | Global、Admins、Internals、Externals、GuestUsers、GuestAdmins、Microsoft365ServiceAccounts、AzureServiceAccounts、CorpServiceAccounts。 |
| ポリシーの種類 | BaseProtection、AppProtection、DataProtection、IdentityProtection、AttackSurfaceReduction、Compliance。 |
| アプリ | AllApps、O365 (すべての Office 365 サービスの場合)、EXO (Exchange Online の場合)。 |
| プラットフォーム | AnyPlatform、Unknown、WindowsPhone、macOS、iOS、Android。 |
| 付与の制御 | Block、ADHJ、Compliant、Unmanaged (アンマネージドはデバイスの状態の条件で指定されます)。 |
| 説明 | ポリシーの目的についての省略可能な説明。 |
番号付けスキーム
管理を簡単にするため、この番号付けスキームをお勧めします。
| ペルソナ グループ | 番号の割り当て |
|---|---|
| CA-Persona-Global | CA001 - CA099 |
| CA-Persona-Admins | CA100 - CA199 |
| CA-Persona-Internals | CA200 - CA299 |
| CA-Persona-Externals | CA300 - CA399 |
| CA-Persona-GuestUsers | CA400 - CA499 |
| CA-Persona-GuestAdmins | CA500 - CA599 |
| CA-Persona-M365ServiceAccounts | CA600 - CA699 |
| CA-Persona-AzureServiceAccounts | CA700 - CA799 |
| CA-Persona-CorpServiceAccounts | CA800 - CA899 |
| CA-Persona-WorkloadIdentities | CA900 - CA999 |
| CA-Persona-Developers | CA1000 - CA1099 |
ポリシーの種類
推奨されるポリシーの種類は次のとおりです。
| ポリシーの種類 | 説明/例 |
|---|---|
| BaseProtection | ペルソナごとに、このポリシーの種類によってカバーされるベースライン保護があります。 マネージド デバイスのユーザーの場合、通常、これは既知のユーザーと既知のデバイスです。 外部のゲストの場合、既知のユーザーと多要素認証である場合があります。 基本保護は、特定のペルソナのユーザーに対するすべてのアプリの既定のポリシーです。 特定のアプリに別のポリシーが必要な場合は、そのアプリを基本保護ポリシーから除外し、そのアプリのみを対象とする明示的なポリシーを追加します。 例: Internals の基本保護は、すべてのクラウド アプリについて既知のユーザーと既知のデバイスを要求することですが、Outlook on the web はすべてのデバイスから許可するものとします。 基本保護ポリシーから Exchange Online を除外し、既知のデバイスまたは多要素認証を必要とする Exchange Online 用に別のポリシーを追加することができます。 |
| IdentityProtection | 各ペルソナの基本保護に加えて、ID に関連する条件付きアクセス ポリシーを設定できます。 例: レガシ認証をブロックし、高いユーザーまたはサインインのリスクに対して追加の多要素認証を必要とし、多要素認証の登録には既知のデバイスを必要とします。 |
| DataProtection | このポリシーの種類は、基本保護の上位の追加レイヤーとしてデータを保護するデルタ ポリシーを示します。 例:
|
| AppProtection | このポリシーの種類は、基本保護に対するもう 1 つの追加です。 例 :
|
| AttackSurfaceReduction | この種類のポリシーの目的は、さまざまな攻撃を軽減することです。 例 :
|
| コンプライアンス | コンプライアンス ポリシーを使用して、カスタマー サービスにアクセスするゲスト向けの使用条件を見るようユーザーに要求することができます。 |
アプリ
次の表では、ポリシー名のアプリ コンポーネントについて説明します。
| アプリの名前 | 説明/例 |
|---|---|
| AllApps | AllApps は、すべてのクラウド アプリが条件付きアクセス ポリシーの対象であることを示します。 条件付きアクセスをサポートしているものとそうでないものを含む、すべてのエンドポイントが対象となります。 シナリオによっては、すべてのアプリを対象にするとうまくいかないことがあります。 基本ポリシーでは、すべてのエンドポイントがそのポリシーでカバーされるように、すべてのアプリを対象にすることをお勧めします。 Microsoft Entra ID に追加される新しいアプリも、自動的にそのポリシーに準拠するようになります。 |
| <AppName> | <AppName> は、ポリシーが対応するアプリの名前のプレースホルダーです。 名前が長くなりすぎないようにしてください。 名前の例:
|
プラットフォームの種類
次の表では、ポリシー名のプラットフォーム コンポーネントについて説明します。
| プラットフォームの種類 | 説明 |
|---|---|
| AnyPlatform | ポリシーの対象はすべてのプラットフォームです。 通常は、[任意のデバイス] を選ぶことでこれを構成します。 (条件付きアクセス ポリシーでは、"プラットフォーム" と "デバイス" の両方が使用されます)。 |
| iOS | このポリシーは、Apple iOS プラットフォームが対象です。 |
| Android | このポリシーは、Google Android プラットフォームが対象です。 |
| Windows | このポリシーは、Windows プラットフォームが対象です。 |
| Linux | このポリシーは、Linux プラットフォームが対象です。 |
| WindowsPhone | このポリシーは、Windows Phone プラットフォームが対象です。 |
| macOS | このポリシーは、macOS プラットフォームが対象です |
| iOSAndroid | このポリシーは、iOS と Android の両方のプラットフォームが対象です。 |
| Unknown | このポリシーは、それまでに出てきていないすべてのプラットフォームが対象です。 通常、これはすべてのデバイスを含め、すべての個別のプラットフォームを除外することによって構成します。 |
付与の制御の種類
次の表では、ポリシー名の付与の制御コンポーネントについて説明します。
| [付与タイプ] | 説明/例 |
|---|---|
| ブロック | ポリシーによってサインインがブロックされます |
| MFA | このポリシーでは、多要素認証が必要です。 |
| 対応 | このポリシーでは、エンドポイント マネージャーによって決定される準拠デバイスが必要であるため、デバイスをエンドポイント マネージャーで管理する必要があります。 |
| CompliantorAADHJ | このポリシーでは、準拠しているデバイス "または" Microsoft Entra ハイブリッド参加済みデバイスが必要です。 ドメイン参加している標準の会社のコンピューターは、ハイブリッド Microsoft Entra ID 参加済みでもあります。 共同管理されているか Microsoft Entra 参加済みである携帯電話および Windows 10 コンピューターは、準拠しているとすることができます。 |
| CompliantandAADHJ | このポリシーでは、準拠している "かつ" Microsoft Entra ハイブリッド参加済みであるデバイスが必要です。 |
| MFAorCompliant | このポリシーには、準拠デバイスか、準拠していない場合は多要素認証が必要です。 |
| MFAandCompliant | このポリシーには、準拠デバイスと多要素認証の両方が必要です。 |
| MFAorAADHJ | このポリシーでは、Microsoft Entra ハイブリッド参加済みコンピューター "または" 多要素認証 (Microsoft Entra ハイブリッド参加済みコンピューターではない場合) が必要です。 |
| MFAandAADHJ | このポリシーでは、Microsoft Entra ハイブリッド参加済みコンピューター "および" 多要素認証が必要です。 |
| RequireApprovedClient | このポリシーには、承認されたクライアント アプリが必要です。 |
| AppProtection | このポリシーには、アプリ保護が必要です |
| アンマネージド | このポリシーは、Microsoft Entra ID によって認識されていないデバイスを対象とします。 たとえば、この付与の種類を使って、任意のデバイスから Exchange Online へのアクセスを許可できます。 |
ネームド ロケーション
条件付きアクセス ポリシーで使用するために、次の標準の場所を定義することをお勧めします。
- 信頼できる IP と内部ネットワーク。 これらの IP サブネットは、コンピューター システムの管理、ネットワーク レベルの認証、侵入検出など、物理的なアクセス制限やその他の制御が実施されている場所とネットワークを表します。 これらの場所は安全性が高いので、条件付きアクセスの適用を緩和できます。 Azure または他のデータセンターの場所 (IP) をこの場所に含めるか、または独自のネームド ロケーションを使用するかを検討します。
- Citrix で信頼された IP。 オンプレミスに Citrix がある場合で、Citrix セッションからクラウド サービスに接続できるようにする必要がある場合は、Citrix ファーム用に個別の発信 IPv4 アドレスを構成すると便利な場合があります。 その場合は、必要に応じて、それらの場所を条件付きアクセス ポリシーから除外することができます。
- Zscaler の場所 (該当する場合)。 コンピューターに ZPA エージェントがインストールされていて、インターネットへのすべてのトラフィックが Zscaler クラウドに、またはそこを経由して転送されます。 そのため、条件付きアクセスで Zscaler のソース IP を定義し、モバイル デバイス以外からのすべての要求が Zscaler を経由するよう要求する必要があります。
- ビジネスが許可されている国/リージョン。 国/リージョンを 2 つのロケーション グループに分割すると便利な場合があります：1 つは従業員が通常働いている世界の領域を表し、もう 1 つは他の場所を表します。 これにより、組織が通常活動している地域の外部から発信された要求に対して、追加の制御を適用できます。
- 多要素認証が困難または不可能な場合がある場所。 状況によっては、多要素認証を必要とすると、従業員が作業を行うのが困難になることがあります。 たとえば、スタッフには、多要素認証の頻繁なチャレンジに対応する時間や機会がない可能性があります。 または、場所によっては、RF スクリーニングや電気的干渉によって、モバイル デバイスの使用が困難になることがあります。 通常、そのような場所では他の制御を使うか、信頼されている可能性があります。
場所ベースのアクセス制御では、要求の送信元 IP を使って、要求時のユーザーの場所を特定します。 パブリック インターネットでスプーフィングを実行するのは簡単ではありませんが、ネットワーク境界によって提供される保護は、以前より関連性が低いと見なされるようになっている可能性があります。 アクセスの条件として場所のみに依存することはお勧めしません。 ただし、非対話型のシナリオで使用される、オンプレミスのサービス アカウントからのアクセスをセキュリティで保護する場合のような、一部のシナリオでは、使用できる最適な制御である可能性があります。
推奨される条件付きアクセス ポリシー
推奨される条件付きアクセス ポリシーを含むスプレッドシートを作成しました。 こちらからそのスプレッドシートをダウンロードできます。
提案されたポリシーを出発点として使用してください。
ビジネスにとって重要なユース ケースに対応するため、ポリシーは時間の経過と共におそらく変化します。 次に、変更が必要になる可能性のあるシナリオの例をいくつか示します。
- 多要素認証、アプリの保護、承認されたクライアント アプリに基づいて、アンマネージド デバイスを使用する従業員を対象に、Exchange Online への読み取り専用アクセスを実装します。
- Azure Information Protection によって提供される強化された保護を使わずに機密情報がダウンロードされないように、情報保護を実装します。
- ゲストによるコピーと貼り付けに対する保護を提供します。
現在、複数のプレビューがパブリック プレビューに入っているため、推奨される条件付きアクセス (CA) スターター ポリシーのセットの更新が間もなく行われます。
条件付きアクセスのガイダンス
条件付きアクセス ポリシーのスターター セットが用意できたので、それらを制御された段階的な方法で展開する必要があります。 展開モデルを使うことをお勧めします。
1 つの方法を次に示します。
考え方として、まず 1 つのペルソナ グループ内の少数のユーザーにポリシーを展開します。 このデプロイには、Persona Ring 0 という名前の関連付けられた Microsoft Entra グループを使用できます。 すべてが機能することを確認した後、さらに多くのメンバーがいるペルソナ リング 1 グループに割り当てを変更します。
その後、すべてのポリシーが展開されるまで、同じリング ベースの方法を使用してポリシーを有効にします。
通常、リング 0 とリング 1 のメンバーは手動で管理します。 数百または数千ものユーザーを含むリング 2 または 3 グループは、特定のペルソナのユーザーの割合に基づく動的なグループを使って管理できます。
展開モデルの一部としてのリングの使用は、初期展開の場合だけではありません。 新しいポリシーまたは既存のポリシーに対する変更が必要な場合にも使用できます。
展開が完了したら、「条件付きアクセスの原則」で説明されている監視の制御も設計して実装する必要があります。
初期展開を自動化するだけでなく、CI/CD パイプラインを使ってポリシーの変更を自動化することもできます。 この自動化には Microsoft365DSC を使用できます。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパル作成者:
- Claus Jespersen | プリンシパル コンサルタント ID と Sec
パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。
次のステップ
関連リソース
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示