メインコンテンツへスキップ
Gateway を公開するのは、誰が到達できるのか、どのように認証されるのか、どのエージェントを起動できるのか、そしてそれらのエージェントがどのツールを使用できるのかを説明できるようになってからにしてください。不明な点がある場合は、ループバックのみのアクセスに戻し、監査を再実行してください。
このランブックは、より広範な セキュリティ ガイダンスを、リモートアクセスとメッセージング公開のためのオペレーターチェックリストに落とし込んだものです。

​
公開パターンを選択する

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

​
事前インベントリ

bind、プロキシ、Tailscale、またはチャネルポリシーを変更する前に、次を記録してください。
  • Gateway ホスト、OS ユーザー、状態ディレクトリ（デフォルトは ~/.openclaw）。
  • Gateway URL とバインドモード（gateway.bind、デフォルトポートは 18789）。
  • 認証モード、トークン/パスワードのソース、または信頼済みプロキシの ID ソース。
  • 有効な各チャネルと、それが DM、グループ、または Webhook を受け付けるかどうか。
  • 非ローカル送信者から到達可能なエージェント。
  • 到達可能な各エージェントのツールプロファイル、サンドボックスモード、昇格ツールポリシー。
  • それらのエージェントが利用できる外部認証情報。
  • ~/.openclaw/openclaw.json と認証情報のバックアップ場所。
複数人がボットにメッセージを送信できる場合、これはユーザー単位のホスト分離ではなく、共有された委任ツール権限として扱ってください。

​
ベースラインチェック

アクセスを開く前に実行してください。 
openclaw doctor
openclaw security audit
openclaw security audit --deep
openclaw 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 を拒否するか、承認を必須にする。
  • 特定の信頼済み送信者が必要としない限り、昇格ツールは無効のままにする。
  • オープンまたは半オープンなメッセージングサーフェスでは、browser、canvas、node、cron、gateway、session-spawn ツールを避ける。
  • バインドマウントは狭く保つ。認証情報、ホーム、Docker ソケット、システムパスは避ける。
  • 実質的に異なる信頼境界には、別々の Gateway、OS ユーザー、またはホストを使用する。
リモートユーザーが完全には信頼されていない場合、分離はプロンプトやセッションラベルだけではなく、別々のデプロイから得る必要があります。

​
変更後の検証

公開変更ごとに、次を実施してください。
  1. openclaw security audit --deep を再実行する。
  2. 承認済み接続が成功することを確認する。
  3. 未承認の送信者またはブラウザーセッションが拒否されることを確認する。
  4. ログがシークレットを秘匿することを確認する。
  5. DM/グループのルーティングが意図したエージェントのみに到達することを確認する。
  6. 影響の大きいツールが承認を求めるか拒否されることを確認する。
  7. 受け入れた残存警告を文書化する。
現在の変更が理解されるまで、次の公開変更に進まないでください。

​
ロールバック計画

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 },
  },
}
その後、次を実施してください。
  1. 公開転送、Tailscale Funnel、またはリバースプロキシルートを停止する。
  2. Gateway トークン/パスワードと影響を受けた連携認証情報をローテーションする。
  3. 許可リストから "*" と想定外の送信者を削除する。
  4. 最近の監査ログ、実行履歴、ツール呼び出し、設定変更をレビューする。
  5. openclaw security audit --deep を再実行する。
  6. ワークフローを満たす最も狭いパターンでアクセスを再有効化する。

​
レビューチェックリスト

  • 文書化された理由がない限り、Gateway はループバックのみのままにする。
  • 非ループバックアクセスには認証、ファイアウォール設定があり、公開の直接ルートがない。
  • 信頼済みプロキシのデプロイでは、厳格なプロキシ IP とヘッダー制御がある。
  • DM はデフォルトでオープンアクセスにせず、ペアリングまたは許可リストを使用する。
  • グループではメンションまたは明示的な許可リストを必須にする。
  • 共有チャネルが個人の認証情報に到達しない。
  • 非 main セッションはサンドボックスモードで実行される。
  • ホスト exec と昇格ツールは拒否されるか、承認ゲート付きである。
  • ログはシークレットを秘匿する。
  • 重大な監査検出事項は解決済みである。
  • ロールバック手順はテストされ、文書化されている。