PCI DSS Veri Akış Diyagramı: Kart Sahibi Verilerini Haritalama ve Kapsamı Daraltma

Bir PCI DSS değerlendirmesi genellikle aynı istekle başlar: kart verisinin nereye gittiğini gösterin. Wiki'nizdeki diyagramda servisler ve oklar vardır, ama hangi okun kart numarası taşıdığı, hangisinin yalnızca token taşıdığı ya da analitik veri ambarının neden kapsam dışı olduğu görünmez. Bu olmadan her sistem bir kapsam tartışmasına dönüşür.

Bu yazı PCI DSS v4.0.1'in ne istediğini, kapsam kategorilerini, barındırılan ödeme alanlarıyla çalışan bir ödeme akışı örneğini, token'ları, segmentasyonu, SAQ türlerini ve diyagramın güncel tutulmasını ele alır. Hukuki veya uyumluluk tavsiyesi değildir: neyin geçerli olduğuna acquirer'ınız veya değerlendiriciniz karar verir, resmi metinler PCI SSC Document Library içindedir.

PCI DSS v4.0.1 ne istiyor

Haziran 2024'te yayımlanan PCI DSS v4.0.1, yazının yazıldığı tarihte (Kasım 2026) güncel sürümdür. İleri tarihli gereksinimleri 31 Mart 2025'te zorunlu hale geldi. Üç gereksinim diyagramlarınızı şekillendirir:

Hesap verisi, kart sahibi verisini (PAN, kart sahibi adı, son kullanma tarihi, servis kodu) ve hassas kimlik doğrulama verisini (tam iz verisi, kart doğrulama kodu, PIN ve PIN blokları) kapsar. PAN belirleyici öğedir: onu saklıyor, işliyor veya iletiyorsanız bir kart sahibi verisi ortamınız (CDE) var demektir.

SAQ A ne gereksinim 1'i ne de 12.5.2'yi içerir, SAQ A-EP 1.2.3 ve 1.2.4'ü içerir, SAQ D ve tam değerlendirmeler üçünü de içerir. SAQ A'da bile diyagram, uygunluğunuzun en açık kanıtıdır.

Üç tür sistem

Bölüm 4, gereksinimleri CDE'ye ve “kart sahibi verisinin ve/veya hassas kimlik doğrulama verisinin güvenliğini etkileyebilecek” her şeye uygular; bu ifade v4.0.1'de “CDE'nin güvenliği” ifadesinin yerine geldi. Standardın kendi örneği “bir ödeme formunun veya sayfasının oluşturulmasını kontrol eden bir web sunucusu”dur. PCI SSC'nin kapsam rehberi sistemleri yukarıdan aşağıya kontrol edilen üç kategoriye ayırır:

Bir sistem, uyduğu en yüksek kategoriye aittir. Segmentasyon isteğe bağlıdır, ancak onsuz tüm “düz ağ” kapsama girer ve tek başına şifreleme genellikle kart verisini kapsam dışına çıkarmaz.

Örnek: barındırılan ödeme alanlarıyla bir ödeme akışı

Bir mağaza web uygulaması ödeme sayfasını sunar; kart alanları ödeme sağlayıcısından gelen bir iframe'dir ve sıkça barındırılan alanlar (hosted fields) denir. Bir sipariş servisi ödemeleri tahsil eder, Postgres siparişleri saklar, gece çalışan bir iş veri ambarını besler ve CI/CD mağazayı dağıtır:

1. Tarayıcı ödeme sayfasını yükler; sağlayıcının script'i kart alanlarını kendi iframe'inde oluşturur.
2. Müşteri PAN'ı, son kullanma tarihini ve CVC'yi yazar, tarayıcı bunları TLS ile doğrudan sağlayıcıya gönderir. Same-origin politikası, satıcı sayfasının script'lerini iframe'in dışında tutar.
3. Sağlayıcı PAN'ı kendi vault'unda saklar ve bir token döndürür.
4. Sayfa siparişi ve token'ı sipariş servisine gönderir.
5. Sipariş servisi token'ı sağlayıcının API'si üzerinden bir gizli anahtarla tahsil eder, sağlayıcı da kart ağı üzerinden yetkilendirme ister.
6. Bir webhook sonucu doğrular. Sipariş servisi token kimliğini, kart markasını ve son dört haneyi saklar.

Hiçbir satıcı sistemi PAN'ı saklamaz, işlemez veya iletmez; dolayısıyla satıcının CDE'si yoktur. Kendi değerlendirmesi olan sağlayıcıyı gereksinim 12.8 kapsamında yönetirsiniz. Ödeme ağ geçidi entegrasyon diyagramı aynı ödeme akışını sıralı diyagram olarak gösterir; e-ticaret platformu diyagramı ise onu katalog, sepet ve sipariş servislerinin arasına yerleştirir.

Web uygulaması kapsamda kalır: onu ya da yüklediği bir script'i değiştiren saldırgan iframe'i sahte bir formla değiştirebilir. E-skimming adı verilen bu saldırı, v4.0'ın 6.4.3'ü (ödeme sayfası script'lerini yetkilendirme, bütünlük kontrolü ve envanter) ve 11.6.1'i (ödeme sayfalarındaki değişiklikleri tespit etme) eklemesinin nedenidir. Standart dağıtım araçlarını sistem bileşeni saydığı için CI/CD de kapsamdadır.

Token'lar ve kapsamda bıraktıkları

PCI SSC'nin tokenizasyon kılavuzları, de-tokenizasyon ve PAN depolama dahil tokenizasyon sistemini CDE'ye koyar. Yalnızca token tutan sistemler, PAN token'lardan geri elde edilemiyorsa, de-tokenizasyon isteyemiyor veya vault'a erişemiyorlarsa ve CDE'den segmente edilmişlerse kapsam dışı olabilir.

Vault sağlayıcıya ait olduğundan sipariş servisi ve veritabanı bu şartı karşılayabilir, ancak bir tuzak var: yeniden kullanılabilir bir token ile gizli API anahtarı tahsilat oluşturabilir. Kılavuz, işlem başlatabilen token'ların “PCI DSS kapsamında olabileceğini” söyler ve satıcılara acquirer'larına danışmalarını önerir. Anahtarı herhangi bir production secret gibi koruyun.

Segmentasyon ve nasıl test edilir

Segmentasyon genellikle güvenlik duvarı kuralları, security group'lar veya ayrı bulut hesapları anlamına gelir. Bir CDE'yi izole ediyorsa, gereksinim 11.4.5 bu kontroller için nitelikli, bağımsız bir test uzmanı tarafından en az 12 ayda bir ve değişikliklerden sonra (servis sağlayıcılar için altı ayda bir) sızma testi yapılmasını ister. 1.2.3 ağ diyagramında her segmenti ve aralarındaki kontrolleri, bir mantıksal ağ topolojisinde olduğu gibi çizin.

Burada satıcı CDE'si olmadığından önemli olan sınır, ödeme sayfasını değiştirebilecek her şeyi çevreler: sipariş servisi, veri ambarı ve kimlik bilgileri mağazaya dağıtım yapamamalıdır.

Mimari seçimler ve SAQ türleri

Ödeme tasarımınız, öz değerlendirme anketini (SAQ) büyük ölçüde belirler; acquirer'ınız bunu onaylar:

Ocak 2025 SAQ A revizyonu, 6.4.3 ve 11.6.1'i anketten çıkardı ve bir uygunluk ölçütü ekledi: satıcı “sitesinin, satıcının e-ticaret sistemlerini etkileyebilecek script saldırılarına açık olmadığını” doğrular. FAQ 1588 iki yola izin verir: sayfanızı 6.4.3 ve 11.6.1'dekine benzer tekniklerle korumak ya da sağlayıcınızın, talimatlara uygun uygulandığında çözümünün bunu sağladığını onaylamasını almak. Ölçüt yönlendirmelere değil gömülü iframe'lere uygulanır ve ikisi de bir Approved Scanning Vendor tarafından üç ayda bir tarama gerektirir (FAQ 1604). Kendi sayfanızın oluşturduğu tek bir kart alanı bile SAQ A'yı dışarıda bırakır.

Diyagramı güncel tutmak

Standart, “hesap verisinin akışındaki veya saklanmasındaki her değişikliği” potansiyel olarak önemli sayar. Yeni bir ödeme yöntemi, sağlayıcı veya kanal, bir ödeme sayfası script'i ya da ödeme verisine dokunan bir dışa aktarım, log hattı veya destek aracı eklediğinizde diyagramı güncelleyin.

Destek taleplerinde ve sohbetlerde kart numaralarına dikkat edin: böyle istenmeyen bir kanal için v4.0.1, onu CDE'ye dahil etmenizi ya da veriyi güvenli biçimde silip kanalın bunun için kullanılmasını durdurmanızı söyler. Diyagrama tarihi, yazarı ve onaylayanı yazın; yaşayan dokümantasyon iş akışı sahiplik ve güncelleme tetikleyicilerini ele alır.

Kart sahibi veri akış diyagramı

Nasıl okunur:

• Üç bölge. Kırmızı sağlayıcının CDE'si, amber ödeme sayfasını değiştirebilen satıcı sistemleri, turkuaz yalnızca token işleyen sistemlerdir.
• Renkler veriyi izler: kart verisi kırmızı, token turkuaz, ikisi de değilse gri; kesikli çizgi asenkron demektir.
• Numaralar tek bir satın alımı izler. Kırmızı yol hiçbir satıcı çerçevesine girmez.
• İki not kalan riskleri işaretler: sayfa script'leri ve yeniden kullanılabilir token'lar.
• Gösterge veri sınıflarını ve kapsamı özetler.

PCI DSS veri akış diyagramlarını net çizmek

Her akışı ve depoyu etiketleyin:

• Kapsamı çerçeve olarak çizin ve 1.2.3 rehberinin önerdiği gibi kapsam dışı alanları gölgeleyin.
• Kanal başına bir diyagram çizin: e-ticaret, telefon ve terminaller farklıdır.
• Sessiz yolları ekleyin: iadeler, chargeback'ler, yedekler, loglar ve destek araçları.
• Ağ diyagramıyla eşleştirin; veri akış diyagramı onu tamamlamalıdır.
• Dışarıda bırakın: hesap verisi veya token içermeyen çağrıları.

Sık yapılan bir hata, yalnızca token tutan sistemlerin içinden geçen bir PAN çizgisidir; bu, onları kâğıt üzerinde kapsama çeker. Notasyon için veri akış diyagramı örneklerine, güven sınırları için tehdit modelleme rehberine, benzer bir envanter için GDPR veri haritasına bakın.

Archboard'da oluşturun

1. Google veya GitHub ile giriş yapın ve bir diyagram oluşturun.
2. Müşterinin tarayıcısı için C4 Modeli paketinden bir Person ekleyin.
3. Sağlayıcı (kırmızı), kapsam içi satıcı (amber) ve kapsam dışı satıcı (turkuaz) için Temel paketinden üç Çerçeve node'u ekleyin.
4. Sağlayıcı çerçevesine, barındırılan alanlar ve ödeme API'si için C4 Modeli paketinden iki External System node'u ve Güvenlik paketinden bir Kasa ekleyin. Kart ağları için çerçevenin altına bir External System koyun.
5. Amber çerçeveye web uygulaması için C4 Modeli paketinden bir Container ve DevOps paketinden bir Pipeline ekleyin.
6. Turkuaz çerçeveye sipariş servisi için bir Container, ayrıca Veri paketinden Postgres ve Veri ambarı node'ları ekleyin.
7. Etiketli bağlantılar çizin: kart verisi için kırmızı, token için turkuaz, diğerleri için gri; webhook ve dışa aktarım için kesikli.
8. Temel paketinden bir Markdown göstergesi ve iki Temel Metin notu ekleyin.

1.2.3 ağ diyagramı için Terraform dönüştürücü, .tf dosyalarınızdan ilk taslağı verir; ödeme akışı diyagramı sayfası sıralı görünümleri gösterir.

Örnek 14 diagram node kullanıyor ve Free planın sınırları içinde kalıyor.

SSS

PCI DSS veri akış diyagramı zorunlu mu? Evet. v4.0.1'deki gereksinim 1.2.4, tüm hesap verisi akışlarının güncel tutulan doğru bir veri akış diyagramını ister. SAQ A bunu dışarıda bırakır; SAQ A-EP, SAQ D ve tam değerlendirmeler içerir.

PCI ağ diyagramı ile veri akış diyagramı arasındaki fark nedir? Ağ diyagramı (1.2.3) CDE ile diğer ağlar arasındaki bağlantıları gösterir. Veri akış diyagramı (1.2.4) hesap verisinin nereye gittiğini ve nerede saklandığını gösterir. İkisi uyumlu olmalıdır.

Bir iframe veya barındırılan ödeme sayfası web sitemi PCI kapsamından çıkarır mı? Hayır. Kart verisini sistemlerinizden uzak tutar, ancak iframe'i gömen sayfa yine saldırıya uğrayabilir; bu yüzden SAQ A üç ayda bir ASV taraması ve iframe'ler için script saldırılarına karşı koruma ister.

Yalnızca token saklayan sistemler PCI DSS kapsamı dışında mıdır? Olabilirler: PAN token'lardan geri elde edilemiyorsa ve sistemler tokenizasyon sisteminden segmente edilmişse. İşlem başlatabilen token'lar yine de kapsamda olabilir.

PCI kapsamı ve diyagramlar ne sıklıkla gözden geçirilmeli? Hesap verisi akışları değiştiğinde veri akış diyagramını güncelleyin, kapsamı en az 12 ayda bir ve önemli değişikliklerden sonra (12.5.2), servis sağlayıcılar için ise altı ayda bir doğrulayın.

Ücretsiz başlayın — tek kullanıcı, kredi kartı gerekmez.