城咲子|情報システム部セキュリティ担当のつぶやき(ぼやき)

情シスの日常あるある備忘録 ※ほぼ愚痴です

城咲子|情報システム部セキュリティ担当のつぶやき

【内部不正事例】NTTグループ情報漏洩インシデントの深層分析と、レジリエントな内部セキュリティ態勢構築への設計図

NTTグループで発生した約928万件の顧客情報漏洩。10年間にわたり、特権IDを持つ内部関係者によってデータが盗まれ続けていたという事実は、セキュリティに携わる者として見過ごすことのできない深刻な事態です。

これは、高度なサイバー攻撃によるものではなく、最も基本的であるはずの内部統制の崩壊によって引き起こされました。

東証プライム上場企業の情シスでセキュリティを担当する私、城咲子(CISSP/登録セキスペ)の視点から、このインシデントの深層を分析し、私たちが自組織を守るために今すぐ何をすべきかを考察します。

これは対岸の火事ではありません。あなたの会社は「性善説」に依存したセキュリティ運用になっていませんか?



10年間検知できなかった「内部犯行」の構造

まず、このインシデントがどれほど深刻な問題をはらんでいるか、事実関係を整理します。

  • 実行者: NTTビジネスソリューションズに派遣されていた元派遣社員。
  • 手段: 運用保守業務で利用していた「システム管理者アカウント(特権ID)」を悪用。
  • 結果: 約10年間にわたり、クライアント企業69社、約928万件の顧客情報を不正に持ち出し、名簿業者に売却。
  • 発覚: 2022年にクライアントから指摘があったにも関わらず検知できず、最終的に警察の捜査によって発覚。

私がこのインシデントで最も重大視しているのは、「なぜ10年間も検知できなかったのか」という点です。NTT自身の調査報告書[1]は、その原因を明確に示しています。それは、セキュリティの基本原則がことごとく破られていたという現実です。

崩壊していた「4つの基本的な防御線」

今回の不正行為は、4つの致命的な欠陥が重なったことで可能になりました。これは、情シス担当者として決して見逃してはならないポイントです。

1. データアクセスの無統制(DBへの直接アクセス)

システム管理者が、保守作業用の端末から本番環境のデータベースに直接アクセスし、データをダウンロードできる状態でした[1]。

本来、本番データへのアクセスは厳格に制限され、必要な場合でも申請と承認に基づく一時的な許可や、データのマスキング(匿名化)が必須です。保守端末に直接データをダウンロードできる状態は、情報漏洩の経路を自ら用意していたに等しいと言えます。

2. 物理的な持ち出し経路(USBメモリの利用許可)

保守作業端末において、USBメモリなどの外部記憶媒体の利用が許可されていました[1]。

いくらシステム上でデータをダウンロードできても、それを外部に持ち出す手段がなければ、被害は限定的だったかもしれません。しかし、USBポートが解放されていたことで、ダウンロードしたデータは容易に物理的に持ち出されてしまいました。

3. リアルタイム検知の欠如(アラート機能の不備)

900万件を超えるデータを長期間にわたってダウンロードするという異常な振る舞いをタイムリーに検知する仕組みが存在しませんでした[1]。

「いつもと違う操作」「大量のデータアクセス」は、内部不正の典型的な兆候です。これらの高リスクな操作を検知し、即座にアラートを上げる仕組み(SIEMやUEBAなど)が機能していれば、10年間も被害が続くことはなかったはずです。

4. 監査システムの形骸化(ログ監視の不備)

アクセスログや操作ログの定期的かつ実効性のあるチェックが実施されていませんでした[1]。

これが決定打です。ログは「取得しているだけ」では何の意味もありません。「誰が、いつ、何をしたか」を独立した立場の第三者が定期的にレビューしてこそ、初めて「監査」として機能します。

さらに言えば、2022年に外部から指摘を受けて実施した社内調査でも不正を発見できなかった[1]事実は、調査対象のログを管理する特権管理者自身が不正行為者であった場合、内部調査がいかに無力であるかを証明しています。


「狐に鶏小屋の番をさせる」性善説の終わり

このインシデントの根底にあるのは、「システム管理者は信頼できる」という「性善説」に基づいた運用です。

しかし、セキュリティの世界、特に私の信条である「属人性の徹底排除」の観点から言えば、これは最も危険な考え方です。システム管理者は、その強力な権限ゆえに、性悪説(ゼロトラスト)に基づいて厳格に管理・監視されなければなりません。

「信頼するが、検証する(Trust but Verify)」という言葉がありますが、現代のセキュリティ、特に内部脅威対策においては「決して信頼せず、常に検証する(Never Trust, Always Verify)」というゼロトラストの原則こそが基本です。


NTTの是正措置を情シス目線で評価する

インシデント発覚後、NTTグループは再発防止策を公表しました[1][10]。これらの対策は、私たち情シス担当者が「自社ならどうするか」を考える上で非常に参考になります。

1. リモートデスクトップ(VDI)方式の導入

対策: 保守作業を中継サーバへのリモートデスクトップ(画面転送方式)に変更し、保守端末にデータが保存されないようにした[1][10]。 評価: これは非常に有効な対策です。VDI(仮想デスクトップ)化により、データそのものはサーバ側に残り、手元の端末には画面情報しか転送されません。これにより、ローカルへのデータダウンロードという主要な漏洩経路を技術的に遮断できます。

2. 外部記憶媒体の利用禁止

対策: 保守作業端末でのUSBメモリなどの利用を技術的・物理的に禁止した[1]。 評価: これはセキュリティの基本中の基本です。データ持ち出しの物理的な経路を断つことは必須です。ただし、実務上は「正規の業務でデータ転送が必要な場合」の代替手段をどう確保するかが課題となります。NTTでは「複数管理者の相互チェック」を必須とするシステム的な統制を導入した[1]としており、これは「一人では不正ができない」仕組みとして評価できます。

3. 独立した第三者によるログ監査

対策: 各組織での定期的なログチェックに加え、業務担当外の第三者組織による抜き打ちチェックを導入した[1]。 評価: これこそが「監査の形骸化」を防ぐ鍵です。ログのレビューは、操作を行った当事者やその上長ではなく、利害関係のない独立した部門(例えば、内部監査部門やセキュリティ部門)が行わなければ意味がありません。「狐に鶏小屋の番をさせる」状態を解消する、極めて重要な一歩です。

4. 共有アカウントの廃止

対策: 共有アカウントを廃止し、すべての操作が個人に紐づく仕組みを導入した[10]。 評価: これもまた、特権ID管理の基本です。「誰がやったか」を特定できない共有IDは、不正の温床となります。すべての操作に明確な「責任の所在」を持たせることは、不正の抑止に直結します。


あなたの会社は大丈夫?委託元に突きつけられた「監督責任」

この問題は、NTTグループだけの話では終わりませんでした。

個人情報保護委員会(PPC)は、NTTに業務を委託していた56の事業者(つまりNTTの顧客)に対しても調査を行い、その委託先(NTT)に対する監督が不十分であったと指摘しました[3]。

これは、私たち情シス担当者にとって非常に重い事実です。 「大手企業だから」「契約書にセキュリティ条項を入れているから」という理由だけで、委託先のセキュリティ対策を鵜呑みにしていないでしょうか?

PPCは、「委託先の監督を適切に行うよう」広く注意喚起を行いました[3J。これは、委託元企業も「他人事」では済まされないという強いメッセージです。今や、委託先が適切なセキュリティ対策(アクセス管理、ログ監視など)を実施しているかを、実態ベースで確認・監督する責任が委託元にあるのです。

私の信条の一つに「自分が動くのではなくルールを変えて人と組織を動かす」というものがありますが、まさに委託先管理とは、契約とルール、そして実態の監査を通じて、外部組織を適切に動かす(コントロールする)ことに他なりません。


まとめ:情シス担当者が今すぐ確認すべきこと

今回のNTTのインシデントは、セキュリティの基本がいかに重要であるか、そして「信頼」という名の「油断」がいかに危険であるかを、私たちに痛烈に突きつけました。

「情シス部門は経営の片腕」であるべきです。経営に資するためにも、私たちは自社のセキュリティ体制を今一度、厳しく見直す必要があります。

【今すぐ確認すべきチェックリスト】

  1. 特権ID管理:
    • 特権IDは誰が保持していますか? その権限は「最小権限の原則」に基づいていますか?
    • 特権IDの利用申請、承認、返却のプロセスは確立されていますか?
    • 共有IDは存在していませんか? もし存在する場合、操作者を特定できる仕組みがありますか?
  2. アクセス制御:
    • 本番環境のデータベースに、保守端末や開発環境から直接アクセスできてしまいませんか?
    • VDIや踏み台サーバを経由するなどの、適切なアクセス経路制御が行われていますか?
  3. ログ監視・監査:
    • 重要な操作(特権IDの利用、大量データアクセス)のログは取得・保管されていますか?
    • そのログを、「操作担当者と利害関係のない独立した立場」の人間が定期的にレビューしていますか?
    • 異常な操作(夜間や休日のアクセス、大量ダウンロード)を検知し、即座にアラートを上げる仕組みはありますか?
  4. 物理・論理的対策:
    • 業務上不要なPCのUSBポートは無効化されていますか?
    • データの持ち出し(メール添付、クラウドストレージ、USBメモリ等)を制御・監視するDLP(情報漏洩防止)ソリューションは導入されていますか?
  5. 委託先管理:
    • 業務委託先に対して、契約書上の確認だけでなく、セキュリティ対策の実態(ログ監査の状況、アクセス制御の方法など)を定期的に報告させていますか?

このインシデントを「他人事」とせず、「自社ごと」として捉え、組織のセキュリティ体制を見直すきっかけにしていただければ幸いです。


引用・参考資料

  1. NTTビジネスソリューションズに派遣された 元派遣社員によるお客さま情報の不正流出について|NTTビジネスソリューションズ株式会社
  2. NTT西日本‐関連企業からの不正流出発覚で行政処分|株式会社アトムシステム
  3. 株式会社NTTマーケティングアクト ProCX 等に対する個人情報の保護に関する法律に基づく勧告等及び個人情報取扱事業者等に対する注意喚起|個人情報保護委員会
  4. お客さま情報の不正流出に関するお詫びとお知らせ|西日本電信電話株式会社
  5. お客さま情報の不正持ち出しを踏まえたNTT西日本グループの情報セキュリティ強化に向けた取組みについて|株式会社NTTマーケティングアクトProCX
  6. 個人情報928万人分を漏えいさせたNTT西日本グループ2社に対し、個人情報保護委員会が指導と勧告を実施|オプティマ・ソリューションズ株式会社
  7. お客さま情報の不正持ち出しを踏まえたNTT西日本グループの情報セキュリティ強化に向けた取組みについて|NTTビジネスソリューションズ株式会社
  8. 【2025】情報漏洩が発生したNTT系の企業を3社紹介!原因・補償内容・NTTの事後対策まで徹底解説|キャド研](https://cad-kenkyujo.com/jyouhourouei-ntt/)
  9. お客さま情報の不正流出に関するお詫びとお知らせ|株式会社NTTマーケティングアクトProCX
  10. お客さま情報の不正持ち出しを踏まえた NTT西日本グループの情報セキュリティ強化に向けた取組みについて(別紙)|株式会社NTTマーケティングアクトProCX
  11. VDIのセキュリティリスクとは?対策について徹底解説|株式会社インターネットイニシアティブ
  12. VDI(仮想デスクトップ)とは?仕組みやメリット・デメリットをわかりやすく解説|NTTPCコミュニケーションズ
  13. テレワーク成功の要、リモートデスクトップの長所短所とセキュリティ問題|ティエスエスリンク株式会社
  14. VDIはなぜ高セキュリティと言われるのか?その理由を検証:コラム|株式会社日立システムズエンジニアリングサービス
  15. セキュリティ事故に学ぶVDI(仮想デスクトップ)の有効性|NTTコムウェア
  16. VDIとリモートデスクトップの違いとは?両者の特長と用途を解説|moconavi NOTE
  17. Privileged Access Management (PAM) Best Practices|Heimdal Security
  18. Privileged Access Management Best Practices|SSH Communications Security
  19. 12 Privileged Access Management Best Practices in 2025|Securden
  20. What Is Zero Trust Architecture? Key Elements and Use Cases|Palo Alto Networks
  21. Zero Trust Architecture: A Systematic Literature Review|arXiv
  22. How to Implement a Zero Trust Security Strategy in an Enterprise Environment|ZPE Systems
  23. DLP - 情報漏洩防止|NTTコムウェア
  24. DLPとは?情報漏洩を防ぐためのセキュリティ対策方法|NTTコミュニケーションズ
  25. DLP - ICT用語集|NTT西日本
  26. お客さま情報の不正持ち出しを踏まえたNTT西日本グループの情報セキュリティ強化に向けた取り組みの進捗状況について|株式会社NTTマーケティングアクトProCX