PCI DSS'te Veritabanı Tarafı: Hangi Kontroller Sizi Bağlar?

Kart ödeme standardına tabi bir kurumda uygulama, ağ ve şifreleme tarafı genellikle olgun olur. Denetimde sürtünme çıkan yer çoğu zaman veritabanı operasyonudur: kim üretime betik geçirdi, kim veri çekti, o erişim neye dayanıyordu ve bunu nasıl gösteriyorsunuz. Bu yazı, standardın dört gereksiniminin veritabanı tarafındaki karşılığını ve tipik bulguları anlatıyor.

Kart Verisi Ortamında Veritabanı Nerede Duruyor

Kart verisi ortamı, kart verisini saklayan, işleyen veya ileten her bileşeni kapsar. Veritabanı bu tanımın tam merkezindedir ve genellikle üç ayrı sıfatla birden kapsama girer: veriyi saklar, veriye erişim noktasıdır ve üzerinde çalışan her betik veriyi değiştirebilir.

Buradan çıkan pratik sonuç şudur: uygulama katmanı için kurduğunuz kontrollerin veritabanı katmanında da bir karşılığı olması beklenir. Uygulamada kod incelemesi ve dağıtım kaydı varsa, veritabanında da değişikliğin kaydı ve onayı beklenir.

Gereksinim 6: Değişiklik Güvenli Yönetilir

Standardın altıncı gereksinimi güvenli sistem geliştirme ve bakımı üzerinedir; içindeki değişiklik yönetimi başlığı, tüm sistem bileşenlerindeki değişikliklerin güvenli biçimde yönetilmesini ister. "Tüm sistem bileşenleri" ifadesi veritabanını da kapsar ve pratikte şu dördü aranır: değişikliğin etkisinin belgelenmesi, yetkili taraflarca onaylanması, işlevsel test ve geri alma planı.

Veritabanı tarafında bu dördünün en zayıf halkası genellikle geri alma planıdır. Uygulama sürümünde geri alma önceki paketi yeniden dağıtmaktır ve kolayca gösterilir. Veritabanında ise geri alma planı çoğu zaman "yedekten döneriz" cümlesinden ibarettir. Bir denetçi bunu sorduğunda ikinci soruyu da sorar: bu planı en son ne zaman denediniz ve dönüş süresi neydi.

İkinci zayıf halka onayın kapsamıdır. Uygulama sürümü onaylanmıştır ama o sürümün içinde giden veritabanı betiği ayrıca değerlendirilmemiştir. Onay sürüme verildiğinde veritabanı değişikliği görünmez hale gelir.

Gereksinim 7: Bilmesi Gereken Kadar Erişim

Yedinci gereksinim, sistem bileşenlerine ve kart verisine erişimin iş gereksinimiyle sınırlanmasını ister. Veritabanı tarafında bu, iki ayrı soruya dönüşür ve ikincisi çoğu kurumda cevapsızdır.

Birinci soru: Hangi hesabın hangi tabloya erişim yetkisi var? Bu cevaplanabilir; veritabanının kendi yetki tabloları vardır.

İkinci soru: Yetkisi olan kişi geçen ay kart verisine kaç kez, hangi iş gerekçesiyle eriştti ve çektiği veri şu anda nerede? Yetki listesi bu soruyu cevaplamaz. Yetki, erişebilme olasılığını gösterir; gerçek erişimin gerekçesini göstermez. "Bilmesi gereken kadar" ilkesi olasılıkla değil, gerçekleşen erişimle ölçülür.

Gereksinim 8: Benzersiz Kimlik ve Atıf

Sekizinci gereksinim, kullanıcıların tanımlanması ve erişimin doğrulanması üzerinedir. Kritik nokta şudur: standart paylaşılan hesabı topyekun yasaklamaz, atfedilemeyen kullanımı yasaklar. Bir eylem bir kişiye bağlanabiliyorsa mekanizma kabul edilebilir.

Veritabanı operasyonunda burada iki ayrı kimlik vardır ve karıştırılmamaları gerekir:

Toplantıda kurulacak doğru cümle şudur: uygulama havuz hesabını bölmeye çalışmayın, o mimari bir tercihtir. Odaklanılması gereken yer, insanların elle kullandığı hesaplardır. Kişisel yönetici hesabı olmadan çalışan bir düzende, işlem kimliği kayıt katmanından gelir ve atıf boşluğu kapanır.

Gereksinim 10: Erişimin Kaydı ve İzlenmesi

Onuncu gereksinim, sistem bileşenlerine ve kart verisine yapılan tüm erişimin kaydedilmesini ve izlenmesini ister. Kurumların çoğu bu gereksinimi bir log toplama meselesi olarak okur ve veritabanı denetim kaydını açar, bir izleme aracı kurar, logları merkezi bir platforma akıtır. Bu doğru bir uygulamadır ve gereklidir.

Eksik kalan kısım logun kendisi değil, logun bütünlüğü ve anlamıdır. Denetçi iki şey sorar. Birincisi: bu kaydın değiştirilmediğini nasıl gösteriyorsunuz? Kaydı tutan sistemin yöneticisi aynı zamanda kayıt üreten kişiyse, bu soru kolay cevaplanmaz. İkincisi: bu erişim izinli miydi? Log bu soruyu cevaplayamaz çünkü izin kararı loga hiç ulaşmaz.

Veritabanı Tarafında En Sık Çıkan Dört Bulgu

• Onay sürüme verilmiş, veritabanı değişikliği ayrıca değerlendirilmemiş. Sürüm kaydı vardır ama içindeki betiğin ne yaptığına dair bir değerlendirme yoktur.
• Geri alma planı yazılı değil veya hiç denenmemiş. "Yedekten döneriz" bir plan değil, bir umuttur.
• Üretimden veri çekme talepleri kayıtsız. Destek veya analiz için alınan dosyanın gerekçesi, alıcısı ve saklama süresi yoktur.
• Acil müdahalelerin sonradan değerlendirmesi tamamlanmamış. Kayıt açılmıştır, değerlendirme adımı hiç kapanmamıştır ve bekleyeni sayan bir yer yoktur.

Denetçinin İsteyeceği Kanıt

Denetim gününde istenen şey bir politika belgesi değil, tek bir olay üzerinden yürüyen bir zincirdir. Kurumunuzun bunu ne kadar sürede toparladığını ölçün:

• Rastgele seçilmiş bir üretim değişikliğinin betiği, hangi kurala göre riskli sayıldığı ve kimin onayladığı.
• Çalışan metnin onaylanan metinle aynı olduğunun kanıtı.
• Aynı dönemde kart verisi içeren bir tablodan yapılmış bir okumanın gerekçesi, maskeleme kararı ve teslim adresi.
• Bu kayıtların üretildikten sonra değiştirilmediğinin, kaydı tutan ekipten bağımsız olarak gösterilmesi.
• Geçen çeyrekte reddedilen taleplerin listesi. Sıfırsa kontrolün eleme yaptığı gösterilemez.

Bu beş maddeyi dakikalar içinde tek bir kayıttan gösterebiliyorsanız veritabanı tarafı denetime hazırdır. Farklı sistemlerden ekran görüntüsü toplayarak gösteriyorsanız, hazırlık her denetimde yeniden ödenen bir maliyettir.