--- read_when: - LAN、tailnet、Tailscale Serve、Funnel、またはリバースプロキシ経由で Gateway を公開する - 実際のメッセージングユーザーの利用を許可する前にデプロイをレビューする - リスクのあるリモートアクセスまたは DM 設定をロールバックする sidebarTitle: Exposure runbook summary: OpenClaw Gateway をループバックの外部に公開する前の事前確認およびロールバック用チェックリスト title: Gateway 公開手順書 x-i18n: generated_at: "2026-07-26T09:05:09Z" model: gpt-5.6 postprocess_version: locale-links-v1 prompt_version: 32 provider: openai source_hash: fb8e66af57e804325afc91281122b822183337177c734efe065c5fc18b175e72 source_path: gateway/security/exposure-runbook.md workflow: 16 --- Gateway を公開するのは、誰がアクセスできるか、どのように認証されるか、 どのエージェントを起動できるか、またそのエージェントがどのツールを 使用できるかを説明できるようになってからにしてください。判断に迷う場合は、local loopback のみによるアクセスへ戻し、監査を再実行してください。 このランブックでは、広範な[セキュリティ](/ja-JP/gateway/security)ガイダンスを、 リモートアクセスおよびメッセージング公開のための運用者向けチェックリストに落とし込みます。 ## 公開パターンを選択する ワークフローを満たす最も限定的なパターンを優先してください。 | パターン | 推奨される場合 | 必須の制御 | | -------------------------- | ----------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | | local loopback + SSH トンネル | 個人利用、管理者アクセス、デバッグ | `gateway.bind: "loopback"` を維持し、`127.0.0.1:18789` をトンネルする | | local loopback + Tailscale Serve | Control UI/WebSocket への個人用 tailnet アクセス | Gateway を local loopback のみに維持する。Tailscale のアイデンティティヘッダーが認証するのは Control UI の WebSocket サーフェスのみであり、他の認証パスではない | | Tailnet/LAN バインド | 既知のデバイスからなる専用プライベートネットワーク | Gateway 認証、ファイアウォールの許可リスト、公開ポートフォワーディングなし | | 信頼済みリバースプロキシ | Gateway の前段にある組織の SSO/OIDC | `trusted-proxy` 認証、厳格な `trustedProxies`、ヘッダーの上書き/削除ルール、明示的な許可ユーザー | | 公開インターネット | まれな高リスクのデプロイ | アイデンティティ対応プロキシ、TLS、レート制限、厳格な許可リスト、サンドボックス化された非メインセッション | Gateway への直接的な公開ポートフォワーディングは避けてください。公開アクセスが 必要な場合は、アイデンティティ対応プロキシを前段に配置し、そのプロキシを Gateway への唯一のネットワークパスにしてください。 ## 事前インベントリ バインド、プロキシ、Tailscale、またはチャネルポリシーを変更する前に、以下を記録してください。 - Gateway ホスト、OS ユーザー、および状態ディレクトリ（デフォルトは `~/.openclaw`）。 - Gateway URL とバインドモード（`gateway.bind`、デフォルトポートは `18789`）。 - 認証モード、トークン/パスワードの取得元、または信頼済みプロキシのアイデンティティソース。 - 有効なすべてのチャネル、および DM、グループ、Webhook のどれを受け入れるか。 - ローカル以外の送信者から到達可能なエージェント。 - 到達可能な各エージェントのツールプロファイル、サンドボックスモード、および昇格ツールポリシー。 - それらのエージェントが利用可能な外部認証情報。 - `~/.openclaw/openclaw.json` と認証情報のバックアップ先。 複数の人がボットにメッセージを送信できる場合、これはユーザーごとのホスト分離ではなく、 共有された委任ツール権限として扱ってください。 ## ベースラインチェック アクセスを開放する前に実行してください。 ```bash openclaw doctor openclaw security audit openclaw security audit --deep openclaw health ``` 重大な検出事項を最初に解決してください。警告は、そのデプロイにおいて意図的であり、 文書化されている場合にのみ受け入れてください。各 `checkId` の意味と修正キーについては、 [セキュリティ監査チェック](/ja-JP/gateway/security/audit-checks)を参照してください。 リモート 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 トラフィックを受け入れる前に リバースプロキシを有効にしてください。 `tools.exec.security: "deny"` は、無害な診断を含むすべての exec 呼び出しをブロックします。 診断または低リスクのコマンドが必要な場合は、脅威モデルに合致する特定の送信者、 エージェント、コマンド、および承認モードを選択してからに限り、これを緩和してください。 ## DM とグループの公開 メッセージングチャネルは信頼できない入力サーフェスです。DM または グループを許可する前に、次を行ってください。 - `dmPolicy: "open"` よりも、`dmPolicy: "pairing"` または厳格な `allowFrom` リストを優先してください。 - `"*"` の許可リストと広範なツールアクセスを組み合わせないでください。 - ルームが厳格に管理されている場合を除き、グループではメンションを必須にしてください。 - 複数の人がボットに DM を送信できる場合は、DM セッションが コンテキストを共有しないように、`session.dmScope: "per-channel-peer"`（複数アカウント対応チャネルでは `"per-account-channel-peer"`）を設定してください。 - 共有チャネルは、ツールを最小限に抑え、個人の 認証情報を持たないエージェントにルーティングしてください。 ペアリングは、送信者によるボットの起動を承認します。その送信者を 独立したホストセキュリティ境界にするものではありません。 ## リバースプロキシのチェック アイデンティティ対応プロキシでは、次を確認してください。 - プロキシは Gateway へ転送する前にユーザーを認証する必要があります。 - ファイアウォールまたはネットワークポリシーは、Gateway ポートへの直接アクセスをブロックする必要があります。 - `gateway.trustedProxies` には、プロキシの送信元 IP のみを列挙する必要があります。 - プロキシは、クライアントから提供されたアイデンティティヘッダーおよび転送 ヘッダーを削除または上書きする必要があります。 - プロキシが複数の対象者にサービスを提供する場合は、 `gateway.auth.trustedProxy.allowUsers` を設定してください。 - `gateway.auth.trustedProxy.allowLoopback` は、ローカルプロセスが信頼され、 プロキシがアイデンティティヘッダーを所有する同一ホスト上のプロキシにのみ使用してください。 プロキシを変更した後は `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 が過度に公開されている可能性がある場合は、次のように設定してください。 ```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 は local loopback のみに維持されている。 - local loopback 以外からのアクセスには、認証とファイアウォール制御があり、公開された直接ルートがない。 - 信頼済みプロキシのデプロイでは、プロキシ IP とヘッダー制御が厳格に設定されている。 - DM は、デフォルトでオープンアクセスにせず、ペアリングまたは許可リストを使用している。 - グループでは、メンションまたは明示的な許可リストが必須になっている。 - 共有チャネルから個人の認証情報へ到達できない。 - 非メインセッションがサンドボックスモードで実行されている。 - ホストでの exec と昇格ツールが拒否されるか、承認を必須としている。 - ログでシークレットが秘匿化されている。 - 重大な監査検出事項が解決されている。 - ロールバック手順がテストされ、文書化されている。