Quản lý API key cho LLM: Hạn mức chi tiêu, xoay key và truy cập ứng dụng an toàn hơn
Tác giả: Nicho
API key của LLM là thông tin xác thực có thể cho phép chi tiêu và truy cập. Quản lý tốt key nghĩa là trả lời được bốn câu hỏi: key được lưu ở đâu, key làm được gì, khối lượng công việc của key tiêu tốn bao nhiêu, và bạn có thể thu hồi key nhanh đến mức nào?
Một yêu cầu đầu tiên thành công không trả lời câu nào trong số đó. Trước khi một bản thử nghiệm trở thành ứng dụng dùng chung, hãy thiết lập vòng đời key và ranh giới truy cập mà bạn có thể giải thích mà không cần mở thông tin xác thực thô của bất kỳ ai.
Giữ key của nhà cung cấp phía sau ứng dụng của bạn
Đừng nhúng API key dài hạn của nhà cung cấp vào JavaScript trên trình duyệt, gói ứng dụng di động hay bộ nhớ trình duyệt. Gửi secret đến thiết bị của người dùng cuối khiến secret nằm ngoài tầm kiểm soát của máy chủ bạn. OpenAI khuyến nghị rõ ràng nên định tuyến yêu cầu qua backend thay vì để lộ key trong môi trường phía client. Hướng dẫn an toàn API key của OpenAI
Với một ứng dụng web thông thường, hãy dùng ranh giới này:
Signed-in user → your authenticated backend → LLM provider
Trình duyệt xác thực với ứng dụng của bạn. Backend của bạn chọn mô hình được phép và lấy thông tin xác thực của nhà cung cấp từ kho secret phía máy chủ.
Nhưng chuyển key về backend vẫn chưa đủ. Một proxy không xác thực vẫn có thể để người lạ tiêu số dư của bạn mà không hề thấy secret. Hãy áp dụng xác thực người dùng, giới hạn kích thước yêu cầu, giới hạn thao tác được phép và kiểm soát mức sử dụng theo từng người dùng trước khi chuyển tiếp công việc. Đừng để một URL bất kỳ do client cung cấp quyết định nơi backend gửi header xác thực.
Tách riêng các khối lượng công việc trước khi chia sẻ thông tin xác thực
Tránh dùng một key cho production, staging, laptop của lập trình viên và một tác vụ nhập dữ liệu theo lịch. Tách riêng giúp bạn dễ nhận diện mức sử dụng và thu hồi một khối lượng công việc mà không làm hỏng mọi thứ khác.
Một bản kiểm kê ban đầu hữu ích không chứa secret thô:
| Trường | Ví dụ |
|---|---|
| Khối lượng công việc | Công cụ tóm tắt cho hỗ trợ khách hàng |
| Môi trường | Production |
| Người phụ trách | Nhóm ứng dụng |
| Tham chiếu secret | Tên mục trong secret manager |
| Quyền truy cập dự kiến | Mô hình tóm tắt đã được phê duyệt |
| Điều kiện rà soát | Thay đổi triển khai hoặc người phụ trách rời đi |
| Quy trình thu hồi | Liên kết đến runbook nội bộ |
Hãy dùng ranh giới theo project hoặc service account của nhà cung cấp khi có, thay vì chỉ đổi tên những key vẫn giữ nguyên quyền. Ví dụ, tài liệu về project của OpenAI mô tả service account và tài nguyên theo phạm vi project. Đó là khả năng riêng của từng nhà cung cấp, không phải bảo đảm rằng mọi gateway tương thích đều có cùng mức cách ly. Quản lý project của OpenAI
Lưu secret mà không phân phối tràn lan
Ưu tiên một hệ thống quản lý secret chuyên dụng với quyền truy cập chỉ giới hạn cho những khối lượng công việc và người vận hành cần đến. Ghi lại quyền sở hữu và siêu dữ liệu vòng đời tách biệt với giá trị thông tin xác thực. OWASP khuyến nghị quyền truy cập chi tiết và quản lý secret xuyên suốt quá trình tạo, xoay vòng, thu hồi và hết hạn. Bảng tóm tắt quản lý secret của OWASP
Với một triển khai nhỏ, biến môi trường được bảo vệ trên máy chủ có thể là một cách tích hợp, nhưng không phải là chiến lược bảo mật hoàn chỉnh. Hãy xem lại ai có thể đọc cài đặt triển khai, chạy lệnh gỡ lỗi hoặc xem báo cáo sự cố. Không bao giờ in toàn bộ biến môi trường khi chẩn đoán lỗi kết nối.
Giữ thông tin xác thực ngoài tệp mã nguồn, ảnh container, ảnh chụp màn hình, ticket và tin nhắn chat. Dùng ví dụ cấu hình đã che thông tin trong tài liệu. Một đồng đội đang xử lý lỗi thường chỉ cần endpoint, model, lỗi đã làm sạch và mã định danh yêu cầu, chứ không cần chính key.
Định nghĩa “hạn mức” thực sự nghĩa là gì
Đừng coi mọi hạn mức trên bảng điều khiển là trần chi tiêu cứng áp dụng ngay. Trước khi tin vào một cơ chế kiểm soát, hãy xác định:
- Cơ chế đó gửi cảnh báo hay từ chối các yêu cầu thêm.
- Cơ chế đó áp dụng cho một key, dự án, tài khoản hay người dùng ứng dụng.
- Chu kỳ đặt lại và múi giờ, nếu có.
- Cách xử lý các yêu cầu đồng thời và việc ghi nhận mức sử dụng bị trễ.
- Ai nhận cảnh báo và ai có thể thay đổi cài đặt.
Hãy ghi lại những điểm chưa rõ thay vì mặc định là mọi thứ diễn ra thuận lợi. Vẫn giữ cơ chế kiểm soát đầu vào và giám sát ở phía ứng dụng ngay cả khi nhà cung cấp có tính năng hạn mức.
Ví dụ, một ứng dụng hỗ trợ có thể chỉ cho phép model đã được duyệt, giới hạn kích thước đầu vào, giới hạn đầu ra yêu cầu và giới hạn số thao tác mỗi ngày của từng khách hàng. Những cơ chế này phục vụ các mục đích khác nhau: giới hạn model thu hẹp lựa chọn, giới hạn yêu cầu thu hẹp khối lượng, còn kiểm soát chi tiêu thu hẹp mức rủi ro về tiền. Không cơ chế nào thay thế được các cơ chế còn lại.
Cấu hình các cơ chế kiểm soát key đã công bố của cheapaimodel
Trang bảng giá công khai của cheapaimodel mô tả hạn mức theo từng key, ngày hết hạn, danh sách cho phép model và danh sách cho phép IP. Trang này cũng nêu rằng hạn mức của một key không thể vượt quá số tiền mà số dư tài khoản có thể chi trả, và số dư tài khoản cạn kiệt khiến các yêu cầu qua gateway trả về 403.
Với một tích hợp mới, hãy chọn danh sách cho phép model hẹp và hạn mức phù hợp với khối lượng công việc đó. Đặt ngày hết hạn cho các tích hợp tạm thời. Cân nhắc dùng danh sách cho phép IP khi máy chủ của bạn có địa chỉ ra cố định, đã biết; hãy tính đến hạ tầng dự phòng trước khi bật tính năng này.
Những khuyến nghị này dựa trên mô tả sản phẩm đã công bố, không phải một cuộc kiểm toán độc lập về thời điểm thực thi. Đừng hứa hẹn không chi vượt khi có yêu cầu đồng thời, và đừng nhầm giới hạn IP là thứ thay thế cho việc giữ kín thông tin xác thực. Kiểm tra tài liệu cheapaimodel hiện hành trước khi cấu hình triển khai.
Xoay key có chủ đích; thu hồi khẩn cấp khi bị lộ
Với việc xoay key theo kế hoạch, hãy bàn giao có kiểm soát:
- Xác định mọi triển khai và tác vụ chạy nền đang dùng thông tin xác thực cũ.
- Tạo thông tin xác thực thay thế với các giới hạn mong muốn.
- Cập nhật tham chiếu hoặc giá trị secret qua quy trình triển khai thông thường của bạn.
- Xác nhận các khối lượng công việc bị ảnh hưởng đang dùng thông tin xác thực thay thế.
- Thu hồi thông tin xác thực cũ và ghi lại việc hoàn tất.
Mọi phần trùng lặp nên có chủ đích và ngắn. Đừng để một key cũ còn hoạt động vô thời hạn “để phòng hờ.” Hết hạn cũng cần có người phụ trách: một thông tin xác thực sắp hết hạn mà không có kế hoạch gia hạn có thể thành sự cố ngừng dịch vụ đáng lẽ tránh được.
Một key bị lộ thì khác. Ưu tiên thu hồi và khoanh vùng thay vì giữ một khoảng thời gian chuyển đổi thoải mái. Kiểm tra mức sử dụng, xác định các deployment bị ảnh hưởng, và khôi phục dịch vụ bằng key thay thế được gửi qua kênh secret đã được phê duyệt.
Xóa một key bị rò rỉ khỏi commit Git mới nhất không làm key hết hiệu lực hay xóa các bản sao đang tồn tại. Hướng dẫn của GitHub đặt việc thu hồi hoặc xoay vòng thông tin xác thực trước việc dọn dẹp lịch sử repo và giải thích vì sao dọn dẹp cần phối hợp. Hướng dẫn xóa dữ liệu nhạy cảm của GitHub
Đưa việc quản lý key vào vận hành
Trước khi ra mắt, hãy xác nhận rằng có người trả lời được: ai sở hữu key này, dịch vụ nào dùng key, điều gì ngăn chặn việc sử dụng lạm dụng, và làm sao để vô hiệu hóa key?
Một tích hợp dễ quản lý có câu trả lời cụ thể. Nếu câu trả lời là “mọi người dùng chung một key,” hãy sửa ranh giới đó trước khi mở rộng lưu lượng. Quản lý key an toàn hơn không nằm ở mẹo lưu trữ khéo léo mà ở việc giữ quyền truy cập hẹp, chi tiêu minh bạch, và thu hồi thiết thực.