- Akun Google Cloud milik SSLMate ditangguhkan untuk ketiga kalinya tanpa pemberitahuan, sehingga fitur integrasi layanannya berulang kali terhenti
- Untuk integrasi Cloud DNS dan Cloud Domains pelanggan, mereka menggunakan struktur pembuatan dan pendelegasian service account sesuai dokumentasi Google, tetapi pendekatan ini terus menjadi sasaran penangguhan
- Penangguhan pertama (2024) menimbulkan kekacauan besar karena proses pemulihan yang tidak efisien dan penyebab yang tidak jelas, dan pada dua penangguhan berikutnya pun hanya email otomatis yang berulang tanpa pemberitahuan sebelumnya
- Sebagai alternatif, autentikasi berbasis long-lived key lemah dari sisi keamanan, sementara OIDC (OpenID Connect) memiliki prosedur konfigurasi yang terlalu rumit
- Pada akhirnya, integrasi Google Cloud menunjukkan batasan struktural di mana hanya dua dari tiga hal ini yang bisa dipilih: keamanan, kemudahan, dan stabilitas
Kasus penangguhan akun Google Cloud yang berulang
- Akun Google Cloud SSLMate ditangguhkan tanpa pemberitahuan sebelumnya pada hari Jumat di dua kesempatan berturut-turut pada 2024 dan 2025
- Penangguhan yang sama juga pernah terjadi pada 2024, dan pada ketiga kejadian itu tidak ada alasan yang jelas maupun cara mencegah terulangnya kejadian
- Untuk berintegrasi dengan akun Google Cloud pelanggan, SSLMate menggunakan metode delegasi service account
- Untuk setiap pelanggan, mereka membuat service account di bawah proyek SSLMate, lalu pelanggan memberikan hak akses Cloud DNS dan Cloud Domains kepada akun tersebut
- SSLMate lalu dapat menyamar secara virtual (impersonate) sebagai service account tersebut saat diperlukan untuk mengaksesnya
- Struktur ini didasarkan pada praktik yang direkomendasikan dokumentasi resmi Google, dan merupakan cara yang aman serta mudah dikonfigurasi tanpa kredensial jangka panjang
Penangguhan pertama (2024)
- Saat penangguhan pertama, semua fungsi integrasi pelanggan gagal dan akses ke konsol diblokir
- Tim dukungan Google memang merespons, tetapi proses pemulihannya tidak efisien, misalnya email dipantulkan karena akun dinonaktifkan
- Mereka diminta memberikan project ID, tetapi tidak bisa karena akses ke konsol tidak tersedia
- Setelah verifikasi nomor telepon, hanya sebagian proyek yang dipulihkan, lalu keesokan harinya mereka kembali menerima email otomatis tentang pembatasan akses
- Setelah beberapa email otomatis berikutnya, pemulihan penuh baru selesai sekitar 19 jam kemudian
- Google tidak mengungkap alasan penangguhan, dan tidak ada email pemberitahuan sebelumnya
- Setelah itu, SSLMate menambahkan fitur health check untuk memantau tingkat kesalahan integrasi agar bisa mendeteksi lebih dini
Penangguhan kedua (sekitar Oktober 2025)
- Saat health check gagal, sebagian besar integrasi mengembalikan error “Invalid grant: account not found”
- Login ke konsol masih memungkinkan, tetapi untuk tiap proyek mereka hanya menerima email yang menyebut “dipulihkan berdasarkan informasi yang diberikan”
- Email pemberitahuan penangguhan tetap tidak pernah diterima
- Setelah itu, fungsi integrasi kembali normal
Penangguhan ketiga (November 2025)
- Setelah health check kembali gagal, saat mengakses konsol muncul jenis pesan error yang baru
- Sebagian besar proyek ditangguhkan, termasuk proyek untuk integrasi pelanggan
- Mereka mengajukan banding pada hari Jumat, tetapi pada hari Minggu malah menerima email pemberitahuan penangguhan seluruh akun
- Pada hari Senin, segera setelah tulisan tersebut muncul di Hacker News, sebagian besar proyek dipulihkan, dan beberapa jam kemudian seluruh akses kembali pulih
- Kali ini pun tidak diberikan penyebab penangguhan maupun cara pencegahannya
Kasus pelanggan yang menjadi pengecualian
- Selama semua periode penangguhan, integrasi milik satu pelanggan tetap berfungsi normal
- Meski menggunakan service account dalam proyek yang sama, pelanggan tersebut tidak terdampak
- Tidak ada penjelasan tambahan mengenai penyebabnya
Masalah ketergantungan pada Google Cloud dan alternatifnya
- SSLMate menilai bahwa mereka tidak bisa bergantung pada akun Google dalam lingkungan produksi
- Sistem Google memungkinkan akun, proyek, atau bahkan seluruh GCP ditangguhkan secara sewenang-wenang
- Alternatif 1: pelanggan membuat service account sendiri lalu memberikan autentikasi ke SSLMate menggunakan long-lived key
- Konfigurasinya sederhana, tetapi keamanannya lemah karena risiko kebocoran kunci dan tidak bisa dirotasi
- Alternatif 2: menggunakan OpenID Connect (OIDC)
- Ini adalah cara standar yang dipakai di integrasi GitHub Actions maupun Azure, dan memungkinkan akses yang aman tanpa kredensial jangka panjang
- Namun, konfigurasi di Google Cloud terlalu rumit dengan proses 7 langkah
Kerumitan konfigurasi OIDC
- Untuk menggunakan OIDC, langkah-langkah berikut diperlukan
- Mengaktifkan IAM Service Account Credentials API
- Membuat service account
- Membuat Workload Identity Pool
- Membuat Workload Identity Provider di dalam Pool
- Memberikan izin agar SSLMate dapat menyamar sebagai service account
- Memberikan role kepada service account
- Mengirimkan service account dan Provider ID yang telah dibuat ke SSLMate
- Setiap langkah memerlukan resource ID dari langkah sebelumnya, sehingga sulit diikuti oleh pelanggan
- Penulis menilai langkah-langkah berikut sebagai prosedur yang tidak perlu
- Seharusnya role bisa diberikan langsung tanpa harus membuat service account
- Dalam kebanyakan kasus, Pool hanya berisi satu Provider, sehingga pembuatan Pool sendiri menjadi duplikasi yang tidak perlu
- Tanpa membuat Provider pun, seharusnya role bisa diberikan langsung ke URL issuer OIDC dan subject
Masalah struktural dan kesimpulan
- Integrasi Google Cloud saat ini pada dasarnya hanya memungkinkan memilih dua dari tiga hal berikut
- Tanpa kredensial jangka panjang
- Mudah dikonfigurasi pelanggan
- Aman dari penangguhan sewenang-wenang
- Pendekatan berbasis service account milik SSLMate memberikan keamanan dan kemudahan, tetapi tetap berisiko ditangguhkan
- Pendekatan service account + key mudah dikonfigurasi dan kecil kemungkinan ditangguhkan, tetapi keamanannya lemah
- Pendekatan OIDC unggul dari sisi keamanan dan ketahanan terhadap penangguhan, tetapi rumit dikonfigurasi
- Kesimpulannya, selama Google tidak menyederhanakan OIDC sebagai metode integrasi kelas satu, integrasi yang aman dan stabil akan sulit diwujudkan
Ringkasan komentar pembaca
- Seorang pembaca berkomentar, “Gunakan penyedia cloud lain, GCP itu yang terburuk”
- Penulis menjawab bahwa “mereka perlu itu untuk integrasi karena pelanggan menggunakan GCP”
- Pembaca lain mengatakan, “Keamanan dan keandalan bertentangan dengan kesederhanaan,” dan menilai pelanggan yang mengutamakan kesederhanaan mungkin memang tidak cocok
2 komentar
"Android developer verification akan berakhir seperti ini juga. Banyak orang akan diblokir untuk mengembangkan aplikasi Android."
Ini mungkin pendapat di Hacker News yang paling membekas bagi saya. Saya rasa waktunya tidak lama lagi.
Opini Hacker News
Orang-orang menganggap Google sebagai mitra yang dapat dipercaya, tetapi kenyataannya sistemnya dirancang seperti pabrik ritel berskala besar
Menangani jutaan orang, dan satu langkah perlindungan otomatis yang salah bisa menghancurkan hidup ribuan orang
Ketiadaan dukungan pelanggan atau jawaban otomatis yang tidak bermakna tampaknya bukan sekadar penghematan biaya, melainkan strategi meminimalkan tanggung jawab hukum
Kebanyakan orang tahu bahwa akun Google bisa ditangguhkan kapan saja tanpa alasan
Nyatanya hampir semua orang kenal satu dua orang di sekitarnya yang kehilangan akses ke akunnya
Kecuali kontraknya bernilai jutaan dolar, saya rasa hampir tidak ada yang benar-benar melihat Google sebagai mitra sejati
Semua platform memprioritaskan skalabilitas
Mustahil mempertahankan hubungan manusiawi dengan tiap pengguna sambil tetap menjaga profitabilitas setingkat bandar narkoba
Meski satu orang baik ikut tersaring secara keliru, itu tetap dianggap sebagai ‘biaya yang perlu’
Kemarin Wise, sebelumnya akun GitHub juga diblokir dengan cara seperti ini
Perusahaan beroperasi bukan seperti demokrasi, melainkan seperti wilayah feodal
Jika sistem otomatis memutuskan Anda seorang kriminal, hukuman langsung dijatuhkan tanpa pengadilan
Kita masih bisa berbicara dengan manusia sungguhan, bukan sekadar chatbot
Saat ini saya memakai Tuta Mail, dan saya suka enkripsi tahan-kuantum serta lingkungan tanpa iklan
Saya juga bisa membuat sebanyak mungkin alamat alias dengan domain saya sendiri
Beberapa tahun lalu akun YouTube Premium saya diblokir karena alasan spam
Padahal saya cuma menonton video, tetapi akun saya dihapus dan akses ke halaman pembayaran juga ditutup
Selama menjalani proses banding ala robot yang hanya bisa dilakukan sekali tiap 3 minggu, tagihan tetap berjalan
Dukungan berbayar Google One pun tidak berguna karena mereka bilang “itu tim lain jadi kami tidak bisa membantu”
Pada akhirnya saya menyelesaikannya dengan memblokir kartu, lalu beberapa bulan kemudian saya menerima pesan bahwa “itu sebuah kesalahan”
Ironisnya, WeChat menyelesaikannya dalam sehari lewat panggilan dengan manusia — sampai saya merasa dukungan pelanggan negara sensor lebih baik
Masalahnya bukan hanya Google, tetapi juga struktur perusahaan besar yang bergantung pada algoritma secara umum
Di Reddit pun akun saya yang sudah berumur 20 tahun kena shadowban tanpa alasan
Banding diabaikan, dan semua posting serta komentar saya difilter
Fediverse menunjukkan model alternatif yang lebih baik — kuncinya adalah komunitas kecil dan rasio moderator yang tinggi
Struktur yang memungkinkan satu tagar #fediblock memicu pemblokiran otomatis di ratusan server justru mengulang sensor tanpa akuntabilitas
Nyatanya instance Mastodon kota kami hancur karena itu, dan semua orang pindah ke Bluesky
Tidak sulit bagi mereka untuk menempatkan sekitar 100 orang guna menangani kasus tepi seperti ini
Namun mereka tidak melakukannya karena itu akan mengurangi margin
Bukan karena tidak punya uang, melainkan karena mereka memilih untuk tidak menggunakannya
Ke depan sepertinya masalah seperti ini juga akan muncul di Gemini API
Jika pelanggan menghasilkan gambar yang melanggar aturan, bisa saja Gmail bisnis atau bahkan Gmail pribadi untuk pemulihan langsung ditangguhkan permanen pada saat itu juga
Verifikasi pengembang Android juga tampaknya akan bergerak ke arah seperti ini
Banyak pengembang kemungkinan besar akan mengalami penangguhan status pengembang tanpa alasan yang jelas
Saya pernah melihat kasus ketika akun pribadi para pegawai sebuah perusahaan kecil ikut diblokir dengan alasan “terkait dengan akun pengembang yang sebelumnya ditangguhkan”
Dalam keadaan bergantung pada platform seperti itu, menurut saya sulit mempertahankan keahlian secara berkelanjutan
Layanan kami juga hanya memakai tombol “Login with Google”, tetapi tiba-tiba akunnya diblokir
Alasannya cuma samar-samar: “melanggar persyaratan layanan”
Sambil mengajukan banding dan buru-buru menyiapkan alternatif login bagi pengguna, keesokan harinya tiba-tiba datang email bahwa “banding disetujui”
Pada akhirnya memang pulih, tetapi rasa tidak percaya tetap tertinggal
Akun AdSense saya ditangguhkan tiga kali hanya karena memasang satu tanda seru di iklan
Pada akhirnya saya menutup akunnya, tetapi rasanya saya mungkin masih dilacak sebagai “akun berpotensi penipuan”
Jika pengguna baru bisa ditangguhkan dalam satu jam, saya jadi bertanya-tanya kenapa proses pendaftarannya dibuat semudah itu sejak awal
Dalam situasi seperti ini, saya jadi berpikir apakah Google perlu digugat atau didorong untuk menghadapi regulasi yang lebih ketat
Katanya Google sering tidak hadir, atau malah mencoba berdalih dengan TOS lalu itu berbalik merugikan mereka di mata hakim
Saya penasaran apa yang terjadi pada akun login khusus Passkey yang terdaftar dengan akun email yang ditangguhkan
Hampir tidak ada orang yang tampaknya pernah menguji apakah Passkey yang disinkronkan ke Google Password Manager tetap berfungsi setelah akun ditangguhkan,
atau justru tidak bisa dipulihkan karena akses emailnya ikut terblokir