HONDA LABO

本田研究室

Azure ADの条件付きアクセス

条件付きアクセスは、Azure ADで使用される機能で、リソースにアクセスする場合に、認可の条件を定義できる機能で、Microsoftのゼロトラストアーキテクチャの中核をなすアクセスポリシーエンジンという位置づけになっています。

Azure Active Directory の条件付きアクセスとは | Microsoft Docs

 

条件付きアクセスを使えば、たとえば「Slackにアクセスするには、〇〇グループのメンバーで、Intuneに登録されていること」といった条件を定義することが可能です。

 

条件付きアクセスで定義できる一般的な条件は以下のとおりです。

  • ユーザーまたはグループ メンバーシップ
    • 特定のユーザーとグループをポリシーの対象にすることができるため、管理者はアクセスをきめ細かく制御できます。
  • IP の場所に関する情報
    • 組織では、ポリシーに基づく決定を行うときに使用できる、信頼された IP アドレス範囲を作成できます。
    • 管理者は、国/地域全体の IP 範囲を指定して、その範囲からのトラフィックをブロックまたは許可することができます。
  • Device
    • 条件付きアクセス ポリシーを適用するとき、特定のプラットフォームのデバイスまたは特定の状態であるとマークされたデバイスを使用しているユーザーを使用できます。
  • Application
    • 特定のアプリケーションにアクセスしようとするユーザーは、さまざまな条件付きアクセス ポリシーをトリガーできます。
  • リアルタイムでの計算されたリスクの検出
    • シグナルと Azure AD Identity Protection の統合により、条件付きアクセス ポリシーで危険なサインイン動作を特定できます。 その上で、ポリシーでユーザーにパスワード変更や多要素認証の実行を強制してリスク レベルを下げることや、管理者が手動で対処するまでユーザーのアクセスをブロックすることができます。
  • Microsoft Cloud App Security (MCAS)
    • ユーザーのアプリケーションへのアクセスとセッションをリアルタイムで監視および制御できるようにします。クラウド環境へのアクセスと、クラウド環境で実行されるアクティビティの可視性を高めて制御を強化できます。

Azure Active Directory の条件付きアクセスとは | Microsoft Docs

 

はじめて条件付きアクセスのポリシーを作成する際、ファイアウォールポリシーのようなものかな?と思ってしまう方もいらっしゃると思いますが、違います。このあたりは以下のドキュメントが参考になると思うので、まずご参照いただくと良いかと思います。

条件付きアクセスポリシーは、アクセスを許可する条件の設定ではなく、アクセスをブロック / または制限 (特定の条件を満たさなければブロック) する条件を設定します。

また、条件付きアクセスポリシーを複数定義した場合、定義した順番 (画面表示上の上下) で優先順位はありません。

条件付きアクセスの基本的な考え方 | Japan Azure Identity Support Blog 

 

Azure AD条件付きアクセスを利用するには、Azure AD Premium P1 ライセンス が必要です。Microsoft 365 Business Premium ライセンスをでも、条件付きアクセス機能にアクセスできます。

また、サインイン リスクに対処するID 保護(Identity Protection)を利用するには、Azure AD Premium P2 ライセンスが必要です。Identity Protection によって次のようなさまざまな種類のリスクが特定されます。可能であれば、ID保護は利用したいところです。

  • 匿名 IP アドレスの使用 
  • 特殊な移動
  • マルウェアにリンクした IP アドレス
  • 通常とは異なるサインイン プロパティ
  • 漏洩した資格情報
  • パスワード スプレー
  • その他...

Azure Active Directory Identity Protection とは | Microsoft Docs

Azure AD Premium P2は、単体だと¥1,023です。M365 E5をお持ちの場合はバンドルされているので無料で使えます。

価格 - Azure Active Directory | Microsoft Azure

 

一点、条件付きアクセスの注意点をあげるとすると、条件付きアクセスはあくまで認証・認可の際の処理だということです。一度、認可されると、条件付きアクセスの設定を変更した、もしくは認可されないに条件に遷移したとしても、しばらくの間はアプリケーションを利用可です。

このあたりは以下のドキュメントが参考になると思いますが、アクセストークンが一度発行されると、それが切れるまで、もしくは アプリケーション側で強制ログアウトさせる(*1)までは、アプリケーションが利用可能となってしまうことが原因です。

Azure AD の継続的アクセス評価 | Microsoft Docs

 

この点も考えて利用可能な条件を設計する必要があるでしょう。

たとえば、社内で認証を行い、それを社外に持ち出すと、アクセストークンが切れる or SaaS側で強制ログアウトさせるまでは、社外でも利用可となってしまいます。テザリングに切り替えるだけで社外になるので、持ち出しにはそこまで時間はかかりません。

これを防ぐ(絶対に社内からのアクセスのみ許可)には、アプリケーション側でIPアドレス制限をかけて、VDIかVPNを利用することになるかと思います。

Azure AD の条件付きアクセスに関する Q&A | Japan Azure Identity Support Blog

 

ちなみにこの問題を改善するのが、前述の記事中にもある「継続的なアクセス評価」です。これは条件付きアクセスを個々のセッションに拡張し、新たなリスクが発生した場合に、ほぼリアルタイムでポリシーを適用する仕組みになります。この機能は年内に一般公開される予定だそうです。

 

その他、緊急アクセス用のアカウント(emergency)を作成するなどのベストプラクティスもあります。

azure-docs.ja-jp/plan-conditional-access.md at master · MicrosoftDocs/azure-docs.ja-jp · GitHub

 

また、Azure Identity サポート チームの方がAzure Active Directory Identity Blog で公開された記事を日本語訳されております。こちらの記事も非常に参考になります。

Ignite における ID 関連の発表まとめ - Azure AD の技術革新による障害耐性の強化 | Japan Azure Identity Support Blog

 

 

--------------------------------

(*1)アプリケーション側で強制ログアウトをさせる機能を実装していることもあります

Azure Active Directory で緊急時にユーザー アクセスを取り消す | Microsoft Docs

 

その他参考: