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。CLIはOTLPの出力にも付与する | 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を使います。認可コードを途中で盗聴されても、PKCEがあるので再利用できません。
デバイス確認ページ(/device)は同一オリジンのPOSTだけを受け付け、RFC 8628 §5.1に沿ったIP単位のレート制限もかかります。この制限は後述のuser_code総当たり耐性と対になっています。
SSRFガードがブロックする宛先、許可する宛先
IdP・OTLPコレクター・provider: anthropicの上流へのリクエストは、SSRFガードを通ります。DNSを解決し、解決したIPに接続を固定してから通信する仕組みです。運用者が設定するURLがクラウドのメタデータエンドポイントへ誘導されないための備えです。
| 宛先の種類 | 既定の扱い | 理由 |
|---|---|---|
| リンクローカルアドレス | 既定の扱いブロック | 理由クラウドメタデータへの誘導を防ぐ |
| クラウドメタデータアドレス | 既定の扱いブロック | 理由メタデータへの誘導を防ぐ |
ループバック(localhost等) | 既定の扱いブロック | 理由同じホスト上の内部サービスへ向かわせない |
| RFC 1918プライベートレンジ | 既定の扱い許可 | 理由IdPやOTLPコレクターが社内網に置かれるのが通常のため |
ガードの射程はprovider: anthropicまでです。それ以外のプロバイダーでは、設定の読み込み時にbase_urlがこれらのアドレスやメタデータのホスト名を指していれば拒否します。接続自体はプロバイダーのSDKが行うため、DNSのチェックは入りません。プロキシ専用のegressを有効にすると、アドレスの検査は手前のフォワードプロキシへ移ります。ゲートウェイはホスト名だけを渡すので、プロキシ側の許可リストでこれらの宛先を拒否しておく必要があります。
ループバック上のコレクターにどうしても到達させたい場合だけ、ゲートウェイの環境変数で例外を開けます。
export CLAUDE_GATEWAY_ALLOW_LOOPBACK=1この変数は運用者が設定したすべてのURLに対してループバック制限を緩め、起動時に出すクラウドメタデータ到達性の警告も同時にスキップします。ローカル開発用のIdPやサイドカーのOTLPコレクターのように、正当な理由がある場合だけ設定し、恒常的な運用ではコレクターに社内網の固有アドレスを持たせる方が安全です。自前の外向き通信制御(egress)を追加する場合は、ワークロードIDのようなインスタンスメタデータ資格情報を使う限り、ゲートウェイがメタデータサーバーへ到達できる経路を残す必要があります。
user_codeが総当たりされない理由
デバイス確認ページに入力するuser_codeは、20文字のアルファベットから選ぶ8文字です。
user_codeの総当たり耐性
文字数
8文字
20文字のアルファベットから選ぶ
組み合わせ
約256億通り
20の8乗
有効期間
10分
過ぎると失効する
組み合わせ数と10分の失効に、IP単位のレート制限が重なることで、正規のサインインを妨げずに総当たりを現実的でなくしています。
ゲートウェイの設計が守らない2つの脅威
脅威モデルが明示的に対象外としているのは次の2つです。どちらも「ゲートウェイの設計」ではなく「運用側のインフラ」として守る領域です。
設計が守る範囲と運用側の責任
設計が守る
短命なJWT、PKCE、SSRFガード、/deviceのレート制限。開発者のノートPCが乗っ取られても、上流の資格情報は手元にありません。
運用側が守る
ゲートウェイホストの侵害: ホストは上流の認証情報を保持し、全開発者にmanaged settingsを配ります。設定への統制力はMDMに匹敵し、承認ダイアログは変更を目立たせても、ホストの防御は代替しません。
悪意あるOIDCプロバイダー: id_tokenに署名するため、任意の身元を主張できます。IdPの選定と保護は組織の責任です。
この線引きを理解しておくと、「ゲートウェイを導入すればIdPの管理がおろそかでよい」という誤解を避けられます。ゲートウェイが強いのは通信経路の設計であって、配布元そのものの信頼性を作り出すわけではありません。
接続先の偽装にはクライアント側の検査が効く
SSRFガードがゲートウェイから外へ向かう通信を守る一方、開発者のCLIにも宛先を疑う検査があります。信頼されたゲートウェイはコマンドを実行する設定を配れるため、CLIは公開アドレスのゲートウェイにはサインインしません。
サインインから設定が効くまでの関門
- 1
宛先がプライベートか検査する
/loginで、ゲートウェイのホスト名が解決するアドレスをすべて調べます。1つでも公開アドレスなら拒否です。 - 2
IdPでサインインする
デバイスグラントとPKCEで、ゲートウェイがJWTを発行します。
- 3
managed settingsを取得する
サインイン済みのセッションは、ゲートウェイに届かないと約10秒後にエラーで終了します。設定なしで起動することはありません。
- 4
危険な設定は承認を求める
次節の項目が届くと、承認ダイアログが出ます。
プライベートと見なすのは、RFC 1918、リンクローカル、CGNATの100.64.0.0/10、IPv6のULA(fc00::/7)、ループバックです。デュアルスタックの名前で公開レンジのAAAAレコードが混じると、この検査に落ちます。AWSの内部デュアルスタックロードバランサーは公開レンジのAAAAを返すため、典型的な原因です。自社が使う公開IPv4空間にゲートウェイを置く場合は、managed settingsのgatewayInternalNetworksでそのブロックを宣言します。
社内のプロキシを経由する環境では、プロキシのホスト名もプライベートへ解決する必要があります。そうでない場合は、ゲートウェイのホストをNO_PROXYに加えて直接接続にします。http://の接続先を受け付けるのは、ホストがループバックのときだけです。
ホスト侵害を「対象外」としつつ実害を限定する承認ダイアログ
ゲートウェイホストの侵害が設計の対象外だとしても、そこから配られるmanaged settingsが開発者のマシンで無条件に効くわけではありません。次の項目が届くと、CLIは適用前に開発者へ承認ダイアログを出します。
- フック(
hooks) - プロキシやベースURLなど、承認を要する
env変数 apiKeyHelperやstatusLineのようなシェル実行系の設定sandbox.bwrapPath等、サンドボックスのバイナリ指定- 通信を横取りする
sandbox.network.tlsTerminate等、サンドボックスの隔離を弱める設定
開発者が拒否すると、CLIは終了します。侵害されたホストが不正な設定を配っても、開発者の目に触れずに実行される経路ではない、という点が実害の上限を作っています。
承認はゲートウェイ単位で記録されます。同じゲートウェイにサインインし直しても、承認が必要な設定が変わらない限りダイアログは再表示されません。別のゲートウェイへのサインイン、設定の変更、同じゲートウェイでの新しい証明書の承認では、再び表示されます。平文HTTPのループバック開発用ゲートウェイは承認が保存されないため、サインインのたびに表示されます。
穴になりうるのは非対話の実行です。claude -p、Agent SDKのセッション、VS Code拡張のチャットパネル、デスクトップアプリのCodeタブはダイアログを出せません。承認が必要な設定が届くと、その回の実行にだけ適用され、承認済みとしては記録されません。承認がない間は、非対話の実行が起動のたびに設定を取得し直します。
立場によって変わる読み方
同じ脅威モデルでも、誰が読むかによって効いてくる箇所が違います。
| 立場 | この設計が変えること |
|---|---|
| 開発者 | この設計が変えること資格情報を持たない代わりに、ゲートウェイが落ちると作業できなくなる |
| ゲートウェイ運用者 | この設計が変えることホストへの侵害はMDMを乗っ取られるのと同じ重大度になる。ホストへのアクセス統制はMDM並みの重みを持つ |
| セキュリティレビュー担当 | この設計が変えること質問票の大半は次の対応表でそのまま埋まるが、ホスト侵害の検知は自社の監視設計に委ねられたままになる |
コンプライアンス質問票にどう答えるか
セキュリティレビューやコンプライアンス質問票で聞かれる項目は、公式ドキュメントの「Compliance posture」節にほぼそのまま対応します。
| 質問される観点 | 回答の要点 |
|---|---|
| データレジデンシー | 回答の要点Anthropic APIを上流に設定していない限り、ゲートウェイのデータプレーンはAnthropicに何も送らない。テレメトリ・監査・ID・設定は運用者が指定した宛先だけに届く |
| ホストプロセスの通信 | 回答の要点ホストプロセスはClaude Code CLI自体で、Anthropicへは何も送らない。v2.1.227より前はバージョン等の起動テレメトリに加え、起動時にボディなしのHEADリクエストをapi.anthropic.comの/api/helloへ1回送っていた。プロキシ変数やmTLSクライアント証明書を設定していない環境では、ANTHROPIC_BASE_URLがあればそちらへ送られた。応答は無視されるので、egressで遮断しても動作に影響はない |
| クライアント側の分析 | 回答の要点ゲートウェイへのサインイン中は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に対応 |
| 脆弱性の報告 | 回答の要点公式の脆弱性報告フローに従う |
表の読み分けは、ゲートウェイ自身の通信は既定でAnthropicに出ない一方、開発者端末の通信は明示的に止める必要がある、という点です。更新チェックや初回サインイン前のイベントは、設定を配布しない限り送られ続けます。
TLSについては表に収まらない補足が2つあります。まずlisten.public_urlは、ゲートウェイ自身のリスナーで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)の健全性は、この設計が保証してくれる範囲の外にあります。ゲートウェイは、モデルへの唯一の経路であることも強制しません。自前の資格情報を持つ開発者はプロバイダーへ直接アクセスできるため、その経路を閉じるのはネットワーク側の判断です。api.anthropic.comへのegressをゲートウェイ以外から遮断する場合は、各開発者のマシンから同ホストを呼ぶWebFetchのドメイン安全確認も止まります。managed policyでskipWebFetchPreflight: trueを設定すれば、確認そのものを無効にできます。
まとめ
守るべき範囲を決めるなら、経路の検査はゲートウェイに任せ、ホストの防御とIdPの管理は自分たちの仕事として切り出す、というのが判断の軸です。
実装はClaude apps gatewayの使い方にあります。gateway.yamlの項目は設定リファレンス、運用の流れはデプロイと運用ガイドです。ゲートウェイ経由のセッションではRemote Controlを使えません。