条件付きアクセスのデプロイを計画する
アプリとリソースに関する組織のアクセス戦略を実現するために、条件付きアクセスのデプロイを計画することが重要です。 条件付きアクセス ポリシーによって、優れた構成柔軟性が提供されます。 ただし、この柔軟性は、慎重に計画して、望ましくない結果を避ける必要があることも意味します。
Azure Active Directory (Azure AD) の条件付きアクセスは、ユーザー、デバイス、場所などのシグナルを分析して、決定を自動化し、リソースに関する組織のアクセス ポリシーを適用します。 条件付きアクセス ポリシーを使用して、セキュリティ コントロールを管理する条件を構築できます。必要に応じてアクセスをブロックしたり、多要素認証を要求したり、ユーザーのセッションを制限したりするが、必要がなければユーザーの邪魔をしない条件を設定できます。
この評価と強制によって、条件付きアクセスは、Microsoft のゼロ トラスト セキュリティ体制管理の基礎を定義します。
Microsoft では、Azure AD Premium を利用しないテナントでも基本レベルのセキュリティが有効であることを保証するセキュリティの既定値群を提供しています。 条件付きアクセスを使用すると、セキュリティの既定値群と同じ保護を提供するが、きめ細かな制御が可能なポリシーを作成できます。 条件付きアクセス ポリシーを作成するとセキュリティの既定値群を有効にできなくなるため、条件付きアクセスとセキュリティの既定値群を組み合わせることは想定されていません。
前提条件
- Azure AD Premium P1、P2、または試用版ライセンスが有効になっていて、正常に動作している Azure AD テナント。 必要に応じて、無料で作成できます。
- 条件付きアクセス ポリシーに Identity Protection のリスクを含めるには、Azure AD Premium P2 が必要です。
- 条件付きアクセスに関与する管理者は、実行しているタスクに応じて、次のロールの割り当てを 1 つ以上持っている必要があります。 最小特権のゼロ トラスト原則に従う場合は、Privileged Identity Management (PIM) を使用して、Just-In-Time で特権ロールの割り当てをアクティブ化することを検討してください。
- 条件付きアクセス ポリシーと構成を読み取る
- 条件付きアクセス ポリシーを作成または変更する
- 実際のユーザーにデプロイする前に、ポリシーが期待どおりに機能することを確認できるテスト ユーザー (管理者以外)。 ユーザーを作成する必要がある場合は、「クイックスタート: Azure Active Directory に新しいユーザーを追加する」を参照してください。
- 管理者以外のユーザーが所属するグループ。 グループを作成する必要がある場合は、Azure Active Directory でグループを作成し、メンバーを追加する方法に関する記事を参照してください。
変更の連絡
コミュニケーションは、新しい機能の成功に必要不可欠です。 ユーザー エクスペリエンスがどのように変わるのか、いつ変わるのか、問題が発生したときにサポートを受ける方法について、ユーザーに事前に連絡する必要があります。
条件付きアクセス ポリシーのコンポーネント
条件付きアクセス ポリシーは、誰がリソースにアクセスできるか、どのようなリソースにアクセスできるか、それはどのような条件かについての質問に答えるものです。 ポリシーは、アクセスを許可するか、セッション制御を使用してアクセスを制限するか、またはアクセスをブロックするように設計できます。 条件付きアクセス ポリシーを作成するには、次のような if-then ステートメントを定義します。
| 割り当てが満たされた場合 | アクセス制御を適用する |
|---|---|
| 財務のユーザーが給与処理アプリケーションにアクセスしている場合 | 多要素認証および準拠しているデバイスを要求する |
| 財務に属していないメンバーが給与処理アプリケーションにアクセスしている場合 | アクセスのブロック |
| ユーザー リスクが高い場合 | 多要素認証とセキュリティで保護されたパスワードの変更を要求する |
ユーザーの除外
条件付きアクセス ポリシーは強力なツールであり、次のアカウントをポリシーから除外することをお勧めします。
- 緊急アクセス用アカウントまたは非常用アカウント。テナント全体でアカウントがロックアウトされるのを防ぎます。 発生する可能性は低いシナリオですが、すべての管理者がテナントからロックアウトされた場合に、ご自身の緊急アクセス用管理アカウントを使用してテナントにログインし、アクセスの復旧手順を実行できます。
- 詳細については、「Azure AD で緊急アクセス用アカウントを管理する」を参照してください。
- サービス アカウントとサービス プリンシパル (Azure AD Connect 同期アカウントなど)。 サービス アカウントは、特定のユーザーに関連付けられていない非対話型のアカウントです。 これらは通常、アプリケーションへのプログラムによるアクセスを可能にするバックエンド サービスによって使用されますが、管理目的でシステムにサインインする場合にも使用されます。 プログラムでは MFA を完了できないため、このようなサービス アカウントは対象外とする必要があります。 サービス プリンシパルによる呼び出しは、ユーザーをスコープとする条件付きアクセス ポリシーではブロックされません。 ワークロード ID の条件付きアクセスを使用して、サービス プリンシパルを対象とするポリシーを定義します。
- 組織のスクリプトまたはコードでこれらのアカウントが使用されている場合は、それをマネージド ID に置き換えることを検討してください。 これらの特定のアカウントは、一時的な回避策として、ベースライン ポリシーの対象外にすることができます。
適切な質問をする
ここでは、割り当てとアクセス制御に関する一般的な質問をいくつか示します。 ポリシーを構築する前に、ポリシーごとに質問に対する回答を文書化します。
ユーザーまたはワークロード ID
- どのユーザー、グループ、ディレクトリ ロール、またはワークロード ID がポリシーに含まれますか? または、除外されますか?
- どのような緊急アクセス用のアカウントまたはグループをポリシーから除外する必要がありますか?
クラウド アプリまたはアクション
このポリシーは、いずれかのアプリケーション、ユーザー操作、または認証コンテキストに適用されますか? 該当する場合、
- ポリシーをどのアプリケーションまたはサービスに適用しますか?
- どのようなユーザー アクションがこのポリシーの対象となりますか?
- このポリシーはどのような認証コンテキストに適用されますか?
条件
- ポリシーに含める、またはポリシーから除外するデバイス プラットフォームはどれですか?
- 組織の既知のネットワークの場所は何ですか?
- ポリシーにどの場所を含め、どの場所を除外しますか?
- どのクライアント アプリの種類をポリシーに含め、どれを除外しますか?
- 特定のデバイス属性を対象とする必要がありますか?
- ID 保護を使用する場合、サインインまたはユーザーのリスクを組み込みますか?
ユーザー リスクとサインイン リスク
Azure AD Premium P2 ライセンスを持つ組織では、条件付きアクセス ポリシーにユーザーとサインインのリスクを含めることができます。 これらを追加すると、ユーザーまたはサインインが危険と見なされる場合にのみ、多要素認証またはセキュリティで保護されたパスワードの変更を要求することで、セキュリティ対策の摩擦を軽減することができます。
リスクとポリシーでの使用の詳細については、記事「リスクとは」を参照してください。
コントロールをブロックまたは許可する
次の 1 つ以上を必須としてリソースへのアクセスを許可しますか?
- 多要素認証
- デバイスが準拠としてマーク済みであること
- Hybrid Azure AD Join を使用したデバイスの使用
- 承認済みクライアント アプリの使用
- アプリ保護ポリシー適用済み
- パスワードの変更
- 利用規約に同意済み
アクセスのブロックは強力なコントロールであり、適用するには適切な知識が必要です。 ブロック ステートメントのあるポリシーには予想外の副作用が含まれることがあります。 大規模にコントロールを有効にする前に、適切なテストと検証が不可欠です。 管理者は、変更を行うにあたり、条件付きアクセスのレポート専用モードや条件付きアクセスの What If ツールなどのツールを使う必要があります。
セッション制御
クラウド アプリに次のアクセス制御を適用しますか?
- アプリによって適用される制限を使用する
- アプリの条件付きアクセス制御を使用する
- サインインの頻度を適用する
- 永続的ブラウザー セッションを使用する
- 継続的アクセス評価をカスタマイズする
ポリシーの組み合わせ
ポリシーを作成して割り当てるときは、アクセス トークンのしくみを考慮する必要があります。 アクセス トークンでは、要求を行っているユーザーが認可および認証されているかどうかに基づいて、アクセスを許可または拒否します。 要求元は、自分が本人であることを証明できる場合、保護されたリソースまたは機能にアクセスできます。
条件付きアクセス ポリシー条件によってアクセス制御がトリガーされない場合、既定でアクセス トークンが発行されます。
このポリシーは、アプリでアクセスをブロックするのを妨げるものではありません。
たとえば、次のような簡略化されたポリシーの例を考えてみます。
ユーザー: 財務グループ
アクセス: 給与処理アプリ
アクセス制御: 多要素認証
- ユーザー A は財務グループに属しており、給与処理アプリにアクセスするには多要素認証を実行する必要があります。
- ユーザー B は財務グループに属しておらず、アクセス トークンが発行され、多要素認証を実行せずに給与処理アプリにアクセスできます。
財務グループの外部のユーザーが給与処理アプリにアクセスできないようにするには、次の簡略化されたポリシーのような、他のすべてのユーザーをブロックするポリシーを別途作成することができます。
ユーザー: すべてのユーザーを含める/財務グループを除外する
アクセス: 給与処理アプリ
アクセス制御: アクセスをブロックする
これで、ユーザー B が給与処理アプリにアクセスしようとすると、ブロックされます。
Recommendations
条件付きアクセスの使用と他のお客様のサポートについて学習したことを考慮して、学習内容に基づいていくつかの推奨事項を次に示します。
条件付きアクセス ポリシーをすべてのアプリに適用する
すべてのアプリに少なくとも 1 つの条件付きアクセス ポリシーが適用されていることを確認してください。 セキュリティの観点からは、すべてのクラウド アプリに適用されるポリシーを作成してから、そのポリシーを適用したくないアプリケーションを除外することをお勧めします。 このプラクティスにより、新しいアプリケーションをオンボードするたびに条件付きアクセス ポリシーを更新する必要がなくなります。
ヒント
1 つのポリシーでブロックとすべてのアプリを使用する場合は特に注意してください。 これにより、Azure portal から管理者がロックアウトされる可能性があります。また、Microsoft Graph などの重要なエンドポイントに対しては除外を構成できません。
条件付きアクセス ポリシーの数を最小限にする
アプリごとにポリシーを作成するのは効率的ではなく、管理が困難になります。 条件付きアクセスでは、テナントあたりポリシーが 195 個に制限されています。 アプリを分析し、同じユーザーに対して同じリソース要件があるアプリケーションにそれらをグループ化することをお勧めします。 たとえば、すべての Microsoft 365 アプリまたはすべての HR アプリで同じユーザーに対して同じ要件がある場合、1 つのポリシーを作成し、それが適用されるすべてのアプリを含めます。
レポート専用モードの構成
既定では、テンプレートから作成された各ポリシーはレポート専用モードで作成されます。 意図した結果を得るために、各ポリシーを有効にする前に、組織で使用状況をテストおよび監視することをお勧めします。
レポート専用モードでポリシーを有効にします。 レポート専用モードでポリシーを保存すると、サインイン ログでリアルタイム サインインへの影響を確認できます。 サインイン ログから、イベントを選択し、[レポート専用] タブに移動して、各レポート専用ポリシーの結果を確認します。
分析情報とレポートのブックで、条件付きアクセス ポリシーの全体的な影響を確認できます。 ブックにアクセスするには、Azure Monitor のサブスクリプションが必要であり、サインイン ログを Log Analytics ワークスペースにストリーミングする必要があります。
中断に対する計画を立てる
多要素認証や 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 365 組織の一般的なセキュリティ ポリシーに関する記事を参照してください。 これらのテンプレートは、Microsoft の推奨事項をデプロイするのに便利な方法です。 緊急アクセス アカウントは必ず除外してください。
ポリシーの影響を評価する
次のツールを使用して、変更の前後の両方でポリシーの効果を評価することをお勧めします。 シミュレートされた実行により、条件付きアクセス ポリシーの影響を把握できますが、適切に構成された開発環境での実際のテスト実行に代わるものではありません。
- レポート専用モードと、条件付きアクセスに関する分析情報とレポートのブック。
- What If ツール
ポリシーをテストする
ポリシーの除外条件を必ずテストしてください。 たとえば、MFA を必要とするポリシーからユーザーまたはグループを除外することができます。 他のポリシーの組み合わせでは、除外されたユーザーに MFA を要求する可能性があるため、それらのユーザーに MFA を求めるプロンプトが表示されるかどうかをテストする必要があります。
テスト ユーザーを使用して、テスト計画で各テストを実行します。 テスト計画は、予想される結果と実際の結果を比較するために重要です。 次の表は、いくつかのテスト ケースの例の概要です。 実際の条件付きアクセス ポリシーを構成する方法に基づいて、このシナリオと予想される結果を調整します。
| ポリシー | シナリオ | 予測される結果 |
|---|---|---|
| リスクの高いサインイン | ユーザーが未承認のブラウザーを使用してアプリにサインインする | サインインがユーザーによって実行されなかった確率に基づいてリスク スコアを計算します。 ユーザーは MFA を使用した自己修復を要求されます |
| デバイス管理 | 承認済みユーザーが承認済みデバイスからサインインしようとする | アクセスが許可されます |
| デバイス管理 | 承認済みユーザーが承認されていないデバイスからサインインしようとする | アクセスはブロックされます |
| 危険なユーザーのパスワード変更 | 承認されたユーザーが、侵害された資格情報でサインインしようとする (リスクの高いサインイン) | ユーザーはパスワードを変更するよう求められるか、ポリシーに基づいてアクセスがブロックされます |
運用環境でデプロイする
ユーザーがレポート専用モードを使用して影響を確認したら、管理者は [ポリシーの有効化] トグルを [レポート専用] から [オン] に移動できます。
ポリシーをロールバックする
新しく実装したポリシーをロールバックする必要がある場合は、次の 1 つ以上のオプションを使用します。
ポリシーを無効にする。 ポリシーを無効にすると、ユーザーがサインインしようとしたときにポリシーが適用されなくなります。 ポリシーを使用したい場合には、いつでも戻ってそのポリシーを有効にできます。
ポリシーからユーザーまたはグループを除外する。 ユーザーがアプリにアクセスできない場合、そのユーザーをポリシーから除外することを選択できます。
注意事項
ユーザーを信頼できる状態でのみ、除外は控えめに使用してください。 ユーザーはできるだけ早くポリシーまたはグループに追加し直す必要があります。
ポリシーが無効にされたり不要になったりした場合は、削除します。
条件付きアクセス ポリシーのトラブルシューティングを行う
ユーザーが条件付きアクセス ポリシーに関する問題を抱えている場合は、トラブルシューティングを容易にするために次の情報を収集します。
- ユーザー プリンシパル名
- ユーザー表示名
- オペレーティング システム名
- タイム スタンプ (おおよその時刻でもかまいません)
- ターゲット アプリケーション
- クライアント アプリケーションの種類 (ブラウザーとクライアント)
- 相関 ID (この ID はサインインに固有です)
ユーザーが [詳細] リンクを含むメッセージを受信した場合、それらのユーザーはこの情報の大部分を収集できます。
情報を収集した後、次のリソースを参照してください。
- 条件付きアクセスでのサインインの問題 – エラー メッセージと Azure AD のサインイン ログを使用して、条件付きアクセスに関連する予期しないサインイン結果について理解してください。
- What-If ツールの使用 - ポリシーが特定の状況でユーザーに適用された理由や適用されなかった理由、ポリシーが既知の状態で適用されるかどうかについて理解してください。