PCI DSS test verisi konusu, çoğu ekibin ilk bakışta atladığı bir gerçeği barındırır: kart verisiyle çalışan bir test ortamı, üretim kadar ciddi kurallara tabidir. Bu yazıda standardın test süreçlerine nasıl dokunduğunu, hangi verilerin yetkilendirmeden sonra saklanamayacağını, maskeleme ve jetonlaştırmanın ne işe yaradığını ve sentetik verinin neden zorunlu hâle geldiğini bulacaksınız.
PCI DSS nedir ve test verisiyle ilişkisi nedir?
PCI DSS, kart kuruluşları tarafından belirlenen ve kart verisini işleyen, ileten veya saklayan bütün kuruluşları bağlayan bir veri güvenliği standardıdır. Banka olmak gerekmez; bir e-ticaret sitesi işletmek, bir ödeme sayfası geliştirmek veya kart verisinin geçtiği bir sistemin parçası olmak standardın kapsamına girmek için yeterlidir.
Standardın önemli bir özelliği, kapsamın üretim ortamıyla sınırlı olmamasıdır. Kart verisinin bulunduğu her sistem, o verinin nerede kullanıldığına bakılmaksızın kapsama girer. Test ortamı, eğitim ortamı, demo ortamı; hepsi aynı soruyla karşı karşıyadır: burada gerçek kart verisi var mı? Varsa, üretimdeki koruma düzeyi burada da geçerlidir.
Bu yüzden “burası yalnızca test, bir şey olmaz” yaklaşımı savunulabilir bir yaklaşım değildir. Test ortamları tipik olarak daha az izlenir, erişim yetkileri daha geniştir ve ekran görüntüleri ekip içinde serbestçe paylaşılır. Kart verisi için en riskli yerlerin başında tam olarak buralar gelir.
Test ortamları neden uyum kapsamındadır?
Bir test ortamının üretimden farkı, verinin gerçek olup olmamasıdır; güvenlik gereksinimlerinin geçerli olup olmaması değildir. Gerçek kart verisi test ortamına kopyalandığı anda, o ortam kart verisi işleyen bir sistem hâline gelir ve standardın bütün ilgili maddelerine tabi olur.
İkinci neden daha pratiktir: test ortamları genellikle üretimden alınmış veri kopyalarıyla doldurulur. Bu, veritabanı göçlerini, arama davranışını ve raporları gerçekçi biçimde denemek için yapılır. Ancak üretimden alınan bir kopyada kart numaraları da bulunur. Kopyalama işlemi bir kez yapıldığında kart verisi artık iki yerde yaşar ve ikinci yerdeki koruma seviyesi genellikle daha düşüktür.
Üçüncü neden, geliştiricinin günlük çalışma biçimidir. Test sırasında hata ayıklamak için istek ve yanıtlar kaydedilir, tarayıcı geliştirici araçları açık bırakılır, ekran görüntüleri alınır. Bu kayıtların hiçbiri kart verisi içermemelidir; içeriyorsa uyum ihlali doğmuş demektir.
Yetkilendirmeden sonra hangi veriler saklanamaz?
Standardın bu konudaki maddesi oldukça nettir: hassas kimlik doğrulama verileri, yetkilendirme işleminden sonra saklanamaz. Bu gruba kartın güvenlik kodu ve manyetik şeridin tam verisi girer. Şifreli saklama da kuralı değiştirmez; yasak, verinin kendisine yöneliktir.
Buna karşılık hesap verisi, yani kart numarası ve son kullanma tarihi gibi bilgiler belirli koşullarla saklanabilir. Koşulların başında verinin korunması ve gösterim sırasında maskelenmesi gelir. Yaygın uygulama, numaranın yalnızca baştaki belirli sayıda ve sondaki dört basamağını göstermek, aradaki kısmı gizlemektir. Böylece kullanıcı hangi kartı kullandığını anlar ama numaranın tamamı ekranda görünmez.
Bu ayrımı bir tabloyla özetleyelim.
| Veri türü | Yetkilendirme sonrası saklanabilir mi? | Not |
|---|---|---|
| Güvenlik kodu | Hayır | Şifreli saklama da yasaktır |
| Manyetik şeridin tam verisi | Hayır | Aynı kapsamdadır |
| Kart numarası | Koşullu | Korunmalı ve gösterimde maskelenmelidir |
| Son kullanma tarihi | Koşullu | Hesap verisi kapsamındadır |
| Kart sahibinin adı | Koşullu | Aynı koruma yükümlülüğüne tabidir |
| Sağlayıcı tarafından üretilen referans | Evet | Jetonlaştırma bu referansı kullanır |
Maskeleme, jetonlaştırma ve sentetik veri
Bu üç yaklaşım, kart verisini yönetmenin farklı seviyelerine karşılık gelir ve birbirinin alternatifi değil, tamamlayıcısıdır.
Maskeleme, veriyi olduğu gibi tutup yalnızca gösterimini sınırlar. Uygulaması en kolay yöntemdir, ancak veri hâlâ sistemde durur; erişim yetkisi olan biri onu görebilir.
Jetonlaştırma, kart numarasının yerine ödeme hizmeti sağlayıcısının ürettiği bir referansı kullanır. Numara sizin sisteminize hiç girmez; yalnızca referans tutulur. Bu yaklaşım, saklama yükümlülüğünün büyük kısmını sağlayıcıya devreder ve kapsamı daraltır.
Sentetik veri ise test ortamı için üretilmiş kurgusal veridir. Gerçek bir kartı temsil etmez, hiçbir hesaba bağlı değildir ve kaybolduğunda kimseye zarar vermez. Geliştirme ve test ortamlarında kullanılması gereken veri türü budur.
Gerçek kart verisi test ortamına nasıl sızar?
Sızma genellikle kötü niyetle olmaz; alışkanlıklardan doğar. En sık görülen yollar şunlardır: üretim veritabanının maskelenmeden kopyalanması, hata ayıklama amacıyla tutulan tam istek kayıtları, ekran görüntüleriyle paylaşılan ödeme ekranları, test kartı yerine geliştiricinin kendi kartıyla yapılan denemeler ve destek ekibine iletilen müşteri kayıtları.
Bu listenin ortak noktası, hiçbirinin kasıtlı bir ihlal olmamasıdır. Bu yüzden sorunu yalnızca eğitimle çözmek mümkün değildir; teknik bariyerler gerekir. Üretimden veri kopyalayan bir sürecin, kopyalama sırasında hassas alanları otomatik olarak kaldırması veya değiştirmesi gerekir. Kayıt tutan katmanların, kart numarası ve güvenlik kodu içeren alanları kaydetmeden önce sansürlemesi gerekir.
Uyumlu test verisini nereden bulurum?
Test ortamı için tek doğru kaynak, sentetik veridir. Sitemizdeki sahte kredi kartı numarası üretici, tam olarak bu ihtiyaç için tasarlanmıştır: istediğiniz kart ağından, istediğiniz adette test numarası üretir ve her numara yalnızca yapısal olarak geçerlidir. Üretilen numaraların hiçbiri gerçekte piyasaya sürülmemiştir, hiçbir hesaba bağlı değildir ve gerçek bir ödeme için kullanılamaz; bu nedenle test ortamınızda saklanmalarında bir sakınca yoktur. Araç şu adreste: test kredi kartı numarası üretici.
Ürettiğiniz veriyi test kayıtlarını doldurmak için kullanabilir, gerçek veriye hiç ihtiyaç duymadan bütün akışları deneyebilirsiniz. Saklama yasağının ayrıntılarını CVV rehberinde bulabilirsiniz.
Geliştiriciler için: saklama, maskeleme ve ortam ayrımı
İlk kural, saklanmaması gereken veriyi hiç toplamamaktır. Güvenlik kodu veri modelinde bir alan olarak yer almasın; yalnızca yetkilendirme isteğine eklenip gönderilsin. Alan yoksa yanlışlıkla kaydedilmesi de mümkün olmaz.
İkinci kural, kayıt katmanında sansür uygulamaktır. İstek ve yanıt gövdelerini kaydeden ara katmanlar, ödeme uç noktalarını tanıyıp hassas alanları maskeleyerek yazmalıdır. Hata izleme araçlarına gönderilen bağlam nesneleri de aynı süzgeçten geçmelidir. Bu süzgeci tek bir noktada uygulamak, farklı ekiplerin farklı davranmasını engeller.
Üçüncü kural, test verisinin üretim verisinden türetilmemesidir. Test ortamını doldurmak için üretimden kopya almanız gerekiyorsa, kopyalama sürecinin bir parçası olarak hassas alanları kurgusal değerlerle değiştirin. Bu işlemi elle yapmak sürdürülebilir değildir; sürece gömülü ve tekrarlanabilir olmalıdır.
Dördüncü kural, ortam ayrımıdır. Test ve üretim anahtarları, veritabanları ve erişim yetkileri birbirinden ayrı olsun. Geliştiricinin üretim kart verisine erişmesi gerekiyorsa bu erişim kayıt altına alınmalı ve gerekçelendirilmelidir; varsayılan durum erişimin kapalı olmasıdır.
Beşinci kural, düzenli denetimdir. Test ortamında saklanan kayıtları belirli aralıklarla tarayarak hassas alanların sızıp sızmadığını kontrol edin. Bu taramayı otomatik hâle getirin; elle yapılan denetimler ilk yoğun dönemde unutulur.
Sonraki adımlar
Uyumluluk tarafını netleştirdikten sonra sıradaki adım, sentetik veriyle uçtan uca test yapmaktır. Hangi durumların sınanacağını ödeme formu test listesi adım adım sıralıyor; test setinizi kurmak için test kredi kartı numaraları yazısına göz atabilirsiniz. Kendi verinizi hemen üretmek için üreticiyi açıp birkaç numara almanız yeterli.