Nhà phát triển bị cảnh báo tài khoản Google Cloud bị chiếm quyền nhưng vẫn bị tính phí 11.000 USD
"A developer reported that a compromised Google Cloud service account key led to $11,089.77 in charges over 48 hours, mostly from Gemini image-generation usage, after Google flagged the account as hijacked and suspended it. Although the account was reinstated after the key was revoked, Google Cloud billing reportedly refused to waive the unauthorized charges, highlighting gaps in spending controls and dispute resolution for compromised cloud credentials."
Sự cố cho thấy rủi ro từ service account key compromise có thể dẫn tới chi phí lớn dù đã bị cảnh báo và đình chỉ; điểm then chốt là khả năng truy vết/forensics hạn chế và cơ chế miễn phí không rõ ràng trong quy trình tranh chấp.
Tác động tài chính ngắn hạn có thể đáng kể (khoảng 11.089,77 USD trong 48 giờ) và làm tăng chi phí vận hành do không được waive/credit sau khi đã khắc phục; đồng thời nhấn mạnh khó khăn trong kiểm soát chi phí theo dự án khi khóa bị lạm dụng.
Trong giai đoạn 48 giờ từ 7–8/6, nhà phát triển Charles Jones cho biết tài khoản Google Cloud của ông ghi nhận 11.089,77 USD chi phí, phần lớn đến từ việc sử dụng các mô hình Gemini image-generation. Jones nói không có quy trình tạo ảnh AI và cho rằng nguyên nhân bắt nguồn từ việc khóa dịch vụ firebase-adminsdk service account key bị lộ.
Theo thông báo tạm đình chỉ gửi ngày 7/6, hệ thống của Google cho rằng tài khoản “engaged in abusive activity consistent with hijacked resources”. Jones đã thực hiện các bước khắc phục theo hướng dẫn: vô hiệu hóa service account và revoked khóa. Tài khoản sau đó được khôi phục, nhưng nhóm Google Cloud billing được cho là tiếp tục từ chối miễn/hoàn các khoản phí phát sinh.
Bài viết cũng nêu rằng các khiếu nại tương tự về API key compromise và phí gian lận không phải hiếm. Về mặt kiểm soát chi phí, Google được mô tả là chưa có cơ chế project-wide spending cap phổ quát; Budget Alerts và một số giới hạn theo API có thể không tự chặn việc phát sinh hóa đơn. Khuyến nghị thực tế: áp dụng spending caps (nếu có), cấu hình giới hạn theo dịch vụ, thường xuyên xoay khóa, và chuẩn bị quy trình phản hồi khi xảy ra sự cố để giảm rủi ro tranh chấp thanh toán.