ネットワークポリシー

ネットワークポリシーは、HTTP/HTTPSフィルタリングプロキシを介して、サンドボックスがアクセスできる外部リソースを制御します。ポリシーを使用することで、エージェントによる社内ネットワークへのアクセス防止、コンプライアンス要件の遵守、または特定のサービスへのインターネットアクセスの制限が可能です。

各サンドボックスには、外部へのHTTPおよびHTTPSトラフィックに対してポリシーを適用するフィルタリングプロキシが備わっています。生のTCPやUDP接続など、他のプロトコルによる外部サービスへの接続はブロックされます。エージェントのすべての通信は、このHTTPプロキシを経由するか、サンドボックス内に閉じている必要があります。

プロキシはホスト上のエフェメラルポートで動作しますが、エージェントコンテナからは host.docker.internal:3128 としてアクセス可能です。

セキュリティに関する考慮事項

ネットワークポリシーはセキュリティの「一層」として利用し、それだけに依存しないでください。主な隔離機能はmicroVMの境界によって提供されます。ネットワークポリシーは、HTTP/HTTPSトラフィックに対する追加の制御手段です。

ネットワークフィルタリングは、プロセスが接続できるドメインを制限しますが、通信内容（コンテンツ）の検査は行いません。ポリシーを設定する際は、以下の点に注意してください：

github.com のような広範なドメインを許可すると、ユーザー生成コンテンツを含むそのドメイン上のあらゆるコンテンツへのアクセスが可能になります。エージェントがこれらをデータ漏洩のチャネルとして利用する可能性があります。
「ドメインフロントリング（Domain fronting）」技術により、許可されたドメインを経由してフィルタを回避される可能性があります。これはHTTPSプロキシの仕組み上、避けられない性質です。

信頼できるドメインのみを許可してください。設定したポリシーが何を許可しているかを理解する責任はユーザーにあります。

ネットワークフィルタリングの仕組み

各サンドボックスには、ホスト上で動作するHTTP/HTTPSプロキシがあります。このプロキシには、サンドボックス内部から host.docker.internal:3128 でアクセスできます。

エージェントがHTTPまたはHTTPSリクエストを行う際、プロキシは以下の処理を行います：

リクエスト内のホスト名に対してポリシーをチェックします。ホストがブロックされている場合、リクエストは即座に停止されます。
サーバーに接続します。ホストが明示的に許可されていない場合は、サーバーのIPアドレスを BlockCIDR（ブロック対象CIDR）ルールと照合します。

例えば、localhost はデフォルトの許可リストには含まれていませんが、デフォルトの「allow（許可）」ポリシーでは許可されています。しかし、明示的に許可されていないため、プロキシは解決されたIPアドレス（127.0.0.1 または ::1）を BlockCIDR ルールと照合します。127.0.0.1/8 と ::1/128 はどちらもデフォルトでブロックされているため、ip6-localhost のような localhost のDNSエイリアスも捕捉されます。

エージェントが localhost 上のサービスにアクセスする必要がある場合は、許可リストにポート番号を含めて指定してください（例：localhost:1234）。

host.docker.internal へのHTTPリクエストは localhost に書き換えられるため、許可リストでは localhost という名前のみが機能します。

デフォルトポリシー

カスタムポリシーを設定しない限り、新しいサンドボックスには以下のデフォルトポリシーが適用されます：

ポリシーモード: allow （明示的にブロックされたもの以外はすべて許可）

ブロック対象CIDR:

10.0.0.0/8 - プライベートネットワーク (クラスA)
127.0.0.0/8 - ループバックアドレス
169.254.0.0/16 - リンクローカルアドレス
172.16.0.0/12 - プライベートネットワーク (クラスB)
192.168.0.0/16 - プライベートネットワーク (クラスC)
::1/128 - IPv6 ループバック
fc00::/7 - IPv6 ユニークローカルアドレス
fe80::/10 - IPv6 リンクローカルアドレス

許可されたホスト:

*.anthropic.com - Claude API および関連サービス
platform.claude.com:443 - Claude プラットフォームサービス

デフォルトポリシーでは、インターネットアクセスを許可しつつ、プライベートネットワーク、localhost、およびクラウドのメタデータサービスへのアクセスをブロックします。明示的に許可されたホストは、パフォーマンス向上のためにCIDRチェックをバイパスします。

ネットワーク活動の監視

エージェントがどこにアクセスしているか、リクエストがブロックされているかを確認できます：


$ docker sandbox network log

ネットワークログには、HTTP/HTTPSリクエストの集計サマリーが表示されます：

Allowed requests - ポリシーによって許可されたリクエスト
Blocked requests - ポリシーによって拒否されたリクエスト

アクセスされた各ホストについて、以下の情報が表示されます：

Sandbox - リクエストを行ったサンドボックス名
Host - 送信先（ホスト名とポート）
Rule - 一致したポリシー（または <default policy>）
Last Seen - 最後にアクセスされた日時
Count - 追跡開始以降のリクエスト数

ネットワークログを使用して、エージェントの挙動を理解し、許可すべきブロックされたリクエストを特定し、ポリシーの問題をデバッグしてください。ログはポリシーを定義する際に特に役立ちます。エージェントが実際に何にアクセスしようとしているかが明確になるからです。

ログ出力の例


$ docker sandbox network log
Blocked requests:
SANDBOX          HOST                    RULE             LAST SEEN         COUNT
my-sandbox       internal.corp.com:443   <default policy> 14:30:15 12-Feb   3
my-sandbox       192.168.1.100:22        <default policy> 14:25:10 12-Feb   1
 
Allowed requests:
SANDBOX          HOST                          RULE                   LAST SEEN         COUNT
my-sandbox       api.anthropic.com:443         api.anthropic.com      14:35:21 12-Feb   15
my-sandbox       registry.npmjs.org:443        *.npmjs.org            14:32:18 12-Feb   8
my-sandbox       raw.githubusercontent.com:443 *.githubusercontent.com 14:30:45 12-Feb   2

ログは許可されたリクエストとブロックされたリクエストを別々のセクションで表示します。機械可読な出力には --json、ヘッダーを非表示にするには --quiet、表示件数を制限するには --limit N を使用してください。

ポリシーの適用

docker sandbox network proxy コマンドを使用して、サンドボックスのネットワークポリシーを設定します。ポリシーの変更を適用するには、サンドボックスが実行中である必要があります。変更は即座に反映され、サンドボックスの再起動後も保持されます。

例：内部ネットワークをブロックする

エージェントがローカルネットワーク、Dockerネットワーク、およびクラウドメタデータサービスにアクセスするのを防ぎます。これにより、エージェントがパッケージをインストールしたりパブリックAPIにアクセスしたりすることを許可しつつ、内部サービスへの不慮のアクセスを防ぐことができます。


$ docker sandbox network proxy my-sandbox \
  --policy allow \
  --block-cidr 10.0.0.0/8 \
  --block-cidr 172.16.0.0/12 \
  --block-cidr 192.168.0.0/16 \
  --block-cidr 127.0.0.0/8

このポリシーは：

インターネットアクセスを許可
RFC 1918 プライベートネットワーク（10.x.x.x, 172.16-31.x.x, 192.168.x.x）をブロック
localhost（127.x.x.x）をブロック

Note

これらのCIDRブロックは、デフォルトですでにブロックされています。上記の例は、それらを明示的に設定する方法を示しています。完全なリストについてはデフォルトポリシーを参照してください。

例：パッケージマネージャーのみに制限する（拒否リスト）

厳格に制御するには、パッケージリポジトリのみを許可する拒否リスト（denylist）ポリシーを使用します：


$ docker sandbox network proxy my-sandbox \
  --policy deny \
  --allow-host "*.npmjs.org" \
  --allow-host "*.pypi.org" \
  --allow-host "files.pythonhosted.org" \
  --allow-host "*.rubygems.org" \
  --allow-host github.com

Note

このポリシーはAIコーディングエージェントのバックエンド（例：Claude Codeの場合は xyz.anthropic.com）もブロックしてしまいます。エージェントが必要とするホスト名も必ず含めるようにしてください。

これにより、エージェントは依存関係のインストールはできますが、任意のインターネットリソースにはアクセスできなくなります。これはCI/CD環境や信頼できないコードを実行する場合に有用です。

例：AI APIと開発ツールを許可する

AIサービスへのアクセスとパッケージマネージャー、バージョン管理システムを組み合わせます：


$ docker sandbox network proxy my-sandbox \
  --policy deny \
  --allow-host api.anthropic.com \
  --allow-host "*.npmjs.org" \
  --allow-host "*.pypi.org" \
  --allow-host github.com \
  --allow-host "*.githubusercontent.com"

これにより、エージェントはAI APIの呼び出し、パッケージのインストール、GitHubからのコード取得が可能になりますが、それ以外のインターネットアクセスはブロックされます。

例：特定のAPIを許可しつつ、サブドメインをブロックする

詳細な制御のために、ポート指定のルールやサブドメインパターンを使用します：


$ docker sandbox network proxy my-sandbox \
  --policy deny \
  --allow-host api.example.com:443 \
  --allow-host cdn.example.com \
  --allow-host "*.storage.example.com:443"

このポリシーが許可するもの：

api.example.com のポート 443 へのリクエスト（通常は https://api.example.com）
cdn.example.com の任意のポートへのリクエスト
storage.example.com の任意のサブドメインのポート 443 へのリクエスト（例：us-west.storage.example.com:443）

example.com（全ポート）、www.example.com（全ポート）、または api.example.com:8080 へのリクエストは、パターンに一致しないためすべてブロックされます。

ドメインとそのすべてのサブドメインの両方を許可するには、両方のパターンを指定してください：


$ docker sandbox network proxy my-sandbox \
  --policy deny \
  --allow-host example.com \
  --allow-host "*.example.com"

ポリシーモード：許可リスト（allowlist） vs 拒否リスト（denylist）

ポリシーには、デフォルトの挙動を決定する2つのモードがあります。

許可リスト（Allowlist）モード

デフォルト：すべてのトラフィックを許可し、特定の送信先のみブロックします。


$ docker sandbox network proxy my-sandbox \
  --policy allow \
  --block-cidr 192.0.2.0/24 \
  --block-host example.com

エージェントにほとんどのリソースへのアクセスを許可しつつ、特定のネットワークやドメインのみをブロックしたい場合に使用します。制限が少なく、エージェントが広範なインターネットアクセスを必要とする開発環境に適しています。

拒否リスト（Denylist）モード

デフォルト：すべてのトラフィックをブロックし、特定の送信先のみ許可します。


$ docker sandbox network proxy my-sandbox \
  --policy deny \
  --allow-host api.anthropic.com \
  --allow-host "*.npmjs.org"

外部アクセスを厳格に制御したい場合に使用します。エージェントが必要とする各サービスを明示的に許可する必要があるため、セキュアですが手間がかかります。本番環境、CI/CDパイプライン、または信頼できないコードを扱う場合に適しています。

ドメインとCIDRのマッチング

ドメインパターンは、完全一致、ワイルドカード、ポート指定をサポートしています：

example.com - そのドメインのみに一致（ポート不問）
example.com:443 - example.com のポート 443（標準的なHTTPSポート）へのリクエストに一致
*.example.com - api.example.com や www.example.com などのすべてのサブドメインに一致
*.example.com:443 - サブドメインの[ポート 443 へのリクエストに一致

重要なマッチングの動作：

example.com はサブドメインに一致しません。api.example.com へのリクエストは example.com のルールには該当しません。
*.example.com はルートドメインに一致しません。example.com へのリクエストは *.example.com のルールには該当しません。
ドメインとそのサブドメインの両方を許可するには、example.com と *.example.com の両方を指定する必要があります。

複数のパターンがリクエストに一致する場合、最も具体的なパターンが優先されます：

ホスト名とポートの完全一致: api.example.com:443
ホスト名の完全一致（ポート不問）: api.example.com
ワイルドカードパターン（長い一致が優先）: *.api.example.com:443, *.api.example.com, *.example.com:443, *.example.com
キャッチオールワイルドカード: *:443, *
デフォルトポリシー（許可または拒否）

これにより、広範なパターンをブロックしつつ、特定の例外を許可することができます。例えば、example.com と *.example.com をブロックしたまま、api.example.com:443 だけを許可することが可能です。

CIDRブロックは、DNS解決後のIPアドレスに対してマッチングを行います：

192.0.2.0/24 は、すべての 192.0.2.x アドレスをブロックします。

ドメインをブロックまたは許可すると、プロキシはそのドメインをIPアドレスに解決し、それらのIPをCIDRルールと照合します。つまり、CIDR範囲をブロックすると、その範囲のIPに解決されるすべてのドメインに影響します。

HTTPSトンネリングのためのバイパスモード

デフォルトでは、プロキシはHTTPS接続に対して「中間者（MITM）」として動作し、TLSを終端して独自の認証局（CA）でトラフィックを再暗号化します。これにより、プロキシはポリシーを適用したり、特定のサービスに認証情報を注入したりできます。サンドボックスコンテナはプロキシのCA証明書を信頼しています。

一部のアプリケーションは証明書のピン留め（Certificate Pinning）などの技術を使用しており、MITMプロキシでは動作しません。このような場合は、バイパスモードを使用して、検査なしで直接HTTPSトラフィックをトンネリングします：


$ docker sandbox network proxy my-sandbox \
  --bypass-host api.service-with-pinning.com

特定のIP範囲をバイパスすることも可能です：


$ docker sandbox network proxy my-sandbox \
  --bypass-cidr 203.0.113.0/24

トラフィックがバイパスされると、プロキシは：

内容を検査せず、単純なTCPトンネルとして動作します。
リクエストに認証情報を注入することはできません。
ドメインフロントリングなどの回避技術を検出することはできません。
最初の接続時のドメインとポートの一致確認による制限は引き続き行われます。

バイパスモードは必要な場合にのみ使用してください。バイパスされたトラフィックでは、MITM検査による可視性とセキュリティのメリットが失われます。github.com のような広範なドメインをバイパスすると、プロキシはエージェントがそのドメイン上で何にアクセスしているかを把握できなくなります。

ポリシーの永続化

ネットワークポリシーはJSON設定ファイルに保存されます。

サンドボックスごとの設定

docker sandbox network proxy my-sandbox を実行すると、その特定のサンドボックスの設定のみが更新されます。ポリシーは ~/.docker/sandboxes/vm/my-sandbox/proxy-config.json に保存されます。

新規作成されるサンドボックスに適用されるデフォルトポリシーは、直接変更しない限り変わりません。

デフォルト設定

新しいサンドボックス用のデフォルトネットワークポリシーは ~/.sandboxd/proxy-config.json に保存されています。このファイルは、最初のサンドボックスが起動した際に（まだ存在しない場合のみ）自動的に作成されます。

現在のデフォルトポリシーは allow で、ブロックされたCIDR範囲（プライベートネットワーク、localhost、クラウドメタデータサービス）以外のすべての外部接続を許可します。

デフォルトポリシーを変更する方法：

~/.sandboxd/proxy-config.json を直接編集する。
または、特定のサンドボックスのポリシーをデフォルトの場所にコピーする：
```
$ cp ~/.docker/sandboxes/vm/my-sandbox/proxy-config.json ~/.sandboxd/proxy-config.json
```

新しいサンドボックスを作成する前に、セキュリティ要件に合わせてデフォルトポリシーを確認・カスタマイズしておくことをお勧めします。一度作成されると、アップグレードによってデフォルトポリシーファイルが上書きされることはなく、カスタム設定が維持されます。