Claude apps gatewayの脅威モデルとコンプライアンス対応
Claude apps gatewayが何から開発者を守り、何を運用側の責任として切り離しているかを、脅威モデルとコンプライアンス質問票の観点でまとめます。
Claude apps gatewayが守る境界とはどこか
Claude apps gatewayは、Claude Codeとモデルプロバイダーの間に置くセルフホスト型のゲートウェイです。組織のネットワーク内側に配置しますが、そこに接続してくる開発者のノートPCそのものは信頼しません。短命なJWT・PKCE・SSRFガードの3点で、ラップトップが乗っ取られた場合の被害範囲を絞り込む設計です。
一方で、ゲートウェイのホスト自体が乗っ取られるケースと、悪意あるOIDCプロバイダーは設計の対象外です。この2点は公式ドキュメントが明示的に「運用側が守るインフラ」と線引きしています。守備範囲と非対象を分けて把握しておくと、セキュリティレビューで聞かれる質問にその場で答えられます。
5種類のデータがどこへ流れるか
脅威モデルを読む前に、そもそも何がどこへ流れるかを押さえておくと理解が早くなります。公式ドキュメントは5種類のデータについて経路を明示しています。
| データ | 経路 | Anthropicへの送信 |
|---|---|---|
| 推論(プロンプト・応答) | 経路CLI→ゲートウェイ→上流 | Anthropicへの送信Anthropic APIを上流に設定している場合のみ |
| テレメトリ(OTLPメトリクス、任意でログ・トレース) | 経路CLI→ゲートウェイ→自社のコレクター | Anthropicへの送信されない |
| ID情報(メール・グループ・sub) | 経路IdP→ゲートウェイ→JWT→CLI | Anthropicへの送信されない(forward_user_identityを有効にすると自社プロキシへは送られる) |
| managed settings | 経路自社のgateway.yaml→CLI | Anthropicへの送信されない |
| 監査ログ | 経路ゲートウェイのstderr→自社の集約先 | Anthropicへの送信されない |
ID情報の行だけは条件付きです。ゲートウェイはIdPから受け取ったメール・グループ・subをJWTに載せてCLIへ渡すだけですが、forward_user_identityを有効にすると、開発者のメールとIdPのsubを追加ヘッダーとして自社プロキシにも送るようになります。送信先はあくまで運用者自身が指定したプロキシで、Anthropicではありません。
推論以外の4種類はいずれもAnthropicに届かない設計です。Anthropicに何かが送られるのはAnthropic APIを上流に選んだときの推論トラフィックだけで、それ以外の運用データは組織の外に出ません。この非対称性が、後続の脅威モデルとコンプライアンス対応の前提になっています。
短命JWTとPKCEでラップトップの侵害を無力化する
開発者はAPIキーやクラウド認証情報を持たず、ゲートウェイが発行する短命なベアラートークンだけを保持します。CLIとゲートウェイの間はRFC 8628のデバイスグラントで結ばれ、ゲートウェイとIdPの間の認可コード交換は既定でPKCEを使います。認可コードを途中で盗聴されても再利用できません。
デバイス確認ページ(/device)は同一オリジンのPOSTだけを受け付け、RFC 8628 §5.1に沿ったIP単位のレート制限もかかります。この制限は後述のuser_code総当たり耐性と対になっています。
SSRFガードがブロックする宛先、許可する宛先
ゲートウェイの発信リクエストは、DNS解決からTCP接続までを一貫してチェックするSSRFガードを通ります。IdPやOTLPコレクターのURLを運用者が自由に設定できる以上、そのURLがクラウドのメタデータエンドポイントへリダイレクトされない保証が必要だからです。
| 宛先の種類 | 既定の扱い | 理由 |
|---|---|---|
| リンクローカルアドレス | 既定の扱いブロック | 理由クラウドメタデータへの誘導を防ぐ |
| クラウドメタデータアドレス | 既定の扱いブロック | 理由認証情報の窃取経路になるため |
ループバック(localhost等) | 既定の扱いブロック | 理由誤って内部サービスへ到達するのを防ぐ |
| RFC 1918プライベートレンジ | 既定の扱い許可 | 理由IdPやOTLPコレクターが社内網に置かれるのが通常のため |
ループバック上のコレクターにどうしても到達させたい場合だけ、ゲートウェイの環境変数で例外を開けます。
export CLAUDE_GATEWAY_ALLOW_LOOPBACK=1この変数は運用者が設定したすべてのURLに対してループバック制限を緩め、起動時に行うクラウドメタデータ到達性チェックも同時にスキップします。ローカル開発用のIdPやサイドカーのOTLPコレクターのように、正当な理由がある場合だけ設定し、恒常的な運用ではコレクターに社内網の固有アドレスを持たせる方が安全です。自前の外向き通信制御(egress)を追加する場合は、ワークロードIDのようなインスタンスメタデータ資格情報を使う限り、ゲートウェイがメタデータサーバーへ到達できる経路を残す必要があります。
user_codeが総当たりされない理由
デバイス確認ページに入力するuser_codeは、20文字のアルファベットから選ぶ8文字です。組み合わせは20の8乗、約256億通りになり、10分で失効します。
数字の組み合わせと失効時間だけでも十分な耐性ですが、レート制限が重なることで、正規のサインインフローを妨げずに総当たりの試行回数を実質ゼロに近づけています。この制限はあくまでサインイン画面向けで、サインイン後の推論リクエストには別枠のレート制御が必要になる点も覚えておくとよいでしょう。
ゲートウェイの設計が守らない2つの脅威
脅威モデルが明示的に対象外としているのは次の2つです。どちらも「ゲートウェイの設計」ではなく「運用側のインフラ」として守る領域です。
この線引きを理解しておくと、「ゲートウェイを導入すればIdPの管理がおろそかでよい」という誤解を避けられます。ゲートウェイが強いのは通信経路の設計であって、配布元そのものの信頼性を作り出すわけではありません。
ホスト侵害を「対象外」としつつ実害を限定する承認ダイアログ
ゲートウェイホストの侵害が設計の対象外だとしても、そこから配られるmanaged settingsが開発者のマシンで無条件に効くわけではありません。次の項目が届くと、CLIは適用前に開発者へ承認ダイアログを出します。
- フック(
hooks) - プロキシやベースURLなど、承認を要する
env変数 apiKeyHelperやstatusLineのようなシェル実行系の設定sandbox.bwrapPath等、サンドボックスのバイナリ指定- 通信を横取りする
sandbox.network.tlsTerminate等、サンドボックスの隔離を弱める設定
開発者が承認しなければ、CLIはそのポリシーを適用せずセッションを終了します。侵害されたホストが不正な設定を配っても、開発者の目に触れずに実行される経路ではない、という点が実害の上限を作っています。ただし非対話の-p実行はこのダイアログを表示できないため、その回の実行にだけ設定が適用され、承認済みとしては記録されません。
立場によって変わる読み方
同じ脅威モデルでも、誰が読むかによって効いてくる箇所が違います。
| 立場 | この設計が変えること |
|---|---|
| 開発者 | この設計が変えること資格情報を自分で持たなくなる代わり、ゲートウェイに10秒以内で到達できないとセッションが起動しない |
| ゲートウェイ運用者 | この設計が変えることホストへの侵害はMDMを乗っ取られるのと同じ重大度になる。ホストへのアクセス統制をIdP側の統制以上に厳格にする理由はここにある |
| セキュリティレビュー担当 | この設計が変えること質問票の大半は次の対応表でそのまま埋まるが、ホスト侵害の検知は自社の監視設計に委ねられたままになる |
コンプライアンス質問票にどう答えるか
セキュリティレビューやコンプライアンス質問票で聞かれる項目は、公式ドキュメントの「Compliance posture」節にほぼそのまま対応します。
| 質問される観点 | 回答の要点 |
|---|---|
| データレジデンシー | 回答の要点Anthropic APIを上流に設定していない限り、ゲートウェイのデータプレーンはAnthropicに何も送らない。テレメトリ・監査・ID・設定は運用者が指定した宛先だけに届く |
| ホストプロセスの通信 | 回答の要点ホストプロセスはClaude Code CLI自体で、Anthropicへは何も送らない。v2.1.227より前はバージョン等の起動テレメトリを送っており、コンテナ環境でCLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1を設定すると止められた |
| クライアント側の分析 | 回答の要点ゲートウェイへのサインイン中はCLI自身の利用状況分析とエラー報告が無効になる。初回サインイン前のスタートアップイベントを止めるには、クライアント側managed settingsでDISABLE_TELEMETRYを配布する |
| エラー報告 | 回答の要点モデルリクエストの送信先がAnthropicの一次APIでなくAmazon Bedrock等の場合、CLIはエラー報告そのものを常に無効にする |
| クライアント端末の残存通信 | 回答の要点CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFICとskipWebFetchPreflight: trueの両方を設定しない限り、開発者のCLIはWebFetchのホスト名チェックとバージョンチェックをAnthropicへ送り続ける |
| クライアント更新 | 回答の要点更新チェックはゲートウェイ通信とは別経路。自社配布でバージョンを固定するならDISABLE_UPDATESを、バックグラウンド更新だけ止めるならDISABLE_AUTOUPDATERを使う |
| TLS | 回答の要点public_urlは本番でHTTPS必須。IdPも本番ではHTTPS必須で、Postgresは?sslmode=requireに対応 |
| 脆弱性の報告 | 回答の要点公式の脆弱性報告フローに従う |
この表を眺めると、ほとんどの項目が「既定でオフ、必要な通信だけ明示的にオンにする」という同じ方針の繰り返しだと分かります。個々のトグルを覚えるより、この方針を先に理解しておくほうが、新しい質問が来たときにも自分で答えを導けます。
TLSについては表に収まらない補足が2つあります。まずlisten.public_urlは、ゲートウェイ自身のリスナーでTLSを終端する場合と、手前にTLS終端するingress(TLS証明書を終端してから内部へ転送するプロキシ)を置く場合のどちらでも設定が必要で、ingress側ではStrict-Transport-Securityヘッダーも別途設定しておく必要があります。もう1つは、ゲートウェイ自身は平文HTTPの接続を拒否しない設計だという点です。「HTTPS必須」は運用者がpublic_urlをhttps://で設定し、ingressやリスナー側でTLSを終端することで初めて成立する話であり、ゲートウェイが平文アクセスを自動的に弾いてくれるわけではありません。
サインイン後のトランスクリプト共有についても触れておく価値があります。サーベイのプロンプトで転写共有に同意しても、Anthropicへはアップロードされず、~/.claude/feedback-bundles/配下にローカルファイルとして書き出されるだけです。
監査担当がまず見る対象は配布経路の設計
このセキュリティ設計が前提にしているのは、ゲートウェイを「信頼された配布点」として扱う考え方です。managed settingsを配布する経路そのものが攻撃対象になり得るという想定に立ち、JWTの短命化・PKCE・SSRFガードのすべてが「配布経路の途中を守る」方向に寄っています。
裏を返せば、配布点そのもの(ゲートウェイホストとIdP)の健全性は、この設計が保証してくれる範囲の外にあります。安心してよいのは経路の途中だけで、両端の管理は依然として組織の責任です。
まとめ
Claude apps gatewayの脅威モデルは、ラップトップの侵害を前提に置いた経路防御と、ホスト・IdPという両端を運用責任に切り分ける設計でできています。データフロー・SSRFガード・承認ダイアログはいずれも「途中経路を守る」という同じ方針の別の現れで、両端の健全性まで肩代わりしてくれるわけではありません。導入時の実装手順はClaude apps gatewayの使い方、gateway.yamlの全項目は設定リファレンス、デプロイと運用の流れはデプロイと運用ガイドで確認できます。ゲートウェイ経由のセッションでRemote Controlが使えなくなる点も、資格情報をゲートウェイ側に一本化する同じ設計思想の延長線上にあります。