--- read_when: - Gateway を LAN、tailnet、Tailscale Serve、Funnel、またはリバースプロキシ経由で公開する - 実際のメッセージングユーザーを許可する前にデプロイをレビューする - リスクの高いリモートアクセスまたは DM 設定のロールバック sidebarTitle: Exposure runbook summary: local loopback を越えて OpenClaw Gateway を公開する前の事前確認とロールバックのチェックリスト title: Gateway公開ランブック x-i18n: generated_at: "2026-06-27T11:37:04Z" model: gpt-5.5 postprocess_version: locale-links-v1 provider: openai source_hash: c5e94cc03b9d79a03eb16aa04bad0fd311b72f27f14182c036832382dbce3d0f source_path: gateway/security/exposure-runbook.md workflow: 16 --- 誰が Gateway に到達できるか、どのように認証されるか、どのエージェントをトリガーできるか、それらのエージェントがどのツールを使用できるかを説明できるようになってから、Gateway を公開してください。迷った場合は、ループバックのみのアクセスに戻し、監査を再実行してください。 このランブックは、より広範な [セキュリティ](/ja-JP/gateway/security) ガイダンスを、リモートアクセスとメッセージング公開のためのオペレーターチェックリストに落とし込みます。 ## 公開パターンを選択する ワークフローを満たす最も狭いパターンを優先してください。 | パターン | 推奨される場合 | 必須の制御 | | -------------------------- | ----------------------------------------------- | --------------------------------------------------------------------------------------------------- | | ループバック + 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 doctor openclaw security audit openclaw security audit --deep openclaw 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 ユーザー、またはホストを使用する。 リモートユーザーが完全には信頼されていない場合、分離はプロンプトやセッションラベルだけでなく、別個のデプロイから得る必要があります。 ## 変更後の検証 各公開変更の後に: 1. `openclaw security audit --deep` を再実行する。 2. 承認済み接続が成功することをテストする。 3. 未承認の送信者またはブラウザーセッションが拒否されることをテストする。 4. ログがシークレットを伏せることを確認する。 5. DM/グループのルーティングが意図したエージェントにのみ到達することを確認する。 6. 影響の大きいツールが承認を求めるか、拒否されることを確認する。 7. 受け入れた残余警告を文書化する。 現在の変更が理解されるまで、次の公開変更に進まないでください。 ## ロールバック計画 Gateway が過度に公開されている可能性がある場合: ```json5 { 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 と昇格ツールは拒否されるか、承認ゲートされる。 - ログはシークレットを伏せる。 - 重大な監査検出事項は解決済みである。 - ロールバック手順はテストされ、文書化されている。