正解：エ
各選択肢の解説
ア退職時の手続に、各クラウドサービスのパスワードを変更する作業を追加する。
誤り。サービスごとの手作業に戻すと、サービスが増えるたびに漏れが起きます。 今回の原因は、認証基盤を通らずに入れる経路が残っていたことです。経路を残したまま 手順を増やしても、同じ見落としを繰り返すおそれがあります。
イ認証基盤のパスワードを長く複雑なものにし、定期的に変更させる。
誤り。これは認証基盤へのログインを推測されにくくする対策です。元社員は認証基盤を 使わずに入っているので、認証基盤のパスワードをどれだけ強くしても、この経路は ふさがりません。守る場所が違います。
ウ各クラウドサービスのログイン記録を毎月確認し、退職者の利用を探す。
誤り。記録の確認は、起きた不正を後から見つける発見的な対策です。見つかるまでの 最大1か月は入られたままになり、再発そのものは防げません。予防策と組み合わせる 補助として位置づけます。
エ連携したクラウドサービスでは、個別のIDとパスワードによる直接ログインを無効にする。
正解。シングルサインオン経由でしか入れないようにすれば、認証基盤のIDを止めるだけで 全サービスへの入口が閉じます。導入前のIDという抜け道をなくすのが根本の対策です。
理解を深めるために
正面の門を閉めても、裏口が開いていれば意味がない
シングルサインオンを入れると「認証基盤でIDを止めれば、全部のサービスに入れなくなる」と 考えがちです。しかしそれが成り立つのは、すべての入口が認証基盤を通るときだけです。 導入前に作ったIDとパスワードでの直接ログインが残っていれば、それは鍵を回収し忘れた 裏口と同じです。
なぜ抜け道が残るのか
- クラウドサービスの多くは、SAML連携を設定しても、元からあるIDとパスワードでの ログインを自動では止めない（設定で「シングルサインオンのみ」に切り替える必要がある）
- 導入前から使っていた社員には、サービス側のIDとパスワードがそのまま残っている
- 退職時の手続は認証基盤だけを対象にしているので、サービス側のIDは誰も止めない
対策は、連携したサービスで直接ログインを無効にし、入口を認証基盤の1か所にそろえることです。 障害時のために管理者用の直接ログインを残す場合は、特権IDとして別に管理し、 使える人と使った記録を押さえます。導入時には、サービス側に残っている既存のIDも 棚卸しして整理します。
混同しやすいものとの違い
| 対策 | 何に効くか |
|---|---|
| 直接ログインの無効化 | 認証基盤を通らない経路そのものをなくす |
| 退職時に各サービスのパスワード変更 | 個別の経路を手作業で閉じる（漏れが起きる） |
| 認証基盤のパスワード強化 | 認証基盤への推測・総当たり（今回の経路とは別） |
| ログイン記録の定期確認 | 起きた不正の発見（予防ではない） |
場面から対策を選ぶ問題では、まず「その人はどの入口から入ったか」を確かめると、 入口そのものをふさぐ選択肢を見つけやすくなります。