Gateway 公開手順書

​

公開パターンを選択する

​

事前インベントリ

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

​

ベースラインチェック

openclaw doctor
openclaw security audit
openclaw security audit --deep
openclaw health

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

​

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

{
  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 },
  },
}

​

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 は、ローカルプロセスが信頼され、 プロキシがアイデンティティヘッダーを所有する同一ホスト上のプロキシにのみ使用してください。

​

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

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

​

変更後の検証

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

​

ロールバック計画

{
  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 と昇格ツールが拒否されるか、承認を必須としている。
• ログでシークレットが秘匿化されている。
• 重大な監査検出事項が解決されている。
• ロールバック手順がテストされ、文書化されている。