条件付きアクセス フレームワークとポリシー
この記事では、「条件付きアクセスゼロ トラスト アーキテクチャ 」で説明されているように、ペルソナベースの条件付きアクセス アーキテクチャ実装するためのフレームワークを提供します。 この記事では、条件付きアクセス ポリシーを形成して名前を付ける方法について詳しく説明します。 ポリシーを作成するための出発点もあります。
ここで提供されているようなフレームワーク (名前付け標準を含む) を使用しない場合、ポリシーは時間の経過と同時に、アドホックな方法で異なるユーザーによって作成される傾向があります。 これにより、ポリシーが重複する可能性があります。 ポリシーを作成したユーザーが使用できなくなった場合、他のユーザーがポリシーの目的を知りにくい場合があります。
構造化されたフレームワークに従うと、ポリシーを理解しやすくなります。 また、すべてのシナリオを簡単にカバーでき、トラブルシューティングが困難なポリシーの競合を回避できます。
名前付け規則
適切に定義された名前付け規則は、ポリシーの目的を理解するのに役立ちます。これにより、ポリシーの管理とトラブルシューティングが容易になります。 名前付け規則は、ポリシーの構成に使用するフレームワークに適合している必要があります。
推奨される名前付けポリシーは、ペルソナ、ポリシーの種類、アプリに基づいています。 次のようになります。
<CANumber>-<Persona>-<PolicyType>-<App>-<Platform>-<GrantControl>-<OptionalDescription>
この名前のコンポーネントを次に示します。
| 名前付けコンポーネント | 説明/例 |
|---|---|
| CA 番号 | ポリシーの種類のスコープと順序をすばやく識別するために使用されます。 例: CA001-CA099。 |
| ペルソナ | グローバル、管理者、インターナル、エクスターナル、ゲストユーザー、ゲスト管理者、Microsoft365サービスアカウント、Azureサービスアカウント、企業サービスアカウント。 |
| ポリシーの種類 | BaseProtection、AppProtection、DataProtection、IdentityProtection、AttackSurfaceReduction、Compliance。 |
| アプリ | AllApps、O365 (すべての Office 365 サービス用)、EXO (Exchange Online 用)。 |
| プラットホーム | AnyPlatform、Unknown、WindowsPhone、macOS、iOS、Android。 |
| 制御権の付与 | ブロック、ADHJ、準拠、アンマネージド (デバイスの状態条件でアンマネージドが指定されている場合)。 |
| 説明 | ポリシーの目的の説明 (省略可能)。 |
番号付けスキーム
管理を容易にするために、次の番号付けスキームをお勧めします。
| Persona グループ | 番号の割り当て |
|---|---|
| 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 用の別のポリシーを追加できます。 |
| アイデンティティ保護 | 各ペルソナの基本保護の上に、ID に関連する条件付きアクセス ポリシーを設定できます。 例: レガシ認証をブロックし、高いユーザーまたはサインイン リスクに対して追加の多要素認証を必要とし、多要素認証の登録に既知のデバイスを必要とします。 |
| データ保護 | このポリシーの種類は、基本保護の上に追加レイヤーとしてデータを保護するデルタ ポリシーを示します。 例：
|
| AppProtection | このポリシーの種類は、基本保護にもう 1 つの追加機能です。 例：
|
| AttackSurfaceReduction | この種のポリシーの目的は、さまざまな攻撃を軽減することです。 例：
|
| コンプライアンス | コンプライアンス ポリシーを使用して、顧客サービスにアクセスするゲストの利用規約の表示をユーザーに要求できます。 |
アプリ
次の表では、ポリシー名のアプリ コンポーネントについて説明します。
| アプリ名 | 説明/例 |
|---|---|
| AllApps | AllApps は、すべてのクラウド アプリが条件付きアクセス ポリシーの対象であることを示します。 条件付きアクセスをサポートするものやサポートしていないエンドポイントなど、すべてのエンドポイントについて説明します。 一部のシナリオでは、すべてのアプリをターゲットにすることはできません。 すべてのエンドポイントがそのポリシーでカバーされるように、基本ポリシー内のすべてのアプリを対象にすることをお勧めします。 Microsoft Entra ID に表示される新しいアプリも、ポリシーに自動的に準拠します。 |
| <AppName> | <AppName> は、ポリシーがアドレス指定するアプリの名前のプレースホルダーです。 名前を長くしないでください。 名前の例:
|
プラットフォームの種類
次の表では、ポリシー名のプラットフォーム コンポーネントについて説明します。
| プラットフォームの種類 | 説明 |
|---|---|
| AnyPlatform | このポリシーは、任意のプラットフォームを対象としています。 通常、これを構成するには、任意のデバイスを選択します。 (条件付きアクセス ポリシーでは、"プラットフォーム" という単語と "デバイス " という単語の両方が使用されます)。 |
| iOS | このポリシーは、Apple iOS プラットフォームを対象としています。 |
| アンドロイド | このポリシーは Google Android プラットフォームを対象としています。 |
| ウィンドウズ | このポリシーは、Windows プラットフォームを対象としています。 |
| Linux | このポリシーは Linux プラットフォームを対象としています。 |
| WindowsPhone | このポリシーは、Windows Phone プラットフォームを対象としています。 |
| macOS | このポリシーは macOS プラットフォームを対象としています |
| iOSAndroid | このポリシーは、iOS プラットフォームと Android プラットフォームの両方を対象としています。 |
| 不明 | このポリシーは、以前に一覧表示されていないプラットフォームを対象としています。 通常、これはすべてのデバイスを含め、すべての個別のプラットフォームを除外することによって構成します。 |
コントロールの種類を付与する
次の表では、ポリシー名の Grant Control コンポーネントについて説明します。
| 許可の種類 | 説明/例 |
|---|---|
| Block | ポリシーによってサインインがブロックされる |
| 美術学修士 (MFA) | このポリシーには多要素認証が必要です。 |
| 対応 | このポリシーには、エンドポイント マネージャーによって決定される準拠デバイスが必要であるため、デバイスをエンドポイント マネージャーで管理する必要があります。 |
| CompliantorAADHJ | ポリシーには、準拠しているデバイスまたは Microsoft Entra ハイブリッド参加済みデバイスが必要です。 ドメインに参加している会社の標準コンピューターも、Hybrid Microsoft Entra ID 参加済みです。 共同管理または Microsoft Entra に参加している携帯電話と Windows 10 コンピューターは準拠している可能性があります。 |
| CompliantandAADHJ | このポリシーには、準拠しているデバイスと Microsoft Entra ハイブリッド参加済みデバイスが必要です。 |
| MFAorCompliant | ポリシーが準拠していない場合は、ポリシーに準拠しているデバイスまたは多要素認証が必要です。 |
| MFAandCompliant | ポリシーには、準拠しているデバイスと多要素認証が必要です。 |
| MFAまたはAADHJ | このポリシーには、Microsoft Entra ハイブリッド参加済みコンピューターではない場合は、Microsoft Entra ハイブリッド参加済みコンピューターまたは多要素認証が必要です。 |
| MFAandAADHJ | このポリシーには、Microsoft Entra ハイブリッド参加済みコンピューターと多要素認証が必要です。 |
| 承認されたクライアントが必要 | ポリシーには、承認されたクライアント アプリが必要です。 |
| 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 グループを使用できます。 すべてが正常に機能することを確認したら、割り当てをメンバー数の多いグループである Persona Ring 1 に変更し、その後さらに進めます。
その後、すべてのポリシーがデプロイされるまで、同じリングベースのアプローチを使用してポリシーを有効にします。
通常、リング 0 とリング 1 のメンバーは手動で管理します。 数百または数千のユーザーを含むリング 2 または 3 グループは、特定のペルソナ内のユーザーの割合に基づく動的グループを使用して管理できます。
デプロイ モデルの一部としてリングを使用することは、初期デプロイだけではありません。 また、新しいポリシーや既存のポリシーへの変更が必要な場合にも使用できます。
デプロイが完了したら、条件付きアクセスの原則で説明した監視コントロールも設計して実装する必要があります。
初期デプロイを自動化するだけでなく、CI/CD パイプラインを使用してポリシーの変更を自動化することもできます。 この自動化には Microsoft365DSC を使用できます。
貢献者
この記事は Microsoft によって管理されています。 もともとは次の共同作成者によって作成されました。
主要な著者
- クラウス ジェスペルセン |プリンシパル コンサルタント ID&Sec
非公開の LinkedIn プロファイルを表示するには、LinkedIn にサインインします。
次の手順
- ラーニング パス: ID とアクセス を実装および管理する
- 条件付きアクセス ポリシー
関連リソース
- 条件付きアクセスの概要
- 条件付きアクセスの設計原則と依存関係の
- ゼロ トラストとペルソナに基づく条件付きアクセスの設計