Sunucu tabanlı HSM'lerde tutulan e-imzaların yetkisiz kullanımını engellemek için en iyi pratikler nelerdir?

Ağ tabanlı Donanımsal Güvenlik Modülleri (Network HSM), kurumsal özel anahtarların (Private Key) donanım dışına çıkarılmasını (export edilmesini) kriptografik ve fiziksel olarak engeller. Ancak bu mimaride en büyük yanılgı, anahtar dışarı sızdırılamadığı için imzalama sürecinin tamamen güvende olduğunu varsaymaktır. HSM'e imza talebi gönderen uygulama sunucuları veya API ağ geçidi ele geçirildiğinde, saldırganlar anahtarı çalmadan HSM'i bir 'İmzalama Kahini' (Signing Oracle / Confused Deputy) olarak kullanarak yetkisiz milyonlarca sahte belgeyi imzalayabilirler. Bu tehdidi bertaraf etmek için uçtan uca savunma mimarisi kurgulanmalıdır.

• Donanımsal Bütünlük ve Sıfırlama (Zeroization): HSM cihazının FIPS 140-2 Level 3 sertifikasyonuna sahip olması, fiziksel kurcalama (fiziksel kasanın açılması, voltaj/ısı anomalileri) durumunda özel anahtarların donanımsal olarak anında silinmesini (zeroize) garanti eder.
• Rol Ayrımı (Separation of Duties): Güvenlik Yöneticisi (Security Officer), Kripto Kullanıcısı (Crypto User) ve Denetçi (Auditor) rolleri katı biçimde ayrılmalıdır. Anahtar yönetimi yapan yönetici imzalama yapamamalı, imzalama yapan servis hesabı anahtar yetkilerini değiştirememelidir.
• Çift Kontrol ve Eşik Değeri (M-of-N Quorum / Dual Control): Kritik anahtarların partition (bölüm) kilidinin açılması veya yetki yükseltilmesi tek bir kişinin inisiyatifine bırakılamaz. Örneğin, 5 güvenlik yetkilisinden en az 3'ünün (3-of-5) fiziksel akıllı kartlarını ve PIN'lerini HSM'e takması şart koşulmalıdır (Shamir's Secret Sharing tabanlı çoklu anahtar paylaşımı).

• Karşılıklı TLS (mTLS) ve Sertifika Sabitleme: HSM ile konuşan API sunucuları arasında şifresiz veya tek taraflı bağlantı kesinlikle yasaklanmalıdır. Yalnızca kurumsal CA tarafından üretilmiş, HSM tarafında IP ve parmak izi (fingerprint) seviyesinde beyaz listeye (allowlist) alınmış istemci sertifikalarına sahip sunucular mTLS ile el sıkışabilmelidir.
• İmzalanacak İçerik ve Şema Doğrulaması (Pre-Signing Validation): HSM API'si istemciden gelen rastgele bir hash değerini doğrudan imzalamamalıdır. İstemci uygulamanın gönderdiği XML/PDF belgesi, yalıtılmış bir doğrulama katmanında şema doğrulamasına (XSD/Schematron), iş kuralları denetimine (örneğin fatura tutarı, onaylayan yönetici kimliği) tabi tutulmalı; hash değeri bu güvenli ağ geçidi içinde hesaplanarak HSM'e iletilmelidir.
• Kısa Ömürlü JWT / OAuth 2.0 İmzalı Talepler: API çağrıları, işlemi başlatan yetkili yöneticinin veya iş sürecinin kriptografik olarak imzalanmış, maksimum 1-2 dakika geçerli token'larını barındırmalıdır.

• Eşik Değeri ve Devre Kesici (Circuit Breaker): İmzalama API'sine katı hız limitleri (örneğin dakika başına maksimum 200 imzalama) konulmalıdır. Mesai saatleri dışında veya olağan dışı hacimlerde gelen imza taleplerinde devre kesici otomatik devreye girerek API'yi kilitlemeli ve nöbetçi SOC analistine acil durum eskalasyonu yapmalıdır.
• WORM (Write Once, Read Many) Denetim İzi: HSM tarafından üretilen her imzalama işleminin zaman damgası, istek yapan istemci IP'si, anahtar kimliği ve hash kaydı değiştirilemez (WORM) depolama alanına ve merkezi SIEM'e TLS üzerinden anlık olarak (Syslog/CEF) akıtılmalıdır.