Tiêu Chuẩn Mở ORKS: Hồi Chuông Tự Hủy Cho API Key

Mọi lãnh đạo an ninh mạng đều từng trải qua một sự cố tương tự: một nhà nghiên cứu, một máy quét, hay một người lạ tốt bụng tìm thấy một trong những API key của bạn nằm trong một kho lưu trữ công khai. Đồng hồ bắt đầu đếm ngược, nhưng thay vì một công tắc tiêu diệt, những gì diễn ra sau đó lại là một cuộc săn tìm thông tin mệt mỏi. Key này do công ty nào phát hành? Tôi nên liên hệ với ai? Có file security.txt không? Có ai đọc hộp thư đó không? Đến khi đúng người thu hồi đúng thông tin đăng nhập, thì hàng giờ hoặc hàng ngày đã trôi qua, trong khi kẻ tấn công chỉ cần vài phút. Các bot quét các kho lưu trữ công khai liên tục và phần lớn các bí mật bị rò rỉ vẫn còn hoạt động trong nhiều năm sau đó.

Điều khiến tôi băn khoăn về vấn đề này là chúng ta đã từng giải quyết được nó một lần. Vào năm 2013, OAuth có được RFC 7009, một chuẩn endpoint thu hồi token có thể được khám phá thông qua một URL cấu hình nổi tiếng (well-known). Bất kỳ client nào tuân thủ cũng có thể tiêu diệt một token một cách lập trình. Sau đó, ngành công nghiệp tiếp tục cung cấp các API key thô, loại thông tin đăng nhập thực sự bị rò rỉ nhiều nhất, mà không có một cơ chế thu hồi nào.

Điểm sáng duy nhất là GitHub Secret Scanning Partner Program: các nhà cung cấp đăng ký mẫu key của họ, GitHub quét các commit công khai và việc thu hồi thông qua webhook. Nó hoạt động, nhưng lại độc quyền, tập trung và chỉ dành cho những người được mời. Trong khi đó, hãy nhìn vào hướng đi của các công cụ quét mã nguồn mở mới. Thế hệ máy quét mới đều liệt kê cùng một mục trong lộ trình: tự động thu hồi thông qua các API của nhà cung cấp. Mỗi một công cụ trong số đó sẽ phải tự tay xây dựng các tích hợp, từng nhà cung cấp một, bởi vì không có một tiêu chuẩn nào để yêu cầu nhà phát hành "vui lòng tiêu diệt key này."

Đây chính là khoảng trống. Vì vậy, hãy để tôi phác thảo một tiêu chuẩn mà tôi muốn nó tồn tại. Tôi đặt tên cho nó là ORKS (Open Revocable Key Standard - Tiêu chuẩn khóa có thể thu hồi mở), với một bản đặc tả được đăng trên GitHub. Giống như những cuốn băng với lời dặn dò tự hủy trong bộ phim "Nhiệm vụ bất khả thi", ý tưởng rất đơn giản: mọi thông tin đăng nhập nên có cơ chế tự hủy được tích hợp sẵn.

Bốn Phần Chính Của Đề Xuất

1. Key có khả năng tự xưng danh nhà phát hành. Mỗi key mang một tiền tố cố định, tên miền của nhà phát hành (được mã hóa), phần bí mật và một mã kiểm tra (checksum): orks_{issuer}_{secret}_{check}. GitHub đã chứng minh cả hai nửa của mô hình này. Tiền tố token của họ giúp việc quét trở nên khả thi và checksum nhúng đã loại bỏ các cảnh báo sai. Điểm mới ở đây là tên miền của nhà phát hành, để bất kỳ máy quét nào tìm thấy một key cũng có thể biết chính xác phải gọi cho ai mà không cần kết nối mạng.

2. Một công tắc tiêu diệt có thể khám phá. Mọi nhà phát hành sẽ phục vụ một file JSON nhỏ tại đường dẫn /.well-known/api-key-config, chứa endpoint thu hồi, endpoint kiểm tra tùy chọn, đầu mối liên hệ an ninh và các ràng buộc key mà họ hỗ trợ. Cơ chế này giống như giao thức khám phá OIDC hay security.txt đã làm.

3. Thu hồi bằng quyền sở hữu. Chỉ cần gửi POST toàn bộ key tới endpoint thu hồi, không yêu cầu xác thực. Logic ở đây: bất kỳ ai giữ key đều có thể lạm dụng nó, vì vậy việc cho phép họ tiêu hủy nó là một sự cải thiện thực sự. Việc yêu cầu toàn bộ key đồng nghĩa với việc không có gì để liệt kê (enumerate), và endpoint sẽ trả về phản hồi "đã chấp nhận" giống nhau dù key đó đang hoạt động, đã chết hay chưa từng tồn tại.

4. Các ràng buộc được công bố. File khám phá (discovery file) quảng cáo các ràng buộc mà nhà phát hành hỗ trợ như danh sách IP được phép, thời gian hết hạn bắt buộc, phạm vi truy cập (scopes) và xác thực mTLS. Đột nhiên, câu hỏi "liệu nhà cung cấp này có hỗ trợ khóa ghim IP không?" có thể được trả lời bằng một yêu cầu GET đơn giản thay vì cả một chuỗi email kéo dài hai tuần.

Sợi dây kéo không làm dừng chuyền sản xuất

Phản đối mạnh nhất đối với việc thu hồi không cần xác thực là tính sẵn sàng. Nếu quyền sở hữu trao quyền thu hồi, một key bị rò rỉ không chỉ là vấn đề bảo mật dữ liệu (confidentiality). Bất kỳ ai tìm thấy nó cũng có thể phá vỡ tích hợp sản xuất của bạn chỉ với một lệnh curl.

Câu trả lời của Toyota cho một tình huống tương tự là sợi dây andon (dây kéo để cảnh báo): bất kỳ công nhân nào cũng có thể kéo nó, nhưng kéo nó không làm nhà máy dừng ngay lập tức. Nó chỉ báo hiệu sự chú ý, và chuyền sản xuất chỉ dừng lại nếu vấn đề không được giải quyết trong một khoảng thời gian nhất định. ORKS mượn thiết kế đó với một tùy chọn chế độ cách ly (quarantine). Một yêu cầu thu hồi không cần xác thực không tiêu diệt ngay lập tức. Thay vào đó:

• Chủ sở hữu được thông báo ngay lập tức qua mọi kênh đã đăng ký, kèm theo bằng chứng của người báo cáo.
• Key bị hạn chế ngay lập tức: chỉ đọc, bị giới hạn tốc độ, các thao tác phá hủy bị chặn, mọi hành động đều bị ghi log.
• Một bộ đếm thời gian bắt đầu (mặc định 24 giờ, được quảng cáo trong file khám phá). Khi hết thời gian, key sẽ tự động tiêu diệt.
• Chủ sở hữu có thể tăng tốc để thu hồi ngay lập tức hoặc hủy bỏ sau khi xác nhận bằng chứng, chỉ thực hiện qua trang tổng quan được xác thực, không bao giờ qua liên kết email.

Việc quấy rối trở thành một quá trình kiểm soát, dừng lại từ từ thay vì một sự cố gián đoạn hoàn toàn. Một key thực sự bị rò rỉ sẽ trải qua những giờ phút cuối cùng trong tình trạng "bị còng tay" thay vì hoàn toàn hoạt động. Và đối với các loại key có rủi ro cao như thanh toán và quản trị, nhà phát hành có thể tuyên bố chế độ thu hồi ngay lập tức. Sự đánh đổi này trở thành một chính sách rõ ràng, được công bố thay vì một sự ngẫu nhiên dựa trên việc ai đọc hộp thư an ninh đầu tiên.

Tại Sao AI Agent Khiến Điều Này Trở Nên Cấp Thiết?

Tất cả những điều trên đều đúng khi chủ sở hữu thông tin đăng nhập là một nhà phát triển và một đường ống CI/CD. Vấn đề trở nên gay gắt hơn khi chủ sở hữu đó ngày càng là một AI agent tự động.

Các agent là những "kẻ nhân bản thông tin đăng nhập". Một agent duy nhất được kết nối vào hệ thống công cụ của bạn sẽ nắm giữ key cho email, mã nguồn, CRM, thanh toán và hạ tầng đám mây cùng một lúc, và các nhóm triển khai agent nhanh hơn nhiều so với việc họ kiểm kê chúng. Các agent cũng gây rò rỉ theo những cách khác: chúng có thể bị ép buộc thông qua tấn công Prompt Injection (tiêm nhiễm chỉ dẫn) để đánh cắp chính thông tin đăng nhập của chúng và chúng phản ánh các bí mật vào log với tốc độ máy móc. Khoảng thời gian từ lúc bị xâm phạm đến lúc bị lạm dụng giảm từ nhiều ngày xuống còn vài giây, điều này khiến bất kỳ con đường thu hồi nào bắt đầu bằng một email đều quá chậm.

ORKS phù hợp với kỷ nguyên agent theo ba cách:

• Một công tắc tiêu diệt có thể đọc bằng máy chính xác là giao diện mà một hệ thống tự động có thể sử dụng.
• Một rào chắn an toàn bắt được một nỗ lực tấn công tiêm nhiễm đang diễn ra có thể cách ly chính thông tin đăng nhập đó như một phản xạ.
• Các ràng buộc được khai báo là cách để bạn trao một chiếc chìa khóa cho thứ mà bạn không hoàn toàn tin tưởng: khóa ghim IP, giới hạn phạm vi, thời gian sống ngắn.

Và mô hình tôi thích nhất đã đảo ngược hoàn toàn vấn đề: một agent hoàn thành nhiệm vụ của mình nên tự thu hồi khóa của chính nó khi kết thúc. Các khóa được tạo với chính sách "tự thu hồi ngay" cùng với TTL ngắn cho bạn đặc quyền tối thiểu trên chiều thời gian. Một khóa được tìm thấy trong log sau khi nhiệm vụ của nó đã hoàn thành là một khóa đã chết, và cuộc gọi thu hồi đóng vai trò như một sự kiện kiểm toán.

Ngành công nghiệp đang hội tụ vào các giải pháp kiểu OAuth cho danh tính agent, và điều đó là đúng đắn. Nhưng thực tế trong giai đoạn chuyển tiếp là hàng triệu agent đang giữ các khóa tĩnh cho các dịch vụ không cung cấp giải pháp tốt hơn. Một tiêu chuẩn thu hồi không làm cho những khóa đó trở nên "tốt". Nó khiến chúng có thể bị "tiêu diệt". Và đối với một agent có thể bị thao túng để lạm dụng chúng, đó chính là đặc tính quan trọng nhất.

Con Đường Phía Trước

Vẻ đẹp của các quy ước well-known là chúng không cần một cơ quan trung ương cũng như không cần sự chấp nhận trên diện rộng ngay lập tức. Một nhà cung cấp duy nhất có thể ra mắt trong sprint tiếp theo: thêm tiền tố vào khóa của bạn, xuất bản một file JSON tĩnh, thiết lập một endpoint. Các máy quét đang chạy đua để xây dựng các tích hợp thu hồi riêng cho từng nhà cung cấp sẽ có được một bộ phát hiện tổng quát. Mỗi nhà phát hành mới làm cho mọi máy quét trở nên hữu ích hơn, đó chính là vòng lặp đã làm cho security.txt trở nên phổ biến.

Điểm cuối cùng là sự nhàm chán theo hướng tốt nhất:

Một khóa bị rò rỉ, một máy quét hoặc chính agent đó tìm thấy nó trong vài phút, giải mã nhà phát hành, truy cập endpoint well-known và cách ly thông tin đăng nhập. Chủ sở hữu thức dậy với một thông báo, một liên kết bằng chứng và một nút "xoay khóa" thay vì một báo cáo gian lận.

Nhiệm vụ của bạn, nếu bạn chấp nhận: hãy làm cho mọi khóa bạn phát hành đều có khả năng tự tiêu diệt. Đề xuất này sẽ không phủ nhận bạn.

Bản đặc tả đầy đủ (ORKS v0.1), bao gồm các lược đồ endpoint, định dạng khóa và trạng thái máy cách ly, đang được mở để xem xét và đóng góp tại github.com/6d6b68/ORKS. Mọi phản hồi, ý kiến phản đối và các công trình tiền nhiệm mà tôi có thể đã bỏ sót đều được hoan nghênh: hãy mở một issue hoặc một pull request.

Minh họa về định dạng key và cơ chế thu hồi chuẩn

Về Tác Giả

Chân dung Matt Honea

Matt Honea là CISO tại Hippocratic AI. Trước đây, ông là Trưởng phòng An ninh và Tuân thủ tại Forward Networks. Ông là một nhà lãnh đạo an ninh có kinh nghiệm trong các lĩnh vực tình báo mối đe dọa, mạng máy tính, pháp y hệ thống, kiểm toán an ninh doanh nghiệp, phân tích phần mềm độc hại và an ninh vật lý. Ông cũng là một diễn giả, tác giả và khách mời thường xuyên của các podcast về an ninh. Matt cũng nắm giữ một bằng sáng chế của Hoa Kỳ, nhiều giải thưởng của Chính phủ Hoa Kỳ và được vinh danh là một trong những "40 Under 40" của Silicon Valley Business Journal.