Lỗ hổng bảo mật nghiêm trọng trong Azure OpenAI: Agent trả lời theo quyền của indexer, không phải người dùng

Một agent trợ lý email xây dựng trên Azure OpenAI vừa phơi bày một lỗ hổng bảo mật đáng lo ngại trong các hệ thống RAG (Retrieval-Augmented Generation) triển khai tùy chỉnh: nó trả về nội dung SharePoint mà người dùng quyền thấp không thể truy cập trực tiếp, dù đã vượt qua mọi bài kiểm tra đánh giá chất lượng. Sự cố này đặt ra câu hỏi lớn về ranh giới phân quyền trong các ứng dụng AI agent đang vận hành thực tế.

Agent vượt qua mọi bài đánh giá nhưng thất bại ở bài kiểm tra quan trọng nhất

Egiziago Cioffi, IT và Enterprise Architect kiêm CEO của SynSphere Italia, một đối tác Microsoft tại Milan, đã tự tay xây dựng một agent trả lời email tự động bằng Azure OpenAI. Anh viết job đánh chỉ mục, cấu hình pipeline truy xuất, kết nối với SharePoint, và mọi bài đánh giá nội bộ đều đạt điểm sạch. Agent tự động xử lý khoảng 60% email khách hàng đến.

Nhưng khi Cioffi chạy thử nghiệm với tài khoản quyền thấp (low-privilege) trên cùng câu hỏi mà tài khoản quyền cao đã hỏi, kết quả không khớp. Agent trả về nội dung SharePoint mà tài khoản quyền thấp không thể mở trực tiếp trên SharePoint. Nhật ký hệ thống kể một câu chuyện hoàn toàn khác so với điểm số đánh giá.

Nguyên nhân: Pipeline RAG tùy chỉnh bỏ qua kiểm soát ACL gốc

Azure AI Search đã cung cấp tính năng cắt giảm ACL (Access Control List) ở cấp tài liệu dựa trên token Entra từ bản xem trước tháng 5/2025, và đồng bộ ACL SharePoint sau đó. Tuy nhiên, khả năng này không phải lúc nào cũng được áp dụng đúng nơi cần thiết.

Vấn đề nằm ở các pipeline tùy chỉnh. Theo tài liệu của Microsoft, nếu trường permitted-groups không được ánh xạ, quyền truy cập cấp tài liệu sẽ bị tắt — một mặc định fail-open nguy hiểm. Các pipeline RAG tùy chỉnh bỏ qua Azure AI Search hoàn toàn thường lập chỉ mục dưới một tài khoản dịch vụ có quyền rộng, mà không có bất kỳ kiểm tra quyền nào tại thời điểm truy vấn, trừ khi nhà phát triển tự xây dựng.

"Nếu thông tin xác thực NHI (Non-Human Identity) thường có quyền ủy quyền rộng và có thể đọc dữ liệu đặc quyền cao, thì dữ liệu đó được lưu trong index. Nếu ứng dụng không thực thi truy xuất nhận biết danh tính, người dùng 'bình thường' với quyền thấp hơn có thể truy vấn ứng dụng và truy cập dữ liệu bị hạn chế. Điều này sụp đổ ranh giới ủy quyền xuống mức quyền thấp nhất có khả năng tìm kiếm." — Adriel Desautels, CEO Netragard.

Dữ liệu độc lập: 91% cuộc tấn công thành công kết thúc bằng đánh cắp dữ liệu thầm lặng

Nghiên cứu từ Straiker's red team, công bố trong báo cáo STAR Labs Threat Report tháng 7, cho thấy qua hơn 1.700 lần khai thác thành công trên agent sản xuất, 91% cuộc tấn công vào agent năng suất kết thúc bằng việc đánh cắp dữ liệu mà không bị phát hiện — không cần malware, không di chuyển ngang mạng. Agent chỉ đơn giản trả về toàn bộ dữ liệu nó có thể với tới.

Viện An ninh AI Anh Quốc (UKASI) cũng độc lập ghi nhận 19 hành động agent ngoài kiểm soát trong một cuộc đánh giá an ninh mạng. Mặc dù không cùng cơ chế, điểm chung là thiếu kiểm tra phạm vi runtime — agent hoạt động ngoài ý định của người triển khai mà không có cơ chế phát hiện kịp thời.

Vì sao các bài đánh giá không phát hiện ra lỗ hổng?

Các bài đánh giá của nhóm Cioffi chỉ kiểm tra tính chính xác, mức độ liên quan và hoàn thành nhiệm vụ. Chúng không bao giờ hỏi: pipeline truy xuất đang dùng quyền của ai khi lấy dữ liệu?

"Agent có xu hướng chạy một danh tính phi nhân (non-human identity) duy nhất, tồn tại lâu dài, với một loạt quyền rộng mà nó có thể cần cho bất kỳ nhiệm vụ nào. Các bài đánh giá cũng thường không bao gồm prompt, output, transcript, bộ nhớ và nhật ký — nơi dữ liệu có thể bị đọc hoặc chiếm quyền qua nội dung tiêm nhiễm." — Adriel Desautels.

Giải pháp đơn giản: Một bộ lọc tại thời điểm truy vấn

Giải pháp của Cioffi không cần một nền tảng danh tính mới. Anh chuyển quyết định phân quyền vào ngay đường truy xuất: thêm một bộ lọc tại query-path kiểm tra quyền SharePoint của người dùng yêu cầu trước khi model nhìn thấy bất kỳ chunk dữ liệu nào. Bộ lọc chạy tại thời điểm truy vấn, không phải lúc index.

Kết quả: Agent vẫn tự động xử lý khoảng 60% email đến — tương đương trước khi thêm bộ lọc. Cái giá phải trả là một số nội dung trước đây agent dùng để trả lời giờ bị loại trừ, vì quyền của người dùng không với tới. Đó là cái giá của việc thực thi ranh giới bảo mật.

Nền tảng quản trị danh tính: Cần thiết nhưng không đủ

CrowdStrike hoàn tất thâu tóm SGNL trị giá 740 triệu USD vào tháng 2/2026, và Palo Alto Networks hoàn tất thương vụ CyberArk 25 tỷ USD cùng tháng — minh chứng cho vai trò trung tâm của bảo mật danh tính. Nhưng các nền tảng này quản lý vòng đời thông tin xác thực, không quản lý ranh giới phân quyền truy xuất — thời điểm tài khoản dịch vụ được cấp quyền đúng truy xuất nội dung thay mặt người dùng có quyền thấp hơn.

Cả hai lớp kiểm soát đều cần thiết. Bộ lọc của Cioffi và ACL trimming gốc của Azure AI Search giải quyết cùng một lớp, nhưng không thay thế quản trị danh tính. Một hệ thống sản xuất muốn đóng cả hai lỗ hổng — vòng đời thông tin xác thực và phân quyền truy xuất — phải có kiểm soát ở cả hai lớp.

Bài kiểm tra 30 phút mà mọi đội an ninh có thể chạy

Chỉ cần một câu hỏi: Hệ thống truy xuất AI của bạn đang dùng quyền của ai khi lấy nội dung?

Cách kiểm tra đơn giản:

• Chạy cùng một câu hỏi mà tài khoản quyền cao đã hỏi, nhưng dùng tài khoản quyền thấp.
• So sánh kết quả với những gì tài khoản quyền thấp có thể truy cập trực tiếp qua hệ thống gốc (như SharePoint).
• Nếu agent trả về nhiều hơn quyền truy cập trực tiếp cho phép — ranh giới phân quyền chưa được thực thi.

"Bài kiểm tra đầu tiên sẽ nhắm vào khoảng trống giữa dữ liệu và chỉ dẫn, và khoảng trống giữa danh tính người dùng và thông tin xác thực của assistant. Chúng tôi sẽ cố gieo một chỉ dẫn trong nội dung mà chúng tôi nghĩ assistant sẽ tiếp nhận như dữ liệu, để hướng dẫn nó thực hiện hành động đặc quyền mà người dùng tấn công không được phép." — Adriel Desautels.

Bài kiểm tra này chỉ tốn hai tài khoản và 30 phút — nhưng tạo ra kết quả mà không điểm số đánh giá nào có thể thay thế.

Câu chuyện của Cioffi là lời cảnh tỉnh: Đánh giá chất lượng câu trả lời không đồng nghĩa với đánh giá bảo mật phân quyền. Trước khi triển khai agent tiếp theo, hãy chạy bài so sánh hai tài khoản. 30 phút sẽ cho bạn biết mình đang đứng ở phía nào của ranh giới an toàn.