Lỗ hổng Amazon Quick: AWS bảo "không rủi ro" vì khách hàng không dùng tính năng bảo mật đó?

Hầu hết người dùng AWS chấp nhận giao diện người dùng (UI) tồi tệ và bảng giá phức tạp vì họ tin vào mô hình bảo mật vững chắc của gã khổng lồ đám mây này. Tuy nhiên, sự cố gần đây với Amazon Quick (dịch vụ BI trước đây là QuickSight) đã đặt ra câu hỏi lớn về niềm tin đó.

Vào ngày 12/5, Fog Security đã công bố một lỗ hổng bypass quyền ủy quyền trong Amazon Quick. Cụ thể, khi quản trị viên sử dụng "quyền tùy chỉnh" (custom permissions) để từ chối truy cập vào AI Chat Agents, giao diện người dùng sẽ ẩn tính năng này đi. Tuy nhiên, API lại vẫn tiếp tục trả lời các yêu cầu trò chuyện từ bất kỳ người dùng nào trong tài khoản biết cách gửi yêu cầu.

Lỗ hổng và phản ứng của AWS

AWS đã triển khai bản vá chỉ trong vòng 8 ngày sau khi nhận được báo cáo, một tốc độ đáng khen ngợi đối với một quy mô lớn như vậy. Tuy nhiên, điều gây tranh cãi lại nằm ở phản hồi sau đó. AWS phân loại mức độ nghiêm trọng là "không có" (none), không gửi thông báo cho khách hàng và không công bố bất kỳ cảnh báo nào.

Trong tuyên bố của mình, AWS khẳng định: "Vấn đề này đã được giải quyết vào tháng 3 năm 2026. Không có dữ liệu khách hàng nào bị rủi ro và không yêu cầu khách hàng thực hiện hành động nào."

Lập luận "không ai dùng nên không sao"

Amazon Quick được quảng cáo là một trợ lý AI kết nối với Slack, Teams, Outlook, CRM và cơ sở dữ liệu, "mang lại câu trả lời dựa trên dữ liệu kinh doanh thực tế của bạn". Nếu một người dùng không được phép có thể gửi yêu cầu trực tiếp đến tác nhân AI và nhận được câu trả lời dựa trên dữ liệu nội bộ, thì làm sao có thể nói rằng dữ liệu không bị rủi ro?

Sau khi câu chuyện lan truyền, một phát ngôn viên của AWS đã đưa ra bình luận bổ sung gây sốc: "Nhà nghiên cứu đang sử dụng khả năng Kiểm soát Quản trị viên mà không có khách hàng nào đang sử dụng tích cực khi xác thực phía máy chủ không tồn tại."

Tức là, AWS thừa nhận kiểm tra ủy quyền phía máy chủ bị thiếu, nhưng biện hộ rằng không có khách hàng nào thực sự cấu hình quyền truy cập đó trong thời gian lỗi xảy ra.

Một cái khóa không ai khóa?

Đây là một lập luận phòng thủ kỳ lạ: "Cái khóa cửa trước không hoạt động, nhưng may là không ai khóa cửa cả, nên sao bạn phải bực mình?". AWS còn khẳng định chắc nịch rằng họ biết chính xác không khách hàng nào đã cấu hình quyền tùy chỉnh này. Điều này vô tình tiết lộ rằng tính năng quản lý truy cập duy nhất mà dịch vụ cung cấp hoàn toàn bị người dùng bỏ mặc.

Mô hình truy cập của Amazon Quick vốn đã là một ngoại lệ: các chính sách IAM không quản lý AI Chat Agent của Quick, SCP và RCP cũng không áp dụng. "Quyền tùy chỉnh" là nút điều khiển duy nhất mà dịch vụ này cung cấp. Nếu nút điều khiển đó không thực thi, thì không có gì khác bảo vệ dữ liệu cả.

Niềm tin đang bị thử thách

Trong suốt thập kỷ qua, lợi thế cạnh tranh của AWS không phải là giá cả hay trải nghiệm nhà phát triển, mà là niềm tin vào những thứ cơ bản: ranh giới, danh tính và độ bền. Khách hàng chấp nhận trả giá cao của AWS vì họ tin vào những thứ nhàm chán nhưng quan trọng đó.

Tuy nhiên, năm nay niềm tin đó đang bị thử thách. Tần suất các tư vấn bảo mật của AWS trong giai đoạn 2025–2026 đã tăng lên đáng kể. Việc liên tục phát hiện các lỗi kiểm tra quyền ủy quyền bị thiếu trong các dịch vụ AI mới, cộng với cách truyền thông thiếu minh bạch, đang khiến khách hàng đặt câu hỏi về "cái lõi" bảo mật mà họ vẫn tin tưởng.

Việc đánh giá mức độ nghiêm trọng là "không có" đối với một lỗi bypass quyền truy cập không phải là một phát hiện bảo mật khách quan, mà là một quyết định truyền thông. Và quyết định đó hiện tại đang đọc theo hướng: "Chúng tôi sẽ sửa lỗi, chúng tôi sẽ không nói cho bạn biết nó từng tồn tại, và nếu bạn hỏi, chúng tôi sẽ giải thích là bạn cũng chẳng dùng tính năng đó anyway."