Cloudflare giới thiệu mô hình kiểm soát truy cập dành riêng cho AI Agent

Trong mười hai năm qua, bảo mật doanh nghiệp đã chuyển dịch khỏi việc tin tưởng vào mạng nội bộ. BeyondCorp đã lập luận rằng nguồn gốc của một yêu cầu, dù là bên trong phạm vi doanh nghiệp hay trên Internet công cộng, không nên là yếu tố quyết định việc yêu cầu đó có được cho phép hay không. Thay vào đó, danh tính và tình trạng thiết bị mới là yếu tố quyết định. Mô hình đó đã chiến thắng: hiện nay nó là nền tảng cho phần lớn các kiến trúc Zero Trust.

BeyondCorp của Google giả định một chủ thể cụ thể: một con người sử dụng thiết bị, hoạt động với tốc độ của con người. Các tổ chức hiện đang triển khai các tác nhân (agent) – những chủ thể phần mềm có khả năng suy luận, hành động và truy cập vào các hệ thống thay mặt chúng ta. Một tác nhân chạy theo phạm vi nhiệm vụ (task-scoped) có tính chất tạm thời. Nó kết thúc khi công việc hoàn thành. Một dịch vụ tác nhân tồn tại lâu dài có thể xử lý nhiều nhiệm vụ như vậy và di chuyển dữ liệu nhanh hơn con người rất nhiều.

Các biện pháp kiểm soát mà chúng ta xây dựng cho con người không phát đi cảnh báo lỗi khi chúng ta áp dụng chúng cho các tác nhân. Chúng thất bại một cách âm thầm bằng cách cấp quyền quá mức, giám sát quá ít và tin tưởng quá lâu.

Bài viết này đề xuất một mô hình truy cập dành cho các tác nhân: Mô hình Truy cập Tác nhân (Agent Access Model - AAM). Chúng tôi mô tả mô hình này và chỉ ra cách xây dựng các thành phần của nó. Sau đó, chúng tôi đi qua một ví dụ cụ thể và tách biệt các biện pháp kiểm soát đơn chủ thể hiện có với vấn đề khó khăn hơn là kiểm soát truy cập đa chủ thể.

Phần lớn các công việc hiện nay cố gắng làm cho mỗi quyết định truy cập trở nên thông minh hơn. AAM áp dụng một cách tiếp cận khác: thu hẹp khả năng của tác nhân, để ngay từ đầu có ít thứ cần phải đánh giá hơn.

Sự chuyển dịch

Một thập kỷ trước, câu hỏi hóc búa trong bảo mật doanh nghiệp là yêu cầu này đến từ đâu, và liệu tôi có tin tưởng nơi đó không? Câu trả lời của BeyondCorp là bạn không nên tin tưởng nơi đó chút nào. Bạn xác thực người dùng, kiểm tra thiết bị và đưa ra quyết định truy cập cho yêu cầu cụ thể đó. Vị trí trở thành một tín hiệu trong số nhiều tín hiệu, chứ không phải là một phán quyết cuối cùng.

Việc tái định hình đó hiệu quả vì chủ thể rất dễ nhận diện. Một con người đăng nhập mỗi sáng, mang theo một hoặc hai thiết bị, làm việc với tốc độ của con người và tạo ra một luồng quyết định truy cập mà hệ thống có thể suy luận được. Chúng ta đã xây dựng cả một ngành công nghiệp xoay quanh hình thái chủ thể đó: đăng nhập một lần (SSO), tình trạng thiết bị, truy cập có điều kiện, chấm điểm rủi ro phiên làm việc.

Các tác nhân không có hình thái đó.

Một dịch vụ tác nhân có thể chạy nhiều nhiệm vụ. Trong bài viết này, một tác nhân là một lần chạy theo phạm vi nhiệm vụ. Chúng tôi sử dụng đồ thị thực thi nhiệm vụ (task execution graph) cho tất cả công việc thuộc về lần chạy đó và được quản lý bởi cùng một giới hạn năng lực và mức độ tin cậy. Cùng một bộ khung (harness) giải quyết một nhiệm vụ khác, tiêu thụ một sự kiện khác hoặc chạy theo lịch trình khác sẽ tạo ra một đồ thị mới. Một chỉ dẫn duy nhất từ con người (đối soát hai sổ cái này, phân loại các cảnh báo qua đêm, mở một pull request để sửa lỗi này) có thể điều phối một hoặc nhiều nhiệm vụ như vậy. Mỗi nhiệm vụ có thể cần truy cập vào cơ sở dữ liệu, quản lý mã nguồn, nhật ký, hệ thống quản lý yêu cầu (ticketing systems), cơ sở tri thức, tài liệu hoặc bảng tính. Nhiệm vụ có thể cần quyền truy cập rộng. Nó cần quyền đó ngay bây giờ, cho nhiệm vụ này, và lý tưởng nhất là không được lâu hơn dù chỉ một giây.

Một tác nhân phải có đủ thẩm quyền để hoàn thành nhiệm vụ của mình và không được nhiều hơn thế. Nguyên tắc đặc quyền tối thiểu (least privilege) đã có từ lâu như chính việc kiểm soát truy cập. Điều thay đổi là tốc độ và tần suất cần phải thực thi nó. Đối với lực lượng lao động là con người, đặc quyền tối thiểu thường là một chính sách được xem xét hàng quý. Đối với số lượng lớn các tác nhân tồn tại ngắn hạn, đó là một hệ thống chạy theo thời gian thực và để lại dấu vết kiểm toán.

Tại sao mô hình con người không thể áp dụng

Các tác nhân trông giống như các tài khoản dịch vụ hoặc người dùng có tốc độ xử lý rất nhanh. Bốn đặc tính khiến cả hai bộ kiểm soát này trở nên không phù hợp.

Các tác nhân có tính tạm thời. Thông tin xác thực lại có tính bền vững. Các tài khoản dịch vụ được thiết kế cho phần mềm tồn tại lâu dài: hệ thống lương, công việc hàng loạt hàng đêm. Chúng thường đi kèm với các khóa tồn tại lâu dài, phạm vi rộng và tần suất xoay vòng hiếm. Khi áp dụng cho các tác nhân ngắn hạn, những thông tin xác thực đó tồn tại lâu hơn công việc mà chúng được cấp và vẫn nằm trong bộ nhớ, nhật ký hoặc các biến môi trường nơi chúng có thể bị phát lại. Thời hạn của thông tin xác thực phải khớp với thời hạn của nhiệm vụ. Đối với một tác nhân, thời hạn đó thường chỉ tính bằng phút.

Các tác nhân hành động ở tốc độ máy. Các biện pháp phát hiện bất thường, giới hạn tốc độ và kiểm soát mất mát dữ liệu được tinh chỉnh cho hoạt động của con người có thể phản ứng quá chậm. Một tác nhân có kết nối cơ sở dữ liệu và đường truyền mạng ra ngoài có thể đọc một bảng và POST nó đến một điểm cuối bên ngoài trước khi một biện pháp kiểm soát do con người tinh chỉnh kịp lấy mẫu. Do đó, các biện pháp kiểm soát ngăn chặn phải chạy nội tuyến (inline), ngay tại điểm hành động.

Lời nhắc (prompt) không phải là một vành đai bảo mật. Các nhóm thường yêu cầu tác nhân không được truy cập vào môi trường production hoặc không bao giờ gửi dữ liệu cho bên thứ ba. Những chỉ dẫn đó giúp định hình hành vi, nhưng chúng không thực thi quyền truy cập. Một mô hình có thể bị thao túng bởi nội dung được chèn vào dữ liệu mà nó đọc hoặc có thể tự thực hiện một hành động không an toàn. Ý định được suy luận có thể cung cấp thông tin cho quyết định rủi ro, nhưng kẻ tấn công có thể định hình tín hiệu đó thông qua chính văn bản đó. Việc thực thi thuộc về bộ khung (harness) trung gian các lệnh gọi công cụ và tại lớp mạng trung gian các gói tin. Một ranh giới mà bạn có thể dùng lời nói để vượt qua thì không phải là một ranh giới.

Các tác nhân tổng hợp thẩm quyền qua nhiều bước trung gian (hops). Một tác nhân có thể gọi một công cụ, công cụ đó lại gọi một tác nhân khác, và tác nhân này gọi một API thay mặt cho con người ban đầu. Ở đâu đó trong chuỗi đó, câu trả lời cho việc "đây là dành cho ai" và "họ được phép làm gì" có thể biến mất. Các nguyên thủy (primitives) hiện có xử lý một bước ủy quyền đơn lẻ tốt hơn là xử lý nhiều bước hoặc nhiều con người.

Mô hình Truy cập Tác nhân (Agent Access Model)

Mô hình Truy cập Tác nhân bắt đầu với một quy tắc: Không tin tưởng vào lần chạy (run). Hãy ủy quyền mọi hành động dựa trên nhiệm vụ và trạng thái tích lũy của nó.

BeyondCorp đã loại bỏ sự tin tưởng ngầm định khỏi mạng. AAM loại bỏ sự tin tưởng ngầm định khỏi đồ thị thực thi nhiệm vụ. Việc ủy quyền cho một hành động không được chuyển sang hành động tiếp theo. Mỗi hành động được đánh giá dựa trên ba yếu tố: tác nhân đó là ai, nó được ủy quyền thực hiện nhiệm vụ gì và đồ thị đã chạm vào những tài nguyên liên quan đến chính sách nào. Trạng thái tích lũy đó chỉ có thể làm giảm khả năng còn lại của đồ thị.

Beyond Zero của Google thực hiện bước đi đầu tiên tương tự: thu hẹp ranh giới tin cậy từ ứng dụng xuống từng hành động riêng lẻ và đưa ra quyết định ở tốc độ máy. Beyond Zero đặt một công cụ suy luận đằng sau mỗi quyết định ủy quyền. AAM giới hạn tập hợp năng lực mà công cụ đó phải đánh giá. Hai cách tiếp cận này khớp với nhau. Đối với các hành động vượt qua ranh giới trung gian đã khai báo, AAM ghi lại tác nhân, chủ thể và nhiệm vụ đằng sau mỗi quyết định ủy quyền.

AAM có năm nguyên tắc.

1. Thông tin xác thực có thời hạn ngắn và bị ràng buộc. Một tác nhân nhận được thông tin xác thực được tạo ra cho nhiệm vụ đó và hết hạn cùng với nhiệm vụ. Các token bị ràng buộc với người gửi, vì vậy một token bị đánh cắp không thể bị phát lại nếu không có khóa chứng thực do bộ khung (harness) nắm giữ.

2. Việc thực thi nằm ở bộ khung và mạng, không phải ở lời nhắc (prompt). Chính sách được áp dụng tại nơi các lệnh gọi công cụ và yêu cầu mạng thực sự diễn ra. Lời nhắc là nơi bạn thể hiện ý định. Nó không bao giờ là nơi bạn thực thi một ranh giới.

3. Sự giám sát của con người là ngoại lệ. Việc phê duyệt chỉ dành cho các quyết định thực sự cần thiết. Việc yêu cầu con người phê duyệt từng bước sẽ tạo ra sự mệt mỏi và thói quen nhấp chuột phản xạ.

4. Các quyền được xem xét dựa trên bằng chứng. Hoạt động được ghi lại trực tiếp có thể cho thấy nơi một mẫu nhiệm vụ quá rộng hoặc quá hẹp. Hệ thống đề xuất thay đổi để xem xét, và thay đổi được phê duyệt sẽ áp dụng cho các nhiệm vụ trong tương lai. Nó không bao giờ mở rộng nhiệm vụ đang hoạt động.

5. Trạng thái năng lực di chuyển theo một hướng. Khi một sự kiện được bảo vệ đã khai báo xảy ra, Trust Ratchet (Cơ chế chốt tin cậy) sẽ loại bỏ các năng lực trên toàn bộ đồ thị thực thi nhiệm vụ theo chính sách. Thẩm quyền bị loại bỏ bởi Trust Ratchet chỉ có thể quay lại trong một nhiệm vụ mới được ủy quyền.

Một kiến trúc tham chiếu

Kiến trúc này có bốn biện pháp kiểm soát chủ động và hai hệ thống hỗ trợ. Các biện pháp kiểm soát chủ động quản lý nhiệm vụ. Nhật ký Hoạt động Tác nhân (Agent Activity Log) và Vòng lặp Xem xét Quyền (Grant Review Loop) hoạt động dựa trên bằng chứng mà nhiệm vụ để lại. AAM xác định cách các mảnh ghép này khớp với nhau và những gì mỗi phần phải đảm bảo. Đây là một kiến trúc tham chiếu, không phải là đặc tả kỹ thuật ở cấp độ dây dẫn.

4.1 Nhà môi giới Danh tính Tác nhân (Agent Identity Broker)

Tại thời điểm điều phối, Nhà môi giới Danh tính Tác nhân cấp một thông tin xác thực có thời hạn ngắn, có thể xác minh và được giới hạn trong phạm vi nhiệm vụ. Thông tin xác thực đó hết hạn không muộn hơn thời điểm nhiệm vụ kết thúc.

Thông tin xác thực được giới hạn theo nhiệm vụ: nó mã hóa "đây là tác nhân X, hành động thay mặt cho chủ thể H, để thực hiện nhiệm vụ T". Nó cũng bị ràng buộc với người gửi, gắn liền với một khóa chứng thực do bộ khung nắm giữ. Một token bị rò rỉ không thể bị phát lại nếu không có khóa đó, và mô hình không bao giờ nhận được khóa này.

Các tiêu chuẩn hiện có cung cấp cả hai nguyên thủy này. OAuth 2.0 Token Exchange (RFC 8693) xác định việc trao đổi thông qua Dịch vụ Token Bảo mật và có thể tạo ra một token được thu hẹp theo đối tượng, tài nguyên hoặc phạm vi. Chính sách của máy chủ ủy quyền xác định những gì nó cấp. Claim "act" của token xác định tác nhân hiện tại, trong khi các claim "act" lồng nhau có thể lưu giữ các tác nhân trước đó để quy trách nhiệm. DPoP (RFC 9449) ràng buộc một token OAuth với một khóa khách hàng và yêu cầu chứng thực trên mỗi yêu cầu được bảo vệ. Chứng thực đó bao gồm phương thức HTTP và URI mục tiêu, nhưng không bao gồm phần thân yêu cầu, tham số truy vấn hoặc đối số công cụ. Do đó, bộ khung phải ủy quyền cho một biểu diễn yêu cầu bất biến và thực thi chính yêu cầu đó.

Không tiêu chuẩn nào xác định mẫu nhiệm vụ, trạng thái Trust Ratchet hoặc việc thực thi đa lớp của AAM. Bản dự thảo AAuth 09 giải quyết vấn đề danh tính và ủy quyền từ tác nhân đến tài nguyên, bao gồm danh tính theo từng phiên bản, nhiệm vụ tùy chọn, quyền công cụ, kiểm toán và ủy quyền bất đồng bộ. Nó có thể hiện thực hóa một phần của mô hình này và vẫn đang trong quá trình phát triển. AAM phụ thuộc vào bốn đặc tính của thông tin xác thực: thời hạn ngắn, giới hạn theo nhiệm vụ, ràng buộc với người gửi và có thể quy trách nhiệm. Nó không phụ thuộc vào việc một giao thức cụ thể nào đó phải chiến thắng.

4.2 Công cụ Truy cập theo Phạm vi Nhiệm vụ (Task-Scoped Access Engine)

Thông tin xác thực thiết lập tác nhân đó là ai và nó đang thực hiện nhiệm vụ nào. Công cụ Truy cập theo Phạm vi Nhiệm vụ quyết định, trên mỗi yêu cầu, liệu danh tính này có được phép thực hiện hành động này đối với tài nguyên này hay không. Nó mở rộng Công cụ Kiểm soát Truy cập của BeyondCorp bằng cách biến chính nhiệm vụ thành một đầu vào hạng nhất cho quyết định.

Công việc của nó là làm cho đặc quyền tối thiểu trở thành cả mặc định và giới hạn tối đa. Một quyền cấp cho nhiệm vụ có thể đọc là: "tác nhân X, cho nhiệm vụ T, có thể đọc các bảng A, B và C trong mười phút tới". Đó là phạm vi bao bọc. Các hành động không được khai báo sẽ bị từ chối.

Phạm vi bao bọc đó đến từ đâu? Phạm vi của một nhiệm vụ được khai báo khi tác nhân được điều phối, không phải do tác nhân thương lượng khi đang chạy. Trong trường hợp phổ biến, một con người hoặc một hệ thống hành động theo thẩm quyền thường trực của con người sẽ xác định một mẫu nhiệm vụ một lần: "Đối soát có thể đọc ba bảng này và đăng lên kênh này". Mỗi lần điều phối sẽ khởi tạo nó. Các mẫu là đơn vị cấu hình, vì vậy số lượng chính sách theo sát số lượng các nhiệm vụ riêng biệt thay vì số lần chạy. Tại thời điểm điều phối, Công cụ Truy cập giao thoa mẫu đã phê duyệt với thẩm quyền của chủ thể khởi tạo và dịch vụ tác nhân, sau đó áp dụng chính sách của chủ sở hữu tài nguyên và người thuê. Sự giao thoa đó là giới hạn năng lực của nhiệm vụ. Tác nhân có thể yêu cầu ít hơn, và Trust Ratchet có thể loại bỏ các năng lực. Thẩm quyền rộng hơn đòi hỏi một nhiệm vụ mới được ủy quyền.

Đối với mỗi hành động, bộ điều hợp (adapter) xây dựng và đóng băng biểu diễn yêu cầu hoàn chỉnh, bao gồm thao tác, tài nguyên, các đối số ảnh hưởng đến phạm vi, người thuê và người nhận. Công cụ Truy cập ủy quyền biểu diễn đó dựa trên giới hạn năng lực hiện tại, và bộ điều hợp thực thi chính biểu diễn đó. Việc gia hạn thông tin xác thực sẽ xác thực lại giới hạn ban đầu và trạng thái Trust Ratchet hiện tại. Nó không thể khôi phục một năng lực đã bị loại bỏ hoặc kéo dài thời hạn tối đa của nhiệm vụ.