Merhaba

Seri: SOC Analistleri İçin Log İzleme Rehberi (Ödeme Kuruluşları)

1. Log İzleme Temelleri
2. Mevzuat, Retention ve Silme Yasağı (Bu Yazı)
3. Windows/AD ve Linux Hardening
4. Uygulama ve Veritabanı Katmanı
5. Ağ Katmanı (Firewall/IDS-IPS/WAF/DDoS)
6. Container ve Kubernetes
7. Bulut (AWS/Azure/GCP)
8. XDR/EDR ve Bütünsel Korelasyon

Ön Not – Kapsam ve Amaç

Bu seri, kritik logları izlemeyi ve anlamayı öğretmek amacıyla yazılmıştır. Odak noktası tek tek ürünler değil, sürecin kendisidir: hangi olayın neden önemli olduğu, nasıl toplandığı, korele edildiği ve korunduğu.

Metindeki donanım, yazılım ve uygulama örnekleri (ürün adları, Event ID’ler, konfigürasyon parametreleri, komutlar) versiyona, sürüme ve yıllara göre değişiklik gösterebilir. Bir ayarın adı değişebilir, bir ürün yaşam döngüsünü tamamlayabilir, yeni bir alternatif ortaya çıkabilir. Bu nedenle örnekleri birebir kopyalanacak reçeteler olarak değil, mantığı kavramak için birer illüstrasyon olarak okuyun; kendi ortamınıza uygularken ilgili üreticinin güncel dokümantasyonunu esas alın.

Aynı şekilde, “Ödeme Kuruluşları İçin PCI DSS, HIPAA ve Türkiye Mevzuatı Bağlamında” hazırlanan bölümler de yürürlükteki düzenlemelere dayanır ve mevzuat değiştikçe güncellenmesi gerekir. PCI DSS sürümleri, TCMB tebliğleri, KVKK/MASAK düzenlemeleri ve retention süreleri zaman içinde değişebilir. Bu rehber hukuki veya denetim danışmanlığı yerine geçmez; nihai uygulama için kurumunuzun uyumluluk ekibine, QSA’sına ve güncel resmi mevzuata başvurun.

Kısacası: amaç, süreci ve mantığı anlamaktır. Örnekler bugünün fotoğrafıdır; ilke ise kalıcıdır.

Serinin ikinci bölümü. Birinci bölümde log kaynaklarının temellerini kurmuştuk. Burada odak, Türkiye’de faaliyet gösteren ödeme kuruluşları: PCI DSS, HIPAA ve ISO 27001 çerçeveleri; 6493, TCMB Bilgi Sistemleri Tebliği, 5651, MASAK ve KVKK’nın birleşik etkisi; tiered retention mimarisi, veri lokasyonu kısıtı ve denetimde en sık kesilen nokta olan silme yasağı.

4. Türkiye Bağlamı – Ödeme Kuruluşlarında Log Yönetimi

Buraya kadar anlattıklarımız uluslararası çerçeveler. Ancak Türkiye’de faaliyet gösteren bir ödeme kuruluşu veya elektronik para kuruluşu, PCI DSS’in çok ötesinde yükümlülükler taşır. Yıllarca regüle bir ödeme kuruluşunda sistem ve ağ yönetimi yaptıktan sonra şunu net söyleyebilirim: bu bölüm, denetimde en çok bulgu çıkan alandır.

4.1. Yasal Dayanak Matrisi

Bağlayıcı süre = en uzunu. Ödeme kuruluşu için tasarım hedefi 10 yıl olmalıdır.

4.2. Ödeme Kuruluşuna Özgü – Mutlaka Loglanacak Olaylar

A. İşlem Katmanı (6493 / TCMB)

• Her ödeme emri: gönderen, alıcı, tutar, para birimi, timestamp, kanal, maskeli IBAN/kart
• İşlem durum geçişleri (initiated → authorized → settled → reversed / refund / chargeback)
• Mutabakat (reconciliation) çalıştırmaları ve farklar
• Limit aşımı, reddedilen işlem ve red sebebi
• Kart/hesap bloke-açma işlemleri
• Fon transferi, cüzdan yükleme/çekme, e-para ihraç/itfa kayıtları

B. Müşteri ve KYC (MASAK)

• Kimlik tespiti (onboarding) adımları ve doğrulama sonuçları
• Yasaklı / PEP / OFAC / BM listesi tarama sonuçları
• Şüpheli İşlem Bildirimi (ŞİB) üretimi ve MASAK’a iletim kaydı
• Sürekli izleme (transaction monitoring) kural tetiklemeleri
• Risk skoru değişimleri

C. Kimlik Doğrulama ve Yetkilendirme

• Tüm login/logout, başarılı ve başarısız (kaynak IP, cihaz, kanal)
• MFA / SCA (Strong Customer Authentication) doğrulama sonuçları
• Şifre/PIN/parola değişimi ve sıfırlama
• Yetki (rol) ataması, kaldırılması, yükseltilmesi
• Privileged / Domain Admin / root oturumları – CyberArk PAM session recording ile eşlenmeli
• Servis hesabı (service account) kullanımı

D. Veri Erişimi (KVKK + PCI DSS 10.2.1.1)

• Müşteri kişisel verisine her erişim (kim, ne zaman, hangi kayıt)
• Kart sahibi verisine (PAN/CHD) her bireysel erişim
• Toplu veri export / rapor alma / veritabanı sorgu logları
• Veri silme, anonimleştirme, imha işlemleri (KVKK imha politikası kanıtı)

E. Sistem ve Altyapı

• Konfigürasyon değişiklikleri (FortiGate policy, AD GPO, K8s manifest, DB schema)
• Sunucu/servis start-stop, servis hesabı değişimi
• Yazılım kurulum, patch, deployment (CI/CD pipeline izleri)
• Yedekleme/geri yükleme işlemleri
• Audit log servisinin durdurulması/başlatılması (PCI 10.2.1.6)
• Audit log’lara erişim (PCI 10.2.1.3)
• Sistem seviyesi nesne oluşturma/silme (PCI 10.2.1.7)

F. Güvenlik Olayları

• FW/IPS/WAF blok ve alarm kayıtları
• DLP ihlal olayları
• AV/EDR tespitleri
• FIM (dosya bütünlüğü) değişiklik alarmları
• Anti-fraud kural tetiklemeleri
• Kritik güvenlik kontrolünün arızalanması (PCI 10.7) – SIEM, FIM, AV veya segmentasyon devre dışı kalırsa derhal alarm

G. Üçüncü Taraf ve API

• Açık Bankacılık / API çağrıları (TPP erişimi, consent verme/iptal)
• Banka, kart şeması, PSP entegrasyon logları
• Outsourcing/tedarikçi uzaktan erişim oturumları

4.3. Her Log Kaydında Zorunlu Alanlar

timestamp        → ISO 8601, UTC + TZ offset, ms hassasiyet
user_id / actor  → gerçek kişi (paylaşılan hesap YASAK)
source_ip        → device_id / channel (web, mobil, API, POS)
event_type       → olay tipi
target_resource  → hesap no, işlem ID, tablo/dosya adı
outcome          → success / failure + hata kodu
correlation_id   → işlem uçtan uca izlenebilmeli

Kural: Loga açık PAN, CVV, PIN, parola, tam TCKN, tam IBAN yazılmaz. Maskeleme (ilk 6 – son 4) veya tokenizasyon zorunludur (PCI DSS 3.3, 3.4).

4.4. Log Güvenliği – Teknik Kontroller

4.5. Log İnceleme (Review) Prosedürü

Denetçi “yapıyoruz” demeyi kabul etmez. Her inceleme için kim inceledi + ne zaman + ne buldu + ne aksiyon aldı + kapanış kaydı olmalıdır.

4.6. Tiered Retention Referans Mimarisi

Kaynaklar: FortiGate · AD/DC · PostgreSQL · RKE2/K8s · Exchange · Uygulama · POS/API
        │  (TLS, syslog / beats / agent)
        ▼
┌─────────────────────────────────────────────┐
│ HOT - SIEM (QRadar / ELK)                   │  0–12 ay
│ Korelasyon, gerçek zamanlı alarm, arama     │  ← PCI 10.5.1: 3 ay "immediately available"
└─────────────────────────────────────────────┘
        │  günlük export + SHA-256 + NEZD
        ▼
┌─────────────────────────────────────────────┐
│ WARM - Searchable Archive                   │  1–3 yıl
│ ELK Frozen Tier / QRadar Data Node          │  ← BDDK 3 yıl, KVKK 2 yıl, 5651 2 yıl
└─────────────────────────────────────────────┘
        │
        ▼
┌─────────────────────────────────────────────┐
│ COLD - Immutable / WORM                     │  3–10 yıl
│ MinIO Object Lock (on-prem, TR) /           │  ← 6493 & TCMB: 10 yıl
│ NetApp SnapLock / ExaGrid RTL / LTO WORM    │  ← MASAK: 8 yıl
│ + offline / air-gapped kopya                │
└─────────────────────────────────────────────┘
        │
        ▼
   Kontrollü İmha (KVKK İmha Politikası + tutanak)

Anahtar nokta veri lokasyonu. TCMB Bilgi Sistemleri Tebliği gereği ödeme kuruluşlarının birincil ve ikincil sistemleri Türkiye’de bulunmalıdır. Dolayısıyla COLD katmanı için AWS/Azure global region’lar yerine yurt içi datacenter / bulut (Bulutistan, İş Net, İnnova, Superonline, DgpaysIT, DT İletişim gibi yerli sağlayıcılar) veya tamamen on-prem (S3-uyumlu object storage: Ceph / NetApp StorageGRID / SeaweedFS / ticari appliance, ya da NetApp SnapLock) çözümler regülasyon açısından güvenli tercihtir. Seçeneklerin ayrıntılı karşılaştırması için Bölüm 3.2’deki “S3-Uyumlu On-Prem WORM – MinIO Alternatifleri” başlığına bakın.

4.7. Silme ve İmha Kuralları

Burada iki ayrı şeyden bahsediyoruz ve denetimde ikisi farklı değerlendirilir. Karıştırmamak lazım.

Log Silme → Kesinlikle Yasak

İşlem/Müşteri Verisi Silme → Nüans Var

Burada Dikkatli Olmak Gerekir:

Yasak Olan:

• İşlem kaydının fiziksel silinmesi (hard delete) – 10 yıl saklama zorunlu.
• Muhasebe/mutabakat kaydının değiştirilmesi.
• Reversal/iptal işleminin orijinal kaydı silerek yapılması.

Doğru Yöntem:

• Soft delete / logical delete – kayıt kalır, is_deleted flag’i işaretlenir.
• Append-only / immutable ledger – düzeltme yeni bir kayıt (reversal entry) olarak yazılır, orijinal asla değişmez.
• Muhasebe mantığı: storno kaydı, silme değil.

KVKK İstisnası:

• Veri sahibinin silme talebi (unutulma hakkı) ancak yasal saklama yükümlülüğü varsa KVKK m.7 devreye girmez. 6493’ün 10 yıl şartı, KVKK’nın silme talebini bloke eder.
• 10 yıl dolduktan sonra → KVKK İmha Politikası gereği silme/anonimleştirme ZORUNLU olur. Yani süresiz saklamak da ihlaldir.

Veri Tipine Göre Özet

Temel ilke: Retention süresi içinde silmek yasak; retention süresi dolduğunda saklamak yasak. İkisi de denetim bulgusudur.

Teknik Uygulama

• Veritabanı: DELETE yetkisi uygulama hesabından kaldırılır; sadece INSERT + UPDATE (flag).
• DB seviyesinde trigger ile DELETE engellenir ve loglanır.
• Object store: Compliance Mode (Governance değil).
• İmha ancak: onaylı politika + imha komisyonu kararı + imha tutanağı ile yapılır.

SIEM Kuralı – Yetkisiz Silme Girişimi:

KURAL: Retention Süresi Dolmadan Silme Girişimi
  (S3: DeleteObject / DeleteObjectVersion / PutBucketLifecycle /
       PutObjectRetention → DENIED)
  OR (Windows EventID 1102, 104, 4719)
  OR (SIEM retention policy modification)
  OR (Backup/archive volume delete attempt)
  → P1: Anında SOC + Bilgi Güvenliği Yöneticisi + hesabı askıya al
  → MITRE ATT&CK: T1070.001 / T1485

4.8. SIEM Korelasyon Kural Önerileri (QRadar / ELK)

Bölüm 2.1’deki Event ID tablolarını fiili tespit kurallarına dönüştürelim.

🔴 P1 – Anında Alarm (SOC Çağrısı):

Kural 1 – Domain Admin’e Üye Eklendi:

  EventID = 4728 OR 4756
  AND TargetUserName IN ("Domain Admins","Enterprise Admins",
                         "Schema Admins","Administrators",
                         "Account Operators","Backup Operators",
                         "Print Operators","Server Operators")

  → Aksiyon: Anında SOC + IT Müdürü bildirimi; CyberArk oturum kaydı ile eşleştir
  → MITRE: T1098.007 (Account Manipulation: Additional Local/Domain Groups)

Kural 2 – Security Log Temizlendi:

  EventID = 1102 OR 104

  → Aksiyon: Kritik. Anti-forensics göstergesi. Host'u izole et.
  → MITRE: T1070.001 (Indicator Removal: Clear Windows Event Logs)

Kural 3 – Audit Policy Değiştirildi:

  EventID = 4719

  → MITRE: T1562.002 (Impair Defenses: Disable Windows Event Logging)

Kural 4 – Mesai Dışı Hesap Oluşturma + Anında Yetkilendirme:

  EventID = 4720 (hesap oluştur)
  FOLLOWED BY EventID = 4728 / 4732 / 4756 (gruba ekle)
  WITHIN 10 dakika
  AND (saat < 08:00 OR saat > 19:00 OR hafta sonu)

  → Persistence göstergesi
  → MITRE: T1136.002 (Create Account: Domain Account)

Kural 5 – RBCD / Shadow Credentials Saldırısı:

  EventID = 4742
  AND (msDS-AllowedToActOnBehalfOfOtherIdentity değişti
       OR msDS-KeyCredentialLink değişti)

  → MITRE: T1098 / T1550.003

Kural 6 – DCSync Girişimi:

  EventID = 4662
  AND Properties CONTAINS "1131f6aa-9c07-11d1-f79f-00c04fc2dcd2"  (DS-Replication-Get-Changes)
                       OR "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2"  (DS-Replication-Get-Changes-All)
  AND SubjectUserName NOT IN (DC computer accounts, AAD Connect service account)

  → MITRE: T1003.006

🟠 P2 – Aynı Gün İnceleme

Kural 7 – Ayrıcalıklı Grup Üyelik Değişikliği (Ekleme/Çıkarma, Tümü):

  EventID IN (4728, 4729, 4732, 4733, 4756, 4757)

  → Change Management kaydı ile eşleştir
  → Onaysız değişiklik varsa → uyumsuzluk bulgusu

Kural 8 – Toplu Hesap Silme / Disable:

  EventID = 4726 OR 4725
  COUNT >= 5 in 10 dakika

  → Sabotaj / insider threat göstergesi
  → MITRE: T1531 (Account Access Removal)

Kural 9 – Admin Parola Sıfırlama (Başkası Tarafından):

  EventID = 4724
  AND TargetUserName IN (privileged_accounts_list)

  → Hesap ele geçirme göstergesi

Kural 10 – Kerberoasting:

  EventID = 4769
  AND TicketEncryptionType = 0x17 (RC4-HMAC)
  AND ServiceName != "krbtgt$"
  AND COUNT DISTINCT ServiceName > 10 in 1 saat BY same account

  → MITRE: T1558.003

Kural 11 – Password Spray:

  EventID = 4625 (Status 0xC000006A - wrong password)
  AND COUNT DISTINCT TargetUserName > 15
  BY same SourceIP in 15 dakika

  → MITRE: T1110.003

Kural 12 – AD Recon (BloodHound / SharpHound):

  EventID = 4799
  AND COUNT > 20 in 5 dakika BY same SubjectUserName

  → MITRE: T1069.002 (Permission Groups Discovery: Domain Groups)

Kural 13 – AD Nesne İzni (ACL) Değiştirildi:

  EventID = 4670 OR 5136
  AND ObjectType = "domainDNS" OR hedef privileged OU/grup

  → AD DACL backdoor
  → MITRE: T1222.001

🟡 P3 – Periyodik İnceleme (Haftalık / Aylık)

• 4672 – Special privilege ataması: baseline dışı hesap var mı?
• 4720 / 4726 – Hesap yaşam döngüsü: İK onboarding/offboarding kayıtlarıyla mutabakat
• 4722 / 4725 – Enable/disable trendi: uzun süre disable kalıp aniden enable olan hesap? (dormant account revival)
• 4740 – Lockout trendi: brute force mi, uygulama kaynaklı mı?
• 4738 – UAC flag değişimi: DONT_REQ_PREAUTH (AS-REP roast hazırlığı), PASSWD_NOTREQD

4.9. PCI DSS 10.2.1.x → Windows Event ID Eşleşmesi

4.10. Ödeme Kuruluşu – Özel Kontrol Noktaları

4.11. Denetim Hazırlığı – Kanıt (Evidence) Listesi

• Log Yönetimi Politikası (onaylı, versiyonlu, yıllık gözden geçirilmiş)
• Kişisel Veri Saklama ve İmha Politikası (KVKK)
• Log kaynağı envanteri – CDE/kritik sistem kapsamı ile eşleşen
• Retention konfigürasyon ekran görüntüleri (SIEM + object store lock policy)
• Object Lock Compliance Mode konfigürasyon kanıtı (Governance değil)
• NEZD sertifikası + örnek damgalanmış log paketi doğrulaması
• Hash/FIM bütünlük raporu örneği
• Günlük inceleme kayıtları (min. 3 aylık örnek)
• Offense/incident kapama kayıtları
• Restore/geri dönüş testi tutanağı – arşivden log geri getirilebiliyor mu?
• Ayrıcalıklı erişim ayrımı (SoD) matrisi
• DB’de DELETE yetkisinin kaldırıldığını gösteren grant listesi
• İmha Komisyonu kararı + imha tutanağı örnekleri
• Retention süresi dolan verinin fiilen imha edildiğinin kanıtı
• NTP topolojisi ve senkronizasyon kanıtı
• Kritik kontrol arızası tespit mekanizması kanıtı (PCI 10.7)
• Yıllık BS denetim raporu / PCI DSS AOC

4.12. En Sık Görülen Denetim Bulguları

Bu yazıda log izlemenin temellerini; log tiplerini, anomali ve fraud tespitini, retention ve WORM depolama yaklaşımlarını ele aldık. Ödeme Kuruluşlarında Log Yönetimi: Mevzuat, Retention ve Silme Yasağı – Bölüm 2 böylece tamamlandı.

Serinin bir sonraki yazısında “Windows/AD ve Linux Log Hardening (Ödeme Kuruluşu)” konularına giriyoruz: PCI DSS, HIPAA ve Türkiye mevzuatının (6493, TCMB, 5651, MASAK, KVKK) log yönetimi üzerindeki birleşik etkisi.

Başka bir yazıda görüşmek dileğiyle…