条件付きアクセス

条件付きアクセスまとめ：設計・運用のベストプラクティス この記事の内容 Microsoft Entraの条件付きアクセスについて、MVP・トレーナーとして著名なクニースグル氏のブログ記事「All About Identity」の要点を解説します ポリシー設計における「シンプルさを保つ」戦略と、評価軸を用いた管理手法を紹介します Intune・PowerShell・Defender for Cloud Appsなど、他のMicrosoftサービスとの高度な連携パターンを説明します COBO・COPE・BYODといったデバイス管理モデルごとのアクセス制御の考え方を整理します 現場で起こりがちなトラブルとその解決策、および設計の原点に立ち返る視点を提供します 条件付きアクセスの基礎とよくある課題 今回は、Microsoft Entraの「条件付きアクセス」について、非常に参考になるブログ記事をご紹介します。 この記事は、長年Microsoft MVPとして活躍され、多くのIT技術者のトレーナーも務めるクニースグル氏が運営するブログ「All About Identity」に掲載された「条件付きアクセスまとめ」というエントリです。 企業のセキュリティ担当者であれば、「条件付きアクセスの設定を見直したい」「運用を引き継いだけれど、複雑でよくわからない」といった悩みを抱えることがあるでしょう。条件付きアクセスは非常に強力な機能ですが、独特の癖もあります。クニースグル氏の記事では、そうした課題を解決するための骨太な情報が体系的にまとめられています。 記事では、まず「条件付きアクセスとは何か」という基本から、分かりやすい図解を交えて丁寧に解説されています。さらに、具体的な設定例と共に、それに伴うトラブルシューティングについても詳しく触れられています。例えば、「IT担当者が緊急時にアクセスできなくなった」「社内IPアドレスが固定されていない環境でどう対応するか」といった、現場で起こりがちな問題とその解決策が示されています。 時には「そもそも実現したいことは何か？」という原点に立ち返り、別のアプローチを検討する視点も提供されており、多角的に理解を深めることができます。 ポリシー設計のベストプラクティス：シンプルさを保つ戦略 複雑なポリシーは管理を困難にするため、記事では「ポリシーはシンプルに保つべき」という原則が強調されています。そのために、明確な評価軸を設けてポリシーを定義し、運用していくことの重要性が提言されています。 評価軸を定めることで、「どのユーザー」のための「どのポリシー」なのかが明確になります。これにより、ポリシーの数が増えても、それぞれの役割が明確であるため、管理が煩雑になるのを防ぐことができます。 ただし、「シンプルにする」こと自体が目的ではありません。「どのようにシンプルさを維持するか」という戦略を持つことが不可欠です。その戦略を立てる上で、評価軸を持つという考え方は非常に有効なアプローチです。 各種Microsoftサービスとの高度な連携 条件付きアクセスは、他のMicrosoftサービスと連携することで、さらに強力なセキュリティを実現できます。記事では、以下のような連携パターンが紹介されています。 Microsoft Intune との連携 コンプライアンスポリシーを利用して、組織のセキュリティ要件を満たしたデバイスのみアクセスを許可する構成が可能です。デバイスの健全性を条件付きアクセスの判断材料として活用できます。 PowerShell によるポリシー管理 スクリプトを用いて、ポリシーの構成や状態を効率的にチェックする手法が紹介されています。多数のポリシーを一括で確認・管理する際に特に有効です。 Microsoft Entra ID P2 の高度な機能 P2ライセンスで利用可能になる高度な機能との連携により、よりきめ細かなアクセス制御が実現できます。 Microsoft Defender for Cloud Apps との連携 アプリケーションレベルでの詳細なセッション制御が可能になります。具体的には、印刷やコピー＆ペーストのブロックといった操作制限を実装できます。 この連携は特に注目すべき点で、高コストなVDI（仮想デスクトップ基盤）を導入せずとも、情報漏洩リスクを低減できる有効な手段として紹介されています。VDI代替手段として検討する価値があります。 デバイスの種類に応じたアクセス制御 記事では、デバイスの管理モデルごとにポリシーを使い分けるアプローチも紹介されています。以下の3つのモデルを定義し、それぞれに適したポリシーを適用します。 モデル 正式名称 概要 COBO Company-Owned, Business-Only 企業所有・業務専用デバイス COPE Company-Owned, Personally-Enabled 企業所有・個人利用可能デバイス BYOD Bring Your Own Device 個人所有デバイス このようにデバイスの利用形態ごとにポリシーを分けることで、セキュリティと利便性のバランスを取ることが可能になります。各モデルで求められるセキュリティ要件は異なるため、一律の制御ではなくモデルに応じた最適なポリシーを設計することが重要です。 ...

【全EntraID管理者必見！】条件付きアクセスの「全てのリソース+除外設定」の挙動に注意が必要！ この記事の内容 Microsoft Entra ID の条件付きアクセスで「すべてのクラウドアプリ」を対象にしたポリシーに除外設定を加えると、意図しない挙動が発生することがあります 除外設定を追加しただけで、デバイス準拠要求のポリシーが特定のアプリに効かなくなる現象を実際に検証・確認しました この挙動はバグではなく、Microsoft の公式ドキュメントに記載されている仕様です User.Read や profile、openid などの低権限スコープのみを要求するアプリは、除外設定がある場合にポリシー適用から自動的に外れます セキュリティ要件によっては「すべてのクラウドアプリ＋除外設定」という構成が意図したとおりに機能しない可能性があり、既存ポリシーの見直しが必要です 前提：準拠デバイスを要求するポリシーの基本動作 まず、基本的な動作を確認します。Entra ID の条件付きアクセスポリシーを新規に作成し、「すべてのクラウドアプリ」へのアクセスに対して「準拠しているとしてマーク済みのデバイスが必要」という制御を設定します。 このポリシーを「レポート専用モード」で有効化し、Intune などに登録されていない非準拠デバイスから Entra ID 認証を試みます。 この設定では、非準拠デバイスからのアクセスはブロックされるはずです。実際にサインインログを確認すると、期待どおり「失敗」と記録され、失敗の理由として「準拠しているデバイスが必要」と表示されます。ここまでは、多くの管理者が期待する通りの動作です。 問題の挙動：除外設定を追加した途端、ポリシーが効かなくなる ここからが本題です。先ほど作成したポリシーに、ほんの少し変更を加えます。 対象リソースの設定で「すべてのクラウドアプリ」を選択した状態のまま、「対象外とするクラウドアプリ」に、現在テストしている認証とは全く関係のないアプリケーションを1つだけ追加します。 この状態で、再度、非準拠デバイスから Entra ID 認証（今回の検証では OP-SSH ログイン）を試みます。 ポリシーの意図としては、特定のアプリを除外しただけであり、それ以外のアプリには引き続きデバイス準拠の要求が適用されるはずです。しかし実際のサインインログを確認すると、結果は「成功」となり、条件付きアクセスポリシーは「適用なし」と表示されてしまいます。 つまり、関係のないアプリを1つ除外設定に追加しただけで、デバイスの準拠を求める制御が効かなくなってしまったのです。 なぜこのような挙動になるのか？公式ドキュメントの記述 この一見不可解な動作は、バグではなく Microsoft の公式ドキュメントに記載されている仕様です。 「すべてのリソースにアプリの除外がある場合の条件付きアクセスの動作」という項目に、次のような記述があります。 すべてのリソースを対象にしながらポリシーから除外するリソースがある場合、誤ってユーザーアクセスをブロックしないように、特定の低い権限のスコープがポリシーの適用から除外されます。 具体的には、以下のような基本的なユーザープロファイル読み取りに相当する、特権レベルの低いアクセス許可のみを要求するアプリケーションは、ポリシーの対象から自動的に外れます。 U p o s r p e o e r f n . i i R l d e e a d 今回の検証で利用した SSH ログインツールは、認証時にこれらの「基本的な情報」しか要求していませんでした。そのため、ポリシーに除外設定が加わったことで、この「低い権限スコープは許可する」という仕様が適用され、デバイス準拠のチェックをすり抜けてしまったというのが真相です。 ...