2026年9月25日
ゼロトラストWGリーダー　諸角昌宏

背景

ゼロトラスト実装の5ステップ（NSTACモデル）入門シリーズのプロテクトサーフェスについて、いろいろと質問をいただいている。その中で、John Kindervagの言っている「Protect Surface is much smaller and more knowable than the Attack Surface.（プロテクトサーフェスは、アタックサーフェスよりもはるかに小さく、はるかに把握しやすい。）」 は根拠があるのかという質問が寄せられている。そこで、事例を交えてこれを説明していきたいと考えた。まず、「この内容に該当するような事例があるか」ということになるが、ここでAIに支援を求めたところ、Target社の情報漏えい事件が上がってきた。

はじめに

「ゼロトラスト実装の5ステップ（NSTACモデル）入門」シリーズでは、ゼロトラストの出発点として「アタックサーフェス（攻撃対象領域）ではなく、プロテクトサーフェス（保護対象領域）に焦点を絞る」という考え方を紹介してきた。しかし「アタックサーフェスが広すぎて把握しきれない」という説明は、ともすれば抽象的に響いてしまう。

本ブログでは、この点を示す実例として、2013年に発生したTarget社の大規模情報漏えい事件を取り上げる。この事件は、セキュリティ業界で最も広く分析されてきた事例の一つであり、アタックサーフェスの広さと、プロテクトサーフェスを正しく隔離することの重要性の両方を、同時に教えてくれていると考えている。

Target社の大規模情報漏えい事件　～　何が起きたか

攻撃者は2013年11月15日、空調・冷凍設備の保守を請け負う地方の業者、Fazio Mechanical Services社から盗んだ認証情報を使って、Target社のネットワークに侵入した。Fazio社は、電子請求書の提出・契約管理・プロジェクト管理のためだけに、Target社のシステムへリモートアクセスできる契約だった。捜査関係者の話として、攻撃者はFazio社の従業員にフィッシングメールを送り、その認証情報を窃取したと報じられている（なお、これはTarget社・Fazio社の双方から公式に表明された確定した手口ではないことは述べておく）。

そこを足がかりに、攻撃者はTarget社のネットワーク内を横移動し、全米1,797店舗（後年の報道による）のPOSシステムにまで到達した。Target社がネットワークを適切に分離していなかったため、本来つながっているべきでないシステム同士が結びついてしまっていたことが、被害を広げる決定打となった。

結果として、約4,000万件のカード情報と、最大7,000万人分の個人情報が流出した。被害総額は、報道時期や算定方法によって幅があり、2億ドル超から、2014年時点のアナリスト試算では最大4億2,000万ドルに達するという推計も示されている。

なぜこれが「アタックサーフェスの広さ」の良い例なのか

「クレジットカード情報を守る」と考えるとき、誰も「空調業者の請求システムへのアクセス」を守るべき対象だとは思わない。しかし、実際の侵入口はそこだった。

アタックサーフェスには、こうした「守るべきだと誰も思っていなかった場所」が無数に含まれている。取引先、保守業者、委託先など、業務上必要だからという理由だけで存在する、無数の細い糸がある。そのすべてを事前に洗い出し、守り切ることは事実上不可能である。これが、ゼロトラストが「アタックサーフェス全体を守る」という発想を捨て、「本当に守るべきもの（プロテクトサーフェス）に焦点を絞る」という発想に転換する理由である。

空調業者の請求システムはプロテクトサーフェスにできるのか

ここで一つ、重要な問いが浮かぶ。「空調業者の請求システムも、DAAS（データ・アプリケーション・資産・サービス）として定義すれば、プロテクトサーフェスにできるのではないか」というものである。

答えは「YES」である。契約情報や請求データ（D）、ベンダー用ポータル（A）、それをホストするサーバー（A）、リモートアクセスの仕組み（S）、これらを1つの業務システムとして束ね、プロテクトサーフェスとして定義することは十分可能である。

しかし、これは本質ではない。Target社に本当に必要だったのは、請求システムを守ることではなく、カード会員データというプロテクトサーフェスを、他のすべてから隔離することだった。ゼロトラストは「攻撃者がどこから来るか」を防ぐのではなく、「侵入されても、守るべきプロテクトサーフェスにだけは到達させない」という設計を取る。カード会員データのプロテクトサーフェスが正しく隔離されていれば、攻撃者がアタックサーフェスのどこから侵入しようと、それが空調業者だろうと、他の誰かだろうと、守るべきものには届かない。

トランザクションフローとして、この経路は存在したのか

もう一つ、重要な点がある。「業務上正当なトランザクションフロー」と「実際に存在してしまった経路」は別物であるということである。

Fazio社は、電子請求・契約管理のためだけにアクセス権を持っていた。したがって、カード会員データやPOSシステムとやり取りする業務上の理由は、そもそもない。つまり、もしTarget社がステップ2（トランザクションフローのマッピング）を正しく行っていたら、カード会員データへのフロー図に「空調業者の請求システム」が登場することは、ありえないはずだった。

ところが実際には、ネットワークが適切に分離されていなかったため、マッピング上は存在しないはずの経路が、物理的には通ってしまっていた。これは、ステップ4で説明した「フローにある流れは許可の候補、フローにない流れは原則拒否」という原則が機能していなかった、ということに他ならない。

もしステップ5（監視と保守）で定期的に「定義したフローと、実際に観測されるフロー」を突き合わせていれば、空調業者のセグメントからカード会員データ環境へ到達できる経路が実在すること自体が、「本来ないはずの抜け道」として検知できていたはずである。

図1：実際に起きたことと、ゼロトラストの5ステップが機能していた場合の対比（公開報道を基に作成）

5ステップに当てはめると

この事件を、本シリーズの5ステップに当てはめ直すと、失敗の構造がより明確になる。なお、NSTACの5ステップモデルは2022年に公表されたものであり、2013年の事件当時にTarget社がこの手順を実際に採用していた（あるいは特定の手順が欠けていた）という記録があるわけではない。以下は、起きた事実に、後からゼロトラストの枠組みを当てはめて整理した、筆者による分析である。

ステップ	この事件では
ステップ1：プロテクトサーフェスの定義	カード会員データという、守るべきプロテクトサーフェスは（おそらく）認識されていた
ステップ2：トランザクションフローのマッピング	そこへの正当なフローが厳密にマッピングされていなかった（あるいは、マッピングと実態が一致しているかの検証が甘かった）
ステップ3：アーキテクチャの構築	ネットワークが十分に分離されておらず、PEPに相当する「関所」がフローの境界に存在しなかった
ステップ4：ポリシーの作成	「フローにない通信は拒否する」というポリシーが、実効的に機能していなかった
ステップ5：監視と保守	定義したフローと実態の突き合わせが行われず、抜け道が長期間放置された

表1：Target社の事件を5ステップに当てはめた場合の失敗構造（筆者による整理）

つまりこの事件は、5ステップのどこか一つが欠けたら何が起きるかを、そのまま実証した事例だと言える。

まとめ

Target社の事件が教えてくれるのは、次の2点である。

• アタックサーフェスは、空調業者の請求システムのように、誰も予想しない場所まで含みうるほど広い。すべてを事前に守り切ることはできないと考える。
• だからこそ重要なのは、守るべきプロテクトサーフェスを正しく定義し、そこへの正当なフローだけを許可し、それ以外を遮断すること。攻撃者がどこから来るかではなく、どこにも到達させないことに焦点を当てるべきである。

これは、「ゼロトラスト実装の5ステップ」シリーズが第1回から第5回まで一貫して説いてきた考え方、つまり守る対象を定め、流れを可視化し、アーキテクチャで隔離し、ポリシーで許可を絞り、監視で継続的に確かめるというのが、机上の空論ではなく、現実の重大な事件の教訓そのものであることを示している。

以上