Rà soát quyền truy cập AI API là biện pháp kiểm soát chứng minh rằng mọi khóa cổng (gateway key) vẫn có đúng chủ sở hữu, phạm vi, môi trường, kế hoạch luân chuyển và quy trình hủy quyền khi nghỉ việc. Đây không chỉ là một cuộc quét bí mật (secrets scan). Đây là cuộc rà soát định kỳ để trả lời các câu hỏi liệu mỗi khóa có nên tiếp tục tồn tại hay không, ai chịu trách nhiệm về nó, nó có thể truy cập những gì, nó có thể tạo ra chi tiêu bao nhiêu, nhật ký nào chứng minh việc sử dụng nó, và điều gì sẽ xảy ra khi một người, nhà cung cấp, dự án hoặc workload rời đi.
Điều này quan trọng hơn đối với các cổng AI so với các khóa API dịch vụ đơn lẻ thông thường. Một thông tin xác thực cổng có thể truy cập nhiều mô hình, nhà cung cấp, họ điểm cuối (endpoint families), ngân sách và sản phẩm. Một khóa cũ có thể duy trì hoạt động của một quy trình tự động hóa đã ngừng hoạt động. Một khóa có phạm vi rộng có thể cho phép một tác vụ trong môi trường sandbox gọi các mô hình sản phẩm (production models). Khóa của một nhà thầu đã nghỉ việc vẫn có thể gửi yêu cầu thông qua một tích hợp dùng chung. Một tuyến dự phòng (fallback route) có thể tiếp tục sử dụng một nhà cung cấp mà bộ phận mua sắm không còn phê duyệt.
Sử dụng cuộc rà soát quyền truy cập AI API này để biến quyền truy cập cổng thành một tệp bằng chứng do người mua sở hữu. Cuộc rà soát này sẽ cho phép các đội ngũ bảo mật, nền tảng, mua sắm, tài chính và sản phẩm trả lời cùng những câu hỏi sau này: ai sở hữu khóa này, tại sao nó tồn tại, phạm vi nào được phép, nó được luân chuyển khi nào, nó có thể gọi những tuyến nào, và sự kiện hủy quyền nào sẽ thu hồi nó?
Đối với người mua Flatkey, việc rà soát thuộc về tài khoản cổng và bề mặt khóa/tuyến (key/route surface). Trang web công khai hiện tại của Flatkey định vị sản phẩm là một cổng AI API duy nhất cho việc truy cập mô hình, định tuyến, thanh toán, phân tích sử dụng và kiểm soát vận hành, với một khóa API, một URL cơ sở và một bảng điều khiển. Điều đó làm cho cổng trở thành một nơi hữu ích để tập trung hóa bằng chứng truy cập. Nó không loại bỏ nhu cầu xác minh các vai trò cụ thể của tài khoản, nhật ký, xử lý payload thô, điều khoản của nhà cung cấp và các thủ tục hủy quyền trước khi sử dụng trong môi trường sản phẩm.
Một cuộc rà soát quyền truy cập AI API phải quyết định những gì
Một cuộc rà soát quyền truy cập AI API nên phê duyệt thông tin xác thực và tuyến mà nó có thể truy cập. Nếu cuộc rà soát chỉ dừng lại ở việc "khóa vẫn hoạt động", nó sẽ bỏ lỡ rủi ro về quản trị.
| Lĩnh vực rà soát | Quyết định cần đưa ra | Bằng chứng cần lưu giữ | Điều kiện thất bại |
|---|---|---|---|
| Mục đích kinh doanh | Sản phẩm, quy trình làm việc hoặc đội ngũ nào cần khóa này? | Hồ sơ trường hợp sử dụng, phê duyệt của chủ sở hữu, thẻ môi trường | Không có chủ sở hữu kinh doanh hiện tại |
| Chủ sở hữu là con người | Ai chấp nhận rủi ro và ngân sách cho khóa này? | Chủ sở hữu được chỉ định, chủ sở hữu dự phòng, ánh xạ quản lý hoặc đội ngũ | Chủ sở hữu đã nghỉ việc, không xác định, hoặc chỉ là hộp thư dùng chung |
| Chủ sở hữu kỹ thuật | Ai có thể luân chuyển, vô hiệu hóa và khắc phục sự cố của khóa? | Runbook, nhóm trực, đường dẫn kho khóa (key vault) | Không ai có thể luân chuyển nó một cách an toàn |
| Môi trường | Đây là quyền truy cập cho dev, staging, production, CI, nhà cung cấp hay break-glass? | Thẻ môi trường, ranh giới dự án, cấu hình tuyến | Khóa không dành cho sản phẩm có thể gọi các tuyến sản phẩm |
| Phạm vi | Nó có thể sử dụng những mô hình, điểm cuối, công cụ, tệp, prompt, xuất dữ liệu sử dụng, API quản trị hoặc tuyến nào? | Danh sách phạm vi, ánh xạ vai trò, cài đặt nhà cung cấp | Phạm vi rộng hơn yêu cầu của workload |
| Ngân sách và hạn ngạch | Áp dụng các giới hạn chi tiêu, token, tốc độ và mô hình nào? | Chính sách hạn ngạch, chủ sở hữu cảnh báo, người rà soát tài chính | Khóa có thể chi tiêu mà không có chủ sở hữu được chỉ định |
| Ghi nhật ký và kiểm toán | Những sự kiện nào chứng minh việc sử dụng và thay đổi? | Siêu dữ liệu yêu cầu, nhật ký thay đổi tuyến, nhật ký thay đổi khóa, các hàng dữ liệu sử dụng | Việc sử dụng không thể liên kết với khóa, chủ sở hữu, tuyến và thời gian |
| Luân chuyển | Khóa cũ sẽ được thay thế như thế nào mà không gây gián đoạn? | Ngày luân chuyển, chuyển đổi sang khóa thứ hai, kiểm tra lần sử dụng cuối, bằng chứng xóa | Khóa không có trình kích hoạt luân chuyển hoặc hết hạn |
| Hủy quyền khi nghỉ việc | Sự kiện nào thu hồi quyền truy cập? | Trình kích hoạt khi nhân sự/nhà cung cấp/dự án kết thúc, xóa khỏi nhóm, hồ sơ vô hiệu hóa khóa | Khóa vẫn tồn tại sau khi người dùng, nhà cung cấp hoặc dự án kết thúc |
Đầu ra là một sổ đăng ký truy cập cộng với danh sách hành động: giữ lại, thu hẹp, luân chuyển, gán lại, vô hiệu hóa, xóa hoặc leo thang.
Xây dựng sổ đăng ký khóa trước tiên
Đừng bắt đầu một cuộc rà soát quyền truy cập AI API bằng cách luân chuyển khóa một cách mù quáng. Hãy xây dựng một sổ đăng ký mô tả vai trò thực tế của khóa trong môi trường sản phẩm.
Mỗi khóa cổng nên có các trường sau:
| Trường | Tại sao nó quan trọng |
|---|---|
| Bí danh hoặc ID của khóa | Cho phép người rà soát thảo luận về khóa mà không để lộ giá trị bí mật |
| Dự án hoặc không gian làm việc của cổng | Phân tách ranh giới sản phẩm, môi trường, khách hàng hoặc đội ngũ |
| Chủ sở hữu và chủ sở hữu dự phòng | Ngăn chặn quyền truy cập mồ côi và việc luân chuyển bị đình trệ |
| Workload hoặc tích hợp | Cho biết tại sao khóa tồn tại và nó được triển khai ở đâu |
| Môi trường | Ngăn chặn môi trường dev, test, CI và production chia sẻ thông tin xác thực |
| Các tuyến và mô hình được phép | Làm cho việc rà soát quyền truy cập AI trở nên cụ thể đối với hành vi của mô hình và điểm cuối |
| Các điểm cuối và công cụ được phép | Ghi nhận liệu khóa có thể gọi các API trò chuyện, hình ảnh, video, tệp, thực thi công cụ hoặc API quản trị hay không |
| Phạm vi hoặc vai trò | Chứng minh nguyên tắc đặc quyền tối thiểu thay vì quyền truy cập quản trị được kế thừa |
| Vị trí lưu trữ bí mật | Cho biết liệu khóa có nằm trong kho (vault), kho bí mật CI, tệp cục bộ hay một vị trí không được hỗ trợ |
| Lần sử dụng cuối và mẫu sử dụng | Phân biệt các khóa đang hoạt động với các thông tin xác thực cũ hoặc bị rò rỉ |
| Chủ sở hữu chi phí và hạn ngạch | Gắn kết chi tiêu mô hình với một chủ sở hữu ngân sách |
| Ngày và phương pháp luân chuyển | Cho biết khi nào và làm thế nào khóa có thể được thay thế |
| Trình kích hoạt hủy quyền | Xác định thay đổi nào sẽ thu hồi hoặc thu hẹp quyền truy cập |
Sổ đăng ký không nên bao gồm các giá trị bí mật. Nó nên bao gồm đủ siêu dữ liệu để luân chuyển và thu hồi khóa một cách nhanh chóng.
Gán chủ sở hữu trước phạm vi
Một cuộc rà soát quyền truy cập AI API sẽ thất bại khi mọi khóa đều thuộc về "bộ phận kỹ thuật" hoặc "đội ngũ nền tảng". Việc sở hữu chung khiến quyền truy cập vẫn tồn tại sau khi nhân viên, nhà thầu, nhà cung cấp và các dự án không còn nữa.
Sử dụng bốn vai trò chủ sở hữu:
| Vai trò chủ sở hữu | Chịu trách nhiệm về | Nên phê duyệt |
|---|---|---|
| Chủ sở hữu kinh doanh | Liệu quy trình công việc có còn cần truy cập AI không | Giữ, loại bỏ hoặc chuyển giao khóa |
| Chủ sở hữu kỹ thuật | Luân chuyển, lưu trữ, triển khai, khôi phục và ứng phó sự cố | Kế hoạch luân chuyển và bằng chứng chuyển đổi |
| Chủ sở hữu bảo mật | Phạm vi, đặc quyền tối thiểu, ghi nhật ký, lộ dữ liệu và hủy quyền khi nghỉ việc | Thay đổi phạm vi và xử lý ngoại lệ |
| Chủ sở hữu tài chính hoặc vận hành | Chi tiêu, hạn ngạch, bất thường về sử dụng và đối chiếu hóa đơn | Chính sách ngân sách và hạn ngạch |
Chủ sở hữu kinh doanh và chủ sở hữu kỹ thuật không nên là cùng một người đại diện trừ khi đội ngũ rất nhỏ. Một khóa sản xuất cần một người chấp nhận rủi ro kinh doanh và một người có thể thay đổi thông tin xác thực một cách an toàn.
Đối với các khóa do người sở hữu, yêu cầu một người cụ thể cùng với đội ngũ. Đối với các khóa do dịch vụ sở hữu, yêu cầu một tài khoản dịch vụ, danh tính workload, kho lưu trữ, đường ống triển khai và nhóm chủ sở hữu. Đối với các khóa của nhà cung cấp, yêu cầu chủ sở hữu hợp đồng, chủ sở hữu dữ liệu, ngày hết hạn và kế hoạch gỡ bỏ.
Rà soát phạm vi so với workload thực tế
Đặc quyền tối thiểu là cốt lõi của việc rà soát quyền truy cập AI API. Câu hỏi không phải là "người dùng này có cần AI không?" mà là "workload này cần chính xác những hành động API nào?"
Hướng dẫn RBAC của OpenAI là một mô hình hữu ích vì nó phân tách vai trò tổ chức, vai trò dự án, nhóm, quyền, khóa API dự án, quản trị dự án và tài khoản dịch vụ. Hướng dẫn này cũng lưu ý rằng ranh giới dự án có thể cô lập các môi trường thử nghiệm, staging và sản xuất. Hãy áp dụng tư duy tương tự cho bất kỳ cổng AI nào: giới hạn phạm vi của khóa ở dự án, route, endpoint, lớp mô hình và bộ hành động nhỏ nhất hỗ trợ cho workload.
Tài liệu về liên kết danh tính workload của OpenAI bổ sung một mẫu quan trọng khác: các danh tính bên ngoài có thể được ánh xạ tới một tài khoản dịch vụ, dự án cụ thể và các quyền API tùy chọn, và các quyền ánh xạ đó không thể cấp quyền truy cập vượt quá tài khoản dịch vụ đã được ánh xạ. Đó là mô hình tư duy đúng đắn cho việc truy cập cổng: một công việc CI, workload máy chủ hoặc tự động hóa không nên kế thừa quyền truy cập console rộng rãi của một chủ sở hữu là con người.
Đối với mỗi khóa, hãy ghi lại xem nó có thể:
- Thực hiện các yêu cầu mô hình.
- Chỉ sử dụng các mô hình đã được phê duyệt hoặc các route dự phòng.
- Gọi các endpoint tệp, vector, prompt, eval, batch, hình ảnh, âm thanh, video hoặc quản trị.
- Đọc dữ liệu xuất sử dụng hoặc dữ liệu thanh toán.
- Thay đổi route, hạn ngạch, khóa, vai trò, nhật ký hoặc cài đặt của nhà cung cấp.
- Truy cập các prompt thô, đầu ra, đối số công cụ, tệp, dấu vết hoặc chỉ siêu dữ liệu.
Sau đó, so sánh phạm vi thực tế với phạm vi cần thiết:
| Nếu khóa chỉ cần... | Thì nó không nên có khả năng... |
|---|---|
| Gọi một route trò chuyện sản xuất | Quản lý khóa, người dùng, route, thanh toán hoặc tài khoản nhà cung cấp |
| Chạy các đánh giá (eval) trên môi trường staging | Gọi các route sản xuất hoặc nguồn dữ liệu khách hàng |
| Tạo hình ảnh trong một công việc hàng loạt (batch job) | Đọc các tệp, prompt hoặc dữ liệu xuất sử dụng không liên quan |
| Xuất dữ liệu sử dụng cho bộ phận tài chính | Thay đổi mô hình, prompt, hạn ngạch hoặc route của cổng |
| Chạy các kiểm thử sơ bộ (smoke test) CI | Sử dụng thông tin xác thực của người dùng có thời hạn dài |
| Hỗ trợ tích hợp với nhà cung cấp | Truy cập các route nội bộ hoặc môi trường của khách hàng khác |
Nếu một nhà cung cấp hoặc cổng không cung cấp các phạm vi chi tiết, hãy bù đắp bằng cách tách biệt dự án, tách biệt route, giới hạn hạn ngạch, hạn chế IP hoặc workload, chu kỳ luân chuyển ngắn hơn và giám sát chặt chẽ hơn.
Luân chuyển khóa với kế hoạch chuyển đổi
Luân chuyển là một nhiệm vụ về độ tin cậy, không chỉ là nhiệm vụ bảo mật. Hướng dẫn cập nhật khóa truy cập của AWS mô tả một mẫu thực tế: tạo khóa thứ hai trong khi khóa đầu tiên vẫn còn hoạt động, cập nhật các ứng dụng để sử dụng khóa mới, kiểm tra việc sử dụng khóa cũ, vô hiệu hóa nó trước khi xóa, đợi đủ lâu để phát hiện các lệnh gọi còn sót lại, và sau đó xóa nó. Trình tự đó hữu ích cho các khóa cổng AI vì việc xóa đột ngột có thể làm hỏng các lệnh gọi mô hình, các công việc chạy nền và các agent tương tác với khách hàng.
Hướng dẫn về khóa tài khoản dịch vụ của Google Cloud cũng coi các khóa tài khoản dịch vụ là thông tin xác thực nhạy cảm và khuyến nghị các phương thức xác thực an toàn hơn nếu có thể. Tài liệu về luân chuyển khóa của họ nhấn mạnh rằng việc luân chuyển cần được lên kế hoạch, chứ không phải là hành động ứng phó sau khi bị lộ.
Sử dụng quy trình luân chuyển sau:
| Bước | Hành động | Bằng chứng |
|---|---|---|
| 1. Chuẩn bị | Xác nhận chủ sở hữu, workload, vị trí khóa, các tuyến, hạn ngạch và đường dẫn khôi phục | Hàng đăng ký và runbook |
| 2. Tạo khóa thay thế | Tạo khóa mới hoặc ánh xạ workload mới mà không xóa khóa cũ | ID khóa mới, thời gian tạo, chủ sở hữu |
| 3. Triển khai | Cập nhật vault, secret CI, secret runtime hoặc tích hợp gateway | Bản ghi triển khai hoặc phiếu thay đổi |
| 4. Kiểm tra nhanh (Smoke test) | Gửi các yêu cầu được kiểm soát qua mọi tuyến đã được phê duyệt | ID yêu cầu, tuyến, mô hình, trạng thái, mẫu chi phí |
| 5. Theo dõi khóa cũ | Kiểm tra dữ liệu sử dụng lần cuối, nhật ký và cảnh báo lỗi đối với lưu lượng truy cập của khóa cũ | Ảnh chụp màn hình lần sử dụng cuối cùng hoặc đọc lại API |
| 6. Vô hiệu hóa | Vô hiệu hóa khóa cũ trước khi xóa nếu nền tảng hỗ trợ trạng thái đó | Dấu thời gian vô hiệu hóa và chủ sở hữu |
| 7. Xóa | Xóa khóa cũ sau khoảng thời gian quan sát | Bằng chứng xóa |
| 8. Đóng | Cập nhật sổ đăng ký và ngày rà soát tiếp theo | Bản ghi rà soát quyền truy cập |
Việc luân chuyển khẩn cấp sẽ bỏ qua khoảng thời gian quan sát dài nhưng không bỏ qua bằng chứng. Nếu một khóa bị rò rỉ, hãy thu hồi nó, luân chuyển các workload phụ thuộc, tìm kiếm mã nguồn và nhật ký để tìm secret bị lộ, và ghi lại những hệ thống nào đã được kiểm tra sau đó. Bảng tra cứu Quản lý Secret của OWASP rất hữu ích ở đây vì nó coi việc kiểm toán, luân chuyển, thu hồi, xóa và phát hiện vòng đời là một phần của quản lý secret.
Hủy quyền khi nghỉ việc phải thu hồi nhiều hơn là chỉ thông tin đăng nhập của người dùng
Hủy quyền khi nghỉ việc (Offboarding) là nơi nhiều chương trình rà soát quyền truy cập AI API thất bại. Việc xóa một người khỏi SSO không phải lúc nào cũng xóa các khóa dịch vụ, secret CI, thông tin đăng nhập của nhà cung cấp được chia sẻ, các tệp .env cục bộ, khóa bảng điều khiển của nhà cung cấp mô hình hoặc khóa gateway được tạo dưới tài khoản của người đó.
Tạo các trình kích hoạt hủy quyền cho:
- Nhân viên nghỉ việc.
- Nhà thầu hoặc nhà cung cấp nghỉ việc.
- Chuyển nhóm.
- Dự án ngừng hoạt động.
- Lưu trữ kho mã nguồn.
- Di chuyển môi trường khách hàng.
- Thay thế tài khoản nhà cung cấp.
- Ngừng hoạt động tuyến gateway.
- Sự cố bảo mật hoặc nghi ngờ lộ khóa.
Đối với mỗi trình kích hoạt, hãy quyết định điều gì phải xảy ra:
| Trình kích hoạt hủy quyền | Hành động bắt buộc | Bằng chứng cần lưu giữ |
|---|---|---|
| Chủ sở hữu là người nghỉ việc | Phân công lại chủ sở hữu kinh doanh và kỹ thuật; luân chuyển các khóa do người dùng tạo | Xóa khỏi HR/IdP, cập nhật chủ sở hữu, nhật ký luân chuyển |
| Nhà thầu nghỉ việc | Xóa vai trò dự án, thu hồi khóa nhà cung cấp, luân chuyển các khóa tích hợp được chia sẻ | Phiếu hủy quyền nhà cung cấp |
| Tài khoản dịch vụ ngừng hoạt động | Vô hiệu hóa tuyến, thu hồi khóa, xóa secret CI, xóa mục vault không sử dụng | Đọc lại tuyến và bằng chứng xóa secret |
| Dự án ngừng hoạt động | Vô hiệu hóa tất cả các khóa của dự án và lưu trữ bằng chứng sử dụng/thanh toán | Danh sách kiểm tra kết thúc dự án |
| Thay đổi nhà cung cấp | Luân chuyển khóa phía nhà cung cấp và secret phía gateway | Bằng chứng từ bảng điều khiển của nhà cung cấp và kiểm tra gateway |
| Tuyến ngừng hoạt động | Xóa tuyến mô hình, phương án dự phòng, hạn ngạch, cảnh báo và khóa bị lộ | Bằng chứng xóa tuyến |
| Nghi ngờ rò rỉ khóa | Thu hồi ngay lập tức, luân chuyển, tìm kiếm, rà soát sự cố | Mốc thời gian sự cố và kiểm tra sau luân chuyển |
Đừng đợi đến kỳ rà soát hàng quý mới xử lý việc hủy quyền. Việc rà soát quyền truy cập AI API hàng quý nên xác minh rằng các trình kích hoạt hủy quyền đã hoạt động.
Sử dụng tệp bằng chứng dành riêng cho gateway
Đối với các AI gateway, một cuộc rà soát IAM thông thường là không đủ. Tệp bằng chứng phải kết nối quyền truy cập khóa với hành vi của tuyến AI, chi tiêu cho mô hình và các ranh giới của nhà cung cấp.
| Mục bằng chứng | Những gì người rà soát cần xem |
|---|---|
| ID hoặc bí danh của khóa | Định danh ổn định, không phải là secret |
| Ánh xạ chủ sở hữu | Chủ sở hữu kinh doanh, chủ sở hữu kỹ thuật, người rà soát bảo mật, người rà soát tài chính |
| Danh sách tuyến | Các tuyến gateway, mô hình, nhà cung cấp, họ điểm cuối và phương án dự phòng đã được phê duyệt |
| Danh sách phạm vi | Các hành động mà khóa có thể thực hiện và các hành động bị từ chối rõ ràng |
| Ranh giới môi trường | Môi trường dev, staging, production, CI, nhà cung cấp hoặc khách hàng |
| Vị trí secret | Vault, kho secret CI, trình quản lý secret trên đám mây hoặc vị trí được phê duyệt khác |
| Lần sử dụng cuối | Lần sử dụng gần đây theo tuyến, mô hình và workload |
| Sự kiện thay đổi | Ai đã tạo, luân chuyển, vô hiệu hóa, xóa hoặc thay đổi khóa |
| Bằng chứng chi phí | Các hàng sử dụng, hạn ngạch, số dư, chủ sở hữu hóa đơn, ngưỡng cảnh báo |
| Bằng chứng dữ liệu | Liệu các prompt, kết quả đầu ra, tệp, dấu vết và siêu dữ liệu có được lưu trữ hoặc xuất ra ngoài không |
| Bản ghi luân chuyển | Tạo khóa mới, vô hiệu hóa khóa cũ, xóa khóa cũ, kiểm tra nhanh (smoke test) |
| Trình kích hoạt hủy quyền | Điều kiện người dùng, nhóm, nhà cung cấp, workload hoặc dự án thu hồi quyền truy cập |
| Ngoại lệ | Quyền truy cập rộng tạm thời, ngày hết hạn, người phê duyệt và các biện pháp kiểm soát bù trừ |
Kết nối tệp này với danh sách kiểm tra AI API gateway cho doanh nghiệp, nhật ký kiểm toán cho việc sử dụng AI API, và đánh giá rủi ro nhà cung cấp AI API. Việc rà soát quyền truy cập quyết định ai có thể gọi gateway. Nhật ký kiểm toán chứng minh những gì đã thay đổi. Việc rà soát rủi ro nhà cung cấp chứng minh những ranh giới nào của nhà cung cấp ngược dòng vẫn được áp dụng.
Danh sách kiểm tra rà soát quyền truy cập khóa API
Chạy danh sách kiểm tra này cho mọi dự án cổng sản xuất, dự án staging có rủi ro cao, tích hợp nhà cung cấp và tự động hóa CI có thể gọi các mô hình AI.
- Xuất kho khóa.
Lấy mọi khóa cổng, khóa nhà cung cấp, tài khoản dịch vụ, ánh xạ định danh khối lượng công việc, bí mật CI và thông tin xác thực của nhà cung cấp có thể khởi tạo các yêu cầu AI.
- Xác nhận chủ sở hữu đang hoạt động.
Đối chiếu mỗi khóa với một chủ sở hữu kinh doanh, chủ sở hữu kỹ thuật, người đánh giá bảo mật và chủ sở hữu chi phí. Gán lại hoặc vô hiệu hóa các khóa mồ côi.
- Xác nhận mục đích của khối lượng công việc.
Gắn khóa với một tính năng sản phẩm, tự động hóa, kho lưu trữ, nhà cung cấp, môi trường khách hàng hoặc quy trình vận hành.
- Xác minh việc tách biệt môi trường.
Xác nhận rằng quyền truy cập phát triển, staging, sản xuất, CI, nhà cung cấp và quyền truy cập khẩn cấp (break-glass) không chia sẻ cùng một khóa.
- Rà soát phạm vi và các tuyến đường.
So sánh các phạm vi được phép, mô hình, họ điểm cuối, tuyến đường dự phòng, tài khoản nhà cung cấp, quyền công cụ, tệp, câu lệnh và khả năng quản trị với nhu cầu thực tế của khối lượng công việc.
- Rà soát việc sử dụng và bằng chứng sử dụng lần cuối.
Tìm kiếm các khóa không sử dụng, lưu lượng truy cập bất thường, các mô hình không mong muốn, các đợt tăng đột biến ngoài giờ, các khu vực địa lý mới hoặc các mẫu chi tiêu không khớp với chủ sở hữu.
- Rà soát việc ghi nhật ký và xử lý dữ liệu.
Xác nhận siêu dữ liệu, câu lệnh, đầu ra, tệp, dấu vết và các hàng thanh toán nào được lưu trữ. Sử dụng danh sách kiểm tra lưu giữ dữ liệu AI API nếu việc lưu giữ payload và siêu dữ liệu không rõ ràng.
- Luân chuyển hoặc thu hẹp quyền truy cập.
Đối với mỗi khóa, hãy chọn giữ lại, thu hẹp, luân chuyển, gán lại, vô hiệu hóa, xóa hoặc leo thang. Theo dõi hành động cho đến khi hoàn tất.
- Kiểm tra quy trình hủy quyền khi nghỉ việc.
Chọn các trường hợp nhân viên, nhà cung cấp, dự án và tuyến đường vừa kết thúc gần đây. Xác minh rằng quyền truy cập đã được gỡ bỏ và các khóa cũ không còn tồn tại sau khi kết thúc.
- Thiết lập trình kích hoạt tiếp theo.
Xác định tần suất rà soát và các trình kích hoạt dựa trên sự kiện: thay đổi chủ sở hữu, thay đổi tuyến đường, thay đổi mô hình, thay đổi phạm vi, thay đổi nhà cung cấp, rò rỉ khóa, sự cố, kết thúc hợp đồng với nhà cung cấp hoặc bất thường về chi phí.
Ví dụ về chính sách tuyến đường
Việc rà soát quyền truy cập AI API nên tạo ra một chính sách mà các kỹ sư có thể triển khai. Lược đồ chính xác phụ thuộc vào cổng của bạn, nhưng hình dạng của cơ chế kiểm soát phải rõ ràng.
key_id: support-agent-prod-gateway
owners:
business: support_ops
technical: ai_platform
security: appsec
finance: finops
environment: production
workload:
service: support-agent-api
repository: support-platform
deployment: production
routes:
allowed:
- support-summary-prod
- support-classification-prod
denied:
- experimental-tools
- unrestricted-admin
models:
allowed_groups:
- approved-support-models
fallback_requires_same_data_policy: true
scopes:
allow:
- model_request
- usage_metadata_read
deny:
- key_management
- route_management
- raw_payload_export
- admin_api
quotas:
monthly_budget_usd: 500
alert_owner: finops
burst_limit: controlled
logging:
request_metadata: enabled
raw_payload_storage: verify_in_account
audit_events_required:
- key_created
- key_rotated
- key_disabled
- route_changed
rotation:
cadence: 90d_or_owner_change
method: create_second_key_cutover_deactivate_delete
last_completed: 2026-07-04
offboarding:
triggers:
- owner_departure
- vendor_exit
- service_retirement
- route_decommission
- suspected_exposure
exceptions:
allowed: false
Chính sách này buộc việc rà soát quyền truy cập phải đi vào hoạt động. Nếu cổng không thể thể hiện quyết định một cách trực tiếp, hãy giữ quyết định đó trong tệp bằng chứng và thêm các biện pháp kiểm soát bù trừ như các dự án riêng biệt, cấu hình tuyến đường hẹp, hạn ngạch thấp hơn, luân chuyển ngắn hơn và cảnh báo mạnh mẽ hơn.
Điều này phù hợp với Flatkey như thế nào
Flatkey có thể là bề mặt hoạt động cho việc rà soát quyền truy cập AI API vì bề mặt sản phẩm công khai tập trung vào quyền truy cập mô hình thống nhất, một khóa, một URL cơ sở tương thích với OpenAI, định tuyến, thanh toán, phân tích sử dụng, giới hạn hạn ngạch và một bảng điều khiển cho các khóa và định tuyến. Trang chủ hiện tại hiển thị mẫu bộ định tuyến sử dụng https://router.flatkey.ai/v1/chat/completions, trong khi các trang giá cả và mô hình mô tả quyền truy cập mô hình, phạm vi phủ sóng của nhà cung cấp, số dư trả trước, phân tích sử dụng và thanh toán API sản xuất.
Sử dụng Flatkey để tập trung hóa việc rà soát, sau đó xác minh các chi tiết cụ thể của tài khoản này trước khi dựa vào cơ chế kiểm soát:
- Vai trò nào có thể tạo, xem, luân chuyển, vô hiệu hóa hoặc xóa các khóa cổng.
- Liệu các khóa có thể được tách biệt theo dự án, môi trường, khối lượng công việc, nhà cung cấp và khách hàng hay không.
- Mỗi khóa có thể gọi những mô hình, nhà cung cấp, họ điểm cuối và tuyến đường dự phòng nào.
- Những hạn ngạch, số dư và cảnh báo sử dụng nào được áp dụng cho mỗi khóa hoặc tuyến đường.
- Những sự kiện kiểm toán nào tồn tại cho các thay đổi về khóa, thay đổi tuyến đường, thay đổi hạn ngạch, thay đổi ghi nhật ký và thay đổi nhà cung cấp.
- Liệu các câu lệnh thô, đầu ra, tệp, đối số công cụ, dấu vết hay chỉ siêu dữ liệu được lưu giữ.
- Liệu việc hủy quyền khi nghỉ việc có thể được gắn với người dùng, nhóm, nhà cung cấp, dự án và tài khoản dịch vụ hay không.
Ưu điểm của cổng là tập trung hóa bằng chứng. Người mua vẫn là người sở hữu việc rà soát quyền truy cập AI API.
Tần suất rà soát quyền truy cập
Thiết lập cả việc rà soát theo lịch trình và dựa trên sự kiện.
| Loại rà soát | Tác nhân kích hoạt | Hành động tối thiểu |
|---|---|---|
| Rà soát hoạt động hàng tháng | Khóa cổng sản xuất | Rà soát chủ sở hữu, lần sử dụng cuối, chi tiêu, cuộc gọi thất bại, các tuyến mới |
| Rà soát bảo mật hàng quý | Tất cả các khóa sản xuất và nhà cung cấp | Xác nhận lại chủ sở hữu, phạm vi, luân chuyển, hủy quyền, các trường hợp ngoại lệ |
| Rà soát phát hành | Tuyến, mô hình, điểm cuối, nhà cung cấp mới hoặc dự phòng | Phê duyệt phạm vi khóa trước khi ra mắt |
| Rà soát hủy quyền khi nghỉ việc | Nhân viên, nhà cung cấp, dự án hoặc dịch vụ kết thúc | Gán lại, luân chuyển, vô hiệu hóa hoặc xóa các khóa bị ảnh hưởng |
| Rà soát sự cố | Rò rỉ, bất thường, chi tiêu không mong muốn, lạm dụng, bỏ qua chính sách | Thu hồi, luân chuyển, điều tra và cập nhật các biện pháp kiểm soát |
| Rà soát gia hạn | Hợp đồng, DPA, điều khoản nhà cung cấp, tính sẵn có của mô hình, thay đổi giá cả | Xác thực lại bằng chứng của nhà cung cấp và cổng |
Quy tắc quan trọng nhất: mọi trường hợp ngoại lệ đều phải có thời hạn. Các khóa có phạm vi rộng, khóa dùng chung, khóa khẩn cấp và khóa của nhà cung cấp cần có chủ sở hữu rõ ràng, ngày hết hạn và các tác nhân kích hoạt rà soát.
Câu hỏi thường gặp
Rà soát quyền truy cập AI API là gì?
Rà soát quyền truy cập AI API là một quy trình kiểm tra quản trị định kỳ nhằm xác nhận mọi khóa cổng AI hoặc khóa nhà cung cấp vẫn có chủ sở hữu, mục đích, phạm vi, giới hạn tuyến, mô hình sử dụng, kế hoạch luân chuyển, dấu vết kiểm toán và tác nhân kích hoạt hủy quyền hợp lệ.
Rà soát quyền truy cập AI API khác với luân chuyển khóa API như thế nào?
Luân chuyển là thay thế một thông tin xác thực. Rà soát quyền truy cập AI API quyết định liệu thông tin xác thực đó có nên tồn tại hay không, ai sở hữu nó, nó có thể truy cập những gì, nó chi tiêu tiền như thế nào, nhật ký nào chứng minh việc sử dụng và sự kiện nào sẽ thu hồi nó.
Ai nên sở hữu khóa cổng AI?
Mọi khóa sản xuất nên có một chủ sở hữu kinh doanh, chủ sở hữu kỹ thuật, người rà soát bảo mật và chủ sở hữu tài chính hoặc vận hành. Các khóa do con người sở hữu không nên là thông tin xác thực dài hạn cho các dịch vụ sản xuất; các khóa do dịch vụ sở hữu cần có bằng chứng về danh tính khối lượng công việc, kho lưu trữ, triển khai và nhóm chủ sở hữu.
Nên luân chuyển khóa AI API bao lâu một lần?
Tần suất luân chuyển phụ thuộc vào rủi ro, khả năng của nền tảng và các yêu cầu tuân thủ, nhưng các khóa sản xuất nên có một tần suất được lên kế hoạch cộng với các tác nhân kích hoạt dựa trên sự kiện. Luân chuyển ngay lập tức sau khi nghi ngờ bị lộ, chủ sở hữu rời đi, nhà cung cấp kết thúc hợp đồng, thay đổi phạm vi, thay đổi tài khoản nhà cung cấp hoặc dự án ngừng hoạt động.
Quy trình hủy quyền khi nghỉ việc đối với khóa AI API nên bao gồm những gì?
Quy trình hủy quyền khi nghỉ việc nên bao gồm việc xóa vai trò người dùng, gán lại hoặc luân chuyển các khóa do người dùng tạo, thu hồi thông tin xác thực của nhà cung cấp, xóa các bí mật CI, vô hiệu hóa các tài khoản dịch vụ đã ngừng hoạt động và xác minh nhật ký của cổng/nhà cung cấp để tìm kiếm việc sử dụng cũ sau khi xóa.
Cổng AI giúp ích cho việc rà soát quyền truy cập như thế nào?
Một cổng AI có thể tập trung hóa các khóa, chính sách tuyến, việc sử dụng, hạn ngạch, thanh toán và bằng chứng thay đổi trên các nhà cung cấp. Nó không thay thế việc rà soát theo nguyên tắc đặc quyền tối thiểu hoặc xác minh cụ thể theo tài khoản. Sử dụng cổng làm bề mặt bằng chứng, sau đó xác minh hành vi của nhà cung cấp và tài khoản người mua.
Kết luận
Một cuộc rà soát quyền truy cập AI API sẽ giúp mọi thông tin xác thực của cổng đều có thể giải thích được. Hãy duy trì một sổ đăng ký, gán chủ sở hữu thực sự, thu hẹp phạm vi, luân chuyển với kế hoạch chuyển đổi, kiểm tra quy trình hủy quyền và đóng mọi trường hợp ngoại lệ bằng bằng chứng. Khi bạn sẵn sàng tập trung hóa quyền truy cập mô hình AI, định tuyến, sử dụng và thanh toán đằng sau một cổng duy nhất, hãy xem lại bảng giá và danh mục mô hình hiện tại của Flatkey, sau đó nhận một khóa.
