Halk sağlığı ve enfeksiyon kontrolünde en katı kurallar cerrahi ameliyathaneler ve Biyogüvenlik Seviye-4 (BSL-4) karantina laboratuvarları için geçerlidir. Burada hava akışı HEPA filtrelerle sürekli süzülür, odadaki pozitif basınç dışarıdan tek bir toz zerresinin içeri girmesini engeller, içeri giren personelin kıyafetleri sterilize edilir ve her yüzey düzenli olarak kimyasal tahlillerden geçer. Şimdi bir kasabın ya da sokak satıcısının, semt pazarındaki açık tezgahının ortasında açık kalp ameliyatı yapmaya kalkıştığını düşünün. Üstelik İl Sağlık Müdürlüğü'ne dilekçe verip "Ben burada ameliyat yapacağım, bana acilen uluslararası laminar hava akışı ve BSL-4 sterilizasyon sertifikası düzenleyin" diye talepte bulunursa ne olur? Komik bile olmayan bir akıl tutulması yaşanır.

Türkiye'deki bilişim ve e-ticaret ekosisteminde de durum farksızdır. Yıllık 100-200 TL'ye (veya 5-10 dolara) satın aldığı paylaşımlı hosting (shared hosting) paketine WooCommerce veya OpenCart kuran bir işletme sahibinin; bankalardan doğrudan Sanal POS entegrasyonu alırken karşısına çıkan PCI-DSS (Payment Card Industry Data Security Standard) denetim anketini görünce hosting firmasına destek bileti açması bu sahnenin kusursuz bir kopyasıdır:

"Bankam benden PCI-DSS Seviye 1 uyumluluğu, TLS 1.3 zorunluluğu, özel IP, sunucu kök erişim logları ve zafiyet tarama raporu istiyor. Sunucunuz bu standartları karşılıyor mu? Acilen PCI belgenizi gönderin, posumuz onaylanmadı!"


PCI-DSS Nedir ve Ne İster?

Visa, MasterCard, American Express, Discover ve JCB konsorsiyumu tarafından kurulan PCI Güvenlik Standartları Konseyi (PCI SSC), kredi kartı verilerinin saklandığı, işlendiği veya iletildiği tüm sistemler için acımasız ve tavizsiz kurallar koyar.

Temel şartlar şunlardır:

  1. Güvenli Ağ ve Sistemler: Güvenlik duvarı (firewall) yapılandırması, satıcı tarafından sağlanan varsayılan şifrelerin (default passwords) asla kullanılmaması.
  2. Kart Sahibi Verilerinin Korunması: Saklanan verilerin şifrelenmesi (AES-256), genel ağlar üzerinden iletilen kart verilerinin güçlü kriptografiyle korunması (TLS 1.2+).
  3. Zafiyet Yönetim Programı: Sistemlerin güncel anti-virüs yazılımlarıyla taranması, tüm yazılım ve işletim sistemi yamalarının düzenli olarak uygulanması.
  4. Sıkı Erişim Kontrol Önlemleri: Veriye erişimin iş gereksinimlerine göre sınırlandırılması (Role-Based Access Control), her erişim için benzersiz bir kullanıcı kimliği tanımlanması, çok faktörlü kimlik doğrulama (MFA).
  5. Ağların Düzenli Olarak İzlenmesi ve Test Edilmesi: Tüm ağ kaynaklarına ve kart verilerine erişimin günlük loglarının tutulması ve logların değiştirilemez bir SIEM sunucusuna aktarılması.

Şimdi bu kuralları alın ve yıllık 100 TL'lik bir paylaşımlı Linux sunucusunun gerçekleriyle yan yana koyun.


Paylaşımlı Hosting Mimarisi: Umumi Koğuş Gerçeği

Paylaşımlı hosting, tek bir fiziksel sunucu üzerinde (örneğin Dual Xeon, 128 GB RAM) 500 ila 2.000 farklı web sitesinin aynı işletim sistemini, aynı web sunucusunu (Apache/LiteSpeed), aynı MySQL sunucusunu ve aynı ortak IP adresini paylaştığı bir umumi koğuş modelidir.

+------------------------------------------------------------------------+
|                 TEK BİR PAYLAŞIMLI FİZİKSEL SUNUCU                     |
|                                                                        |
|  [Sizin 100 TL'lik Siteniz]   [Komşu: Korsan Dizi Sitesi]              |
|  (WooCommerce - Sanal POS)    (Sürekli Telif & DDOS Saldırısı Alıyor)  |
|                                                                        |
|  [Komşu: Hacklenmiş WordPress] [Komşu: Günde 50.000 Spam Mail Atan]   |
|  (Web Shell Yüklü, Port Tarıyor) (IP'yi Kara Listelere Sokuyor)        |
|                                                                        |
|------------------------------------------------------------------------|
|     ORTAK KAYNAKLAR: Tek Kernel, Tek MySQL Soketi, Tek Ağ Arayüzü      |
|     GÜVENLİK SINIRI: Yalnızca CloudLinux CageFS & Chroot İzolasyonu    |
+------------------------------------------------------------------------+

Bu ortamda PCI-DSS standartlarını sağlamak mantıken ve fiziksel olarak imkânsızdır:

1. Kök Düzeyinde Loglama ve İzleme İmkânsızlığı

PCI-DSS, sunucuya kimin hangi saatte ne amaçla girdiğinin auditd seviyesinde loglanmasını ister. Paylaşımlı sunucuda müşteriye SSH veya sudo yetkisi verilemez. Müşteri sunucunun güvenlik duvarı kurallarını veya kernel loglarını göremez; çünkü görürse diğer 1.000 komşu sitenin de verilerini görmüş olur.

2. Paylaşımlı IP ve Ortak Portlar

Aynı IP adresini kullanan diğer bir müşterinin sitesi zafiyet içeriyorsa, üçüncü taraf bir güvenlik tarama aracı (ASV - Approved Scanning Vendor) IP adresini taradığında 80, 443, 21, 25 gibi ortak portlarda zafiyet raporlar. Komşunuzun güncellenmemiş eski PHP script'i yüzünden sizin PCI-DSS taramanız kırmızı alarm verip başarısız (Fail) olur.

3. Kaynak İzolasyonu ve Yan Kanal Saldırıları (Side-Channel)

CloudLinux CageFS gibi teknolojiler kullanıcıları kendi chroot kafeslerine hapseder; ancak aynı çekirdeği (kernel) paylaşan bir sistemde bellek tabanlı Spectre/Meltdown tarzı yan kanal açıklarına veya yerel yetki yükseltme (local root privilege escalation) risklerine karşı %100 garanti verilemez. Kart hamili verisinin aktığı bir sunucuda bu risk kabul edilemez.


Esnafın İsyanı ve Yanılgı: "Hosting Firması İlgisiz!"

Bankanın gönderdiği 12 sayfalık Güvenlik Açığı Raporu'nu (ASV Scan Report) alan müşteri destek talebini açar:
"Sunucunuzda port 21 FTP açık görünüyor, derhal kapatın! OpenSSL sürümü eskiymiş, güncelleyin! Bize PCI sertifikanızı verin!"

Hosting firmasının teknik destek mühendisi yanıt verir:
"Sayın müşterimiz, hesabınız paylaşımlı hosting paketindedir. Port 21 diğer 800 müşterimizin dosya transferi için aktiftir, tek bir müşteri için kapatılamaz. Bu sunucu PCI-DSS sertifikasyonuna tabi değildir; sözleşmemizde kart saklama veya PCI uyumluluğu taahhüdü yer almamaktadır. PCI uyumluluğu için izole bir Cloud/Dedicated sunucuya geçmeli ve gerekli mimariyi kendiniz kurmalısınız."

Müşteri hiddetlenir: "Ben sizden site barındırma aldım, güvenli değil misiniz yani?! Benim sitemden kart çekilemeyecek mi?!"


Klinik Çözüm: Ortak Ödeme Sayfası (Hosted Payment Page)

Burada asıl anlaşılması gereken şey, küçük bir işletmenin kredi kartı bilgilerini kendi sunucusuna ASLA temas ettirmemesi gerektiğidir.

Eğer altyapınız için ayırabileceğiniz bütçe yıllık 100 TL ise, bankanın Doğrudan API (Direct POST / Merchant Host) modelini kullanamazsınız. Kullanmamalısınız da. Çünkü doğrudan API modelinde müşteri kredi kartı numarasını, son kullanma tarihini ve CVV kodunu sizin web sitenizdeki form kutucuğuna yazar. Form verisi sizin sunucunuzdaki PHP script'ine düşer, oradan cURL ile bankaya gönderilir. Kart verisi o 100 TL'lik sunucunun RAM'inden ve işlemcisinden geçer! O sunucu hacklenirse veya sayfaya bir JavaScript enjeksiyonu (Magecart saldırısı) yapılırsa, çalınan milyonlarca liralık kartın hukuki sorumluluğu tamamen işletmeye aittir.

Doğru Reçete: Ortak Ödeme / iframe Modeli

Küçük ve orta ölçekli işletmeler için doğru mimari şudur:

  • Iyzico, PayTR, ParamPOS veya Bankanın Ortak Ödeme Sayfası:
    Müşteri "Ödeme Yap" dediğinde kart bilgilerini sizin sitenizde girmez. Ya güvenli bir iframe içinde ya da doğrudan BDDK ve PCI-DSS Seviye 1 sertifikalı ödeme kuruluşunun kendi sunucusuna yönlendirilir.
  • Kart bilgisi sizin sunucunuzun kablosuna bile değmez. Ödeme işlemi ödeme kuruluşunun BSL-4 standartlarındaki steril veri merkezinde tamamlanır; sitenize sadece "Ödeme Başarılı - Referans No: 918239" şeklinde bir webhook yanıtı döner.
  • Bu senaryoda işletme, PCI-DSS formunda en hafif seviye olan SAQ A (Self-Assessment Questionnaire A) formunu doldurur: "Ben kart verisine dokunmuyorum, tüm işlemi lisanslı kuruluşa devrettim" der ve hiçbir sunucu denetimine girmeden onay alır.
+------------------------------------------------------------------------+
|                      MİMARİ DOĞRU ÇÖZÜM: SAQ-A                         |
|                                                                        |
|  Müşteri Sitenize Gelir (100 TL'lik Hosting)                           |
|       │                                                                |
|       ▼ "Ödeme Yap" Butonu                                             |
|  [Doğrudan PCI-DSS Seviye 1 Kuruluşun Güvenli Havuzuna Yönlendirilir]  |
|  (Kart bilgisi İyzico / PayTR / Banka Ortak Sayfasında Girilir)        |
|       │                                                                |
|       ▼                                                                |
|  Kart çekilir, onaylanır.                                              |
|       │                                                                |
|       ▼ Sitenize Yalnızca Başarı Kodu Döner:                           |
|  [Siteniz: "Siparişiniz Alındı!"]                                      |
|                                                                        |
|  SONUÇ: Kart verisi 100 TL'lik sunucuya HİÇ DEĞMEDİ. Güvenlik: %100   |
+------------------------------------------------------------------------+

Sonuç

Toplu taşıma otobüsüyle Formula 1 yarışına katılamazsınız; katılamadığınız için de belediye otobüsü şoförünü "Neden pit-stopta lastik değiştirmiyorsun" diye azarlayamazsınız.

Paylaşımlı hosting; kişisel bloglar, portföy siteleri ve basit kurumsal tanıtım sayfaları için maliyet-etkin harika bir çözümdür. Ancak finansal verilerin, kredi kartı işlemlerinin ve regülasyona tabi kritik altyapıların koşulacağı bir mecra değildir. Kredi kartı verisiyle çalışacaksanız ya bütçenizi izole mimarilere (Dedicated/VPC) göre planlayacak ve profesyonel sistem mühendisliği alacaksınız; ya da haddinizi bilip kart verisine el sürmeden işi lisanslı ödeme geçitlerine devredeceksiniz.