Node.js AsyncLocalStorage ile Güvenli Observability

Request Context Kaybolursa Güvenlik Körleşir

Node.js backend'lerinde observability çoğu zaman logger eklemekle sınırlı kalır. Ancak mikroservis, queue, async job ve dış servis çağrılarının olduğu bir sistemde tek bir log satırı yeterli değildir. Bir güvenlik olayını anlamak için request ID, kullanıcı, tenant, session, trace ID, risk skoru ve endpoint bilgisi aynı akışta taşınmalıdır.

AsyncLocalStorage bu noktada güçlü bir araçtır. Her request için küçük bir context oluşturur ve bu context async/await, promise ve callback zincirlerinde taşınabilir. Böylece her fonksiyona requestId parametresi geçirmek zorunda kalmadan log ve audit verisini tutarlı hale getirebilirsiniz.

Güvenlik Açısından Ne İşe Yarar?

AsyncLocalStorage doğru kullanıldığında şu problemleri çözer:

• Hangi log satırı hangi kullanıcı isteğine ait?
• Permission denied olayı hangi tenant içinde yaşandı?
• Bir export job hangi request ile başladı?
• Hangi correlation ID ödeme provider çağrısına gitti?
• Saldırı sırasında aynı kullanıcı hangi endpoint zincirini izledi?

Bu sorulara cevap veremeyen backend sistemi olay müdahalesinde zayıftır.

Minimal Context Tasarımı

Context küçük ve kontrollü olmalıdır. Büyük objeler, request body, token veya kullanıcı profili AsyncLocalStorage içine konmamalıdır. Güvenli context örneği:

type RequestContext = {
  requestId: string;
  tenantId?: string;
  userId?: string;
  sessionId?: string;
  route?: string;
  riskLevel?: "low" | "medium" | "high";
};

Bu alanlar log, trace ve audit event üretmek için yeterlidir. Hassas veri taşımadan korelasyon sağlar.

Yanlış Kullanım Riskleri

AsyncLocalStorage bir session store değildir. Cache değildir. Authorization kaynağı hiç değildir. Eğer backend policy kararını yalnızca context içindeki tenantId değerine dayandırırsa saldırı yüzeyi açılır. Context gözlem ve korelasyon içindir; güvenlik kararları server-side doğrulanmış session ve policy katmanından gelmelidir.

Ayrıca uzun ömürlü timer, global singleton veya stream akışlarında context referansları yanlış tutulursa memory leak oluşabilir. Bu nedenle kullanım kapsamı net olmalı ve yük testiyle doğrulanmalıdır.

Audit Log ile Birleştirme

Güvenlik açısından en değerli kullanım, audit event'lerin otomatik context ile zenginleşmesidir:

audit.log("api_key.created", {
  requestId: ctx.requestId,
  tenantId: ctx.tenantId,
  userId: ctx.userId,
  target: apiKey.id,
});

Bu yapı sayesinde kritik olaylar sonradan birleştirilebilir. API key üretimi, role değişimi, export, webhook secret görüntüleme, payment action ve admin impersonation gibi olaylar mutlaka context taşımalıdır.

Eresus Yaklaşımı

Eresus Security, backend değerlendirmelerinde observability tasarımını güvenlik kontrolü olarak inceler. AsyncLocalStorage gibi araçlar doğru kullanıldığında saldırı analizi ve regülasyon kanıtı üretir; yanlış kullanıldığında ise veri sızıntısı veya memory leak kaynağına dönüşür.

Saha Kontrol Notları

Bu başlık pratikte yalnızca teorik risk olarak ele alınmamalıdır. AI sistemlerinde zafiyetin etkisi, modelin bulunduğu ortam ve bağlı olduğu veri kaynaklarıyla birlikte değişir.

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

• Model veya agent hangi ortamda çalışıyor?
• Hangi kullanıcı veya servis hesabı kullanılıyor?
• Hassas veri kaynakları ayrı etiketlenmiş mi?
• Model dosyası veya artefact kaynağı doğrulanmış mı?
• Yükleme anında kod çalıştırma riski var mı?
• Retrieval sonuçları kullanıcı yetkisine göre filtreleniyor mu?
• Tool çağrıları ayrı loglanıyor mu?
• Kritik aksiyonlarda onay mekanizması var mı?
• Test ortamı production verisinden ayrılmış mı?
• Olay halinde hangi loglardan geri dönüş yapılacak?

Uygulama Kontrol Listesi

• Güvenilmeyen model dosyaları izole ortamda açılmalı.
• Model registry erişimi minimum yetkiyle çalışmalı.
• Hash, imza veya provenance bilgisi tutulmalı.
• Agent tool izinleri görev bazlı ayrılmalı.
• Memory ve retrieval kaynakları ayrı güven sınırı olarak ele alınmalı.
• Prompt testleri runtime aksiyon testleriyle desteklenmeli.
• Her bulgu iş etkisiyle birlikte raporlanmalı.

Karar Noktası

Bu risk müşteri verisine, üretim API’sine, geliştirici ortamına veya model yükleme hattına dokunuyorsa bekletilmemelidir. Eresus Security bu tip incelemelerde dosya, runtime, tool ve veri sınırını birlikte test ederek gerçek saldırı yolunu 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?