ファッション大手ZARAを擁するInditexグループのデータベースに不正アクセスが発生し、19万7,400人分の個人情報が流出したことが、Have I Been Pwned（HIBP）の分析により明らかになった。今回の侵害を引き起こしたのはZARA自身のシステムではなく、かつて連携していた外部技術プロバイダーだ。「自社は万全」という安心感の裏側に巨大なリスクが潜んでいたこのケースは、日本企業にとっても決して対岸の火事ではない。

何が起きたのか

HIBPの分析によると、流出データには以下が含まれる。

  • ユニークなメールアドレス（197,400件）
  • 購入履歴・注文ID・商品SKU
  • 地理的ロケーション情報
  • サポートチケット内容（問い合わせ元マーケット含む）

Inditexは「氏名・電話番号・住所・認証情報・支払い情報（クレジットカード等）は含まれていない」と説明しており、顧客の直接的な金銭被害や不正ログインリスクは限定的とみられる。ただしメールアドレスと購入履歴・サポート履歴の組み合わせは、標的型フィッシングやソーシャルエンジニアリングの材料として十分すぎる情報量だ。

攻撃の手口：Anodot認証トークンの悪用

今回の攻撃で注目すべきは侵入経路だ。犯行グループ「ShinyHunters」は、クラウドデータ監視サービスAnodotの認証トークンを不正取得し、そこからBigQueryインスタンスにアクセスして140GBのアーカイブを窃取したと主張している。

Anodotのようなデータ分析・監視ツールは、BigQueryやSnowflake、Redshiftといったデータウェアハウスと幅広く連携するため、サービスアカウントに強力な読み取り権限が付与されていることが多い。この「機械のアカウント（Non-Human Identity / NHI）」が長期間にわたって有効な認証情報を保持し続けることが、攻撃者に格好の標的を提供している。

ShinyHuntersはこの手法で数十社のデータを窃取したと述べており、Microsoft Entra・Okta・Google SSOを標的にしたビッシング（音声フィッシング）キャンペーンとの関連も指摘されている。Salesforce、Microsoft 365、Google Workspace、Slack、Zendesk、Dropboxなど、多くのSaaSサービスが連鎖的に標的にされている点は見逃せない。

「委託先リスク」という本質的な問題

Inditexが強調するように、Inditex自身のシステムは侵害されていない。しかし過去に連携していたベンダーが保持していたデータが盗まれた。これがいわゆる「サードパーティ・サプライチェーン攻撃」の典型だ。

日本企業でも同様のリスクは広く存在する。

  • SaaSツールに付与したサービスアカウント・APIキーの棚卸しが未実施
  • 契約終了後もアクセス権限が残存するベンダーアカウント
  • 監視ツール・分析ツールへの過剰な権限付与
  • 「いつ誰が作ったかわからないトークン」の長期放置

認証情報には有効期限がないものも多く、適切にローテーション・失効処理しなければ、何年も経ってから攻撃のエントリポイントになりうる。

実務への影響：NHI管理と最小権限の徹底

今回の事例から、エンジニアやIT管理者が直ちに着手すべきポイントを整理する。

1. NHIの棚卸し

サービスアカウント、APIキー、OAuthトークン、クラウドIAMロールをすべて一覧化する。特に「誰が作成したか不明なトークン」は最優先で精査する。

2. 最小権限原則の適用

データ分析・監視ツールへのアクセス権は読み取り専用に限定し、BigQueryのデータセットレベルで権限を絞る。不要なリソースへのアクセスは即時削除する。

3. 認証情報のローテーションと有効期限設定

長寿命なAPIキーを廃止し、OAuth 2.0のアクセストークンのような短期トークンに切り替える。Just-In-Time（JIT）アクセスモデルの採用も有力な選択肢だ。

4. ベンダー契約終了時のアクセス権限失効プロセスの確立

委託終了後に認証情報が残存しないよう、オフボーディング手順を文書化・自動化する。「取引終了＝即時アクセス権剥奪」が原則であるべきだ。

5. サプライチェーン全体のセキュリティ評価

主要ベンダーへのSOC 2レポート要求やセキュリティアンケート実施を定期化し、委託先のセキュリティ体制を継続的に評価する。

筆者の見解

今回のZARA侵害が示すのは、「自社のセキュリティ」だけを固めても意味がないという厳しい現実だ。Inditexはおそらく自社インフラのセキュリティに多大な投資をしていたはずだ。しかし、過去に連携していたベンダーに残存していた認証情報が、侵害のエントリポイントになった。

NHI管理は地味なタスクだが、実は業務自動化の根幹でもある。サービスアカウントやAPIトークンの管理が甘ければ、自動化推進のボトルネックになるだけでなく、セキュリティホールにもなる。「常時アクセス権の付与はリスク」という原則は、人間のアカウントだけでなく機械のアカウントにも等しく適用されなければならない。

ゼロトラストを本当に実現するには、人のIDだけでなく「アクセスするすべてのもの」をID管理の対象にする必要がある。ShinyHuntersが今回利用した手法は、まさにその盲点を正確に突いている。残念ながら多くの日本企業でも、機械アカウントの管理は後回しにされているのが現状ではないか。今回のZARAの事例を、自社のNHI棚卸しを始めるきっかけにしてほしい。

出典: この記事は Zara data breach exposed personal information of 197,000 people の内容をもとに、筆者の見解を加えて独自に執筆したものです。