Bảo mật OpenClaw: hướng dẫn cấu hình an toàn theo từng bước

Hướng dẫn OpenClaw

(1) Hướng dẫn OpenClaw chi tiết nhất từ A tới Z

(2) Cài OpenClaw lên VPS Việt Nam để chạy 24/7

(3) Tùy biến OpenClaw: Tạo trợ lý AI theo phong cách riêng của bạn

(4) Tự động hoá với OpenClaw: Cron Jobs, Heartbeats và Webhooks

(5) Cài đặt và tạo Skills cho OpenClaw: Mở rộng khả năng không giới hạn

(6) Kết nối OpenClaw với nhiều AI cùng lúc: Claude, ChatGPT, Gemini

(7) OpenClaw + GitHub: Quản lý toàn bộ dev workflow bằng chat

(8) OpenClaw + Home Assistant: Điều khiển nhà thông minh bằng chat

(9) Tích hợp OpenViking vào OpenClaw: Nâng cấp bộ nhớ AI Agent, giảm 83% token cost

(10) Bảo mật OpenClaw: hướng dẫn cấu hình an toàn theo từng bước

(11) Một số skill nên cân nhắc cho OpenClaw

(12) So sánh cách chạy OpenClaw: VPS, Mac Mini, Windows, Linux, Docker, Raspberry Pi

(13) OpenClaw hybrid: Gateway trên VPS + Node trên Mac local

(14) Tối ưu chi phí OpenClaw: Cách giảm 70% token usage mà vẫn giữ chất lượng

(15) Quản lý nhiều VPS bằng OpenClaw – CMDB cá nhân cho SysAdmin

(16) Biến OpenClaw thành NOC Engineer – Giám sát server 24/7 bằng AI

(17) OpenClaw cho team: Chia sẻ trợ lý AI cho nhiều người dùng

(18) 10 cách sử dụng OpenClaw hữu ích mà bạn chưa nghĩ tới

OpenClaw có thể đọc file, sửa file, chạy lệnh, gọi tool và nhận lệnh từ Telegram, Discord hoặc các kênh khác. Vì vậy, việc bảo mật không nằm ở một dòng cấu hình duy nhất, mà ở cách khóa dần từng lớp. Nếu làm đúng thứ tự, hệ thống sẽ dễ kiểm soát hơn. Nếu mở bot hoặc gateway ra ngoài quá sớm, rủi ro sẽ tăng lên rõ rệt.

Bài này đi theo đúng trình tự nên làm khi triển khai thực tế: chọn mô hình dùng, khóa gateway, khóa channel, thu hẹp quyền tool, bật sandbox ở chỗ cần, dọn secrets và logs, chạy audit, rồi cuối cùng là rà lại các lỗi hay gặp. Mục tiêu là giúp bạn có một cấu hình đủ an toàn để dùng hằng ngày và dễ kiểm soát khi cần rà soát hoặc mở rộng.

Về cách áp dụng cấu hình, bạn có thể sửa trực tiếp file ~/.openclaw/openclaw.json rồi chạy lại lệnh kiểm tra hoặc khởi động lại dịch vụ tương ứng. Nếu đang dùng OpenClaw trong một session đủ quyền, bạn cũng có thể yêu cầu nó chỉnh file giúp, nhưng vẫn nên đọc lại diff hoặc nội dung thay đổi trước khi áp dụng trên máy đang chạy thật.

Điều cần nhớ: OpenClaw được thiết kế theo mô hình trợ lý cá nhân. Đây không phải là ranh giới multi-tenant mạnh để nhiều người lạ cùng dùng chung một gateway mà vẫn tách quyền như một dịch vụ SaaS.

Chọn cách triển khai trước khi mở quyền

Trước khi chỉnh openclaw.json, bạn nên xác định mình đang dùng OpenClaw theo kiểu nào. Đây là bước định hướng ban đầu, nhưng nó ảnh hưởng trực tiếp đến cách cấu hình các phần còn lại. Bài so sánh các cách chạy OpenClaw sẽ giúp bạn chọn hình thức triển khai phù hợp.

• Chỉ dùng trên máy của chính bạn: đây là cách an toàn nhất để bắt đầu. Gateway chỉ cần nghe local, không cần mở LAN, không cần cho bot vào group.
• Dùng từ xa qua tailnet: hợp khi bạn muốn điều khiển máy ở nhà hoặc VPS từ laptop, điện thoại hay máy khác. Lúc này ưu tiên Tailscale hoặc một lớp mạng riêng tương tự, thay vì mở public port.
• Đưa bot vào Telegram hoặc Discord, nhất là group: đây là trường hợp dễ phát sinh rủi ro nhất vì số người chạm được vào bot nhiều hơn, và mọi sai sót ở channel policy hay tool policy sẽ lộ ra rất nhanh.

Nếu chưa có nhu cầu rõ ràng, cứ bắt đầu từ kiểu thứ nhất. Nhiều lỗi bảo mật với OpenClaw bắt đầu từ việc mở quyền truy cập quá sớm ngay sau khi cài đặt.

Khóa gateway trước: bind và auth là lớp đầu tiên

Gateway là lớp đầu tiên của toàn bộ hệ thống. Nếu lớp này mở quá rộng thì những lớp sau chỉ còn mang tính giảm thiểu thiệt hại, chứ không cứu được kiến trúc sai ngay từ đầu. Khi bắt đầu, nên để gateway nghe trên loopback.

{
  "gateway": {
    "bind": "loopback",
    "auth": {
      "mode": "token",
      "token": "mot-token-dai-ngau-nhien-kho-doan"
    }
  }
}

Với cấu hình này, gateway chỉ nghe trên 127.0.0.1. Nó không tự lộ ra LAN hay ra Internet. Đây là điểm xuất phát phù hợp để kiểm tra tool, rà lại policy, chạy audit và xác nhận hệ thống hoạt động đúng.

Nếu cần token mới, bạn có thể tạo nhanh bằng lệnh:

openclaw doctor --generate-gateway-token

Chỉ khi thực sự cần truy cập từ xa mới nên cân nhắc các mode khác như lan hoặc tailnet. Có một điểm rất dễ nhầm: dùng Tailscale không có nghĩa là auth của OpenClaw trở nên không quan trọng. Tailscale chỉ giúp thu hẹp bề mặt mạng. Quyền truy cập vào gateway vẫn phải khóa đúng bằng token, password hoặc cơ chế auth phù hợp.

Nếu máy của bạn chạy nhiều gateway, ví dụ một cái để dùng thật và một cái để lab, hãy tập thói quen gọi lệnh có chỉ rõ đích. Không nên phụ thuộc hoàn toàn vào target mặc định.

openclaw gateway status
openclaw gateway health
openclaw gateway health --url ws://127.0.0.1:19021 --token YOUR_TOKEN

Lỗi kiểu này gặp khá thường xuyên: gateway không hỏng, auth không sai, nhưng lệnh đang trỏ nhầm sang instance khác.

Đến lượt channel: ai được quyền nói chuyện với bot

Sau khi gateway đã được khóa ở mức cơ bản, bước tiếp theo là channel. Đây là chỗ quyết định ai có thể gửi yêu cầu vào OpenClaw qua Telegram, Discord, WhatsApp hay kênh khác. Nếu phần này mở quá rộng, các lớp bảo vệ phía sau sẽ khó phát huy tác dụng.

Với DM (Direct Message), hai mode nên dùng nhiều nhất là pairing và allowlist. open chỉ nên dùng khi bạn hiểu rất rõ mình đang đánh đổi cái gì.

{
  "channels": {
    "telegram": {
      "dmPolicy": "pairing"
    },
    "discord": {
      "dmPolicy": "allowlist",
      "allowFrom": ["123456789012345678"]
    }
  }
}

Nếu bot nằm trong group, đừng chỉ nghĩ tới chuyện “cho bot vào được là xong”. Nếu cần hình dung rõ hơn các kiểu triển khai thực tế, bạn có thể xem thêm bài cài OpenClaw lên VPS. Trong group, bạn nên có thêm ít nhất hai lớp:

• giới hạn group hoặc user nào được phép gọi bot
• bật requireMention để bot không nhảy vào mọi câu trong phòng chat

{
  "channels": {
    "discord": {
      "groupPolicy": "allowlist",
      "allowFrom": ["111111111111111111"],
      "requireMention": true
    }
  }
}

Cách hiểu ngắn gọn là thế này: dmPolicy quyết định ai được DM bot, allowFrom quyết định ai thực sự được phép, còn requireMention giúp bot chỉ phản hồi khi bị gọi đúng cách. Ba phần này cần đi cùng nhau để tạo thành một cấu hình đủ chặt.

Nhiều người thêm bot vào group xong chỉ bật requireMention rồi yên tâm. Như vậy chưa đủ. Nếu policy vẫn quá rộng, ai được quyền mention bot thì vẫn có thể kéo bot làm những thứ không nên làm.

Khóa tool theo đúng nhu cầu, đừng cấp rộng hơn mức cần dùng

Đây là phần quyết định phạm vi tác động khi có sự cố. Agent không rủi ro vì nó “thông minh”, mà vì nó được cấp quyền gì. Với OpenClaw, quyền tool luôn nên đi từ tối thiểu rồi mở dần, không đi theo hướng ngược lại.

Nếu phải chọn một tool để siết đầu tiên, hãy siết exec. Cấu hình an toàn cho đa số máy cá nhân là:

{
  "tools": {
    "exec": {
      "security": "allowlist",
      "ask": "on-miss"
    }
  }
}

Hiểu đơn giản là: lệnh quen thuộc nằm trong allowlist thì chạy được, lệnh lạ thì hỏi. Cách này an toàn hơn so với việc mở full rồi kỳ vọng model sẽ luôn diễn giải đúng yêu cầu.

Nếu không thực sự cần, hãy tắt luôn elevated. Còn nếu cần, thì chỉ mở cho đúng người dùng được phép.

{
  "tools": {
    "elevated": {
      "enabled": true,
      "allowFrom": {
        "telegram": ["123456789"]
      }
    }
  }
}

Với bot trong group hoặc các agent xử lý nội dung ít tin cậy hơn, nên siết chặt hơn nữa: deny hẳn những tool như exec, process, write, edit, hoặc trình duyệt nếu không cần dùng tới.

{
  "agents": {
    "list": [
      {
        "id": "public",
        "tools": {
          "deny": ["exec", "process", "write", "edit", "browser"]
        }
      }
    ]
  }
}

Đừng quên một nhóm quyền dễ bị xem nhẹ là các tool điều khiển tiến trình hoặc session. Chúng không hào nhoáng như shell, nhưng vẫn đủ để mở thêm nhiều bề mặt tác động mà bạn không muốn có trong một channel rộng.

Bật sandbox cho đúng chỗ

Sandbox nên được cân nhắc nghiêm túc, nhất là khi session không hoàn toàn tin cậy hoặc bot hoạt động trong channel rộng. Nhưng cần hiểu đúng vai trò của nó: sandbox giúp giảm thiệt hại nếu model chạy sai, chứ không biến một policy lỏng thành an toàn tuyệt đối.

Một cấu hình nên bắt đầu là:

{
  "agents": {
    "defaults": {
      "sandbox": {
        "mode": "all",
        "scope": "session",
        "workspaceAccess": "none"
      }
    }
  }
}

Nếu muốn hiểu nhanh ba mode thường gặp:

• off: không sandbox, chỉ nên dùng cho session cá nhân mà bạn thật sự kiểm soát được
• non-main: session chính chạy bình thường, session phụ đi qua sandbox
• all: chặt nhất, phù hợp khi nhiều nguồn vào cùng chạm tới bot

Phần hay gây hiểu nhầm là workspaceAccess. Nếu để none, agent trong sandbox sẽ không thấy workspace chính. Điều này tốt cho an toàn, nhưng cũng có nghĩa là một số lệnh đọc file hoặc sửa file sẽ fail đúng như thiết kế. Thấy fail ở đây chưa chắc là lỗi. Có khi policy đang làm đúng việc của nó.

Ngoài ra, sandbox còn có thể vướng những chuyện rất đời thường như thiếu binary, không có mạng để tải package, hoặc không mount thứ bạn cần. Vì vậy, khi debug, nên tự hỏi trước: lệnh fail vì OpenClaw hỏng, vì tool thiếu, hay vì mình đang nhốt nó trong môi trường chặt hơn?

Secrets, logs và transcript

Sau khi gateway, channel và tool đã ổn, bước tiếp theo là dọn các thứ còn lại trên ổ đĩa. Đây là chỗ nhiều người chủ quan nhất mà quên mất rằng file config, log và transcript cũng là dữ liệu nhạy cảm.

Điều đầu tiên nên làm là bỏ secret dạng plaintext ra khỏi config chính. Thay vì ghi thẳng API key, hãy dùng SecretRef qua biến môi trường hoặc provider tương ứng.

{
  "models": {
    "providers": {
      "openai": {
        "apiKey": {
          "source": "env",
          "provider": "default",
          "id": "OPENAI_API_KEY"
        }
      }
    }
  }
}

Bạn có thể kiểm tra nhanh bằng các lệnh:

openclaw secrets audit --check
openclaw secrets configure
openclaw secrets reload

Còn với logs và transcript, cách nghĩ đúng là xem chúng như dữ liệu vận hành nhạy cảm. Nếu bạn đang dùng OpenClaw để theo dõi nhiều máy, bài quản lý nhiều VPS bằng OpenClaw cũng khá liên quan vì nó cho thấy lượng thông tin vận hành mà agent có thể chạm tới. Logs và transcript có thể chứa output lệnh, đường dẫn file, metadata kết nối, nội dung chat, sự kiện pairing và nhiều dữ liệu không nên chia sẻ nguyên trạng.

Tối thiểu, hãy siết quyền file của thư mục cấu hình:

chmod 700 ~/.openclaw
chmod 600 ~/.openclaw/openclaw.json

Khi cần nhờ người khác xem lỗi, ưu tiên gửi output đã được rút gọn từ status hoặc audit trước. Chỉ gửi raw log khi thật sự cần, và nhớ bỏ token, secret, đường dẫn nhạy cảm hoặc dữ liệu riêng tư liên quan tới hệ thống của bạn.

Chạy security audit, nhưng đừng hiểu sai tác dụng của nó

Sau khi đã khóa các lớp chính, bạn nên chạy audit để xem còn gì hở. Đây là bước rất nên có, nhưng cũng dễ bị kỳ vọng quá mức nếu hiểu sai vai trò của audit. Audit giúp phát hiện cấu hình nguy hiểm hoặc quá rộng. Nó không thay bạn thiết kế kiến trúc và cũng không tự sửa hết các quyết định vận hành sai.

openclaw security audit
openclaw security audit --deep

Nếu muốn thử auto-fix cho các phần an toàn, có thể chạy thêm. Thực tế, nên xem đây là bước hỗ trợ sau khi bạn đã sửa các khóa chính trong file cấu hình, không phải bước thay thế cho việc tự rà lại policy:

openclaw security audit --fix

Khi đọc kết quả, hãy tập trung vào các nhóm sau:

• gateway bind và auth
• DM hoặc group policy đang quá rộng
• tool mạnh nhưng lại mở ở channel rộng
• quyền file còn lỏng
• các cờ nguy hiểm hoặc cấu hình kiểu break-glass còn sót lại

Cần nói thẳng một chuyện: --fix không phải nút “vá xong bảo mật”. Nó không tự hiểu được bối cảnh triển khai của bạn để kéo mọi thứ về trạng thái tối ưu. Ví dụ, nó không thể thay bạn quyết định gateway nào nên để loopback, group nào thực sự nên mở, hay ai mới được dùng elevated.

Trên máy có nhiều instance, nhớ kiểm tra đúng target trước khi audit. Nếu probe nhầm gateway, kết quả rất dễ nhìn giống lỗi auth hoặc lỗi mạng, trong khi vấn đề thật chỉ là đang soi sai đích.

Những lỗi hay gặp nhất khi mới siết bảo mật OpenClaw

Dưới đây là các lỗi mình thấy thực tế nhất, và cũng là các lỗi khiến người dùng mất thời gian debug nhiều nhất.

1. Mở gateway ra LAN quá sớm

Mới cài xong đã chuyển sang lan để “test cho tiện” là thói quen rất dễ gặp. Cách an toàn hơn là test trên loopback trước, xác nhận mọi thứ ổn rồi mới mở rộng dần.

2. Có Tailscale rồi nghĩ khỏi cần auth

Tailscale giúp thu hẹp bề mặt mạng, không thay auth của OpenClaw. Nếu gateway vẫn mở sai hoặc token yếu, bạn vẫn đang để cửa ngõ ở trạng thái kém an toàn.

3. Đưa bot vào group nhưng quên siết tool

Bot trong group mà vẫn giữ exec, process, write hay edit quá rộng thì chỉ cần một yêu cầu tệ là đủ mệt. Group càng rộng, tool càng phải chặt.

4. Bật sandbox rồi tưởng lệnh nào cũng phải chạy như trên host

Không phải. Có lệnh fail vì trong sandbox không có binary, không có mạng, hoặc không thấy workspace chính. Đó là khác biệt vận hành, không hẳn là lỗi sản phẩm.

5. Trên máy nhiều gateway nhưng vẫn dùng target mặc định

Đây là lỗi rất phổ biến trong vận hành. Khi có lab và prod cùng nằm trên một host, hãy xem --url và --token như thói quen bắt buộc cho các lệnh quan trọng.

6. Gửi nguyên log cho đồng nghiệp hoặc support

Log rất hữu ích cho việc xử lý sự cố, nhưng cũng dễ làm lộ dữ liệu không nên chia sẻ. Nên xem raw log là tài liệu nội bộ và chỉ trích phần thực sự cần dùng.

Checklist rà nhanh trước khi dùng thật

Nếu muốn kiểm tra nhanh một hệ OpenClaw đã đủ chặt chưa, bạn có thể rà theo danh sách này:

• ☐ Tôi đã xác định rõ mình đang dùng local only, remote qua tailnet hay bot trong group.
• ☐ Gateway vẫn để bind: "loopback" nếu chưa thật sự cần mở rộng.
• ☐ Gateway có auth bằng token hoặc password đủ mạnh.
• ☐ DM không mở tự do nếu không có lý do rõ ràng.
• ☐ Group có requireMention và allowlist phù hợp.
• ☐ exec đang ở allowlist + ask: "on-miss" hoặc chặt hơn.
• ☐ elevated đã tắt hoặc chỉ mở cho đúng người.
• ☐ Các agent ở channel rộng đã bỏ những tool nguy hiểm không cần thiết.
• ☐ Sandbox đã bật cho session hoặc agent ít tin cậy hơn.
• ☐ Secret không còn nằm plaintext trong config.
• ☐ Quyền file của ~/.openclaw và openclaw.json đã đủ chặt.
• ☐ Tôi đã chạy openclaw security audit và đọc kết quả theo đúng bối cảnh triển khai.
• ☐ Tôi biết log và transcript nằm ở đâu, và không chia sẻ raw log bừa.

Kết

Việc siết bảo mật cho OpenClaw sẽ dễ kiểm soát hơn nếu đi đúng thứ tự: khóa gateway trước, rồi mới đến channel, tool, sandbox và phần dữ liệu lưu trên đĩa. Không nên tìm một mẹo duy nhất để giải quyết toàn bộ bài toán bảo mật. Với OpenClaw, an toàn đến từ việc mỗi lớp đều đủ chặt cho đúng bối cảnh sử dụng của bạn.

Nếu phải nhớ một câu thôi, thì là câu này: không mở rộng phạm vi truy cập trước khi xác định rõ bot đang có những quyền gì. Điều này đặc biệt quan trọng khi chia sẻ OpenClaw cho nhiều người dùng. Giữ nguyên tắc đó, cộng thêm thói quen chạy audit định kỳ, bạn sẽ bớt được rất nhiều ca đau đầu khi đem OpenClaw vào dùng thật.