- Tài khoản Google Cloud của SSLMate bị đình chỉ lần thứ ba mà không báo trước, khiến các tính năng tích hợp dịch vụ liên tục bị gián đoạn
- Để tích hợp Cloud DNS và Cloud Domains cho khách hàng, công ty đã dùng mô hình tạo và ủy quyền tài khoản dịch vụ theo tài liệu của Google, nhưng cách làm này liên tục trở thành đối tượng bị đình chỉ
- Lần đình chỉ đầu tiên (2024) gây hỗn loạn lớn do quy trình khôi phục kém hiệu quả và nguyên nhân không rõ ràng; hai lần đình chỉ sau đó cũng chỉ lặp lại email tự động mà không có thông báo trước
- Về phương án thay thế, xác thực dựa trên khóa dài hạn có điểm yếu về bảo mật, còn OIDC (OpenID Connect) thì quy trình thiết lập quá phức tạp
- Kết quả là trong các tích hợp Google Cloud, một giới hạn mang tính cấu trúc lộ ra: chỉ có thể chọn hai trong ba yếu tố bảo mật, tiện lợi và ổn định
Trường hợp tài khoản Google Cloud bị đình chỉ lặp lại
- Tài khoản Google Cloud của SSLMate đã bị đình chỉ không báo trước vào các ngày thứ Sáu trong hai năm liên tiếp 2024 và 2025
- Trước đó cũng đã có một lần đình chỉ tương tự vào năm 2024, và cả ba lần đều không được cung cấp lý do rõ ràng hay cách ngăn tái diễn
- SSLMate sử dụng cơ chế ủy quyền qua tài khoản dịch vụ để tích hợp với tài khoản Google Cloud của khách hàng
- Với mỗi khách hàng, SSLMate tạo một tài khoản dịch vụ trong dự án của SSLMate, rồi khách hàng cấp cho tài khoản đó quyền truy cập Cloud DNS và Cloud Domains
- Khi cần, SSLMate sẽ mạo danh (impersonate) tài khoản dịch vụ đó để truy cập
- Cấu trúc này dựa trên cách làm được tài liệu chính thức của Google khuyến nghị, và là một phương án an toàn, dễ thiết lập, không cần thông tin xác thực dài hạn
Lần đình chỉ đầu tiên (2024)
- Ở lần đình chỉ đầu tiên, toàn bộ chức năng tích hợp với khách hàng đều thất bại và quyền truy cập console bị chặn
- Nhóm hỗ trợ của Google có phản hồi, nhưng quy trình khôi phục kém hiệu quả, ví dụ tài khoản bị vô hiệu hóa khiến email bị trả lại
- SSLMate bị yêu cầu cung cấp project ID nhưng không thể làm được vì không truy cập được console
- Sau khi xác minh số điện thoại, chỉ một phần dự án được khôi phục, rồi hôm sau lại nhận email tự động thông báo hạn chế truy cập
- Sau thêm nhiều email tự động, toàn bộ được khôi phục sau khoảng 19 giờ
- Google không tiết lộ lý do đình chỉ, và cũng không có email thông báo trước
- Sau đó, SSLMate bổ sung chức năng health check theo dõi tỷ lệ lỗi tích hợp để phát hiện sớm
Lần đình chỉ thứ hai (khoảng tháng 10/2025)
- Health check thất bại và phần lớn tích hợp trả về lỗi “Invalid grant: account not found”
- Vẫn có thể đăng nhập console, nhưng với từng dự án chỉ nhận được email kiểu “đã được khôi phục dựa trên thông tin được cung cấp”
- Vẫn không nhận được email thông báo đình chỉ
- Sau đó, chức năng tích hợp hoạt động bình thường trở lại
Lần đình chỉ thứ ba (11/2025)
- Sau khi health check lại thất bại, khi truy cập console thì xuất hiện một kiểu thông báo lỗi mới
- Phần lớn dự án bị đình chỉ, bao gồm cả các dự án dùng để tích hợp với khách hàng
- Đã gửi đơn khiếu nại vào thứ Sáu, nhưng đến Chủ nhật lại nhận được email thông báo đình chỉ toàn bộ tài khoản
- Đến thứ Hai, ngay sau khi bài viết này được đăng lên Hacker News, phần lớn dự án được khôi phục và vài giờ sau toàn bộ quyền truy cập được phục hồi
- Lần này cũng không được cung cấp nguyên nhân hay cách phòng tránh
Trường hợp ngoại lệ của một khách hàng
- Trong suốt mọi đợt đình chỉ, chỉ có tích hợp của một khách hàng vẫn hoạt động bình thường
- Dù vẫn dùng tài khoản dịch vụ trong cùng một dự án, trường hợp này không bị ảnh hưởng
- Không có thêm giải thích nào về nguyên nhân
Vấn đề phụ thuộc vào Google Cloud và các phương án thay thế
- SSLMate kết luận rằng không thể phụ thuộc vào tài khoản Google trong môi trường production
- Hệ thống của Google được thiết kế theo cách mà tài khoản, dự án, hoặc thậm chí toàn bộ GCP có thể bị đình chỉ một cách tùy ý
- Phương án 1: khách hàng tự tạo tài khoản dịch vụ rồi cung cấp thông tin xác thực cho SSLMate bằng khóa dài hạn (long-lived key)
- Thiết lập đơn giản, nhưng bảo mật yếu do rủi ro lộ khóa và không thể xoay vòng hiệu quả
- Phương án 2: dùng OpenID Connect (OIDC)
- Đây là cách tiêu chuẩn được dùng trong tích hợp GitHub Actions hay Azure, cho phép truy cập an toàn mà không cần thông tin xác thực dài hạn
- Nhưng quy trình thiết lập trên Google Cloud lại quá phức tạp với 7 bước
Độ phức tạp của cấu hình OIDC
- Để sử dụng OIDC, cần các bước sau
- Bật IAM Service Account Credentials API
- Tạo tài khoản dịch vụ
- Tạo Workload Identity Pool
- Tạo Workload Identity Provider trong Pool
- Cấp quyền để SSLMate có thể mạo danh tài khoản dịch vụ
- Gán vai trò (Role) cho tài khoản dịch vụ
- Gửi ID của tài khoản dịch vụ và Provider đã tạo cho SSLMate
- Mỗi bước đều cần resource ID từ bước trước, nên khách hàng rất khó làm theo
- Tác giả cho rằng các bước sau là thủ tục không cần thiết
- Cần có khả năng gán vai trò trực tiếp mà không cần tạo tài khoản dịch vụ
- Trong đa số trường hợp, Pool chỉ chứa một Provider nên việc tạo Pool tự thân đã là công việc lặp thừa
- Cần có khả năng gán vai trò trực tiếp cho URL issuer OIDC và subject mà không cần tạo Provider
Vấn đề cấu trúc và kết luận
- Hiện tại, với tích hợp Google Cloud, chỉ có thể chọn hai trong ba yếu tố sau
- Không cần thông tin xác thực dài hạn
- Khách hàng dễ thiết lập
- An toàn trước việc bị đình chỉ tùy ý
- Cách làm dựa trên tài khoản dịch vụ của SSLMate đảm bảo bảo mật và tính tiện lợi, nhưng vẫn có rủi ro bị đình chỉ
- Cách dùng tài khoản dịch vụ + khóa thì dễ thiết lập và ít rủi ro bị đình chỉ hơn, nhưng bảo mật yếu
- Cách dùng OIDC có độ an toàn và khả năng tránh đình chỉ cao, nhưng thiết lập phức tạp
- Kết luận là nếu Google không đơn giản hóa OIDC thành một phương thức tích hợp hạng nhất, thì sẽ rất khó có được một tích hợp vừa an toàn vừa ổn định
Tóm tắt bình luận của độc giả
- Một độc giả nhận xét: “Hãy dùng nhà cung cấp đám mây khác, GCP là tệ nhất”
- Tác giả đáp rằng: “Khách hàng dùng GCP nên vẫn cần hỗ trợ tích hợp”
- Một độc giả khác chỉ ra rằng bảo mật và độ tin cậy xung đột với sự đơn giản, và những khách hàng ưu tiên sự đơn giản có thể không phù hợp
2 bình luận
"Việc xác minh nhà phát triển Android rồi cũng sẽ thành ra như thế này. Rất nhiều người sẽ bị cấm phát triển cho Android."
Đây là ý kiến trên Hacker News khiến tôi nhớ nhất. Tôi nghĩ ngày đó sẽ không còn xa.
Ý kiến Hacker News
Mọi người nghĩ Google là một đối tác đáng tin cậy, nhưng trên thực tế đây là một hệ thống được thiết kế như một cỗ máy bán lẻ quy mô lớn
Phục vụ hàng triệu người, và chỉ một biện pháp bảo vệ tự động sai lệch cũng có thể phá hỏng cuộc sống của hàng nghìn người
Việc thiếu hỗ trợ khách hàng hay những câu trả lời vô nghĩa được tự động hóa không chỉ là cắt giảm chi phí mà còn có vẻ là một chiến lược giảm thiểu trách nhiệm pháp lý
Hầu hết mọi người đều biết rằng tài khoản Google có thể bị đình chỉ bất cứ lúc nào mà không cần lý do
Thực tế, ai cũng quen một hai người từng mất quyền truy cập tài khoản
Trừ khi là hợp đồng trị giá hàng triệu đô, tôi nghĩ rất ít người xem Google là một đối tác thực sự
Mọi nền tảng đều ưu tiên mở rộng quy mô
Không thể vừa duy trì quan hệ mang tính con người với từng người dùng, vừa giữ mức lợi nhuận kiểu buôn ma túy
Dù có một người vô tội bị vạ lây thì cũng bị xem là “chi phí cần thiết”
Hôm qua là Wise, trước đó là tài khoản GitHub bị chặn theo kiểu này
Doanh nghiệp không vận hành như nền dân chủ mà giống một lãnh địa phong kiến hơn
Nếu hệ thống tự động kết luận bạn là tội phạm, bạn sẽ bị trừng phạt ngay mà không qua xét xử
Có thể nói chuyện với người thật, chứ không phải chatbot đơn thuần
Hiện tôi đang dùng Tuta Mail, và tôi thích mã hóa kháng lượng tử cùng môi trường không quảng cáo của nó
Tôi cũng có thể tạo bao nhiêu địa chỉ bí danh tùy thích bằng tên miền của mình
Vài năm trước, tài khoản YouTube Premium của tôi bị chặn vì lý do spam
Dù tôi chỉ xem video, tài khoản vẫn bị xóa và cả trang thanh toán cũng bị khóa truy cập
Trong lúc phải đi qua quy trình kháng cáo máy móc chỉ được làm một lần mỗi 3 tuần, tôi vẫn tiếp tục bị trừ tiền
Hỗ trợ trả phí của Google One cũng vô dụng vì nói rằng “đó là đội khác nên không thể giúp”
Cuối cùng tôi phải hủy thẻ để xử lý, rồi vài tháng sau mới nhận được tin nhắn bảo rằng “đó là nhầm lẫn”
Trớ trêu là WeChat lại cho tôi gọi được cho người thật và giải quyết chỉ trong một ngày — khiến tôi có cảm giác chăm sóc khách hàng ở nhà nước kiểm duyệt còn tốt hơn
Vấn đề không chỉ nằm ở Google mà ở toàn bộ cấu trúc đại doanh nghiệp phụ thuộc thuật toán
Ngay cả trên Reddit, tài khoản 20 năm tuổi của tôi cũng bị shadowban mà không rõ lý do
Kháng cáo bị phớt lờ, bài viết và bình luận đều bị lọc hết
Fediverse cho thấy một mô hình thay thế tốt hơn — cốt lõi là cộng đồng nhỏ và tỷ lệ moderator cao
Cấu trúc mà chỉ với một thẻ #fediblock là có thể bị chặn tự động trên hàng trăm máy chủ lại tiếp tục tạo ra kiểu kiểm duyệt vô trách nhiệm
Thực tế, instance Mastodon của thành phố chúng tôi đã sụp đổ như vậy, và mọi người chuyển sang Bluesky
Việc bố trí khoảng 100 người để xử lý những trường hợp biên kiểu này đâu có khó
Nhưng họ không làm vì như vậy sẽ làm giảm biên lợi nhuận
Không phải vì họ thiếu tiền, mà vì họ chọn không chi
Tôi nghĩ sau này Gemini API cũng sẽ gặp những vấn đề kiểu này
Nếu khách hàng tạo ra hình ảnh vi phạm quy định, thì ngay lập tức cả Gmail doanh nghiệp lẫn Gmail cá nhân dùng để khôi phục cũng có thể bị đình chỉ vĩnh viễn
Việc xác minh nhà phát triển Android có lẽ cũng sẽ đi theo hướng này
Khả năng cao là rất nhiều nhà phát triển sẽ bị đình chỉ tư cách nhà phát triển mà không rõ lý do
Trước đây tôi từng thấy trường hợp tài khoản cá nhân của nhân viên trong một công ty nhỏ bị chặn cùng với lý do “có liên quan đến tài khoản nhà phát triển từng bị đình chỉ trước đó”
Tôi nghĩ rất khó duy trì chuyên môn khi bị phụ thuộc vào nền tảng như vậy
Dịch vụ của chúng tôi cũng chỉ dùng mỗi nút “Login with Google”, vậy mà tài khoản vẫn đột nhiên bị chặn
Lý do duy nhất chỉ là cụm từ mơ hồ “vi phạm điều khoản”
Trong lúc gửi kháng cáo và vội vàng chuẩn bị phương án đăng nhập thay thế cho người dùng, thì hôm sau đột nhiên lại nhận được email “kháng cáo được chấp nhận”
Kết quả là tuy được khôi phục, nhưng cảm giác mất niềm tin vẫn còn đó
Tài khoản AdSense của tôi đã bị đình chỉ ba lần chỉ vì đặt một dấu chấm than trong quảng cáo
Cuối cùng tôi đóng tài khoản, nhưng có lẽ đến giờ nó vẫn đang bị theo dõi như một “tài khoản có nguy cơ gian lận”
Nếu cấu trúc là để người dùng mới bị đình chỉ chỉ sau một giờ, thì thật khó hiểu vì sao quy trình đăng ký ban đầu lại được làm dễ đến vậy
Trong tình huống này, tôi băn khoăn không biết có nên kiện Google hoặc yêu cầu siết chặt quản lý hay không
Tôi nghe nói nhiều trường hợp Google không ra hầu tòa, hoặc viện cớ bằng TOS rồi lại phản tác dụng trước thẩm phán
Tôi tò mò không biết các tài khoản đăng nhập chỉ dùng Passkey được đăng ký bằng một email đã bị đình chỉ sẽ ra sao
Liệu Passkey đã đồng bộ vào Google Password Manager có còn hoạt động sau khi tài khoản bị đình chỉ hay không,
hay vì mất quyền truy cập email nên không thể khôi phục nữa — có lẽ rất ít người từng thử kiểm tra chuyện này