Denetim kayıtları ve uygulama logları, güvenliğin vazgeçilmez araçlarıdır. Bir olayı geriye dönük incelemek, hatayı ayıklamak ya da şüpheli bir davranışı tespit etmek için ayrıntılı kayıtlara ihtiyaç duyulur. Ancak bu kayıtların kendisi de bir veri deposudur ve çoğu zaman uygulamanın ana veritabanı kadar özenle korunmaz. Log dosyaları farklı sunuculara kopyalanır, izleme araçlarına gönderilir, hata ayıklama sırasında ekip içinde paylaşılır ve uzun süre saklanır.
Bu nedenle kayıtlara ne yazıldığı, en az kayıtların varlığı kadar önemlidir. Bir müşterinin kimlik numarası, bir kullanıcının parolası ya da bir sigorta şirketi bağlantısının erişim belirteci log satırlarına düştüğünde, veritabanındaki tüm koruma önlemleri arka kapıdan aşılmış olur. Bu yazıda log hijyeni kavramını ve acente yazılımı açısından uygulanabilir kuralları ele alıyoruz.
Loglar neden hassas veri biriktirir?
Hassas verinin loglara sızması çoğu zaman bilinçli bir karar değil, gözden kaçan bir ayrıntıdır. Tipik sızıntı yolları şunlardır:
- İsteğin tamamını kaydetmek: Hata ayıklamayı kolaylaştırmak için gelen her isteğin gövdesi loglanır; bu gövdede giriş formundaki parola veya teklif formundaki kimlik bilgisi bulunabilir.
- Hata mesajları: Bir doğrulama hatası, kullanıcının girdiği değeri mesajın içine ekleyerek log'a yazar.
- Adres satırındaki parametreler: Kimlik numarası veya plaka gibi değerler sorgu parametresi olarak gönderildiğinde, web sunucusu erişim kayıtlarına otomatik olarak düşer.
- Entegrasyon yanıtları: Sigorta şirketi servislerinden dönen yanıtların tamamı kaydedildiğinde, müşteri bilgileri ve teklif ayrıntıları da log'a girer.
- Başlıklar ve belirteçler: Yetkilendirme başlıkları ve oturum çerezleri kaydedildiğinde, log'u okuyan biri bu belirteçlerle oturum açabilir.
Asla yazılmaması gerekenler
Bazı veri türleri, hangi gerekçeyle olursa olsun log'a yazılmamalıdır:
- Parolalar, tek kullanımlık doğrulama kodları ve kurtarma kodları
- Oturum çerezleri, erişim ve yenileme belirteçleri
- API anahtarları ve sigorta şirketi portal kimlik bilgileri
- Şifreleme anahtarları ve sertifika özel anahtarları
- Kart numarası ve benzeri ödeme bilgileri
Maskelenerek yazılabilecekler
Bazı bilgiler olay incelemesi için gerekli olabilir, ancak tam halleriyle tutulmaları gerekmez:
- Kimlik numarası: Yalnızca son haneler veya geri döndürülemez bir özet değer.
- Telefon ve e-posta: Kısmen maskelenmiş biçim.
- Plaka ve adres: Teklif akışının hangi kayıt için çalıştığını anlamaya yetecek ölçüde, tercihen kayıt kimliği üzerinden dolaylı referans.
- IP adresi: Güvenlik incelemesi için değerlidir; saklama süresi ve erişimi sınırlandırılmalıdır.
En sağlıklı yaklaşım, log'a hassas değerin kendisi yerine kaydın sistem içindeki kimliğini yazmaktır. "Müşteri kaydı 48213 güncellendi" bilgisi, inceleme yapan yetkiliye ilgili kaydı panel üzerinden yetkisi dahilinde açma imkanı verir; log dosyasını okuyan biri ise müşteri hakkında bir şey öğrenmez.
Denetim izi ile teknik log arasındaki ayrım
Denetim izi, kimin hangi işlemi ne zaman yaptığını gösteren, iş açısından anlamlı kayıtlardır. Teknik loglar ise uygulamanın çalışmasına dair ayrıntılar içerir. İkisini aynı yerde ve aynı kurallarla tutmak sorun yaratır. Denetim izi daha uzun saklanır ve yetkili yöneticilere açıktır; teknik loglar daha kısa saklanır ve yalnızca teknik ekibin erişimindedir. Bu ayrım, her iki kayıt türü için de doğru saklama ve erişim kurallarının uygulanmasını kolaylaştırır.
Uygulanabilir log hijyeni kuralları
- İzin listesi kullanın: Neyin yazılmayacağını listelemek yerine, hangi alanların yazılabileceğini tanımlayın. Yeni eklenen bir alan, varsayılan olarak log dışında kalır.
- Merkezi maskeleme uygulayın: Loglama altyapısında parola, belirteç ve kimlik numarası gibi örüntüleri otomatik olarak maskeleyen bir katman bulunsun.
- Hassas değerleri adres satırında taşımayın: Kimlik numarası ve benzeri veriler sorgu parametresi yerine istek gövdesinde gönderilmeli.
- Hata ayıklama modunu canlıda kapatın: Ayrıntılı loglama gerekiyorsa sınırlı süre ve kapsamla açılmalı, iş bitince kapatılmalıdır.
- Saklama süresi belirleyin: Teknik loglar gereğinden uzun tutulmamalı; süresi dolan kayıtlar otomatik silinmelidir.
- Log erişimini sınırlayın: Log dosyalarına ve izleme araçlarına erişim, ana veritabanı kadar sıkı kontrol edilmelidir.
- Düzenli tarama yapın: Loglar dönemsel olarak hassas veri örüntüleri için taranmalı; bulunan sızıntıların kaynağı düzeltilmelidir.
Geliştirme sürecine yerleştirmek
Log hijyeni, yazılım geliştirme sürecinin olağan bir kontrol adımı haline geldiğinde kalıcı olur. Kod incelemelerinde yeni eklenen log satırlarının hangi verileri içerdiğine bakılması, otomatik testlerde örnek bir parola veya kimlik numarasının log çıktısında görünüp görünmediğinin denetlenmesi ve yeni bir entegrasyon eklendiğinde hangi yanıt alanlarının kaydedileceğinin açıkça kararlaştırılması bu adımın parçalarıdır. Teklif motoru gibi trafik, kasko ve DASK için ayrı akışlarla çalışan bileşenlerde her akışın kendi log kuralları ayrıca gözden geçirilmelidir; çünkü her akışın taşıdığı kişisel veri türü farklıdır. Böylece sorun, canlı ortamda ortaya çıkmadan önce yakalanır.
Ekip içinde paylaşılan hata ekran görüntüleri ve log alıntıları da aynı özeni hak eder. Bir hatayı bildirmek için log satırlarını mesajlaşma kanalına yapıştıran geliştirici, farkında olmadan müşteri verisini başka bir ortama taşıyabilir. Paylaşımdan önce maskeleme yapılması ve mümkünse yalnızca olay kimliğinin paylaşılması iyi bir alışkanlıktır.
Bir sızıntı fark edildiğinde
Loglarda parola veya belirteç gibi bir verinin bulunduğu fark edildiğinde, yalnızca ilgili satırları silmek yeterli değildir. Etkilenen parolalar ve belirteçler geçersiz kılınmalı, logların kopyalandığı tüm yerler belirlenmeli, sızıntıya yol açan kod düzeltilmeli ve olay kayıt altına alınmalıdır. Kişisel veri içeren bir sızıntı söz konusuysa, yükümlülüklerin değerlendirilmesi için hukuk danışmanına başvurulmalıdır.
Az ama doğru kayıt
İyi bir log, olayı anlamaya yetecek kadar bilgi içeren ama okuyan kişiye gereğinden fazlasını göstermeyen kayıttır. Bu dengeyi kurmak geliştirme sürecinin bir parçası olmalı, sonradan yapılan bir temizlik işine dönüşmemelidir. CRM işlemlerinizin ve acente yazılımındaki kullanıcı hareketlerinin nasıl kaydedildiğini görmek için demo talebi oluşturabilirsiniz.