よんけんだより

思いついたら書いてます。なので、あんまり読みやすくないかも。備忘です。

条件付きアクセスの想定アクセス洗い出し

条件付きアクセスはそもそも、MSの推奨としては、ゴールデンパターンから足し引きして考えてねーってものなのですが、いかんせん「そうじゃない!1から考えるんだ!」が求められることもあります。

その場合について思いを馳せます。

そもそもMicrosoft365はID/PWでアクセスできるんすわ

これに尽きちゃうんだけど、条件付きアクセスはなんも設定しなければ、ID/PWで認証通ります(近年の更新でMFAが強制的に...みたいなのがあった気がしますが、、)

で、セキュリティの重要さが浸透してきた近年では、「ID/PWだけでいいわけないっしょwww」となりました。

なんでかっていうと

  • 偽のユーザーがアクセスして、攻撃しちゃう
  • 真のユーザーでも、うっかり漏洩しちゃう
  • 真のユーザーのプライベートパソコンからうっかりアクセスしちゃう
  • なんも管理されてないスマホからうっかりアクセスされちゃう

とかあるわけですよ。

流石に嫌ですよね。ビジネス影響大きいですよね。なんか、適当なサービスならいいかもしれないですけど、ビジネスアプリ。しかもMS365ってofficeと密接だし、大事過ぎるデータですよね。

だからこそ、「どんなアクセスだったら許容するか」って考え方が重要なんです。
そういうワケで、そこのフィルターをする条件付きアクセスがあるワケです。

やっぱWhat if 大事すぎ

👆に書き忘れたけど、MDCAと連携する条件付きアクセスとか、Azureポータルどうする?とかクライアントアプリどうする?ということは一旦置いておいて、デバイス信頼とユーザー信頼とロケーション信頼に基づく条件付きアクセスについて考えて行きます。

各3要素について

条件付きアクセスでは、「どういう接続?」をていぎするときには下記3点が使われることが多いんじゃなかろうかと思ってます。

どういう用途のデバイスがアクセスしてきていいかの整理がとても重要です。また、どういう設定の端末が飛んでくるかの整理も重要です。どういう設定がー。っていうのはIntuneのコンプライアンスポリシーと連携してます。詳細は省きます

  • ユーザー

誰がアクセスしてくんの?って話。

後々、誰がどのデバイス使うの?とか、どのライセンス振るの?みたいな話に発展しがちなので、早めに「くくり」として抑えるのマジで大事。

  • ロケーション

どこから認証が飛んでくるの?って話。例えば、社内LANがMAC認証あるなら、色々と認証超えてることになるからセーフにできるなって考え方になることが多い。キーワードは信頼済みロケーション

フュージョンさせて通信サブジェクトを見えるようにする

ユーザー、デバイス、ロケーション。この3つを組み合わせて、「業務上どの通信が発生しうるか」整理します。つまり、XユーザーはJ端末を使う!といった整理や、YユーザーはJ端末使わない。といった整理が生まれます。この整理をサブジェクトっていうと分かりやすいなーって思ってます。正しい言葉があったら教えてください

この時マトリクスがあるといいです。

どのアクセスにどのリスクを感じるか

というワケなんです。アクセスを許容したい通信サブジェクトが見えたら次はその許容したい通信のリスクを考えます。この時に考えたいのはなんのためにその認証を行うかです。なんも考えずMFA達成しても意味なかなっちゃうので。

  • 接続してきたユーザーが不正なユーザでないか確かめたい
    多用素認証がいいですよね。スマホとか携帯に飛ばすやつ。なりすまししづらいです。いわゆる、ユーザーが不正でないチェックです。
  • 接続してきたデバイスが安全な設定になっててほしい。
    Intuneのコンプライアンスポリシーで実現可能です。「コンプライアンスポリシーに準拠していること」という制御項目が条件付きアクセスのポリシーにあります。
    ただし、ゲストユーザーには効きません。
    このデバイスのチェックはいわゆるデバイスが不正でないチェックです。
  • ロケーション
    例えば、社内LANがMAC認証とか証明書とかで制御されてる場合にそのIPから飛んでくる端末はGPOとかで制御されてるし、AD参加してるし、安全だよな!という担保があるよね、という体で特定IPからのアクセスは許可する〜とかできます。知ってるところか、知らんところかでもリスクは変わるはずです(ゼロトラストだーって言われてる時代だけども、やっぱ残るよね)

この3点を、業務上使う認証サブジェクトに照らして考えていき、どのサブジェクトはどういうリスクがある?っていうのを洗い、どういう認証を求めるか考えていきます。

それをマトリクスにした上で、満たす様に条件付きアクセスを考えます。

ここからは努力の世界...

漏れてしまうパターンについて

多分、9割くらいの確率で考慮が漏れちゃうと思います。

ここまでやった上で、追加認証を要求するサブジェクトがあるってことは、ID/PWだけでアクセスできちゃうものがあります。

逆そこで定義されていないアクセスはどうする?っていうのまで拾ってこそかもしれません。

四の五の書いたけど

やっぱりMS様提供してくれてるゴールデンパターンと接続サブジェクトを見比べて抜け漏れ検討するのがいいと思うな・・・。

Microsoft Entra ID の条件付きアクセスとは - Microsoft Entra ID | Microsoft Learn

関連参考リンク

https://github.com/yusukekodama/PMActivities/blob/master/AzureADKnowledge/KnowledgeBase.md

PMActivities/Webinar/Schedule.md at master · yusukekodama/PMActivities · GitHub

条件付きアクセスの基本的な考え方 | Microsoft Learn

条件付きアクセスの基本的な考え方 | Japan Azure Identity Support Blog (jpazureid.github.io)

github.com