Digital Incident Management 第二話 情報「漏えいはない」と、まだ言えない 改訂版
今回のお話に登場する「MACアドレス」について、少しだけ説明します。
MACアドレスとは、パソコンやスマートフォンなどのネットワーク機器にある通信インターフェースを識別するための番号です。一般に、ネットワーク上で機器を見分ける手がかりとして使われます。
会社によっては、このMACアドレスを端末の登録情報として管理し、ネットワークへの接続制御に利用することがあります。
ただし、MACアドレスそのものがパスワードのような秘密情報というわけではありません。また、登録を削除しただけで、紛失した端末があらゆるシステムから遮断されるわけでもありません。実際にどこまで接続を制限できるかは、会社のネットワーク構成や認証方式によって異なります。
だからこそ、端末を紛失した際には、ネットワーク側の接続制御だけでなく、端末管理、クラウドサービスの認証、アクセスログなどを併せて確認する必要があります。
黒木厳が向き合うのは、単にパソコンを一台なくしたという問題ではありません。
**その端末が、いつ、どこに、どのように接続していたのか。そして、何が起きていないと確認できるのか。**
危機管理は、分からないことを、分かったことにしないところから始まります。
第二話 情報「漏えいはない」と、まだ言えない
「まず、警察への遺失届を進めてください。それから、プレスリリースの原案を用意してください」
黒木厳がそう告げると、会議室に集まった三人の視線が一斉に彼へ向いた。
情報セキュリティ担当の佐伯、総務部の田辺、広報部の三浦。三人とも、黒木が復帰したばかりであることを知っていた。前任者の不在によって、彼が本来のCIO業務に加え、引き継ぎ案件と部門横断の調整まで抱えていることも承知していた。
それでも、誰も「復帰初日からですか」とは言わなかった。
会社支給のノートPCが一台、行方不明になった。
単なる備品の紛失として処理することもできるかもしれない。しかし、その端末が業務用であり、社内ネットワークやクラウドサービスへの接続に使われていた以上、所在確認だけで済ませるわけにはいかなかった。
「警察への届出は総務で進めます。紛失した社員から、最後に端末を確認した場所と時間を聞き取ります」
田辺が手帳を開いた。
「お願いします。本人の記憶が曖昧でも、推測で埋めないでください。最後に確実に使った時刻、移動経路、立ち寄った場所。分かっていることと、本人の推測は分けて記録してください」
黒木は佐伯に向き直った。
「端末管理システム上の最終接続時刻は？」
「確認中です。資産管理番号は特定できています。遠隔ロックの可否についても調べています」
「では、端末管理側で実行できる措置を確認してください。認証セッションの失効も、利用しているサービスごとに検討する。ただし、遠隔消去は証拠保全や復旧の可能性を考慮して判断してください。消去すれば、すべて解決するわけではありません」
「了解しました」
「それから、もう一つ。ネットワーク側の接続制御は、どうなっていますか」
佐伯の手が止まった。
「ネットワーク側、ですか」
「端末のMACアドレスが登録されているはずです。その登録が接続許可に使われているのか、まず確認してください。もしMACアドレスを使った接続制御があるなら、紛失端末の登録を無効化できるか調べる。実施した場合は、時刻と担当者、処理結果を記録してください」
「分かりました。NAC側の登録状態も確認します」
「ただし、MACアドレスの登録を無効化することと、端末をあらゆるシステムから遮断することは同じではありません。ネットワーク側の制御と、端末管理、クラウド認証は分けて考えてください」
黒木はホワイトボードに三つの言葉を書いた。
**ネットワーク。端末。認証。**
「それぞれの担当が、どこまで対応したのかを見えるようにしてください。『対策済み』という一言でまとめないこと。何を、どの範囲で、いつ実施したのかが必要です」
佐伯は三つの言葉を見つめ、それから手元の資料に書き込んだ。
「承知しました」
黒木は三浦に向き直った。
「プレスリリースの原案もお願いします」
「公表する前提でしょうか」
「まだ決めていません。ですが、必要になってから書き始めるのでは遅い。現時点で確認できている事実を基に、骨格を作ってください」
三浦は少し考えた。
「紛失した端末の概要、現在の調査状況、お客様への影響、今後の対応、といった構成でしょうか」
「その構成でいいでしょう。ただし、確認できたことと、調査中のことを分けてください。『情報漏えいはありません』と書くなら、その根拠を説明できなければならない。調査が始まったばかりなのに、安心させるためだけの文言を先に置くことはできません」
三浦は頷いた。
「公表の要否と時期は、調査結果や法務の見解も踏まえて判断する、ということですね」
「そうです。発表すること自体が目的ではありません。必要な相手に、必要な情報を、正確に伝えることが目的です」
会議室の空気が、少しだけ引き締まった。
黒木は壁の時計を見た。午前十時二十分。まだ午前中だというのに、今日の予定表はすでに役に立たなくなりつつあった。
しかし、予定表が崩れることと、仕事の順序を失うことは違う。
彼はホワイトボードに四つの項目を書き足した。
一、警察への届出と端末の所在確認。
二、接続制御と認証の確認。
三、アクセスログの保全と影響範囲の調査。
四、社内外への説明準備。
「この四つを並行して進めます。ただし、担当は分ける。私は判断と調整に責任を持ちます。技術的な確認をすべて私の机に集める必要はありません」
佐伯が尋ねた。
「Google Workspaceへの移行作業は、どうしますか。今日も予定が入っています」
黒木はすぐには答えなかった。
Microsoft 365からGoogle Workspaceへの移行は、まだ完了していない。メール、カレンダー、共有ファイル、アクセス権限。移行対象によって進捗は異なり、旧環境と新環境の両方が業務に使われている。
この時期に端末紛失が起きたということは、確認すべき環境が一つではないということでもあった。
「移行全体を反射的に止める必要はありません。ただし、事故対応に影響する作業は棚卸しします。認証設定、アクセス権限、アカウントの切り替えなど、今回の調査と交差する作業は、影響を確認するまで慎重に扱ってください」
「通常のデータ移行は？」
「影響がないと確認できたものは、責任者の判断で継続して構いません。ただし、監査ログの取得や接続状況の確認を難しくする変更は避ける。移行作業の記録と、インシデント対応の記録を混ぜないでください」
佐伯は手元の資料に書き込んだ。
「移行責任者にも連絡します」
「お願いします。今日の移行判定会議は予定どおり開催しましょう。ただし、事故対応の状況によっては議題を組み替えます。延期する場合も、理由と影響を明確にしてください」
黒木はホワイトボードを指した。
「危機が起きたからといって、ほかの仕事が消えるわけではありません。逆に、ほかの仕事があるからといって、危機対応を後回しにもできない。だからこそ、優先順位と担当を明確にするんです」
会議は二十分ほどで終わった。
三人がそれぞれの部署へ戻ると、黒木の机には端末の資産管理記録、前日の業務予定、移行プロジェクトの進捗表が届いていた。どれも必要な情報だったが、それらをすべて一人で読み込んでいては、判断する時間がなくなる。
彼は秘書に連絡し、午前中の予定を一部組み替えた。移行作業の細かな確認はプロジェクト責任者へ、端末の技術的な調査はセキュリティチームへ。自分の手元には、判断が必要な事項と、部門間で調整が必要な事項だけを集める。
その直後、佐伯から電話が入った。
「黒木さん、端末の管理情報を確認できました。最後に管理サーバーと通信した時刻は、昨夜の二十一時四十七分です」
「それ以降の通信がない、という意味ですね？」
「はい。ただし、通信がないことだけでは、端末が使用されていないとは言い切れません。電源が切れている可能性もありますし、ネットワークに接続していない可能性もあります」
「その認識でいいです。確認できた事実と、そこから推測できることを分けて報告してください」
「遠隔ロックについては、実行可能な状態か確認しています。認証セッションについても、関連サービスごとに調べています」
「進めてください。端末が見つかった場合の対応も考えておきましょう。見つかったから即座に安全、というわけではありませんから」
電話を切った黒木は、資料に時刻を書き込んだ。
二十一時四十七分。
その時刻を境に、端末の状況は分からなくなっている。しかし、それが何を意味するのかは、まだ分からない。
Windows Helloによる指紋認証が設定されていること。業務データは原則としてクラウドに保存され、端末のローカル領域には業務データを保存しない運用になっていること。
どちらも、被害を抑えるための重要な対策だった。
しかし、対策が存在することと、その対策が今回の端末で十分に機能していると確認できたことは同じではない。
端末内に一時ファイルやキャッシュが残っていないか。ブラウザーに認証情報やセッションが保持されていないか。紛失前後に不審なアクセスがなかったか。クラウド側で利用できる監査ログは何か。
確認すべきことは、まだ残っている。
そして、ログの確認は、端末管理システムだけで終わるものでもなかった。
午後一時、佐伯が再び会議室に入ってきた。今度はノートPCではなく、紙の資料を持っていた。
「黒木さん。ネットワーク側の登録状態について、確認結果が出ました」
「聞かせてください」
「紛失端末のMACアドレスは、社内ネットワークの接続管理システムに登録されています。ただし、MACアドレスの登録だけで、すべてのネットワーク接続が許可される構成ではありません。認証や接続条件も組み合わせています」
「では、登録を削除すれば完全に遮断できる、とは言えないわけですね」
「はい。接続制御の仕組みを確認したうえで、該当端末の登録を無効化する手順を進めています。実施後は、拒否されたことを示す記録も確認します」
黒木は頷いた。
「識別情報そのものをログから消さないでください。登録を無効化することと、過去の記録を消すことは別です。端末を識別できなければ、過去の接続履歴を調べることも難しくなります」
「分かっています。登録変更の前後で状態を記録し、処理時刻と担当者も残します」
「お願いします。では、次にアクセスログです。昨夜の二十一時四十七分を境にするだけではなく、その前後を十分に確認してください。紛失したと考えられる時間帯と、本人の最後の利用時刻を照らし合わせます」
佐伯は資料を開いた。
「ネットワーク側の接続履歴、端末管理側の通信履歴、Microsoft 365の監査ログ、Google Workspace側の利用記録を、それぞれ取得可能な範囲で確認します。ログの保持期間や記録できる項目が異なるため、同じ条件で単純比較はできませんが、時刻を合わせて整理します」
「それでいい。まず、何が記録されているのかを確認する。ログが存在しないことと、不審なアクセスが存在しなかったことを混同しないでください」
「はい」
「アカウントのサインイン履歴も確認してください。普段と異なる場所や端末からのアクセス、失敗した認証の繰り返し、紛失後の不自然なセッション利用がないか。ただし、普段と違うというだけで不正アクセスと断定しないこと。本人の業務や移動の可能性も照合します」
佐伯は、少し表情を引き締めた。
「ログに不審な記録があれば、侵入されたということですか？」
「いいえ。疑わしい記録は、調査を深める根拠です。単独の記録だけで侵入を断定することはできません。逆に、明確な異常が見つからないからといって、すべてのリスクがなくなったとも言えない」
黒木は資料の余白に線を引いた。
「端末の接続履歴と、クラウドへのアクセス履歴は別です。ネットワークに接続していない端末でも、別の場所から盗まれたセッション情報が悪用される可能性はあります。だから、端末側の記録だけでなく、クラウド側の認証と利用状況も確認する必要があるんです」
「分かりました」
「それと、今回の調査で取得したログは、原本の保全を優先してください。分析用の複製を作り、取得時刻、取得者、取得方法を記録する。後から説明できる形にしておきましょう」
佐伯が退出した後、黒木は時計を見た。
午後一時二十分。
プレスリリースの原案を確認する時間を確保する必要があった。だが、その前に一つだけ、関係部署へ確認しておきたいことがあった。
端末は、Microsoft 365とGoogle Workspaceのどちらを利用していたのか。
正確には、どちらか一方だけを使っていたとは限らない。移行期間中の端末には、旧環境の認証情報やブラウザーセッションが残っている可能性がある。新環境の利用が始まっていれば、そちらのログも調査対象になる。
黒木は移行プロジェクト責任者に連絡した。
「紛失端末について、Microsoft 365とGoogle Workspaceの利用状況を確認したい。対象社員のアカウントが、どのサービスに、どの認証方式で接続していたか。移行の進捗表だけではなく、実際の利用状況を確認してください」
「承知しました。対象者の利用サービスと、移行対象の範囲を整理します」
「アカウントや権限を不用意に変更しないでください。事故対応側と調整しながら進めましょう。必要なアクセス制限は速やかに実施しますが、調査のために残すべき記録まで失わないように」
通話を終えると、広報部の三浦が原案を持ってきた。
「第一稿です。紛失した端末の概要、現在の調査状況、今後の対応を記載しています。確認できていない項目は、未確認と明示しました」
黒木は受け取った文書に目を通した。
文章は簡潔だった。会社支給のノートPC一台が所在不明となっていること。会社が端末の所在確認と影響範囲の調査を進めていること。確認できた事実に基づき、必要な対応を行うこと。
余計な説明はなかった。
「いいですね。これなら、調査が進んだ段階で必要な情報を追加できます」
三浦は尋ねた。
「ネットワークの接続制御やアクセスログの確認についても、発表文に含めますか」
「実施したことを確認できたら、説明に含めるか検討しましょう。ただし、技術的な措置を実施したという事実と、それによってリスクが完全になくなったという結論は別です。現時点では、どこまで調査できたのかを正確に表現することが大切です」
「公表の要否と時期は、まだ未定ですね」
「はい。調査結果、法務の見解、経営陣との協議を踏まえて判断します。必要な報告や本人通知がある場合は、その要件と期限も確認してください」
三浦が退出すると、黒木は椅子の背にもたれた。
ようやく、対応の骨格ができてきた。
だが、問題が解決したわけではない。警察への届出は進行中であり、端末は見つかっていない。ネットワーク側の登録無効化も、実施結果の確認が必要だった。アクセスログの調査は始まったばかりで、情報漏えいの有無も確定していない。
プレスリリースは用意できたが、公表の判断はこれからだ。
そのとき、携帯電話が震えた。
総務の田辺からだった。
「黒木さん、紛失した社員と連絡が取れました。本人は、昨夜の会食後に駅へ向かったところまでは覚えているそうです。ただ、電車に乗ったかどうか、その後どこに立ち寄ったかは、はっきりしないとのことです」
「分かりました。本人を責めるのは後にしてください。今は記憶を整理して、確認できることを一つずつ確認する。会食の店、移動経路、利用した交通機関。領収書や決済履歴など、本人が確認できる手がかりも整理しましょう」
「警察への届出に必要な情報も、引き続き集めます」
「お願いします。会社としての対応と、本人への聞き取りは分けて進めてください。本人の記憶だけに頼らず、確認可能な記録を探しましょう」
通話を終えた黒木は、窓の外を見た。
端末はまだ見つかっていない。情報漏えいの有無も確定していない。プレスリリースは用意できたが、公表の判断はこれからだ。そして、Google Workspaceへの移行も止まったわけではない。
仕事は一つも片づいていないように見える。
しかし、何が分かっていて、何が分かっていないのか。誰が何を調べ、誰がどの判断を担うのか。その輪郭だけは、少しずつ明確になっていた。
黒木は机に戻り、インシデント対応表を開いた。
ネットワーク側の接続制御。端末管理側の状態。クラウドサービスの認証記録。紛失前後のアクセスログ。
それぞれの項目に、担当者と確認状況を書き込んでいく。
彼は、まだ完了していない項目に目を留めた。
アクセスログの確認。
そこには、まだ何の結論も記されていなかった。
だが、何も書かれていないことは、何も起きていないことの証明ではない。
黒木はペンを置いた。
「まず、記録を集めましょう。判断は、そのあとです」
その言葉を、今度は自分自身に向けていた。
危機対応は、通常業務を消してくれない。通常業務もまた、危機対応を待ってはくれない。
だからこそ、CIOが必要なのだ。
そして、今回の事故が単なる端末の紛失で終わるのか、それとも別の問題につながるのか。
その答えは、まだログの向こう側にあった。
