Snowflake Müşterilerini Vuran Token Sızıntısı: Zincir Kırıldı

Size bir şey söyleyeyim, Bir veri ihlali haberi çıkınca çoğu kişi “yine bir şirket hack’lendi” deyip geçiyor. Anlıyorum, ben de bazen öyle yapıyorum açıkçası. Ama işin içine SaaS entegratörü, çalınan kimlik doğrulama token’ları ve onlarca kuruma yayılan veri hırsızlığı girince tablo bambaşka bir hal alıyor (kendi tecrübem). Asıl mesele şu: saldırganlar çoğu zaman doğrudan ana hedefe girmiyor — aradaki güven köprüsünü ele geçirip sessizce, hiç ses çıkarmadan içeri süzülüyor (evet, doğru duydunuz). Ve fark edilene kadar iş işten geçmiş oluyor.

Bu olayda da benzer bir zincir görüyoruz (şaşırtıcı ama gerçek). Bir SaaS entegrasyon sağlayıcısının ihlale uğraması sonrası çalınan token’lar kullanılarak Snowflake müşterilerine yönelik veri hırsızlığı saldırıları yapıldığı bildirildi. Hani kapıyı kırmıyorlar da anahtarı cebinizden alıp evinize giriyorlar ya… Tam olarak o his işte. Sinir bozucu.

Asıl Darbe Nereden Geldi?

Bence, Güvenlik dünyasında en can sıkıcı senaryo bu bence. Saldırgan sizin sisteminizi değil, sizin güvendiğiniz üçüncü tarafı hedef alıyor (yanlış duymadınız). O noktada alarm eşiği düşüyor, trafik meşru görünüyor ve denetim ekipleri ilk bakışta “normal” sandığı hareketleri gözden kaçırabiliyor — çünkü beklemedikleri şeye dikkat edemiyorlar. İşin aslı şu ki, SaaS entegratörleri tam da bu yüzden kilit hale geldi; hem vazgeçilmez oldular hem de kör nokta.

Evet, doğru duydunuz.

Sorun sadece veri sızıntısı değil. Yetki devri modeli denen şey var ya, asıl problem orada. Bir servis başka servise bağlanırken (söylemesi ayıp) token kullanıyor, API çağrıları yapıyor, erişim açıyor. Eğer o token çalınırsa saldırgan için ortada kilit falan kalmıyor. Anahtar var, adres var, rota var… gerisi malum.

Kasım 2024’te İstanbul’da bir finans ekibiyle yaptığım kapalı oturumda buna çok benzer bir vakayı tartışmıştık. O ekipte olay doğrudan Snowflake değildi,. Üçüncü taraf entegrasyon üzerinden gelen yetkisiz sorgular yüzünden loglar günlerce temiz görünmüştü — tam anlamıyla tertemiz, şüphe uyandıracak tek bir işaret yok. Sonradan fark ettik ki problem firewall’da değilmiş; güvenilen servis hesabının davranışında saklanıyormuş. Kimse o hesabı sorgulamayı düşünmemiş çünkü “güvenilir” etiketini taşıyordu.

Kısa bir not düşeyim buraya.

Neden Bu Kadar Tehlikeli?

Şöyle ki, Klasik “şifreyi sıfırladık, tamamdır” yaklaşımı burada işlemiyor. Hiç işlemiyor. Token tabanlı erişimlerde saldırgan elindeki belirteci geçerli olduğu sürece kullanabiliyor; sistem ona kapıyı açmaya devam ediyor çünkü token geçerli görünüyor. Bir de üstüne bu erişim genelde otomasyonlarda kullanıldığı için insan gözüne pek çarpmıyor — makine konuşuyor makineyle, kim bakacak ki?

Bence en rahatsız edici kısım şu: kurumsal ekipler çoğu zaman kendi sistemlerini sıkılaştırdığını düşünürken asıl açık dışarıdaki partnerde kalabiliyor. Kendi bahçenizi çitle çevirmişsiniz ama komşunun kapısı ardına kadar açık bırakılmış (kendi tecrübem). Garip ama gerçek. Ve ne yazık ki yaygın.

Yani, Ekim 2023’te Berlin’de katıldığım bir güvenlik çalıştayında bir CISO bana aynen şunu demişti: “Bizde sızıntı yoktu, tedarik zincirimizde vardı.” O cümle aklımda kaldı. Çünkü bugünün saldırıları tam olarak bunu yapıyor; tek noktayı delmek yerine bağlantılı halkaları koparıyor, teker teker. Bu konuyla ilgili Anthropic’in Mythos hamlesi: Güvenlikte yeni bir vitrin yazımıza da göz atmanızı tavsiye ederim.

Aşama	Saldırgan Ne Yapıyor?	Neden İşe Yarıyor?
İlk erişim	SaaS entegratörünü ele geçiriyor	Daha zayıf halka genelde orası oluyor
Token hırsızlığı	Kullanılabilir kimlik bilgilerini alıyor	Erişim meşru görünüyor
Yan hareket	Müşteri ortamlarına sorgu gönderiyor	Anormal trafik gibi görünmeyebiliyor
Veri çıkarma	Dosya ve tablo verilerini topluyor	Tespit edilmesi gecikebiliyor

Küçük Startup ile Kurumsal Şirket Arasındaki Fark Ne?

Küçük startup için mesele genelde hızla büyüyen entegrasyon listesi oluyor. Her yeni araç tak-çalıştır mantığıyla ekleniyor, kim hangi token’ı nerede tutuyor sorusu ise ikinci, üçüncü plana düşüyor — bazen neredeyse tamamen unutuluyor. Açık konuşayım: bu aşamada ekipler çoğu zaman güvenliği ürünün arkasına itiyor, sonra da ilk audit geldiğinde şaşkına dönüyor. Şaşırmamalılar aslında ama yine de şaşırıyorlar.

Kurum tarafında manzara daha karmaşık. Daha olgun da olabilir diye düşünülüyor — her zaman öyle değil tabi. Büyük şirketlerde entegrasyon sayısı arttıkça görünürlük sorunu başlıyor; yüzlerce servis hesabı, ayrı ayrı izinler. Birbirine kenetlenmiş pipeline’lar derken yanlış yapılandırma ihtimali giderek büyüyor. Gözden kaçan küçük şeyler birikirken fark etmek zor oluyor. 2026’da Ağ Kurma Laboratuvarı: CML, GNS3, INE yazımızda bu konuya da değinmiştik.

Açık konuşayım, Küçük startup avantajı: hızlı karar verir, birkaç günde token rotasyonu. Least privilege uygulayabilir.
Küçük startup dezavantajı: kaynak azdır, izleme eksik kalır.
Kurum avantajı: SOC ve IAM süreçleri vardır.
Kurum dezavantajı: süreç ağırdır, değişiklik yapmak bazen haftalar sürer.

Neyi Önce Düzeltmeli?

Lafı gevelemeden söyleyeyim: önce erişimi daraltmak gerekiyor. Token’ın kapsamını küçültün, süreyi kısaltın, kullanılmayan bağlantıları kapatın — bunlar temel, bunlarsız olmaz. Sonra loglara bakın; özellikle sıra dışı sorgu hacmi, mesai saati dışı erişimler ve alışılmadık IP desenleri önemli sinyal veriyor. Bunları atlamayın.

Tuhaf ama, Neyse uzatmayalım… Bu tür olaylarda “hemen tüm sistemi kapatalım” refleksi anlaşılır ama her zaman doğru değil. Bazen sadece ilgili entegrasyonu askıya almak yeterli olur. Neden önemli bu? Bazen de tüm secrets döngüsünü yenilemek gerekiyor — duruma göre değişiyor, tek reçete yok.

En kritik ders şu: Güvenlik artık sadece içerideki duvarları yükseltmek değil, dışarıdaki tüm bağlantıları da tek tek denetlemek zorunda.

Saldırıya Karşı Pratik Savunma Planı

Şöyle söyleyeyim, Bu haberi editör masasında ilk gördüğümde aklıma hemen “incident response checklist” geldi. Çünkü böyle durumlarda teori güzel görünür ama pratikte herkes aynı anda panikler — ürün ekibi ne olduğunu anlamaya çalışır, güvenlik ekibi log kovalar, yönetim ise “peki biz ne kadar etkilendik?” diye sorar. Herkes birbirinden farklı bir şey ister, ortada kaos olur.

Bence uygulanabilir savunma planı üç parçadan oluşuyor: kimliği sıkıştırmak, görünürlüğü artırmak ve etki alanını küçültmek. En çok da SaaS integrator kullanan ekipler için bu üçlü gerçekten hayati — atlarsanız başınız belaya girer. Google’dan Android Kullanıcılarına 135 Milyon Dolarlık Payout: Şimdi Ne Yapmalı? yazımızda bu konuya da değinmiştik.

• MFA tek başına yeterli sanmayın: Token bazlı bağlantılar ayrıca incelenmeli.
• Kapsam kontrolü yapın: Entegrasyonların gerçekten ihtiyaç duyduğu izinlerle sınırlayın.
• Döngüsel rotasyon uygulayın: API anahtarlarını periyodik olarak yenileyin.
• Anomali izleme kurun: Büyük veri çekimleri ve olağandışı saatlerdeki erişimleri işaretleyin.
• Tedarikçi değerlendirmesi yapın: Partnerlerin güvenlik olgunluğunu düzenli kontrol edin.

Peki Hangi Araçlar İşe Yarar?

Bazı ekipler SIEM’e abanıyor ama sihir orada değil; doğru alarm kurgusunda gizli. Bir de DLP sistemleri var ki — şimdi burada dürüst olmak lazım — bazen işe yarıyor, bazen yaramıyor. Ham haldeyken fazla gürültü çıkarabiliyorlar, her şeyi alarm olarak işaretleyince kimse o alarmlara bakmaz hale geliyor. Hani ne farkı var diyorsunuz, değil mi? O yüzden kuralları iş yüküne göre ince ayar yapmak şart, yoksa araç değil yük olur.

# Basit kontrol mantığı örneği
if login_source not in trusted_ip_ranges:
alert("Şüpheli giriş")
if query_volume > baseline * 3:
alert("Anormal veri çekimi")
if token_age > rotation_policy_days:
revoke_token()

Sektörün Çıkarması Gereken Dersler

Ağustos 2024’te Londra’da konuştuğum bir bulut mimarı bana şöyle demişti: “Bugün güvenlik duvarını delmek pahalıysa tedarik zincirini kiralamak daha ucuz.” Sert bir cümleydi. Haklıydı da. Çünkü modern saldırılar artık direkt çatışmadan çok dolaylı yol tercih ediyor; sürtüşme nerede azsa oradan gidiyorlar, her zaman öyle yapmışlar aslında. Open Banking, Yapay Zekâ Ajanları İçin Neden Biçilmiş Kaftan? yazımızda da bu konuya değinmiştik. Yapay Zekâyla Kod Yazarken Kontrolü Nasıl Kaybetmiyorum yazımızda da bu konuya değinmiştik.

Bu haberin bence en önemli taraflarından biri psikolojik etkisi. Ekipler kendini güvende sanarken asıl tehlikenin ortak kullanılan servislerde saklandığını görmek moral bozucu — gerçekten. İyi yapılandırılmış sandığınız mimari tek bir kötü entegre noktayla sallanabiliyor. Bu farkındalık rahatsız edici ama gerekli.

E tabi burada suç tamamen teknolojiye atılamaz. Kurumsal alışkanlıklar, aceleyle açılan test hesapları, eskiden kalma yetkiler… Bunların hepsi üst üste binince küçük bir ihlal büyük hasara dönüşebiliyor. Teknik sorun kadar davranışsal sorun da bu. İkisini birlikte çözmeden sadece araç almak yetmiyor — çok nadir yetmedi zaten.

Sıkça Sorulan Sorular

SaaS integrator breach tam olarak ne demek?

SaaS entegratörünün ihlale uğraması demek,birden fazla bulut servisi arasında köprü kuran aracın ele geçirilmesi demektir.Bu durumda saldırgan yalnızca o araca değil,bağlı olduğu müşteri sistemlerine de ulaşmaya çalışabilir.

Token çalındığında şifre değiştirmek yeterli mi?

Bazen hayır.Çünkü token geçerli kaldığı sürece şifre değişimi tek başına etkili olmayabilir.Önemli olan aktif oturumları iptal etmek,token’ları rotasyona sokmak ve yetkileri yeniden gözden geçirmek.

Küçük şirketler nasıl korunmalı?

Kapsam daraltma,token rotasyonu ve temel log izleme ile başlanmalı.Az araç kullanmak bazen daha iyidir çünkü her yeni entegrasyon yeni risk getirir.Yani önce sadelik,sonra ölçek geliyor.

Böyle saldırılar nasıl fark edilir?

Anormal sorgu hacmi,beklenmeyen coğrafi konumdan girişler,mesai dışı aktiviteler ve büyük veri dışa aktarma hareketleri önemli işaretlerdir.Ama dürüst olayım,bazıları haftalarca fark edilmeyebilir;özellikle günlük işler çok yoğunsa.

Kaynaklar ve İleri Okuma

Snowflake Security Resmi Sayfası

Snowflake Access Control Dokümantasyonu

OWASP API Security Top 10

\{“analysis”:””}