Kafka Event Streaming ve Backend Güvenliği

Event Streaming Hız Kazandırır, Sınırları Bulanıklaştırır

Kafka ve event streaming mimarileri modern backend sistemlerde senkron bağımlılıkları azaltır. Sipariş, ödeme, bildirim, fraud analizi, audit log ve data pipeline gibi akışlar birbirinden ayrılır. Bu, ölçeklenebilirlik için güçlü bir adımdır; fakat güvenlik sınırları doğru çizilmezse olay tabanlı mimari veri sızıntısı ve yetki atlama yüzeyine dönüşebilir.

Senkron API dünyasında request ve response net görünür. Event streaming dünyasında ise bir servis event üretir, başka servisler onu tüketir, üçüncü bir servis yan etki üretir. Bu zincirde yanlış event, yanlış consumer veya yanlış yetki modeli ciddi sonuç doğurabilir.

Kafka'da Güvenlik Sadece TLS Değildir

Kafka cluster'ı TLS ile konuşuyor olabilir; bu tek başına yeterli değildir. Asıl sorular şunlardır:

Hangi servis hangi topic'e yazabilir?
Hangi consumer hangi tenant verisini okuyabilir?
Event payload içinde hassas veri var mı?
Schema değişimi eski consumer'ları nasıl etkiler?
Replay yapıldığında aynı yan etki tekrar oluşur mu?
Poison message sistemi kilitleyebilir mi?

Bu sorular yanıtlanmadan Kafka güvenli kabul edilmemelidir.

Topic Yetkileri ve Least Privilege

Kafka'da sık görülen hata, servis hesaplarına geniş topic yetkisi vermektir. Bir ödeme servisi yalnızca payment.events topic'ine yazmalı ve gerekli topic'leri okumalıdır. Tüm topic'leri okuyabilen bir servis hesabı ele geçirildiğinde saldırgan kurumdaki olay akışını izleyebilir.

Servis hesabı tasarımında:

Read ve write yetkileri ayrılmalı.
Production ve staging cluster kimlikleri farklı olmalı.
Consumer group yetkileri kontrol edilmeli.
Admin yetkileri pipeline servislerine verilmemeli.
Topic naming tenant ve domain sınırlarını yansıtmalı.

Schema Governance

Event payload'ları zamanla büyür. Bir ekip "debug için" müşteri e-postası, token parçası veya internal risk skorunu event içine ekleyebilir. Bu alan tüm downstream consumer'lara gider ve fark edilmeden veri minimizasyonu ihlal edilir.

Schema registry veya schema review süreci bu yüzden güvenlik kontrolüdür. Her yeni alan için şu sorular sorulmalıdır:

Bu alan gerçekten gerekli mi?
PII veya secret içeriyor mu?
Hangi consumer'lar okuyacak?
Retention süresi regülasyonla uyumlu mu?
Maskelenmiş veya tokenized taşınabilir mi?

Replay ve Idempotency

Kafka'nın güçlü yanlarından biri event replay yeteneğidir. Aynı özellik güvenlik açısından risklidir. Bir consumer replay sırasında ödeme, e-posta, SMS veya webhook gibi yan etkileri tekrar üretirse sistem iş mantığı olarak bozulur.

Consumer tarafında idempotency key, event version, processed-event store ve yan etki kontrolü olmalıdır. "At least once" teslimat modelini güvenli yapmak backend ekibinin sorumluluğudur.

Poison Message ve Dead Letter Queue

Yanlış formatlı veya kötü niyetli event consumer'ı sürekli crash ettiriyorsa sistem durabilir. Poison message koruması, retry limiti, dead letter queue ve alarm mekanizması zorunludur. Ancak DLQ hassas payload saklıyorsa ikinci bir veri sızıntısı deposuna dönüşür.

Eresus Yaklaşımı

Eresus Security, event-driven backend güvenlik testlerinde Kafka topic yetkileri, schema sızıntıları, replay etkisi, DLQ veri riski ve consumer idempotency davranışlarını birlikte değerlendirir. Event streaming mimarisi güçlüdür; fakat güvenli olması için olayların kim tarafından, hangi amaçla ve hangi sınırda tüketildiği kanıtlanmalıdır.

Saha Kontrol Notları

Backend ve API güvenliği, endpoint saymaktan ibaret değildir. Asıl risk çoğu zaman rol, tenant, object ownership ve async iş akışlarında ortaya çıkar.

İnceleme sırasında şu kanıtlar toplanmalıdır:

Endpoint hangi business object üzerinde çalışıyor?
Kullanıcı rolü aksiyonla eşleşiyor mu?
Tenant ID kullanıcıdan mı geliyor, sunucu tarafında mı çözülüyor?
JWT sadece kimlik taşıyıcısı mı, yoksa yanlışlıkla yetki kaynağı mı yapılmış?
Rate limit kullanıcı, IP ve maliyetli aksiyon bazında ayrılıyor mu?
Webhook ve queue tarafında aynı yetki kontrolü tekrar ediliyor mu?
Loglar object ID ve tenant bağlamını gösteriyor mu?
Hata cevapları veri sızdırıyor mu?
Test hesapları gerçek rolleri temsil ediyor mu?
Retest için net başarı kriteri var mı?

Uygulama Kontrol Listesi

Her endpoint için ownership kontrolü yazılmalı.
BOLA ve IDOR testleri rol ve tenant çaprazlamasıyla yapılmalı.
Admin aksiyonları ayrı onay ve log gerektirmeli.
Provider entegrasyonları token kapsamı açısından incelenmeli.
Async job ve webhook akışları test kapsamına alınmalı.
Bulgular teknik etki ve iş etkisiyle birlikte sınıflandırılmalı.

Karar Noktası

API müşteri verisi, ödeme, abonelik, dosya veya entegrasyon taşıyorsa manuel assessment gerekir. Eresus Security bu noktada scanner çıktısının ötesine geçip yetki hatasını gerçek isteklerle kanıtlar.

Ek Kontrol Soruları

Bu risk hangi varlıkları etkiliyor?
Hangi kullanıcı rolleri bu akışa erişebiliyor?
Aynı sorun başka endpoint veya entegrasyonda tekrar ediyor mu?
Bulgunun müşteri verisine etkisi var mı?
Loglardan olayın izi sürülebiliyor mu?
Düzeltme sonrası retest nasıl yapılacak?
Geçici önlem ile kalıcı çözüm ayrıldı mı?
İş etkisi teknik ekibin dışında da anlaşılır mı?
Benzer hata için önleyici kontrol eklenebilir mi?
Ekip bu kontrolü release sürecine bağlayabilir mi?
Gerekirse bağımsız doğrulama için hangi kanıtlar hazırlanmalı?
Sonraki sprintte hangi iç bağlantı ve servis sayfası desteklemeli?