> ## Documentation Index > Fetch the complete documentation index at: https://openclawdoc.org/llms.txt > Use this file to discover all available pages before exploring further. > 単一オペレーター前提の信頼境界、監査チェック、認証情報保護、プロキシ設定、サンドボックス、インシデント対応まで網羅します。 # セキュリティ > \[!WARNING] > **パーソナルアシスタントの信頼モデル:** 本ガイドは、ゲートウェイごとに 1 つの信頼できるオペレーター境界があることを前提としています（単一ユーザー / パーソナルアシスタントモデル）。 > OpenClaw は、複数の敵対的ユーザーが 1 つのエージェント / ゲートウェイを共有する状況における、対敵対的マルチテナントのセキュリティ境界としては設計されていません。 > 信頼レベルが混在する運用や敵対的ユーザーを扱う必要がある場合は、信頼境界を分割してください（ゲートウェイと認証情報を分け、可能であれば OS ユーザーやホストも分けてください）。 ## まず確認すること: パーソナルアシスタントのセキュリティモデル OpenClaw のセキュリティガイダンスは、**パーソナルアシスタント**としての導入を前提にしています。すなわち、1 つの信頼できるオペレーター境界の下に、複数のエージェントが存在し得るというモデルです。 * サポート対象のセキュリティ前提は、ゲートウェイごとに 1 ユーザー / 1 信頼境界であることです。境界ごとに 1 つの OS ユーザー / ホスト / VPS を推奨します。 * 相互に信頼できないユーザーや敵対的ユーザーが 1 つの共有ゲートウェイ / エージェントを使うことは、サポート対象のセキュリティ境界ではありません。 * 敵対的ユーザー間の隔離が必要な場合は、信頼境界ごとに分離してください。ゲートウェイと認証情報を分け、可能であれば OS ユーザーやホストも分けてください。 * 複数の信頼できないユーザーが、ツール有効な 1 つのエージェントにメッセージを送れる場合、それらのユーザーはそのエージェントに委任された同一のツール権限を共有しているものとして扱います。 このページで扱うのは、**このモデルの中で**どのように堅牢化するかです。1 つの共有ゲートウェイ上で対敵対的マルチテナント隔離を提供するものではありません。 ## クイックチェック: `openclaw security audit` 関連項目: [Formal Verification (Security Models)](/security/formal-verification/) 次のコマンドは定期的に実行してください。特に、設定を変更した後やネットワーク公開面を広げた後は必須です。 ```bash theme={"theme":{"light":"min-light","dark":"min-dark"}} openclaw security audit openclaw security audit --deep openclaw security audit --fix openclaw security audit --json ``` この監査では、ありがちな危険設定を検出します。例として、ゲートウェイ認証の露出、ブラウザ制御の露出、昇格ツールの許可リスト、ファイルシステム権限などがあります。 OpenClaw は製品であると同時に実験的な側面も持ちます。最先端モデルの挙動を、実際のメッセージング面や実ツールに接続するためです。**「完全に安全な」構成は存在しません。** 重要なのは、次の点を意識的に設計することです。 * 誰がボットに話しかけられるか * ボットがどこで動作できるか * ボットが何に触れられるか まずは機能する最小限の権限から始め、信頼が持てる範囲だけ段階的に広げてください。 ## デプロイ時の前提（重要） OpenClaw は、ホストと設定の境界が信頼されていることを前提としています。 * 誰かがゲートウェイホストの状態や設定（`~/.openclaw`、`openclaw.json` を含む）を変更できるなら、その人物は信頼されたオペレーターとして扱います。 * 相互に信頼できない、あるいは敵対的な複数のオペレーターのために 1 つのゲートウェイを共有する構成は、**推奨されません**。 * 信頼レベルが混在するチームでは、個別のゲートウェイで信頼境界を分離してください。最低でも OS ユーザーやホストを分けてください。 * OpenClaw は 1 台のマシン上で複数のゲートウェイインスタンスを動かせますが、推奨運用は信頼境界を明確に分離することです。 * 推奨される標準形は、1 台のマシン / ホスト（または VPS）に 1 ユーザー、そのユーザーに 1 ゲートウェイ、そのゲートウェイに 1 つ以上のエージェントという構成です。 * 複数のユーザーが OpenClaw を利用する場合は、ユーザーごとに 1 台の VPS / ホストを用意してください。 ### 実務上の帰結（オペレーターの信頼境界） 1 つのゲートウェイインスタンス内では、認証済みオペレーターのアクセスは、ユーザー別テナントではなく、信頼されたコントロールプレーン権限として扱われます。 * 読み取り / コントロールプレーン権限を持つオペレーターは、設計上、ゲートウェイのセッションメタデータや履歴を閲覧できます。 * セッション識別子（`sessionKey`、セッション ID、ラベル）は、認可トークンではなくルーティング用セレクターです。 * たとえば `sessions.list`、`sessions.preview`、`chat.history` のようなメソッドに対して、オペレーターごとの隔離を期待することは、このモデルの対象外です。 * 敵対的ユーザー間の隔離が必要なら、信頼境界ごとに個別のゲートウェイを運用してください。 * 1 台のマシン上に複数のゲートウェイを置くこと自体は技術的に可能ですが、マルチユーザー隔離の推奨ベースラインではありません。 ## パーソナルアシスタントモデル（マルチテナントバスではない） OpenClaw は、1 つの信頼できるオペレーター境界の下に複数のエージェントが存在し得る、パーソナルアシスタントのセキュリティモデルとして設計されています。 * 複数人が同じツール有効エージェントにメッセージできるなら、その全員が同じ権限セットを間接的に操作できます。 * ユーザーごとのセッション / メモリ分離はプライバシーには有効ですが、共有エージェントをユーザー別のホスト認可境界に変えるものではありません。 * ユーザー同士が互いに敵対的になり得るなら、信頼境界ごとに別々のゲートウェイ、または OS ユーザー / ホストを用意してください。 ### 共有 Slack ワークスペース: 現実的なリスク 「Slack の全員がボットにメッセージできる」構成で本質的なリスクになるのは、委任されたツール権限です。 * 許可された送信者は誰でも、エージェントのポリシー範囲内でツール呼び出し（`exec`、ブラウザ、ネットワーク / ファイルツール）を誘発できます。 * 1 人の送信者によるプロンプト / コンテンツインジェクションで、共有状態、デバイス、出力に影響する動作が引き起こされる可能性があります。 * 1 つの共有エージェントが機密認証情報やファイルにアクセスできる場合、許可された送信者なら誰でも、ツール経由で情報持ち出しを誘発できる可能性があります。 チーム向けワークフローでは、最小限のツールだけを持つ別個のエージェント / ゲートウェイを使い、個人データを扱うエージェントは非公開のままにしてください。 ### 会社共有エージェント: 許容できるパターン このパターンが許容できるのは、そのエージェントを使う全員が同一の信頼境界に属し（たとえば 1 つの社内チーム）、かつエージェントの用途が厳密に業務用に限定されている場合です。 * 専用のマシン / VM / コンテナで動かしてください。 * そのランタイムには専用の OS ユーザーと専用のブラウザ / プロファイル / アカウントを使ってください。 * 個人の Apple / Google アカウントや、個人のパスワードマネージャー / ブラウザプロファイルをそのランタイムにサインインさせないでください。 同じランタイムで個人用と会社用の ID を混在させると、分離が崩れ、個人データ露出のリスクが高まります。 ## ゲートウェイとノードの信頼概念 ゲートウェイとノードは、役割の異なる 1 つのオペレーター信頼ドメインとして扱います。 * **ゲートウェイ**はコントロールプレーンであり、ポリシー面（`gateway.auth`、ツールポリシー、ルーティング）を担います。 * **ノード**はそのゲートウェイとペアリングされたリモート実行面です。コマンド実行、デバイス操作、ホストローカル機能を担います。 * ゲートウェイに認証された呼び出し元は、ゲートウェイスコープでは信頼されます。ペアリング後のノード動作は、そのノード上の信頼されたオペレーター動作として扱われます。 * `sessionKey` はルーティング / コンテキスト選択用であり、ユーザー別認証ではありません。 * 実行承認（許可リスト + ask）は、敵対的マルチテナント隔離ではなく、オペレーター意図のガードレールです。 敵対的ユーザーを隔離したい場合は、OS ユーザー / ホストごとに信頼境界を分け、別々のゲートウェイを運用してください。 ## 信頼境界マトリクス リスク評価時のクイックモデルとして、次の表を参照してください。 | 境界または制御 | 意味 | よくある誤解 | | ------------------------------------- | ------------------------------- | ------------------------------------- | | `gateway.auth`（トークン / パスワード / デバイス認証） | ゲートウェイ API の呼び出し元を認証する | 「安全性のためには全フレームにメッセージ単位の署名が必要」 | | `sessionKey` | コンテキスト / セッション選択用のルーティングキー | 「セッションキーはユーザー認証境界」 | | プロンプト / コンテンツのガードレール | モデル悪用のリスクを下げる | 「プロンプトインジェクションだけで認証バイパスが証明される」 | | `canvas.eval` / browser evaluate | 有効化されている場合の意図的なオペレーター機能 | 「JS eval の原始機能があるだけでこの信頼モデルでは脆弱性」 | | ローカル TUI の `!` シェル | オペレーターが明示的に起動するローカル実行 | 「ローカルシェルの便利コマンドはリモートインジェクション」 | | ノードのペアリングとノードコマンド | ペアリング済みデバイスに対するオペレーターレベルのリモート実行 | 「リモートデバイス制御は既定で信頼できないユーザーアクセスとして扱うべき」 | ## 設計上、脆弱性ではないもの 次のようなパターンはよく報告されますが、実際に境界バイパスが示されない限り、通常は no-action として扱われます。 * ポリシー / 認証 / サンドボックスのバイパスを伴わない、プロンプトインジェクションのみの連鎖。 * 1 つの共有ホスト / 設定で敵対的マルチテナント運用している前提に基づく主張。 * 共有ゲートウェイ構成で、通常のオペレーター読み取り経路（たとえば `sessions.list` / `sessions.preview` / `chat.history`）を IDOR とみなす主張。 * localhost 専用デプロイに対する指摘（たとえば、ループバック専用ゲートウェイでの HSTS 欠如）。 * このリポジトリに存在しないインバウンドパスに対する Discord inbound webhook 署名の指摘。 * `sessionKey` を認証トークンとみなし、「ユーザー別認可がない」と評価する指摘。 ## 研究者向け事前チェックリスト GHSA を起票する前に、次のすべてを確認してください。 1. 再現手順が最新の `main` または最新リリースで今も成立すること。 2. レポートに、正確なコードパス（`file`、関数、行範囲）と検証したバージョン / コミットが含まれていること。 3. 影響が、文書化された信頼境界をまたいでいること。単なるプロンプトインジェクションでは不十分です。 4. 主張内容が [Out of Scope](https://github.com/openclaw/openclaw/blob/main/SECURITY.md#out-of-scope) に含まれていないこと。 5. 既存アドバイザリとの重複確認が済んでいること。該当する場合は正規の GHSA を再利用してください。 6. デプロイ前提（ループバック / ローカルか、公開されているか。オペレーターが信頼できるかどうか）が明示されていること。 ## 60 秒でできる堅牢化ベースライン まずは次のベースラインを適用し、そのうえで信頼できるエージェントに対してのみ必要なツールを段階的に再有効化してください。 ```json5 theme={"theme":{"light":"min-light","dark":"min-dark"}} { gateway: { mode: "local", bind: "loopback", auth: { mode: "token", token: "replace-with-long-random-token" }, }, session: { dmScope: "per-channel-peer", }, tools: { profile: "messaging", deny: ["group:automation", "group:runtime", "group:fs", "sessions_spawn", "sessions_send"], fs: { workspaceOnly: true }, exec: { security: "deny", ask: "always" }, elevated: { enabled: false }, }, channels: { whatsapp: { dmPolicy: "pairing", groups: { "*": { requireMention: true } } }, }, } ``` この構成では、ゲートウェイはローカル専用に保たれ、DM は分離され、コントロールプレーン / ランタイム系ツールは既定で無効になります。 ## 共有受信トレイのクイックルール 複数人がボットに DM できる場合は、次を守ってください。 * `session.dmScope: "per-channel-peer"` を設定してください。複数アカウント対応チャネルでは `"per-account-channel-peer"` を使います。 * `dmPolicy: "pairing"` または厳格な許可リストを維持してください。 * 共有 DM と広範なツール権限を組み合わせないでください。 * これにより協調的 / 共有受信トレイは堅牢化できますが、ユーザーがホスト / 設定への書き込み権を共有している状況に対する、敵対的共同テナント隔離を提供するものではありません。 ### 監査が確認する項目（概要） * **インバウンドアクセス**（DM ポリシー、グループポリシー、許可リスト）: 見知らぬ相手がボットを起動できるか。 * **ツールの影響半径**（昇格ツール + open な部屋）: プロンプトインジェクションがシェル / ファイル / ネットワーク操作に発展し得るか。 * **ネットワーク露出**（ゲートウェイ bind / auth、Tailscale Serve / Funnel、弱い / 短い認証トークン）。 * **ブラウザ制御の露出**（リモートノード、リレーポート、リモート CDP エンドポイント）。 * **ローカルディスク衛生**（権限、シンボリックリンク、config include、「同期フォルダ」パス）。 * **プラグイン**（明示的な許可リストなしで拡張が存在しないか）。 * **ポリシードリフト / 設定不整合**（サンドボックス Docker 設定があるのにサンドボックスモードが off、`gateway.nodes.denyCommands` が正確なコマンド名一致のみでシェル文字列を検査しないため実効性がない、危険な `gateway.nodes.allowCommands`、グローバル `tools.profile="minimal"` をエージェント単位設定が上書きしている、拡張プラグインツールが寛容なツールポリシー下で到達可能、など）。 * **ランタイム期待値のずれ**（たとえばサンドボックスモードが off のまま `tools.exec.host="sandbox"` が設定され、実際にはゲートウェイホスト上で直接実行される、など）。 * **モデル衛生**（設定モデルがレガシーに見える場合の警告。ハードブロックではありません）。 `--deep` を指定すると、OpenClaw は稼働中ゲートウェイに対して可能な範囲でライブプローブも実施します。 ## 認証情報ストレージマップ アクセス監査やバックアップ対象の判断には、次を参照してください。 * **WhatsApp**: `~/.openclaw/credentials/whatsapp//creds.json` * **Telegram bot token**: 設定 / 環境変数、または `channels.telegram.tokenFile` * **Discord bot token**: 設定 / 環境変数、または SecretRef（env / file / exec プロバイダー） * **Slack トークン**: 設定 / 環境変数（`channels.slack.*`） * **ペアリング許可リスト**: * `~/.openclaw/credentials/-allowFrom.json`（デフォルトアカウント） * `~/.openclaw/credentials/--allowFrom.json`（非デフォルトアカウント） * **モデル認証プロファイル**: `~/.openclaw/agents//agent/auth-profiles.json` * **ファイルバック Secret payload（任意）**: `~/.openclaw/secrets.json` * **レガシー OAuth import**: `~/.openclaw/credentials/oauth.json` ## セキュリティ監査チェックリスト 監査が検出結果を出したら、次の優先順位で扱ってください。 1. **open な設定 + ツール有効**: まず DM / グループを絞り（ペアリング / 許可リスト）、その後にツールポリシー / サンドボックスを締めます。 2. **パブリックネットワーク露出**（LAN bind、Funnel、認証なし）: 直ちに修正してください。 3. **ブラウザ制御のリモート露出**: オペレーターアクセス同等として扱います。tailnet 限定にし、ノードは意図的にペアリングし、公開露出は避けてください。 4. **権限**: 状態 / 設定 / 認証情報 / 認証データが group/world readable になっていないことを確認してください。 5. **プラグイン / 拡張**: 明示的に信頼したものだけを読み込んでください。 6. **モデル選択**: ツール有効ボットには、最新で指示耐性の高いモデルを優先してください。 ## セキュリティ監査用語集 実運用で特によく見る、高シグナルな `checkId` の例です（網羅一覧ではありません）。 | `checkId` | Severity | 重要な理由 | 主な修正キー / パス | Auto-fix | | -------------------------------------------------- | ------------- | -------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | -------- | | `fs.state_dir.perms_world_writable` | critical | 他のユーザー / プロセスが OpenClaw の状態全体を変更できる | `~/.openclaw` のファイルシステム権限 | yes | | `fs.config.perms_writable` | critical | 他者が認証 / ツールポリシー / 設定を変更できる | `~/.openclaw/openclaw.json` のファイルシステム権限 | yes | | `fs.config.perms_world_readable` | critical | 設定ファイルからトークンや設定が漏えいし得る | 設定ファイルのファイルシステム権限 | yes | | `gateway.bind_no_auth` | critical | 共有シークレットなしでリモート bind されている | `gateway.bind`, `gateway.auth.*` | no | | `gateway.loopback_no_auth` | critical | 逆プロキシ越しの loopback が未認証になる可能性がある | `gateway.auth.*`, proxy 設定 | no | | `gateway.http.no_auth` | warn/critical | `auth.mode="none"` でゲートウェイ HTTP API が到達可能 | `gateway.auth.mode`, `gateway.http.endpoints.*` | no | | `gateway.tools_invoke_http.dangerous_allow` | warn/critical | HTTP API 経由で危険なツールを再有効化してしまう | `gateway.tools.allow` | no | | `gateway.nodes.allow_commands_dangerous` | warn/critical | 高影響なノードコマンド（カメラ / 画面 / 連絡先 / カレンダー / SMS）を有効化する | `gateway.nodes.allowCommands` | no | | `gateway.tailscale_funnel` | critical | 公開インターネットに露出する | `gateway.tailscale.mode` | no | | `gateway.control_ui.allowed_origins_required` | critical | 非 loopback の Control UI に、明示的なブラウザ origin 許可リストがない | `gateway.controlUi.allowedOrigins` | no | | `gateway.control_ui.host_header_origin_fallback` | warn/critical | Host header 由来の origin fallback を有効化している（DNS rebinding 緩和を弱める） | `gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback` | no | | `gateway.control_ui.insecure_auth` | warn | insecure-auth 互換トグルが有効 | `gateway.controlUi.allowInsecureAuth` | no | | `gateway.control_ui.device_auth_disabled` | critical | デバイス ID チェックを無効化する | `gateway.controlUi.dangerouslyDisableDeviceAuth` | no | | `gateway.real_ip_fallback_enabled` | warn/critical | `X-Real-IP` fallback を信用すると、proxy 設定ミス時に送信元 IP 偽装を許す | `gateway.allowRealIpFallback`, `gateway.trustedProxies` | no | | `discovery.mdns_full_mode` | warn/critical | mDNS full mode が `cliPath` / `sshPort` メタデータをローカルネットワークに広告する | `discovery.mdns.mode`, `gateway.bind` | no | | `config.insecure_or_dangerous_flags` | warn | 安全でない / 危険なデバッグフラグが有効 | 複数キー（詳細は検出結果参照） | no | | `hooks.token_too_short` | warn | hook 入口に対する総当たり耐性が弱い | `hooks.token` | no | | `hooks.request_session_key_enabled` | warn/critical | 外部呼び出し元が `sessionKey` を選べる | `hooks.allowRequestSessionKey` | no | | `hooks.request_session_key_prefixes_missing` | warn/critical | 外部指定のセッションキー形状に上限がない | `hooks.allowedSessionKeyPrefixes` | no | | `logging.redact_off` | warn | 機密値がログ / ステータスに漏れる | `logging.redactSensitive` | yes | | `sandbox.docker_config_mode_off` | warn | サンドボックス Docker 設定はあるが非アクティブ | `agents.*.sandbox.mode` | no | | `sandbox.dangerous_network_mode` | critical | サンドボックス Docker ネットワークが `host` や `container:*` 名前空間結合を使っている | `agents.*.sandbox.docker.network` | no | | `tools.exec.host_sandbox_no_sandbox_defaults` | warn | サンドボックス off 時に `exec host=sandbox` がホスト実行に解決される | `tools.exec.host`, `agents.defaults.sandbox.mode` | no | | `tools.exec.host_sandbox_no_sandbox_agents` | warn | エージェント単位の `exec host=sandbox` が、サンドボックス off 時にホスト実行に解決される | `agents.list[].tools.exec.host`, `agents.list[].sandbox.mode` | no | | `tools.exec.safe_bins_interpreter_unprofiled` | warn | `safeBins` にインタープリタ / ランタイムがあり、明示プロファイルなしで exec リスクが広がる | `tools.exec.safeBins`, `tools.exec.safeBinProfiles`, `agents.list[].tools.exec.*` | no | | `skills.workspace.symlink_escape` | warn | workspace `skills/**/SKILL.md` が workspace ルート外に解決される（symlink 連鎖の逸脱） | workspace `skills/**` のファイルシステム状態 | no | | `security.exposure.open_groups_with_elevated` | critical | open グループ + 昇格ツールで高影響なプロンプトインジェクション経路ができる | `channels.*.groupPolicy`, `tools.elevated.*` | no | | `security.exposure.open_groups_with_runtime_or_fs` | critical/warn | open グループが、サンドボックス / workspace ガードなしでコマンド / ファイルツールに到達できる | `channels.*.groupPolicy`, `tools.profile/deny`, `tools.fs.workspaceOnly`, `agents.*.sandbox.mode` | no | | `security.trust_model.multi_user_heuristic` | warn | 設定がマルチユーザーに見える一方、ゲートウェイ信頼モデルはパーソナルアシスタント前提 | 信頼境界分離、または共有ユーザー向け堅牢化（`sandbox.mode`、tool deny、workspace scoping） | no | | `tools.profile_minimal_overridden` | warn | エージェント上書きがグローバル minimal profile を回避している | `agents.list[].tools.profile` | no | | `plugins.tools_reachable_permissive_policy` | warn | 寛容なポリシー下で拡張ツールに到達できる | `tools.profile` + tool allow / deny | no | | `models.small_params` | critical/info | 小さなモデル + 危険なツール面の組み合わせで注入耐性が下がる | モデル選択 + サンドボックス / ツールポリシー | no | ## HTTP 経由の Control UI Control UI がデバイス ID を生成するには、**安全なコンテキスト**（HTTPS または localhost）が必要です。`gateway.controlUi.allowInsecureAuth` は、安全なコンテキスト、デバイス ID、デバイスペアリングの各チェックを**回避しません**。HTTPS（Tailscale Serve など）を使うか、`127.0.0.1` で UI を開くことを推奨します。 緊急退避用途に限り、`gateway.controlUi.dangerouslyDisableDeviceAuth` を使うとデバイス ID チェックを完全に無効化できます。これは重大なセキュリティ低下なので、積極的にデバッグしていて短時間で元に戻せる場合を除き、無効のままにしてください。 `openclaw security audit` は、この設定が有効だと警告を出します。 ## 安全でない / 危険なフラグのまとめ `openclaw security audit` は、既知の安全でない / 危険なデバッグスイッチが有効な場合、`config.insecure_or_dangerous_flags` を出力します。現在このチェックで集約されるものは次のとおりです。 * `gateway.controlUi.allowInsecureAuth=true` * `gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback=true` * `gateway.controlUi.dangerouslyDisableDeviceAuth=true` * `hooks.gmail.allowUnsafeExternalContent=true` * `hooks.mappings[].allowUnsafeExternalContent=true` * `tools.exec.applyPatch.workspaceOnly=false` OpenClaw の設定スキーマ内で定義されている、完全な `dangerous*` / `dangerously*` キーは次のとおりです。 * `gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback` * `gateway.controlUi.dangerouslyDisableDeviceAuth` * `browser.ssrfPolicy.dangerouslyAllowPrivateNetwork` * `channels.discord.dangerouslyAllowNameMatching` * `channels.discord.accounts..dangerouslyAllowNameMatching` * `channels.slack.dangerouslyAllowNameMatching` * `channels.slack.accounts..dangerouslyAllowNameMatching` * `channels.googlechat.dangerouslyAllowNameMatching` * `channels.googlechat.accounts..dangerouslyAllowNameMatching` * `channels.msteams.dangerouslyAllowNameMatching` * `channels.irc.dangerouslyAllowNameMatching`（拡張チャネル） * `channels.irc.accounts..dangerouslyAllowNameMatching`（拡張チャネル） * `channels.mattermost.dangerouslyAllowNameMatching`（拡張チャネル） * `channels.mattermost.accounts..dangerouslyAllowNameMatching`（拡張チャネル） * `agents.defaults.sandbox.docker.dangerouslyAllowReservedContainerTargets` * `agents.defaults.sandbox.docker.dangerouslyAllowExternalBindSources` * `agents.defaults.sandbox.docker.dangerouslyAllowContainerNamespaceJoin` * `agents.list[].sandbox.docker.dangerouslyAllowReservedContainerTargets` * `agents.list[].sandbox.docker.dangerouslyAllowExternalBindSources` * `agents.list[].sandbox.docker.dangerouslyAllowContainerNamespaceJoin` ## リバースプロキシ設定 ゲートウェイをリバースプロキシ（nginx、Caddy、Traefik など）の背後で動かす場合は、クライアント IP を正しく判定するために `gateway.trustedProxies` を設定してください。 ゲートウェイは、`trustedProxies` に含まれないアドレスから proxy ヘッダーが届いても、その接続をローカルクライアントとは扱いません。ゲートウェイ認証が無効なら、その接続は拒否されます。これにより、proxy 越し接続が localhost 由来に見えて自動的に信頼されるような認証バイパスを防ぎます。 ```yaml theme={"theme":{"light":"min-light","dark":"min-dark"}} gateway: trustedProxies: - "127.0.0.1" # proxy が localhost で動く場合 # 任意。既定値は false。 # proxy が X-Forwarded-For を付与できない場合のみ有効化してください。 allowRealIpFallback: false auth: mode: password password: ${OPENCLAW_GATEWAY_PASSWORD} ``` `trustedProxies` を設定すると、ゲートウェイは `X-Forwarded-For` を使ってクライアント IP を判定します。`X-Real-IP` は既定では無視され、`gateway.allowRealIpFallback: true` を明示した場合に限り使われます。 望ましいリバースプロキシ動作（受信した forwarding ヘッダーを上書きする）: ```nginx theme={"theme":{"light":"min-light","dark":"min-dark"}} proxy_set_header X-Forwarded-For $remote_addr; proxy_set_header X-Real-IP $remote_addr; ``` 望ましくないリバースプロキシ動作（信用できない forwarding ヘッダーを追記 / 保持する）: ```nginx theme={"theme":{"light":"min-light","dark":"min-dark"}} proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; ``` ## HSTS と origin に関する注意 * OpenClaw ゲートウェイは、まずローカル / ループバック前提です。TLS をリバースプロキシで終端するなら、その HTTPS ドメイン側で HSTS を設定してください。 * ゲートウェイ自身が HTTPS を終端する場合は、`gateway.http.securityHeaders.strictTransportSecurity` を設定すれば、OpenClaw のレスポンスに HSTS ヘッダーを出せます。 * 詳細なデプロイガイドは [Trusted Proxy Auth](/gateway/trusted-proxy-auth#tls-termination-and-hsts) にあります。 * 非 loopback の Control UI 配備では、既定で `gateway.controlUi.allowedOrigins` が必須です。 * `gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback=true` は Host header 起点の origin fallback モードを有効にします。危険なオペレーター選択ポリシーとして扱ってください。 * DNS rebinding と proxy の Host header 振る舞いは、デプロイ堅牢化の論点として扱ってください。`trustedProxies` は最小限に絞り、ゲートウェイをパブリックインターネットへ直接露出しないでください。 ## ローカルのセッションログはディスクに保存される OpenClaw は、セッショントランスクリプトを `~/.openclaw/agents//sessions/*.jsonl` に保存します。 これはセッション継続性と、必要に応じたセッションメモリ索引付けのために必要ですが、同時に **ファイルシステムアクセスを持つ任意のプロセス / ユーザーが、そのログを読める**ことも意味します。 ディスクアクセス自体を信頼境界として扱い、`~/.openclaw` の権限を厳格にしてください（下記の監査節も参照）。 エージェント間でより強い分離が必要なら、別々の OS ユーザーまたは別ホストで運用してください。 ## ノード実行（`system.run`） macOS ノードがペアリングされている場合、ゲートウェイはそのノード上で `system.run` を呼び出せます。これは Mac 上での **リモートコード実行** です。 * ノードペアリング（承認 + トークン）が必要です。 * Mac 側では **Settings → Exec approvals** で制御します（security + ask + allowlist）。 * リモート実行を許可したくないなら、security を **deny** に設定し、その Mac のノードペアリングを解除してください。 ## 動的スキル（watcher / リモートノード） OpenClaw は、セッション途中でスキル一覧を更新できます。 * **Skills watcher**: `SKILL.md` の変更は、次のエージェントターンでスキルスナップショットに反映され得ます。 * **Remote nodes**: macOS ノードを接続すると、bin probe に基づいて macOS 専用スキルが利用候補になります。 スキルフォルダは **信頼済みコード** として扱い、変更できる人を厳格に制限してください。 ## 脅威モデル AI アシスタントには次の能力があります。 * 任意のシェルコマンドを実行できる * ファイルを読み書きできる * ネットワークサービスへアクセスできる * WhatsApp アクセスを与えれば、誰にでもメッセージを送れる あなたにメッセージする相手には次のことができます。 * AI をだまして危険な操作をさせようとする * データへのアクセスを社会的に誘導しようとする * インフラの詳細を探ろうとする ## コア概念: 知能より先にアクセス制御 ここで起きる失敗の多くは、高度なエクスプロイトではありません。単に「誰かがボットに頼み、ボットがその通りにやった」というものです。 OpenClaw の基本姿勢は次のとおりです。 * **まず本人性**: 誰がボットに話しかけられるかを決める（DM ペアリング / 許可リスト / 明示的な `open`）。 * **次にスコープ**: ボットがどこで動けるかを決める（グループ許可リスト + mention 制御、ツール、サンドボックス、デバイス権限）。 * **最後にモデル**: モデルは操作され得る前提で考え、操作されても影響範囲が限定されるように設計する。 ## コマンド認可モデル スラッシュコマンドと各種ディレクティブは、**認可された送信者**に対してのみ有効です。認可は、チャネルの許可リスト / ペアリングと `commands.useAccessGroups` から導かれます（[Configuration](/gateway/configuration) と [Slash commands](/tools/slash-commands) を参照してください）。チャネル許可リストが空、または `"*"` を含む場合、そのチャネルではコマンドが事実上 open になります。 `/exec` は、認可済みオペレーター向けのセッション限定の簡易機能です。設定を書き換えたり、他セッションを変更したりはしません。 ## コントロールプレーンツールのリスク 組み込みツールのうち、永続的なコントロールプレーン変更を起こせるものが 2 つあります。 * `gateway`: `config.apply`、`config.patch`、`update.run` を呼び出せます。 * `cron`: 元の会話 / タスク終了後も動き続けるスケジュールジョブを作れます。 信頼できないコンテンツを扱うエージェント / 面では、これらを既定で拒否してください。 ```json5 theme={"theme":{"light":"min-light","dark":"min-dark"}} { tools: { deny: ["gateway", "cron", "sessions_spawn", "sessions_send"], }, } ``` `commands.restart=false` は restart アクションを止めるだけです。`gateway` による config / update 操作までは無効化しません。 ## プラグイン / 拡張 プラグインは、ゲートウェイ **同一プロセス内**で動きます。信頼済みコードとして扱ってください。 * 信頼できる提供元のプラグインだけを導入してください。 * `plugins.allow` のような明示的許可リストを推奨します。 * 有効化前にプラグイン設定を確認してください。 * プラグイン変更後はゲートウェイを再起動してください。 * npm からプラグインを入れる場合（`openclaw plugins install `）は、未信頼コードを実行するのと同じだと考えてください。 * インストール先は `~/.openclaw/extensions//`（または `$OPENCLAW_STATE_DIR/extensions//`）です。 * OpenClaw は `npm pack` を使い、そのディレクトリで `npm install --omit=dev` を実行します（npm lifecycle script はインストール中にコード実行できます）。 * バージョンは固定指定（`@scope/pkg@1.2.3`）を推奨し、有効化前に展開済みコードをディスク上で確認してください。 詳細: [Plugins](/tools/plugin) ## DM アクセスモデル（pairing / allowlist / open / disabled） 現在 DM を扱えるすべてのチャネルは、メッセージ処理**前**にインバウンド DM を制御する DM ポリシー（`dmPolicy` または `*.dm.policy`）を持ちます。 * `pairing`（既定）: 未知の送信者には短いペアリングコードを返し、承認されるまでそのメッセージは無視します。コードの有効期限は 1 時間です。同じ相手が繰り返し DM しても、新しい要求が作られるまではコードを再送しません。保留中要求の上限は、既定で **チャネルごとに 3 件**です。 * `allowlist`: 未知の送信者を遮断します（ペアリングハンドシェイクなし）。 * `open`: 誰でも DM 可能にします（公開）。**チャネル許可リストに `"*"` を含める明示的 opt-in が必要です。** * `disabled`: インバウンド DM を完全に無視します。 CLI から承認するには次を使います。 ```bash theme={"theme":{"light":"min-light","dark":"min-dark"}} openclaw pairing list openclaw pairing approve ``` 詳細とディスク上のファイル: [Pairing](/channels/pairing) ## DM セッション分離（マルチユーザーモード） 既定では、OpenClaw は **すべての DM をメインセッションに流し込む**ため、デバイスやチャネルをまたいでアシスタントの継続性が保たれます。**複数人**がボットへ DM できる場合（open DM や複数人の許可リスト）は、DM セッションを分離することを検討してください。 ```json5 theme={"theme":{"light":"min-light","dark":"min-dark"}} { session: { dmScope: "per-channel-peer" }, } ``` これにより、グループチャット分離を維持しつつ、ユーザー間のコンテキスト漏れを防げます。 これはメッセージング上のコンテキスト境界であり、ホスト管理境界ではありません。ユーザー同士が互いに敵対的で、しかも同じゲートウェイホスト / 設定を共有するなら、信頼境界ごとに別ゲートウェイを運用してください。 ### セキュア DM モード（推奨） 上の設定断片は **secure DM mode** と考えてください。 * 既定値: `session.dmScope: "main"`（すべての DM が継続性のため 1 つのセッションを共有） * ローカル CLI オンボーディングの既定: 未設定時に `session.dmScope: "per-channel-peer"` を書き込みます（明示設定済みの値は保持） * Secure DM mode: `session.dmScope: "per-channel-peer"`（チャネル + 送信者ごとに DM コンテキストを分離） 同じチャネルで複数アカウントを運用しているなら、代わりに `per-account-channel-peer` を使ってください。同一人物が複数チャネルから連絡してくる場合は、`session.identityLinks` を使ってそれらの DM セッションを 1 つの正規 ID にまとめられます。詳細は [Session Management](/concepts/session) と [Configuration](/gateway/configuration) を参照してください。 ## 許可リスト（DM + グループ）: 用語整理 OpenClaw には、「誰が bot を起動できるか」を決める層が 2 つあります。 * **DM 許可リスト**（`allowFrom` / `channels.discord.allowFrom` / `channels.slack.allowFrom`; legacy: `channels.discord.dm.allowFrom`, `channels.slack.dm.allowFrom`）: ダイレクトメッセージで bot に話しかけられる相手を決めます。 * `dmPolicy="pairing"` のとき、承認情報は `~/.openclaw/credentials/` 以下のアカウントスコープなペアリング許可リストストアに書き込まれます（デフォルトアカウントは `-allowFrom.json`、非デフォルトアカウントは `--allowFrom.json`）。この内容は設定ファイル上の許可リストとマージされます。 * **グループ許可リスト**（チャネル固有）: bot がどのグループ / チャネル / guild からのメッセージを受け付けるかを決めます。 * よくあるパターン: * `channels.whatsapp.groups`, `channels.telegram.groups`, `channels.imessage.groups`: `requireMention` などのグループ単位既定値。これを設定するとグループ許可リストとしても機能します（全許可を維持したいなら `"*"` を含めます）。 * `groupPolicy="allowlist"` + `groupAllowFrom`: グループセッション内で bot を起動できる送信者を制限します（WhatsApp / Telegram / Signal / iMessage / Microsoft Teams）。 * `channels.discord.guilds` / `channels.slack.channels`: 面単位の許可リスト + mention 既定値。 * グループ判定の順序は、まず `groupPolicy` / グループ許可リスト、その次に mention / reply による起動条件です。 * bot メッセージへの返信（暗黙 mention）は、`groupAllowFrom` のような送信者許可リストを回避しません。 * **セキュリティ注意**: `dmPolicy="open"` と `groupPolicy="open"` は最後の手段として扱ってください。使用は極力避け、完全に全員を信頼する部屋でなければ pairing + 許可リストを使ってください。 詳細: [Configuration](/gateway/configuration) と [Groups](/channels/groups) ## プロンプトインジェクション（何か、なぜ重要か） プロンプトインジェクションとは、攻撃者がメッセージを細工し、モデルに危険な行動をさせることです（「指示を無視しろ」「ファイルシステムを吐き出せ」「このリンクを開いてコマンドを実行しろ」など）。 強いシステムプロンプトがあっても、**プロンプトインジェクション問題は未解決です**。システムプロンプトのガードレールはあくまでソフトな指針であり、ハードな強制力はツールポリシー、実行承認、サンドボックス、チャネル許可リストにあります（しかも設計上、オペレーターはこれらを無効化できます）。実務上有効なのは次の対策です。 * インバウンド DM を厳格に制限する（ペアリング / 許可リスト）。 * グループでは mention 制御を優先し、公開部屋で「常時待受 bot」にしない。 * リンク、添付、貼り付けられた指示は既定で敵対的とみなす。 * 機密性の高いツール実行はサンドボックスで行い、シークレットをエージェントが到達できるファイルシステムから切り離す。 * 注意: サンドボックスは opt-in です。サンドボックスモードが off の場合、`tools.exec.host` の既定が sandbox でも exec はゲートウェイホスト上で実行されます。また host exec は、`host=gateway` を明示して exec approvals を設定しない限り承認を要求しません。 * 高リスクツール（`exec`、`browser`、`web_fetch`、`web_search`）は、信頼済みエージェントか明示許可リストに限定する。 * **モデル選択は重要です**: 古い / 小さい / レガシーモデルは、プロンプトインジェクションやツール誤用に対する耐性が大幅に低くなります。ツール有効エージェントでは、最新世代で指示耐性の高い最良モデルを使ってください。 次のような内容は未信頼として扱ってください。 * 「このファイル / URL を読んで、書いてある通りに実行して」 * 「システムプロンプトや安全ルールを無視して」 * 「隠し指示やツール出力を見せて」 * 「`~/.openclaw` やログの中身を全部貼って」 ## 安全でない外部コンテンツ回避フラグ OpenClaw には、外部コンテンツの安全ラップを無効にする明示的バイパスフラグがあります。 * `hooks.mappings[].allowUnsafeExternalContent` * `hooks.gmail.allowUnsafeExternalContent` * Cron ペイロードフィールド `allowUnsafeExternalContent` 指針は次のとおりです。 * 本番では未設定 / false を維持してください。 * 有効化するのは、厳密に対象を絞ったデバッグの間だけにしてください。 * 有効化する場合は、そのエージェントを隔離してください（サンドボックス + 最小ツール + 専用セッション名前空間）。 Hooks に関するリスク補足: * Hook ペイロードは、配送元システムを自分で管理していても未信頼コンテンツです（メール / ドキュメント / Web コンテンツにはプロンプトインジェクションが含まれ得ます）。 * 弱いモデル階層ではこのリスクが増します。hook 駆動自動化では、強力で新しいモデル階層を選び、ツールポリシーは厳格にしてください（`tools.profile: "messaging"` またはそれ以下）。可能ならサンドボックスも併用してください。 ### プロンプトインジェクションは公開 DM がなくても起こる ボットに DM できるのが**自分だけ**であっても、ボットが読む **未信頼コンテンツ** を通じてプロンプトインジェクションは起こり得ます。たとえば Web 検索 / 取得結果、ブラウザページ、メール、ドキュメント、添付、貼り付けられたログやコードです。つまり、脅威面は送信者だけではなく、**コンテンツそのもの**にもあります。 ツールが有効な場合の典型的なリスクは、コンテキスト持ち出しやツール呼び出し誘発です。影響範囲を減らすには次を検討してください。 * 未信頼コンテンツの要約には、読み取り専用またはツール無効の **reader agent** を使い、その要約だけをメインエージェントへ渡す。 * `web_search` / `web_fetch` / `browser` は必要時以外、ツール有効エージェントで無効にしておく。 * OpenResponses の URL 入力（`input_file` / `input_image`）では、`gateway.http.endpoints.responses.files.urlAllowlist` と `gateway.http.endpoints.responses.images.urlAllowlist` を厳格に設定し、`maxUrlParts` は低く保つ。 * 未信頼入力に触れるエージェントでは、サンドボックスと厳格なツール許可リストを有効化する。 * シークレットをプロンプトに埋め込まず、ゲートウェイホスト上の env / 設定経由で渡す。 ### モデル強度（セキュリティ注記） プロンプトインジェクション耐性は、モデル階層間で**均一ではありません**。小型 / 低コストモデルほど、敵対的プロンプト下でのツール誤用や指示乗っ取りに弱い傾向があります。 ツール有効エージェントや未信頼コンテンツを読むエージェントでは、古い / 小さいモデルのプロンプトインジェクションリスクが高すぎる場合があります。そのようなワークロードを弱いモデル階層で動かさないでください。 推奨事項: * ツール実行やファイル / ネットワークアクセスがある bot には、**最新世代で最上位クラスのモデル**を使ってください。 * ツール有効エージェントや未信頼 inbox に対して、**古い / 弱い / 小さいモデル**は使わないでください。プロンプトインジェクションリスクが高すぎます。 * やむを得ず小さいモデルを使うなら、**影響範囲を削ってください**（読み取り専用ツール、強いサンドボックス、最小限のファイルシステムアクセス、厳格な許可リスト）。 * 小型モデル運用時は、**全セッションでサンドボックスを有効化し**、入力が厳格に制御されていない限り **`web_search` / `web_fetch` / `browser` を無効化**してください。 * trusted input だけを扱い、ツールもない chat-only の個人アシスタントであれば、小型モデルでも通常は問題ありません。 ## グループでの reasoning / verbose 出力 `/reasoning` と `/verbose` は、本来パブリックチャネル向けではない内部推論やツール出力を露出させる可能性があります。グループでは **デバッグ専用** と考え、明示的に必要な場合を除いて無効のままにしてください。 指針: * 公開ルームでは `/reasoning` と `/verbose` を無効に保つ。 * 有効化するなら、信頼できる DM か厳格に管理された部屋に限定する。 * verbose 出力には、ツール引数、URL、モデルが参照したデータが含まれ得ることを忘れない。 ## 設定の堅牢化（例） ### 0) ファイル権限 ゲートウェイホスト上では、設定と状態を非公開に保ってください。 * `~/.openclaw/openclaw.json`: `600`（ユーザーのみ読み書き） * `~/.openclaw`: `700`（ユーザーのみ） `openclaw doctor` は、これらの権限を警告し、必要なら強化を提案できます。 ### 0.4) ネットワーク露出（bind + port + firewall） ゲートウェイは **WebSocket + HTTP** を 1 つのポートで多重化します。 * 既定値: `18789` * 設定 / フラグ / 環境変数: `gateway.port`, `--port`, `OPENCLAW_GATEWAY_PORT` この HTTP 面には、Control UI と canvas host が含まれます。 * Control UI（SPA assets）（既定ベースパス `/`） * Canvas host: `/__openclaw__/canvas/` と `/__openclaw__/a2ui/`（任意の HTML / JS。未信頼コンテンツとして扱ってください） 通常のブラウザで canvas コンテンツを開く場合は、一般的な未信頼 Web ページと同じように扱ってください。 * canvas host を未信頼なネットワーク / ユーザーへ露出しない。 * 影響を理解していない限り、canvas コンテンツを特権的な Web 面と同一 origin で共有しない。 bind モードは、ゲートウェイがどこで待ち受けるかを決めます。 * `gateway.bind: "loopback"`（既定）: ローカルクライアントのみ接続可能。 * 非 loopback bind（`"lan"`、`"tailnet"`、`"custom"`）は攻撃面を拡大します。共有トークン / パスワードと実際の firewall を組み合わせる場合にのみ使ってください。 経験則: * LAN bind より Tailscale Serve を優先してください（Serve ならゲートウェイは loopback のまま、アクセス制御は Tailscale が担います）。 * やむを得ず LAN bind するなら、port を厳密な送信元 IP 許可リストで firewall してください。広範な port-forward は避けてください。 * 認証なしのまま `0.0.0.0` にゲートウェイを露出してはいけません。 ### 0.4.1) Docker のポート公開 + UFW（`DOCKER-USER`） VPS 上で Docker を使って OpenClaw を動かす場合、公開されたコンテナポート （`-p HOST:CONTAINER` や Compose の `ports:`）は、ホストの `INPUT` ルールだけでなく Docker の forwarding chain も通ります。 Docker トラフィックを firewall ポリシーと整合させるには、`DOCKER-USER` でルールを強制してください （この chain は Docker 自身の accept ルールより先に評価されます）。 近年の多くのディストリビューションでは、`iptables` / `ip6tables` は `iptables-nft` フロントエンドを使いますが、これらのルールは nftables backend にも適用されます。 最小許可リスト例（IPv4）: ```bash theme={"theme":{"light":"min-light","dark":"min-dark"}} # /etc/ufw/after.rules （独立した *filter セクションとして追記） *filter :DOCKER-USER - [0:0] -A DOCKER-USER -m conntrack --ctstate ESTABLISHED,RELATED -j RETURN -A DOCKER-USER -s 127.0.0.0/8 -j RETURN -A DOCKER-USER -s 10.0.0.0/8 -j RETURN -A DOCKER-USER -s 172.16.0.0/12 -j RETURN -A DOCKER-USER -s 192.168.0.0/16 -j RETURN -A DOCKER-USER -s 100.64.0.0/10 -j RETURN -A DOCKER-USER -p tcp --dport 80 -j RETURN -A DOCKER-USER -p tcp --dport 443 -j RETURN -A DOCKER-USER -m conntrack --ctstate NEW -j DROP -A DOCKER-USER -j RETURN COMMIT ``` IPv6 は別テーブルです。Docker IPv6 が有効なら、`/etc/ufw/after6.rules` に対応するポリシーも追加してください。 ドキュメント例で `eth0` のようなインターフェース名を固定しないでください。インターフェース名は VPS イメージによって異なり（`ens3`、`enp*` など）、不一致があると deny ルールが意図せず効かない可能性があります。 再読み込み後の簡易確認: ```bash theme={"theme":{"light":"min-light","dark":"min-dark"}} ufw reload iptables -S DOCKER-USER ip6tables -S DOCKER-USER nmap -sT -p 1-65535 --open ``` 外部から見えるポートは、意図的に公開したものだけであるべきです（多くの構成では SSH + リバースプロキシ用ポート程度）。 ### 0.4.2) mDNS / Bonjour discovery（情報露出） ゲートウェイは、ローカルデバイス発見のために mDNS（`_openclaw-gw._tcp`、port 5353）で存在を通知します。full モードでは、運用上の詳細を漏らし得る TXT record が含まれます。 * `cliPath`: CLI バイナリの完全ファイルシステムパス（ユーザー名やインストール場所が分かる） * `sshPort`: ホストで SSH が有効であることを広告する * `displayName`, `lanHost`: ホスト名情報 **運用上のセキュリティ観点:** インフラ情報をブロードキャストすると、ローカルネットワーク上の第三者が偵察しやすくなります。ファイルシステムパスや SSH 有無のような「一見 harmless」な情報でも、攻撃者の環境把握を助けます。 **推奨事項:** 1. **Minimal mode**（既定。公開面のあるゲートウェイに推奨）: 機微な項目を mDNS ブロードキャストから除外します。 ```json5 theme={"theme":{"light":"min-light","dark":"min-dark"}} { discovery: { mdns: { mode: "minimal" }, }, } ``` 2. **完全に無効化**: ローカルデバイス発見が不要なら、mDNS 自体を無効にしてください。 ```json5 theme={"theme":{"light":"min-light","dark":"min-dark"}} { discovery: { mdns: { mode: "off" }, }, } ``` 3. **Full mode**（明示的 opt-in）: TXT record に `cliPath` と `sshPort` を含めます。 ```json5 theme={"theme":{"light":"min-light","dark":"min-dark"}} { discovery: { mdns: { mode: "full" }, }, } ``` 4. **環境変数による代替**: 設定を変えずに mDNS を切る場合は `OPENCLAW_DISABLE_BONJOUR=1` を設定します。 minimal mode でも、`role`、`gatewayPort`、`transport` のような、デバイス発見に必要な最低限の情報は引き続き広告されます。一方で `cliPath` と `sshPort` は省かれます。CLI path が必要なアプリは、認証済み WebSocket 接続経由で取得できます。 ### 0.5) ゲートウェイ WebSocket を厳格化する（ローカル認証） ゲートウェイ認証は **既定で必須** です。トークン / パスワードが設定されていない場合、ゲートウェイは WebSocket 接続を拒否します（fail-closed）。 オンボーディングウィザードは、loopback であっても既定でトークンを生成するため、ローカルクライアントでも認証が必要です。 すべての WS クライアントに認証を要求するには、トークンを設定してください。 ```json5 theme={"theme":{"light":"min-light","dark":"min-dark"}} { gateway: { auth: { mode: "token", token: "your-token" }, }, } ``` `openclaw doctor --generate-gateway-token` でも生成できます。 注意: `gateway.remote.token` / `.password` はクライアント側の認証情報ソースです。これ単体ではローカル WS アクセスを保護しません。 ローカル呼び出し経路は、`gateway.auth.*` が未設定のときに `gateway.remote.*` を fallback として使えます。 `wss://` を使う場合は、必要に応じて `gateway.remote.tlsFingerprint` で TLS pinning を行ってください。 平文の `ws://` は既定では loopback 専用です。信頼できるプライベートネットワーク経路でどうしても必要な場合のみ、クライアント側プロセスに `OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1` を設定して緊急回避としてください。 ローカルデバイスペアリング: * ローカル接続（loopback またはゲートウェイホスト自身の tailnet アドレス）に対しては、同一ホスト上クライアントの利便性のため、デバイスペアリングは **自動承認** されます。 * それ以外の tailnet peer はローカル扱いされません。引き続きペアリング承認が必要です。 認証モード: * `gateway.auth.mode: "token"`: 共有 bearer token（多くの構成で推奨） * `gateway.auth.mode: "password"`: パスワード認証（`OPENCLAW_GATEWAY_PASSWORD` の env 設定を推奨） * `gateway.auth.mode: "trusted-proxy"`: ID 認識型リバースプロキシにユーザー認証を委ね、ヘッダーで ID を受け取る（[Trusted Proxy Auth](/gateway/trusted-proxy-auth) を参照） ローテーション手順（トークン / パスワード）: 1. 新しいシークレットを生成 / 設定する（`gateway.auth.token` または `OPENCLAW_GATEWAY_PASSWORD`）。 2. ゲートウェイを再起動する（または macOS app がゲートウェイを監督しているならその app を再起動する）。 3. ゲートウェイに接続するリモートクライアント側の認証情報（`gateway.remote.token` / `.password`）を更新する。 4. 古い認証情報では接続できないことを確認する。 ### 0.6) Tailscale Serve の ID ヘッダー `gateway.auth.allowTailscale` が `true` のとき（Serve では既定）、OpenClaw は Control UI / WebSocket 認証に対して、Tailscale Serve の ID ヘッダー（`tailscale-user-login`）を受け入れます。OpenClaw は、`x-forwarded-for` のアドレスをローカル Tailscale daemon の `tailscale whois` で解決し、その結果とヘッダー値を照合して本人性を検証します。これは、loopback に到達し、かつ Tailscale が注入する `x-forwarded-for`、`x-forwarded-proto`、`x-forwarded-host` を含むリクエストに対してのみ発動します。 一方で HTTP API エンドポイント（たとえば `/v1/*`、`/tools/invoke`、`/api/channels/*`）は、引き続き token / password 認証が必要です。 重要な境界注記: * ゲートウェイ HTTP bearer 認証は、実質的にオールオアナッシングなオペレーター権限です。 * `/v1/chat/completions`、`/v1/responses`、`/tools/invoke`、`/api/channels/*` を呼べる認証情報は、そのゲートウェイに対するフルアクセスのオペレーターシークレットとして扱ってください。 * 未信頼の呼び出し元にこれらの認証情報を共有しないでください。信頼境界ごとに別ゲートウェイを用意する方を優先してください。 **信頼前提:** token なし Serve 認証は、ゲートウェイホスト自体が信頼できることを前提にしています。同一ホスト上で未信頼コードが動く可能性があるなら、これを防御と見なしてはいけません。その場合は `gateway.auth.allowTailscale` を無効にし、token / password 認証を必須にしてください。 **セキュリティルール:** 自前のリバースプロキシからこれらのヘッダーを転送しないでください。TLS 終端やプロキシをゲートウェイ手前に置くなら、`gateway.auth.allowTailscale` は無効にし、代わりに token / password 認証（または [Trusted Proxy Auth](/gateway/trusted-proxy-auth)）を使ってください。 Trusted proxies: * TLS をゲートウェイの手前で終端するなら、`gateway.trustedProxies` に proxy の IP を設定してください。 * OpenClaw は、それらの IP から届く `x-forwarded-for`（または `x-real-ip`）を、ローカルペアリング判定と HTTP auth / local 判定のクライアント IP 算出に使います。 * proxy は `x-forwarded-for` を**上書き**し、ゲートウェイ port への直接アクセスを遮断してください。 関連項目: [Tailscale](/gateway/tailscale) と [Web overview](/web) ### 0.6.1) ノードホスト経由のブラウザ制御（推奨） ゲートウェイはリモートにあるが、ブラウザは別マシン上で動かしたい場合は、そのブラウザマシン上で **node host** を動かし、ゲートウェイからブラウザ操作をプロキシさせてください（[Browser tool](/tools/browser) 参照）。ノードペアリングは管理者アクセス相当として扱ってください。 推奨パターン: * ゲートウェイと node host は同じ tailnet（Tailscale）上に置く。 * ノードは意図的にペアリングし、ブラウザ proxy routing が不要なら無効にする。 避けるべきこと: * relay / control port を LAN や公開インターネットに露出すること。 * ブラウザ制御エンドポイントに対して Tailscale Funnel を使うこと（公開露出になるため）。 ### 0.7) ディスク上のシークレット（何が機微情報か） `~/.openclaw/`（または `$OPENCLAW_STATE_DIR/`）配下のものは、シークレットや私的データを含み得ると考えてください。 * `openclaw.json`: ゲートウェイトークン、リモートゲートウェイ設定、プロバイダー設定、許可リストなどを含み得ます。 * `credentials/**`: チャネル認証情報（例: WhatsApp 認証情報）、ペアリング許可リスト、レガシー OAuth import。 * `agents//agent/auth-profiles.json`: API key、token profile、OAuth token、および任意の `keyRef` / `tokenRef`。 * `secrets.json`（任意）: `file` SecretRef provider（`secrets.providers`）が使うファイルバック secret payload。 * `agents//agent/auth.json`: 旧互換用ファイル。静的な `api_key` 項目は検出時に除去されます。 * `agents//sessions/**`: セッショントランスクリプト（`*.jsonl`）とルーティングメタデータ（`sessions.json`）。私的メッセージやツール出力を含み得ます。 * `extensions/**`: インストール済みプラグイン（およびその `node_modules/`）。 * `sandboxes/**`: ツール用サンドボックス workspace。サンドボックス内で読み書きしたファイルのコピーが蓄積し得ます。 堅牢化のコツ: * 権限は厳格にする（ディレクトリ `700`、ファイル `600`）。 * ゲートウェイホストではフルディスク暗号化を使う。 * ホストを共有する場合は、ゲートウェイ専用の OS ユーザーを使う。 ### 0.8) ログ + トランスクリプト（マスキング + 保持期間） アクセス制御が正しくても、ログやトランスクリプトから機密情報が漏れることがあります。 * ゲートウェイログには、ツール要約、エラー、URL が含まれ得ます。 * セッショントランスクリプトには、貼り付けられたシークレット、ファイル内容、コマンド出力、リンクが含まれ得ます。 推奨事項: * ツール要約のマスキングは有効のままにしてください（`logging.redactSensitive: "tools"`。既定値）。 * 環境固有のパターンは `logging.redactPatterns` に追加してください（トークン、ホスト名、内部 URL など）。 * 診断共有では、生ログより `openclaw status --all` を優先してください（貼り付けやすく、シークレットはマスクされます）。 * 長期保持が不要なら、古いセッショントランスクリプトやログファイルは間引いてください。 詳細: [Logging](/gateway/logging) ### 1) DMs: 既定は pairing ```json5 theme={"theme":{"light":"min-light","dark":"min-dark"}} { channels: { whatsapp: { dmPolicy: "pairing" } }, } ``` ### 2) Groups: どこでも mention 必須 ```json theme={"theme":{"light":"min-light","dark":"min-dark"}} { "channels": { "whatsapp": { "groups": { "*": { "requireMention": true } } } }, "agents": { "list": [ { "id": "main", "groupChat": { "mentionPatterns": ["@openclaw", "@mybot"] } } ] } } ``` グループチャットでは、明示的に mention されたときだけ応答させてください。 ### 3. 番号を分ける AI 用の番号は、個人の番号とは分けることを検討してください。 * 個人番号: 私的な会話を非公開のまま保てる * bot 用番号: 適切な境界を設けたうえで AI に処理させる ### 4. 読み取り専用モード（現状はサンドボックス + ツールで実現） 次を組み合わせれば、すでに読み取り専用プロファイルを構成できます。 * `agents.defaults.sandbox.workspaceAccess: "ro"`（workspace アクセスなしなら `"none"`） * `write`、`edit`、`apply_patch`、`exec`、`process` などを拒否する tool allow / deny リスト 将来的には、この構成を簡単にする `readOnlyMode` フラグを追加する可能性があります。 追加の堅牢化オプション: * `tools.exec.applyPatch.workspaceOnly: true`（既定）: サンドボックスが off でも、`apply_patch` が workspace ディレクトリ外を更新 / 削除できないようにします。workspace 外へ書き込みたい意図が明確な場合にのみ `false` にしてください。 * `tools.fs.workspaceOnly: true`（任意）: `read` / `write` / `edit` / `apply_patch` のパスと、ネイティブプロンプトの画像自動読み込み対象を workspace ディレクトリに制限します（現時点で絶対パスを許可しているが、1 本のガードレールを追加したい場合に有用です）。 * ファイルシステムルートは狭く保つ: エージェント workspace やサンドボックス workspace にホームディレクトリ全体のような広いルートを指定しないでください。広いルートは `~/.openclaw` 配下の状態 / 設定のような機微ファイルまでファイルシステムツールに露出させます。 ### 5) セキュアなベースライン（そのまま使える例） ゲートウェイを非公開に保ち、DM ではペアリングを要求し、グループでの常時待受 bot を避ける「安全側既定」設定の例です。 ```json5 theme={"theme":{"light":"min-light","dark":"min-dark"}} { gateway: { mode: "local", bind: "loopback", port: 18789, auth: { mode: "token", token: "your-long-random-token" }, }, channels: { whatsapp: { dmPolicy: "pairing", groups: { "*": { requireMention: true } }, }, }, } ``` ツール実行も既定でより安全にしたい場合は、サンドボックスを加え、オーナー以外のエージェントでは危険なツールを拒否してください（後述の「Per-agent access profiles」の例を参照）。 組み込みのベースラインでは、チャット駆動のエージェントターンに対し、オーナー以外の送信者は `cron` と `gateway` ツールを使えません。 ## サンドボックス（推奨） 専用ドキュメント: [Sandboxing](/gateway/sandboxing) 補完的なアプローチが 2 つあります。 * **ゲートウェイ全体を Docker で動かす**（コンテナ境界）: [Docker](/install/docker) * **ツールサンドボックス**（`agents.defaults.sandbox`。ゲートウェイ自体はホスト、ツールだけ Docker 隔離）: [Sandboxing](/gateway/sandboxing) 補足: エージェント間アクセスを防ぐには、`agents.defaults.sandbox.scope` を `"agent"`（既定）に保つか、より厳格に `"session"` を使ってください。`scope: "shared"` は 1 つのコンテナ / workspace を共有します。 また、サンドボックス内での agent workspace アクセスも検討してください。 * `agents.defaults.sandbox.workspaceAccess: "none"`（既定）: agent workspace を見せず、ツールは `~/.openclaw/sandboxes` 下の sandbox workspace に対して実行されます。 * `agents.defaults.sandbox.workspaceAccess: "ro"`: agent workspace を `/agent` に読み取り専用でマウントします（`write` / `edit` / `apply_patch` は無効化されます）。 * `agents.defaults.sandbox.workspaceAccess: "rw"`: agent workspace を `/workspace` に読み書き可能でマウントします。 重要: `tools.elevated` は、exec をホスト上で実行するグローバルな escape hatch です。`tools.elevated.allowFrom` は厳格に絞り、見知らぬ相手には有効化しないでください。さらに `agents.list[].tools.elevated` でエージェント単位制限も可能です。詳細は [Elevated Mode](/tools/elevated) を参照してください。 ### サブエージェント委任のガードレール セッションツールを許可する場合、委任されたサブエージェント実行も別の境界判断として扱ってください。 * そのエージェントが本当に委任を必要としない限り、`sessions_spawn` は拒否する。 * `agents.list[].subagents.allowAgents` は、安全と分かっている対象エージェントに限定する。 * サンドボックス必須のワークフローでは、`sessions_spawn` に `sandbox: "require"` を渡す（既定は `inherit`）。 * `sandbox: "require"` は、対象の子ランタイムがサンドボックスされていない場合に即座に失敗します。 ## ブラウザ制御のリスク ブラウザ制御を有効にすると、モデルは実ブラウザを操作できます。そのブラウザプロファイルがすでにログイン済みセッションを持っていれば、モデルはそれらのアカウントやデータにアクセスできます。ブラウザプロファイルは **機微状態** として扱ってください。 * エージェント専用プロファイルを使ってください（既定の `openclaw` プロファイル）。 * 個人の普段使いプロファイルをエージェントに向けないでください。 * サンドボックスされたエージェントでは、信頼できない限りホストブラウザ制御を無効にしてください。 * ブラウザダウンロードは未信頼入力として扱い、できれば分離したダウンロードディレクトリを使ってください。 * エージェント用プロファイルでは、可能ならブラウザ同期やパスワードマネージャーを無効にしてください（影響範囲を減らせます）。 * リモートゲートウェイでは、「ブラウザ制御」は、そのプロファイルで到達できるものに対する「オペレーターアクセス」と同等だと考えてください。 * ゲートウェイと node host は tailnet 限定にし、relay / control port を LAN や公開インターネットに露出しないでください。 * Chrome extension relay の CDP endpoint は認証で保護されています。接続できるのは OpenClaw クライアントのみです。 * ブラウザ proxy routing が不要なら無効にしてください（`gateway.nodes.browser.mode="off"`）。 * Chrome extension relay mode は **より安全という意味ではありません**。既存の Chrome タブを乗っ取れます。そのタブ / プロファイルが到達できる範囲では、あなたとして振る舞えると考えてください。 ### ブラウザ SSRF ポリシー（trusted-network 既定） OpenClaw のブラウザネットワークポリシーは、既定では trusted-operator モデルです。private / internal 宛先は、明示的に無効にしない限り許可されます。 * 既定値: `browser.ssrfPolicy.dangerouslyAllowPrivateNetwork: true`（未設定時は暗黙的に true） * 旧エイリアス: `browser.ssrfPolicy.allowPrivateNetwork` も互換のため引き続き受理されます。 * Strict mode: `browser.ssrfPolicy.dangerouslyAllowPrivateNetwork: false` にすると、private / internal / special-use 宛先を既定で拒否します。 * strict mode では、`hostnameAllowlist`（`*.example.com` のようなパターン）と `allowedHostnames`（`localhost` のようなブロック対象名も含めた厳密例外）を使って明示例外を追加します。 * redirect 経由の pivot を減らすため、ナビゲーションはリクエスト前にチェックされ、さらにナビゲーション後の最終 `http(s)` URL に対しても可能な範囲で再チェックされます。 strict policy の例: ```json5 theme={"theme":{"light":"min-light","dark":"min-dark"}} { browser: { ssrfPolicy: { dangerouslyAllowPrivateNetwork: false, hostnameAllowlist: ["*.example.com", "example.com"], allowedHostnames: ["localhost"], }, }, } ``` ## エージェント単位のアクセスプロファイル（マルチエージェント） マルチエージェントルーティングでは、各エージェントに独自のサンドボックス + ツールポリシーを持たせられます。これを使って、エージェントごとに **フルアクセス**、**読み取り専用**、**アクセスなし** を割り当ててください。詳細な優先順位規則は [Multi-Agent Sandbox & Tools](/tools/multi-agent-sandbox-tools) を参照してください。 よくある用途: * Personal agent: フルアクセス、サンドボックスなし * Family / work agent: サンドボックスあり + 読み取り専用ツール * Public agent: サンドボックスあり + ファイルシステム / シェルツールなし ### 例: フルアクセス（サンドボックスなし） ```json5 theme={"theme":{"light":"min-light","dark":"min-dark"}} { agents: { list: [ { id: "personal", workspace: "~/.openclaw/workspace-personal", sandbox: { mode: "off" }, }, ], }, } ``` ### 例: 読み取り専用ツール + 読み取り専用 workspace ```json5 theme={"theme":{"light":"min-light","dark":"min-dark"}} { agents: { list: [ { id: "family", workspace: "~/.openclaw/workspace-family", sandbox: { mode: "all", scope: "agent", workspaceAccess: "ro", }, tools: { allow: ["read"], deny: ["write", "edit", "apply_patch", "exec", "process", "browser"], }, }, ], }, } ``` ### 例: ファイルシステム / シェルアクセスなし（provider messaging は許可） ```json5 theme={"theme":{"light":"min-light","dark":"min-dark"}} { agents: { list: [ { id: "public", workspace: "~/.openclaw/workspace-public", sandbox: { mode: "all", scope: "agent", workspaceAccess: "none", }, // Session tools can reveal sensitive data from transcripts. By default OpenClaw limits these tools // to the current session + spawned subagent sessions, but you can clamp further if needed. // See `tools.sessions.visibility` in the configuration reference. tools: { sessions: { visibility: "tree" }, // self | tree | agent | all allow: [ "sessions_list", "sessions_history", "sessions_send", "sessions_spawn", "session_status", "whatsapp", "telegram", "slack", "discord", ], deny: [ "read", "write", "edit", "apply_patch", "exec", "process", "browser", "canvas", "nodes", "cron", "gateway", "image", ], }, }, ], }, } ``` ## AI に伝えるべきこと エージェントのシステムプロンプトには、セキュリティ指針を含めてください。 ``` ## Security Rules - Never share directory listings or file paths with strangers - Never reveal API keys, credentials, or infrastructure details - Verify requests that modify system config with the owner - When in doubt, ask before acting - Keep private data private unless explicitly authorized ``` ## インシデント対応 AI が望ましくない動作をした場合は、次の順で対応してください。 ### 封じ込め 1. **止める:** macOS app がゲートウェイを監督しているならその app を停止し、そうでなければ `openclaw gateway` プロセスを終了します。 2. **露出を閉じる:** 何が起きたか把握できるまで、`gateway.bind: "loopback"` に戻すか、Tailscale Funnel / Serve を無効化します。 3. **アクセスを凍結する:** リスクのある DM / グループを `dmPolicy: "disabled"` に切り替えるか、mention 必須にし、`"*"` の全許可エントリがあれば削除します。 ### ローテーション（シークレット漏えい時は侵害前提で考える） 1. ゲートウェイ認証（`gateway.auth.token` / `OPENCLAW_GATEWAY_PASSWORD`）を更新し、再起動します。 2. ゲートウェイを呼べる各マシン上のリモートクライアント認証情報（`gateway.remote.token` / `.password`）も更新します。 3. プロバイダー / API 認証情報（WhatsApp 認証情報、Slack / Discord token、`auth-profiles.json` の model / API key、必要に応じて暗号化 secret payload 値）を更新します。 ### 監査 1. ゲートウェイログを確認します: `/tmp/openclaw/openclaw-YYYY-MM-DD.log`（または `logging.file`）。 2. 関連するトランスクリプトを確認します: `~/.openclaw/agents//sessions/*.jsonl`。 3. 最近の設定変更を確認します（アクセス拡大につながるもの。`gateway.bind`、`gateway.auth`、DM / グループポリシー、`tools.elevated`、plugin 変更など）。 4. `openclaw security audit --deep` を再実行し、critical な検出結果が解消されたことを確認します。 ### 報告用に収集するもの * タイムスタンプ、ゲートウェイホスト OS、OpenClaw バージョン * セッショントランスクリプトと、短いログ tail（マスキング後） * 攻撃者が送った内容と、エージェントが実行した内容 * ゲートウェイが loopback を超えて露出していたか（LAN / Tailscale Funnel / Serve） ## シークレットスキャン（`detect-secrets`） CI では `secrets` ジョブで `detect-secrets` の pre-commit hook を実行します。 `main` への push では常に全ファイルスキャンを実行します。pull request では、 base commit が取得できる場合は変更ファイルのみの高速経路を使い、取得できない場合は全ファイルスキャンにフォールバックします。失敗した場合は、baseline に未登録の新しい候補があるという意味です。 ### CI が失敗した場合 1. まずローカルで再現します。 ```bash theme={"theme":{"light":"min-light","dark":"min-dark"}} pre-commit run --all-files detect-secrets ``` 2. ツールの役割を理解します。 * pre-commit で走る `detect-secrets` は、リポジトリの baseline と excludes を使って `detect-secrets-hook` を実行します。 * `detect-secrets audit` は対話的レビューを開き、baseline 上の各項目を実シークレットか false positive かで分類します。 3. 実シークレットなら、ローテーション / 削除してから再スキャンし、baseline を更新します。 4. false positive なら、対話監査を開いて false としてマークします。 ```bash theme={"theme":{"light":"min-light","dark":"min-dark"}} detect-secrets audit .secrets.baseline ``` 5. 新しい除外が必要なら `.detect-secrets.cfg` に追加し、同じ `--exclude-files` / `--exclude-lines` フラグで baseline を再生成してください（この config ファイルは参照用であり、detect-secrets が自動読込するわけではありません）。 意図した状態が `.secrets.baseline` に反映されたら、その更新をコミットしてください。 ## セキュリティ問題の報告 OpenClaw に脆弱性を見つけた場合は、責任ある開示で報告してください。 1. Email: [security@openclaw.ai](mailto:security@openclaw.ai) 2. 修正されるまでは公開しない 3. 希望があれば、謝辞に名前を掲載する（匿名希望も可）