Quản lý khóa API an toàn cho sản phẩm AI không chỉ đơn thuần là đặt một thông tin xác thực của nhà cung cấp vào kho bí mật. Các ứng dụng AI gửi prompt, tệp, ngữ cảnh truy xuất, đối số công cụ và đầu ra mô hình đi qua các hệ thống thường trải rộng trên nhiều nhà cung cấp và môi trường. Một khóa có thể được mã hóa hoàn hảo khi lưu trữ, trong khi đường dẫn yêu cầu xung quanh vẫn làm lộ dữ liệu nhạy cảm qua bundle trình duyệt, nhật ký debug, đầu ra CI, bản xuất hỗ trợ hoặc một dịch vụ định tuyến được cấp quá nhiều quyền.
Vì vậy, mục tiêu thực tế phải rộng hơn: giữ các khóa nhà cung cấp dài hạn tránh xa các client không đáng tin cậy, cấp cho mỗi workload danh tính nhỏ nhất cần thiết, kiểm soát dữ liệu nào có thể đi qua mỗi ranh giới mô hình, và biến việc xoay vòng cùng thu hồi khóa thành thao tác thường quy thay vì gây gián đoạn.
Hướng dẫn này cung cấp cho các nhóm nền tảng, bảo mật và sản phẩm AI một mô hình vận hành có thể triển khai. Nó bao gồm mô hình đe dọa, mẫu kiểm kê khóa, kiến trúc control plane, quy trình xoay vòng không gián đoạn, quy tắc ghi log, biện pháp bảo vệ CI/CD, quy trình ứng phó sự cố và danh sách kiểm tra cho môi trường production.
Năm ranh giới mà một khóa AI có thể đi qua
Bắt đầu bằng cách lập bản đồ những nơi một bí mật hoặc dữ liệu mà nó cho phép có thể di chuyển. Hầu hết các lỗi xảy ra vì các nhóm bảo vệ khóa nhà cung cấp nhưng bỏ qua một trong những ranh giới liền kề này.
| Ranh giới | Lỗi điển hình | Kiểm soát bắt buộc |
|---|---|---|
| Client đến ứng dụng | Một khóa nhà cung cấp được nhúng trong bundle trình duyệt, binary di động, ứng dụng desktop hoặc tiện ích mở rộng | Giữ khóa nhà cung cấp ở phía server; cấp thông tin xác thực người dùng hoặc phiên làm việc ngắn hạn cho client |
| Ứng dụng đến gateway | Mọi dịch vụ dùng chung một khóa không bị giới hạn | Sử dụng danh tính workload, token gateway có phạm vi, hạn ngạch và chính sách tuyến rõ ràng |
| Gateway đến nhà cung cấp | Một thông tin xác thực có thể truy cập mọi mô hình, dự án hoặc môi trường | Tách khóa theo nhà cung cấp, môi trường, workload và mức rủi ro khi hệ thống hỗ trợ |
| Yêu cầu đến log | Tiêu đề ủy quyền, prompt, tệp hoặc đầu ra xuất hiện trong trace | Chặn các trường bí mật, tối thiểu hóa việc ghi payload, mã hóa định danh, và kiểm thử redaction |
| Vận hành của con người | Khóa bị dán vào ticket, chat, runbook hoặc công cụ hỗ trợ | Sử dụng quy trình truy cập có kiểm soát, truy xuất có kiểm toán, thủ tục break-glass và tự động hết hạn |
Bản đồ ranh giới này thay đổi câu hỏi thiết kế từ “Chúng ta lưu khóa ở đâu?” thành “Danh tính nào có thể thực hiện yêu cầu nào, với dữ liệu nào, qua tuyến nào, và bằng chứng nào còn lại sau đó?”
Sử dụng mô hình lưu giữ khóa ở phía server
Các thông tin xác thực nhà cung cấp dài hạn không nên được gửi đến client trình duyệt, di động, desktop hoặc tiện ích mở rộng. Bất cứ thứ gì được đưa đến thiết bị của người dùng cuối đều nên được xem là có thể bị chính người dùng đó hoặc mã độc chạy với cùng đặc quyền trích xuất lại.
Một mô hình an toàn hơn là:
- Máy khách xác thực với backend của bạn bằng phiên người dùng, thông tin xác thực thiết bị hoặc mã ứng dụng ngắn hạn.
- Backend của bạn cấp quyền cho tính năng được yêu cầu và áp dụng các giới hạn theo từng người dùng hoặc từng tenant.
- Một gateway hoặc tích hợp phía máy chủ chọn nhà cung cấp và mô hình đã được phê duyệt.
- Khóa của nhà cung cấp được truy xuất tại thời điểm chạy hoặc được cung cấp cho workload đáng tin cậy thông qua nền tảng triển khai.
- Phản hồi từ nhà cung cấp đi ngược trở lại qua cùng ranh giới chính sách.
Máy khách không bao giờ cần bí mật của nhà cung cấp. Nó chỉ nhận được quyền gọi sản phẩm của bạn trong phạm vi các giới hạn bạn xác định.
Đối với các tác nhân lập trình và công cụ phát triển cục bộ, hãy dùng cùng nguyên tắc này với một mô hình ngoại lệ có chủ đích. Một nhà phát triển có thể cần một thông tin xác thực cục bộ, nhưng đó nên là thông tin xác thực của sản phẩm hoặc gateway có khả năng thu hồi, gắn với sử dụng, và phạm vi giới hạn — không phải một khóa nhà cung cấp dùng chung toàn tổ chức được sao chép vào dotfiles khắp công ty.
Xây dựng kiểm kê khóa trước khi bạn xoay vòng bất cứ thứ gì
Các dự án xoay vòng thất bại khi các nhóm không biết workload nào đang dùng một khóa. Hãy tạo một kiểm kê có thể đọc bằng máy và chỉ định một chủ sở hữu trước khi thay đổi thông tin xác thực.
Ít nhất, hãy ghi lại:
| Trường | Ví dụ | Vì sao quan trọng |
|---|---|---|
| Secret ID | prod-support-chat-anthropic-01 |
Một tham chiếu nội bộ ổn định, không phải giá trị bí mật |
| Nhà cung cấp và dự án | Tài khoản nhà cung cấp + mã định danh dự án | Xác định phạm vi tác động bên ngoài |
| Môi trường | Phát triển, staging, production | Ngăn hệ thống kiểm thử kế thừa quyền của production |
| Workload | support-chat-api |
Cho phép truy vết và thu hồi có mục tiêu |
| Chủ sở hữu | Nhóm và vòng quay trực ca | Tạo trách nhiệm giải trình trong sự cố |
| Vị trí lưu trữ | Đường dẫn trong secret manager hoặc ràng buộc triển khai | Cho biết nguồn sự thật nằm ở đâu |
| Model/đường dẫn được phép | Họ model đã được phê duyệt hoặc chính sách gateway | Hạn chế việc sử dụng ngoài ý muốn |
| Giới hạn chi tiêu và yêu cầu | Ngân sách workload, RPM, TPM, hoặc kiểm soát đồng thời | Hạn chế lạm dụng và tự động hóa mất kiểm soát |
| Ngày tạo và lần xoay vòng gần nhất | Dấu thời gian | Làm lộ rõ các thông tin xác thực lỗi thời |
| Phương pháp xoay vòng | Dual-key, bí danh phiên bản, hoặc cửa sổ bảo trì | Ngăn các thay đổi ứng biến |
| Phụ thuộc thu hồi | Các dịch vụ phải được cập nhật trước | Bảo vệ tính sẵn sàng |
| Phân loại dữ liệu | Công khai, nội bộ, mật, được quản lý | Kết nối chính sách khóa với quản trị prompt |
Không đưa giá trị của khóa vào kiểm kê. Chỉ lưu siêu dữ liệu và tham chiếu đến secret được quản lý.
Tách biệt danh tính theo môi trường, workload và rủi ro
Mẫu phản-pattern phổ biến nhất là một khóa production duy nhất được chia sẻ bởi mọi dịch vụ. Nó rất tiện cho đến khi một repository, trình chạy kiểm thử, laptop của nhà thầu, hoặc bản ghi hỗ trợ làm lộ nó. Khi đó, nhóm không thể thu hồi khóa mà không làm gián đoạn các sản phẩm không liên quan.
Hãy ưu tiên các danh tính riêng biệt cho:
- Môi trường production, staging, development và kiểm thử cục bộ.
- Lưu lượng hướng tới khách hàng, công cụ nội bộ, job hàng loạt và các pipeline đánh giá.
- Các quy trình làm việc có rủi ro cao có thể gọi công cụ hoặc xử lý dữ liệu mật.
- Các đơn vị kinh doanh hoặc tenant khác nhau khi ranh giới theo hợp đồng yêu cầu phải tách biệt.
- Quyền truy cập khẩn cấp hoặc break-glass, vốn nên vẫn bị vô hiệu hóa hoặc được kiểm soát chặt chẽ trong quá trình vận hành bình thường.
Khi nhà cung cấp có hỗ trợ các hạn chế, hãy áp dụng chúng. Các hạn chế có thể bao gồm API được phép, mô hình, mạng nguồn, dự án, referrer, ứng dụng hoặc hạn ngạch. Ví dụ, hướng dẫn về API key của Google Cloud khuyến nghị hạn chế key, cô lập chúng, xóa các key không cần thiết, tránh commit vào repository và giám sát việc sử dụng.
Nếu nhà cung cấp không cung cấp các kiểm soát đủ chi tiết, hãy thực thi chúng tại gateway của riêng bạn. Một gateway trung tâm có thể xác thực workload đang gọi, ánh xạ nó tới một tuyến đã được phê duyệt, áp dụng ngân sách và giới hạn tốc độ, đồng thời giữ thông tin xác thực của nhà cung cấp phía sau một ranh giới server-side duy nhất đã được rà soát. Xem thêm hướng dẫn kiến trúc AI API gateway để biết thiết kế định tuyến và chuyển đổi dự phòng.
Xem quản trị prompt và log như một phần của quản lý khóa
Một API key cấp quyền cho một đường dẫn dữ liệu. Bảo vệ key mà không kiểm soát đường dẫn đó sẽ khiến rủi ro chính đặc thù của AI vẫn chưa được giải quyết.
Trước khi định tuyến một request, hãy phân loại payload và áp dụng nguyên tắc tối thiểu cần thiết:
- Xóa thông tin xác thực, token, cookie, private key và chuỗi kết nối.
- Loại trừ các trường mà mô hình không cần.
- Token hóa hoặc giả danh hóa các định danh trực tiếp khi tác vụ có thể hoạt động mà không cần chúng.
- Từ chối dữ liệu được quản lý hoặc bị hạn chế theo hợp đồng mà không được hỗ trợ.
- Tách hướng dẫn hệ thống khỏi nội dung người dùng không đáng tin cậy hoặc nội dung truy xuất được.
- Xác thực đối số của công cụ trước khi một agent có thể gọi các hệ thống bên ngoài.
Log cần một schema rõ ràng. Đừng dựa vào việc nhà phát triển sẽ nhớ không ghi lại một đối tượng request. Hãy định nghĩa những trường nào được phép, rồi loại bỏ hoặc chuyển đổi mọi thứ khác.
Một sự kiện sản xuất hữu ích có thể chứa:
{
"request_id": "req_01J...",
"tenant_id_hash": "tnt_7f2...",
"workload": "support-chat-api",
"route_policy": "support-low-risk-v3",
"provider": "selected-provider",
"model": "selected-model",
"input_tokens": 842,
"output_tokens": 211,
"latency_ms": 1370,
"status": 200,
"key_version": "v12",
"redaction_policy": "customer-support-v4"
}
Theo mặc định, nó không nên chứa authorization header, raw provider key, prompt đầy đủ, tài liệu đã tải lên, đối số công cụ chưa được che giấu, hoặc toàn bộ đầu ra của mô hình. Nếu cần ghi lại payload cho một đánh giá hoặc sự cố được kiểm soát chặt chẽ, hãy giới hạn theo thời gian, kiểm soát truy cập và tách biệt rõ ràng khỏi telemetry thường lệ.
OWASP Logging Cheat Sheet cung cấp một cơ sở hữu ích để loại trừ access token, mật khẩu, khóa mã hóa và các dữ liệu nhạy cảm khác khỏi nhật ký ứng dụng.
Thiết kế xoay vòng API key không gây gián đoạn
Xoay vòng chỉ là một biện pháp kiểm soát nếu có thể thực hiện an toàn. Một runbook gây gián đoạn dịch vụ sẽ bị trì hoãn cho đến khi xảy ra tình huống khẩn cấp.
Hãy sử dụng trình tự hai khóa hoặc bí mật theo phiên bản khi nhà cung cấp hỗ trợ thông tin xác thực chồng lấp:
- Tạo một khóa nhà cung cấp mới. Áp dụng các hạn chế giống hệt hoặc chặt hơn so với khóa cũ.
- Lưu nó như một phiên bản bí mật mới. Không ghi đè giá trị cũ tại chỗ nếu nền tảng của bạn hỗ trợ phiên bản hoặc bí danh.
- Triển khai các thành phần đọc chấp nhận phiên bản mới. Cập nhật cổng hoặc các workload để phân giải bí danh hoặc phiên bản hiện tại.
- Chuyển lưu lượng và theo dõi. Xác nhận các yêu cầu thành công, mô hình dự kiến, chi phí, giới hạn tốc độ và tỷ lệ lỗi bằng phiên bản khóa mới.
- Loại bỏ các bên tiêu thụ cũ. Kiểm tra danh mục triển khai, tác vụ, worker và các môi trường khôi phục thảm họa.
- Thu hồi khóa cũ. Không chỉ ngừng sử dụng nó; hãy vô hiệu hóa nó tại nhà cung cấp.
- Xác minh việc bị từ chối. Một kiểm thử có kiểm soát nên xác nhận rằng thông tin xác thực cũ không còn hoạt động.
- Ghi lại bằng chứng. Lưu thời điểm, chủ sở hữu, các workload bị ảnh hưởng, kết quả xác thực và ngày xem xét tiếp theo.
Đối với một hệ thống hỗ trợ chọn phiên bản khóa, ứng dụng nên tham chiếu một bí danh ổn định thay vì mã cứng một phiên bản bí mật:
type ProviderCredential = {
value: string;
version: string;
};
async function loadProviderCredential(): Promise<ProviderCredential> {
const activeVersion = await secretStore.resolveAlias("ai/provider/active");
const value = await secretStore.readVersion("ai/provider", activeVersion);
return { value, version: activeVersion };
}
Không in ra value, không tuần tự hóa đối tượng được trả về, và không đính kèm nó vào lỗi. Chỉ ghi log mã định danh phiên bản không phải bí mật.
OWASP Secrets Management Cheat Sheet khuyến nghị lập kế hoạch cho toàn bộ vòng đời của bí mật, bao gồm tạo, xoay vòng, thu hồi, hết hạn, kiểm toán, sao lưu và quyền truy cập khẩn cấp. Tài liệu này cũng nhấn mạnh việc tự động hóa xoay vòng khi khả thi.
Ngăn bí mật lọt vào kho mã và nhật ký CI
Các trình quản lý bí mật không giúp ích gì sau khi một thông tin xác thực đã bị sao chép vào mã nguồn, một fixture, một artifact build hoặc một bản ghi CI.
Hãy áp dụng các kiểm soát ở ba giai đoạn:
Trước khi commit
- Cung cấp các tệp
.env.examplevới chỗ giữ chỗ, không bao giờ là thông tin xác thực hoạt động. - Giữ các tệp bí mật cục bộ ngoài hệ thống kiểm soát phiên bản.
- Chạy trình quét bí mật nhanh trong pre-commit hooks cho các mẫu nhà cung cấp phổ biến và các giá trị có entropy cao.
- Giúp nhà phát triển hiểu rằng việc xóa một bí mật trong commit sau đó không loại bỏ nó khỏi lịch sử.
Khi push và pull request
- Bật quét bí mật trong kho mã và bảo vệ khi push nếu có.
- Thêm các mẫu tùy chỉnh cho các token cổng nội bộ mà trình quét công khai sẽ không nhận ra.
- Yêu cầu nêu rõ lý do bỏ qua bằng văn bản và chuyển các trường hợp bỏ qua sang bộ phận an ninh xem xét.
- Quét cả các tệp được tạo sinh, notebook, ảnh chụp test, và kế hoạch hạ tầng — không chỉ mã nguồn ứng dụng.
GitHub mô tả push protection như một cách quét trong quá trình push và chặn các bí mật được phát hiện trước khi chúng vào kho lưu trữ. Việc phát hiện không phải là lý do để giữ lại khóa: hãy coi mọi thông tin xác thực đã được cam kết và xác nhận là bị lộ và hãy xoay vòng nó.
Trong CI/CD
- Ưu tiên workload identity hoặc federation ngắn hạn thay vì lưu trữ thông tin xác thực đám mây.
- Chỉ hiển thị bí mật cho job và step cần đến nó.
- Che các giá trị bí mật đã biết, nhưng đừng phụ thuộc vào việc che giấu như là biện pháp kiểm soát chính.
- Tắt shell tracing xung quanh việc truy xuất bí mật.
- Ngăn code từ fork không đáng tin cậy truy cập vào bí mật triển khai.
- Rà soát artifacts, caches, crash dumps và test reports để phát hiện việc vô tình ghi nhận.
Giám sát việc sử dụng mà không ghi log bí mật
Giám sát tốt trả lời câu hỏi “ai đã dùng quyền nào?” mà không ghi lại chính quyền đó.
Theo dõi:
- Workload, môi trường, tenant hoặc project, và phiên bản khóa.
- Nhà cung cấp, model, chính sách route và đường dự phòng.
- Số lượng request, lượng token, chi phí, độ trễ và loại lỗi.
- Mạng nguồn hoặc danh tính triển khai khi hữu ích.
- Truy cập vào secret manager, bao gồm cả các lần đọc bị từ chối.
- Tạo khóa, thay đổi giới hạn, xoay vòng, thu hồi và xóa.
- Sử dụng đột ngột từ một môi trường, địa lý, model hoặc khung thời gian không mong đợi.
Thiết lập cảnh báo dựa trên hành vi, không chỉ tổng chi phí. Một khóa giá trị thấp bị đánh cắp vẫn có thể làm lộ prompt hoặc dò thám các workflow nội bộ. Ngược lại, một job xử lý hàng loạt hợp lệ có thể tạo ra đột biến chi phí mà không có sự xâm phạm thông tin xác thực. Tương quan việc sử dụng từ nhà cung cấp với application request ID, quyết định chính sách của gateway, sự kiện triển khai và nhật ký kiểm toán của secret manager.
Đối với các kiểm soát lưu lượng bổ trợ cho kiểm soát thông tin xác thực, hãy dùng hướng dẫn giới hạn tốc độ LLM và playbook định tuyến fallback API LLM.
Sử dụng đồng hồ sự cố từ lộ lọt đến thu hồi
Khi một khóa có thể đã bị lộ, mục tiêu đầu tiên là ngăn chặn — không phải chứng minh liệu kẻ tấn công đã dùng nó hay chưa.
Thực hiện chuỗi sau:
- Khai báo thông tin xác thực là đáng ngờ. Ghi lại khi nào và ở đâu thông tin đó có thể đã bị lộ.
- Tạo một bản thay thế theo đúng quy trình kiểm soát thông thường. Không dán một khóa mới vào chat để tăng tốc xử lý sự cố.
- Chuyển các khối lượng công việc hợp lệ sang bản thay thế. Sử dụng quy trình xoay vòng đã được chuẩn bị trước.
- Thu hồi khóa đáng ngờ. Nếu việc thu hồi ngay lập tức gây ra thiệt hại không chấp nhận được, hãy cô lập các tuyến và giảm giới hạn trong khi hoàn tất chuyển đổi.
- Kiểm tra mọi vị trí bản sao. Xem lại lịch sử mã nguồn, nhật ký CI, artifact, các lớp container, hệ thống hỗ trợ, bảng điều khiển, notebook, cấu hình cục bộ và bản sao lưu.
- Rà soát các đường dẫn dữ liệu được cấp phép. Xác định những prompt, đầu ra, tệp, công cụ hoặc mô hình nào mà khóa có thể truy cập—not chỉ phạm vi thanh toán của nó.
- Đối chiếu hoạt động. So sánh mức sử dụng từ nhà cung cấp, nhật ký gateway, các lần triển khai, lượt đọc secret và hoạt động của người dùng.
- Thông báo cho đúng chủ sở hữu. Phối hợp với các nhóm bảo mật, nền tảng, pháp lý, quyền riêng tư và khách hàng theo dữ liệu và các hợp đồng liên quan.
- Loại bỏ nguyên nhân gốc rễ. Thêm trình quét bị thiếu, giới hạn, ranh giới danh tính hoặc bộ lọc nhật ký.
- Đo thời gian. Ghi lại thời gian phát hiện, thay thế, chuyển lưu lượng, thu hồi và xác minh.
Thước đo có tính hành động nhất thường là thời gian từ lộ lọt đến thu hồi: khoảng thời gian một thông tin xác thực bị nghi ngờ vẫn có thể sử dụng sau khi tổ chức đã có bằng chứng đáng tin cậy về việc bị lộ. Giảm khoảng thời gian đó đòi hỏi phân công trách nhiệm, kiểm kê, tự động hóa và quy trình xoay vòng đã được kiểm thử—chứ không phải một tài liệu chính sách dài hơn.
Kiến trúc tham chiếu cho sản phẩm AI đa nhà cung cấp
Một thiết lập đa nhà cung cấp an toàn có thể được tổ chức thành năm lớp:
- Lớp danh tính khách hàng: xác thực người dùng, thiết bị, tác nhân hoặc ứng dụng mà không làm lộ thông tin xác thực của nhà cung cấp.
- Lớp ủy quyền ứng dụng: xác minh quyền lợi sản phẩm, ranh giới tenant, quyền truy cập tính năng và ngân sách.
- Lớp chính sách dữ liệu: phân loại và che giấu prompt, tệp, ngữ cảnh được truy xuất và đối số công cụ.
- Lớp gateway và định tuyến: chọn các mô hình đã được phê duyệt, áp dụng hạn mức, ghi nhận phân bổ không chứa bí mật và xử lý chuyển đổi dự phòng.
- Lớp thông tin xác thực của nhà cung cấp: lưu trữ thông tin xác thực của từng nhà cung cấp một cách cô lập, xoay vòng các phiên bản và chỉ cho phép workload định tuyến đáng tin cậy truy cập.
Thiết kế này hạn chế phạm vi ảnh hưởng. Một token khách hàng bị xâm phạm không tự động tiết lộ khóa của nhà cung cấp. Một định danh workload bị xâm phạm cũng không nên cấp quyền truy cập vào mọi nhà cung cấp. Một thông tin xác thực của nhà cung cấp bị rò rỉ cũng không nên cho phép truy cập mọi môi trường. Một lỗi ghi log không nên làm lộ cả bí mật lẫn toàn bộ tải dữ liệu.
Định vị sản phẩm của Flatkey là một endpoint tương thích OpenAI và quyền truy cập hợp nhất trên nhiều nhà cung cấp mô hình. Điều đó có thể giảm số lượng tích hợp đặc thù theo từng nhà cung cấp mà ứng dụng phải duy trì, nhưng một gateway không xóa bỏ trách nhiệm của bạn trong việc bảo mật xác thực client, phân loại dữ liệu yêu cầu, cấu hình log, gán chủ sở hữu và kiểm thử thu hồi. Hãy đánh giá chính xác các kiểm soát có sẵn cho tài khoản và kiến trúc của bạn trước khi triển khai vào production. Bạn có thể bắt đầu với hướng dẫn tích hợp Flatkey và xem lại quyền truy cập mô hình và giá hiện tại.
Danh sách kiểm tra production
Sử dụng danh sách này trước khi ra mắt và trong các đợt rà soát kiểm soát hàng quý.
Quyền quản lý và danh tính
- Không có khóa nhà cung cấp dài hạn nào được nhúng trong mã trình duyệt, di động, desktop hoặc extension.
- Mọi workload production đều có chủ sở hữu và đường dẫn thông tin xác thực có thể nhận diện được.
- Production, staging, development, evaluation và truy cập local được tách biệt.
- Các khóa dùng chung của con người đã được thay thế bằng danh tính của workload hoặc gateway khi có thể.
- Các hạn chế của nhà cung cấp và gateway được đặt ở phạm vi hẹp nhất có thể trong thực tế.
Lưu trữ và phân phối
- Nguồn chuẩn là một secret store được quản lý hoặc một ràng buộc triển khai được kiểm soát.
- Ứng dụng chỉ truy xuất secret tại thời gian chạy và không in hoặc tuần tự hóa chúng.
- Các job CI chỉ nhận những secret cần thiết cho bước tương ứng.
- Truy cập secret và các thay đổi quản trị được kiểm toán.
- Quyền truy cập khẩn cấp break-glass được ghi tài liệu, giới hạn thời gian và được kiểm thử.
Dữ liệu và khả năng quan sát
- Header xác thực và giá trị khóa được loại trừ khỏi log, trace, lỗi và các file xuất hỗ trợ.
- Việc ghi log prompt, output, file và đối số công cụ tuân theo schema allowlist.
- Việc che giấu dữ liệu diễn ra trước khi định tuyến qua nhiều nhà cung cấp.
- Có thể quy trách nhiệm việc sử dụng theo workload, môi trường, tuyến, nhà cung cấp, mô hình và phiên bản khóa.
- Cảnh báo bao gồm cả các tuyến và danh tính bất thường cũng như chi tiêu.
Xoay vòng và phản ứng
- Có sẵn một runbook xoay vòng khóa kép hoặc secret có phiên bản đã được kiểm thử.
- Các khóa cũ được thu hồi ở phía nhà cung cấp và xác minh là không còn sử dụng được.
- Quét secret và bảo vệ khi push bao phủ các kho mã nguồn và artifact được tạo ra.
- Một nghi ngờ rò rỉ kích hoạt việc ngăn chặn ngay lập tức mà không chờ bằng chứng bị lạm dụng.
- Thời gian từ khi lộ lọt đến khi thu hồi được đo sau các buổi diễn tập và sự cố.
Câu hỏi thường gặp
Quản lý khóa API an toàn cho sản phẩm AI là gì?
Đó là thực hành kiểm soát toàn bộ vòng đời và đường đi của yêu cầu đối với thông tin xác thực dùng để gọi các mô hình AI. Nó bao gồm việc giữ khóa ở phía server, danh tính workload, nguyên tắc đặc quyền tối thiểu, lưu trữ secret, chính sách định tuyến, quản trị prompt và log, xoay vòng, giám sát và phản ứng sự cố.
Khóa API AI có nên được lưu trong biến môi trường không?
Biến môi trường có thể là một cơ chế phân phối, nhưng nó không phải là một hệ thống quản lý hoàn chỉnh. Secret vẫn cần một nguồn chuẩn được kiểm soát, quyền truy cập triển khai bị hạn chế, xoay vòng, kiểm toán và bảo vệ khỏi memory dump của tiến trình, log, điểm cuối debug và các tiến trình con kế thừa. Hãy ưu tiên việc tiêm secret nguyên bản của nền tảng hoặc truy xuất khi chạy nếu điều đó cải thiện các kiểm soát đó.
Nên xoay vòng khóa API AI bao lâu một lần?
Hãy sử dụng các khả năng của nhà cung cấp, mô hình mối đe dọa của bạn, các hợp đồng và chính sách nội bộ để xác định khoảng thời gian. Điều quan trọng hơn việc chọn một con số theo lịch ngẫu nhiên là chứng minh rằng việc xoay vòng được tự động hóa hoặc đã được diễn tập, các khóa cũ được thu hồi, các khóa bị nghi ngờ có thể được thay thế ngay lập tức, và các thông tin xác thực lỗi thời không thể tồn tại mà không bị phát hiện.
Trình duyệt có thể gọi trực tiếp một nhà cung cấp AI bằng khóa bị hạn chế không?
Một số nhà cung cấp hỗ trợ các hạn chế phía client cho các API cụ thể, nhưng một sản phẩm AI chạy production nên giả định rằng thông tin xác thực đã phát hành có thể bị khôi phục. Một backend hoặc gateway thường cung cấp khả năng kiểm soát mạnh hơn đối với ủy quyền người dùng, hạn mức, che giấu prompt, lựa chọn nhà cung cấp, phản ứng với lạm dụng, và thu hồi khóa.
Một khóa gateway có an toàn hơn nhiều khóa nhà cung cấp không?
Nó có thể giảm sự lan tràn thông tin xác thực trong mã ứng dụng, nhưng lại tập trung quyền lực tại gateway. Thông tin xác thực của gateway phải được giới hạn phạm vi, có thể truy vết, giới hạn tốc độ, giám sát, có khả năng xoay vòng, và được bảo vệ khỏi client. Các thông tin xác thực nhà cung cấp phía sau nó vẫn cần được cô lập và quản lý vòng đời.
Chúng ta nên làm gì nếu một khóa API xuất hiện trong lịch sử Git?
Hãy coi nó là đã bị xâm phạm. Thu hồi hoặc xoay vòng nó, thay thế các bên tiêu thụ hợp lệ, xem xét hoạt động của nhà cung cấp và gateway, xóa giá trị đó khỏi các nhánh đang hoạt động và các hiện vật liên quan, và thêm quét phòng ngừa. Việc viết lại lịch sử không làm cho một thông tin xác thực vẫn còn hiệu lực trở nên an toàn.
