ritouです。
世の中様々なことが起こります。地震、津波、サ終。まずは落ち着きましょう。
自分が使っているサービスに不正ログインされたかも？と思った時に最初にやるべきこと
概要
最近、不正ログインの話を耳にする機会が増えたのではないでしょうか。証券会社は言わずもがな、GoogleやX（旧Twitter）のアカウントなど、被害はすぐそこに潜んでいます。
巷では 突然現れた親切な人 が「パスキーを設定しましょう」といった対策を教えてくれるのですが、本記事では それよりも先にやるべきこと、そしてサービス提供者が意識すべきこと を解説します。
一人暮らしの自宅に帰宅した際、家の鍵が空いていたら最初に何をしますか？
私が子供の頃の秋田の田舎では、昼間は鍵をかけない家も珍しくありませんでした。しかし、現代ではそうもいきません。
鍵が開いたままの状態で帰宅したときは、まず「誰かが侵入していないか」を最優先で確認する必要があります。
このような状況では、空き巣や不審者がまだ室内に潜んでいる可能性もあるため、安易に中へ入るのは非常に危険です。
おわかりいただけただろうか... オンラインサービスの不正ログイン対応も、これと全く同じ 話なのです。
では、オンラインサービスの不正ログインが疑われた際の「家に誰かいないかチェック」とは何でしょうか？
オンラインサービスにおける「家に誰かいないかチェック」は「ログインセッションの確認」
オンラインサービスで個人情報を閲覧したり、投稿や設定変更を行ったりするには、ログインしている必要があります。
もし悪意のある攻撃者と正規のユーザーが同時にログインしていると、互いに設定を上書きしあう「設定変更合戦」のような事態になりかねません。
少し前に話題になった「Googleアカウントに知らない海外の電話番号が登録され、削除しても復活する」というケースは、まさにこの状況だったと考えられます。
そのため、不正ログインが疑われた場合に真っ先に確認すべきは「ログインセッション」なのです。
これは緊急事態です。現在操作している自身のセッション以外、心当たりのないログインセッションは全て強制的にログアウトさせましょう。 すべての確認・変更作業は、そのあとに行います。
各サービスでログインセッションを確認する方法
- アカウントにアクセスしたデバイスを確認する - Google アカウント ヘルプ
- Xのサードパーティアプリとログインセッションへの権限の付与および取り消し: (補足: OAuth関連の権限管理と一体化しており、少し分かりにくいかもしれません)
可能ならば「何が行われたか」を確認し、設定変更
不審なログインセッションを全て無効にしたら、次にアカウントでどのような操作が行われたか（アクティビティ履歴）を確認します。
全ての設定項目を一つずつ確認するのが理想ですが、現実的には難しい場合もあるでしょう。
例えばGoogleには、ログインや設定変更といったセキュリティ関連の操作履歴を確認する機能があります。これをチェックすることで、不正ログインや意図しない変更が行われたことに気づけます。
アクティビティの確認が終わったら、連絡先やログイン方法（パスワード、パスキー、登録済みのメールアドレスや電話番号など）の設定を見直します。もし攻撃者によって新たなログイン方法が登録されていると、再び侵入される可能性があるためです。
同時進行で攻撃者も設定変更などをしている可能性があるため、全ての設定変更が終わった後に念のため再度ログインセッションを確認することも重要です。
開発者は上記の流れを意識して機能を用意することが重要
MIXI IDではログインセッションやセキュリティアクティビティという名前で機能を提供しています。
大手サービスは、長年にわたって攻撃と戦ってきた経験から、こうした機能の重要性を認識し、実装しているケースが多いでしょう。
一方で、比較的新しいサービスや、パスワード認証のみを提供しているサービスでは、これらの機能が見過ごされがちなのが現状です。
今回紹介したセッション管理やアクティビティ履歴の機能は、新規登録やログインといった機能と同様に、ID管理における**「標準機能」として実装すべきである**、という認識が重要になります。
これらの機能が当たり前に実装されるようになれば、さらにその先にある、ID連携サービス間でのセキュリティ情報共有(SSFの活用)といった、より高度な施策も視野に入ってきます。
まとめ
不正ログインを疑った際に最も優先すべきは、パスワード変更ではなく、自分以外の不審なログインセッションを全て強制的にログアウトさせることです。これにより、攻撃者によるリアルタイムでの不正操作を阻止できます。
その後、アカウントの活動履歴（セキュリティアクティビティ）で被害状況を把握し、攻撃者によって変更された可能性のある連絡先やログイン設定（パスワード、パスキー等）を元に戻しましょう。
また、サービス開発者側は、ユーザーがこうした自己防衛を行えるよう、「ログインセッションの管理機能」と「セキュリティイベントの確認機能」を、ID管理の標準機能として提供することが強く求められます。
ヘルプなどで一連の確認の流れを載せておくことも重要かもしれませんね。
ではまた。
Discussion