はじめに
本記事はMicrosoft Security Advent Calendar 2023、10日目の記事になります。
いいね👍よろしくお願いします！
シリーズ3部作です。
きっかけ
所属企業にて、2022年7月頃、情報システム部門に異動。種々の課題感に対する解決策（ここも話すと長くなる）としてMicrosoft 365 E5を導入することに決定。2023年1月にテナントにライセンスが適用され、E5セキュリティの実装を始める。同時に、組織内でIdPが複数運用されていることに対しても課題感を持っていたため、IdPの整理・統合も始める。
さらに同時期に、セキュリティ侵害の多くの原因が、パスワード漏洩だということを知る。
フィッシングメールでパスワードが漏洩（個人1位）し、クレジットカードが不正利用（個人4位）されたり、インターネット上のサービスに不正ログイン（個人10位）されたり…。スマホ決済の不正利用（個人5位）もですね。標的型攻撃による機密情報の窃取（組織3位）や、ビジネスメール詐欺（組織7位）も多くがパスワード入手を目的にしたものだと考えられます。
もちろん、セキュリティ侵害には他にもいろいろな原因・手法はあるんですけど、まず食い止めるべきはパスワードの漏洩だなと考えたわけです。
目的が決まる
まずは複数運用されているIdP基盤の整理を進め、認証を1元管理できる体制を築くことにします。そのうえで、Microsoft Authenticatorを使用したパスワードレス認証に進んでいくことで、アカウント保護をしていきます。
IdPの統合
さて、さっそくIdPの統合を進めていきます。
IdP統合の話は2023年2月頃から始めました。
当時運用されていたIdPは
- オンプレAD
- Entra ID
- サードパーティ製IdP
の3種類。
既存の運用は所属部署などの社員属性に従い、ユーザーをオンプレAD or サードパーティ製IdPにユーザー作成。M365へログインさせるために、オンプレAD → サードパーティ製IdP → Entra IDの順にユーザー同期。ごく一部のSaaSアプリはサードパーティ製IdPからSSOする構成だが、基本的にSaaSアプリはそれぞれID＆パスワードでログイン。
ユーザーのサインインがそれぞれのIdPに分散しているため、危険なサインイン等の判定ができていなかった。またSaaSアプリはほぼID/PASSでのログインだったため、ユーザーによっては付箋にパスワードが書いている紙をモニターに貼っているような状況。
旧環境
これを、Entra Connectを利用してオンプレADからEntra IDへ同期をするだけのシンプルな構成に変更を進めていった。
シンプルな構成に変更するのは、もちろんサードパーティ製IdPにかかるコストを減らしたかったこともあるが、M365や各種SaaSアプリへのログインをEntra IDに集約することで、危険なサインインや危険なユーザーを察知できるようにしたかったということがある。SSOできるアプリが増えるとユーザーも楽ですし。
新環境 すごくシンプルですよね。
IdP変更は大変
IdPの統合と簡単にはいうけれど、オンプレADとEntra IDをEntra Connectで同期する構成にするということは、この図でいうとサードパーティ製IdPにしかしなかったユーザーはオンプレADへユーザーを新規作成しないといけない。
すると、サードパーティ製IdPにいたユーザーにとっては、ログインURLやパスワードが変更になるためそれなりにユーザー影響がある作業となる。パスワードも、オンプレADにユーザーを新規作成するため、初期パスワードが作成され、その後ユーザー自身でパスワード変更をしてもらう必要もある。新規パスワードをどうにかしてユーザーに伝える必要もある。
ユーザー通知
実際の業務では、IdP切替の必要性やスケジュールをユーザーに通知するため、対象ユーザーをM365グループに招待。M365グループにしておけば、あとからTeamsチームを作成して、そこでフォローすることもできるかなーとか考えてました。
IdP切替についてはそのM365グループに対してメールを繰り返し送信。
( º дº)＜ 「〇月×日に初期パスワードを送信します！」
( º дº)＜ 「▲月■日以降、ログインURLが変わります！」
( º дº)＜ 「初期パスワードはログイン後、すぐに変更してください！」
そしてIdP切替当日
ゴールデンウィーク明けのある日、夕方17時頃にIdPの切替を実施。サードパーティ製IdPからユーザーを削除し、オンプレADへユーザを作成。サードパーティ製IdPにユーザーアカウントがあるユーザーは、今までのログインURLやパスワードではログインできなくなった。
するとユーザーから「ログインできない」と問い合わせが。
こちらとしては何度も案内をしてきたことなので、
( º дº)＜ 「何度もメール送ってますよね？今日が切替実施日ですよ」
と答えます。
ただどうも話を聞いていると様子がおかしい。
情シス内でまわりを見ると「メールはきていない」という問い合わせが複数きている。
鳴る電話。届くメール。
急遽関係者とパートナーで会議。Exchange Onlineのログをたどる。
原因判明😨
M365グループへのメール送信は、Exchange管理センターで下図項目のチェックを入れておかないと、Outlookの各ユーザー受信箱に配信されるのではなく、グループのメールボックスにのみ配信される。（PowerShellでも設定可）
グループのメールボックスは、特に通知などがこないため、大半のユーザーはメールに気づいていないというオチでした。だれも見ていないグループのメールボックスにメールを送り続けていた自分が恥ずかしい…。
切替当日は24時を過ぎるまでユーザー対応と作戦会議。当然翌日もユーザー対応のため予定をすべてキャンセルしてメールや電話を受けまくり。
ログインができなくなっているユーザーは、会社のメールやTeamsもすべて見られなくなっているため、個人の連絡先が分かっていないと連絡がつかない。
個人の連絡先は情シスでは管理しておらず、簡単にアクセスできないため、所属部署の上長経由で対象ユーザーの個人アドレスに連絡をしてもらった。
また、サードパーティ製IdPにサブアドレスとして個人アドレスを登録していた人も若干いたため、そういう人には個別にメールを送る。
2～3日はユーザー対応に追われていました😨
IdP統合完了
IdP統合を行い、全ユーザーに対して再サインインが求められるため、実施日はサインイン数が急激に増えています。
大変なことは他にもたくさんありましたが、なんとかIdP統合作業は終わりました。
IdP基盤はきれいな形になりましたが、まだこのころSSOになっているSaaSアプリはM365+2つほど。社内で運用されている様々なSaaSはパスワード認証のままです。Entra IDもパスワード認証のため、まだまだパスワードレス認証には程遠い状態。
ログ保管のすすめ
少し話は変わりますが、上図のようにサインインの数などを取得するためにはEntra IDのサインインログをどこかにためておく必要があります。Entra IDは簡単にログ保存の設定ができます。
設定をする場所は以下。
Microsoft Entra 管理センター → 診断設定
※LogAnalytics側からでも設定できます。
診断設定にいき、Azure LogAnalyticsワークスペースを接続設定してあげると、テーブルごとに任意の日数監査ログをためておくことができるようになる。サインインログや監査ログを取得し、LogAnalyticsやSentinelでKQLクエリが書けるようにしておくと監査目的以外にも、こういったIdP切替や認証方法の切替を行う際にも、 「全体〇人中あと〇人がサインイン済んでいない」 とか 「Aさんがサインインを繰り返し失敗しているからサポートしてあげよう」 とか、データから様々なインサイトを得て先手を打つことができます。
ログの保管には当然コストがかかります。
ログ保存は必要な期間だけにしましょう。
シリーズ3部作です。