APIエコシステムの死角を突く「Shadow API」とデータ流出

背景と概要

モバイルアプリ、Webサービス、社内システム間のデータ連携において「API（Application Programming Interface）」は欠かせない存在です。しかし、社内のセキュリティ部門やIT部門の管理から漏れている「Shadow API（シャドーAPI）」や、過去の開発で放置された「Zombie API（ゾンビAPI）」が攻撃の標的となっています。

なぜAPIセキュリティ事故が増加しているのか

APIはデータベースと直接接続していることが多く、一度突破されると大量の個人情報や機密データが一括で持ち去られます。

1. 認証・認可の欠如（BOLA / BFOA）

　APIのエンドポイント（URL）に対して適切なアクセス制御が施されておらず、パラメータのID番号（例: `/api/user/1001` を `/1002` に変更）を書き換えるだけで他人のデータが閲覧できてしまう不具合（BOLA）が多発しています。

2. ドキュメント化されていない隠しAPIの放置

　テスト用・開発用に作成したAPIが認証なしでインターネット上に残っており、攻撃者の自動スキャンによって発見・悪用されます。

3. レート制限（Rate Limit）の不足

　短時間での大量リクエストに対する制限がないため、スクレイピングやブルートフォース攻撃によって一気に情報が抜き取られます。

API管理における必須対策

すべてのAPIを可視化し、一元管理する体制を築く必要があります。

1. APIゲートウェイを通じた統一管理

　外部・内部通信のすべてのAPIリクエストをAPIゲートウェイ経由とし、認証・認可・レート制限を一元的に適用します。

2. 自動API探索ツールの活用

　ネットワークトラフィックを解析し、管理下にないShadow APIを自動検知してリスト化します。

3. OWASP API Security Top 10に基づくセキュア設計

　開発ガイドラインにAPI固有の脆弱性対策（特にBOLA対策）を盛り込み、リリース前のコード監査を徹底します。

実務で深掘りしたい確認点

仕様書にないAPI、旧バージョン、テスト用エンドポイント、公開されたスキーマをひとまとまりの管理対象として捉えます。ゲートウェイを通らない通信、認証のない応答、利用者不明のAPIを資産探索で見つけます。 単発の警告だけで判断せず、利用者・端末・時刻・変更履歴を関連付けると、通常業務との違いを説明しやすくなります。

発見時の初動と影響確認

外部公開を制限し、利用元を特定して移行期間を設け、廃止前に依存関係を確認します。 復旧を急ぐ場合も、後から原因と影響範囲を説明できるよう、時刻、担当者、実施した操作、保全した証拠を残します。外部への通知や専門家への相談が必要かも、扱うデータと業務影響から判断します。

継続運用へ落とし込む方法

API台帳、所有者、データ分類、廃止日をCI/CDと連携して自動更新します。 導入時だけで終わらせず、例外件数、検知から対応までの時間、再発、利用者からの相談を定期的に確認します。訓練や実際の対応で見つかった手順の曖昧さを更新し、責任者不在時にも動ける状態を維持します。