IDaaSと条件付きアクセス：AiTMフィッシングによる多要素認証の突破と再発防止

ID管理と条件付きアクセスに関する次の記述を読んで，設問に答えよ。

K社は，従業員約650名の住宅設備の卸売業者である。本社のほか全国に12の営業所があり，営業担当者の多くは顧客先や自宅からも業務を行っている。K社は業務システムの多くをSaaSに移行しており，認証は3年前に導入したIDaaS（以下，Iサービスという）に統合している。IDの管理とIサービスの運用は，情報システム課の4名が担当している。

〔Iサービスの概要〕

Iサービスは，各SaaSに対してSAMLによるシングルサインオン（以下，SSOという）を提供する。利用者がIサービスで認証に成功すると，Iサービスは利用者のブラウザにセッションCookieを発行する。セッションCookieの有効期間は12時間であり，有効期間内は，Iサービスは再認証なしで各SaaSへのSSOを行う。条件付きアクセスのポリシーは，サインインのたびに評価される。その際，セッションCookieを用いたサインインでは，セッションの作成時に完了した認証方法（多要素認証を含む）が引き継がれる。

利用者がパスワードを変更しても，発行済みのセッションCookieは有効期間が切れるまで有効である。管理者が利用者を指定して“セッションの取消し”を実行すると，その利用者の全てのセッションCookieが無効になる。なお，IサービスによるSSOでアクセスする場合，各SaaSは独自のセッションをもたず，アクセスのたびにIサービスのセッションCookieを確認する。そのため，取消し後の次のアクセスでは，Iサービスでの再認証が求められる。

グループウェアSaaS（以下，Gサービスという）のメール機能は，ブラウザのほか，IMAP及びSMTPによる送受信にも対応している。IMAP及びSMTPでは，ID及びパスワードだけで認証する方式（以下，基本認証という）が用いられ，その認証はIサービスが行う。基本認証では，多要素認証を要求することができない。

Iサービスの多要素認証の方式は，スマートフォンの認証アプリに届くプッシュ通知を承認する方式（以下，プッシュ承認という）である。K社の条件付きアクセスのポリシーを表1に示す。

表1　条件付きアクセスのポリシー（抜粋）

注記1　一つのサインインが複数のポリシーの条件に一致する場合は，一致した全てのポリシーの制御を満たしたときだけ許可される。どのポリシーの条件にも一致しないサインインは拒否される。 注記2　P4は，本社及び営業所の複合機が，スキャンした文書を基本認証のSMTPで送信するために設けた。複合機の更新は来年度の予算で計画されている。

〔インシデントの発生〕

9月8日の10時ごろ，営業部のBさんは，自宅で業務中に“経費精算の承認依頼”という件名の電子メールを受信した。本文のリンクを開くと，Iサービスと同じ外観のサインイン画面が表示されたので，BさんはIDとパスワードを入力した。直後にスマートフォンにプッシュ通知が届いたので，Bさんは承認した。その後，画面には経費精算SaaSのトップページが表示され，Bさんは不審に思わなかった。

9月8日の11時，取引先のV社から，“K社から振込先の口座を変更するというメールが届いたが，本当か”という問合せがあった。情報システム課のL主任は，Bさんのメールアカウントが不正に使われたと考え，11時30分にBさんのパスワードを変更した。その後，15時にL主任が調査したところ，Bさんのメールボックスに，V社とのメールを外部のメールアドレスに転送し，Bさんの受信トレイからは削除するルール（以下，転送ルールという）が10時20分に作成されていた。L主任は，Iサービスのサインインログを確認した。Bさんに関係するログと，同日の深夜に記録されたログの抜粋を表2に示す。

表2　Iサービスのサインインログ（抜粋）

注記　Bさんは，自宅では198.51.100.88のISP回線を利用している。Bさんは，警告メールを迷惑メールと考え，開封していなかった。偽のサインイン画面に入力した後にBさんが承認したプッシュ通知は，No.3のときの1回だけである。

No.1は，一つの送信元から多数の利用者に対して，よく使われるパスワードを1回ずつ試す【 a 】の特徴を示している。No.1では全て失敗していたが，L主任は，同じ手口が今後も繰り返されると考えた。

No.3は，Bさんが開いたリンク先のサーバが，Bさんと正規のIサービスとの間で通信を中継していたことを示している。このように，利用者と正規のサイトの間に入り，入力された認証情報やセッションCookieを窃取する手口は，【 b 】型フィッシングと呼ばれる。また，No.5のサインインは，表1の【 c 】によって許可されていた。

しかし，11時30分のパスワードの変更では，No.6のアクセスは防げなかった。L主任は，①Bさんのパスワードの変更に加えて，直ちに実施すべき対応を行った。その後，V社への送金被害がないことが確認された。

〔再発防止策の検討〕

L主任は，再発防止策として，表3の移行計画を作成した。

表3　移行計画（抜粋）

項番1について，L主任は，②パスキーを用いると，No.3と同じ手口で偽のサイトに誘導されても認証が成功しないと説明した。項番3について，L主任は，③P2は，ゼロトラストの考え方に合わないと指摘した。項番5について，情報システム課のM課長から“ポリシーの対象から除外すると，かえって危険ではないか”という質問があった。L主任は，④除外しておく理由を説明し，除外する代わりにセキュリティキーの保管とサインインの通知で不正利用を防ぐことを説明した。

〔退職者アカウントの棚卸し〕

L主任は，インシデントを機に，主要なSaaSのアカウントを棚卸しした。退職者のIサービスのアカウントは，人事システムとの連携によって退職日に無効化されている。棚卸しの結果を表4に示す。

表4　アカウントの棚卸しの結果（抜粋）

L主任は，⑤顧客管理SaaSでは，退職者が退職日の後にサインインできたことに着目し，顧客管理SaaSのサインインの方式をSSOだけに限定するよう営業企画課に依頼した。