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

Entegratörün web servis (API) uçlarında 2FA zorunluluğu yoksa, sadece web portalındaki 2FA bizi ne kadar korur?

Muhasebe ve kurumsal ERP yazılımımız, fatura kesme, e-irsaliye düzenleme ve gelen faturaları sorgulama işlemlerini özel entegratörümüzün SOAP/REST web servisleri (API) üzerinden arka planda otomatik olarak yürütmektedir. Entegratörümüz web portalına girişlerde SMS ve e-posta tabanlı 2FA zorunluluğu getirerek hesap güvenliğini artırdığını savunmaktadır; fakat ERP yazılımımızın entegratörle konuştuğu API uçlarında (endpoint) yalnızca statik bir API Key, kullanıcı adı ve şifre (Basic Auth veya Bearer Token) kullanılmakta, hiçbir çok faktörlü doğrulama (2FA/MFA) bulunmamaktadır. Web portalında 2FA varken API tarafında 2FA olmaması savunmamızda nasıl bir asimetrik açık yaratır? Saldırganlar web portalı 2FA'sını tamamen bypass ederek API üzerinden aynı yetkilerle fatura kesebilir veya verileri sızdırabilir mi? Bu mimaride mTLS, IP Whitelisting, OAuth 2.0 mTLS-PoP ve API Security katmanları nasıl yapılandırılmalıdır?
Durum: Çözüldü Kategori: Soru-Cevap

2 Cevap

✓

Web portalında en sıkı iki faktörlü kimlik doğrulamayı (2FA) uygulayıp, aynı sisteme ve aynı verilere erişim sağlayan web servis (API) uç noktalarını yalnızca statik kimlik bilgileriyle (API Key / Basic Authentication) korumak, siber güvenlikte 'kalenin ön kapısına çelik zırh takıp, arka bahçe kapısını açık bırakmak' olarak adlandırılır. Siber saldırganlar web portalındaki 2FA engelini aşmaya çalışmak yerine, doğrudan API uçlarını hedef alarak portalın tüm koruma mekanizmalarını tamamen bypass ederler.



1. 'Gölge Kapı' (Shadow API) Riski ve OWASP API Security Açıkları:

Bu asimetrik güvenlik açığı, OWASP API Security Top 10 listesindeki iki kritik zafiyetle doğrudan örtüşür:

  • API2:2023 - Broken Authentication (Kusurlu Kimlik Doğrulama): Web portalında kullanıcıdan parola ve dinamik SMS/TOTP kodu istenirken, API ucunda 128 karakterlik statik bir anahtar veya sabit bir şifre talep edilir. Statik API anahtarları zamanla ERP konfigürasyon dosyalarından (appsettings.json, web.config, .env), yazılımcıların kaynak kod depolarından (GitHub/GitLab commit geçmişi) veya bellek dökümlerinden (LSASS / RAM dump) sızdırılabilir.
  • API1:2023 - Broken Object Level Authorization (BOLA): Saldırgan ele geçirdiği API anahtarı ile portal arayüzüne hiç uğramadan cURL, Postman veya Python betikleriyle entegratörün REST/SOAP servislerine istek atabilir.


2. Saldırgan API Üzerinden Hangi Eylemleri Gerçekleştirebilir?:

Özel entegratörlerin web servisleri, portal arayüzünde yapılabilen neredeyse tüm işlemleri programatik olarak yapma yetkisine sahiptir:

  • Toplu Sahte E-Fatura Düzenleme: SendInvoice web metoduna gönderilecek tek bir XML payload'ı ile dakikalar içinde yüzlerce sahte fatura kurumunuz adına düzenlenebilir ve doğrudan GİB sistemine iletilir.
  • Tüm Müşteri ve Finans Verilerinin Sızdırılması: GetInvoices veya GetInvoiceList metodları çağrılarak geçmişe dönük tüm gelen ve giden faturalar, cari hesap bakiyeleri, vergi numaraları ve ticari sırlar topluca çekilebilir.
  • Gelen Faturalara Yetkisiz İtiraz/İptal Yanıtı Verilmesi: Tedarikçilerinizden gelen meşru faturalar sistem üzerinden reddedilerek tedarik zinciri ve ticari operasyonlar kasten baltalanabilir.


3. Sıfır Güven (Zero Trust) API Güvenlik Mimarisi Nasıl Kurulmalıdır?:

API uçlarında insan etkileşimi (GUI) olmadığı için klasik SMS 2FA uygulanamaz; ancak kurumsal düzeyde çok daha güçlü makineden makineye (M2M) kriptografik güvenlik katmanları zorunlu tutulmalıdır:

  1. Karşılıklı TLS Doğrulaması (mTLS - Mutual TLS / RFC 8705): İstemci ERP sunucusu ile Entegratör API sunucusu arasında karşılıklı X.509 dijital sertifika doğrulaması yapılmalıdır. Yalnızca entegratörün tanıdığı özel istemci sertifikasına ve özel anahtarına (private key) sahip sunucu bağlantı kurabilir. API anahtarı çalınsa dahi sertifika olmadan hiçbir işlem yapılamaz.
  2. Katı Kaynak IP Beyaz Listesi (Strict IP Whitelisting): Entegratör API ağ geçidi, dünya geneline açık olmamalı; yalnızca kurumunuza ait statik kurumsal dış IP adreslerinden gelen çağrıları kabul etmelidir. Bulut ERP kullanılıyorsa güvenli IP tünelleri (IPsec VPN / Cloudflare Tunnel) tanımlanmalıdır.
  3. OAuth 2.0 DPoP veya mTLS-Constrained Access Tokens: Statik API Key yerine, RFC 9449 standardında DPoP (Demonstration of Proof-of-Possession) veya RFC 8705 mTLS token kısıtlaması kullanılmalıdır. Token, istemcinin yerel özel anahtarıyla imzalanır ve ağda çalınsa bile başka bir ortamda tekrar kullanılamaz.
  4. İşlem Bazlı Payload İmzalaması: Fatura kesme çağrılarında faturanın XML verisi, kurumun yerel HSM'i veya Mali Mührü ile XMLDSig formatında imzalanmadan API tarafından işleme alınmamalıdır.
  5. API WAF ve Davranışsal Hız Sınırlaması (Rate Limiting): Anormal saatlerde gelen veya olağan dışı hacimdeki API çağrıları (örneğin gece saat 03:00'te saniyede 100 fatura sorgusu) otomatik olarak kısıtlanmalı (throttling) ve güvenlik operasyon merkezine (SOC) bildirilmelidir.
Yanıtlayan
Kıdemli Güvenlik Mimarı T.

Adli bilişim soruşturmalarında API kaynaklı veri ihlalleri incelenirken şu log izleri analiz edilir:

  • Web Sunucusu ve Gateway Logları: IIS, Nginx veya API Gateway (Kong, Apigee) loglarında c-ip (kaynak IP), cs-method, cs-uri-stem ve cs(User-Agent) alanları incelenir. Meşru ERP uygulamasının User-Agent başlığı yerine Python-urllib, Go-http-client veya cURL görülmesi istismarın en somut delilidir.
  • mTLS Sertifika Seri Numarası Teyidi: Bağlantı kurulurken kullanılan istemci sertifikasının seri numarası loglanmalı ve CRL/OCSP sunucularından anlık iptal kontrolü yapılmalıdır.
  • Delil Muhafazası: Saldırganın API üzerinden çektiği veya gönderdiği HTTP istek gövdeleri (request payload) SIEM sisteminde WORM depolama üzerinde saklanarak adli delil zincirine dahil edilmelidir.
Yanıtlayan
Adli Bilişim Uzmanı D.