Gateway
Gateway 公開運用手順書
このランブックは、広範なセキュリティガイダンスを、リモートアクセスとメッセージング公開のための運用者向けチェックリストにまとめたものです。
公開パターンを選択する
ワークフローの要件を満たす、最も限定的なパターンを優先してください。
| パターン | 推奨される状況 | 必須の制御 |
|---|---|---|
| ループバック + SSH トンネル | 個人利用、管理者アクセス、デバッグ | gateway.bind: "loopback" を維持し、127.0.0.1:18789 をトンネルする |
| ループバック + Tailscale Serve | Control UI/WebSocket への個人用 tailnet アクセス | Gateway を local loopback のみに維持する。Tailscale の ID ヘッダーが認証するのは Control UI の WebSocket サーフェスのみであり、他の認証経路は認証しない |
| Tailnet/LAN バインド | 既知のデバイスのみが存在する専用プライベートネットワーク | Gateway 認証、ファイアウォールの許可リスト、公開ポート転送なし |
| 信頼済みリバースプロキシ | Gateway の前段に組織の SSO/OIDC を配置する場合 | trusted-proxy 認証、厳格な trustedProxies、ヘッダーの上書き/除去ルール、明示的な許可ユーザー |
| 公開インターネット | まれな高リスクのデプロイ | ID 対応プロキシ、TLS、レート制限、厳格な許可リスト、サンドボックス化された非メインセッション |
Gateway への直接的な公開ポート転送は避けてください。公開アクセスが必要な場合は、その前段に ID 対応プロキシを配置し、そのプロキシを Gateway への唯一のネットワーク経路にしてください。
事前インベントリ
バインド、プロキシ、Tailscale、またはチャネルポリシーを変更する前に、以下を記録してください。
- Gateway のホスト、OS ユーザー、状態ディレクトリ(デフォルトは
~/.openclaw)。 - Gateway の URL とバインドモード(
gateway.bind。デフォルトポートは18789)。 - 認証モード、トークン/パスワードの取得元、または信頼済みプロキシの ID 情報源。
- 有効になっているすべてのチャネルと、それぞれが DM、グループ、Webhook のどれを受け付けるか。
- ローカル以外の送信者から到達可能なエージェント。
- 到達可能な各エージェントのツールプロファイル、サンドボックスモード、昇格ツールポリシー。
- それらのエージェントが利用できる外部認証情報。
~/.openclaw/openclaw.jsonと認証情報のバックアップ先。
複数の人がボットにメッセージを送信できる場合、これはユーザーごとのホスト分離ではなく、共有された委任ツール権限として扱ってください。
ベースラインチェック
アクセスを開放する前に、以下を実行してください。
openclaw doctoropenclaw security auditopenclaw security audit --deepopenclaw health重大な検出事項を最初に解決してください。警告を受け入れるのは、デプロイ上意図的であり、文書化されている場合に限ります。各 checkId の意味と修正キーについては、セキュリティ監査チェックを参照してください。
リモート CLI の検証では、認証情報を明示的に渡してください。
openclaw gateway probe --url ws://127.0.0.1:18789 --token "$OPENCLAW_GATEWAY_TOKEN"明示的なリモート URL にローカル設定の認証情報が適用されると想定しないでください。
安全性の最低基準
公開するデプロイの出発点として、次の構成を使用してください。
{ 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 トラフィックを受け入れる前にリバースプロキシを有効にします。
tools.exec.security: "deny" は、無害な診断を含むすべての exec 呼び出しをブロックします。診断や低リスクのコマンドが必要な場合は、脅威モデルに合致する特定の送信者、エージェント、コマンド、承認モードを選択した後に限り、この設定を緩和してください。
DM とグループの公開
メッセージングチャネルは、信頼できない入力サーフェスです。DM またはグループを許可する前に、以下を行ってください。
dmPolicy: "open"よりも、dmPolicy: "pairing"または厳格なallowFromリストを優先してください。"*"の許可リストと広範なツールアクセスを組み合わせないでください。- ルームが厳格に管理されている場合を除き、グループではメンションを必須にしてください。
- 複数の人がボットに DM を送信できる場合は、DM セッション間でコンテキストが共有されないように、
session.dmScope: "per-channel-peer"(複数アカウントのチャネルでは"per-account-channel-peer")を設定してください。 - 共有チャネルは、最小限のツールのみを持ち、個人の認証情報を持たないエージェントへルーティングしてください。
ペアリングは、送信者がボットを起動することを承認します。その送信者を独立したホストセキュリティ境界にするものではありません。
リバースプロキシのチェック
ID 対応プロキシでは、以下を確認してください。
- プロキシは、Gateway に転送する前にユーザーを認証する必要があります。
- ファイアウォールまたはネットワークポリシーで、Gateway ポートへの直接アクセスをブロックする必要があります。
gateway.trustedProxiesには、プロキシの送信元 IP のみを指定する必要があります。- プロキシは、クライアントが指定した ID ヘッダーと転送ヘッダーを除去または上書きする必要があります。
- プロキシが複数の対象者にサービスを提供する場合は、
gateway.auth.trustedProxy.allowUsersを設定してください。 gateway.auth.trustedProxy.allowLoopbackは、ローカルプロセスが信頼され、プロキシが ID ヘッダーを管理する同一ホスト上のプロキシにのみ使用してください。
プロキシの変更後に openclaw security audit --deep を実行してください。信頼済みプロキシに関する検出事項は、プロキシが認証境界となるため、重要度の高いシグナルです。
ツールとサンドボックスの確認
エージェントをリモート送信者に公開する前に、以下を行ってください。
- どのセッションがホスト上で実行され、どのセッションがサンドボックス内で実行されるかを確認してください。
- ホスト上での exec を拒否するか、承認を必須にしてください。
- 特定の信頼済み送信者が必要とする場合を除き、昇格ツールを無効のままにしてください。
- オープンまたは半オープンなメッセージングサーフェスでは、ブラウザ、キャンバス、Node、Cron、Gateway、セッション生成ツールを避けてください。
- バインドマウントは限定的にしてください。認証情報、ホーム、Docker ソケット、システムパスを避けてください。
- 信頼境界が実質的に異なる場合は、別々の Gateway、OS ユーザー、またはホストを使用してください。
リモートユーザーが完全には信頼されていない場合、分離はプロンプトやセッションラベルだけでなく、別々のデプロイによって実現する必要があります。
変更後の検証
公開設定を変更するたびに、以下を行ってください。
openclaw security audit --deepを再実行します。- 承認済みの接続が正常に成功することを確認します。
- 未承認の送信者またはブラウザセッションが拒否されることを確認します。
- ログでシークレットが秘匿されることを確認します。
- DM/グループのルーティングが意図したエージェントのみに到達することを確認します。
- 影響の大きいツールが承認を要求するか、拒否されることを確認します。
- 受け入れた残存警告を文書化します。
現在の変更を理解できるまでは、次の公開設定変更に進まないでください。
ロールバック計画
Gateway が過剰に公開されている可能性がある場合は、次のように設定してください。
{ gateway: { bind: "loopback", }, channels: { whatsapp: { dmPolicy: "disabled" }, telegram: { dmPolicy: "disabled" }, discord: { dmPolicy: "disabled" }, slack: { dmPolicy: "disabled" }, }, tools: { exec: { security: "deny", ask: "always" }, elevated: { enabled: false }, },}その後、以下を行います。
- 公開転送、Tailscale Funnel、またはリバースプロキシのルートを停止します。
- Gateway のトークン/パスワードと、影響を受けた連携の認証情報をローテーションします。
- 許可リストから
"*"と想定外の送信者を削除します。 - 最近の監査ログ、実行履歴、ツール呼び出し、設定変更を確認します。
openclaw security audit --deepを再実行します。- ワークフローの要件を満たす最も限定的なパターンでアクセスを再度有効にします。
確認チェックリスト
- 文書化された理由がない限り、Gateway は local loopback のみに維持されている。
- local loopback 以外からのアクセスには認証とファイアウォール制御があり、公開された直接経路がない。
- 信頼済みプロキシを使用するデプロイでは、プロキシ IP とヘッダー制御が厳格に設定されている。
- DM はデフォルトでオープンアクセスにせず、ペアリングまたは許可リストを使用している。
- グループではメンションまたは明示的な許可リストを必須にしている。
- 共有チャネルから個人の認証情報に到達できない。
- 非メインセッションはサンドボックスモードで実行される。
- ホスト上での exec と昇格ツールは拒否されるか、承認ゲートが設定されている。
- ログでシークレットが秘匿されている。
- 重大な監査検出事項が解決されている。
- ロールバック手順がテストされ、文書化されている。