Sự cố gateway AI tự lưu trữ phơi bày lỗ hổng trong xử lý thông tin đăng nhập

Một gateway tương thích OpenAI tự lưu trữ đã gặp sự cố gián đoạn dịch vụ đột ngột khi nhà cung cấp upstream vô hiệu hóa đồng thời sáu vị trí làm việc (seat) độc lập. Sự cố này, được chi tiết hóa trong một bài đăng vào ngày 6 tháng 11 năm 2026, nhấn mạnh những rủi ro của việc gộp các thông tin đăng nhập thuê bao phía sau một điểm thoát (egress point) duy nhất. Tác giả đã giải quyết vấn đề bằng cách tách biệt lưu lượng API-key khỏi các tác vụ dựa trên thuê bao và cải thiện khả năng phân biệt lỗi.

Chuyện gì đã xảy ra

Gateway phục vụ nhiều cấp độ mô hình, bao gồm đọc ngữ cảnh dài và tái cấu trúc mã, sử dụng một bảng điều khiển thống nhất để theo dõi chi phí. Sáu quy trình làm việc riêng biệt, chẳng hạn như lập chỉ mục kho chứa và phân loại CI, xác thực qua các thông tin đăng nhập OAuth thuê bao cá nhân. Trong một cửa sổ phát hiện ngắn, cả sáu vị trí đều bị nhà cung cấp upstream vô hiệu hóa. Nguyên nhân không phải là hoạt động bất thường từ bất kỳ vị trí nào, mà là một cuộc kiểm tra thông tin đăng nhập định kỳ phát hiện vi phạm chính sách.

Trong mười phút đầu tiên của sự cố, mọi thành phần tương tác với gateway đều báo cáo lỗi 401 invalid_api_key. Phản hồi gây hiểu lầm này khiến người vận hành tập trung vào việc xoay vòng các thông tin đăng nhập vốn về mặt kỹ thuật vẫn hợp lệ. Nhà cung cấp upstream thực tế đã trả về một quyết định chính sách, có thể là 403 Forbidden, nhưng logic xử lý lỗi của gateway lại ánh xạ điều này thành một lỗi xác thực chung chung. Việc nhầm lẫn giữa các khối chính sách và lỗi thông tin đăng nhập đã lãng phí thời gian khắc phục sự cố quý giá.

Nguyên nhân gốc rễ nằm ở kiến trúc của gateway. Tất cả sáu vị trí làm việc đều thoát ra qua một container duy nhất với một địa chỉ IP công cộng. Gateway chuẩn hóa các tiêu đề (headers) và xóa dữ liệu đo từ xa (telemetry) của máy khách, khiến sáu quy trình làm việc riêng biệt xuất hiện như một máy khách duy nhất hoạt động với khối lượng gấp sáu lần bình thường. Mô hình này khớp với định nghĩa của nhà cung cấp về việc gộp vị trí hoặc xoay vòng tự động, vi phạm các điều khoản dịch vụ của họ. Hệ thống phát hiện của nhà cung cấp đánh dấu cụm này là một quy tắc xác định đơn lẻ đang kích hoạt thay vì sáu lượt xem xét độc lập bởi con người.

Chi tiết quan trọng

• Nhà cung cấp upstream đã vô hiệu hóa đồng thời sáu vị trí thuê bao do vi phạm chính sách được phát hiện trong một cuộc kiểm tra định kỳ.
• Gateway trả về sai 401 invalid_api_key cho các khối chính sách 403 từ upstream, làm chậm trễ chẩn đoán đúng.
• Tất cả các quy trình làm việc chia sẻ một IP thoát duy nhất và tiêu đề được chuẩn hóa, khiến chúng trông giống như một máy khách có khối lượng cao.
• Điều khoản của nhà cung cấp cấm việc gộp vị trí hoặc tự động hóa xoay vòng trên các công cụ CLI dựa trên thuê bao.
• Giải pháp liên quan đến việc chuyển các công việc thuê bao sang một bộ phân phối tác vụ gọi trực tiếp CLI chính thức, giữ token bên trong binary của nhà cung cấp.
• Các nhiệm vụ điều phối thường xuyên hiện chạy trên các mô hình mở (open-weight models) thông qua API keys, trong khi các nhiệm vụ kỹ thuật nặng sử dụng các vị trí CLI được ủy quyền.

Bối cảnh

Để hiểu sự cố này, cần phân biệt giữa thông tin đăng nhập bearer và token ràng buộc. Một API key là thông tin đăng nhập bearer, nghĩa là bất kỳ ai sở hữu nó đều có thể sử dụng. Ngược lại, một token OAuth được ràng buộc với một danh tính máy khách cụ thể, bao gồm ID máy khách, hồ sơ đồng ý và phạm vi (scopes). Khi một gateway trình bày token OAuth thay mặt cho một quy trình khác, yêu cầu vẫn giữ nguyên các tuyên bố (claims) ban đầu nhưng mất đi bối cảnh hành vi, chẳng hạn như dấu vết TLS và nhịp độ yêu cầu. Các nhà cung cấp sử dụng các tín hiệu hành vi này để phát hiện tự động hóa hoặc chia sẻ vi phạm điều khoản của họ.

Việc xử lý lỗi trong các hệ thống phân tán thường che giấu bản chất thực sự của các thất bại. Mã trạng thái 401 Unauthorized thường chỉ ra thông tin đăng nhập không hợp lệ, trong khi 403 Forbidden chỉ ra rằng máy chủ đã hiểu yêu cầu nhưng từ chối ủy quyền. Ánh xạ cả hai thành cùng một lỗi phía máy khách sẽ loại bỏ thông tin chẩn đoán quan trọng. Trong trường hợp này, lớp dịch của gateway đã che giấu sự thật rằng tài khoản bị chặn vì lý do chính sách, dẫn đến việc người vận hành theo đuổi các biện pháp sửa chữa không liên quan như xoay vòng khóa.

Tại sao điều này quan trọng

Đối với các đội ngũ vận hành cơ sở hạ tầng AI tự lưu trữ, câu chuyện này nhấn mạnh tầm quan trọng của các hợp đồng lỗi chính xác. Khi một gateway trừu tượng hóa nhiều nhà cung cấp hoặc phương pháp xác thực, nó phải bảo toàn ý nghĩa ngữ nghĩa của các lỗi từ upstream. Việc gộp các chế độ thất bại riêng biệt thành một lỗi chung duy nhất buộc các kỹ sư lãng phí thời gian vào các manh mối sai. Triển khai các lớp lỗi riêng biệt cho khối chính sách so với lỗi xác thực cho phép phản ứng sự cố nhanh hơn và cảnh báo chính xác hơn.

Kiến trúc quản lý thông tin đăng nhập cũng có những hàm ý tuân thủ và vận hành đáng kể. Gộp các vị trí thuê bao phía sau một proxy duy nhất có vẻ hiệu quả cho việc theo dõi chi phí, nhưng nó tạo ra một điểm thất bại đơn lẻ và vi phạm hầu hết các điều khoản dịch vụ của nhà cung cấp. Bằng cách coi các thuê bao là các vị trí (seats) chứ không phải API, các đội ngũ có thể tránh các bộ kích hoạt phát hiện dựa trên phân tích hành vi. Cách tiếp cận này đảm bảo rằng mỗi quy trình làm việc duy trì danh tính riêng và tuân thủ các chính sách sử dụng của nhà cung cấp.

Hơn nữa, việc chuyển sang phân phối tác vụ cho các công cụ dựa trên thuê bao cung cấp khả năng cô lập bảo mật tốt hơn. Chạy CLI chính thức trong một môi trường được kiểm soát ngăn ngừa rò rỉ token và đảm bảo rằng các lời nhắc tương tác không gây ra treo ngầm. Phương pháp này tôn trọng mô hình sử dụng dự kiến của nhà cung cấp trong khi vẫn cho phép tự động hóa. Nó cũng tách biệt các tác vụ tần suất cao, chi phí thấp khỏi các khối lượng công việc kỹ thuật nặng, tối ưu hóa cả chi phí và độ tin cậy.

Bạn có thể làm gì

• Kiểm toán xử lý lỗi của gateway để đảm bảo các phản hồi 403 từ upstream không bị ánh xạ thành lỗi 401.
• Tách biệt lưu lượng API-key khỏi việc sử dụng CLI dựa trên thuê bao để tránh vi phạm gộp.
• Sử dụng bộ phân phối tác vụ để gọi trực tiếp các CLI chính thức của nhà cung cấp, giữ token bên trong binary của nhà cung cấp.
• Cấu hình bộ phân phối với thư mục làm việc rõ ràng, stdin đóng và giết nhóm tiến trình khi quá thời gian chờ.
• Vô hiệu hóa thử lại tự động cho các vòng lặp agent nội bộ để ngăn chặn việc kích hoạt các hệ thống phát hiện giới hạn tốc độ hoặc lạm dụng.
• Giám sát các mẫu lưu lượng thoát để đảm bảo các quy trình làm việc riêng biệt không xuất hiện như một máy khách duy nhất có khối lượng cao.