セキュリティ15分で読める

HackerOne従業員287名のSSNが流出——サードパーティNaviaの侵害が連鎖

セキュリティデータ保護サイバー攻撃
加木谷 直俊ソース記事を見る

世界最大のバグバウンティプラットフォームHackerOneが、サードパーティの福利厚生管理会社Navia Benefit Solutionsの侵害を受け、従業員287名の社会保障番号（SSN）、保険情報、医療関連データが流出したことを公表した。Navia全体では約270万人のデータが影響を受けており、OWASP API Security Top 10で1位に挙げられるBOLA（Broken Object Level Authorization）脆弱性が悪用された。セキュリティ企業自身がサードパーティリスクの被害者になるという皮肉な事態は、サプライチェーン全体のセキュリティ管理の重要性を改めて浮き彫りにした。

事件の経緯

Navia Benefit Solutionsは、米国を拠点とする福利厚生管理（Benefits Administration）プラットフォームだ。企業がFSA（Flexible Spending Account）、HSA（Health Savings Account）、COBRA（退職後の保険継続）などの従業員福利厚生プログラムを管理するためのSaaSサービスを提供している。

HackerOneを含む数百社のテック企業が、従業員の福利厚生管理にNaviaを利用していた。Naviaのシステムには、従業員の以下のような機密情報が保管されていた。

  • 社会保障番号（SSN）: 米国の個人識別番号。ID窃盗の最重要ターゲット
  • 医療保険情報: 保険プラン、加入状況、扶養家族情報
  • 金融情報: FSA/HSAの口座情報、払い戻し履歴
  • 個人情報: 氏名、住所、生年月日、電話番号

侵害の発覚

2026年3月、Naviaはシステムへの不正アクセスを検知し、調査を開始した。フォレンジック調査の結果、攻撃者がAPI上のBOLA脆弱性を悪用して、認可チェックを回避し大量のユーザーデータにアクセスしていたことが判明した。

侵害の影響範囲は以下の通りだ。

項目詳細
侵害元Navia Benefit Solutions
影響人数約270万人（Navia全体）
HackerOne被害従業員287名
流出データSSN、保険情報、医療データ、個人情報
攻撃手法BOLA脆弱性の悪用
検知時期2026年3月
不正アクセス期間調査中（数週間〜数ヶ月の可能性）

BOLA脆弱性とは何か

BOLA（Broken Object Level Authorization）は、OWASP API Security Top 10で2023年版・2025年版ともに1位に位置づけられるAPI脆弱性だ。APIにおけるオブジェクトレベルの認可チェックが欠如している状態を指す。

以下の図は、BOLA脆弱性の仕組みを正常なアクセスと対比して示している。

BOLA脆弱性の仕組み：正常なアクセスではユーザーIDに基づく権限チェックが行われるが、BOLA脆弱性ではIDを変更するだけで他人のデータにアクセスできる

具体的な攻撃シナリオ

BOLAの本質は「自分のリクエストのIDを他人のIDに変更するだけで、他人のデータにアクセスできてしまう」というシンプルな問題だ。

例えば、福利厚生管理APIで以下のようなエンドポイントがあるとする。

GET /api/v1/employees/{employee_id}/benefits

正常な動作であれば、認証されたユーザーは自分の employee_id に対応するデータのみにアクセスできる。しかしBOLA脆弱性が存在する場合、employee_id を任意の値に変更するだけで、他の従業員のデータにアクセスできてしまう。

攻撃者は以下の手順でデータを大量に窃取する。

  1. 正規アカウントでログインし、自身の employee_id を特定
  2. IDを連番やUUID推測で変更しながらAPIを連続呼び出し
  3. 認可チェックが行われないため、全ユーザーのデータを取得可能
  4. 自動化スクリプトにより短時間で数百万件のデータを窃取

なぜBOLAは根絶できないのか

BOLAは概念的にはシンプルだが、以下の理由で根絶が困難だ。

  • テストの漏れ: 機能テストでは「正しいデータが返る」ことを確認するが、「他人のデータが返らない」ことの確認が漏れやすい
  • マイクロサービス化の影響: 認証と認可が別サービスに分離されている場合、認可ロジックの実装漏れが発生しやすい
  • 開発速度の優先: スタートアップ環境では認可チェックの実装よりも機能リリースが優先される
  • レガシーAPI: 古いAPIエンドポイントが認可チェックなしのまま残り続ける

サードパーティリスクの連鎖

以下の図は、サードパーティ侵害がどのように連鎖して被害が拡大するかを示している。

サードパーティ侵害の連鎖フロー：攻撃者がNaviaを侵害し、HackerOneを含む多数のクライアント企業のデータが流出する流れ

セキュリティ企業が被害者になる皮肉

HackerOneは世界最大のバグバウンティプラットフォームであり、企業のセキュリティ脆弱性を発見・報告するプラットフォームを運営している。そのHackerOne自身がサードパーティリスクの被害を受けたことは、以下の教訓を示している。

  1. 自社のセキュリティと取引先のセキュリティは別問題: いくら自社のセキュリティが堅牢でも、データを預けるサードパーティが侵害されれば意味がない
  2. 福利厚生・HR系SaaSは高リスク: SSN、医療情報、金融情報など最も機密性の高いデータを扱うが、セキュリティ投資が必ずしも十分ではない
  3. 侵害の連鎖は予測困難: 直接取引のない企業まで被害が波及する

過去のサードパーティ侵害事例との比較

事件年サードパーティ影響被害規模
Navia侵害2026Navia Benefit SolutionsHackerOne他数百社約270万人
MOVEit侵害2023Progress SoftwareShell, BBC他2,500社以上約6,000万人
SolarWinds侵害2020SolarWinds米政府機関、Microsoft他約18,000組織
Target侵害2013Fazio MechanicalTarget約1.1億人
Okta侵害2023Rightway HealthcareOkta全顧客約18,400人

サードパーティ侵害は年々規模が拡大しており、特にHR・福利厚生系プラットフォームは機密データの宝庫として攻撃者に狙われている。

被害者への対応

HackerOneは影響を受けた287名の従業員に対して以下の措置を講じた。

  • 個別通知: 流出したデータの種類を明記した書面を送付
  • クレジット監視サービス: 2年間のIDプロテクションサービス（Experian IdentityWorks）を無料提供
  • SSNの凍結支援: 信用凍結（Credit Freeze）の手続きサポート
  • 専用ホットライン: 被害者向けの問い合わせ窓口を設置

Navia側は、影響を受けた約270万人全員に対して同様の通知と監視サービスを提供するとしている。

サードパーティリスク管理のベストプラクティス

今回の事件を踏まえ、企業がサードパーティリスクを管理するための推奨事項を整理する。

ベンダー評価の強化

評価項目具体的なチェックポイント重要度
セキュリティ認証SOC 2 Type II、ISO 27001の取得状況必須
脆弱性管理定期的なペネトレーションテスト実施の有無必須
インシデント対応インシデント通知のSLA（72時間以内等）必須
データ暗号化保管時・転送時の暗号化方式必須
アクセス制御RBAC/ABACの実装、最小権限の原則高
サブプロセッサー再委託先の管理体制中

技術的対策

  • API Gateway/WAFでの異常検知: APIリクエストのレート制限、パターン異常検知を導入
  • データ最小化: サードパーティに提供するデータを必要最小限に制限
  • 暗号化・トークン化: SSN等の機密データはトークン化して提供し、生データを外部に保管させない
  • 継続的監視: サードパーティのセキュリティ態勢を定期的（四半期ごと）に再評価

契約・法務面の対策

  • データ処理契約（DPA）: GDPR Article 28準拠のDPAを締結
  • 侵害通知義務: 侵害検知後72時間以内の通知義務を契約に明記
  • 監査権: 年1回以上のセキュリティ監査実施権を確保
  • 責任制限: データ侵害時の損害賠償条項を明確化

日本への影響

個人情報保護法との関連

日本の個人情報保護法では、2022年の改正で委託先の監督義務が強化された。今回のNavia侵害のようなケースでは、以下の点が問題になる。

  1. 委託先選定時の適切な評価: 個人情報保護法第25条に基づき、委託先のセキュリティ体制を事前に評価する義務がある
  2. 委託先監督: 委託先が適切な安全管理措置を講じているかを継続的に監督する義務がある
  3. 再委託の管理: 委託先がさらに別の事業者に処理を再委託する場合、元の委託元にも管理責任が生じる

日本企業への教訓

日本企業も海外のHR・福利厚生SaaSを利用するケースが増えている。特に以下の点に注意が必要だ。

  • 海外SaaSへのマイナンバー提供: 外資系企業の日本法人が、グローバルHRシステムにマイナンバーを登録するケースがある。今回のような侵害でマイナンバーが流出するリスクを認識すべきだ
  • クラウドサービスのサプライチェーン: 利用しているSaaSがどのサブプロセッサー（再委託先）にデータを預けているか把握しているか
  • インシデント通知の遅延: 海外のサードパーティで発生した侵害の通知が日本の顧客に届くまでに数週間〜数ヶ月かかるケースがある

日本のサードパーティリスク管理の現状

経済産業省の「サイバーセキュリティ経営ガイドライン」では、サプライチェーン全体のセキュリティ管理を重視しているが、実態としては以下の課題がある。

  • 形式的なチェック: セキュリティチェックシートの形式的なやり取りで終わり、実質的な評価が行われていない
  • SOC 2レポートの未活用: 海外SaaSのSOC 2 Type IIレポートを取得しても、内容を読解・評価できる人材が不足
  • 継続的監視の欠如: 契約時の評価だけで、その後のセキュリティ態勢の変化を追跡していない

金融業界ではFISC（金融情報システムセンター）の安全対策基準で外部委託先管理が詳細に規定されているが、一般企業ではまだ体系的な管理フレームワークが普及していない。

BOLA対策のための技術実装

BOLA脆弱性を防ぐために、開発者が実装すべき対策を紹介する。

認可チェックの原則

# 疑似コード: BOLA対策の基本パターン
def get_employee_benefits(request, employee_id):
    # 1. 認証: ユーザーがログイン済みか確認
    current_user = authenticate(request)

    # 2. 認可: リクエストされたリソースへのアクセス権を確認
    if not authorize(current_user, employee_id):
        return 403 Forbidden

    # 3. データ取得: 認可チェック後にのみデータを返却
    return get_benefits(employee_id)

推奨される防御策

  • ポリシーエンジンの導入: Open Policy Agent（OPA）やCedar等の外部ポリシーエンジンで認可ロジックを一元管理
  • UUID v4の利用: 連番IDではなくランダムなUUIDを使用し、ID推測を困難にする（ただしこれだけでは不十分）
  • APIセキュリティテスト: OWASP ZAPやBurp SuiteでBOLAの自動テストを実施
  • レート制限: 同一ユーザーからの連続リクエストを制限し、大量データ窃取を防止

まとめ

HackerOne従業員データの流出は、セキュリティ企業であってもサードパーティリスクから完全には逃れられないことを証明した事件だ。BOLA脆弱性という基本的なAPI認可の欠陥が約270万人のデータ流出につながった。企業は以下のアクションを取るべきだ。

  1. サードパーティの棚卸しを実施する: 自社のデータを預けているすべてのサードパーティ（特にHR・福利厚生系）をリストアップし、各社のセキュリティ認証（SOC 2 Type II等）の取得状況を確認する。SSNやマイナンバー等の機密データを預けている先を優先的に評価する
  2. API認可チェックの総点検を行う: 自社が提供・利用するすべてのAPIについて、BOLA脆弱性の有無をテストする。OWASP ZAPやBurp Suiteを使った自動テストに加え、手動でのID変更テストも実施する。ポリシーエンジン（OPA等）の導入も検討する
  3. インシデント対応計画を更新する: サードパーティ侵害を想定したインシデント対応プレイブックを作成する。侵害通知を受けてから72時間以内に取るべきアクション（影響範囲の特定、被害者通知、クレジット監視の手配等）を事前に整理しておく

この記事をシェア

XはてブLinkedIn

「セキュリティ」カテゴリの記事

「セキュリティ」の記事をもっと見る

関連記事

新着記事