次の方法で共有


条件付きアクセスのフレームワークとポリシー

この記事では、「条件付きアクセスのゼロ トラスト アーキテクチャ」で説明されているような、ペルソナ ベースの条件付きアクセス アーキテクチャを実装するためのフレームワークについて説明します。 この記事では、条件付きアクセス ポリシーを作成して名前を指定する方法について詳しく説明します。 ポリシーを作成するための出発点も示します。

ここで提供するようなフレームワーク (名前付け標準を含む) を使用しない場合、ポリシーは時間の経過と共に異なるユーザーによってアドホックな方法で作成される傾向があります。 これにより、ポリシーが重複するようになる可能性があります。 ポリシーを作成したユーザーがいなくなった場合、他のユーザーがそのポリシーの目的を把握することが困難になることがあります。

構造化されたフレームワークに従うことで、ポリシーを簡単に理解できるようになります。 また、すべてのシナリオに対応し、トラブルシューティングが困難なポリシーの競合を回避することもできます。

名前付け規則

適切に定義された名前付け規則を使用すると、同僚がポリシーの目的を理解するのに役立ち、ポリシーの管理とトラブルシューティングが容易になります。 命名規則は、ポリシーの作成に使うフレームワークに適合している必要があります。

推奨される名前付けポリシーは、ペルソナ、ポリシーの種類、アプリに基づいています。 これは、次のような内容です。

<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 このポリシーの種類は、基本保護の上位の追加レイヤーとしてデータを保護するデルタ ポリシーを示します。

例:
  • 携帯電話でデータを暗号化し、そのデータの保護を強化するために使用できる、iOS および Android 用のアプリ保護ポリシー。 (アプリ保護ポリシーには、アプリ保護も含まれます)。
  • データが機密情報である場合に、Azure Information Protection がダウンロード中にデータをセキュリティで保護するのに役立つセッション ポリシー。
AppProtection このポリシーの種類は、基本保護に対するもう 1 つの追加です。

例 :
  • 任意のデバイスからの Exchange Online への Web アクセスを許可するとします。 基本ポリシーから Exchange を除外し、Exchange へのアクセス用に新しい明示的なポリシーを作成することができます。たとえば、Exchange Online への読み取り専用アクセスのみを許可します。
  • Microsoft エンドポイント マネージャーの登録に多要素認証が必要であるとします。 基本ポリシーから Intune のエンドポイント マネージャー登録を除外し、エンドポイント マネージャー登録に多要素認証を必要とするアプリ保護ポリシーを追加することができます。
AttackSurfaceReduction この種類のポリシーの目的は、さまざまな攻撃を軽減することです。

例 :
  • 不明なプラットフォームからアクセスが試みられた場合、特定のプラットフォームを必要とする条件付きアクセス ポリシーをバイパスしようとしている可能性があります。 不明なプラットフォームからの要求をブロックして、このリスクを軽減することができます。
  • Azure 管理者の Office 365 サービスへのアクセスをブロックするか、アプリが不適切であることがわかっている場合は、すべてのユーザーについてアプリへのアクセスをブロックします。
コンプライアンス コンプライアンス ポリシーを使用して、カスタマー サービスにアクセスするゲスト向けの使用条件を見るようユーザーに要求することができます。

アプリ

次の表では、ポリシー名のアプリ コンポーネントについて説明します。

アプリの名前 説明/例
AllApps AllApps は、すべてのクラウド アプリが条件付きアクセス ポリシーの対象であることを示します。 条件付きアクセスをサポートしているものとそうでないものを含む、すべてのエンドポイントが対象となります。 シナリオによっては、すべてのアプリを対象にするとうまくいかないことがあります。 基本ポリシーでは、すべてのエンドポイントがそのポリシーでカバーされるように、すべてのアプリを対象にすることをお勧めします。 Microsoft Entra ID に追加される新しいアプリも、自動的にそのポリシーに準拠するようになります。
<AppName> <AppName> は、ポリシーが対応するアプリの名前のプレースホルダーです。 名前が長くなりすぎないようにしてください。

名前の例:
  • Exchange Online の場合は EXO
  • SharePoint Online の場合は SPO

プラットフォームの種類

次の表では、ポリシー名のプラットフォーム コンポーネントについて説明します。

プラットフォームの種類 説明
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 つの方法を次に示します。

Diagram that shows a Conditional Access deployment model.

考え方として、まず 1 つのペルソナ グループ内の少数のユーザーにポリシーを展開します。 このデプロイには、Persona Ring 0 という名前の関連付けられた Microsoft Entra グループを使用できます。 すべてが機能することを確認した後、さらに多くのメンバーがいるペルソナ リング 1 グループに割り当てを変更します。

その後、すべてのポリシーが展開されるまで、同じリング ベースの方法を使用してポリシーを有効にします。

通常、リング 0 とリング 1 のメンバーは手動で管理します。 数百または数千ものユーザーを含むリング 2 または 3 グループは、特定のペルソナのユーザーの割合に基づく動的なグループを使って管理できます。

展開モデルの一部としてのリングの使用は、初期展開の場合だけではありません。 新しいポリシーまたは既存のポリシーに対する変更が必要な場合にも使用できます。

展開が完了したら、「条件付きアクセスの原則」で説明されている監視の制御も設計して実装する必要があります。

初期展開を自動化するだけでなく、CI/CD パイプラインを使ってポリシーの変更を自動化することもできます。 この自動化には Microsoft365DSC を使用できます。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパル作成者:

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ