AzureAD条件付きアクセスを理解するために
みなさんこんにちは。
今回はAzureADのアクセス制御機能、条件付きアクセスについて書きます。
AzureADの機能を学習していて、条件付きアクセスがどのようなものなのか、大枠を知りたい！という方をターゲットにしています。
条件付きアクセスとは
その名のとおり、AzureAD基盤へのサインインに一定の制限をかける機能です。
Microsoft365サービスに加え、AzureADからSSOする場合なども対象になります。
条件付きアクセスが何故必要なのか、その背景を説明します。
M365テナントを作成した際、デフォルトでは「セキュリティの既定値群」という一連の設定が最低限のセキュリティを担保する形になっています。
しかし、カスタマイズできないため少々使いにくいのが実情です。
そのため多くの組織では最初にこれをオフにすることでしょう。
そうなりますと、M365はどの環境からでも資格情報のみでアクセス可能となってしまいます。
これではパスワードを盗まれたり破られた場合、アカウントを乗っ取られる事態になりかねません。
そこで条件付きアクセスを使用して、一定の条件をクリアした場合のみアクセスを許可することが重要になるわけです。
なお、条件付きアクセスを使用するためにはAzureAD Premium P1以上のライセンスが必要です。
BusinessPremiumやM365E3等の包括ライセンスを使用するか、個別に追加する必要があります。
条件付きアクセスでできること
条件付きアクセスに関する公式情報としては、以下のAzureBlogが最も簡潔にまとまっていると思います。
Docsにも色々説明はありますが、正直ある程度理解が進んでからでないと役に立ちません。笑
ただ、簡潔すぎてイメージが湧きづらいと思いますので、設定値を見ながら解説していきます。
こちらが条件付きアクセスポリシーを新規作成する場合の設定項目です。
（2022年4月時点）
まず赤で囲った部分でポリシーの対象とする条件を指定します。
そして青で囲った部分でアクセス制御の内容を指定します。
赤の条件指定部分では、
対象ユーザー
アプリ（サービスと捉えた方がわかりやすい）
デバイスプラットフォーム
IPアドレス
等を組み合わせて指定することができます。
また、ポリシーの対象とするだけではなく、ポリシーの対象外とする、という指定も可能です。（ここが非常に重要）
例えば、管理者ユーザーのみを対象とする、Windowsのみを対象とする、特定のIPを対象外とする、といった形で条件を設定します。
その上で、アクセス制御部分でアクセスをブロックするか、あるいは許可するか指定します。
ブロックに関しては単にブロックだけですが、アクセス権の付与の方は多要素認証やデバイス要件等の内容を設定する必要があります。
（なお、セッションの設定は今回は省略）
こうして見ると「アクセスを許可するにはアクセス権の付与を設定すればいいのか？」と思ってしまいますが、必ずしもそうではありません。
ブロックしたい対象のみを指定することで、逆にそれ以外のアクセスを自由に通すことが可能だからです。
つまり、ポリシー作成のセオリーは以下となります。
通したいアクセス以外をブロックする
↓
通すアクセスに対しアクセス要件を設定する
これを踏まえた上で、ポリシーの設定例をご覧いただきましょう。
条件付きアクセスポリシー例
①社内グローバルIPからのみアクセスを許可するポリシー
近年は境界型防御からゼロトラストモデルへの転換が注目されていますが、これまでのイントラ構成から脱却するにはまだまだ時間がかかりそうです。
そこで、今回は社内グローバルIPからのみアクセスを許可するポリシーを作成していきます。
モバイルからのアクセスにはVPNで固定IPを経由する想定です。
この場合、まずネームドロケーションを設定する必要があります。
条件付きアクセスメニューの[ネームドロケーション]から、アクセス許可するサブネット範囲を登録します。
（入力しているサブネットは適当な値ですのでお気になさらずに）
ネームドロケーションを作成したら、条件付きアクセスポリシーを作成していきます。
[新しいポリシーを作成する]をクリックします。
上から順に行きますと、まず対象/対象外とするユーザーを設定します。
対象をすべてのユーザーに設定し、対象外で個別に除外したいユーザーを選択することにします。
対象外とすべきユーザーとしては、まず1つ以上の管理者アカウントです。
ただし、通常テナント管理を行なっている管理者ではなく、緊急用の管理者アカウントを設置することが推奨されています。
どういうことかと言いますと、条件付きアクセスではアクセスに一定の要件が必要になるため、何かしらの理由で要件を満たせなくなった場合に365サービスにアクセスできなくなるリスクがあるのです。
このポリシーでいえば、社内ネットワークに障害が発生した場合などが考えられます。
そのような緊急時にアクセス制限を受けずに設定値を変更できる管理者アカウントが必要というわけです。
注意すべきは、情シスメンバーなど一般ユーザーが管理者を兼務している場合、対象外にしてはいけない、ということです。
管理者がユーザーとしてメールなど使用していれば、当然アカウントに対し攻撃を受けるリスクが生じます。
むしろそのアカウントは強力な保護をかけた方が良いと言えます。
一方、緊急用アカウントは普段は使用せずに隠しておき、いざという時だけサインインできるように用意しておくものです。（Break Glassアカウントと呼びます）
詳細な運用方法についてはこちらを参照するのが良いでしょう。
また、今回は社内グローバルIPからのアクセスを想定していますので、ゲストユーザー利用を許可する場合はこれも除外する必要があるでしょう。
この辺りの判断は利用状況や構成によって変わりますので、慎重に検討する必要があります。
続いてクラウドアプリに関しては対象を[すべてのクラウドアプリ]とし、対象外は設定しません。
条件の中の[場所]を構成します。
対象を[すべての場所]とし、対象外に先ほど作成したネームドロケーションを指定します。
最後に許可の項目で[アクセスのブロック]を設定し、構成は完了です。
ポリシーを作成する際はレポート専用やオフの状態で作成することが可能ですので、一旦それらで様子を見てみると良いでしょう。
これで特定のIP以外からのアクセスをブロックするポリシーが作成できました。
”特定IPからアクセス許可する”、ではなく”すべてのIPからのアクセスをブロックする、ただし特定のIPを除く”という構成になります。
直感的ではないので難しいく感じるかもしれませんが、ここはどうしても慣れが必要な部分です。
②グローバル管理者に多要素認証を要求するポリシー
①で特定のIPにアクセスを限定することはできましたが、許可IP内からはフリーアクセスであることに変わりはありません。
そこでもう一歩進んだ防御として、グローバル管理者（全体管理者）のアクセスに多要素認証を要求するポリシーを追加してみます。
まず対象のユーザーで、ディレクトリロールの[グローバル管理者]を指定します。
これでグローバル管理者ロールを付与されたアカウントのみを対象とすることができます。
サービス別に管理者ロールを分けて運用されている場合は、各ロールを対象にしてください。
（ただ、グローバル管理者のみで運用している場合が殆どかと思うので、グローバル管理者前提で進めます）
対象アプリはすべてのクラウドアプリ、条件は一旦指定なしにします。
許可の項目でアクセス権の付与を選択し、[多要素認証を要求する]にチェックを入れます。
これでサインイン時にSMSやMicrosoft Authenticatorを使った多要素認証が必須となります。
このようにある程度アクセス可能な条件を絞ったら、あとはその中でアクセス要件を設定していくだけです。
このようにポリシーを複数組み合わせることで、高度なアクセス制御を実装できます。
ポリシー作成時の注意点
最後に、条件付きアクセスを理解する上で押さえておかなければならないポイントをいくつかご紹介します。
（先述のAzureBlogでも触れられています）
①条件付きアクセスポリシーに優先順位はない
条件付きアクセスではアクセス時に全てのポリシーが評価されます。
そのためどれか一つをパスすればOK、というものではなく、
・すべてのブロックポリシーを回避し、
・すべてのアクセス許可ポリシーを満たす
必要があるのです。
特に、1つのアクセス許可ポリシー内ではor条件が指定できるのに対し、複数のアクセス許可ポリシー間では必ずAnd条件となる点に注意が必要です。
②アクセス権の付与より、ブロックが優先される
設定画面を見ていると、「ブロックとアクセス権付与がバッティングしたらどうなるんだろう？」と思うかもしれません。
これについては、常にブロックが優先されます。
ブロックポリシーを作成する際は、慎重に対象外を定め、アクセス不能な状況に陥らないよう注意しましょう。
まとめ
いかがでしたでしょうか。
条件付きアクセスはAzureADのセキュリティレベルを向上させる上で非常に有効ではありますが、とっつきにくいのも事実です。
またどうしても環境に依存する部分があるので、トライアンドエラーが必要になります。
最初は検証環境や少人数間で挙動確認しながら、最適な構成を探してみてください。
この記事が少しでも参考になりましたら幸いです。
この記事が気に入ったらサポートをしてみませんか？