Finans Uygulamalarında Erişim Kayıtları Nasıl Planlanır?

Finans uygulamalarında erişim kayıtları, bir olay yaşandığında ilk bakılan yerdir: Bu müşteri kaydını kim, ne zaman ve hangi yetkiyle görüntüledi? Bu soruya dakikalar içinde yanıt veremeyen bir ekip, hem olay incelemesinde hem de denetimde zorlanır. Sorun çoğu zaman log tutulmamasından değil, loglamanın ihtiyaçlar netleşmeden, geliştirmenin sonunda eklenmesinden kaynaklanır. Bu yazıda KVKK ve denetim gereksinimlerini analiz aşamasında nasıl ele alacağınızı, erişim kayıtları, saklama süreleri ve raporlama ihtiyaçlarını nasıl netleştireceğinizi ve bunları mimariye nasıl yansıtacağınızı adım adım anlatıyoruz.

01Erişim kayıtları neden analiz aşamasında planlanmalı?

Erişim kaydı, uygulamaya sonradan eklenen bir özellik gibi görünse de aslında bir mimari karardır. Hangi servisin hangi olayı üreteceği, kayıtların nerede toplanacağı ve kimlerin okuyabileceği; veri modelini, servis sınırlarını ve altyapıyı etkiler. Bu kararlar canlıya yakın bir zamanda alınırsa üç sorun çıkar:

• Bazı modüller kayıt üretmez; örneğin toplu dışa aktarma ekranı atlanır.
• Kayıt biçimleri servisten servise değişir ve birleştirilemez.
• Saklama süresi ve erişim yetkisi belirsiz kaldığı için kayıtlar ya erken silinir ya da gereğinden uzun tutulur.

Finans tarafında KVKK, BDDK, MASAK ve PCI DSS gibi çerçeveler aynı projede bir araya gelebilir. Her birinin kayıtlardan beklentisi farklıdır. Bu nedenle analiz aşamasında şu üç soruyu yazılı olarak yanıtlayın: Hangi olayı kaydetmeliyiz? Ne kadar süre saklamalıyız? Kayıtlardan hangi raporları üretmemiz gerekecek? OPEIS olarak bu başlıkları, proje başında loglama, erişim kayıtları, veri saklama süreleri ve raporlama gereksinimlerini çıkaran bir analiz çalışmasıyla ele alır ve sonucu mimariye dahil ederiz.

02Hangi olaylar kaydedilmeli, kayıtta hangi alanlar bulunmalı?

Her şeyi kaydetmek de hiçbir şeyi kaydetmemek kadar sorunludur. Çok fazla kayıt, önemli olayı bulmayı zorlaştırır ve gereksiz kişisel veri yığını oluşturur. Başlangıç için olayları risk düzeyine göre gruplayın:

• Kimlik ve oturum olayları: başarılı ve başarısız girişler, çok faktörlü doğrulama adımları, oturum kapanışları.
• Yetki olayları: rol atama ve kaldırma, yetki yükseltme, yönetici paneli işlemleri.
• Veri erişim olayları: müşteri kaydının görüntülenmesi, değiştirilmesi, silinmesi ve özellikle toplu dışa aktarılması.
• Finansal işlem olayları: işlem oluşturma, onaylama, iptal ve limit değişiklikleri.
• Sistem olayları: yapılandırma değişiklikleri, kayıt altyapısının kendi durumu, kayıt silme veya durdurma girişimleri.

Her kayıtta aynı çekirdek alanlar bulunmalıdır; böylece farklı servislerin kayıtları tek sorguda birleştirilebilir:

1. Kullanıcı veya servis hesabı kimliği ve rolü
2. İşlem türü (görüntüleme, değiştirme, silme, dışa aktarma)
3. Etkilenen kaydın türü ve teknik kimliği (içeriği değil)
4. Zaman damgası (tek ve senkronize bir saat kaynağından)
5. Kaynak cihaz, IP ve oturum numarası
6. Sonuç (başarılı, reddedildi, hata)
7. Varsa gerekçe veya talep numarası

Burada kritik bir denge vardır: Erişim kaydı kişisel veriyi korumak için tutulur, yeni bir kişisel veri deposuna dönüşmemelidir. Parola, kart numarası ve kimlik numarasının tamamı gibi alanlar kayda yazılmamalı; gerekirse maskelenmiş veya teknik kimlik olarak tutulmalıdır. Ödeme tarafında kart verisini kendi sistemlerinizde hiç tutmamak, hem PCI DSS kapsamını daraltır hem de kayıtların temiz kalmasını sağlar.

03Saklama süreleri ve raporlama ihtiyaçları nasıl netleştirilir?

Saklama süresini adım adım belirleyin

Tek bir süreyi tüm kayıtlara uygulamak pratik görünür, ancak kayıt sınıflarının dayanakları farklıdır. Şu sırayı izleyebilirsiniz:

1. Kayıt envanteri çıkarın: kimlik olayları, veri erişim olayları, işlem kayıtları ve sistem kayıtlarını ayrı sınıflar olarak listeleyin.
2. Her sınıf için dayanağı yazın: KVKK kapsamındaki saklama ve imha politikanız, sektör düzenlemeleri ve sözleşme yükümlülükleri.
3. Süreleri hukuk ve uyum ekibinizle teyit edin: Süre rakamlarını geliştirme ekibi tahminle yazmamalı; her süre için karşılığında bir dayanak bulunmalı.
4. Katman belirleyin: yakın dönem kayıtları hızlı sorgulanabilir ortamda, eski kayıtlar daha ucuz ve salt okunur arşivde tutulabilir.
5. İmhayı tasarlayın: süre dolduğunda silme işlemi otomatik, kendisi de kayıt altına alınan bir iş olmalıdır.

Raporları baştan yazılı soru olarak tanımlayın

Raporlama ihtiyacı belli değilse hangi alanın kayda yazılacağı da belli olmaz. Denetçinin, uyum biriminin ve güvenlik ekibinin soracağı soruları analiz toplantısında listeleyin. Örnekler:

• Belirli bir müşteri kaydına son dönemde kimler erişti?
• Bir kullanıcının yetkisi ne zaman, kim tarafından değiştirildi?
• Mesai dışında yapılan toplu dışa aktarmalar hangileri?
• Başarısız giriş denemeleri hangi hesaplarda yoğunlaştı?
• Bir veri ihlali şüphesinde etkilenen kayıt kümesi hangi kullanıcıların erişimiyle sınırlı?

Son soru özellikle önemlidir. Veri ihlali bildirim sürecinde zaman kısıtlıdır; hangi verinin kimler tarafından görüldüğünü hızlı gösterebilmek, değerlendirmenizin kalitesini doğrudan etkiler. Her soru için yanıtlayacak kayıt alanını, sorgu sıklığını ve raporu kimin okuyacağını not edin.

04Güvenlik gereksinimleri mimariye nasıl yansıtılır?

Analizde çıkan gereksinimler belge olarak kalırsa işe yaramaz; mimari ve kabul kriterlerine dönüşmelidir. Aşağıdaki başlıklar, finans uygulamalarında sık kullanılan karşılıklardır:

• Merkezi kayıt toplama: Tüm servisler ortak bir şemayla kayıt üretir ve tek bir toplama katmanına gönderir. Böylece bir kullanıcının izi servisler arasında sürülebilir.
• Değiştirilemezlik: Kayıtlar yalnızca eklenebilir, salt okunur arşive taşınabilir bir yapıda tutulur. Uygulama yöneticisi bile kayıtları silememelidir.
• Kayıtlara erişimin kendisi de kayıt altında: Kayıtları kimin okuduğu, sorgu yaptığı veya dışa aktardığı izlenir; kayıt okuma yetkisi rol bazlı ve dar tutulur.
• Saat senkronizasyonu: Servisler aynı zaman kaynağını kullanır; aksi hâlde olay sıralaması güvenilmez olur.
• Uyarı kuralları: Toplu dışa aktarma, yetki yükseltme ve yoğun başarısız giriş gibi olaylar için bir SIEM veya izleme aracında kurallar tanımlanır.
• Maskeleme katmanı: Kişisel veri alanları kayıt üretilirken, kayıt altyapısına ulaşmadan önce maskelenir.

Gereksinimleri test edilebilir yazmak da fark yaratır. Örnek bir kabul kriteri şöyle olabilir: Müşteri bakiyesi görüntülemesi, kullanıcı kimliği ve gerekçe alanıyla birlikte kaydedilir; kayıt ilgili raporda sorgulanabilir. Bu cümle test planına girer, kod incelemesinde kontrol edilir ve sürüm öncesinde doğrulanır. Güvenliği tasarımın parçası olarak ele almak; tehdit modellemesi, güvenli kodlama standartları ve kod incelemesiyle birlikte yürüyen bir yaklaşımdır ve erişim kayıtları bu zincirin görünür çıktısıdır.

05Sık sorulan sorular

Uygulama logu ile erişim kaydı aynı şey midir?

Hayır. Uygulama logu çoğunlukla hata ayıklama için üretilir ve teknik ayrıntı içerir. Erişim kaydı ise kimin hangi veriye, hangi yetkiyle ve ne zaman eriştiğini gösteren, denetim amaçlı ve yapılandırılmış bir kayıttır. İkisini ayrı akışlarda ve ayrı saklama kurallarıyla yönetmek daha sağlıklıdır.

Kayıtlarda kişisel veri tutmak KVKK açısından sorun yaratır mı?

Kayıtlar kişisel veri içerebilir ve bu durumda KVKK ilkeleri bu kayıtlar için de geçerlidir. Bu yüzden veri minimizasyonu esas alınmalı; mümkün olduğunda teknik kimlik ve maskelenmiş değer kullanılmalı, kayıtlara erişim rol bazlı sınırlanmalı ve saklama süresi gerekçelendirilmelidir. Kesin değerlendirme için hukuk danışmanınızla çalışmanızı öneririz.

Saklama süresine kim karar vermeli?

Karar tek bir ekibe ait değildir. Hukuk ve uyum birimi dayanağı belirler, güvenlik ekibi soruşturma ihtiyacını değerlendirir, BT ekibi maliyet ve teknik uygulanabilirliği ortaya koyar. Analiz toplantısında üç tarafın aynı masada olması ve kararın yazılı bir kayıt sınıfı tablosuna dönüşmesi en güvenli yoldur.

06Sonuç

Erişim kayıtları, olay yaşandıktan sonra eklenecek bir araç değil, analiz aşamasında planlanması gereken bir mimari bileşendir. Hangi olayı kaydedeceğinizi, her kayıt sınıfını ne kadar süre ve hangi dayanakla saklayacağınızı ve hangi raporları üreteceğinizi baştan yazarsanız, geliştirme ve denetim süreçleri daha öngörülebilir ilerler. Finans projelerinizde KVKK ve denetim gereksinimlerini birlikte ele almak için Siber Güvenlik hizmet sayfamızı inceleyebilirsiniz.