API Gateway İle Audit Log Nasıl Kontrol Edilir?

API Gateway, mikroservis mimarilerinde trafiğin geçtiği merkezi nokta olduğu için güvenlik, izlenebilirlik ve uyumluluk açısından kritik bir veri kaynağıdır. Hangi istemcinin hangi endpoint’e ne zaman eriştiğini, isteğin hangi yanıt koduyla döndüğünü ve hatanın nerede oluştuğunu doğru okumak; hem operasyon ekiplerinin müdahale süresini kısaltır hem de denetim süreçlerinde güvenilir kanıt sağlar.

Audit Log Neden API Gateway Üzerinden Kontrol Edilir?

Audit log, yalnızca teknik hata kayıtlarından ibaret değildir. Kullanıcı davranışları, yetkilendirme denemeleri, başarısız erişimler, şüpheli istek yoğunlukları ve servisler arası trafik akışı hakkında denetlenebilir kayıt sunar. Gateway katmanı tüm isteklerin giriş noktası olduğu için logların merkezi biçimde toplanması daha tutarlı bir analiz sağlar.

API Gateway audit log kontrolü, özellikle finans, e-ticaret, sağlık, kamu ve SaaS ürünlerinde güvenlik politikalarının doğrulanması için önemlidir. Bir olay yaşandığında “kim, ne zaman, hangi kaynağa erişti?” sorusuna hızlı yanıt verilemiyorsa loglama stratejisinde eksik var demektir.

Kontrol Edilmesi Gereken Temel Audit Log Alanları

Audit logların anlamlı olması için her kaydın belirli alanları içermesi gerekir. Sadece tarih ve hata mesajı kaydetmek çoğu kurumsal senaryoda yeterli değildir.

• Timestamp: İsteğin gerçekleştiği zaman, tercihen UTC formatında tutulmalıdır.
• Request ID veya Correlation ID: Bir isteğin gateway’den mikroservislere kadar izlenmesini sağlar.
• Client IP: Kaynağın tespitinde kullanılır; proxy arkasında gerçek IP başlıkları ayrıca doğrulanmalıdır.
• HTTP method ve endpoint: Hangi kaynağa hangi işlemle erişildiğini gösterir.
• Status code: Başarılı, hatalı veya yetkisiz erişimleri sınıflandırmayı kolaylaştırır.
• Authenticated user veya token subject: İşlemin hangi kullanıcı ya da servis hesabı ile yapıldığını gösterir.
• Latency: Performans sorunlarının güvenlik veya altyapı problemiyle ilişkisini analiz etmeye yardımcı olur.

API Gateway Üzerinde Audit Log Nasıl Aktifleştirilir?

Kullanılan platforma göre adımlar değişse de mantık benzerdir: erişim logları etkinleştirilir, gerekli alanlar formatlanır, loglar merkezi bir hedefe gönderilir ve saklama politikası tanımlanır. AWS API Gateway, Kong, NGINX, Apigee veya Azure API Management gibi çözümlerde bu yapılandırma farklı ekranlardan yapılabilir.

1. Log Formatını Standartlaştırın

Log formatı ekipler arasında ortak anlaşılabilir olmalıdır. JSON tabanlı formatlar, SIEM ve gözlemlenebilirlik araçlarıyla daha kolay işlenir. Alan isimlerini sık değiştirmek, geçmiş analizlerde kırılmalara yol açabilir.

2. Hassas Verileri Loglamayın

En sık yapılan hatalardan biri, authorization header, access token, parola, kart bilgisi veya kişisel veri içeren payload alanlarını olduğu gibi kaydetmektir. Audit log güvenlik sağlar; ancak yanlış yapılandırılırsa veri sızıntısı riskini artırır. Gerekli alanlar maskeleme veya hashleme ile tutulmalıdır.

3. Merkezi Log Toplama Kurgulayın

Logların yalnızca gateway sunucusunda kalması operasyonel risk yaratır. Sunucu silindiğinde, pod yeniden başladığında veya disk dolduğunda kritik kayıtlar kaybolabilir. Bu nedenle loglar merkezi bir platforma, örneğin SIEM, log management veya observability altyapısına aktarılmalıdır.

Audit Log Analizinde Dikkat Edilecek Göstergeler

Audit logları yalnızca olay sonrasında incelemek yeterli değildir. Düzenli analiz ve alarm kuralları, sorunlar büyümeden müdahale edilmesini sağlar.

• Kısa sürede artan 401 ve 403 yanıtları yetkisiz erişim denemelerine işaret edebilir.
• Aynı IP’den farklı kullanıcılarla yapılan denemeler credential stuffing riskini gösterebilir.
• Normalden yüksek 5xx oranı backend servislerinde kesinti veya timeout problemi olduğunu gösterebilir.
• Beklenmeyen endpoint çağrıları, yanlış yayınlanmış API dokümantasyonu veya keşif denemeleriyle ilişkili olabilir.
• Yüksek latency değerleri, rate limit eksikliği ya da servis darboğazı nedeniyle oluşabilir.

Rate Limit, Kimlik Doğrulama ve Audit Log İlişkisi

Gateway üzerinde rate limit, API key, OAuth2, JWT veya mTLS gibi kontroller uygulanıyorsa audit logların bu kararları da yansıtması gerekir. Sadece “istek reddedildi” bilgisi yerine, reddin sebebi açıkça kaydedilmelidir. Örneğin token süresi dolduğu için mi, rol yetkisi yetersiz olduğu için mi, yoksa limit aşıldığı için mi erişim engellendiği ayrıştırılmalıdır.

Bu ayrım, destek ekipleri için de değerlidir. Kullanıcı “API çalışmıyor” dediğinde log üzerinden hatanın kimlik doğrulama, yetki, kota veya backend kaynaklı olup olmadığı hızlıca anlaşılır.

Kurumsal Ortamlarda Saklama ve Uyumluluk Politikası

Audit logların ne kadar süre saklanacağı sektör regülasyonlarına, iç denetim gerekliliklerine ve veri koruma politikalarına göre belirlenmelidir. Gereğinden kısa saklama, olay incelemelerini zorlaştırır; gereğinden uzun saklama ise maliyet ve kişisel veri riski oluşturabilir.

İyi bir politika; saklama süresi, erişim yetkileri, şifreleme, arşivleme ve silme süreçlerini netleştirir. Loglara erişim de ayrıca izlenmelidir. Çünkü audit loglar çoğu zaman sistemin en hassas operasyonel kayıtları arasında yer alır.

Pratik Kontrol Listesi

Canlı ortamda API Gateway audit log kontrolü yaparken aşağıdaki maddeler hızlı bir doğrulama sağlar:

• Her istek için benzersiz request ID üretiliyor mu?
• Loglarda kullanıcı, servis hesabı veya istemci kimliği görünüyor mu?
• Başarısız kimlik doğrulama ve yetkilendirme denemeleri ayrıştırılıyor mu?
• Hassas header ve payload alanları maskeleniyor mu?
• Loglar merkezi sisteme kesintisiz aktarılıyor mu?
• Yetkisiz log erişimleri ayrıca kayıt altına alınıyor mu?
• Alarm kuralları gerçek iş risklerine göre tanımlanmış mı?

Audit log yapısını düzenli olarak test etmek, gateway yapılandırması değiştiğinde beklenmeyen boşlukları erkenden ortaya çıkarır. Yeni bir endpoint, yeni bir kimlik doğrulama yöntemi veya yeni bir mikroservis devreye alındığında log formatının bozulmadığından emin olmak operasyonel güvenilirliği korur.