NECは10月20日、システム開発・保守業務の委託先へのサイバー攻撃をきっかけに、顧客のシステム障害と個人情報を含む情報漏えいを確認したと発表しました。盗まれた正規アカウントの認証情報が悪用されたとしています。

NECの発表によると、委託先が攻撃を受けたのは9月下旬です。影響のあった複数の顧客には、すでに個別の連絡を行いました。10月21日未明時点で確認できた告知には、委託先の企業名、顧客名、漏えい件数の全体は示されていません。被害が確認された部分と、調査を続けている部分を分けて整理する必要があります。

正しいアカウントでも利用者が正しいとは限りません

今回の発表が示す重要な点は、攻撃者が委託先の端末から正規アカウントで顧客のシステムに入ったことです。ログインに使われた情報が形式上正しくても、本人の操作であるとは限りません。パスワードが合っているかどうかだけでは、開発や保守のために用意した接続の安全性を判断できない問題が表れています。

NECは、顧客のサーバー内のファイルが暗号化され、各種システムが利用できない状態になったと説明しています。これは単に情報を見られた可能性の話ではなく、業務の継続に関わる被害です。ただし、どのサービスがいつまで止まったか、すべてが復旧したかという機能別の状況は、今回の告知だけでは確定できません。

これとは別に、NECが作成し、顧客や委託先などとの情報共有に使っていたクラウドストレージ内のファイルの漏えいも確認されました。ファイルには顧客の保有する個人情報やシステム関連情報などが含まれていたとしています。システム停止とファイル流出は、必要な対処も調べる対象も異なる被害として把握しなければなりません。

個人情報の詳細については、判明次第顧客に報告する方針です。したがって、現段階で氏名、住所、決済情報などの具体的な項目が一律に流出したと補うことはできません。情報を保有する顧客が、それぞれの利用者へ何を案内するかも今後の確認事項です。NECと取引があるという理由だけで、すべての企業や利用者を被害対象に含めることは避ける必要があります。

委託の接続が業務の境界を越えます

システムの保守では、外部の担当者が障害調査や更新に対応するため、顧客環境へ接続することがあります。企業の外にある端末でも、許可された業務のために内部の情報へ触れられる場合があります。業務を任せる範囲と、システム上で許可される範囲が一致しているかどうかは、委託元と委託先の双方に関わる論点です。

一般に、必要以上に広い権限が付いていれば、一つの認証情報の悪用が影響する範囲も大きくなり得ます。一方、権限を細かくするだけで今回の被害が確実に防げたと断定することはできません。具体的にどの権限が使われ、どの経路から侵入し、どこまで操作されたかの調査結果が必要です。一般的な対策の話を、今回の原因認定の代わりにはできません。

NECは発覚後、同社が管理する端末を委託先に貸し出すなど、必要な対策を進めているとしています。端末の管理をそろえることは、設定や監視の責任を分かりやすくする一つの方法です。ただし、端末の貸与だけで過去の流出が取り消されるわけではなく、それだけで再発防止が完了したとも言えません。

今後は委託先管理と個人情報管理を強化するとしています。利用する端末、認証、操作権限、ファイル共有の範囲などを含め、実際にどの管理がどう変わるかが問われます。取引先の担当者が交代したときや、保守の契約が終わったときに、接続権限を見直せる仕組みがあるかも、企業一般が確認する観点になります。

現場に現れる二つの負担

ファイルが暗号化された職場では、通常の画面や帳票が使えず、受付、照会、処理の確認などに時間がかかる場合があります。今回の顧客で具体的にどの業務が止まったかは未公表です。それでも、復旧の説明を読む際には、サーバーが動いたという説明と、職員が必要な業務を再開できたという説明を分けて見ることが役立ちます。

情報流出への対応では、どのファイルが対象かを確かめ、個人情報の項目と関係する人を特定する負担が生じます。これはシステムを元に戻す作業と同時に進めなければならないことがあります。顧客が自社の利用者へ連絡するためには、委託先から委託元、委託元から顧客への情報伝達が途切れないことが必要です。

利用者側では、いつも使っているサービスに障害が出ても、今回のNECの事案が原因かどうかはサービス提供元の発表で確かめる必要があります。全国的に障害や不正アクセスの報道が続いていても、似た症状だけで原因を一つにまとめることはできません。各社の告知にある対象サービス名と発生時刻を確認することが出発点になります。

また、利用者が問い合わせる際に、本人確認書類などを必要以上に送り直すことは避けたいところです。どの情報が必要かは、サービス提供元が正式に示す窓口と方法で確認します。今回の事故を装って認証情報を求める連絡が来る可能性を考える際も、実際にそうした二次被害が確認されたという事実とは区別して案内する必要があります。

共有ストレージには別の確認が必要です

クラウドストレージは、関係者が同じ資料を参照できる便利さがあります。一方、複数の組織が同じ場所を利用すると、誰がどの資料にアクセスできるかが見えにくくなることがあります。今回のようにシステム関連情報も含まれていた場合は、ファイルの内容に応じた調査と対処が必要になります。

一般的には、資料に記載された設定情報が現在も使われているか、共有相手に不要な権限が残っていないかを確認する観点があります。ただし、今回認証用の秘密情報がファイルに含まれていたと公表されたわけではありません。システム関連情報という広い表現から、パスワードや鍵の流出を独自に断定することはできません。

停止したシステムを再び使う判断にも段階があります。感染や侵入の影響を調べること、データの正しさを確かめること、接続方法を見直すことは、それぞれ異なる作業です。利用者に向けては、全機能の再開なのか、限られた機能なのか、過去の履歴にも問題なくアクセスできるかといった説明があると、業務を戻す判断がしやすくなります。

企業にとっては、緊急対応にかかる人員や時間も無視できません。ただし、今回の復旧費用、顧客側の損失、補償について確定した金額は確認していません。被害の規模を分かりやすくしようとして推定額を足すことはせず、各社が公表した範囲に従って評価する必要があります。

責任の所在と再発防止を同時に見る

委託先が最初に攻撃を受けたという説明は、委託元の説明責任がなくなることを意味しません。顧客との契約や、誰がどの管理を引き受けていたかによって確認すべき内容は変わります。今回の発表だけで、特定の会社の法的責任や契約違反を認定することはできません。まずは利用者の保護と業務の回復に必要な情報が示されるかが焦点です。

同時に、外部へ委託していること自体を危険の原因と単純化することも適切ではありません。専門的な保守を受けながら安全を保つためには、業務上必要なアクセスをどのように認め、利用状況をどう確かめるかが重要です。委託の有無だけで優劣を決めず、具体的な管理とその検証方法を見る必要があります。

現時点では、攻撃者の属性、最初の侵入手段、被害件数、顧客ごとの復旧状況は未確認または続報待ちです。別の企業や自治体で起きた事件との関連も確認していません。今後はNECの追加発表、被害顧客の公式案内、漏えい情報の特定、運用を変えた後の検証結果を更新の条件とします。

資料が追加された場合は、どこまでが確認済みの被害で、どこからが対策上の念のための対象なのかも整理します。多くの人に広く注意を呼びかけることと、個人情報が実際に外部へ出た人を確定することは同じではありません。対象が変わった理由まで説明されることが、顧客と利用者の混乱を減らすために必要です。

記録を残すことが復旧判断を支えます

顧客企業では、どの時刻に何が使えなかったかを整理することが、問い合わせと復旧後の照合に役立ちます。現場の担当者が別々に把握している情報を集めると、同じ障害が続いているのか、機能ごとに回復が違うのかを確認できます。ただし、事故調査に必要な記録の扱いは担当部署の方針に従い、現場の判断だけで消したり書き換えたりしないことが重要です。

バックアップがある場合でも、単にデータを戻せばすべて解決するとは限りません。戻す時点が業務の記録と整合するか、復旧後に同じ接続経路が残っていないかなどを確認する必要があります。今回どのようなバックアップが使われたかは未公表です。一般に考えられる復旧の条件と、NECが今回実施した具体的な作業を混ぜないようにします。

顧客へ個別に連絡したという説明がある一方、利用者への説明は顧客側から行われる場合があります。運営主体が異なると通知の出る時刻や内容にも違いが生じ得ます。連絡がまだ来ていないことだけで対象外とも、すべての利用者が対象とも決め付けず、自分が利用するサービスの公式な案内を確かめる必要があります。

写真：サーバー設備のイメージ（Unsplash）。

確認資料：NEC「委託先への不正アクセスに起因するお客さまのシステム障害、情報漏えいに関するお詫び」（10月20日）。https://jpn.nec.com/news/info/20261020.html

まとめ

NECの委託先で盗まれた認証情報が悪用され、顧客システムのファイル暗号化と、共有ファイルの漏えいが確認されました。対象の詳細は調査中であり、顧客ごとの公式案内と、接続・情報共有の管理をどう改善するかが今後の焦点です。