安全設計

安全不是一個功能，是一個持續的狀態。

你可以把 OpenClaw 的安全設計想像成同心圓 — 最外層擋掉 99% 的雜訊，中間層驗證身份，最內層控制存取權限。每一層都假設外層可能被突破，獨立運作、互不信任。

Cloudflare Tunnel（零暴露端口）

傳統做法是開一個對外端口、掛上 SSL 憑證、設定防火牆規則。這意味著你的伺服器 IP 暴露在公網上，每天接受成千上萬次自動化掃描。

Cloudflare Tunnel 反轉了這個邏輯。

它的運作方式是由你的伺服器主動向外建立連線，連到 Cloudflare 的邊緣節點。外部請求先抵達 Cloudflare，經過 DDoS 緩解和 WAF（Web Application Firewall）過濾，再透過這條加密通道轉發到你的本機 Gateway。

關鍵在於：

• 伺服器不需要開放任何對外端口 — 連 443 都不用
• 伺服器 IP 不會暴露 — 攻擊者連掃描目標都找不到
• DDoS 防護和 WAF 過濾內建 — 不需要額外設定
• DNS 路由自動管理 — Cloudflare 負責域名解析到最近的邊緣節點

這不是額外加上去的安全層，而是 OpenClaw 推薦部署架構的核心組件。沒有它，你需要自己處理 SSL 憑證續期、防火牆規則、IP 白名單 — 而且你的伺服器會直接面對公網。

Webhook 簽名驗證

Cloudflare Tunnel 擋掉了大部分惡意流量，但通過安全檢查的請求不代表就是合法的。你需要驗證每一則 Webhook 確實來自 LINE 或 Telegram，而不是有人偽造的。

LINE 簽名驗證

LINE 使用 Channel Secret 進行 HMAC-SHA256 簽名。每一則 Webhook 請求的 header 中都帶有 X-Line-Signature，OpenClaw 會用你設定的 Channel Secret 重新計算簽名並比對。不匹配就直接丟棄。

Telegram 簽名驗證

Telegram 的做法不同 — 它基於 Bot Token 產生驗證。OpenClaw 會驗證每一則更新確實來自 Telegram 的伺服器，而不是第三方偽造的 JSON payload。

為什麼這很重要

沒有簽名驗證，任何人只要知道你的 Webhook URL，就可以偽造訊息讓你的 Agent 執行指令。想像一下：攻擊者發送一則偽造的「請刪除所有檔案」的訊息，你的 Agent 以為是合法使用者的指令就照做了。

簽名驗證確保只有來自官方平台的訊息才會被處理。這是零妥協的底線。

Gateway 認證

通過 Webhook 驗證的請求確認了「訊息來自正確的平台」，但 Gateway 本身也需要認證機制，特別是 Web 控制面板和 API 端點。

OpenClaw 提供三種認證方式：

1. Token 認證

在設定檔中指定 gateway.token，所有對 Gateway 的 API 請求都需要在 header 中帶上這個 token。適合程式化存取和自動化整合。

2. 密碼認證

在設定檔中指定 gateway.password，用於 Web 控制面板的登入。適合人類操作者日常使用。

3. Tailscale Headers 認證

如果你的伺服器在 Tailscale mesh VPN 網路中，OpenClaw 可以直接讀取 Tailscale 注入的 header 進行身份識別。零設定、零密碼，網路層自動完成認證。

三種方式不互斥，你可以同時啟用。

額外的安全 headers：

• Anti-clickjacking — Gateway 回應中帶有防止頁面被嵌入 iframe 的 header，避免點擊劫持攻擊
• Same-origin WebSocket 驗證 — 控制面板的 WebSocket 連線會驗證來源，防止跨站 WebSocket 劫持
• 環境變數支援 — token 和密碼都支援從環境變數讀取，不要把機密寫死在設定檔裡

存取控制

認證解決「你是誰」，存取控制解決「你能做什麼」。OpenClaw 提供細粒度的存取控制機制，讓你精確管理誰可以和 Agent 互動。

Pairing 配對機制

對於私訊（DM），OpenClaw 預設要求未知的發送者先通過配對流程。

流程很直覺：陌生人發訊息給你的 Agent，Agent 回覆一個配對碼（Telegram 的配對碼有效期為 1 小時），管理員在終端機執行 openclaw pairing approve <channel> <CODE> 核准後，該使用者才能正常互動。

這就像公司門禁 — 不認識的人得先在大廳登記，保全確認後才能進去。

dmPolicy — 私訊策略

四種模式，從嚴到寬：

groupPolicy — 群組策略

群組層級的存取控制。你可以決定 Agent 是否回應特定群組的訊息、是否需要被 @ 提及才回應、或是完全忽略某些群組。

Allowlist 白名單

白名單支援各平台的原生 ID 格式：

• LINE — 使用者 ID 以 U 開頭，群組 ID 以 C 開頭，聊天室 ID 以 R 開頭
• Telegram — 直接使用數字格式的 user ID

白名單是最嚴格也最明確的存取控制。適合企業內部部署 — 你精確知道誰該有權限。

日誌與監控

安全不是設定完就結束了。你需要持續看到系統的狀態，才能在問題變成事故之前發現它。

即時日誌追蹤

openclaw logs --follow

持續輸出 Gateway 的即時日誌。看到異常的存取模式？看到不認識的 user ID 在嘗試互動？這就是你的第一道早期預警。

深度診斷

openclaw status --deep

對系統進行全面的健康檢查 — Tunnel 連線狀態、Channel Plugin 是否正常、AI 模型 API 是否可達。不只告訴你「活著」，還告訴你「每個零件都正常運作」。

機器可讀的健康快照

openclaw health --json

輸出 JSON 格式的健康狀態，適合接入你現有的監控系統（Prometheus、Grafana、Datadog 等）。自動化監控比人工巡檢可靠一百倍。

日誌管理

日誌檔案由 systemd journal 或 macOS 的 unified logging 統一管理。建議設定 log rotation 避免磁碟被日誌吃滿 — 這是另一個聽起來不會發生、但一定會發生的事。

GetClaw 觀點

GetClaw 團隊持有 ISO 27001、ISO 27701、SOC 2 Type 2 認證。我們理解企業級安全不只是「設定正確」，而是持續的監控、更新、和事件回應。

OpenClaw 的安全設計很扎實 — 零暴露端口、簽名驗證、多層存取控制，這些都是正確的設計選擇。但讓它在企業環境裡真正合規，需要的不只是技術，還有流程和經驗：

• 定期的安全稽核和滲透測試
• 事件回應計畫（Incident Response Plan）
• 存取權限的定期審查
• 合規文件的持續更新

技術把門鎖裝好了，但誰來巡邏、誰來換鎖、鑰匙怎麼管 — 這些才是企業安全的核心。