条件付きアクセスのデプロイを計画する
アプリとリソースに関する組織のアクセス戦略を実現するために、条件付きアクセスのデプロイを計画することが重要です。
Azure Active Directory (Azure AD) の条件付きアクセスは、ユーザー、デバイス、場所などのシグナルを分析して、決定を自動化し、リソースに関する組織のアクセス ポリシーを適用します。 条件付きアクセス ポリシーを使用して、セキュリティ コントロールを管理する条件を構築できます。必要に応じてアクセスをブロックしたり、多要素認証を要求したり、ユーザーのセッションを制限したりするが、必要がなければユーザーの邪魔をしない条件を設定できます。
この評価と強制によって、条件付きアクセスは、Microsoft のゼロ トラスト セキュリティ体制管理の基礎を定義します。
Microsoft では、Azure AD Premium を利用しないテナントでも基本レベルのセキュリティが有効であることを保証するセキュリティの既定値群を提供しています。 条件付きアクセスを使用すると、セキュリティの既定値群と同じ保護を提供するが、きめ細かな制御が可能なポリシーを作成できます。 条件付きアクセス ポリシーを作成するとセキュリティの既定値群を有効にできなくなるため、条件付きアクセスとセキュリティの既定値群を組み合わせることは想定されていません。
前提条件
Azure AD Premium または試用版ライセンスが有効になっていて、正常に動作している Azure AD テナント。 必要に応じて、無料で作成できます。
条件付きアクセスの管理者特権があるアカウント。
実際のユーザーに影響を与える前に、ポリシーが期待どおりに機能することを確認するためのテスト ユーザー (管理者以外)。 ユーザーを作成する必要がある場合は、「クイックスタート: Azure Active Directory に新しいユーザーを追加する」を参照してください。
管理者以外のユーザーが所属するグループ。 グループを作成する必要がある場合は、Azure Active Directory でグループを作成し、メンバーを追加する方法に関する記事を参照してください。
条件付きアクセス ポリシーのコンポーネントについて
ポリシーは、誰がリソースにアクセスするか、どのようなリソースにアクセスするか、どのような条件でアクセスするかについての質問に答えるものです。 ポリシーは、アクセスを許可するか、セッション制御を使用してアクセスを制限するか、またはアクセスをブロックするように設計できます。 if-then ステートメントを定義して、条件付きアクセス ポリシーを構築します。割り当てが満たされている場合、アクセス制御を適用します。
適切な質問をする
ここでは、割り当てとアクセス制御に関する一般的な質問をいくつか示します。 ポリシーを構築する前に、ポリシーごとに質問に対する回答を文書化します。
ユーザーまたはワークロード ID
どのユーザー、グループ、ディレクトリ ロール、ワークロード ID がポリシーに含まれますか? または、ポリシーから除外されますか?
どのような緊急アクセス用のアカウントまたはグループをポリシーから除外する必要がありますか?
クラウド アプリまたはアクション
このポリシーは、いずれかのアプリケーション、ユーザー操作、または認証コンテキストに適用されますか? 該当する場合、
- ポリシーをどのアプリケーションに適用しますか?
- どのようなユーザー アクションがこのポリシーの対象となりますか?
- このポリシーはどのような認証コンテキストに適用されますか?
条件
ポリシーに含める、またはポリシーから除外するデバイス プラットフォームはどれですか?
組織の信頼できる場所は何ですか?
ポリシーにどの場所を含め、どの場所を除外しますか?
どのクライアント アプリの種類をポリシーに含め、どれを除外しますか?
Azure AD 参加済みデバイスまたは Hybrid Azure AD 参加済みデバイスをポリシーから除外するポリシーはありますか?
ID 保護を使用する場合、サインイン リスク保護を組み込みますか?
許可またはブロック
次の 1 つ以上を必須としてリソースへのアクセスを許可しますか?
Require MFA (MFA が必須)
デバイスは準拠としてマーク済みである必要がある
ハイブリッド Azure AD 参加済みのデバイスを必要とする
承認済みクライアント アプリを必須にする
アプリの保護ポリシーを必須にする
パスワードの変更を必須とする
利用規約を使用する
セッション制御
クラウド アプリに次のアクセス制御を適用しますか?
アプリによって適用される制限を使用する
アプリの条件付きアクセス制御を使用する
サインインの頻度を適用する
永続的ブラウザー セッションを使用する
継続的アクセス評価をカスタマイズする
アクセス トークンの発行
アクセス トークンは、要求を行っているユーザーが認可および認証されているかどうかに基づいて、アクセスを許可または拒否します。 要求元は、自分が本人であることを証明できる場合、保護されたリソースまたは機能にアクセスできます。
条件付きアクセス ポリシー条件によってアクセス制御がトリガーされない場合、既定でアクセス トークンが発行されます。
これは、アプリで別の認可によってアクセスをブロックするのを妨げるものではありません。 たとえば、次のようなポリシーを考えてみます。
ユーザーが財務チームに属している場合、給与支払いアプリへのアクセス時に MFA を強制します。
財務チームに属していないユーザーが給与支払いアプリにアクセスしようとした場合、そのユーザーにはアクセス トークンが発行されます。
財務グループの外部のユーザーが給与支払いアプリにアクセスできないことを確実にするには、他のすべてのユーザーをブロックするポリシーを別途、作成する必要があります。 財務チームにも緊急アクセス アカウント グループにも属さないユーザーが給与支払いアプリにアクセスしようとした場合、アクセスをブロックします。
ベスト プラクティスに従う
条件付きアクセスは、優れた構成柔軟性を提供します。 ただし、柔軟性が高いということは、リリースの前に各構成ポリシーを慎重に見直して、望ましくない結果を避ける必要があることも意味します。
緊急アクセス用アカウントを設定する
ポリシーを誤って構成した場合、それによって Azure portal から組織がロックアウトされる可能性があります。
組織で緊急アクセス用アカウントを 2 つ以上作成することで、誤って管理者がロックアウトされた場合の影響を軽減します。 ポリシー管理専用のユーザー アカウントを作成し、すべてのポリシーから除外します。
条件付きアクセス ポリシーをすべてのアプリに適用する
すべてのアプリに少なくとも 1 つの条件付きアクセス ポリシーが適用されていることを確認してください。 セキュリティの観点からは、すべてのクラウド アプリに適用されるポリシーを作成してから、そのポリシーを適用したくないアプリケーションを除外することをお勧めします。 これにより、新しいアプリケーションをオンボードするたびに条件付きアクセス ポリシーを更新する必要がなくなります。
重要
1 つのポリシーでブロックとすべてのアプリを使用する場合は特に注意してください。 これにより、Azure portal から管理者がロックアウトされる可能性があります。また、Microsoft Graph などの重要なエンドポイントに対しては除外を構成できません。
条件付きアクセス ポリシーの数を最小限にする
アプリごとにポリシーを作成するのは効率的ではなく、管理が困難になります。 条件付きアクセスでは、ユーザーごとに最初の 195 個のポリシーのみが適用されます。 アプリを分析し、同じユーザーに対して同じリソース要件があるアプリケーションにそれらをグループ化することをお勧めします。 たとえば、すべての Microsoft 365 アプリまたはすべての HR アプリで同じユーザーに対して同じ要件がある場合、1 つのポリシーを作成し、それが適用されるすべてのアプリを含めます。
レポート専用モードを設定する
次のような一般的なデプロイ イニシアチブの影響を受けるユーザーの数と名前を予測することは困難です。
- レガシ認証のブロック
- MFA の要求
- サインイン リスク ポリシーの実装
レポート専用モードを使用すると、管理者は、環境で条件付きアクセス ポリシーを有効にする前に、その影響を評価できます。 まず、環境で適用する前に、ポリシーをレポート専用モードで構成して一定期間様子を見ます。
中断に対する計画を立てる
MFA や 1 つのネットワークの場所などの単一のアクセス制御に依存して IT システムをセキュリティ保護している場合、その単一のアクセス制御が使用不能になった場合や誤って構成された場合には、アクセス障害が発生する可能性があります。
予期しない中断が発生した場合のロックアウトのリスクを軽減するために、組織に導入する戦略を計画します。
ポリシーの名前付け基準を設定する
名前付け基準があると、Azure 管理ポータルでポリシーを開かなくても、ポリシーを見つけてその用途を理解することができます。 以下を示すようにポリシーの名前を設定することをお勧めします。
シーケンス番号
適用先のクラウド アプリ
応答
適用されるユーザー
いつ適用するか (該当する場合)
例: 外部ネットワークから Dynamics CRP アプリにアクセスするマーケティング ユーザーに対して MFA を要求するポリシーは次のようになります。
わかりやすい名前は、条件付きアクセスの実装の概要を把握するのに役立ちます。 シーケンス番号は、会話でポリシーを参照する必要がある場合に便利です。 たとえば、管理者と電話で話す場合、問題を解決するためにポリシー CA01 を開くように依頼できます。
緊急アクセス制御の名前付け基準
アクティブ ポリシーに加えて、機能停止や緊急状況のシナリオでセカンダリの回復性があるアクセス制御として機能する停止時のポリシーを実装します。 コンティンジェンシー ポリシーの命名規則には、以下を含める必要があります。
他のポリシーから名前が目立つようにするため、先頭に ENABLE IN EMERGENCY (緊急時に有効化)。
適用する必要のある中断の名前。
管理者がポリシーを有効にする順序を理解できるようにするための、順序シーケンス番号。
例
次の名前は、このポリシーが、MFA の中断時に有効にする 4 つのポリシーのうちの最初のポリシーであることを示しています。
- EM01 - ENABLE IN EMERGENCY:MFA Disruption [1/4] - Exchange SharePoint:Require hybrid Azure AD join For VIP users.
サインイン元の国として想定されない国をブロックする
Azure Active Directory では、ネームド ロケーションを作成できます。 許可されている国のリストを作成してから、これらの "許可されている国" を除外したネットワーク ブロック ポリシーを作成します。 比較的狭い地域を主な拠点としている顧客の場合、これによってオーバーヘッドが減少します。緊急アクセス アカウントは必ずこのポリシーから除外してください。
条件付きアクセス ポリシーをデプロイする
新しいポリシーの準備ができたら、条件付きアクセス ポリシーを段階的にデプロイします。
条件付きアクセス ポリシーを構築する
有利なスタートを切るには、一般的な条件付きアクセス ポリシーを参照してください。 Microsoft の推奨事項に付帯している条件付きアクセス テンプレートを使用するのが便利な方法です。 緊急アクセス アカウントは必ず除外してください。
ポリシーの影響を評価する
運用環境で条件付きアクセス ポリシーの影響を確認する前に、次の 2 つのツールを使用してシミュレーションを実行することをお勧めします。
レポート専用モードを設定する
既定では、各ポリシーはレポート専用モードで作成されます。意図した結果を得るために、各ポリシーを有効にする前に、組織で使用状況をテストおよび監視することをお勧めします。
レポート専用モードでポリシーを有効にします。 レポート専用モードでポリシーを保存すると、サインイン ログでリアルタイム サインインへの影響を確認できます。 サインイン ログから、イベントを選択し、[レポート専用] タブに移動して、各レポート専用ポリシーの結果を確認します。
分析情報とレポートのブックで、条件付きアクセス ポリシーの全体的な影響を確認できます。 ブックにアクセスするには、Azure Monitor のサブスクリプションが必要であり、サインイン ログを Log Analytics ワークスペースにストリーミングする必要があります。
What If ツールを使用してサインインをシミュレートする
条件付きアクセス ポリシーを検証するもう 1 つの方法は、What If ツールを使用する方法です。これは、仮想的な状況でサインインするユーザーにどのポリシーが適用されるかをシミュレートします。 テストするサインイン属性 (ユーザー、アプリケーション、デバイス プラットフォーム、場所など) を選択し、どのポリシーが適用されるかを確認します。
注意
シミュレートされた実行により、条件付きアクセス ポリシーの影響について適切に考察できますが、実際のテスト実行に代わるものではありません。
ポリシーのテスト
ポリシーの除外条件を必ずテストしてください。 たとえば、MFA を必要とするポリシーからユーザーまたはグループを除外することができます。 他のポリシーの組み合わせでは、除外されたユーザーに MFA を要求する可能性があるため、それらのユーザーに MFA を求めるプロンプトが表示されるかどうかをテストする必要があります。
テスト ユーザーを使用して、テスト計画で各テストを実行します。 テスト計画は、予想される結果と実際の結果を比較するために重要です。 次の表は、テスト ケースの例の概要です。 実際の条件付きアクセス ポリシーを構成する方法に基づいて、このシナリオと予想される結果を調整します。
| ポリシー | シナリオ | 予測される結果 |
|---|---|---|
| リスクの高いサインイン | ユーザーが未承認のブラウザーを使用してアプリにサインインする | サインインがユーザーによって実行されなかった確率に基づいてリスク スコアを計算します。 ユーザーは MFA を使用した自己修復を要求されます |
| デバイス管理 | 承認済みユーザーが承認済みデバイスからサインインしようとする | アクセスが許可されます |
| デバイス管理 | 承認済みユーザーが承認されていないデバイスからサインインしようとする | アクセスはブロックされます |
| 危険なユーザーのパスワード変更 | 承認済みユーザーが侵害された資格情報を使用してサインインしようとする (高リスクのサインイン) | ユーザーはパスワードを変更するよう求められるか、ポリシーに基づいてアクセスがブロックされます |
運用環境でデプロイする
管理者は、レポート専用モードを使用して影響を確認したら、[ポリシーの有効化] トグルを [レポートのみ] から [オン] に移動できます。
ポリシーをロールバックする
新しく実装したポリシーをロールバックする必要がある場合は、次の 1 つ以上のオプションを使用します。
- ポリシーを無効にする。 ポリシーを無効にすると、ユーザーがサインインしようとしたときにポリシーが適用されなくなります。 ポリシーを使用したい場合には、いつでも戻ってそのポリシーを有効にできます。
- ポリシーからユーザーまたはグループを除外する。 ユーザーがアプリにアクセスできない場合、そのユーザーをポリシーから除外することを選択できます。
注意
このオプションは、ユーザーを信頼できる状態でのみ、控えめに使用してください。 ユーザーはできるだけ早くポリシーまたはグループに追加し直す必要があります。
- ポリシーを削除する。 ポリシーが不要になった場合は、それを削除します。
条件付きアクセス ポリシーに関するトラブルシューティング
ユーザーが条件付きアクセス ポリシーに関する問題を抱えている場合は、トラブルシューティングを容易にするために次の情報を収集します。
ユーザー プリンシパル名
ユーザー表示名
オペレーティング システム名
タイム スタンプ (おおよその時刻でもかまいません)
ターゲット アプリケーション
クライアント アプリケーションの種類 (ブラウザーとクライアント)
相関 ID (これはサインインに固有です)
ユーザーが [詳細] リンクを含むメッセージを受信した場合、それらのユーザーはこの情報の大部分を収集できます。
情報を収集した後、次のリソースを参照してください。
条件付きアクセスでのサインインの問題 – エラー メッセージと Azure AD のサインイン ログを使用して、条件付きアクセスに関連する予期しないサインイン結果について理解してください。
What-If ツールの使用 - ポリシーが特定の状況でユーザーに適用された理由や適用されなかった理由、ポリシーが既知の状態で適用されるかどうかについて理解してください。