条件付きアクセス ポリシーを計画する
アプリとリソースに関する組織のアクセス戦略を実現するために、条件付きアクセスのデプロイを計画することが重要です。
モバイルを重視したクラウド中心の世界では、ユーザーはさまざまなデバイスやアプリを使用してどこからでも組織のリソースにアクセスします。 このため、だれがリソースにアクセスできるかに重点を置くだけでは十分ではなくなっています。 また、ユーザーがいる場所、使用されるデバイス、アクセスされるリソースなども考慮する必要があります。
Microsoft Entra の条件付きアクセス (CA)では、ユーザー、デバイス、場所などのシグナルを分析して、意思決定を自動化し、リソースに関する組織のアクセス ポリシーを適用します。 CA ポリシーを使用して、多要素認証 (MFA) などのアクセス制御を適用できます。 CA ポリシーを使用すると、セキュリティのために必要な場合はユーザーに MFA を要求し、不要な場合はユーザーに対して何も行わないようにすることができます。
セキュリティの既定値群では、基本的なレベルのセキュリティが保証されますが、組織では、セキュリティの既定群の設定よりも高い柔軟性が必要です。 CA を使用すると、より細かい粒度でセキュリティの既定値をカスタマイズしたり、要件を満たす新しいポリシーを構成したりできます。
メリット
条件付きアクセスを導入することの利点は以下の通りです。
- 生産性を向上させる - 1 つ以上のシグナルが必要な場合にのみ、MFA などのサインイン状態でユーザーを中断します。 CA ポリシーを使用すると、ユーザーに MFA を求めるプロンプトをいつ出すか、アクセスをいつブロックするか、ユーザーが信頼できるデバイスをいつ使用する必要があるかを制御できます。
- リスクの管理 - ポリシー条件を使用してリスク評価を自動化すると、リスクの高いサインインが一度に特定され、修復またはブロックされます。 条件付きアクセスと ID 保護を組み合わせることで、異常および疑わしいイベントが検出され、リソースへのアクセスをいつブロックまたは締め出すかを制御できます。
- コンプライアンスとガバナンスに対処する - 条件付きアクセスを使用すると、アプリケーションへのアクセスを監査したり、同意の使用条件を提示したり、コンプライアンス ポリシーに基づいてアクセスを制限したりできます。
- コストの管理 - アクセス ポリシーを Microsoft Entra ID に移行すると、CA とそのインフラストラクチャ コストに対するカスタム またはオンプレミス ソリューションへの依存が軽減されます。
- ゼロ トラスト - 条件付きアクセスは、ゼロトラスト環境に移行するのに役立ちます。
条件付きアクセス ポリシーのコンポーネントについて
CA ポリシーは if-then ステートメントです。割り当てが満たされた場合、それらのアクセス制御が適用されます。 管理者が CA ポリシーを構成すると、条件は 割り当てと呼ばれます。 CA ポリシーを使用すると、特定の割り当てに基づいて組織のアプリに対してアクセス制御を適用できます。
割り当てでは、ポリシーの影響を受けるユーザーとグループ、ポリシーが適用されるクラウド アプリまたは操作、ポリシーが適用される条件が定義されます。 アクセス制御設定により、さまざまなクラウド アプリへのアクセスが許可またはブロックされ、特定のクラウド アプリ内でのエクスペリエンスの制限が可能になります。
割り当て、アクセス制御、セッション制御に関してよく寄せられる質問を次に示します。
- ユーザーとグループ: どのユーザーやグループがポリシーに含まれますか? またはポリシーから除外されますか? このポリシーには、すべてのユーザー、特定のユーザー グループ、ディレクトリ ロール、または外部のユーザーを含めますか?
- クラウド アプリまたはアクション:どのアプリケーションにこのポリシーを適用しますか? どのようなユーザー アクションがこのポリシーの対象となりますか?
- 条件: ポリシーに含まれる、またはポリシーから除外されるデバイス プラットフォームはどれですか? 組織の信頼できる場所は何ですか?
- アクセスの制御:MFA、準拠としてマーク済みのデバイス、Microsoft Entra ハイブリッド参加済みデバイスなどの要件を実装して、リソースへのアクセスを許可しますか?
- セッション制御: アプリのアクセス許可適用や、アプリの条件付きアクセス制御などの要件を実装して、クラウド アプリへのアクセスを制御しますか?
アクセス トークンの発行
アクセス トークンによってクライアントは、保護された Web API を安全に呼び出すことができ、Web API はアクセス トークンを使用して、認証と認可を実行します。 OAuth 仕様では、アクセス トークンは、設定された形式を持たない不透明型の文字列です。 ID プロバイダー (IDP) には、GUID を使用するものと、暗号化された BLOB を使用するものがあります。 Microsoft ID プラットフォームでは、トークンを受け入れる API の構成に応じて、さまざまなアクセス トークン形式が使用されます。
アクセス トークンがどのように発行されるかを理解することが重要です。
注
割り当てが不要で、CA ポリシーが適用されていない場合、既定の動作ではアクセス トークンが発行されます。
たとえば、次のようなポリシーを考えてみます。
ユーザーが Group 1 に所属している場合、App 1 へのアクセスに対して MFA を適用します。
グループ 1 以外のユーザーがアプリにアクセスしようとすると、 "if" 条件が満たされ、トークンが発行されます。 Group 1 の外部のユーザーを除外するには、他のすべてのユーザーをブロックする個別のポリシーが必要になります。
ベスト プラクティスに従う
条件付きアクセスのフレームワークでは、構成の柔軟性が優れています。 ただし、柔軟性が高いということは、リリースの前に各構成ポリシーを慎重に見直して、望ましくない結果を避ける必要があることも意味します。
緊急アクセス用アカウントを設定する
ポリシーを誤って構成した場合、それによって Azure portal から組織がロックアウトされる可能性があります。 組織で緊急アクセス用アカウントを 2 つ以上作成することで、誤った管理者のロックアウトを軽減します。 緊急アクセスアカウントの詳細については、このコースの後半で学習します。
レポート専用モードを設定する
次のような一般的なデプロイ イニシアチブの影響を受けるユーザーの数と名前を予測することは困難です。
- レガシ認証のブロック。
- MFA が必須。
- サインイン リスク ポリシーの実装。
レポート専用モードを使用すると、管理者は、環境で CA ポリシーを有効にする前に、CA ポリシーを評価できます。
サインイン元であることが想定されない国を除外する
Microsoft Entra ID では、ネームド ロケーションを作成できます。 サインインが発生することがほとんどないすべての国を含むネームド ロケーションを作成します。 次に、そのネームド ロケーションからのサインインをブロックする、すべてのアプリ用のポリシーを作成します。 このポリシーから管理者を除外してください。
一般的なポリシー
CA ポリシー ソリューションを計画するときは、次の結果を達成するためにポリシーを作成する必要があるかどうかを評価します。
MFA を必須にする。 一般的なユース ケースでは、管理者による、特定のアプリへの、すべてのユーザーの、または信頼されていないネットワークの場所からの MFA が必要です。
侵害された可能性があるアカウントへの応答。 3 つの既定のポリシーを有効にすることができます。すべてのユーザーに MFA への登録を要求すること、リスクの高いユーザーにパスワードの変更を要求すること、またはサインイン リスクが中程度か高いユーザーに MFA を要求することです。
マネージド デバイスを必須にする。 クラウド リソースへのアクセスでサポートされるデバイスの急増は、ユーザーの生産性の向上に役立ちます。 環境内の特定のリソースに、保護レベルが不明なデバイスがアクセスするのは望ましくない場合があります。 これらのリソースについては、ユーザーがマネージド デバイスを使用した場合に限りアクセスできるようにする必要があります。
承認済みクライアント アプリケーションを必須にする。 従業員は個人的な作業と業務上の作業のどちらにもモバイル デバイスを使用します。 BYOD のシナリオでは、デバイス全体を管理するか、またはデバイスのデータのみを管理するかを決定する必要があります。 データとアクセスのみを管理する場合は、企業のデータを保護できる承認済みクラウド アプリを必須にすることができます。
アクセスをブロックする。 アクセスをブロックすると、ユーザーの他のすべての割り当てが無効になり、組織全体からテナントへのサインオンをブロックすることができます。 たとえば、アプリを Microsoft Entra ID に移行するが、誰もまだサインインする準備ができていない場合などに使用できます。 また、特定のネットワークの場所からのクラウド アプリへのアクセスをブロックしたり、レガシ認証を使用するアプリからのテナント リソースへのアクセスをブロックしたりすることもできます。
重要
すべてのユーザーのアクセスをブロックするポリシーを作成する場合は、ポリシーから緊急アクセス用アカウントを必ず除外します。また、すべての管理者を除外することを検討してください。
ポリシーをビルドしてテストする
デプロイの各段階で必ず、結果が期待どおりであることを評価するようにします。
新しいポリシーの準備が整ったら、それらを運用環境で段階的にデプロイします。
- エンド ユーザーに内部的な変更通知を提供します。
- 少数のユーザーから始めて、ポリシーが想定どおりに動作することを確認します。
- より多くのユーザーが含まれるようにポリシーを拡げます。このとき、すべての管理者は引き続き除外します。 管理者を除外することで、変更が必要になった場合に、だれかがポリシーにアクセスできるようにします。
- ポリシーをすべてのユーザーに適用するのは、ポリシーを全面的にテストした後に限ります。 ポリシーが適用されない管理者アカウントが少なくとも 1 つあることを確認します。
テスト ユーザーの作成
運用環境のユーザーを反映する一連のテスト ユーザーを作成します。 テスト ユーザーを作成すると、実際のユーザーに適用して、アプリやリソースへのアクセスが中断される可能性が発生する前に、ポリシーが想定どおりに機能するか確認することができます。
この目的のためにテスト テナントを持っている組織もあります。 ただし、ポリシーの結果を完全にテストすることができるすべての条件とアプリをテスト テナントで再現することは困難な場合があります。
テスト計画の作成
テスト計画は、予想される結果と実際の結果を比較するために重要です。 何かをテストする前には、常に予想を用意しておきます。 次の表は、テスト ケースの例の概要です。 実際の CA ポリシーを構成する方法に基づいて、このシナリオと予想される結果を調整します。
| ポリシーの名前 | シナリオ | 予想される結果 |
|---|---|---|
| 作業時に MFA を要求する | 承認済みユーザーが、信頼できる場所または社内にいるときにアプリにサインインする | ユーザーは MFA を求められません。 ユーザーはアクセスが許可されています。 ユーザーは信頼できる場所から接続しています。 この場合は、MFA を必要とすることを選択できます。 |
| 作業時に MFA を要求する | 承認済みユーザーが、信頼できる場所または社内にいないときにアプリにサインインする | ユーザーには MFA が求められ、正常にサインインできます |
| (管理者に) MFA を要求する | グローバル管理者がアプリにサインインする | 管理者に多要素認証 (MFA) が求められます |
| リスクの高いサインイン | 未承認のブラウザーを使用してユーザーがアプリにサインインする | ユーザーに MFA が求められます |
| デバイス管理 | 承認済みユーザーが承認済みデバイスからサインインしようとする | アクセスが許可されます |
| デバイス管理 | 承認済みユーザーが承認されていないデバイスからサインインしようとする | アクセスはブロックされます |
| 危険なユーザーのパスワード変更 | 承認されたユーザーが、侵害された資格情報でサインインしようとする (リスクの高いサインイン) | ユーザーはパスワードを変更するよう求められるか、ポリシーに基づいてアクセスがブロックされます |
ライセンス要件
- 無料の Microsoft Entra ID - 条件付きアクセスなし
- 無料の Office 365 サブスクリプション - 条件付きアクセスなし
- Microsoft Entra ID Premium 1 (または Microsoft 365 E3 以降) - 標準ルールに基づく条件付きアクセスの機能
- Microsoft Entra ID Premium 2 - 条件付きアクセス。危険なサインイン、危険なユーザー、リスク ベースのサインイン オプションも使用できます (ID 保護から)