Güvenlik loglarında kişisel veri ve sırlar nasıl korunur?

Kişisel veri ve sırları loglarda korumanın en doğru yolu, hassas değeri daha yazılmadan maskelemek veya hiç kaydetmemektir. Bunun üzerine log erişimini en az yetkiyle sınırlandırın, aktarımda ve depolamada şifreleme kullanın, saklama süresini amaca göre kısaltın ve logların düzenli olarak incelenmesini sağlayın. Sadece log dosyasını sonradan silmek yeterli değildir; değer merkezi log sistemine, hata izine, yedeklere veya üçüncü taraf izleme servisine daha önce gönderilmiş olabilir.

Hangi bilgiler hassastır?​

Kişisel veri; kullanıcı adı, e-posta, telefon, IP adresi, oturum kimliği ve istek içinde taşınan kişiyi belirleyebilecek diğer değerlerdir. Sır ise parola, API anahtarı, erişim belirteci, çerez, özel anahtar, veritabanı bağlantı parolası ve benzeri kimlik doğrulama bilgileridir. Bir bilginin logda görünmesi hata ayıklamayı kolaylaştırsa bile, gereksizse kaydedilmemelidir.

Özellikle şu alanları varsayılan olarak hassas kabul edin: Authorization, Cookie, Set-Cookie, parola alanları, ödeme veya kimlik bilgileri, sorgu dizeleri, yüklenen dosya adları ve hata kayıtlarındaki ortam değişkenleri.

Koruma yaklaşımı​

Loglama politikanızı her alan için “kaydet”, “maskele” veya “hiç kaydetme” kararıyla oluşturun. Aşağıdaki ayrım, uygulama ve web sunucusu loglarının tasarımında kullanılabilir.


Maskeleme gereksiz ayrıntıyı azaltmalıdır; fakat kısmi maskeleme veya hash tek başına hukuken anonim veri garantisi değildir. Örneğin bir e-posta adresini a***@example.com biçiminde göstermek teşhis için yeterli olabilir; ancak tokenın yalnızca ilk veya son birkaç karakterini bırakmak, tokenın tamamının başka bir yerde sızdığı durumda ek risk oluşturabilir. Değerlerin birbirine eşleştirilmesi gerekiyorsa gerçek sırrı değil, erişimi sınırlı ve amaca uygun bir özet değerini kullanın.

Uygulanabilir kurulum ve kontrol adımları​

1. Uygulamanın, web sunucusunun, ters proxy'nin, hata izleme aracının ve merkezi log sisteminin kaydettiği alanları listeleyin. Test ortamında yalnız geçersiz temsili parola/token ve yapay kişisel veri işaretçileri içeren örneklerle hangi kanallara yayıldığını kontrol edin.
2. Kimlik doğrulama başlıkları, çerezler, parola alanları ve sorgu parametreleri için kaynakta filtreleme uygulayın. Filtreyi merkezi log sistemine ulaştıktan sonra değil, uygulama veya sunucu log olayı oluşturulmadan önce çalıştırın.
3. Serbest metin hata mesajlarında istek gövdesi, ortam değişkeni veya bağlantı dizesi yazdırılmasını kapatın. İstisna kaydında tam değer yerine olay kimliği, hata türü, zaman ve güvenli teknik bağlam bırakın.
4. Log erişimini görev gereği gereken hesaplarla sınırlandırın. Yönetici, geliştirici ve destek rollerinin aynı arşive sınırsız erişmesine izin vermeyin; erişim kayıtlarını da ayrıca izleyin.
5. Logları aktarım sırasında koruyun ve depolama alanında şifreli tutun. Şifreleme anahtarlarını loglarla aynı erişim sınırında veya aynı yedek içinde bulundurmayın.
6. Saklama süresini tanımlayın ve süresi dolan kayıtları kurumun imha politikasına göre yönetin. İnceleme kanıtını, zorunlu saklama kaydını ve gerekli yedeği körlemesine silmeyin; yedekteki kopyalar için erişim ve yaşam döngüsü ayrıca planlanır. “Sonsuza kadar saklama” yalnızca teknik olarak kolay olduğu için seçilmemelidir.
7. Değişiklikten sonra merkezi log aramasında temsili test işaretçilerinin sızıp sızmadığını kontrol edin. Gerçek sırrı arama sorgusuna yapıştırmak yeni arama/audit kaydı yaratabilir; gerçek olay incelemesinde değeri ifşa etmeyen dar ve yetkili yöntem kullanın. Beklenen sonuç, hassas değerin görünmemesi; güvenli olay kimliği ve maskelenmiş alanların görünmesidir. Bir sır bulunursa ilgili kimlik bilgisini geçersizleştirin veya yenileyin, kopyalandığı log hedeflerini belirleyin ve erişimi daraltın.

Somut örnek: istek logu​

Bir kullanıcı giriş isteği için ham kaydın şöyle olduğunu varsayalım: POST /[email protected] ve gövdede parola, Cookie başlığında oturum değeri bulunuyor. Bu kaydı olduğu gibi yazmak yerine olay; istek yöntemi, yolun hassas sorgu parametreleri çıkarılmış biçimi, durum kodu, süre, genel istemci bilgisi ve rastgele bir istek kimliğiyle oluşturulmalıdır. E-posta teşhis için gerçekten gerekiyorsa kısmen maskelenebilir; parola, çerez ve erişim belirteci kayda hiç girmemelidir.

Kontrolde log araması parola veya token değerini döndürüyorsa filtre yanlış yerde çalışıyor ya da başka bir bileşen ham isteği kaydediyordur. Sadece uygulama logunu düzeltmek yetmez; proxy, hata izleme servisi, konteyner çıktısı ve yedekler de incelenmelidir. Temiz sonuç alındığında aynı testi hata veren istekler ve başarısız kimlik doğrulama akışı için tekrarlayın.

Sık yapılan hatalar​

• “Loglara yalnız yöneticiler erişiyor” diyerek sırları açık bırakmak. Yetkili bir hesabın ele geçirilmesi hâlinde log arşivi doğrudan saldırı kaynağına dönüşebilir.
• Parolayı maskelediği hâlde Authorization başlığını veya çerezleri kaydetmek.
• Üretimde ayrıntılı hata ayıklama modunu açık bırakmak ve istek gövdesini otomatik kaydetmek.
• Merkezi log sistemini temizleyip uygulama sunucusu, yedek veya hata izleme kopyalarını kontrol etmemek.
• Kişisel veriyi maskeleyip uzun süre saklamak. Maskeleme, gereksiz saklama ve aşırı erişim sorunlarını ortadan kaldırmaz.

Sık sorulan sorular​

Loglar şifreliyse herkesin erişebilmesi sorun olur mu?​

Evet. Şifreleme yetkili okuma erişimini kendiliğinden sınırlamaz; çözme anahtarı ve log arayüzü aynı geniş yetkiyle sunuluyorsa hassas içerik yine görülebilir. Arşiv, arama arayüzü ve anahtar erişimini ayrı denetleyin.

Kullanıcının gönderdiği metin log satırını bozabilir mi?​

Satır sonu ve ayraç karakterleri yapılandırılmamış kayıtta sahte satır veya alan üretebilir. Güvenli yapılandırılmış loglama ve alan kodlaması kullanın; bunu hassas değer filtrelemesinden ayrı sınayın. Maskeleme yapan filtrenin hata yolunda ham gövdeyi tekrar yazmadığını da kontrol edin.