Claude Support › Safeguards › Tuân thủ pháp luật & Bảo vệ trẻ vị thành niên › Yêu cầu bảo mật của Chương trình xác minh an ninh mạng (Cyber Verification Program Security Requirements)

Yêu cầu bảo mật của Chương trình xác minh an ninh mạng (Cyber Verification Program Security Requirements)

Cập nhật: 08/10/2026 • Hướng dẫn kỹ thuật bởi vMix Việt Nam

Khách hàng phải đáp ứng và duy trì các yêu cầu bảo mật sau đây đối với từng cấp độ truy cập của Chương trình xác minh an ninh mạng (Cyber Verification Program – CVP) mà Khách hàng nắm giữ (“Cấp độ truy cập”). Các yêu cầu này áp dụng cho Người dùng được phê duyệt (Approved Users) và Không gian làm việc được cấp quyền (Granted Workspaces).

1. Tất cả các cấp độ truy cập.

  1. Đầu mối liên hệ bảo mật. Khách hàng phải cung cấp cho Anthropic một đầu mối liên hệ bảo mật được chỉ định cụ thể, người có thể nhận các cảnh báo về bảo mật và lạm dụng, đồng thời có khả năng xử lý các cảnh báo đó.

  2. Báo cáo sự cố. Khách hàng phải báo cáo cho Anthropic các trường hợp nghi ngờ xâm phạm hoặc lạm dụng liên quan đến quyền cấp trong vòng 72 giờ, hoặc trong vòng 24 giờ đối với sự cố bảo mật. Có thể báo cáo qua [email protected] hoặc đầu mối liên hệ trong nhóm phụ trách tài khoản của bạn.

  3. Hợp tác. Khách hàng phải điều tra mọi hành vi lạm dụng mà Anthropic phát hiện trong vòng 48 giờ, phối hợp với Anthropic để khắc phục và phản hồi các yêu cầu làm rõ về lạm dụng trong vòng bảy (7) ngày.

  4. Truy cập cá nhân. Mỗi Người dùng được phê duyệt phải đăng nhập bằng chính danh tính của mình. Không được phép dùng chung thông tin đăng nhập, chỗ ngồi (seat), phiên và danh tính workload, cũng như không được dùng tiện ích mở rộng trình duyệt hoặc công cụ proxy làm lộ phiên cho những người không phải là Người dùng được phê duyệt đáp ứng toàn bộ các yêu cầu dưới đây.

  5. Ghi nhận việc sử dụng. Hồ sơ người dùng phải luôn được bật trên Không gian làm việc được cấp quyền để các yêu cầu có thể được gắn với một người dùng hoặc danh tính workload cụ thể.

  6. Thông báo thay đổi. Khách hàng phải thông báo cho Anthropic trong vòng ba mươi (30) ngày khi có thay đổi đáng kể về tình trạng bảo mật, quyền sở hữu, trụ sở chính hoặc đầu mối liên hệ bảo mật.

  7. Đánh giá liên tục. Anthropic có thể yêu cầu Khách hàng cung cấp bằng chứng về việc tuân thủ các Yêu cầu bảo mật của Chương trình xác minh an ninh mạng này.

2. Quyền truy cập phòng thủ (Defense Access).

  1. Xác thực đa yếu tố. Tại thời điểm Khách hàng truy cập CVP, tất cả các tài khoản có thể đăng nhập vào Không gian làm việc được cấp quyền, hoặc nắm giữ thông tin xác thực của không gian làm việc đó, đều phải bật xác thực đa yếu tố. Chậm nhất vào ngày 15 tháng 12 năm 2026 (“Ngày hết hạn chuyển đổi”), tất cả các tài khoản đó phải sử dụng xác thực đa yếu tố chống lừa đảo (phishing-resistant) theo định nghĩa trong tài liệu tóm tắt của CISA “Implementing Phishing-Resistant MFA” và theo NIST SP 800-63B-4, tức là (i) khóa bảo mật FIDO2/WebAuthn, (ii) passkey, lưu trên thiết bị hoặc trong trình quản lý mật khẩu, hoặc (iii) thẻ thông minh/PIV, đồng thời phải tắt tính năng đăng nhập bằng liên kết đăng nhập qua email (magic link). SMS, cuộc gọi thoại, mã gửi qua email, mã từ ứng dụng xác thực và phê duyệt qua thông báo đẩy đều không đạt yêu cầu.

  2. Quản lý thông tin xác thực. Kể từ Ngày hết hạn chuyển đổi, không được sử dụng thông tin xác thực tĩnh đã tải xuống, đã xuất hoặc có thời hạn dài theo bất kỳ cách nào khác, bao gồm cả khóa API, để truy cập mô hình. Các yêu cầu sau áp dụng cho Khách hàng tùy theo (các) nền tảng triển khai mà Khách hàng dùng để truy cập mô hình. Với mỗi nền tảng áp dụng, tất cả Người dùng được phê duyệt và tất cả các workload phải xác thực bằng thông tin xác thực ngắn hạn do dịch vụ danh tính gốc của nền tảng đó cấp và quản lý.

    1. Anthropic (API và Console của bên thứ nhất). Không được phép dùng khóa API tĩnh hoặc có thời hạn dài, kể cả để truy cập tương tác vào Claude Console, Claude for Enterprise, Claude Code và các ứng dụng khác của Anthropic.

    2. Google Vertex. Không được phép dùng tệp khóa JSON của tài khoản dịch vụ (service account) đã tải xuống.

    3. Amazon Web Services (Amazon Bedrock). Không được phép dùng cặp khóa truy cập của người dùng IAM (access key ID và secret access key), ngoại trừ các khóa API Bedrock ngắn hạn hết hạn trong vòng 12 giờ hoặc khi phiên Bedrock kết thúc, tùy theo mốc nào đến trước.

    4. Microsoft Azure (Azure AI Foundry). Không được phép dùng khóa API cũng như client secret hoặc chứng chỉ của service principal đã xuất.

  3. Khóa API tạm thời. Cho đến Ngày hết hạn chuyển đổi, khóa API chỉ được phép sử dụng theo quyền cấp Defense Access nếu mỗi khóa (i) được lưu trong trình quản lý bí mật (secrets manager) hoặc trình quản lý mật khẩu, (ii) được gán cho một người hoặc một workload duy nhất, (iii) không nằm trong mã nguồn và (iv) được thay thế ít nhất 7 ngày một lần. Anthropic có thể giới hạn thời hạn của khóa API theo quyền cấp Defense Access ở mức 7 ngày, và có thể vô hiệu hóa khóa API trên Không gian làm việc được cấp quyền kể từ Ngày hết hạn chuyển đổi.

  4. Người dùng được phê duyệt. Không có giới hạn mặc định về số lượng Người dùng được phê duyệt ở Cấp độ truy cập này.

3. Quyền truy cập phòng thủ dành cho cá nhân.

  1. Cá nhân chỉ đủ điều kiện nhận Defense Access. Phần này áp dụng khi quyền cấp do một cá nhân nắm giữ

    1. Xác thực đa yếu tố. Cá nhân chỉ được đăng nhập vào tài khoản Anthropic nắm giữ quyền cấp thông qua Google hoặc một nhà cung cấp danh tính tương đương. Kể từ ngày được cấp quyền truy cập, tài khoản đó phải bật xác thực đa yếu tố. Chậm nhất vào ngày 15 tháng 12 năm 2026 (“Ngày hết hạn chuyển đổi”), tài khoản đó phải sử dụng xác thực đa yếu tố chống lừa đảo, tức là khóa bảo mật, passkey hoặc thẻ thông minh/PIV, và cá nhân không được dùng tính năng đăng nhập bằng liên kết qua email (magic link). SMS, cuộc gọi thoại, mã gửi qua email, mã từ ứng dụng xác thực và phê duyệt qua thông báo đẩy đều không đạt yêu cầu.

    2. Quản lý thông tin xác thực. Kể từ Ngày hết hạn chuyển đổi, không được sử dụng thông tin xác thực tĩnh hoặc có thời hạn dài, bao gồm cả khóa API, để truy cập mô hình. Claude Code, Claude Console và claude.ai xác thực thông qua OAuth. Quyền truy cập theo chương trình cho các workload, nếu có, phải sử dụng Workload Identity Federation. Cho đến Ngày hết hạn chuyển đổi, chỉ được phép dùng một khóa API nếu khóa đó (i) được lưu trong trình quản lý mật khẩu hoặc kho bí mật cục bộ, (ii) không bao giờ được chia sẻ hoặc đặt trong mã nguồn và (iii) được thay thế ít nhất 7 ngày một lần. Anthropic có thể giới hạn thời hạn của khóa API theo quyền cấp ở mức 7 ngày, và có thể vô hiệu hóa khóa API kể từ Ngày hết hạn chuyển đổi.

    3. Truy cập cá nhân. Cá nhân đó là người duy nhất được phép sử dụng quyền truy cập. Không được phép dùng chung thông tin đăng nhập hoặc phiên, cũng như dùng tiện ích mở rộng trình duyệt hoặc công cụ proxy làm lộ phiên cho người khác.

    4. Giám sát. Toàn bộ lưu lượng theo quyền cấp đều được lưu giữ và giám sát. Không áp dụng chế độ không lưu giữ dữ liệu (Zero data retention).

    5. Trong các yêu cầu áp dụng cho Tất cả các cấp độ truy cập, các yêu cầu Báo cáo sự cố, Hợp tác và Đánh giá liên tục áp dụng cho cá nhân.

4. Quyền truy cập Red Team (Red Team Access).

  1. Quản lý thông tin xác thực. Các yêu cầu sau áp dụng cho Khách hàng tùy theo (các) nền tảng triển khai mà Khách hàng dùng để truy cập mô hình. Với mỗi nền tảng áp dụng, tất cả Người dùng được phê duyệt và tất cả các workload phải xác thực bằng thông tin xác thực ngắn hạn do dịch vụ danh tính gốc của nền tảng đó cấp và quản lý.

    1. Anthropic (API và Console của bên thứ nhất). Không được phép dùng khóa API tĩnh hoặc có thời hạn dài, kể cả để truy cập tương tác vào Claude Console, Claude for Enterprise, Claude Code và các ứng dụng khác của Anthropic.

    2. Google Vertex. Không được phép dùng tệp khóa JSON của tài khoản dịch vụ (service account) đã tải xuống.

    3. Amazon Web Services (Amazon Bedrock). Không được phép dùng cặp khóa truy cập của người dùng IAM (access key ID và secret access key), ngoại trừ các khóa API Bedrock ngắn hạn hết hạn trong vòng 12 giờ hoặc khi phiên Bedrock kết thúc, tùy theo mốc nào đến trước.

    4. Microsoft Azure (Azure AI Foundry). Không được phép dùng khóa API cũng như client secret hoặc chứng chỉ của service principal đã xuất.

  2. Xác thực đa yếu tố. Tại thời điểm Khách hàng truy cập CVP, xác thực đa yếu tố chống lừa đảo phải bảo vệ (i) tất cả các tài khoản có thể đăng nhập vào Không gian làm việc được cấp quyền hoặc nắm giữ thông tin xác thực của không gian làm việc đó, (ii) tài khoản của Người dùng được phê duyệt tại nhà cung cấp danh tính của Khách hàng, (iii) các danh tính AWS, Google Cloud hoặc Azure có thể gọi mô hình, (iv) quyền truy cập quản trị vào bất kỳ hệ thống nào cấp phát hoặc lưu trữ thông tin xác thực của mô hình, và (v) mọi máy tính ảo (virtual desktop) hoặc môi trường biệt lập (enclave) được dùng để đáp ứng các yêu cầu này. Xác thực đa yếu tố chống lừa đảo nghĩa là (i) khóa bảo mật FIDO2/WebAuthn, (ii) passkey, lưu trên thiết bị hoặc trong trình quản lý mật khẩu, hoặc (iii) thẻ thông minh/PIV, phù hợp với tài liệu tóm tắt của CISA “Implementing Phishing-Resistant MFA” và NIST SP 800-63B-4. SMS, cuộc gọi thoại, mã gửi qua email, mã từ ứng dụng xác thực và phê duyệt qua thông báo đẩy đều không đạt yêu cầu, đồng thời phải tắt tính năng đăng nhập bằng liên kết qua email (magic link).

  3. Tài khoản tổ chức. Người dùng được phê duyệt phải đăng nhập bằng tài khoản thuộc tên miền của Khách hàng. Không được phép dùng tài khoản cá nhân và tài khoản webmail.

  4. Người dùng được phê duyệt. Không gian làm việc được cấp quyền được giới hạn ở hai mươi lăm (25) Người dùng được phê duyệt, là những người trực tiếp thực hiện hoặc trực tiếp giám sát công việc mà quyền cấp đã được phê duyệt. Danh tính workload không được tính vào con số này. Khách hàng có thể yêu cầu thêm chỗ cho Người dùng được phê duyệt bằng văn bản (email là đủ). Chỉ những quản trị viên được chỉ định mới có thể thêm thành viên, thay đổi vai trò hoặc tạo danh tính workload hay thông tin xác thực trên Không gian làm việc được cấp quyền.

  5. Cổng kết nối (gateway). Nếu Khách hàng vận hành một gateway hoặc proxy đứng trước mô hình, gateway/proxy đó chỉ được cho phép Người dùng được phê duyệt hoặc danh tính workload của họ đi qua, phải dùng thông tin xác thực ngắn hạn của riêng nó, và chỉ cho phép Người dùng được phê duyệt cùng các nhóm bảo mật, quản trị CNTT hoặc tin cậy và an toàn (trust and safety) của Khách hàng truy cập nhật ký và bản ghi hội thoại của nó.

  6. Hệ thống thông tin xác thực do Khách hàng vận hành. Thông tin xác thực do hệ thống riêng của Khách hàng cấp phải hết hạn trong vòng 12 giờ, chỉ được cấp sau khi xác thực đa yếu tố chống lừa đảo (đối với con người) hoặc xác minh danh tính workload (đối với dịch vụ), và không được để lại bất kỳ thông tin xác thực tĩnh nào trên thiết bị đầu cuối, trong mã nguồn hoặc trong kho lưu trữ dùng chung. Các khóa và bí mật có thể cấp thông tin xác thực cho mô hình phải được lưu trong trình quản lý bí mật hoặc dịch vụ quản lý khóa có ghi nhật ký truy cập.

  7. Thu hồi. Khách hàng phải có khả năng thu hồi bất kỳ thông tin xác thực hoặc danh tính nào bị xâm phạm trong vòng 24 giờ.

  8. Gỡ quyền khi nghỉ việc hoặc chuyển công tác. Khách hàng phải xóa những Người dùng được phê duyệt đã nghỉ việc hoặc được điều chuyển, cùng danh tính workload của họ, khỏi Không gian làm việc được cấp quyền trong vòng ba (3) ngày làm việc.

  9. Lưu lượng mạng đi ra. Ở bất cứ nơi nào mô hình thực hiện công việc tấn công hoặc công việc mang tính agent, lưu lượng đi ra phải được giới hạn theo danh sách cho phép được thực thi bên ngoài máy chủ (host) và phải được ghi nhật ký. Các máy trạm chỉ dùng để nhập lời nhắc tương tác có thể dùng danh sách cho phép trên chính máy đó nếu bản thân công việc mang tính agent chạy trong một sandbox không thể thay đổi danh sách đó.

  10. Thiết bị được quản lý. Người dùng được phê duyệt chỉ được truy cập Không gian làm việc được cấp quyền từ các thiết bị do Khách hàng kiểm soát, được cập nhật hệ điều hành tự động hoặc theo lịch định kỳ, không được dùng thiết bị cá nhân.

  11. Kiểm tra lý lịch. Mọi Người dùng được phê duyệt, kể cả nhà thầu, phải vượt qua quy trình kiểm tra danh tính và, khi pháp luật cho phép, kiểm tra lý lịch tư pháp. Ở những nơi luật địa phương hạn chế việc kiểm tra lý lịch tư pháp, việc xác minh danh tính, quyền được làm việc hoặc xác minh việc làm sẽ được chấp nhận. Việc thẩm tra của chính phủ hoặc giấy phép an ninh (clearance) cũng đáp ứng yêu cầu này.

  12. Quy trình xử lý sự cố. Khách hàng phải duy trì một quy trình được lập thành văn bản cho các trường hợp nghi ngờ quyền cấp bị xâm phạm hoặc lạm dụng, bao gồm việc thu hồi thông tin xác thực và tạm ngưng chỗ ngồi (seat).

  13. Cơ quan chính phủ. Giấy phép vận hành (Authority to Operate) theo FISMA kèm đánh giá độc lập hằng năm của Tổng thanh tra (Inspector General) dựa trên NIST SP 800-53, hoặc một khung tương đương ở cấp quốc gia, sẽ đáp ứng các yêu cầu về Thiết bị được quản lý, Kiểm tra lý lịch và Quy trình xử lý sự cố. Tất cả các yêu cầu khác vẫn tiếp tục được áp dụng.

5. Quyền truy cập chuyên biệt (Specialized Access).

  1. Xác thực đa yếu tố. Tại thời điểm Khách hàng truy cập CVP, xác thực đa yếu tố chống lừa đảo phải bảo vệ (i) tất cả các tài khoản có thể đăng nhập vào Không gian làm việc được cấp quyền hoặc nắm giữ thông tin xác thực của không gian làm việc đó, (ii) tài khoản của Người dùng được phê duyệt tại nhà cung cấp danh tính của Khách hàng, (iii) các danh tính AWS, Google Cloud hoặc Azure có thể gọi mô hình, (iv) quyền truy cập quản trị vào bất kỳ hệ thống nào cấp phát hoặc lưu trữ thông tin xác thực của mô hình, và (v) mọi máy tính ảo (virtual desktop) hoặc môi trường biệt lập (enclave) được dùng để đáp ứng các yêu cầu này. Xác thực đa yếu tố chống lừa đảo nghĩa là (i) khóa bảo mật FIDO2/WebAuthn, (ii) passkey, lưu trên thiết bị hoặc trong trình quản lý mật khẩu, hoặc (iii) thẻ thông minh/PIV, phù hợp với tài liệu tóm tắt của CISA “Implementing Phishing-Resistant MFA” và NIST SP 800-63B-4. SMS, cuộc gọi thoại, mã gửi qua email, mã từ ứng dụng xác thực và phê duyệt qua thông báo đẩy đều không đạt yêu cầu, đồng thời phải tắt tính năng đăng nhập bằng liên kết qua email (magic link).

  2. Quản lý thông tin xác thực. Các yêu cầu sau áp dụng cho Khách hàng tùy theo (các) nền tảng triển khai mà Khách hàng dùng để truy cập mô hình. Với mỗi nền tảng áp dụng, tất cả Người dùng được phê duyệt và tất cả các workload phải xác thực bằng thông tin xác thực ngắn hạn do dịch vụ danh tính gốc của nền tảng đó cấp và quản lý.

    1. Anthropic (API và Console của bên thứ nhất). Không được phép dùng khóa API tĩnh hoặc có thời hạn dài, kể cả để truy cập tương tác vào Claude Console, Claude for Enterprise, Claude Code và các ứng dụng khác của Anthropic.

    2. Google Vertex. Không được phép dùng tệp khóa JSON của tài khoản dịch vụ (service account) đã tải xuống.

    3. Amazon Web Services (Amazon Bedrock). Không được phép dùng cặp khóa truy cập của người dùng IAM (access key ID và secret access key), ngoại trừ các khóa API Bedrock ngắn hạn hết hạn trong vòng 12 giờ hoặc khi phiên Bedrock kết thúc, tùy theo mốc nào đến trước.

    4. Microsoft Azure (Azure AI Foundry). Không được phép dùng khóa API cũng như client secret hoặc chứng chỉ của service principal đã xuất.

  3. Đăng nhập một lần và tài khoản tổ chức. Người dùng được phê duyệt phải đăng nhập bằng tài khoản thuộc tên miền riêng của Khách hàng. Người dùng được phê duyệt phải đăng nhập bằng danh tính thuộc tên miền tổ chức được liên kết (federated) thông qua hệ thống đăng nhập một lần (SSO) của Khách hàng. Không được phép dùng tài khoản cá nhân, tài khoản webmail và tài khoản không được liên kết.

  4. Người dùng được phê duyệt. Không gian làm việc được cấp quyền được giới hạn ở 25 Người dùng được phê duyệt, là những người trực tiếp thực hiện hoặc trực tiếp giám sát công việc mà quyền cấp đã được phê duyệt. Danh tính workload không được tính vào con số này. Khách hàng có thể yêu cầu thêm chỗ cho Người dùng được phê duyệt bằng văn bản (email là đủ). Chỉ những quản trị viên được chỉ định mới có thể thêm thành viên, thay đổi vai trò hoặc tạo danh tính workload hay thông tin xác thực trên Không gian làm việc được cấp quyền.

  5. Cổng kết nối (gateway). Nếu Khách hàng vận hành một gateway hoặc proxy đứng trước mô hình, gateway/proxy đó chỉ được cho phép Người dùng được phê duyệt hoặc danh tính workload của họ đi qua, phải dùng thông tin xác thực ngắn hạn của riêng nó, và chỉ cho phép Người dùng được phê duyệt cùng các nhóm bảo mật, quản trị CNTT hoặc tin cậy và an toàn (trust and safety) của Khách hàng truy cập nhật ký và bản ghi hội thoại của nó.

  6. Hệ thống thông tin xác thực do Khách hàng vận hành. Thông tin xác thực do hệ thống riêng của Khách hàng cấp phải hết hạn trong vòng 12 giờ, chỉ được cấp sau khi xác thực đa yếu tố chống lừa đảo (đối với con người) hoặc xác minh danh tính workload (đối với dịch vụ), và không được để lại bất kỳ thông tin xác thực tĩnh nào trên thiết bị đầu cuối, trong mã nguồn hoặc trong kho lưu trữ dùng chung. Các khóa và bí mật có thể cấp thông tin xác thực cho mô hình phải được lưu trong trình quản lý bí mật hoặc dịch vụ quản lý khóa có ghi nhật ký truy cập.

  7. Thu hồi. Khách hàng phải có khả năng thu hồi bất kỳ thông tin xác thực hoặc danh tính nào bị xâm phạm trong vòng 24 giờ.

  8. Gỡ quyền khi nghỉ việc hoặc chuyển công tác. Khách hàng phải xóa những Người dùng được phê duyệt đã nghỉ việc hoặc được điều chuyển, cùng danh tính workload của họ, khỏi Không gian làm việc được cấp quyền trong vòng 3 ngày làm việc.

  9. Lưu lượng mạng đi ra. Ở bất cứ nơi nào mô hình thực hiện công việc tấn công hoặc công việc mang tính agent, lưu lượng đi ra phải được giới hạn theo danh sách cho phép được thực thi bên ngoài máy chủ (host) và phải được ghi nhật ký. Các máy trạm chỉ dùng để nhập lời nhắc tương tác có thể dùng danh sách cho phép trên chính máy đó nếu bản thân công việc mang tính agent chạy trong một sandbox không thể thay đổi danh sách đó.

  10. Thiết bị được quản lý và bảo vệ chống phần mềm độc hại. Người dùng được phê duyệt chỉ được truy cập Không gian làm việc được cấp quyền từ các thiết bị do Khách hàng kiểm soát, không được dùng thiết bị cá nhân, và các thiết bị đó phải được cập nhật hệ điều hành tự động hoặc theo lịch định kỳ. Mọi thiết bị mà Người dùng được phê duyệt dùng để truy cập Không gian làm việc được cấp quyền đều phải do Khách hàng quản lý và phải chạy cơ chế danh sách cho phép hoặc danh sách chặn ứng dụng ở chế độ thực thi (enforce), hoặc một agent phát hiện và phản hồi điểm cuối (EDR) ở chế độ chặn hoặc ngăn chặn (block/prevent). Một máy tính ảo hoặc môi trường biệt lập được quản lý đáp ứng tiêu chuẩn này cũng được chấp nhận.

  11. Kiểm tra lý lịch. Mọi Người dùng được phê duyệt, kể cả nhà thầu, phải vượt qua quy trình kiểm tra danh tính và, khi pháp luật cho phép, kiểm tra lý lịch tư pháp. Ở những nơi luật địa phương hạn chế việc kiểm tra lý lịch tư pháp, việc xác minh danh tính, quyền được làm việc hoặc xác minh việc làm sẽ được chấp nhận. Việc thẩm tra của chính phủ hoặc giấy phép an ninh (clearance) cũng đáp ứng yêu cầu này.

  12. Quy trình xử lý sự cố. Khách hàng phải duy trì một quy trình được lập thành văn bản cho các trường hợp nghi ngờ quyền cấp bị xâm phạm hoặc lạm dụng, bao gồm việc thu hồi thông tin xác thực, tạm ngưng chỗ ngồi (seat) và thông báo cho Anthropic.

  13. Cơ quan chính phủ. Giấy phép vận hành (Authority to Operate) theo FISMA kèm đánh giá độc lập hằng năm của Tổng thanh tra (Inspector General) dựa trên NIST SP 800-53, hoặc một khung tương đương ở cấp quốc gia, sẽ đáp ứng các yêu cầu về Thiết bị được quản lý và bảo vệ chống phần mềm độc hại, Kiểm tra lý lịch và Quy trình xử lý sự cố. Tất cả các yêu cầu khác vẫn tiếp tục được áp dụng.

✦ LIÊN HỆ TƯ VẤN CÁC DỊCH VỤ AI

Hỗ trợ tư vấn, đào tạo và chuyển giao giải pháp AI cho cá nhân, doanh nghiệp và tổ chức.

Nguồn tài liệu tham khảo: Bài viết được chuyển ngữ và tổng hợp từ tài liệu hỗ trợ chính thức của Anthropic Claude Support: https://support.claude.com/en/articles/17202708-cyber-verification-program-security-requirements ↗
Bản quyền nội dung gốc thuộc về Anthropic. Bản dịch tiếng Việt phục vụ mục đích học tập và tra cứu cộng đồng.
Chat Zalo Chat Zalo
Gọi ngay Chat