Hızlı Cevap

Hızlı cevap: Otel ödeme pentesti, POS cihazlarıyla sınırlı olmayan bir değerlendirmedir; rezervasyon, tahsilat, iade, uzaktan destek ve ağ ayrımı birlikte incelenir. PCI DSS kapsamı, kart verisinin gerçek akışına ve ortamın güvenliğini etkileyebilen sistemlere göre belirlenmelidir. Banka veya ödeme sağlayıcısı kullanmak bütün otel süreçlerini kendiliğinden kapsam dışına çıkarmaz. Testin teslimatı, doğrulanmış bulgularla sorumluluk ve düzeltme haritası olmalıdır.

Misafir resepsiyonda kartını okutur, restorandaki hesabını odasına yazdırır, ayrılırken konaklama ve ek hizmetleri birlikte öder. Başka bir misafir internetten ön ödeme yapmış, şirket müşterisi ise finans ekibinin gönderdiği bağlantıyla tahsilata yönlendirilmiştir. Bu işlemlerin hepsine “otel ödemesi” denir; fakat aynı teknik yoldan geçmezler.

Ödeme güvenliği değerlendirmesinde ilk hata, otelde görülen POS cihazlarını sayıp kapsamın tamamlandığını düşünmektir. Asıl çalışma, işlemin hangi sistemde başladığını, nerede doğrulandığını ve hangi kayıtla eşleştiğini ortaya koyar. Bu makaledeki tablolar oteller için önerilen çalışma örnekleridir; tek başına PCI DSS uygunluk belgesi veya değerlendirme formu değildir.

Ödeme haritası neden cihaz listesinden daha değerlidir?

Bir resepsiyon bilgisayarı kart numarası saklamıyor olabilir. Buna rağmen ödeme yönetim paneline erişiyor, iade işlemi başlatıyor veya sanal POS yapılandırmasını değiştirebiliyor olabilir. Aynı şekilde teknik servis hesabının yalnızca “destek” amacı taşıması, ödeme ortamına etkisinin olmadığı anlamına gelmez.

Harita hazırlanırken normal tahsilatın yanında istisnalar da görüşülmelidir: rezervasyon değişikliği, iptal, kısmi iade, depozito, gecikmiş tahsilat ve ödeme uyuşmazlığı. Otelde bunların hangileri gerçekten uygulanıyorsa kapsam o akışlara göre şekillenir. Kullanılmayan bir ödeme modelini varsaymak, gerçek riskten dikkat çalar.

Oteldeki akış Açıklığa kavuşturulacak konu Kapsam görüşmesindeki sorumlu
Resepsiyon tahsilatı Terminal, bilgisayar ve ağ bağımlılığı Finans ve bilgi işlem
Restoran veya spa hesabı Oda hesabı ile kart tahsilatı arasındaki ilişki Operasyon ve finans
Web rezervasyonu Yönlendirme, gömülü form veya farklı entegrasyon E ticaret ve yazılım ekibi
Ödeme bağlantısı Bağlantının üretimi, alıcısı ve işlem eşleşmesi Rezervasyon ve finans
İade ve iptal Onay yetkisi, tutar ve kayıt tutarlılığı Finans
Uzaktan destek Erişilebilen hedefler ve yönetim yetkisi Bilgi işlem ve tedarikçi

Tabloyu doldurmak için gerçek kart bilgilerini rapora taşımak gerekmez. Akış şeması, sağlayıcı belgeleri ve hassas veri içermeyen işlem örnekleri çoğu kapsam sorusunu açıklığa kavuşturabilir. Belirsiz kalan alanlar, açık bir doğrulama işi olarak listelenmelidir.

PCI DSS kapsamı ile pentest kapsamı nasıl ilişkilidir?

PCI DSS, ödeme kartı verisinin korunmasına yönelik teknik ve operasyonel gereksinimler sunar. Kart verisini saklayan, işleyen veya ileten ortamlarla bu ortamın güvenliğini etkileyebilen bileşenler kapsam değerlendirmesinde önemlidir. PCI SSC'nin standart açıklaması bu çerçeveyi tanımlar.

Otel için hazırlanacak pentest kapsamı, gerçek ödeme mimarisiyle eşleştirilmelidir. Hangi sistemin neden dahil edildiği, hangisinin hangi gerekçeyle ayrı tutulduğu yazılır. Uygulanacak doğrulama yolu ve değerlendirme beklentisi, otelin çalıştığı ödeme kuruluşu ve gerekiyorsa uygun yetkinlikteki değerlendiriciyle netleştirilir.

Burada iki çıktı birbirine karıştırılmamalıdır. Pentest raporu belirli kontrollerin sınandığını ve belirli bulguların ortaya çıktığını gösterir. Otelin bütün PCI DSS gereksinimlerini karşıladığını tek başına kanıtlamaz. Genel kavramlar için DSET ödeme kartı güvenliği rehberi tamamlayıcı bir okumadır.

Ayrı banka sayfası ile gömülü ödeme formu aynı mı?

Hayır. Misafirin ödeme sağlayıcısının ayrı sayfasına yönlendirilmesi ile otel sayfasına gömülü ödeme formu farklı teknik düzenlerdir. Hangi kodun hangi sayfada çalıştığı ve otel sitesindeki bir değişikliğin ödeme akışını nasıl etkileyebileceği ayrı değerlendirilir.

PCI SSC FAQ 1588, SAQ A kapsamındaki belirli betik saldırısı uygunluk ölçütünün gömülü ödeme sayfası veya formu kullanan e ticaret düzenleriyle ilgili olduğunu, yönlendirme modellerine aynı ölçütün uygulanmadığını açıklar. Bu ayrım, yönlendirmeli bir otel sitesinde başka güvenlik sorumluluğu kalmadığı anlamına gelmez.

Pentest açısından otel ekibinin hazırlaması gereken şey, entegrasyonun gerçek çizimidir. “Ödemeyi banka alıyor” açıklaması yeterince ayrıntılı değildir. Ödeme başlatma, dönüş adresi, işlem durumu ve rezervasyon kaydı arasındaki ilişki görünür olmalıdır. Ticari rezervasyon kurallarının sınanması ayrıca otel rezervasyon pentesti kapsamında ele alınır.

Ağ ayrımı bir çizimde değil, erişim sonucunda doğrulanır

Ödeme cihazlarının ayrı bir ağda bulunması iyi bir başlangıç olabilir. Ancak “ayrı VLAN” ifadesi, bütün gereksiz erişimlerin kapandığını kanıtlamaz. Ağın gerçekten hangi bağlantılara izin verdiği, ilgili iş ihtiyacıyla karşılaştırılmalıdır.

Örnek test matrisi, misafir ağı, genel personel ağı ve destek bağlantısından ödeme yönetim alanına ulaşım durumunu ele alabilir. Her yol için beklenen davranış önceden yazılır. Bazı iletişimler iş gereği meşru olabilir; bu nedenle “hiçbir şey erişmemeli” gibi belirsiz bir beklenti yerine hedef ve hizmet bazında karar verilir.

Kontrol iki yönlü düşünülmelidir. Kapsam dışı olduğu düşünülen bir bilgisayarın ödeme sunucusuna erişimi kadar, yönetim sistemlerinin bu bilgisayar üzerinde kullandığı ortak kimlikler de önem taşıyabilir. Teknik sonuç, incelenen yol için kanıt üretir; bütün ağın tüm koşullarda ayrıldığını göstermesi için kapsam ve örnekleme yeterliliği ayrıca açıklanmalıdır.

Bu bölüm, mevcut misafir Wi-Fi ve segmentasyon rehberini ödeme sınırı açısından tamamlar. Misafir ağının korunması ile ödeme kapsamının doğru belirlenmesi ilişkili, fakat aynı iş değildir.

POS yönetiminde tedarikçi erişimi nasıl sınanır?

Ödeme kesintisinde hızlı destek almak önemlidir. Fakat arıza sırasında açılan geçici erişimin aylarca kalması, operasyon kolaylığını kalıcı güvenlik varsayımına dönüştürebilir. Test, tedarikçi hesabının yalnızca gerekli hedefe ulaşmasını, görev süresi sonunda erişimin sonlanmasını ve işlemlerin bir kişiye bağlanabilmesini değerlendirmelidir.

Canlı terminale agresif tarama uygulamak yerine önce üretici koşulları, cihaz modeli ve yönetim yolu belirlenir. Bankaya veya sağlayıcıya ait bileşenler için izin ve koordinasyon ayrıca düzenlenir. Değerlendirme tekniği, cihazın ve ödeme hizmetinin özelliklerine göre seçilir.

Tedarikçi yöneticisi için kullanılan hesabın, otel genelindeki başka sistemlerde de yönetici olması gerekiyorsa bu ihtiyaç belgelenmelidir. Gerekmiyorsa gereksiz erişimin kaldırılması bir düzeltme adayıdır. Grup otellerde konu daha geniştir; tesisler arası erişim ve tedarikçi pentesti ayrıca incelenmelidir.

Tahsilat güvenliği kadar iade yetkisi de önemlidir

Bir çalışan kart verisini hiç görmeden yanlış iade veya hatalı tahsilat eşleşmesi oluşturabilir. Bu, kart verisi gizliliğiyle aynı sorun değildir; fakat otelin finansal güvenliği açısından test edilmesi gereken ayrı bir iş kuralıdır.

Finans ekibiyle birlikte iade başlangıcı, onay, tutar ve işlem eşleşmesi tanımlanır. Yetkisi olmayan kullanıcının işlem yapamaması kadar, yetkili kullanıcının yanlış rezervasyona işlem uygulayamaması da değerlendirilir. Testlerde sağlayıcının deneme ortamı veya açıkça ayrılmış kontrollü kayıtlar kullanılır.

Örnek bir kabul ölçütü şu olabilir: “Rezervasyon görevlisi iade talebi açabilir; finans rolü onay vermeden iade tamamlanmaz ve tutar ilgili işlemin kayıtlı sınırlarını aşmaz.” Bu bütün oteller için zorunlu bir model değildir. Otelin benimsediği görev ayrımının ölçülebilir hale getirilmesidir.

Ödeme testinde kanıt nasıl toplanmalı?

Kanıt, kusuru göstermek için gereken en küçük bilgiyle oluşturulmalıdır. Rapora gerçek kart bilgisi, tam misafir kaydı veya gereksiz işlem dökümü eklemek, raporun kendisini yeni bir hassas veri deposuna çevirebilir. Sentetik işlem kimlikleri, maskelenmiş ekranlar ve sistem günlüklerinden seçilmiş ilgili kayıtlar kullanılabilir.

Test hesabı, işlem zamanı, kaynak sistem ve beklenen sonuç belirtilirse teknik ekip bulguyu daha kolay değerlendirir. Aynı zamanda raporda neyin gözlenmediği yazılır. Ödeme panelinin görünmesi, kart verisinin alındığını; bir terminale ağ erişimi, tahsilatın değiştirilebildiğini göstermez.

Rapor ifadesi Yeterli kanıt için aranacak ayrım
Yönetim ekranına erişim var Yalnızca görüntüleme mi, oturum açma mı?
Yetki sınırı aşıldı Hangi rol hangi kontrollü işlemi yapabildi?
Ödeme durumu tutarsız Hangi kayıtlar ve zamanlar farklılaştı?
Ağ ayrımı yetersiz Hangi başlangıç noktasından hangi hedefe erişildi?
Sorun giderildi İlk senaryo ve ilgili meşru akış yeniden kontrol edildi mi?

Raporun sonundaki imha ve teslim süreci de baştan kararlaştırılmalıdır. Finans ve bilgi işlem ekipleri aynı bulgunun farklı bölümlerini kullanabilir; her ekibe gerekli bilgi verilmesi, bütün ham kanıtın kontrolsüz paylaşılmasını gerektirmez.

Düzeltme planı nasıl hazırlanır?

Her bulgu için otelin yapacağı iş ile sağlayıcının yapacağı iş ayrılır. Ağ kuralı otel ekibinin kontrolünde olabilir, ödeme modülü düzeltmesi tedarikçiye bağlı olabilir. Bu ayrım yapılmazsa sorunlar “bankaya iletildi” veya “yazılım firmasına bildirildi” aşamasında belirsiz biçimde bekler.

Kalıcı çözüm gelene kadar uygulanacak kısıtlamanın neyi azalttığı açıkça belirtilir. Örneğin yönetim panelinin erişimini sınırlamak bir maruziyeti azaltabilir; paneldeki uygulama kusurunun giderildiğini göstermez. Son kapanış, düzeltmenin ilgili senaryoda tekrar değerlendirilmesiyle yapılır.

Test sıklığı, ödeme modeli ve uygulanabilir gereksinimlerle birlikte belirlenir. İncelenen mimari değiştiğinde kapsamın yeniden gözden geçirilmesi gerekir. Bu yazı belirli bir otelin bütün ödeme kanalları için otomatik bir takvim veya uygunluk kararı vermez.

KAOS ve DSET yaklaşımı

DSET ile ödeme güvenliği çalışması planlanırken KAOS destekli inceleme, onaylanmış teknik kapsam içinde kullanılmalıdır. Ödeme sağlayıcısının yetki sınırları, finansal iş kuralları ve operasyon sürekliliği uzman koordinasyonu gerektirir. Çıktı, araç puanından çok hangi riskin hangi kanıtla doğrulandığını açıklamalıdır.

Kapsam görüşmesine ödeme kanalı listesi, sağlayıcı bilgileri, görev rolleri ve ağ bağlantı haritasıyla gelmek faydalıdır. Böylece resepsiyon, finans, bilgi işlem ve dış sağlayıcılar aynı sorumluluk haritası üzerinde çalışabilir.

Sık Sorulan Sorular

POS cihazı bankaya aitse otelin test edeceği bir alan kalır mı?

Otelin ağ bağlantıları, yönetim erişimi, personel rolleri ve rezervasyonla ödeme eşleşmesi değerlendirme konusu olabilir. Bankaya ait cihaz veya altyapının test yöntemi ayrıca koordine edilir. Cihaz sahipliği, otelin bütün iş akışlarının güvenli olduğunu tek başına göstermez.

Her otel aynı PCI DSS değerlendirmesine mi tabidir?

Ödeme akışı, kullanılan entegrasyon ve ilgili ödeme kuruluşunun beklentisi farklı olabilir. Bu nedenle aynı tesis türü veya benzer oda sayısı, aynı doğrulama yolunu otomatik olarak belirlemez. Kapsam gerçek mimari üzerinden netleştirilmelidir.

Başarılı pentest raporu PCI DSS uygunluğu anlamına gelir mi?

Pentest, kapsamındaki güvenlik kontrolleri için teknik kanıt sağlar. PCI DSS değerlendirmesi daha geniş teknik ve operasyonel unsurlar içerir. Bu nedenle bir pentest raporu tek başına bütün gereksinimlerin karşılandığını gösteren belge olarak sunulmamalıdır.

Kaynaklar

  1. PCI SSC: PCI DSS standardı ve kapsam çerçevesi
  2. PCI SSC FAQ 1588: SAQ A ve gömülü ödeme formunda betik güvenliği
  3. PCI SSC: PCI DSS v4.0.1 ve resmî doküman kütüphanesi
  4. DSET: Ödeme kartı güvenliği rehberi

Otelinizin ödeme altyapısı için kanıta dayalı test kapsamını Ankara Hacettepe Teknokent merkezli DSET ile hazırlamak üzere DSET ile iletişime geçin.