パスワード変更だけでは安心できない。外部連携・共有リンク・ログイン状態の点検

不正アクセスや情報漏えいの案内を受けたとき、まずパスワードを変える。それ自体は大切ですが、その一操作ですべてのアクセス経路が閉じるとは限りません。外部ツール用のキー、ログイン済みの端末、共有リンクなどは、パスワードとは別に管理されている場合があります。

この記事では、特定の事故の復旧完了を判定する方法ではなく、小さな会社の担当者が保守会社やサービス提供者と確認するための点検項目を整理します。実際に事故が疑われる場合は、公式の個別案内を優先し、記録を残しながら対応してください。

アクセスの「入口」は一つではない

一般的なWebサービスには、人がログインする入口のほかに、別のサービスが情報を読み書きするための入口があります。たとえば予約の転記、フォームの通知、SNSへの自動投稿などです。

同じアカウントに関係していても、利用者のパスワード変更、ログイン状態の解除、APIキーの失効、共有URLの削除は別の操作になり得ます。すべてのサービスで同じ挙動になるわけではないため、「変えたから大丈夫」ではなく、公式ヘルプで対象範囲を確かめます。

案内メールのリンクをそのまま押す前に、いつも使うブックマークなどから公式サイトへ入ります。提供元が発表している内容と一致しているか、自社の契約や機能が対象かを確認しましょう。パスワードや認証コードをメールで返信してはいけません。

実際の侵害が疑われるときは、気になる設定や通知、確認時刻を記録します。顧客データやキーの値をチャットへ貼り付ける必要はありません。「どの連携があるか」という名称だけでも相談は始められます。見覚えのないアクセスがあれば、社内の責任者と提供元へ早めに連絡してください。

パスワードを変更したら、そのサービスでログイン済みの端末やセッションを確認できるか調べます。変更時にすべて解除されるのか、一部が残るのかはサービスによって異なります。不要なログイン状態を終了する手順も確認します。

あわせて、復旧用メール、電話番号、多要素認証の登録先が現在の担当者のものか見直しましょう。前任者の端末しか承認できない状態では、事故対応の途中で会社自身も入れなくなることがあります。多要素認証は重要ですが、それだけで既存の共有リンクや連携キーまで保護されるわけではありません。

Googleアカウントの公式案内では、「Googleでログイン」に使う接続と、ドライブなどのデータへアクセスする接続を確認できます。ログインに使っただけなのか、ファイルの読み書きまで許可したのかを分けて把握します。

APIキーやトークンは、必要に応じて発行元で無効化・再発行します。自社の管理画面から設定値を消すだけでは、発行元で古いキーが生きている可能性があります。一方、何に使っているか分からないキーを突然失効させると、予約や問い合わせの連携が止まることもあります。

平常時の更新なら、接続先と担当者を特定し、新しい認証情報へ切り替えて動作確認後に旧情報を失効させる手順を検討します。ただし、悪用が進行している疑いがあれば、停止を優先すべき場合があります。事故の切迫度に応じて、提供元や保守担当と判断してください。

資料やプレビューのURLは、知っている人が開ける方式なのか、ログインや所属の確認が必要なのかを確かめます。送ったメールを消しても、リンク自体が有効なら相手のコピーから開ける場合があります。不要なリンクは提供元の手順で無効化します。

退職者や契約終了した外注先の招待も確認対象です。必要な人を削除しないよう、権限一覧を確認してから一件ずつ整理します。接続を解除しても、すでに相手が取得したコピーまで消せるとは限らない点も忘れないでください。

たとえばフォームから表計算へ転記する連携を外すなら、回答が消えたと誤解しないよう、どこまで受け付けられるかを事前に共有します。停止中の代替窓口と、再接続後のテスト担当も決めます。「安全のために外したが、必要な問い合わせを見失った」という別の事故を防ぐためです。

普段から連携ごとに用途、発行元、責任者を残しておけば、事故時にゼロから調べる負担を減らせます。認証情報は承認された秘密情報の管理先へ置き、一般の共有表には貼らないでください。

記録には認証情報そのものを書かず、管理場所だけを残します。「パスワード変更済み」の一行ではなく、どの入口を確認したかが分かること。これが次の担当者にも引き継げる点検になります。