【大情報漏洩時代】なぜゼロトラストは個人情報を守れなかったのか

2026-10-11 最終更新日時 : 2026-10-11 administrator

「正規IDだから仕方がない」を終わらせる、アプリ的ゼロトラストへの転換

エグゼクティブサマリー

2026年の大規模な個人情報漏えいは、最新の防御が破られたというより、防御が届いていない場所を突かれた結果である。多くの企業がゼロトラスト製品を導入したが、その範囲は社員のリモートアクセスとID認証にとどまり、個人情報に触れるアプリとデータの層は手つかずだった。

「正規のIDが盗まれたから仕方がない」という説明は、ゼロトラストの表面的な理解にすぎない。ゼロトラストの本質は、正規のIDであっても「正規らしい使い方をしているか」を継続的に検証することにある。

本レポートの主張は次の3点である。

  • 個人情報・機密情報を扱うアプリには、閲覧件数の上限、異常時の自動遮断などを備えた「アプリ的ゼロトラスト」が不可欠である。
  • その実装責任は、インフラ部門ではなくデータとアプリのオーナーが負うべきである。
  • ベンダーは製品販売で終わらず、導入した製品が実際に機能することに成果責任を持つべきである。業界は侵入経路を共有する仕組みを制度化すべきである。

現状認識：過去最悪のペースと、検証されない「AIのせい」

2026年の上場企業とその子会社による100万件以上の漏えいは、10月5日時点で10件に達し、2025年通年の6件をすでに上回った（東京商工リサーチ調査）。1000万件以上の事故も3件起きている。10月上旬だけでも、大和証券（委託先）、第一ライフ、佐川急便、旭化成セラピューティクス、大起水産などの公表が続いた（NHK）。

セキュリティ会社は7月以降の被害増加を受けて、攻撃にAIが悪用されている可能性が高いと指摘している（NHK）。海外では、AIによる自律的な侵入ツールの痕跡が見つかった韓国の銀行への攻撃も報告されている（Rescana）。

一方で、9月1日〜10月6日に国内で公表された112件のうち、AI悪用が開示された事例はゼロだったという分析がある（SmartScope）。公表内容だけでは、AIの関与を判断できないということだ。

「AIによる攻撃」という説明は、もっともらしいが検証されていない。被害企業の多くは侵入経路や技術的な課題を明らかにしておらず、他社が教訓を得る手段もない。この開示の欠如そのものが、第二・第三の被害を生む構造的な要因になっている。

既存の対策はなぜ機能しなかったのか

既存の対策は、それぞれが想定した脅威には効いている。問題は、攻撃者がその想定の外側を通っていることだ。2026年の公表事例では、SaaS連携アプリの設定不備、Salesforceのguest user設定不備、境界機器の既知の脆弱性、委託先経由の侵入、Okta利用者を狙った電話での認証突破（ビッシング）が目立つ（Rocket Boys 事例一覧、同 まとめ資料）。

対策想定している脅威すり抜けられる理由本来必要だった制御
ファイアウォール / WAF不審な通信、既知の攻撃パターン正規の認証情報とAPIを使う攻撃は「正常な通信」に見える。VPN装置など境界機器そのものが侵入口になる境界機器の迅速なパッチ適用と、通信の中身ではなく振る舞いの監視
ネットワーク上のアクセス制御社内ネットワークでの横移動Webアプリのサービスアカウントが会員DBを全件読める設計が一般的で、アプリを乗っ取られれば全件に届くアプリ→DBの経路での最小権限と行レベルセキュリティ
多要素認証（MFA）パスワードの漏えいフィッシングによるセッショントークンの窃取、ヘルプデスクへのなりすましでのリセット、MFA対象外のAPI・サービスアカウントフィッシング耐性のある認証、例外アカウントの棚卸し、ITDR
保存時の暗号化ディスクやバックアップの盗難DBの透過的暗号化は、正規のアプリからは平文で読める項目単位の暗号化、トークン化
DLP社員による持ち出し誤検知を嫌って監視モードで運用。暗号化通信やSaaS API経由の持ち出しを検知しにくい遮断モードでの運用と、データ参照量そのものの監視

すべての対策に共通する盲点は、「正規のIDによる、正規の経路を使った、大量のデータ参照」である。この盲点を埋めるのがゼロトラストだったはずだ。

ゼロトラストは何だったのか：製品導入と実現の乖離

国内の多くのゼロトラスト導入は、VPNをZTNAやSASEに置き換えるリモートアクセス刷新にとどまった。マイクロセグメンテーション、サービスアカウントの最小権限、データ中心の制御、ID脅威の検知・対応（ITDR）まで踏み込んだ例は少ない。

さらに、今回狙われているのは顧客向けWebサービス、SaaS、委託先が中心である。社員の業務アクセスを守るために買ったゼロトラスト製品の守備範囲の外だ。

防御の4層と、ゼロトラスト投資の範囲・漏えいの到達点

投資は上の2層に集中し、個人情報が実際に抜かれたアプリとデータの層には制御が及んでいない。

NIST SP 800-207は、アクセス判断をログイン時の一回きりではなく、振る舞いや文脈に基づいて継続的に行うことを求めている。「誰が、どのアプリで、どのデータに、どれだけ」アクセスしてよいかが制御されていなければ、それは境界防御と変わらない。認証の関門が一つ増えただけの「ゼロトラスト製品を置いた境界防御」である。

ベンダーはゼロトラスト製品を売り、社内エンジニアは「ゼロトラスト化のため」として稟議を通した。製品の導入をゼロトラストの実現と同一視してきたことが、いま説明責任として問われている。

市場はこの状況を需要の拡大として評価している。2026年8月後半〜9月初めに発表されたCrowdStrike、Okta、Palo Alto Networksなどの決算はいずれも市場予想を上回り、AI導入に伴う顧客のセキュリティ投資増が追い風とされた（ピクテ）。被害が増えるほど売上が伸びる構造は、ベンダーの信頼を問う論点でもある。

提言：個人情報を扱うアプリに「アプリ的ゼロトラスト」を

ネットワークとIDの層で守り切れない以上、最後の砦はデータに触れるアプリそのものである。個人情報・機密情報を扱うアプリは、侵入される前提で設計し直す必要がある。

実装すべき制御

制御内容止められる攻撃
ID・セッション単位の閲覧上限時間あたりの参照件数、一括出力件数に上限を設け、超えたらロックまたはアラート正規IDを使った大量抜き取り
ステップアップ認証大量出力や条件なしの全件抽出に、追加承認や再認証を要求乗っ取られたセッションでの一括取得
行レベルセキュリティアプリのサービスアカウントに全件を見せず、利用者の権限範囲の行だけを返すアプリ侵害からのDB全件取得
APIゲートウェイのクォータとDB監査平常時の参照量からの逸脱を検知API経由の持ち出し
振る舞い分析（UEBA）と累積判定IDごとの平常パターンと比較し、長期間の累積量でも判定閾値を下回るペースで少しずつ抜く攻撃
ハニートークン実在しない会員データを仕込み、参照されたら即アラート気づかれない全件探索

AIを使う攻撃者は、固定の閾値を下回るペースで少しずつ抜く「low and slow」型に最適化しやすい。固定の件数上限だけでなく、振る舞い分析と累積判定を組み合わせることが重要である。

進め方

  • データ分類：個人情報・機密情報がどのDBやSaaSにあるかを洗い出す。
  • アプリの棚卸し：そのデータに触れるアプリ、API、サービスアカウント、委託先の接続をすべて特定する。漏えいの多くは、ここで見落とされた連携アプリや委託先から起きている。
  • 制御の実装：4.1の制御を、データの重要度に応じて段階的に導入する。
  • 監視と対応：アラートを誰が受け、何分以内にアカウントを止めるかまで決める。
  • 責任者の明確化：インフラ部門ではなく、データとアプリのオーナーに責任を持たせる。

なぜ普及しないのか

障壁は技術より組織にある。対策がアプリ設計の領域にあるため、インフラ部門が買うゼロトラスト製品の範囲外になり、アプリ側では誰も責任を持たない。夜間バッチなど正規の大量処理との区別が難しく、誤検知で業務が止まるのを嫌って閾値が緩められる。レガシーアプリは改修コストが大きく後回しにされる。

解決策は、新規開発やSaaS選定の要件定義に「ID単位の参照量制御」と「異常時の自動遮断」を必須項目として入れることである。製品を買うのではなく、設計要件として組み込む。

規格との関係

NIST SP 800-171の最小権限（3.1.5）、監査ログ（3.3系）、異常の検知（3.14系）は、アプリ層まで適用して初めて実質的な意味を持つ。CMMC Level 2の評価でも、ネットワーク制御だけでなくアプリのアクセス制御まで確認するかどうかで、実効性に大きな差が出る。

ベンダーと業界への提言：モノ売りから成果責任へ

「モノからコトへ」の転換が叫ばれて久しい。製品を売って「あとはよろしく」では、ソリューション企業としての信頼を失う。被害が世界的な問題になった今こそ、ベンダーは提供してきた製品の性能を最大化することに、一定の無償支援も含めて取り組む姿勢を示すべきである。

ただし、善意だけに頼るのは現実的ではない。顧客側は、成果責任を契約に組み込むべきである。

  • 導入後の設定成熟度（ポリシーの適用率、例外アカウント数、MFA対象外のIDの数など）をSLAや保守契約の評価項目にする。
  • 定期的な構成診断を保守費の範囲で実施させ、結果を経営層に報告させる。
  • 「導入完了」ではなく「制御が機能していることの検証」を検収条件にする。

侵入経路の共有を制度化する

侵入経路が開示されない背景には、攻撃者に手口を教えるリスクと訴訟リスクがある。タイムズカーの漏えいでは、集団訴訟の登録者が1万人を超えた（NHK）。

公開の詳細開示を一律に求めるより、次の2つが実効性が高い。

  • 免責付きの技術調査機関：航空事故調査（NTSB）のように、責任追及と切り離して原因を調査し、教訓を公表する。
  • ISAC経由のクローズドな共有：業界内で侵入経路と技術的課題を速やかに共有し、同じ手口による被害の連鎖を止める。

独立した検証の役割

「導入したゼロトラストが実際に機能しているか」を、製品を売る立場にない第三者が検証する役割は、現在ほぼ空白である。ベンダーは自社製品の不備を指摘しにくく、社内エンジニアは自ら通した稟議の成果を否定しにくい。利害から独立した評価が、この構造的な死角を埋める。

結び

ゼロトラストは製品の名前ではなく、設計の原則である。「正規のIDだから止められなかった」という説明が通用する限り、同じ手口の被害は繰り返される。

問うべきは「ゼロトラスト製品を導入したか」ではない。「個人情報に触れるすべてのアプリで、正規のIDによる異常な参照を検知し、止められるか」である。この問いに答えられる企業だけが、ゼロトラストを実現したと言える。

株式会社ブラインドフォースは、特定ベンダーに依存しない立場から、ゼロトラストの実効性評価とアプリ層の制御設計を支援する。

出典

NIST SP 800-207 Zero Trust Architecture／NIST SP 800-171 Rev.2

カテゴリー
REPORT
SaaSの死の意味――「利用期間」に払うのをやめ、「生み出した価値」に払う時代へ
【大情報漏洩時代】責任と救済をどう設計するか