はじめに
本記事はMicrosoft Security Advent Calendar 2023、11日目の記事になります。
いいね👍よろしくお願いします！
シリーズ3部作です。
IdP基盤を整理したことによるメリット
IdP基盤をオンプレADとEntra IDのみの構成に整えることができたことで、Entra IDを中心にアカウント保護やSSOを考えていくことができるようになりました。
IdP基盤を整理することのメリットはいくつもありますが、セキュリティ目線で考えると、
- ユーザーリスク
- サインインリスク
の検知があげられます。
IdPがバラバラだった場合
以下のようにユーザーからのアクセスがあった場合、認証基盤がバラバラだった場合はそれぞれなにも検知できず、紛れ込んでいる悪意のあるユーザーもサービスを利用することができてしまいます。
IdPを統一した場合
上記のサインインをまとめて把握することができると、以下のように、どう見ても怪しいサインイン試行があります。こういったサインインに対して、自動的に多要素認証を求めるなど、本人確認を徹底することができ、悪意のあるサインインを防げます。
SaaSアプリのSSO化を進める
そもそもSSOとは
シングルサインオン（SSO）とは、複数のWebアプリケーションにログインする際に、1回の認証で複数のアプリケーションにアクセスできるようにする仕組みです。つまり、複数のWebアプリケーションにログインするために必要なIDやパスワードを1回入力するだけで、複数のWebアプリケーションにアクセスできるようになります。この仕組みにより、ユーザーは複数のIDやパスワードを覚える必要がなくなり、セキュリティも向上します。
IdP整理前
IdP基盤の整理を終えた時点でははEntra ID経由でログインをしているのはM365を含めて3つくらいのSaaSアプリケーションでした。大半のSaaSアプリにはID/PASSでログインをしている状態。
この状態ではリスク検知ができないため、M365や各種SaaSアプリにログインするときに、必ずEntra IDを経由させる＝SSO（シングルサインオン） をさせるように準備を進めていきました。
SaaSアプリをSSOにしていった図
SaaSアプリのSSOは設定が簡単
Entra IDのドキュメントには、SSOを構成する手順がアプリケーションごとにまとまっています。
例えば
- Box
- Zoom
- Adobe
のように、対象のSaaSアプリ側での設定まで踏み込んだドキュメントになっているので、自社で使用しているアプリがこのリストにあれば設定は簡単にできます。このリストにのっていない
SSOは金がかかる
SSOを構成すると、ユーザーはID/PASSの管理をする必要がどんどんなくなっていくため、楽になっていきます。また、前述のとおり、セキュリティ的にもどんどん強固になっていきます。
ただ…
SSOを企業側がやりたがっていることををSaaSアプリ側もわかっていまして…😂
SSOを構成することができるプランは上位プランのみになっているサービスが多いです。
例 DocuSign
電子署名を取り交わすだけなら下位プランでもOKですが、SSOを構成するためには最上位のプランでなければなりません。
例 Bitly
短縮URLサービスのBitlyも、URLを短縮するだけなら下位プランでOKですが、SSOを構成するために最上位プランの契約が必要になります。
SaaSアプリのSSO化をどんどん進める
ということで、SSO化を進めるためには、利用SaaSのプラン変更が伴うためコスト増につながります。が、それ以上にセキュリティ上メリットがあること、ユーザー利便性もあがることを訴え、（おそらく）会社にも理解をしてもらったので各種アプリのSSO化を進めていきました。
プラン変更は営業の方へのコンタクト、打ち合わせ、契約書の巻き取りなどなどそれなりに工数が多く、また「ただSSOにしたいだけなのにこんなに値段変わるの！」というサービスもあり、時間的にも精神的にも大変でした。
Entra IDに認証を集約する！
細かいトラブルはありましたが、SSOができるようになったアプリケーションは順調に増えて、今日時点で30以上になっています。並行して自社開発の業務アプリケーションもSSOできるように追加開発を進めました。
ここまでくると、ユーザーとしても「情シスがSSO化を進めている」と気づいてきて、新たに開発する業務アプリケーションや、既存の小さく運用されていたSaaSに対して、
- 「〇〇（SaaS名）はSSOにできませんか？」
- 「▲▲はSSOにしたほうがいいんですよね？」
といった声が上がるようになってきました。
Entra ID経由でサインインしているアプリと、そのサインイン回数をまとめたグラフ。
リスクの監視ができるようになった
SaaSアプリや自社開発WebアプリをSSOできるようにしていくことで、何かのアプリを利用する際には必ずEntra IDのチェックを通ることになりました。
こういう構成にすることで、以下のような自動修復アクションを構成することができました。
リスクの高いサインイン
リスクの高いサインインアクティビティは、例えば「不可能な移動」があげられます。直前のサインインが日本のIPアドレスからだったのに、その数分後にアメリカのIPからアクセスがあった場合、「不可能な移動」と判定されます。リスクの高いサインインアクティビティがあった場合は再度 「多要素認証以上」の再認証 を求めています。
リスクの高いユーザー
リスクの高いユーザーとして判定されるのは、主にパスワード関係の侵害になります。不正アクセス試行があったユーザーや、パスワード漏洩が認められた場合に「リスクが高いユーザー」となります。
リスクが高いユーザーには、パスワード変更を求めます。 Entra IDにはセルフサービスパスワードリセット（SSPR）という仕組みがあり、ヘルプデスクがサポートせずとも、自分だけでパスワード変更ができます。
再掲
中編まとめ
M365筆頭に、業務に必要なアプリケーションのほとんどの認証がEntra IDを利用することになり、リスク監視、そして自動修復ができるようになりました。（時系列的には並行して進めていましたが）そもそものEntra IDへのログインがパスワードレスになれば、社内はほぼパスワードレス環境になります。
シリーズ3部作です。