Hướng dẫn bảo mật Claude Code: Quyền truy cập, MCP, Sandboxing

Các chatbot truyền thống được cấu hình phía sau một API, nên điều tệ nhất chúng có thể làm là bịa đặt. Nhưng một tác nhân AI viết mã lại nằm ngay trong repo, terminal của bạn và (thường) cả thông tin xác thực đám mây của bạn, đặt nó gần hơn nhiều với các môi trường nhà phát triển có đặc quyền so với bất cứ thứ gì ta từng gọi là chatbot.

Câu hỏi là làm sao dùng Claude Code an toàn mà không làm chậm bạn. Quyền truy cập, kiểm soát MCP và sandboxing với mức tinh chỉnh phù hợp sẽ giúp bạn đạt được điều đó.

Trong bài viết này, tôi sẽ hướng dẫn bạn cách mô hình bảo mật của Claude Code thực sự hoạt động, những nơi bạn cần chú ý, và các thực hành giữ cho nó hữu ích mà không cấp cho nó nhiều quyền hơn dự định.

Nếu bạn hoàn toàn mới với Claude và Claude Code, hãy đăng ký khóa học miễn phí Claude Code 101 để nắm vững cơ bản trong một buổi chiều.

Tìm hiểu mô hình bảo mật của Claude Code

Trước khi tinh chỉnh bất kỳ quy tắc nào, bạn cần một mô hình tư duy về những gì Claude Code thực sự kiểm soát.

Có năm phần chuyển động: hệ thống quyền quyết định điều gì được phép, kiểm soát quyền truy cập công cụ để giới hạn từng khả năng, quyền MCP cho tích hợp bên ngoài, sandboxing để cô lập ở cấp hệ điều hành, và khả năng kiểm toán để xem lại sau. Mỗi phần giải quyết một vấn đề khác nhau, nhưng chúng xếp chồng lên nhau.

Hệ thống quyền

Hệ thống quyền là lớp tĩnh.

Bạn khai báo những gì Claude có thể làm trong settings.json, sử dụng ba danh sách: allow, ask và deny. Quy tắc được đánh giá theo thứ tự deny trước, rồi ask, rồi allow, và khớp đầu tiên sẽ thắng. Một quy tắc deny sẽ chặn lệnh gọi ngay cả khi một quy tắc allow rộng hơn có thể phù hợp với nó.

Nếu không có quy tắc nào khớp, Claude sẽ quay về defaultMode của phiên (nói thêm về các chế độ ở phần tiếp theo).

Kiểm soát quyền truy cập công cụ

Quyền được gắn vào công cụ, không phải vào toàn bộ tác nhân.

Claude Code có bộ công cụ tích hợp riêng, ví dụ Bash cho lệnh shell, Read, Edit và Write cho thao tác hệ thống tệp, WebFetch cho yêu cầu HTTPS, WebSearch cho truy vấn, và vài công cụ khác. Mỗi quy tắc nêu tên một công cụ và (tùy chọn) một bộ định danh trong ngoặc, như Bash(git commit:*) hoặc Read(./.env).

Đây là cách nguyên tắc đặc quyền tối thiểu hoạt động. Bạn có thể cho phép Bash(npm run:*) để chạy kiểm thử mà không cấp cho Claude toàn quyền truy cập shell.

Quyền MCP

Máy chủ MCP mở rộng Claude Code bằng các công cụ mà nó vốn không thiết kế để làm việc cùng.

Mỗi máy chủ mang theo bộ công cụ riêng (máy chủ GitHub bổ sung công cụ pull request, máy chủ cơ sở dữ liệu bổ sung công cụ truy vấn, v.v.). Hệ thống quyền cũng bao phủ chúng, nhưng với cú pháp khác - quy tắc dùng dạng mcp__servername__toolname thay vì bộ định danh trong ngoặc.

Điểm cần nhớ là MCP gần như nhân đôi bài toán vì bạn không chỉ quyết định Claude có thể làm gì với shell của bạn, mà còn quyết định nó có thể làm gì với mọi hệ thống bên ngoài bạn đã kết nối.

Sandboxing

Sandboxing là lớp an toàn ở cấp hệ điều hành bên dưới công cụ Bash.

Quy tắc quyền nói với Claude điều nó nên làm. Sandboxing thực thi điều nó có thể làm, bằng cách hạn chế truy cập hệ thống tệp và các cuộc gọi mạng đi ra ở cấp hệ điều hành. Trên macOS, nó hoạt động sẵn qua Seatbelt. Trên Linux và WSL2, bạn cần cài bubblewrap và socat trước.

Hai lớp này hoạt động tương tự nhưng bao phủ các kịch bản khác nhau. Quyền ngăn Claude thử làm điều gì đó, còn sandboxing ngăn nỗ lực đó thành công nếu một prompt injection dụ Claude thử bằng mọi giá.

Khả năng kiểm toán

Mảnh ghép cuối cùng là có thể thấy điều gì đã xảy ra.

Lệnh /permissions liệt kê mọi quy tắc đang hoạt động và tệp cài đặt nơi mỗi quy tắc đó xuất phát, để bạn có thể trả lời "vì sao Claude chạy cái đó?" Hooks (PreToolUse, PostToolUse và các hook khác) cho phép bạn ghi log mọi lần gọi công cụ vào hệ thống của riêng bạn. Với đội nhóm, các trình xuất OpenTelemetry gửi dữ liệu sử dụng và cuộc gọi công cụ vào bất cứ nền tảng quan sát nào bạn đang vận hành.

Quyền và kiểm soát truy cập trong Claude Code

Phần lớn sự an toàn đến từ thiết lập quyền, nên đây là khu vực bạn sẽ dành nhiều thời gian tinh chỉnh nhất.

Truy cập tệp

Theo mặc định, Claude có thể đọc và chỉnh sửa các tệp trong thư mục nơi bạn khởi chạy nó.

Việc đọc được kiểm soát bởi công cụ Read, và chỉnh sửa bởi Edit và Write. Mỗi công cụ chấp nhận một mẫu đường dẫn trong ngoặc, dùng cú pháp kiểu gitignore, ví dụ Read(**/.env) khớp mọi tệp .env ở bất kỳ độ sâu nào, và Edit(src/**) khớp mọi thứ dưới src/.

Một deny trên Read bao phủ các công cụ tệp của chính Claude Code (Read, Grep, Glob, LS), nhưng đó chỉ là nỗ lực tốt nhất. Một script Python hoặc Node chạy qua Bash vẫn có thể mở tệp, vì lần đọc đó diễn ra qua shell thay vì công cụ Read của Claude. Nếu bí mật là quan trọng, hãy kết hợp deny Read với deny Bash trên cat, head và tail cho những đường dẫn đó.

Để mở rộng quyền truy cập ra ngoài thư mục làm việc, dùng additionalDirectories trong settings.json. Đây là cách bạn cấp cho Claude quyền truy cập vào một thư viện dùng chung bên ngoài repo hoặc một tệp cấu hình trong thư mục home của bạn, mà không xóa bỏ hoàn toàn ranh giới thư mục làm việc.

Thực thi lệnh

Công cụ Bash là thứ bạn phải giới hạn cẩn thận nhất.

Một quy tắc Bash trần cho phép mọi lệnh. Một quy tắc có phạm vi như Bash(npm run:*) chỉ cho phép những lệnh phù hợp. Mẫu colon-star là thứ bạn cần dùng ở đây, và Claude Code hiểu các toán tử shell, nên một quy tắc như Bash(safe-cmd:*) sẽ không khớp với safe-cmd && rm -rf /.

Một số lệnh chạy mà không nhắc hỏi trong mọi chế độ, vì mặc định chúng được coi là chỉ-đọc. Danh sách này bao gồm ls, cat, echo, pwd, head, tail, grep, find, wc, which, diff, stat, du, cd, và các dạng chỉ-đọc của git. Bạn không thể tự thu hẹp danh sách này, nhưng có thể thêm quy tắc ask hoặc deny cho bất kỳ lệnh nào trong số đó để ghi đè mặc định.

Với mọi thứ không được phê duyệt sẵn, Claude sẽ nhắc hỏi ở chế độ mặc định. Hộp thoại hiển thị chính xác lệnh và cho phép bạn phê duyệt một lần, phê duyệt mọi lần gọi sau này khớp mẫu, hoặc từ chối.

Chế độ quyền

Quy tắc quyền là tĩnh, nhưng các chế độ quyền thay đổi cách các lệnh không khớp được xử lý.

Có năm chế độ:

• default: nhắc hỏi khi dùng lần đầu mỗi công cụ.

• acceptEdits: tự động chấp thuận chỉnh sửa tệp trong thư mục làm việc, và vẫn kiểm soát lệnh shell. Hữu ích khi bạn tin tưởng các chỉnh sửa nhưng không tin tưởng shell.

• plan: Claude có thể đọc và phân tích, nhưng không thể chỉnh sửa tệp hoặc chạy lệnh. Phù hợp cho xem xét mã hoặc các buổi lập kế hoạch.

• dontAsk: tự động từ chối mọi thứ không được cho phép rõ ràng.

• bypassPermissions: bỏ qua mọi hộp thoại nhắc. Chỉ an toàn trong môi trường cách ly hoàn toàn như container hoặc VM.

Bạn có thể chuyển qua lại ba chế độ chính bằng Shift+Tab giữa phiên, hoặc chọn một chế độ làm mặc định trong settings.json:

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "deny": ["Read(**/.env)", "Read(**/.env.*)"]
  }
}

Với đội nhóm, managed settings cung cấp một lớp mà người dùng không thể ghi đè. Tệp dùng cùng định dạng JSON và nằm ở đường dẫn hệ thống:

• /Library/Application Support/ClaudeCode/managed-settings.json trên macOS

• /etc/claude-code/managed-settings.json trên Linux

• C:\ProgramData\ClaudeCode\managed-settings.json trên Windows

Các quy tắc deny trong managed settings có hiệu lực trên mọi dự án trên máy, đây là cách bạn thực thi các quy tắc như "không ai đọc tệp .env" hoặc "không ai chạy bypassPermissions" trong toàn tổ chức.

Nguyên tắc đằng sau tất cả những điều này là đặc quyền tối thiểu, giống như bạn áp dụng cho bất kỳ tài khoản dịch vụ nào. 

Bạn nên bắt đầu với bộ quyền nhỏ nhất cho phép công việc diễn ra, và chỉ mở rộng khi gặp trở ngại. Hướng dẫn của chính Anthropic cũng chỉ như vậy - xem lại các thay đổi Claude thực hiện, kiểm toán quy tắc của bạn với /permissions, và giữ các thiết lập đặc thù dự án trong hệ thống quản lý phiên bản để cả nhóm thống nhất về những gì Claude có thể làm.

Sandboxing trong Claude Code

Bạn cho Claude tự động chạy càng nhiều, sandboxing càng có ý nghĩa.

Công cụ Bash có mức phơi bày rộng nhất vì lệnh shell có thể đọc bất kỳ tệp nào bạn có thể đọc và sửa đổi bất cứ thứ gì chúng có quyền ghi. Sandboxing áp đặt các ranh giới ở cấp hệ điều hành cho mọi lệnh Bash và tiến trình con của nó, để Claude có thể chạy tự do hơn trong ranh giới đó mà bạn không phải chấp thuận từng lệnh gọi. Anthropic đã xây dựng điều này để hỗ trợ các lượt chạy tự động an toàn hơn.

Một chi tiết đáng lưu ý là sandbox chỉ bao phủ Bash và các tiến trình con. Nó không hạn chế các công cụ Read, Edit hoặc Write, và những công cụ đó vẫn đi qua hệ thống quyền.

Sandbox gốc

Sandbox gốc được tích hợp sẵn trong Claude Code và bật bằng /sandbox.

Trên macOS, sandboxing sử dụng khung Seatbelt tích hợp sẵn và không cần cài đặt gì. Trên Linux và WSL2, bạn cài bubblewrap để cô lập hệ thống tệp và socat cho proxy mạng. Windows gốc không được hỗ trợ, nên bạn chạy Claude Code bên trong một bản phân phối WSL2.

Ranh giới hệ thống tệp dễ hiểu. Đọc hoạt động ở mọi nơi trừ các đường dẫn bị từ chối, và ghi chỉ hoạt động bên trong thư mục làm việc và các đường dẫn bổ sung bạn cho phép. Nếu bạn thử ghi vào ~/.bashrc từ trong sandbox, bạn sẽ nhận "Operation not permitted" trước cả khi Claude biết là đã thất bại.

Ranh giới mạng thì hơi khác. Lưu lượng đi ra được định tuyến qua một máy chủ proxy chạy bên ngoài sandbox, máy chủ này kiểm tra mọi yêu cầu với danh sách allowedDomains của bạn. Các tên miền mới sẽ kích hoạt hộp thoại xin quyền thay vào đó, nên bạn sẽ thấy chính xác Claude đang hướng tới đâu.

Một cấu hình hoạt động trông như sau:

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true,
    "filesystem": {
      "allowWrite": ["/workspace", "/tmp"],
      "denyRead": ["~/.aws", "~/.ssh"]
    },
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    }
  }
}

Trong nội bộ Anthropic, sandboxing giúp giảm 84% số lần nhắc quyền.

Container phát triển

Container phát triển là bước tiếp theo về mức độ cách ly.

Anthropic có một devcontainer tham chiếu cho Claude Code thiết lập môi trường Ubuntu, mount repo của bạn và cung cấp cho tác nhân một shell để làm việc. Ưu thế so với sandbox gốc là khả năng tái lập, vì mọi người trong nhóm đều có cùng môi trường, cùng công cụ và cùng thiết lập.

Nhưng nhược điểm là chi phí vận hành. 

Bạn thêm khâu build container, mount tệp, và (đôi khi) vòng phản hồi chậm hơn khi dùng container. Với một nhà phát triển đơn lẻ, sandbox gốc thường là đủ. Với đội nhóm hoặc CI, thiết lập này là xứng đáng.

Cách ly dựa trên Docker

Với các phiên tác nhân tự động chạy dài, Docker có thể mở rộng thêm ranh giới sandboxing.

Thiết lập thường trông như sau:

• Ảnh nền tối giản: loại bỏ trình quản lý gói và công cụ mạng mà tác vụ không cần.
• Người dùng không phải root: Claude không bao giờ chạy với quyền root, nên nó không thể sửa tệp hệ thống hoặc cài gói toàn cục.
• Hệ thống tệp gốc chỉ-đọc: mount root của container ở chế độ chỉ-đọc, chỉ cho phép ghi tại các thư mục đầu ra cụ thể.
• Proxy egress: định tuyến mạng đi ra qua proxy cho phép registry gói (npm, PyPI) và từ chối mọi thứ khác, để các lệnh như npm install hoạt động nhưng một lệnh curl tùy ý thì không.
• Giới hạn tài nguyên: đặt giới hạn CPU, bộ nhớ và I/O để một tiến trình không thể làm sập máy chủ.

Docker Sandboxes cấp cho mỗi sandbox một microVM với một daemon Docker riêng. Daemon trên máy chủ thậm chí không nhìn thấy các sandbox trong docker ps. Ranh giới này gần với một VM hơn container, giúp loại bỏ hầu hết đường thoát container mà nhà phát triển lo ngại.

Chiến lược sandboxing cho doanh nghiệp

Với tổ chức, câu hỏi là xếp lớp các kỹ thuật sandbox ra sao, chứ không phải có dùng hay không.

Đa số tiếp cận như sau:

• Quy tắc quyền nằm trong managed-settings.json và không thể bị ghi đè bởi từng nhà phát triển.

• Sandbox gốc chạy bên dưới lớp quyền.

• Dev container hoặc Docker chạy bên dưới lớp đó.

• Với kịch bản đòi hỏi mức tin cậy cao nhất (truy cập production, xử lý bí mật), một VM chuyên dụng không mount hệ thống tệp của host là lớp cuối.

Claude Code trên web là phiên bản được quản lý của cùng ý tưởng. Mỗi phiên chạy trong một VM do Anthropic quản lý, thông tin xác thực nhạy cảm như token git được đặt bên ngoài sandbox trong một proxy, và ranh giới được thực thi bởi hạ tầng.

Bảo mật MCP trong Claude Code

MCP là phần của Claude Code phát triển nhanh nhất.

Mỗi máy chủ MCP bạn kết nối về cơ bản nhân lên những gì Claude có thể làm, nhưng cũng nhân lên bề mặt mà một prompt injection hoặc phụ thuộc bị xâm phạm có thể chạm tới. 

Ví dụ:

• Máy chủ MCP GitHub cấp cho Claude quyền truy cập pull request.
• Máy chủ MCP cơ sở dữ liệu cấp cho nó schema và truy vấn của bạn.
• Máy chủ Slack cấp cho nó quyền truy cập kênh của bạn.

Không điều nào trong số đó là vấn đề, nhưng nó có nghĩa MCP cần cơ chế quản trị riêng. Nội dung lấy qua công cụ MCP (một trang web hoặc phản hồi API) có thể chứa chỉ dẫn được tiêm vào mà Claude thực thi như thể bạn đã gõ chúng. Ngoài ra, mỗi máy chủ bổ sung một thông tin xác thực và một con đường xác thực cần được quản lý riêng.

Quyền công cụ

Các công cụ MCP dùng quy ước đặt tên khác với công cụ tích hợp sẵn.

Định dạng quy tắc là mcp__servername__toolname, không có bộ định danh trong ngoặc. Ví dụ, mcp__github__create_pull_request cho phép Claude gọi đúng công cụ đó, và một deny trên mcp__github__delete_repo sẽ chặn công cụ nguy hiểm. Danh sách allow, ask và deny hoạt động giống hệt như với Bash hoặc Read.

Các quy tắc ưu tiên cũng tương tự - deny trước, rồi ask, rồi allow. Một deny trong managed-settings trên mcp__github__delete_* có hiệu lực trên mọi dự án trên máy.

Quyền tài nguyên

Máy chủ MCP có thể công bố tài nguyên cùng với công cụ.

Một tài nguyên là một phần dữ liệu máy chủ cung cấp để Claude đọc (một tệp trong máy chủ quản lý dự án hoặc một hàng trong máy chủ cơ sở dữ liệu). Quyền truy cập tài nguyên đi qua cùng kiểm tra tin cậy như cuộc gọi công cụ, và kết nối máy chủ MCP lần đầu sẽ chạy bước xác minh tin cậy trước khi bất kỳ công cụ hoặc tài nguyên nào của nó có thể truy cập.

Mặc định đúng là coi tài nguyên như một công cụ khác. Nếu bạn sẽ không cấp thông tin xác thực đó, đừng cấp quyền truy cập tài nguyên.

Máy chủ MCP đã được phê duyệt

Anthropic Directory liệt kê các connector đã được Anthropic xem xét theo tiêu chí niêm yết của họ.

Với tổ chức, một mẫu hình tốt là dùng danh sách cho phép nội bộ. Có hai thiết lập cho phép bạn kiểm soát:

• allowedMcpServers: một mẫu glob các máy chủ mà nhà phát triển có thể thêm vào dự án của họ (ví dụ, company-* để chỉ cho phép các máy chủ do nội bộ duy trì).

• deniedMcpServers: một mẫu các máy chủ không thể thêm, ngay cả khi nhà phát triển cố gắng.

Với các máy chủ bắt buộc phải có trong mọi phiên, tệp managed-mcp.json đặt trong managed settings là cách triển khai. Nhà phát triển không thể xóa hoặc sửa mục này.

Một thiết lập nên tránh trong repo dùng chung là enableAllProjectMcpServers, thiết lập này tự động phê duyệt mọi máy chủ MCP được định nghĩa trong .mcp.json. Điều đó tiện cho công việc cá nhân và nguy hiểm cho bất kỳ thứ gì được commit, vì một PR độc hại có thể thêm máy chủ mới vào .mcp.json và nó sẽ chạy mà không nhắc hỏi.

Quyền truy cập công cụ theo nguyên tắc đặc quyền tối thiểu

Nguyên tắc giống như quyền Bash, chỉ là áp dụng cho MCP.

Câu hỏi khởi đầu là mỗi máy chủ có thông tin xác thực gì. Máy chủ MCP cơ sở dữ liệu nên kết nối tới một bản sao đọc với quyền chỉ-đọc, không phải máy chính có quyền ghi. Máy chủ MCP API nên dùng token được giới hạn ở tập endpoint nhỏ nhất cần thiết, không phải token cá nhân với quyền toàn bộ tổ chức. Vân vân.

Subagent là một cách khác để giới hạn quyền MCP. Một định nghĩa subagent trong .claude/agents/ có thể khai báo chính xác những công cụ nó được truy cập (dùng cú pháp mcp:<server>:<tool>), để một "deploy-agent" có máy chủ hạ tầng còn một "review-agent" chỉ có Read, Grep và Glob. Tác nhân không thể gọi công cụ mà nó không được cấp.

Quản trị MCP

Với một đội hoặc tổ chức vận hành Claude Code ở quy mô lớn, MCP cần hình thức quản trị giống như bất kỳ tích hợp production nào khác.

Điều đó có nghĩa là sổ đăng ký các máy chủ đã phê duyệt với chủ sở hữu được nêu tên, chuỗi kiểm toán đầu-cuối các lần gọi công cụ (các công cụ MCP nào được gọi, bởi ai, với tham số nào), và đánh giá định kỳ danh sách phê duyệt. Các trình xuất OpenTelemetry trong Claude Code cung cấp cho bạn dữ liệu kiểm toán theo định dạng có thể đưa thẳng vào nền tảng quan sát bạn đã chạy.

Với tổ chức lớn hơn, một cổng MCP tập trung là phiên bản gọn gàng nhất của điều này. 

Nhà phát triển kết nối tới cổng thay vì đăng ký từng máy chủ riêng lẻ. Cổng xử lý xác thực, thực thi kiểm soát truy cập dựa trên vai trò ở cấp công cụ, và phát ra một chuỗi kiểm toán duy nhất. Nó cũng giải quyết tình trạng tràn lan thông tin xác thực, vì một bộ thông tin xác thực tại cổng thay thế cho việc mỗi nhà phát triển giữ một bản sao mọi khóa API.

Quản lý bí mật và dữ liệu nhạy cảm

Claude Code có thể đọc mọi thứ bạn có thể đọc, điều này khiến các bí mật có thể bị tiếp cận.

Theo mặc định, Claude Code có thể đọc mọi tệp mà tài khoản người dùng của bạn có thể. Điều đó bao gồm các tệp .env trong dự án, thông tin xác thực AWS trong ~/.aws/, khóa riêng SSH trong ~/.ssh/, token GitHub trong tệp rc của shell, và biến môi trường trong bất kỳ tiến trình con nào Claude tạo ra. Điều này hoàn toàn bình thường và theo thiết kế.

Giữ bí mật ngoài không gian làm việc

Bước đầu tiên là đảm bảo bí mật không nằm trong thư mục Claude đang đọc.

.env là phổ biến nhất. Chúng nằm ở gốc dự án, được nạp bởi mọi công cụ dev, và chứa chính xác những giá trị bạn không muốn xuất hiện trong ngữ cảnh Claude (URL cơ sở dữ liệu và khóa API). 

Dưới đây là vài mẫu bạn có thể dùng:

• Chuyển bí mật sang một thư mục ngoài cây làm việc, ví dụ ~/.config/myapp/secrets.env, và nạp chúng qua một trình quản lý môi trường hoặc thiết lập direnv trỏ tới tệp bên ngoài.

• Với công việc dùng container, giữ một thư mục .secrets/ ngoài bind mount để tệp không thể nhìn thấy từ trong container.

• Thêm Read(**/.env) và Read(**/.env.*) vào danh sách permissions.deny, và ghép chúng với các deny Bash(cat:*/.env) để một script shell không thể đọc điều mà công cụ Read không đọc được.

Dùng trình quản lý bí mật

Với bất cứ thứ gì vượt quá dự án demo, nơi đúng cho bí mật là một trình quản lý bí mật.

Mẫu hình giống nhau bất kể nhà cung cấp (1Password, AWS Secrets Manager, HashiCorp Vault, Doppler, Infisical). Bí mật được đặt trong trình quản lý. Shell hoặc runtime của bạn lấy chúng theo nhu cầu và chỉ phơi bày cho tiến trình cần đến. Claude không bao giờ thấy giá trị thực tế.

Cụ thể với Claude Code, điều này có nghĩa đặt CLAUDE_CODE_SUBPROCESS_ENV_SCRUB để loại bỏ thông tin xác thực Anthropic và nhà cung cấp đám mây khỏi tiến trình con, hoặc dùng sandbox.credentials để unset các biến cụ thể cho các lệnh trong sandbox. Cái đầu ngăn Claude truyền ANTHROPIC_API_KEY của bạn vào script build, và cái thứ hai bao phủ trường hợp rộng hơn của bất kỳ biến môi trường nhạy cảm nào lọt vào lệnh shell.

Hạn chế truy cập kho mã

Tùy chọn thứ ba là ở cấp độ repo.

Nếu một nhà phát triển không cần quyền ghi vào cấu hình chỉ dùng cho production, thì phiên Claude Code của họ cũng không cần. Nghe có vẻ hiển nhiên, nhưng mặc định của hầu hết nhóm là nhà phát triển có quyền rộng hơn mức họ thường dùng, và Claude kế thừa tất cả.

Dưới đây là hai bước bạn có thể thực hiện:

• Tách cấu hình production vào một repo riêng với quyền truy cập chặt chẽ hơn, để môi trường dev nơi Claude làm việc không có các bí mật production ngay từ đầu.

• Dùng token giới hạn phạm vi cho mọi dịch vụ mà Claude tương tác. Ví dụ, một token GitHub cho công việc review mã không cần repo:delete.

Bảo mật Claude Code cho đội nhóm

Một nhà phát triển đơn lẻ có thể thay đổi settings.json tùy ý. Một đội thì không, vì mức độ an toàn tổng thể chỉ tốt bằng cấu hình yếu nhất trên máy yếu nhất. Với triển khai cho đội và tổ chức, Claude Code có một lớp kiểm soát riêng do quản trị viên đẩy xuống và người dùng cá nhân không thể ghi đè.

Managed settings

Managed settings là nền tảng.

Tệp nằm ở đường dẫn hệ thống yêu cầu quyền admin để ghi:

• /Library/Application Support/ClaudeCode/managed-settings.json trên macOS

• /etc/claude-code/managed-settings.json trên Linux

• C:\ProgramData\ClaudeCode\managed-settings.json trên Windows

Thiết lập trong tệp này có mức ưu tiên cao hơn thiết lập cấp người dùng và cấp dự án. Một quy tắc deny đặt ở đây là quy tắc deny trên mọi dự án trên máy, và nhà phát triển không thể loại bỏ bằng cách chỉnh sửa settings.json của riêng họ. Hầu hết tổ chức phân phối tệp qua MDM (Mobile Device Management) hoặc cùng kênh cấu hình họ dùng cho các công cụ dev khác.

Dưới đây là vài thiết lập đáng biết ở lớp managed:

• permissions.deny cho các đường dẫn nhạy cảm và lệnh nguy hiểm

• defaultMode đặt là default hoặc plan (không bao giờ là bypassPermissions)

• allowManagedPermissionRulesOnly: true để khóa bộ quy tắc quyền

• enableAllProjectMcpServers: false để yêu cầu phê duyệt MCP rõ ràng

• Cấu hình trình xuất OpenTelemetry để ghi log

Chính sách quyền dùng chung

Một đội thống nhất về những gì Claude có thể làm thì nên quản lý phiên bản thỏa thuận đó.

Thiết lập cấp dự án nằm trong .claude/settings.json ở gốc repo. Bất cứ điều gì được commit ở đây sẽ áp dụng cho bất kỳ ai chạy Claude trong repo đó. Tệp này là nơi phù hợp cho allow và deny đặc thù dự án.

Với điều đó, có một sự phân tách giữa managed và thiết lập dự án bạn cần biết:

• Managed settings chứa chính sách tổ chức (không ai chạy bypassPermissions, không ai đọc .env).

• Thiết lập dự án chứa quy ước quy trình (kiểm thử của repo này chạy với npm test; script deploy của repo này bị cấm).

Quản trị đội nhóm

Với triển khai cho đội, lớp chính sách cần một chủ sở hữu.

Hầu hết các đội vận hành Claude Code ở quy mô lớn đều có một nhóm nhỏ, thường là bảo mật và kỹ thuật nền tảng, chịu trách nhiệm managed settings, danh sách cho phép MCP, script hook và pipeline OpenTelemetry. Nhóm này cũng xem xét các yêu cầu ngoại lệ và điều chỉnh chính sách khi có tình huống sử dụng mới.

Bạn nên có văn bản cho các phần sau:

• Repo nào nằm trong phạm vi và repo nào không, với chế độ theo tầng rủi ro (repo xử lý dữ liệu được quản lý có thể chạy Claude ở chế độ plan, trong khi repo trang marketing có thể chạy ở chế độ acceptEdits).
• Ai có thể cấp ngoại lệ và cách theo dõi các ngoại lệ đó.
• Chu kỳ xem xét (hàng quý là phổ biến) nơi đội xem lại quy tắc quyền, máy chủ MCP và dữ liệu sự cố.

Ghi log kiểm toán

Claude Code phát ra các sự kiện OpenTelemetry cho mọi quyết định công cụ, kết nối máy chủ MCP, thay đổi chế độ quyền và yêu cầu API. Không có dữ liệu nào được gửi đi cho đến khi admin cấu hình endpoint OTLP trong managed settings.

Dưới đây là một khối managed settings tối thiểu cho telemetry:

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "grpc",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "http://collector.internal:4317"
  }
}

Theo mặc định, nội dung prompt và tham số công cụ bị loại trừ khỏi dữ liệu xuất, nên các sự kiện bạn thu thập là siêu dữ liệu, không phải toàn bộ cuộc hội thoại. Để bao gồm văn bản prompt, bạn đặt OTEL_LOG_USER_PROMPTS=1. Để bao gồm tham số công cụ (thường là thứ bạn muốn cho kiểm toán), bạn đặt OTEL_LOG_TOOL_DETAILS=1. Cả hai quyết định đều có tác động đến quyền riêng tư, nên hầu hết đội coi đó là lựa chọn chính sách có chủ đích và cấu hình backend telemetry để lọc hoặc che trước khi lưu trữ.

Giám sát sử dụng

Luồng OpenTelemetry dùng cho kiểm toán cũng là luồng dùng cho giám sát sử dụng.

Claude Code xuất các số đo cho lượng token dùng, chi phí mỗi yêu cầu, số lượng phiên và tỷ lệ quyết định công cụ. Khi được tổng hợp, các số đo này cho bạn biết nhóm nào đang thu được giá trị nhiều nhất, quy trình nào tạo ra nhiều lần bị từ chối nhất và mô hình nào đang tạo chi phí. Các backend như Datadog, Honeycomb, SigNoz, Elastic và Splunk đều tiếp nhận định dạng OTLP chuẩn.

Một đột biến trong sự kiện permission_decision với decision=deny có thể nghĩa là Claude đang thử quá nhiều, nhưng cũng có thể nghĩa là quy tắc allow của đội quá chặt.

Các lỗi bảo mật Claude Code thường gặp

Một nhóm nhỏ các cấu hình sai xuất hiện trong hầu hết các sự cố Claude Code. Bây giờ tôi sẽ chỉ ra đó là gì và cách xử lý.

Quyền quá rộng

Cách nhanh nhất để làm cùn hệ thống quyền là cho phép quá nhiều.

Nhắc hỏi theo từng lệnh tạo ma sát, và cách sửa dễ dàng là một allow Bash(*) rộng hoặc đặt defaultMode: bypassPermissions. Cả hai đều vô hiệu hóa hầu hết những gì hệ thống quyền làm.

Bạn nên giới hạn quy tắc allow vào các công cụ và lệnh bạn thực sự dùng (ví dụ Bash(npm test:*) và Bash(git status)), và để mọi thứ khác quay về hộp thoại nhắc. Ban đầu bạn sẽ gặp nhiều nhắc hơn nhưng chỉ sau vài phiên, bạn đã đưa vào danh sách cho phép những lệnh mình dùng và các hộp thoại hầu như dừng lại.

Truy cập MCP không hạn chế

Sai lầm thứ hai là kết nối máy chủ MCP mà không kiểm tra chúng đang dùng thông tin xác thực gì hoặc có thể tiếp cận gì.

Điều này thường xảy ra vì ai đó bật enableAllProjectMcpServers, kết nối vài máy chủ từ thư mục MCP công khai và không bao giờ quay lại xem xét. Đến khi một máy chủ với thông tin xác thực yếu làm rò rỉ thứ gì nhạy cảm, kết nối đã đủ cũ trong cấu hình để không ai nhớ là từng phê duyệt.

Cách khắc phục giống hệt phần quyền. Dùng danh sách cho phép rõ ràng qua allowedMcpServers, một managed-mcp.json nội bộ cho những máy chủ mọi người cần, và chu kỳ xem xét danh sách.

Không bật sandboxing

Nếu sandboxing tắt, hệ thống quyền là thứ duy nhất đứng giữa Claude và hệ thống tệp của bạn.

Điều đó ổn cho các phiên tương tác ngắn nơi bạn phê duyệt từng lệnh. Nó không ổn cho các lượt chạy tự động, cho các phiên bạn đã mở rộng quy tắc allow, hoặc cho bất kỳ công việc nào chạm tới mã từ nguồn bên ngoài.

/sandbox sẽ bật nó. Nếu chưa cài phụ thuộc, menu sẽ hiển thị những gì cần cài cho nền tảng của bạn. Khi đã bật, số lần nhắc quyền giảm và hệ điều hành bắt các trường hợp ngoài phạm vi quy tắc allow.

Chấp nhận thay đổi một cách mù quáng

acceptEdits vừa tiện vừa nguy hiểm.

Khi Claude đang viết lại một hàm và bạn giám sát, tự động chấp thuận là ổn. Khi Claude lặp qua 30 tệp trong một giờ, bạn có xu hướng ngừng đọc diff và bắt đầu tin tác nhân. Đó là nơi vấn đề có thể xảy ra.

Hai thói quen bạn nên thực hiện:

• Luôn commit trước khi để Claude chạy tự động, để đường lùi chỉ còn một lệnh git reset.

• Xem diff trước mỗi commit do Claude tạo, không phải diff tích lũy vào cuối phiên.

Bỏ qua dấu vết kiểm toán

Một đội chạy Claude Code mà không có telemetry thì không thể trả lời câu hỏi "phiên nào đã làm điều đó?" Các sự kiện tích lũy cục bộ trên mỗi máy và ở lại đó. Lần đầu bạn cần chuỗi kiểm toán cũng là lúc tệ nhất để phát hiện ra bạn chưa cấu hình.

Mức tối thiểu hữu ích là xuất các sự kiện tool_decision, permission_decision và api_request tới bất kỳ nền tảng quan sát nào đội đã sử dụng. Từ đó, bạn xây dựng bảng điều khiển và cảnh báo khi có tình huống sử dụng phát sinh.

Kết luận

Kịch bản tệ nhất cho một chatbot là một câu trả lời sai. Nhưng với tác nhân viết mã, đó là một lệnh shell chạy trên môi trường production với thông tin xác thực của bạn.

Đó là lý do ba trụ cột sau quan trọng:

• Quyền quyết định Claude được phép làm gì
• Kiểm soát MCP quyết định hệ thống bên ngoài nào nó có thể tiếp cận
• Sandboxing quyết định điều gì xảy ra khi hai phần đầu không đủ

Mỗi phần bao phủ một kiểu lỗi mà các phần khác không bao phủ. Kết hợp lại, chúng xác định ranh giới thực sự mà Claude hoạt động bên trong.

Nếu bạn đang muốn được chứng nhận về AI sinh sinh, dưới đây là so sánh, các khóa học hàng đầu, mẹo chuẩn bị và câu hỏi thường gặp cho Các chứng chỉ Generative AI tốt nhất năm 2026.