Gateway

Gateway公開ランブック

このランブックは、より広範なセキュリティガイダンスを、リモートアクセスとメッセージング公開のためのオペレーターチェックリストに落とし込みます。

公開パターンを選択する

ワークフローを満たす最も狭いパターンを優先してください。

パターン	推奨される場合	必須の制御
ループバック + SSH トンネル	個人利用、管理者アクセス、デバッグ	`gateway.bind: "loopback"` を維持し、`127.0.0.1:18789` をトンネルする
ループバック + Tailscale Serve	Control UI/WebSocket への個人 tailnet アクセス	Gateway はループバックのみに維持し、対応しているサーフェスでのみ Tailscale ID ヘッダーに依存する
tailnet/LAN バインド	既知のデバイスがある専用プライベートネットワーク	Gateway 認証、ファイアウォール許可リスト、公開ポート転送なし
信頼済みリバースプロキシ	Gateway の前段に組織の SSO/OIDC を置く場合	`trusted-proxy` 認証、厳格な `trustedProxies`、ヘッダーの上書き/除去ルール、明示的な許可ユーザー
公開インターネット	まれな高リスクのデプロイ	ID 対応プロキシ、TLS、レート制限、厳格な許可リスト、サンドボックス化された非 main セッション

Gateway への直接の公開ポート転送は避けてください。公開アクセスが必要な場合は、ID 対応プロキシを前段に置き、Gateway への唯一のネットワーク経路をそのプロキシにしてください。

事前インベントリ

バインド、プロキシ、Tailscale、またはチャネルポリシーを変更する前に、以下を記録してください。

Gateway ホスト、OS ユーザー、状態ディレクトリ。
Gateway URL とバインドモード。
認証モード、トークン/パスワードのソース、または信頼済みプロキシの ID ソース。
有効なすべてのチャネルと、それらが DM、グループ、Webhook を受け付けるかどうか。
ローカル以外の送信者から到達可能なエージェント。
到達可能な各エージェントのツールプロファイル、サンドボックスモード、昇格ツールポリシー。
それらのエージェントが利用できる外部認証情報。
~/.openclaw/openclaw.json と認証情報のバックアップ場所。

複数の人がボットにメッセージを送信できる場合、これはユーザーごとのホスト分離ではなく、共有された委任ツール権限として扱ってください。

ベースラインチェック

アクセスを開く前に、以下を実行してください。

bash

openclaw doctoropenclaw security auditopenclaw security audit --deepopenclaw health

重大な検出事項を先に解決してください。警告は、そのデプロイに対して意図的であり文書化されている場合にのみ許容できます。

リモート CLI 検証では、認証情報を明示的に渡してください。

bash

openclaw gateway probe --url ws://127.0.0.1:18789 --token "$OPENCLAW_GATEWAY_TOKEN"

ローカル設定の認証情報が明示的なリモート URL に適用されると想定しないでください。

最小限の安全なベースライン

公開デプロイの出発点として、この形を使用してください。

json5

{  gateway: {    bind: "loopback",    auth: {      mode: "token",      token: "replace-with-a-long-random-token",    },  },  session: {    dmScope: "per-channel-peer",  },  agents: {    defaults: {      sandbox: { mode: "non-main" },    },  },  tools: {    profile: "messaging",    exec: { security: "deny", ask: "always" },    elevated: { enabled: false },  },}

その後、一度に 1 つの制御だけを広げてください。たとえば、書き込み可能なツールを有効にする前に特定のチャネル許可リストを追加する、またはリモート Control UI トラフィックを受け入れる前にリバースプロキシを有効にします。

厳格な exec.security: "deny" ベースラインは、無害な診断を含むすべての exec 呼び出しをブロックします。診断または低リスクのコマンドが必要な場合は、脅威モデルに一致する特定の送信者、エージェント、コマンド、承認モードを選んだ後にのみ、これを緩和してください。

DM とグループの公開

メッセージングチャネルは信頼されない入力サーフェスです。DM またはグループを許可する前に、以下を確認してください。

dmPolicy: "pairing" または厳格な allowFrom リストを優先する。
すべての送信者が信頼済みでない限り、dmPolicy: "open" は避ける。
"*" 許可リストを広範なツールアクセスと組み合わせない。
ルームが厳密に管理されていない限り、グループではメンションを要求する。
複数の人がボットに DM できる場合は、session.dmScope: "per-channel-peer" を使用する。
共有チャネルは、最小限のツールのみを持ち、個人の認証情報を持たないエージェントにルーティングする。

ペアリングは、その送信者がボットをトリガーすることを承認します。その送信者を別個のホストセキュリティ境界にするものではありません。

リバースプロキシチェック

ID 対応プロキシの場合:

プロキシは Gateway に転送する前にユーザーを認証する必要がある。
Gateway ポートへの直接アクセスは、ファイアウォールまたはネットワークポリシーでブロックする必要がある。
gateway.trustedProxies には、プロキシの送信元 IP のみを含める必要がある。
プロキシは、クライアントから提供された ID ヘッダーと転送ヘッダーを除去または上書きする必要がある。
プロキシが複数の利用者層に提供される場合、gateway.auth.trustedProxy.allowUsers には想定ユーザーを列挙するべきです。
同一ホストのループバックプロキシモードでは、ローカルプロセスが信頼済みであり、プロキシが ID ヘッダーを所有している場合にのみ allowLoopback を使用するべきです。

プロキシ変更後に openclaw security audit --deep を実行してください。信頼済みプロキシの検出事項は、プロキシが認証境界になるため、意図的に高シグナルになっています。

ツールとサンドボックスのレビュー

リモート送信者にエージェントを公開する前に、以下を確認してください。

どのセッションがホスト上で実行され、どのセッションがサンドボックスで実行されるかを確認する。
ホスト exec を拒否するか、承認を要求する。
特定の信頼済み送信者が必要としない限り、昇格ツールは無効のままにする。
オープンまたは半オープンなメッセージングサーフェスでは、ブラウザー、キャンバス、node、cron、gateway、session-spawn ツールを避ける。
バインドマウントは狭く保ち、認証情報、ホーム、Docker ソケット、システムパスを避ける。
信頼境界が大きく異なる場合は、別々の Gateway、OS ユーザー、またはホストを使用する。

リモートユーザーが完全には信頼されていない場合、分離はプロンプトやセッションラベルだけでなく、別個のデプロイから得る必要があります。

変更後の検証

各公開変更の後に:

openclaw security audit --deep を再実行する。
承認済み接続が成功することをテストする。
未承認の送信者またはブラウザーセッションが拒否されることをテストする。
ログがシークレットを伏せることを確認する。
DM/グループのルーティングが意図したエージェントにのみ到達することを確認する。
影響の大きいツールが承認を求めるか、拒否されることを確認する。
受け入れた残余警告を文書化する。

現在の変更が理解されるまで、次の公開変更に進まないでください。

ロールバック計画

Gateway が過度に公開されている可能性がある場合: