#security#api#devops#observability#automation
Stateful APIスキャンをCIと本番運用につなぐ方法
APIセキュリティは、エンドポイント単体検査から「状態遷移を追う検査」へ進んでいます。Statefulスキャンは強力ですが、導入の仕方を誤るとアラートが増えるだけで現場は動きません。
重要なのは、検査技術そのものよりも、CI・本番監視・責任分解を一体で設計することです。
Stateless検査の限界
従来型の検査は以下を見逃しがちです。
- 複数API呼び出しをまたぐ認可抜け
- ワークフロー順序の破壊（状態遷移バイパス）
- トークン更新や冪等制御周辺の競合窓
ビジネスロジック脆弱性は時系列依存なので、状態追跡が必須になります。
実装パターン: 2レーン運用
- CIレーン（事前検出）: プレビュー環境で境界付き検査
- 本番レーン（継続検出）: 低負荷・安全制約付きのStateful検査
CIで回帰を止め、本番で構成ドリフトと実運用差分を拾う構えです。
CIレーン設計
- 一時ID・テストデータを自動生成
- 主要シナリオ（登録、権限変更、決済、返金、管理操作）を定義
- ビルド失敗条件はポリシー重大度に限定
情報系アラートで毎回失敗させると、運用はすぐ形骸化します。
本番レーン設計
- カナリアテナント・合成アカウントを利用
- リクエストレートを制限し、検査元を識別可能にする
- スキャナ通信に専用タグを付けて観測系で追跡
- 高信頼の指摘はJira行きではなくインシデント導線へ接続
重大な検知を「後で対応」に落とす構造は危険です。
指摘の再現性を上げる相関情報
各検知には最低限、次を付与します。
- API呼び出しの時系列
- 実行主体（ロール・トークンスコープ）
- 状態遷移グラフ
- Trace ID（ログ・トレースへの接続）
これで「アラート」ではなく「再現可能な修正課題」になります。
責任分解とSLA
セキュリティ基盤チームが仕組みを提供し、各サービスチームが修正SLAを負う形にします。
- Critical: 24時間以内
- High: 72時間以内
- Medium: 次スプリント
- Low: 四半期レビュー
責任者不在のまま高度スキャナを入れると、ダッシュボードだけが増えます。
導入順序
- 重要5ワークフローから開始
- 精度・対応時間を計測
- シナリオを段階拡張
- 品質が安定してからCIゲートを強化
まとめ
Stateful APIスキャンは、導入すれば安全になる魔法ではありません。CIと本番の二層運用、観測可能性、責任契約を同時に設計して初めて、実効的な防御になります。
