E-fatura web servislerinde SSL pinning (sertifika sabitleme) kullanmak mantıklı mı, sertifika yenilemelerinde kesinti yaşatır mı?

E-fatura gibi kritik finansal ve vergi verilerini taşıyan web servislerinde Man-in-the-Middle (MitM) risklerini minimize etmek için SSL Pinning (Sertifika Sabitleme) kullanmak, kağıt üzerinde harika bir API güvenlik katmanı savunması gibi görünse de, pratik uygulamada operasyonel kesinti (outage) riskleri nedeniyle oldukça dikkatli ele alınması gereken karmaşık bir konudur.

Siber savunma ekiplerinizin talebi haklıdır; zira sadece işletim sisteminin güvenilen kök sertifikalarına (Root CA store) bel bağlamak, ağda yetki yükselten bir saldırganın kendi CA'ini sisteme yüklemesi veya dünya çapında güvenilen bir CA'in hacklenmesi durumunda veri akışınızın manipüle edilmesi (örneğin IBAN değişikliği) riskini taşır. Ancak, SSL Pinning entegre edildiğinde, istemci (sizin uygulamanız) entegratörün sunduğu sertifikanın veya açık anahtarın (public key) belirli bir özet değerini (hash) bekler. Entegratör firmalar, acil bir güvenlik açığı, Heartbleed benzeri bir zafiyet veya rutin süre dolumu sebebiyle sertifikalarını yenilediklerinde (örneğin yeni bir sertifika alıp eski CRL/OCSP sunucularından iptal (revoke) ettirdiklerinde), sizin uygulamanız yeni sertifikayı 'saldırı' olarak algılayıp bağlantıyı koparacaktır. E-fatura gönderilememesi, kurumlar için doğrudan yasal cezalar ve ticari kayıplar anlamına gelir.

Bu kesinti riskini ortadan kaldırmanın yolu, doğru Pinning stratejisini seçmektir. Leaf (Yaprak) Sertifikayı pinlemek en sık yapılan hatadır; sertifika değiştiğinde sistem çöker. Kesintileri önlemek için Public Key Pinning (Açık Anahtar Sabitleme) veya Root/Intermediate CA Pinning kullanılmalıdır. Eğer entegratörün Intermediate CA'ini (Ara sertifika otoritesi) pinlerseniz, entegratör aynı CA'den yeni sertifika aldığı sürece uygulamanız kesintisiz çalışmaya devam eder. Daha güvenli bir yöntem olan Public Key Pinning kullanacaksanız, yedeklilik şarttır. Uygulama kodunuzda her zaman bir ana (primary) pin, bir de yedek (backup) pin bulundurmalısınız. Entegratör, gelecekte kullanacağı sertifikanın açık anahtarını önceden üretip size (backup pin olarak) vermeli, geçiş anında sunucuda bu yeni anahtarı devreye aldığında sizin uygulamanız her iki pini de kabul ettiği için sıfır kesinti ile güvenliği sağlamaya devam etmelidir. Ayrıca, ransomware veya yetkisiz erişim adli bilişim (forensics) süreçlerinde, TLS paketlerindeki handshake başarısızlıklarının (Schannel loglarında) gerçek bir MitM saldırısı mı yoksa süresi geçmiş bir pin mi olduğu, SOC ekipleri tarafından SIEM üzerinden titizlikle ayırt edilmelidir.