Azure Managed Service Column ＜Azure運用コラム＞条件付きアクセスでゼロトラストセキュリティを実現する

はじめに

Microsoft 365 や Azure Virtual Desktop、Azure など、Microsoft のクラウドアプリケーションは認証に Azure AD というサービスを使っています。Azure AD には 条件付きアクセス という強力なアクセスコントロール機能があり、要件に合わせて細やかな条件設定をすることができます。近年、注目されているゼロトラストセキュリティ (注釈1) の第一歩として非常にオススメです。

本コラムでは、条件付きアクセスを使ってどのようなことができるのかを紹介し、実際に幾つかの代表的なケースについて試してみます。なお、条件付きアクセスを使うには、Azure AD のライセンスが Azure AD Premium P1 以上であることが必要です。

条件付きアクセスで出来ること

条件付きアクセスはファイアウォールのように “ポリシー” を作成することで設定します。ポリシーは “割り当て” と “アクセス制御” の 2 つの組み合わせから構成されます。

割り当て

プログラム言語でいう if 文に相当する部分です。以下を設定できます。

• ユーザとグループ
• クラウドアプリまたは操作
• 条件

“ユーザとグループ” は Azure AD のユーザが対象となります。実際の運用シーンでは役職や部署などのグループで管理することになるでしょう。

“クラウドアプリまたは操作” は Microsoft 365 や Azure Virtual Desktop、Azure などから選べます。Azure AD は IDaaS でもあるので、連携設定を行えば 独自アプリケーション を対象にすることも可能です。アプリごとにセキュリティレベルの異なるポリシーを割り当てることで、重要なデータを持つアプリは厳しい条件で、そうでないアプリは緩い条件で、ユーザビリティを下げずにセキュリティ対策ができます。

“条件” は “どのような場合に” に相当する部分であり、ポリシーのコアになる部分です。以下の条件を複数、組み合わせることができます。

• ユーザのリスク
• サインインのリスク
• デバイスのプラットフォーム
• 場所
• クライアントアプリ
• デバイスの状態

アクセス制御

割り当てにマッチしたときに実行されるアクションです。以下から選択ができます。

• ブロック
• アクセス権を付与
  • ・多要素認証を要求する
  • ・デバイスは準拠しているとしてマーク済みである必要があります
  • ・Hybrid Azure AD Join を使用したデバイスが必要
  • ・承認されたクライアント アプリが必要です
  • ・アプリの保護ポリシーが必要
  • ・パスワードの変更を必須とする
• セッション
  • ・アプリによって適用される制限を使用する
  • ・アプリの条件付きアクセス制御を使う
  • ・サインインの頻度
  • ・永続的なブラウザーセッション

アクセス制御には “許可” という項目がないので、“~~以外をブロック” もしくは “~~ の場合は追加の条件・操作を求める” といった制限をかける方向での設定になります。

条件付きアクセスを試してみる

できることがたくさんありすぎて迷ってしまいそうですが、ここでは汎用的で、かつ、弊社オススメの4つのケースについて紹介したいと思います。

なお、ポリシーを作成するときの注意事項ですが、必ず1つ以上のユーザは除外するようにしてください。万が一、誤ったポリシーを設定してしまった場合、誰もログインできなくなってしまう可能性があるためです。管理者ユーザには “MFA 認証を必須にする” というポリシーだけを割り当て、それ以外のポリシーからは除外することをオススメします。

ケース 1. 特定 IP アドレス以外からのアクセスをブロックする

最初のケースは、ファイアウォールなどでもよく行われる、アクセス元 IP アドレスによるアクセス制限です。

まず初めに、“ネームドロケーション” を定義します。ここに信頼のできる場所を登録していきます。場所は IP アドレスでもいいし、国でもよいです。[条件付きアクセス] サービスの [ネームドロケーション] メニューより、[国の場所] もしくは、[IP の場所] をクリックします。そして、[信頼できる場所としてマークする] にチェックを入れて追加します。

次に、条件付きアクセスのポリシーを作成します。[ポリシー] メニューを開いて、[新しいポリシー] をクリックします。

名前はポリシーの内容がわかるようにしましょう。”信頼された場所以外からのアクセスをブロック” とします。[ユーザとグループ] は、[対象] を “すべてのユーザー” とし、[対象外] に管理者ユーザを指定します。そして、[クラウドアプリと操作] は [対象] に “すべてのクラウドアプリ” を指定します。このあとのポリシーも、ここは全て共通とします。

[条件] は以下のように、[場所] の設定を行います。[対象] を場所にして、[対象外] にネームドロケーションで定義した場所を指定します。

最後に、[許可] にて “アクセスをブロック” を指定して、完了です。

特定 IP アドレス以外から マイアプリポータル にアクセスすると、以下のようにブロックされました。

社外からのリモートワークが許可されている会社であれば、”ブロック” の代わりに “MFA 認証を要求” にするのも効果があります。

ケース 2. Microsoft が怪しいと判断したアクセスに MFA 認証を求める

このケースは、Microsoft が提供する Identity Protection というセキュリティサービスとの連携を利用したもので、非常に強力です。Identity Protection は Microsoft に蓄積された膨大なデータを機械学習によって分析し、自動でリスクを検出してくれます。(1 日あたり 6 兆 5000 億の信号を分析しているとのこと！)

Identity Protection が検出した “怪しいアクセス” は、サインインリスク と呼ばれます。どのようなアクセスが怪しいと判断されるかは サインイン リスク に幾つか例が載っています。「匿名 IP アドレスからのアクセス」「最初のアクセスから短い時間での遠く離れた場所からのアクセス」「よく使われるパスワードを片っ端から試そうとするアクセス」などです。

これらは機械学習によって学習することで誤検知が減っていきます。例えば、「最初のアクセスから短い時間での遠く離れた場所からのアクセス」でいうと、「VPN 接続を使っている」など原因が明らかになった場合は、そのパターンは検知しなくなります。

サインインリスクを使った条件ポリシーとしては、”サインインリスクが中以上の場合に、MFA 認証を要求” という設定が推奨されています。誤検知の可能性もゼロではないので、ブロックではなく MFA 認証が推奨されています。以下の通り、設定してください。[許可] には “アクセス権を付与” にチェックを入れた上で “パスワードの変更を必須とする” を選択します。

テストのために「匿名 IP アドレスからのアクセス」をして試してみましょう。Tor ブラウザを使って、マイアプリポータルにアクセスしてみます。以下のように、パスワード入力後に MFA 認証 (今回は電話を使ったコード認証) の画面が表示されました。

MFA 認証の初期設定をしていないユーザには、以下の画面が表示され、ログインすることはできません。(ブロックされたときとはメッセージが異なります。)

なお、ユーザーごとの Azure AD Multi-Factor Authentication を有効にしてサインイン イベントのセキュリティを確保する にあるとおり、Azure AD サービスの画面から MFA 認証の有効/無効をユーザ個別に設定する管理コンソールを開けるのですが、条件付きアクセスを利用する場合は、こちらの画面から設定してはいけません。条件付きアクセスの MFA 認証要求は、ユーザ個別の設定とは無関係に行われます。

ケース 3. 流出の可能性があるユーザ情報でのアクセスにパスワード変更を求める

Identity Protection が検出するリスクには、サインインリスクの他に ユーザリスク というものもあります。これはパスワードが流出していたり、乗っ取りの可能性があったりといった、ユーザアカウント個別に検出されるリスクを意味します。

こちらは、”ユーザリスクが高の場合に、パスワードの変更を必須とする” という設定が推奨されています。[許可] には “アクセス権を付与” にチェックを入れた上で “多要素認証を要求する” を選択します。

こちらも Tor ブラウザにてテストすることができます。この条件にマッチすると、一旦 MFA 認証が求められます。MFA 認証による本人確認のあと、パスワード変更の画面が表示されます。

なお、Hybrid ID 環境では、上記のように自分自身でパスワードを変更できるのは、Azure AD Connect の設定にて “Password Writeback” を有効にしている場合だけです。Hybrid ID 環境ではオンプレ側のパスワードがマスタとなっているので、Azure AD 側で変更したパスワードを “Writeback” しなければならないためです。

ケース 4. オンプレ AD DS に参加しているデバイス以外からのアクセスをブロックする

このケースは、Hybrid ID 環境を構築してみる で紹介した Hybrid ID 環境を対象としています。社内に AD 環境があるような会社にて、ドメインに参加しているオフィス内の PC からはアプリへのアクセスを許可するが、個人所有のノート PC やスマホからのアクセスは拒否したい、のような状況を想定しています。

まず最初に、少しだけ下準備があります。Hybrid Azure AD Join といって、オンプレ AD DS 上のデバイスを Azure AD に登録する機能を設定します。Azure AD Connect の設定画面を開き、[Configure Device Options] をクリックしてください。以下の通り、[Hybrid ID Join] の設定をします。

現時点では、Windows のみが対象 となっています。

同期が完了すると、Azure AD の [デバイス] メニューにデバイスが追加されます。

Hybrid Azure AD Join の設定が完了したので、これを条件とするポリシーを作成します。

ドメインに参加していないデバイスからアクセスすると、以下のとおり、ブロックされました。同じブロックでもメッセージが変わるのが親切ですね。

条件付きアクセスの [許可] には、もうひとつデバイスに関するものとして “デバイスは準拠しているとしてマーク済みである必要があります” がありました。これは Intune というデバイス管理サービスと連携するものです。

Intune では Windows 以外のデバイスでも管理ができ、「OS のバージョンが指定したものより新しいか」「パスワードが指定の要件を満たしているか」「ウイルス対策ソフトはインストールされているか」といったコンプライアンスポリシーを設定することができます。コンプライアンスポリシーを満たしていないデバイスからのアクセスは、条件付きアクセスによってブロックすることができます。

まとめ

本コラムでは条件付きアクセスの代表的な機能について紹介しました。出来ることが非常に多く、まだまだ一部分しか紹介しきれていませんが、非常に強力なセキュリティサービスだということを分かっていただけたかと思います。

実際の現場に導入するには、環境や要望に合わせて適切なポリシーを設計したり、組み合わせたりしなければなりません。また、業務に影響がないように少しずつ、しかし、全てのユーザに適用できるよう確実に、進めていく必要があります。弊社ではシステム管理者の方が新しい技術を導入するためのお手伝いをしておりますので、お困りの際はぜひお声掛けください。

（本文へ戻る）

Tag： セキュリティ 条件付きアクセス

• 

  Hybrid ID 環境 + Azure Virtual Desktop (AVD 旧:Windows Virtual Desktop) を構築してみる

• 

  Hybrid ID 環境 + Azure Files を構築してみる