🔐
Dijital Kimlik Lab PKI & Siber Güvenlik Mimarisi Portalı
← Tüm Sorulara Dön

Entegratörün SSL sertifikası süresi dolduğunda, ERP sistemindeki otomatik e-fatura gönderim kuyruğu nasıl tepki vermelidir?

Kurumumuzun ERP sistemi, gün sonunda on binlerce e-faturayı arka planda çalışan asenkron mesaj kuyrukları (RabbitMQ / Apache Kafka) ve zamanlanmış servisler aracılığıyla özel entegratörün REST/SOAP API uç noktalarına otomatik olarak iletmektedir. Geçtiğimiz günlerde özel entegratörün genel X.509 SSL/TLS web servis sertifikasının süresi dolmuş veya sertifika yetkilisi (CA) tarafından iptal edilmiştir. Bu kesinti esnasında bazı yazılımcılar sistemin fatura göndermeye devam edebilmesi için HTTP istemci kodunda SSL sertifika doğrulamasını geçici olarak devre dışı bırakmayı (`CURLOPT_SSL_VERIFYPEER = false` / `RejectUnauthorized = false`) önermiştir. Siber savunma mimarisi açısından bu bypass hamlesinin doğuracağı riskler nelerdir? Entegratör sertifikası geçersizleştiğinde ERP gönderim kuyruğu MitM (Araya Girme) saldırılarına zemin hazırlamadan, mali mühür kriptografik bütünlüğünü koruyarak ve mükerrer faturalama yaşamadan Devre Kesici (Circuit Breaker), Dead Letter Queue (DLQ) ve CRL/OCSP kontrol mimarisini nasıl işletmelidir?
Durum: Çözüldü Kategori: Soru-Cevap

2 Cevap

✓

Özel entegratörün SSL/TLS sertifikası süresi dolduğunda veya sertifika zinciri bozulduğunda HTTP istemcisinde SSL doğrulamasını devre dışı bırakmak (CURLOPT_SSL_VERIFYPEER = false), kurumsal siber savunmada asla affedilemez 'ölümcül bir güvenlik hatası' (cardinal sin) olarak kabul edilir. Bu işlem yapıldığı anda kurumun tüm finansal iletişimi savunmasız kalır; faturayı kesintisiz gönderme uğruna kurumun tüm dijital varlığı ve KVKK uyumu tehlikeye atılmış olur.



1. SSL Doğrulamasını Kapatmanın Doğuracağı Ağır Riskler:
  • Araya Girme (Man-in-the-Middle - MitM) Felaketi: TLS doğrulaması kapatıldığında, istemci bağlandığı sunucunun gerçekten entegratör olup olmadığını doğrulayamaz. Yerel ağda, internet servis sağlayıcıda veya DNS katmanında (DNS Spoofing, ARP Zehirleme, BGP Hijacking) araya giren herhangi bir saldırgan sahte bir sunucu kurarak ERP'den çıkan tüm faturaları yakalayabilir.
  • Veri Manipülasyonu ve Sahte IBAN Saldırıları: Saldırgan giden e-fatura XML paketinin gövdesindeki alıcı IBAN numaralarını kendi hesaplarıyla değiştirip entegratöre iletebilir veya müşterilere sahte faturalar düzenleyebilir.
  • API Anahtarları ve Kimlik Belirteçlerinin Çalınması: HTTP başlığında (Header) taşınan statik API anahtarları, Basic Auth parolaları veya Bearer Token değerleri aradaki saldırgan tarafından anında kopyalanır.


2. Kriptografik Doğrulama: CRL ve OCSP Mekanizmaları:

Güvenli bir kurumsal mimaride ERP sistemi TLS sertifikasının yalnızca geçerlilik tarihini (NotAfter) kontrol etmekle yetinmemelidir:

  • Online Certificate Status Protocol (OCSP) ve CRL: Sertifikanın kök veya ara sertifika sağlayıcısı (KamuSM, DigiCert vb.) tarafından iptal edilip edilmediği anlık olarak OCSP sorgusuyla veya Sertifika İptal Listesi (CRL) üzerinden denetlenmelidir.
  • Hard-Fail Kuralı: İstemci 'Soft-fail' yerine 'Hard-fail' modunda çalışmalıdır. Yani OCSP yanıtı alınamıyorsa veya iptal edilmişse güvenli kabul edilmemeli, bağlantı derhal sonlandırılmalıdır. Entegratör sunucusunda gecikmeleri önlemek için OCSP Stapling (RFC 6066) zorunlu tutulmalıdır.


3. Güvenli Kuyruk Mimarisi: Circuit Breaker ve DLQ Tasarımı:

Sertifika hatası meydana geldiğinde ERP gönderim hattı şu dayanıklılık (resilience) desenlerini işletmelidir:

  1. Devre Kesici (Circuit Breaker - Resilience4j / Polly): TLS el sıkışma hatası (SSLHandshakeException, CERT_DATE_INVALID) alındığı anda devre anında 'OPEN' (Açık) durumuna geçmelidir. Kuyruktan entegratöre doğru giden tüm HTTP istekleri derhal dondurulmalı, entegratör sunucusu lüzumsuz istek yağmuruna tutulmamalıdır.
  2. Mesajların Güvenli İzolasyonu (Dead Letter Queue - DLQ): Hata alan faturalar kesinlikle 'başarısız/iptal' olarak işaretlenip silinmemelidir. Mesajlar güvenli bir bekletme kuyruğuna (Retry/DLQ) aktarılmalıdır.
  3. İmza Bütünlüğü ve Değişmezlik: Faturanın UBL-TR XML içeriği yerel FIPS 140-2 Level 3 onaylı HSM veya KamuSM akıllı kart mikrodenetleyicisi (CCID) ile önceden XAdES-BES standardında imzalanmışsa, bu imzanın SHA-256 hash değeri veritabanında kilitli kalmalıdır. Kuyrukta bekleyen dosya üzerinde hiçbir değişiklik yapılmamalıdır.
  4. Üstel Geri Çekilme (Exponential Backoff): Sistem her saniye faturayı tekrar denemek yerine, yalnızca entegratörün sağlık kontrolü (health-check) uç noktasına üstel aralıklarla (1, 2, 4, 8, 15 dakika) hafif ping istekleri göndermelidir.
  5. Yeniden Başlatma ve Mükerrerlik (Idempotency) Koruması: Entegratör sertifikayı yenilediğinde devre 'HALF-OPEN' konumuna getirilmeli; önce tek bir test faturası ile mTLS el sıkışması doğrulanmalıdır. Ardından kuyruk boşaltılırken, faturanın benzersiz GUID (ETTN) numarası entegratörde sorgulanarak mükerrer fatura kesilmesinin önüne geçilmelidir.
Yanıtlayan
Kıdemli Güvenlik Mimarı T.

SOC ve Güvenlik Operasyonları açısından geçersiz sertifika anomalilerine verilecek operasyonel yanıt:

  • SIEM SEV-1 Güvenlik Alarmı: ERP'nin entegratöre yaptığı TLS çağrısında sertifika hatası üretildiği an SIEM üzerinde 'High Priority TLS Anomaly / Potential MitM' alarmı tetiklenmeli; nöbetçi güvenlik analistine ve ERP yöneticisine anında SMS/e-posta bildirim düşmelidir.
  • TLS Parmak İzi (JA4) Değişim Analizi: Entegratör sunucusundan dönen TLS sertifikasının parmak izi (fingerprint / SHA-256 hash) aniden değişmişse, bunun meşru bir yenileme mi yoksa ağ seviyesinde bir araya girme saldırısı mı olduğu firewall ve DNS logları korele edilerek incelenmelidir.
  • Uzak Masaüstü ve Konfigürasyon Değişikliği Denetimi: Yazılımcıların sertifika bypass kodunu acil olarak canlı sunucuya atmasını engellemek için, ERP sunucularına yapılan RDP oturumları (Event ID 4624 LogonType 10) ve dosya değişiklikleri (Sysmon Event ID 11) denetim altında tutulmalıdır.
Yanıtlayan
SOC Analisti Berke K.