← Tüm Sorulara Dön

Özel entegratör web servislerinde API anahtarı sızdırıldığında, IP beyaz listesi (IP Whitelisting) tek başına 2FA / MFA yerini tutar mı?

ERP ve muhasebe yazılımımız ile özel entegratör arasındaki fatura transferi, e-irsaliye gönderimi ve cari mutabakatlar REST/SOAP web servisleri (API) üzerinden statik bir API Key ve Bearer Token ile otomatik olarak yürütülmektedir. Entegratörümüz servis uç noktalarında dinamik çok faktörlü doğrulama (2FA/MFA) bulunmadığını ancak sistemin kurumumuza ait statik IP adresleri ile sınırlandırıldığını (Strict IP Whitelisting), bu sayede API anahtarı sızsa dahi dış dünyadan kimsenin işlem yapamayacağını ve bu yapının 2FA seviyesinde güvenlik sağladığını iddia etmektedir. Siber savunma mimarisi ve sıfır güven (Zero Trust) ilkeleri açısından, IP beyaz listelemesi gerçekten 2FA'nın yerini tutabilir mi? SSRF (Server-Side Request Forgery), BGP hijacking, ele geçirilmiş VPN/Jump Host ve iç ağda yanal sıçrama (lateral movement) senaryolarında bu kısıtlama nasıl aşılır; mTLS, RFC 9449 DPoP ve HSM tabanlı imzalama katmanları nasıl kurgulanmalıdır?

Durum: Çözüldü Kategori: Soru-Cevap

2 Cevap

✓

Kesinlikle hayır; siber savunma mimarisinde IP beyaz listelemesi (IP Whitelisting), hiçbir koşulda iki faktörlü kimlik doğrulamanın (2FA/MFA) veya kriptografik kimlik kanıtlamanın yerini tutamaz. IP adresine güvenmek, modern Sıfır Güven (Zero Trust) prensiplerine taban tabana zıttır ve sistemde sahte bir güvenlik algısı (false sense of security) yaratarak kurumları yıkıcı saldırılara karşı savunmasız bırakır.

1. Temel Kavramsal Yanılgı: Ağ Yönlendirme vs. Kimlik Doğrulama:

2FA/MFA doğrulamasının temeli, birbirinden bağımsız en az iki faktörün (bildiğin bir şey, sahip olduğun bir şey, olduğun bir şey) doğrulanmasıdır. Kaynak IP adresi ise bir kimlik doğrulama faktörü değildir; yalnızca TCP/IP yığınında (Layer 3/4) paketlerin yönlendirilmesini sağlayan değişken bir ağ özniteliğidir. IP beyaz listesi yalnızca bir çevre güvenlik filtresidir (perimeter firewall control); uygulama katmanında (Layer 7) kimliği ve yetkiyi garanti edemez.

2. IP Kısıtlamasını Çökerten Saldırı Vektörleri:

Saldırganlar sızdırdıkları API anahtarını doğrudan kendi bilgisayarlarından kullanamasalar bile, IP engelini şu yöntemlerle kolayca aşarlar:

Sunucu Taraflı İstek Sahteciliği (SSRF): Kurumun izinli IP bloğundan internete çıkan herhangi bir web sunucusunda (örneğin müşteri portalı veya WordPress blogu) basit bir SSRF zafiyeti bulunduğunda, saldırgan bu sunucuyu bir vekil (proxy) olarak kullanarak entegratörün API'sine sızdırılan API anahtarıyla istek atabilir. Entegratör paketin meşru kurumsal IP'den geldiğini görür ve sahte faturayı onaylar.
Uç Nokta İhlali ve Yanal Sıçrama (Lateral Movement): Kurum çalışanlarından birinin bilgisayarına oltalama yoluyla sızan bir saldırgan, yerel ağ üzerinden kurumun dış NAT IP'sini kullanarak entegratör API'sine erişebilir. RDP oturumları (Windows Event ID 4624 LogonType 10 ve Event ID 1149) üzerinden Jump Host veya muhasebe sunucusu ele geçirildiğinde, saldırganın tüm API çağrıları izinli IP üzerinden akar.
VPN ve Bulut Egress IP Paylaşımı: Bulut ortamlarında (AWS NAT Gateway, Azure, Cloudflare) kullanılan statik çıkış IP'leri, konfigürasyon hataları veya aynı barındırma sağlayıcısını kullanan diğer kiracılar tarafından istismar edilebilir.
BGP Hijacking ve Ters Proxy Başlık Manipülasyonu: Entegratör ters proxy kullanıyor ve X-Forwarded-For başlığını doğru doğrulamıyorsa, IP spoofing veya BGP rota saptırma taktikleriyle IP filtreleri manipüle edilebilir.

3. Doğru Sıfır Güven (Zero Trust) API Mimarisi:

IP kısıtlamasına bel bağlamak yerine şu kriptografik katmanlar uygulanmalıdır:

Karşılıklı TLS Doğrulaması (mTLS - RFC 8705): API çağrısı yapan istemci ile entegratör arasında çift yönlü X.509 sertifika doğrulaması yapılmalıdır. API anahtarı çalınsa dahi, kurumun sunucusundaki özel anahtar (private key) olmadan TLS el sıkışması tamamlanamaz. Sertifikaların geçerliliği CRL ve OCSP servisleriyle anlık denetlenmelidir.
Kriptografik Token Bağlama (DPoP - RFC 9449): Statik Bearer Token yerine, Demonstration of Proof-of-Possession (DPoP) kullanılmalıdır. İstemci her API isteğini kendi asimetrik anahtarıyla imzalar; çalınan token başka bir makineden kullanılamaz.
HSM FIPS 140-2 Level 3 Donanımsal İmzalama: Fatura gönderme (SendInvoice) gibi yüksek riskli finansal API metotlarında, yalnızca HTTP header'ındaki anahtara güvenilmemeli; faturanın XML içeriği kurumun Donanımsal Güvenlik Modülü (HSM) veya Mali Mührü üzerinden PKCS#11 çağrısıyla imzalanmış olarak gönderilmelidir.

Yanıtlayan

Kıdemli Güvenlik Mimarı T.

Adli bilişim vakalarında IP kısıtlamasına güvenilerek yapılan ihmaller sıkça karşımıza çıkmaktadır. Böyle bir ihlalin adli analizinde şu adımlar yürütülür:

Egress Proxy ve Sysmon Ağ Logları: Şirket içindeki hangi makinenin entegratör API'sine anormal istekler gönderdiği Sysmon Event ID 3 (Network Connection) ve giden proxy logları incelenerek tespit edilir.
API Gateway İstek Gövdesi İncelemesi: Entegratör API Gateway loglarında isteklerin User-Agent, TLS JA4 parmak izi ve HTTP method dağılımı korele edilir. Meşru ERP uygulamasının dışında çalışan şüpheli script'ler (cURL, Python) saptanarak saldırganın iç ağdaki konumu izole edilir.
Anahtar İptali ve Güvenlik Rotasyonu: Sızıntı anında API anahtarı derhal iptal edilmeli, mTLS sertifikaları OCSP üzerinden geçersiz kılınmalı ve tüm erişim jetonları yenilenmelidir.

Yanıtlayan

Adli Bilişim Uzmanı D.