S6: セキュリティ
メンバー限定 — Practitioner 資格が必要。Addie と約 60 分。ハンズオンラボとアダプティブ試験を組み合わせます。
このモジュールは AdCP 固有のコントロール — エージェント型広告システムに固有の脅威モデル、層状防御、運用対応パターン — をカバーします。一般的なセキュリティプログラムの代替ではありません。認定スペシャリストは AdCP のコントロールがどう構成されるかについて推論できます; OWASP Top 10 や一般的なセキュリティエンジニアリングについては、組織のセキュリティトレーニングを参照してください。
このトラックが検証を準備する専門分野
以下のspecialisms はセキュリティドメインに該当します。それぞれ独自のコンプライアンスストーリーボードを持ちます — 完全な分類については コンプライアンスカタログ を参照。
あなたがデモンストレーションすること
- エージェント型広告の脅威モデルを説明: クレデンシャル窃盗、リプレイ攻撃、クロステナントデータ漏洩、アウトバウンドフェッチでの SSRF、なりすましエージェントアイデンティティ、不正なガバナンストークン使用、監査ログ改ざん
- AdCP の 5 層防御モデル — アイデンティティ、分離、冪等性、署名付きガバナンス、監査可能性 — をウォークスルーし、各層が閉じる特定の攻撃を名指す
- 冪等性キーを発行し、サンドボックスに対して 3 つの観測可能な結果を生成 — 成功する初回呼び出し、冪等リプレイ(
replayed: true、変更されないリソース)、ペイロード変更でのコンフリクト — し、4 番目について推論: TTL 期限切れ(サンドボックスのリプレイウィンドウは 24h なので、期限切れはセッション内で観測されるのではなく推論される)と、キーの欠如がセラーの安全性保証から何を取り除くか - 署名付きガバナンストークンを取得しデコードし、次にサンドボックス検証者を使ってチェックリストが有効なトークンを受け入れ、改ざんされたもの(署名)、誤アドレスのもの(
aud/ confused-deputy)、失効したキーで署名されたものを拒否するのを見る — 各失敗ステップが閉じる攻撃と、なぜ失効が期限切れより前にチェックされるかを説明 - アウトバウンドフェッチでの 6 点 SSRF チェック(HTTPS のみ強制、クラウドメタデータエンドポイントを含む予約 IP 拒否リスト、IP ピン検証、リダイレクト抑制、サイズとタイムアウトの上限、抑制されたエラー詳細)を指定し、エージェントがメタデータ IP webhook ターゲットを拒否するのをデモンストレーション
- クレデンシャル侵害、webhook シークレットローテーション、ガバナンスキー失効、当事者間インシデント通信をカバーする運用ランブックを設計
- インシデントの記述が与えられたら、どの防御層が失敗したか、どの特定のコントロールを強化するかを識別
S4(ガバナンス)は セラーの 視点から 15 ステップの JWS セラー検証をカバーします — セラーがバイヤーのガバナンスエージェントによって発行されたガバナンストークンをどう検証するか。S6 は セキュリティオペレーターの 視点からそれをカバーします — 自身のトークン発行実装が正しいことを検証し、各ステップが何を閉じるか推論する。重複は意図的です; フレーミングが異なります。
前提読書
セキュリティモデル
AdCP の 5 層防御モデル: アイデンティティ、分離、冪等性、署名付きガバナンス、監査可能性。
セキュリティ実装
実装リファレンス: 冪等性強制、webhook HMAC 検証、SSRF 規律、署名付きガバナンス、プリンシパル分離、インサートレート上限。
キャンペーンガバナンス仕様
ガバナンストークン構造、JWS 検証モデル、マルチパーティライフサイクル追跡の相関モデル。
エージェントの運用
運用の関心事としてのセキュリティ: クレデンシャル管理、ローテーション頻度、インシデント対応。
アカウントとセキュリティ
プリンシパル分離、アカウントスコープアクセス、マルチテナント分離。
認証
静的クレデンシャル強制、OAuth ディスカバリー、RFC 9728 オーディエンスバインディング、認証ベースライン専門分野。
テストエージェントへの接続
ラボ演習は公開テストエージェントに対して実行します。共有トークンを使います — サインアップ不要:ラボ演習
- 脅威モデルウォークスルー — 各脅威(クレデンシャル窃盗、リプレイ、クロステナント漏洩、SSRF、なりすましアイデンティティ、不正ガバナンス、監査改ざん)をそれを閉じる特定の AdCP コントロールにマップ。なぜ単一の層だけでは不十分かを説明。
- 冪等性ライフサイクル — ミューテーション呼び出し(例:
create_property_list)で 1 つの冪等性キーを使い: (a) 初回呼び出し — 成功を観測; (b) 同一リプレイ — 変更されないリソース id でreplayed: trueを観測し、新しい副作用がないことを確認; (c) 同じキー、異なるペイロード —IDEMPOTENCY_CONFLICTエラーを観測。次に 4 番目の結果 — リプレイウィンドウが経過した後の期限切れ(24h なのでセッション内で再現不可) — について推論し、冪等性キーの欠如がセラーの at-most-once 安全性保証にとって何を意味するか説明。 - ガバナンストークン検証 — サンドボックスガバナンスエージェントから署名付きガバナンストークンを取得(
sync_plans、次に intent フェーズのcheck_governance)し、そのヘッダー(alg、typ、kid)とクレーム(aud、sub、phase、jti、exp)をデコード。次にサンドボックス検証者(comply_test_controllerシナリオverify_governance_token)を実行し、JWS チェックリストがトークンを受け入れ拒否するのを見る: 有効なトークンはすべてのステップを通過; 改ざんされたクレームは署名ステップで失敗(governance_token_invalid); 異なるセラーにバインドされたトークンはaudバイトマッチで失敗(governance_token_not_applicable— confused deputy、mode: wrong_aud_demo経由); 失効したキーで署名されたトークンは失効ステップで失敗(governance_token_revoked、mode: revoked_demo経由)。それぞれについて、失敗ステップが閉じる攻撃を説明 — そして失効が期限切れの 前に チェックされるので、失効したトークンは経過していても拒否されることに注意。(jtiの既視重複排除 —audとは別 — が同じトークンのリプレイを止めるステップ。) - SSRF 防御 — URL がクラウドメタデータアドレス(
https://169.254.169.254/latest/meta-data/)をターゲットする webhooknotification_configをsync_accounts経由で登録; エージェントがnotification_configs[].urlのVALIDATION_ERRORで同期的にそれを拒否するのを観測し、受け入れられる公開ホストと対比。6 点 SSRF チェックを指定し、各点が何を閉じるか説明 — 予約 IP / メタデータ拒否リスト、接続時 IP ピン(DNS リバインディング)、リダイレクト抑制、抑制されたエラー詳細。 - プリンシパル分離 — リソースを作成したアカウントとは異なるアカウントに読み取りをスコープし、結果を正しく解釈: アカウントスコープの not-found を認可の 拒否 と区別。分離モデル — アカウントスコープアクセス — と、アカウントスコープトークンが強制されなかった場合に何が壊れるか(漏洩したトークンでのクロステナント読み書き)を説明。
- インシデントランブック設計 — クレデンシャル侵害シナリオ(API キーが公開リポジトリに漏洩)が与えられたら、対応を設計: どのキーをどの順序でローテーションするか、カウンターパーティにどう通知するか、どの監査イベントをレビューするか、侵害ウィンドウをどう検証するか。
- 防御層診断 — 3 つのインシデント記述(リプレイ攻撃成功、クロステナントデータ返却、キー失効後にガバナンストークン受け入れ)が与えられたら、各ケースでどの層が失敗したか、どの特定のコントロールを強化するかを識別。
評価
合格しきい値: 70%。