Özel entegratörlerin REST API uçlarında kullanılan JWT kimlik doğrulamasında token hırsızlığına karşı refresh token rotasyonu ve mTLS zorunluluğu nasıl uygulanmalıdır?

Özel entegratör statüsündeki kurumlarda kritik finansal veri (e-fatura ve e-SMM gibi) işleyen REST API uç noktalarında, geleneksel statik JWT (JSON Web Token) tabanlı kimlik doğrulama mekanizmaları, token hırsızlığına karşı ne yazık ki oldukça zayıftır. XSS (Cross-Site Scripting), zararlı tarayıcı eklentileri (malicious extensions) veya ağ seviyesindeki Man-in-the-Middle (MitM) saldırıları aracılığıyla Access Token'ların çalınması, saldırganın yetkili bir kullanıcı veya sistem gibi davranarak API üzerinden sahte fatura kesmesine, sistem konfigürasyonlarını değiştirmesine veya gizli müşteri verilerini dışarı sızdırmasına (data exfiltration) doğrudan olanak tanır. Bu bağlamda, API güvenlik katmanlarınızı ve dijital kimlik doğrulama süreçlerinizi güçlendirmek için Refresh Token Rotasyonu ve Mutual TLS (mTLS) mekanizmalarını birleşik, çok katmanlı bir siber savunma mimarisinde uygulamanız yasal bir zorunluluk kadar elzemdir.

Refresh Token Rotasyonu: Sadece kısa ömürlü (örneğin 5-10 dakika geçerliliği olan) Access Token'lar kullanmak tek başına yeterli bir savunma hattı değildir. Kullanıcı veya API istemcisi yeni bir Access Token talep ettiğinde, mevcut Refresh Token da anında iptal edilerek yeni ve benzersiz bir Refresh Token ile değiştirilmelidir (rotasyon işlemi). Eğer bir siber saldırgan çalınmış bir Refresh Token'ı kullanmaya çalışırsa, Auth sunucusu aynı token'ın daha önce (veya eşzamanlı olarak yasal istemci tarafından) kullanıldığını tespit ederek (Reuse Detection) o kullanıcıya ait tüm aktif token zincirini anında iptal etmeli (revoke) ve kullanıcının yeniden güçlü kimlik doğrulaması (örneğin donanımsal token ile MFA) yapmasını zorunlu kılmalıdır. Bu sayede çalınan token'ların kullanım ömrü, etki alanı ve saldırı yüzeyi minimize edilir.

Mutual TLS (mTLS) ve Token Bağlama: API güvenliğinin en üst seviyesi için, sadece sunucunun değil, istemcinin de X.509 dijital sertifikası ile kimliğini doğruladığı mTLS (Mutual TLS) iletişimi kesinlikle zorunlu kılınmalıdır. Bu sayede Man-in-the-Middle (MitM) saldırıları ağ seviyesinde engellenir. Daha da önemlisi, JWT'ler mTLS bağlantısındaki istemci sertifikasının parmak izine (hash'ine) kriptografik olarak bağlanmalıdır (OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens). Böylece saldırgan bir şekilde JWT'yi çalsa bile, kendi cihazından mTLS bağlantısını kurarken kullandığı sertifika, orijinal istemcinin sertifikası ile uyuşmayacağı için API ağ geçidi (API Gateway) token'ı geçersiz sayıp reddedecektir. İstemci sertifikalarının güvenliği için CCID standartlarında akıllı kart mikrodenetleyicileri içeren güvenilir e-imza donanımları veya HSM cihazları kullanılmalı, sertifika iptal durumları API Gateway üzerinde CRL ve OCSP protokolleri ile anlık (real-time) olarak kontrol edilmelidir. Ransomware veya ağ sızıntısı durumlarında, RDP logları (Event ID 4624 ve 4625) detaylı incelenerek sunucu tarafındaki sertifika özel anahtarlarının (Private Key) kopyalanıp kopyalanmadığı adli bilişim (digital forensics) ekiplerince (SOME) derhal tespit edilmeli, HSM kullanımı ile özel anahtarların sunucu belleğine (RAM) hiçbir şekilde şifresiz çıkması engellenerek FIPS standartları sağlanmalıdır.