Quét tìm bí mật API AI nên tìm thấy các khóa của nhà cung cấp trước khi chúng trở thành một phiếu sự cố, một hóa đơn bất ngờ, hoặc một sự cố ngừng hoạt động sản xuất. Đối với các đội ngũ AI, điều đó có nghĩa là quét nhiều hơn cả mã nguồn. Các khóa của nhà cung cấp có thể trôi dạt vào notebook, các bộ kiểm thử prompt, biến CI, runbook, bản ghi hỗ trợ, các lớp Docker, các tự động hóa trình duyệt, và các ví dụ được sao chép từ cuộc trò chuyện nội bộ.
Kế hoạch phòng ngừa rất đơn giản: quét ở những nơi công việc AI diễn ra, ánh xạ mỗi phát hiện tới một người sở hữu, chứng minh xem khóa có đang hoạt động hay không, xoay vòng phạm vi phù hợp, và lưu giữ bằng chứng mà các bộ phận mua sắm, tài chính, kỹ thuật nền tảng và bảo mật đều có thể đọc được.
Flatkey hữu ích trong quy trình làm việc này vì trang web công khai hiện tại định vị flatkey.ai xoay quanh một khóa API duy nhất để truy cập các mô hình chính thức của GPT, Claude, Gemini, DeepSeek, hình ảnh, âm thanh và video, với khả năng hiển thị trên bảng điều khiển về việc sử dụng, chi phí, định tuyến và lỗi. Điều đó có thể làm giảm sự lan rộng của các khóa từ nhà cung cấp trực tiếp, nhưng không loại bỏ nhu cầu quét tìm bí mật API AI. Hãy coi mọi thông tin xác thực của Flatkey, OpenAI, Anthropic, Gemini và các nhà cung cấp khác như một bí mật cần được quét, xác định quyền sở hữu, phạm vi và bằng chứng xoay vòng.
Đối với lộ trình xoay vòng, hãy kết hợp hướng dẫn này với danh sách kiểm tra cổng xoay vòng khóa API AI, quy trình xem xét quyền truy cập API AI, chính sách biên tập lại API AI, và danh sách kiểm tra ghi nhật ký payload API AI.
Quy trình làm việc Quét tìm Bí mật API AI
Hầu hết các đội ngũ đã biết rằng họ không nên commit các khóa API. Vấn đề khó hơn là vận hành một quy trình làm việc có thể phát hiện khóa sớm và vẫn cho người sở hữu sự cố biết phải làm gì tiếp theo.
| Giai đoạn | Nội dung cần quét | Quyết định cần đưa ra | Bằng chứng cần lưu giữ |
|---|---|---|---|
| Trước khi commit | Tệp cục bộ, notebook, cấu hình, bộ kiểm thử | Commit có thể tiếp tục không? | Tên trình quét, phiên bản bộ quy tắc, đường dẫn bị chặn, người sở hữu là nhà phát triển |
| Pull request | Diff, các tệp đã thêm, các tài sản được tạo ra | PR nên bị chặn hay cần xem xét? | ID phát hiện, họ bí mật, đường dẫn, người xem xét, giải pháp |
| Đường ống CI | Toàn bộ kho lưu trữ và bối cảnh xây dựng | Có gì lọt vào nhánh sau khi kiểm tra cục bộ không? | Tác vụ CI, SHA của commit, đầu ra của trình quét, thay đổi danh sách cho phép |
| Registry và kho lưu trữ artifact | Container, gói, nhật ký xây dựng | Có khóa nào rời khỏi kiểm soát nguồn không? | Digest của artifact, đường dẫn lớp/tệp, trạng thái thu hồi |
| Hệ thống runtime và hỗ trợ | Nhật ký, dấu vết, runbook, phiếu, bản ghi | Có khóa nào trở nên có thể quan sát được bên ngoài bộ phận kỹ thuật không? | Chỉ mục nhật ký, ID phiếu, trạng thái lưu giữ, phiếu biên tập lại |
| Sau khi xoay vòng | Bảng điều khiển sử dụng, bản ghi kiểm toán của nhà cung cấp, nhật ký cổng | Khóa cũ đã ngừng hoạt động và khóa mới có giữ đúng phạm vi không? | Khóa cũ bị vô hiệu hóa, chủ sở hữu khóa mới, kiểm thử sơ bộ, xem xét sử dụng |
Đây là quy tắc cốt lõi cho việc quét tìm bí mật API AI: một phát hiện không được đóng lại khi một mẫu khớp. Nó được đóng lại khi đội ngũ biết liệu thông tin xác thực có hợp lệ hay không, nó đã bị lộ ở đâu, ai sở hữu nó, cái gì đã được xoay vòng, và bản ghi nào chứng minh rằng khóa cũ không còn quan trọng nữa.
Bắt đầu với Phạm vi bao phủ Khóa của Nhà cung cấp
Đừng dựa vào một regex "khóa API" chung chung. Các đội ngũ AI thường làm việc với nhiều nhà cung cấp, cổng và công cụ, mỗi loại có hình dạng khóa và mô hình quyền khác nhau.
Xây dựng một danh sách các nhà cung cấp trước khi tinh chỉnh các quy tắc:
| Họ thông tin xác thực | Nơi thường xuất hiện | Yêu cầu quét |
|---|---|---|
| Khóa OpenAI và thông tin xác thực tài khoản dịch vụ | Dịch vụ backend, notebook, bộ công cụ đánh giá, ví dụ SDK AI | Phát hiện các chuỗi khóa có khả năng, bối cảnh dự án/tài khoản dịch vụ, sự không khớp giữa tổ chức/dự án, và các khóa cũ đã bị thu hồi trong bộ nhớ đệm cục bộ |
| Khóa Anthropic | Công cụ agent, các trình bao bọc phía máy chủ, kiểm thử notebook, các ví dụ SDK dành riêng cho Claude | Phát hiện các khóa trực tiếp và tách chúng khỏi ID không gian làm việc, token quản trị, và các ví dụ vô hại |
| Khóa API Gemini hoặc Google | Nguyên mẫu client, notebook, tệp env, ví dụ cho di động/web | Phát hiện các khóa API và kiểm tra xem các hạn chế, việc xoay vòng và xóa có được ghi lại hay không |
| Các khóa cổng như khóa Flatkey | Mã bộ định tuyến mô hình dùng chung, ví dụ di chuyển URL cơ sở, kiểm thử sơ bộ CI | Quét và xoay vòng khóa cổng giống như một khóa của nhà cung cấp trực tiếp |
| Các ngoại lệ của trình quét | Bộ kiểm thử, tài liệu, ví dụ, các giá trị đã băm | Giữ cho danh sách cho phép hẹp, được xem xét, có thời hạn và cụ thể theo đường dẫn |
Tài liệu chính thức của các trình quét hỗ trợ cách tiếp cận nhiều lớp này. Tính năng quét bí mật của GitHub bao gồm các mẫu bí mật được hỗ trợ, bảo vệ khi đẩy (push protection), và các mẫu tùy chỉnh. Tính năng phát hiện bí mật của GitLab có thể chạy trong các đường ống. Gitleaks và TruffleHog là các trình quét kho lưu trữ/lịch sử phổ biến. Tài liệu của nhà cung cấp sau đó sẽ cho bạn biết cách xử lý họ khóa bị ảnh hưởng sau khi phát hiện.
Đặt Việc Quét ở Mọi Nơi Khóa AI Di Chuyển
Một khóa API AI có thể bị rò rỉ mà không cần được commit vào main.
Sử dụng danh sách kiểm tra vị trí tối thiểu này:
- Chạy trình quét pre-commit cục bộ cho mã nguồn, tệp
.env, notebook, các fixture được tạo và ví dụ về prompt. - Bật tính năng quét bí mật do kho lưu trữ lưu trữ và bảo vệ push ở những nơi nền tảng hỗ trợ.
- Chạy phát hiện bí mật CI trên các pull request và các nhánh được bảo vệ.
- Quét lịch sử Git trước khi xuất bản các ví dụ SDK, mẫu công khai hoặc kho lưu trữ khởi đầu nội bộ.
- Quét các image container và các tạo phẩm gói trước khi phát hành.
- Quét các runbook hỗ trợ, ghi chú sự cố và các gói khắc phục sự cố đã xuất để tìm các bí mật đã sao chép.
- Xem lại nhật ký và dấu vết để tìm các kết xuất prompt, header hoặc môi trường vô tình.
Lần quét đầu tiên của quét tìm bí mật API AI nên có phạm vi rộng. Lần quét thứ hai nên chính xác: tinh chỉnh danh sách cho phép, thêm các mẫu tùy chỉnh cho khóa cổng hoặc các trình bao bọc nội bộ, và ngăn các kết quả dương tính giả khiến nhóm bỏ qua các cảnh báo.
Ánh xạ mọi phát hiện đến một chủ sở hữu
Quét bí mật mà không có quyền sở hữu sẽ trở thành một hàng đợi các chuỗi đáng sợ. Trước khi bạn xoay vòng, hãy ghi lại phạm vi hoạt động.
| Trường | Tại sao nó quan trọng |
|---|---|
| Nhãn khóa không bí mật | Cho phép các nhóm thảo luận về khóa mà không cần sao chép bí mật |
| Nhà cung cấp hoặc cổng | Xác định nơi thu hồi, xoay vòng và kiểm tra việc sử dụng |
| Chủ sở hữu | Nêu tên nhóm hoặc tài khoản dịch vụ chịu trách nhiệm về khóa |
| Môi trường | Phân tách môi trường phát triển, staging, sản xuất, batch, đánh giá và tự động hóa hỗ trợ |
| Các mô hình và điểm cuối được phép | Cho biết liệu khóa có thể tiếp cận các bề mặt văn bản, hình ảnh, video, batch hoặc quản trị hay không |
| Lớp dữ liệu | Làm rõ liệu các prompt có thể chứa văn bản của khách hàng, dữ liệu được quy định, bí mật hoặc dữ liệu chỉ dùng nội bộ hay không |
| Sử dụng gần đây | Giúp quyết định liệu khóa có bị lạm dụng hay chỉ đơn giản là bị lộ |
| Chủ sở hữu xoay vòng | Nêu tên người có thể tạo khóa thay thế và cập nhật các triển khai |
| Chủ sở hữu tài chính | Giúp giải thích các đợt tăng đột biến chi phí từ lưu lượng bị rò rỉ, thử lại hoặc có số token cao |
Flatkey có thể giúp việc xem xét này khi nhóm của bạn định tuyến lưu lượng mô hình đã được phê duyệt thông qua một cổng tương thích với OpenAI và xem xét việc sử dụng, chi phí, định tuyến và lỗi hiện tại từ bảng điều khiển sản phẩm. Hãy giữ cho tuyên bố đó ở phạm vi hẹp: xác minh các trường bảng điều khiển hiện tại chính xác, hàng giá, tuyến mô hình, khả năng hiển thị nhật ký và nhãn khóa trong tài khoản của bạn trước khi dựa vào chúng làm bằng chứng cho sự cố.
Phân loại tính hợp lệ trước khi xác định phạm vi xoay vòng
Không phải mọi kết quả khớp đều là một sự cố đang diễn ra. Một số phát hiện là giá trị thử nghiệm, đoạn mã bị cắt ngắn, ví dụ hoặc các khóa đã bị thu hồi. Việc phân loại vẫn nên nhanh chóng và thận trọng.
Sử dụng bảng phân loại này:
| Tín hiệu | Ý nghĩa | Hành động |
|---|---|---|
| Bí mật có khả năng đầy đủ trong mã nguồn, nhật ký hoặc ticket | Giả định đã bị lộ cho đến khi có bằng chứng ngược lại | Thu hồi hoặc xoay vòng ngay lập tức, sau đó điều tra việc sử dụng |
| Khóa một phần, giá trị bị che hoặc ảnh chụp màn hình bị mờ | Vẫn có thể tiết lộ ngữ cảnh tài khoản hoặc tiền tố | Xem xét thủ công và biên tập lại nếu hữu ích cho kẻ tấn công |
| Lộ ra trên kho lưu trữ công khai | Khả năng truy cập từ bên ngoài | Xoay vòng, bảo quản bằng chứng, kiểm tra việc sử dụng của nhà cung cấp, thông báo cho chủ sở hữu |
| Lộ ra trên nhánh chỉ dùng nội bộ | Rủi ro bên ngoài thấp hơn, nhưng vẫn không an toàn | Xoay vòng dựa trên môi trường và đặc quyền |
| Trùng khớp với danh sách cho phép của trình quét | Có thể là dương tính giả hoặc fixture thử nghiệm được chấp nhận | Yêu cầu người xem xét, ngày hết hạn và đường dẫn chính xác |
| Sử dụng bất ngờ sau khi bị lộ | Có thể bị lạm dụng hoặc sai lệch tự động hóa | Vô hiệu hóa khóa, thu thập nhật ký, leo thang quy trình xử lý sự cố |
Nếu phát hiện là khóa của nhà cung cấp AI trong môi trường sản xuất, hãy xoay vòng trước và tranh luận sau. Các khối lượng công việc AI có thể tạo ra rủi ro thực sự về chi phí, dữ liệu và độ tin cậy chỉ trong vài phút.
Xoay vòng phạm vi nhỏ, không phải toàn bộ tài khoản
Quét tìm bí mật API AI tốt sẽ dễ dàng hơn khi các khóa được giới hạn phạm vi trước khi chúng bị rò rỉ. Một khóa sản xuất được chia sẻ sẽ buộc phải có một phản ứng trên diện rộng. Các khóa riêng biệt theo chủ sở hữu, môi trường, khối lượng công việc và tuyến cho phép bạn xoay vòng trong một bán kính ảnh hưởng nhất định.
Đối với các khóa API AI, kế hoạch xoay vòng nên nêu rõ:
| Câu hỏi về xoay vòng | Câu trả lời xem xét |
|---|---|
| Chính xác thì cái gì đã bị rò rỉ? | Nhà cung cấp hoặc cổng, nhãn khóa không bí mật, đường dẫn, commit, tạo phẩm, nhật ký hoặc ticket |
| Nó có thể làm gì? | Các mô hình, họ điểm cuối, hành động quản trị, ngân sách, dự án, tổ chức và tuyến |
| Ai sở hữu khóa thay thế? | Nhóm, tài khoản dịch vụ, chủ sở hữu nền tảng, chủ sở hữu tài chính |
| Các triển khai sẽ cập nhật như thế nào? | Đường dẫn trình quản lý bí mật, biến CI, cấu hình thời gian chạy, kế hoạch dự phòng |
| Việc sử dụng cũ sẽ được phát hiện như thế nào? | Việc sử dụng của nhà cung cấp, nhật ký cổng, ID yêu cầu, bảng điều khiển chi phí, cảnh báo |
| Bằng chứng nào sẽ kết thúc sự cố? | Hồ sơ thu hồi, kiểm tra sơ bộ khóa mới, không có việc sử dụng sau khi thu hồi, ticket biên tập |
Tài liệu nền tảng OpenAI hiện tại phân tách các quyền khóa API dự án, quản trị dự án, tài khoản dịch vụ, bảng điều khiển sử dụng và quyền yêu cầu mô hình. Anthropic ghi lại các khái niệm xác thực bằng khóa API và quản lý quản trị/API. Hướng dẫn về khóa API của Google Cloud nhấn mạnh các hạn chế, xoay vòng, xóa và tránh sử dụng khóa trong mã phía máy khách hoặc mã công khai. Hãy sử dụng các biện pháp kiểm soát dành riêng cho nhà cung cấp đó thay vì viết một bước xoay vòng trung lập với nhà cung cấp mà không ai có thể thực thi.
Thêm khóa cổng vào trình quét
Khi một nhóm áp dụng một cổng AI, các khóa nhà cung cấp trực tiếp sẽ trở nên hiếm hơn trong mã ứng dụng. Điều đó là tốt. Nhưng khóa cổng lại trở nên quan trọng.
Đối với Flatkey, các trang công khai hiện tại được kiểm tra vào ngày 11 tháng 7 năm 2026 cho thấy định vị xoay quanh một khóa, một URL cơ sở cổng tương thích với OpenAI, phân tích sử dụng, kiểm soát chi phí, nhật ký yêu cầu, một hóa đơn cho tất cả các nhà cung cấp và một số dư cho tất cả các họ mô hình. Hãy sử dụng thông tin đó như bằng chứng công khai có ghi ngày, không phải là sự đảm bảo vĩnh viễn cho tài khoản.
Trình quét của bạn vẫn nên coi khóa cổng là một bí mật sản xuất:
- Thêm các mẫu tùy chỉnh cho bất kỳ định dạng khóa cổng nào đã được ghi nhận hoặc xác nhận qua tài khoản.
- Gắn nhãn các khóa theo chủ sở hữu, môi trường, tuyến đường và chủ sở hữu ngân sách.
- Giữ các khóa của nhà cung cấp trực tiếp ra khỏi kho ứng dụng sau khi một tuyến đường cổng được phê duyệt.
- Quét tài liệu di chuyển và các ví dụ để tìm các khóa cũ của nhà cung cấp đã được sao chép.
- Xem lại bảng điều khiển sử dụng cổng sau khi phát hiện để xem liệu có các tuyến đường, mô hình hoặc chi tiêu không mong muốn xuất hiện hay không.
- Lưu trữ khóa cổng trong cùng một trình quản lý bí mật và quy trình luân chuyển như thông tin xác thực của nhà cung cấp trực tiếp.
Điều này giữ được lợi ích của việc hợp nhất mà không biến một thông tin xác thực cổng thành một siêu khóa chia sẻ không được xem xét.
Kiểm soát kết quả dương tính giả mà không che giấu rủi ro
Kết quả dương tính giả là không thể tránh khỏi. Hãy coi danh sách cho phép như một biện pháp kiểm soát bảo mật, không phải là một ngăn kéo chứa đồ linh tinh.
| Quy tắc danh sách cho phép | Biện pháp kiểm soát bắt buộc |
|---|---|
| Dữ liệu thử nghiệm | Sử dụng các giá trị giả rõ ràng và giữ chúng trong một đường dẫn chỉ dành cho thử nghiệm |
| Ví dụ trong tài liệu | Sử dụng kiểu giữ chỗ được nhà cung cấp phê duyệt, không bao giờ sử dụng tiền tố thật cộng với entropy thực tế |
| Phát hiện trong quá khứ | Liên kết đến phiếu luân chuyển và quyết định xóa bỏ |
| Tệp được tạo | Tạo lại mà không có các chuỗi giống bí mật hoặc loại trừ đường dẫn tạo tệp kèm theo xem xét |
| Mẫu của nhà cung cấp | Giữ một liên kết nguồn và chứng minh rằng nó không thể xác thực |
| Ngoại lệ tạm thời | Thêm chủ sở hữu, ngày hết hạn và xem xét gia hạn |
Nếu các nhà phát triển liên tục đưa các ví dụ trông giống thật vào danh sách cho phép, hãy sửa các mẫu. Các ví dụ tốt hơn sẽ giảm bớt sự mệt mỏi do cảnh báo và giảm khả năng một vụ rò rỉ khóa API LLM thực sự trông có vẻ bình thường.
Xây dựng Gói Bằng chứng
Đầu ra của việc quét tìm bí mật API AI nên là một gói bằng chứng nhỏ có thể tồn tại qua các lần chuyển giao giữa các bộ phận kỹ thuật, bảo mật, mua sắm và tài chính.
Hồ sơ bằng chứng quét tìm bí mật API AI
ID phát hiện:
Trình quét và phiên bản quy tắc:
Nhà cung cấp hoặc cổng:
Nhãn khóa không phải bí mật:
Kho, tạo phẩm, nhật ký hoặc phiếu:
SHA commit hoặc digest tạo phẩm:
Chủ sở hữu:
Môi trường:
Tuyến đường và họ điểm cuối được phép:
Lớp dữ liệu:
Khóa có hợp lệ không:
Có sử dụng sau khi bị lộ không:
Hành động luân chuyển:
Khóa cũ bị vô hiệu hóa lúc:
Khóa thay thế được triển khai lúc:
ID yêu cầu kiểm tra sơ bộ:
Xem xét chi phí hoặc sử dụng:
Phiếu biên tập/xóa bỏ:
Người xem xét:
Tác nhân gia hạn:Không dán khóa thô vào hồ sơ này. Sử dụng nhãn không phải bí mật, ID khóa, tham chiếu bảng điều khiển của nhà cung cấp hoặc mã định danh đã được băm và được bộ phận bảo mật phê duyệt.
Các câu hỏi cần đặt ra cho bộ phận mua sắm
Đối với người mua ở giai đoạn quyết định, việc quét tìm bí mật API AI thuộc về quá trình xem xét nhà cung cấp và vận hành. Hãy hỏi:
| Câu hỏi | Tại sao nó quan trọng |
|---|---|
| Hiện có bao nhiêu khóa nhà cung cấp trực tiếp trong các kho ứng dụng? | Đo lường sự lan rộng của khóa trước khi hợp nhất cổng |
| Công cụ nào chặn bí mật trước khi đẩy lên và trong CI? | Cho thấy liệu có biện pháp phòng ngừa nào tồn tại trước khi ứng phó sự cố hay không |
| Các định dạng khóa của nhà cung cấp và cổng có được bao phủ không? | Ngăn chặn các điểm mù của trình quét |
| Ai sở hữu từng khóa API AI sản xuất? | Giúp việc luân chuyển trở nên khả thi |
| Các khóa có được tách biệt theo môi trường và khối lượng công việc không? | Giảm bán kính ảnh hưởng |
| Việc sử dụng có thể được xem xét theo khóa, tuyến đường, mô hình và chi phí không? | Hỗ trợ xem xét lạm dụng và tài chính |
| Sổ tay hướng dẫn luân chuyển khẩn cấp là gì? | Chứng minh rằng nhóm có thể hành động mà không cần chờ đợi một cuộc họp rút kinh nghiệm sau sự cố |
| Các ngoại lệ của trình quét được xem xét như thế nào? | Ngăn chặn sự sai lệch của danh sách cho phép |
Nếu bạn đang đánh giá Flatkey, hãy thêm một bước chứng minh dành riêng cho Flatkey: tạo một khóa thử nghiệm, chạy một yêu cầu rủi ro thấp thông qua tuyến đường mô hình dự định, và xác minh các bằng chứng về việc sử dụng, chi phí, định tuyến và xem xét khóa hiện tại mà nhóm của bạn sẽ dựa vào. Sau đó, quyết định xem liệu các khóa của nhà cung cấp trực tiếp có thể được xóa khỏi cấu hình cấp ứng dụng hay không.
Câu hỏi thường gặp
Quét tìm bí mật API AI là gì?
Quét tìm bí mật API AI là hoạt động tìm kiếm các khóa API của nhà cung cấp AI và cổng trong mã nguồn, lịch sử Git, biến CI, tạo phẩm, nhật ký, sổ tay hướng dẫn, phiếu hỗ trợ và các bề mặt quy trình làm việc khác trước khi thông tin xác thực bị lộ gây ra tác động về chi phí, dữ liệu hoặc độ tin cậy.
Quét tìm bí mật API AI có khác với quét tìm bí mật thông thường không?
Cơ chế quét có sự tương đồng, nhưng các khóa AI cần được xem xét thêm về quyền truy cập mô hình, họ điểm cuối, việc lộ lọt prompt và đầu ra, chi phí token, các tuyến đường dự phòng và bằng chứng luân chuyển dành riêng cho nhà cung cấp. Một khóa AI bị rò rỉ có thể tạo ra cả rủi ro bảo mật và chi tiêu sử dụng tăng nhanh.
Tôi có nên quét tìm khóa cổng cũng như khóa của nhà cung cấp trực tiếp không?
Có. Một cổng có thể giảm sự lan rộng của khóa nhà cung cấp trực tiếp, nhưng khóa cổng vẫn cấp quyền truy cập mô hình. Hãy quét tìm nó, lưu trữ trong trình quản lý bí mật, chỉ định chủ sở hữu, tách biệt các môi trường và luân chuyển nó khi bị lộ.
Điều gì nên kết thúc một phát hiện rò rỉ khóa API AI?
Một phát hiện chỉ nên được đóng lại sau khi bí mật thô đã được xóa hoặc biên tập, khóa đã bị thu hồi hoặc luân chuyển, việc sử dụng sau khi bị lộ đã được xem xét, chủ sở hữu đã được thông báo, khóa thay thế đã được kiểm tra sơ bộ và bằng chứng đã được đính kèm vào hồ sơ sự cố hoặc hồ sơ xem xét quyền truy cập.
Flatkey có cung cấp tính năng quét tìm bí mật API AI không?
Đừng giả định điều đó từ các trang công khai. Các trang công khai của Flatkey hỗ trợ truy cập mô hình bằng một khóa, định tuyến tương thích với OpenAI, phân tích sử dụng, kiểm soát chi phí, nhật ký yêu cầu và khả năng hiển thị thanh toán. Sử dụng các trình quét kho lưu trữ, CI, tạo phẩm và nhật ký của bạn để tìm bí mật, sau đó sử dụng bằng chứng tài khoản Flatkey ở những nơi có liên quan để xem xét việc sử dụng và xoay vòng khóa cổng.
Kết luận
Quét tìm bí mật API AI nên là một quy trình phòng ngừa, chứ không phải là một lệnh grep sau khi rò rỉ. Quét mã, lịch sử, CI, tạo phẩm, nhật ký, phiếu yêu cầu và sổ tay vận hành. Bao gồm các khóa nhà cung cấp trực tiếp và khóa cổng. Ánh xạ mọi phát hiện đến một chủ sở hữu và phạm vi. Xoay vòng khóa với bán kính ảnh hưởng an toàn nhỏ nhất. Lưu bằng chứng chứng minh khóa cũ đã bị xóa và tuyến đường mới đã được kiểm soát.
Nếu bạn muốn giảm sự lan rộng của khóa nhà cung cấp trực tiếp trong khi vẫn giữ việc truy cập mô hình, định tuyến, sử dụng và xem xét chi phí ở một nơi, nhận một khóa, sau đó thêm khóa Flatkey vào cùng quy trình quét tìm bí mật API AI và xoay vòng khóa mà bạn sử dụng cho mọi thông tin xác thực của nhà cung cấp.
Các nguồn để xem xét
- Trang chủ Flatkey
- Bảng giá Flatkey
- Quét tìm bí mật của GitHub
- Bảo vệ push của GitHub
- Các mẫu quét tìm bí mật được GitHub hỗ trợ
- Phát hiện bí mật của GitLab
- Kho lưu trữ Gitleaks
- Kho lưu trữ TruffleHog
- Quyền RBAC trên nền tảng OpenAI
- Xác thực Anthropic
- Các phương pháp hay nhất về khóa API của Google Cloud
