Zopio

Finansal altyapıda denetim kaydı neyi kanıtlamalıdır?

Her şeyi loglamak denetim kanıtı oluşturmakla aynı şey değildir. Finansal altyapı; güvenlik açısından hassas ve finansal olarak anlamlı aksiyonları değiştirilebilir uygulama loglarına veya operatör hafızasına bağlı kalmadan yeniden kurabilecek kalıcı kayıtlara ihtiyaç duyar.

01

Kullanıcıyı, aksiyonu, hedefi ve sonucu kaydet

İyi bir denetim olayı; işlemi yapan kişiyi, kimlik doğrulama bağlamını, yapılan işlemi, hedef kaynağı, zamanı, ilgili istek bilgisini ve sonucu tanımlar. Bir değişiklik yapıldıysa neyin değiştiğini yeniden kurabilecek önce/sonra bilgisi veya değişmez referans korunmalıdır.

02

Ayrıcalıklı ve politika değiştiren aksiyonları kapsa

Yönetici erişimi, rol değişikliği, kimlik bilgisi değişikliği, yapılandırma değişikliği ve finansal davranışı etkileyen aksiyonlar açık kapsama ihtiyaç duyar. PCI DSS Requirement 10 örneğin kart verisi ortamındaki erişim ve güvenlikle ilgili faaliyetlerin kaydedilmesini ve izlenmesini öne çıkarır.

03

Denetim kanıtını koru

Aksiyonu yapan kişi kaydı sessizce değiştirebiliyorsa denetim kanıtı değer kaybeder. Risk modeline uygun ekleme odaklı kayıt yapısı, saklama kontrolleri, bütünlük koruması ve sınırlandırılmış yönetici erişimi kullanılmalıdır.

04

İnceleme sırasında sorgulanabilir hale getir

Operasyonel soruları hızlı cevaplayamayan uyumlu bir arşiv pratikte zayıf kanıttır. Tanımlayıcılar ve ilişkilendirme alanları, inceleme yapan kişinin müşteri, ödeme, API anahtarı, kullanıcı veya yapılandırma değişikliğinden ilgili olay zincirine ilerlemesini sağlamalıdır.

05

Hangi olayların denetim kanıtı gerektirdiğini belirleyin

Uygulama logları hata ayıklama için, denetim kayıtları ise hesap verebilirlik için optimize edilir. Her hata ayıklama olayı uzun süre saklanmak zorunda değildir; her denetim olayı da ayrıntılı hata izi gerektirmez. Erişimi, yapılandırmayı, finansal durumu, güvenlik duruşunu veya kanıtı değiştiren aksiyonları belirleyin. Bu olaylar tutarlı şema ve risk ya da regülasyon ortamına uygun saklama süresi gerektirir.

Örnekler rol ve yetki değişiklikleri, API anahtarı yaşam döngüsü, ödeme aktarımı veya iade onayı, yönlendirme politikası değişikliği, hassas veriye erişim, yapılandırma istisnası, oturum açma ve güvenlik olayları ile yönetici aksiyonlarını içerir. Kesin liste ürüne göre değişebilir; ancak geliştiricinin tesadüfen logladığı olaylardan ibaret olmamalıdır.

06

Yetkilendirmeyi yeniden kuracak kadar bağlam kaydedin

'Kullanıcı 123 bir ayarı değiştirdi' bilgisi tek başına yeterli değildir. İnceleme yapan kişi hangi kiracının, hesabın, politikanın ve kaynağın etkilendiğini görebilmelidir. Kullanıcı kimliği, gerektiğinde kimlik doğrulama yöntemi, kiracı bağlamı, aksiyon, hedef, kritik özellikler, sonuç ve ilişkilendirme kimliği kaydedilmelidir. Politika temelli sistemlerde aksiyona neden izin verildiğini açıklamak için politika veya yapılandırma sürümü de kritik olabilir.

Denetim kaydına gereksiz hassas veri koymayın. Kanıt aksiyonu açıklamalı, ancak ödeme kimlik bilgilerinin veya kişisel verinin ikinci ve kontrolsüz bir kopyasına dönüşmemelidir. Yeterli hesap verebilirlik sağlıyorsa referans, hash veya maskelenmiş gösterim kullanın.

07

Bütünlüğü ve yönetici ayrımını koruyun

Sıradan uygulama yöneticisi denetim izini kanıt bırakmadan değiştirebiliyor veya silebiliyorsa kayıt zayıftır. Sessiz değişikliği zorlaştıran yazma yolları ve saklama kontrolleri kullanın, saklama politikası yönetim yetkisini sınırlandırın ve denetim sisteminin kendisi üzerinde yapılan yönetici aksiyonlarını da kaydedin. Koruma seviyesi riske göre değişebilir; temel prensip aynıdır: kanıt, kanıtladığı aksiyondan daha kolay değiştirilememelidir.

Saklama politikası açık olmalıdır. Sınırsız saklama gizlilik ve depolama riskini büyütür; yetersiz saklama ise incelemeyi zayıflatır. Süreleri düzenleyici, sözleşmesel ve operasyonel ihtiyaçlarla hizalayın ve istisnaları belgeleyin.

08

Olay yaşanmadan önce inceleme sorgularını tasarlayın

Bir inceleme ekibinin 'bu yönlendirme kuralını kim değiştirdi, hangi işlemler etkilendi, kullanıcı o sırada yetkili miydi?' veya 'olay sırasında bu kiracıya hangi yönetici erişti?' diye soracağını varsayın. Bu sorular yapılandırılmamış logların manuel olarak birleştirilmesini gerektiriyorsa denetim modeli operasyonel olarak olgun değildir.

Olası incelemelere göre ilişkilendirme kimlikleri ve indeksli alanlar tanımlayın. Böylece denetim izi yalnız teknik olarak var olan bir arşiv değil, makul sürede cevap üretebilen çalışan bir kontrol haline gelir.

09

Denetim sisteminin kendisini de izleyin

Denetlenebilirlik pasif saklama değildir. Loglama hatası, veri alım boşluğu, olay hacminde beklenmeyen düşüş, saklama yapılandırması değişikliği ve denetim deposuna ayrıcalıklı erişim için uyarılar üretin. İncelenen olay sırasında kanıt üretmeyi bırakan sistem, normal çalışma süresi metriğinin yakalamadığı bir kontrol arızası yaratır.

Temsili olayların geri getirilebildiğini ve geçmişin yeniden kurulabildiğini düzenli olarak test edin. Kanıt kalitesi gerçek bir denetim veya güvenlik olayı buna ihtiyaç duymadan önce doğrulanmalıdır.

Pratik çıkarımlar

Kimin ne yaptığını, hangi kaynağa hangi bağlamla yaptığını ve sonucu kaydet.

Ayrıcalık ve politika değişikliklerini temel denetim olayı olarak ele al.

Denetim kanıtını sessiz değişikliklere karşı koru.

Yalnız saklama için değil gerçek inceleme için ilişkilendirme alanları tasarla.

Birincil kaynaklar