- SSLMate'in Google Cloud hesabı üçüncü kez önceden haber verilmeden askıya alındı ve hizmet entegrasyonu özellikleri tekrar tekrar kesintiye uğradı
- Müşterilerin Cloud DNS ve Cloud Domains entegrasyonu için Google dokümanlarını izleyerek servis hesabı oluşturma ve yetki devri yapısına başvuruldu, ancak bu yöntem sürekli askıya alma hedefi oldu
- İlk askıya alma (2024), kurtarma sürecindeki verimsizlik ve belirsiz nedenler yüzünden büyük karışıklık yarattı; sonraki iki askıya almada da önceden bildirim olmadan yalnızca otomatik e-postalar tekrarlandı
- Alternatif olarak uzun ömürlü anahtar tabanlı kimlik doğrulama güvenlik açısından zayıf, OIDC(OpenID Connect) ise kurulum süreci bakımından aşırı karmaşık
- Sonuç olarak Google Cloud entegrasyonlarında güvenlik, kullanım kolaylığı ve istikrar arasından yalnızca ikisinin seçilebildiği yapısal bir sınır ortaya çıkıyor
Google Cloud hesabının tekrar tekrar askıya alınması vakası
- SSLMate'in Google Cloud hesabı 2024 ve 2025'te art arda cuma günlerinde önceden haber verilmeden askıya alındı
- Daha önce de 2024'te aynı askıya alma yaşanmıştı ve üç olayın hiçbirinde açık bir gerekçe ya da tekrarını önleme yöntemi sunulmadı
- SSLMate, müşterilerin Google Cloud hesaplarıyla entegre olmak için servis hesabı yetki devri yöntemini kullanıyor
- Her müşteri için SSLMate projesi altında bir servis hesabı oluşturuluyor ve müşteri bu hesaba Cloud DNS ve Cloud Domains erişim yetkisi veriyor
- SSLMate gerektiğinde bu servis hesabını taklit ederek (impersonate) erişiyor
- Bu yapı, Google'ın resmi dokümanlarında önerilen yönteme dayanıyor ve uzun ömürlü kimlik bilgileri olmadan güvenli, kurulumu da basit bir yöntem
İlk askıya alma (2024)
- İlk askıya almada tüm müşteri entegrasyonları başarısız oldu ve konsol erişimi engellendi
- Google destek ekibi yanıt verdi, ancak hesap devre dışı olduğu için e-postaların geri dönmesi gibi nedenlerle kurtarma süreci verimsizdi
- Proje ID'si istendi, ancak konsola erişim olmadığı için paylaşılamadı
- Telefon numarası doğrulamasından sonra yalnızca bazı projeler geri açıldı ve ertesi gün yeniden otomatik e-postayla erişim kısıtlaması bildirildi
- Sonrasında gelen birden çok otomatik e-postanın ardından yaklaşık 19 saat sonra tam erişim geri geldi
- Google askıya alma nedenini açıklamadı ve önceden gönderilmiş bir uyarı e-postası da yoktu
- SSLMate daha sonra erken tespit için entegrasyon hata oranlarını izleyen bir sağlık kontrolü ekledi
İkinci askıya alma (2025 Ekim civarı)
- Sağlık kontrolü başarısız oldu ve entegrasyonların çoğu "Invalid grant: account not found" hatası döndürdü
- Konsola giriş yapılabiliyordu, ancak her proje için yalnızca "sağladığınız bilgilere göre kurtarıldı" anlamına gelen e-postalar alındı
- Askıya alma bildirimi e-postası hâlâ gelmedi
- Sonrasında entegrasyon işlevi normale döndü
Üçüncü askıya alma (2025 Kasım)
- Sağlık kontrolü yeniden başarısız olduktan sonra konsola erişimde yeni tür bir hata mesajı gösterildi
- Projelerin büyük bölümü askıya alındı; müşteri entegrasyonlarına ayrılmış projeler de buna dahildi
- Cuma günü itiraz gönderildi, ancak pazar günü tüm hesabın askıya alındığını bildiren bir e-posta alındı
- Pazartesi günü, ilgili yazı Hacker News'te yayımlandıktan hemen sonra projelerin çoğu geri açıldı ve birkaç saat sonra tam erişim yeniden sağlandı
- Bu kez de askıya alma nedeni ya da nasıl önleneceği açıklanmadı
İstisna müşteri vakası
- Tüm askıya alma dönemlerinde yalnızca bir müşterinin entegrasyonu normal çalıştı
- Aynı proje içindeki servis hesabı kullanılmış olmasına rağmen etkilenmedi
- Bunun nedenine ilişkin ek bir açıklama yok
Google Cloud bağımlılığı sorunu ve alternatifler
- SSLMate, üretim ortamında Google hesabına güvenilemeyeceği sonucuna vardı
- Google sisteminde hesap, proje ya da GCP'nin tamamı rastgele askıya alınabilecek bir yapıya sahip görünüyor
- Alternatif 1: Müşteri servis hesabını kendisi oluşturur ve SSLMate'e uzun ömürlü anahtar (long-lived key) ile kimlik doğrulama sağlar
- Kurulum basit olsa da anahtar sızması riski ve döndürülememe sorunu nedeniyle güvenlik zayıf
- Alternatif 2: OpenID Connect(OIDC) kullanımı
- GitHub Actions veya Azure entegrasyonlarında kullanılan standart yöntemle, uzun ömürlü kimlik bilgileri olmadan güvenli erişim sağlanabilir
- Ancak Google Cloud tarafındaki kurulum 7 adımlı bir süreç olduğu için aşırı karmaşık
OIDC kurulumunun karmaşıklığı
- OIDC kullanmak için şu adımlar gerekiyor
- IAM Service Account Credentials API'yi etkinleştirmek
- Servis hesabı oluşturmak
- Workload Identity Pool oluşturmak
- Pool içinde Workload Identity Provider oluşturmak
- SSLMate'in servis hesabını taklit edebilmesi için yetki vermek
- Servis hesabına rol (Role) atamak
- Oluşturulan servis hesabı ile Provider ID'yi SSLMate'e iletmek
- Her adım bir önceki adımın kaynak ID'sine ihtiyaç duyduğu için müşterilerin bunu takip etmesi zor
- Yazar şu adımları gereksiz işlemler olarak eleştiriyor
- Servis hesabı oluşturmadan da rollerin doğrudan atanabilmesi gerekir
- Çoğu durumda Pool yalnızca tek bir Provider içerdiğinden ayrıca Pool oluşturmak gereksiz bir tekrar işi
- Provider oluşturmadan da OIDC issuer URL'si ve subject üzerine doğrudan rol atanabilmesi gerekir
Yapısal sorun ve sonuç
- Mevcut Google Cloud entegrasyonunda şu üç maddeden yalnızca ikisi seçilebiliyor
- Uzun ömürlü kimlik bilgileri olmaması
- Müşterinin kolayca kurabilmesi
- Rastgele askıya almalara karşı güvenli olması
- SSLMate'in servis hesabı tabanlı yöntemi güvenlik ve kullanım kolaylığı sağlıyor, ancak askıya alma riski taşıyor
- Servis hesabı + anahtar yöntemi kurulumu kolaylaştırıyor ve askıya alma riskini düşürüyor, ancak güvenliği zayıf
- OIDC yöntemi güvenlik ve askıya almaya karşı dayanıklılık sağlıyor, ancak kurulumu karmaşık
- Sonuç olarak Google OIDC'yi birinci sınıf entegrasyon yöntemi olarak sadeleştirmedikçe güvenli ve istikrarlı entegrasyon kurmak zor görünüyor
Okur yorumlarının özeti
- Bir okur, "Başka bir bulut sağlayıcısı kullanın, GCP en kötüsü" dedi
- Yazar buna, "Müşteriler GCP kullandığı için entegrasyon açısından buna ihtiyaç var" diye yanıt verdi
- Başka bir okur ise "Güvenlik ve güvenilirlik, sadelikle çatışır" diyerek sadeliği önceleyen müşterilerin buna uygun olmadığını savundu
2 yorum
"Android geliştirici doğrulaması da sonunda tam olarak böyle olacak. Pek çok kişinin Android için geliştirme yapması yasaklanacak."
Hacker News yorumları arasında aklımda en çok kalanlardan biri bu. Bunun o kadar da uzak olmadığını düşünüyorum.
Hacker News görüşü
İnsanlar Google'ı güvenilir bir iş ortağı olarak görüyor, ancak gerçekte sistem büyük ölçekli bir perakende fabrikası gibi tasarlanmış
Milyonlarca kişiye hizmet veriyor ve hatalı bir otomatik koruma önlemi tek başına binlerce insanın hayatını altüst edebiliyor
Müşteri desteğinin yokluğu ya da otomatik, anlamsız yanıtlar yalnızca maliyet düşürme değil, hukuki sorumluluğu en aza indirme stratejisi gibi görünüyor
Çoğu insan, Google hesabının herhangi bir anda sebepsiz yere askıya alınabileceğini biliyor
Hatta çevresinde hesabına erişimi kaybetmiş bir iki kişi tanıyan neredeyse herkes var
Milyonlarca dolarlık bir sözleşme söz konusu değilse, Google'ı gerçek bir ortak olarak gören insan sayısının çok az olduğunu düşünüyorum
Tüm platformlar ölçeklenmeyi önceliklendiriyor
Tek tek kullanıcılarla insani bir ilişkiyi korurken aynı zamanda uyuşturucu satıcısı düzeyinde kârlılığı sürdürmek imkânsız
İyi niyetli tek bir kişinin yanlışlıkla hedef alınması bile “gerekli maliyet” sayılıyor
Dün Wise, ondan önce de GitHub hesapları bu şekilde engellendi
Şirketler demokrasi gibi değil, feodal mülkler gibi yönetiliyor
Otomatik sistem sizi suçlu ilan ederse, yargılama olmadan doğrudan cezalandırılıyorsunuz
Gerçek bir insanla konuşabiliyorsunuz, sıradan bir chatbot'la değil
Şu anda Tuta Mail kullanıyorum; kuantum dirençli şifreleme ve reklamsız ortam hoşuma gidiyor
Kendi alan adımla istediğim kadar takma adres de oluşturabiliyorum
Birkaç yıl önce YouTube Premium hesabım spam gerekçesiyle engellendi
Sadece video izlememe rağmen hesabım silindi ve ödeme sayfasına erişimim de kapatıldı
Sadece 3 haftada bir yapılabilen robotik itiraz süreci devam ederken benden ücret alınmaya devam edildi
Google One'ın ücretli desteği de “başka bir ekip bakıyor, yardımcı olamayız” diyerek tamamen işe yaramaz çıktı
Sonunda kartı iptal ederek sorunu çözdüm, birkaç ay sonra ise “bu bir hataydı” mesajı aldım
İşin ironik yanı, WeChat bir gün içinde beni gerçek bir insanla görüştürüp sorunu çözdü — bu da bana sansür devletinin müşteri desteğinin daha iyi olduğu hissini verdi
Sorun yalnızca Google değil, genel olarak algoritmaya bağımlı büyük şirket yapısında
Reddit'te de 20 yıllık hesabım sebepsiz yere shadowban yedi
İtirazım görmezden gelindi, tüm yazılarım ve yorumlarım filtrelendi
Fediverse, daha iyi bir alternatif model gösteriyor — burada küçük topluluklar ve yüksek moderatör oranı kilit önemde
Tek bir #fediblock etiketiyle yüzlerce sunucuda otomatik engelleme yapılabilmesi, sorumluluktan kaçan sansürü yeniden üretiyor
Nitekim şehrimizdeki Mastodon instance'ı bu şekilde çöktü ve herkes Bluesky'a geçti
Bu tür edge case durumları ele alacak 100 kadar kişiyi istihdam etmek hiç de zor değil
Ama kâr marjı düşeceği için bunu yapmıyorlar
Mesele paralarının olmaması değil, harcamamayı tercih etmeleri
İleride Gemini API tarafında da benzer sorunlar çıkacak gibi görünüyor
Müşteri kuralları ihlal eden bir görsel üretirse, bunun sonucunda kurumsal Gmail ya da kişisel kurtarma amaçlı Gmail hesabı bile kalıcı olarak askıya alınabilir
Android geliştirici doğrulaması da muhtemelen benzer şekilde ilerleyecek
Pek çok geliştiricinin sebepsiz yere geliştirici yetkisinin askıya alınması riski büyük
Geçmişte küçük bir şirkette çalışanların kişisel hesaplarının, “daha önce askıya alınmış bir geliştirici hesabıyla bağlantılı” denilerek topluca engellendiği bir örnek görmüştüm
Platforma bu kadar bağımlıyken uzmanlığı korumanın zor olduğunu düşünüyorum
Bizim servisimiz de sadece “Login with Google” düğmesini kullanıyordu ama bir anda hesap engellendi
Gerekçe olarak sadece belirsiz bir “şartların ihlali” ifadesi verildi
İtiraz edip bir yandan da kullanıcılar için alternatif giriş yöntemleri hazırlarken, ertesi gün aniden “itiraz kabul edildi” e-postası geldi
Sonuçta hesap geri açıldı ama geriye güvensizlik kaldı
AdSense hesabım, reklama tek bir ünlem işareti koyduğum için üç kez askıya alındı
Sonunda hesabı kapattım ama hâlâ “potansiyel dolandırıcılık hesabı” olarak işaretleniyor olabileceğimi düşünüyorum
Yeni bir kullanıcı bir saat içinde askıya alınıyorsa, o zaman baştan kayıt sürecini neden bu kadar kolay yaptıkları sorgulanmalı
Böyle bir durumda Google'a karşı dava açmak ya da daha sıkı düzenleme istemek gerekip gerekmediğini düşünüyorum
Duyduğuma göre Google çoğu zaman duruşmaya gelmiyor ya da TOS'u savunma olarak öne sürüp hâkim nezdinde ters etki yaratabiliyor
Askıya alınmış bir e-posta hesabına kayıtlı yalnızca Passkey ile giriş yapılan hesapların ne olacağını merak ediyorum
Google Password Manager ile senkronize edilmiş Passkey'nin hesap askıya alındıktan sonra da çalışıp çalışmadığını,
yoksa e-postaya erişim kesildiği için kurtarmanın imkânsız mı hâle geldiğini test etmiş çok az kişi vardır diye düşünüyorum