HSM, yani donanım güvenlik modülü, TLS özel anahtarını sunucuda bir dosya olarak saklamak yerine kendi içinde korur ve anahtarla yapılan işlemleri denetler. Anahtar çiftini HSM içinde üretmek ve özel anahtarı cihazdan düz metin olarak çıkarmamak, bu korumanın temelini oluşturur.

İmzaya dayalı TLS kimlik doğrulamasında web sunucusu, yük dengeleyici veya başka bir TLS sonlandırma bileşeni özel anahtarı okumak yerine HSM'ye imzalama isteği gönderir. HSM, isteği gönderen uygulamanın yetkisini denetler, imzayı kendi içinde üretir ve yalnız sonucu uygulamaya döndürür.

Bu yaklaşım riski azaltır; ancak tek başına güvenlik garantisi vermez. Erişim yetkileri, denetim kayıtları, yedeklilik, eski anahtarın yeni bir anahtarla değiştirilmesi ve olay müdahalesi yanlış planlanırsa özel anahtar cihaz içinde kalsa bile hizmet kesintisi veya yetkisiz kullanım yaşanabilir.

TLS Sertifikası ile Özel Anahtar Arasındaki Fark Nedir?

TLS sertifikası, alan adı veya hizmet kimliğiyle bir açık anahtarı ilişkilendiren ve istemcilere gönderilebilen bir belgedir. Özel anahtar, sertifikadaki açık anahtarla aynı anahtar çiftinin parçasıdır. Sunucu, özel anahtarı kullanarak ürettiği imzayla bu anahtara sahip olduğunu kanıtlar.

Sertifika dosyasının paylaşılması normaldir; özel anahtarın paylaşılması veya gereksiz yere kopyalanması ise saldırı yüzeyini büyütür. HSM tasarımında sertifika nesnesi ile özel anahtar nesnesi ayrı yönetilebilir. Buradaki asıl amaç, özel anahtarın gizliliğini korumak ve yetkisiz kullanılmasını engellemektir.

Sertifika zincirinin doğru sunulması, özel anahtarın nasıl saklandığını göstermez. Dışarıdan yapılan bir sertifika ve zincir incelemesi, anahtarın gerçekten HSM içinde bulunduğunu tek başına doğrulayamaz.

Anahtarın HSM İçinde Üretilmesi ve Kullanılması

Kuruluş, anahtarın nerede üretileceğini, hangi işlemlerde kullanılacağını ve hangi koşullarda dışarı çıkarılabileceğini HSM kurulumuna başlamadan önce belirlemelidir.

Anahtar Çiftinin Cihaz İçinde Oluşturulması

Anahtar çifti HSM içinde üretildiğinde özel anahtar değeri genel amaçlı işletim sistemi belleğinde veya dosya sisteminde oluşturulmaz. Açık anahtar dışarı alınarak CSR’ye (Certificate Signing Request) eklenir; istek, özel anahtar kullanılarak HSM içinde imzalanır. Özel anahtar ise HSM içindeki anahtar nesnesi olarak kalır.

Özel anahtarı dışa aktarılamaz olarak oluşturmak, uygulamanın anahtarı düz metin biçiminde okumasını engellemeyi amaçlar. Dışa aktarımın nasıl sınırlandığı HSM'nin güvenlik politikasına, yedekleme yöntemine ve yönetim yetkilerine bağlıdır; ürün belgelerinde düz metin biçiminde dışa aktarım, anahtar sarma ve yedekleme yolları ayrı ayrı doğrulanmalıdır. Anahtar sarma, anahtarı başka bir anahtarla şifreleyerek korumalı biçimde aktarma yöntemidir.

TLS El Sıkışmasında İmzalama

TLS 1.3'te sertifikayla kimlik doğrulayan sunucu, özel anahtarıyla CertificateVerify imzasını üretir. İmzalanan veri, el sıkışma mesajlarının özetini ve TLS'nin belirlediği ek bağlam bilgisini içerir. HSM kullanıldığında TLS bileşeni, imzalanacak veriyi veya bu verinin özetini işlem parametreleriyle birlikte cihaza iletir; HSM imzayı üretir ve özel anahtar değerini uygulamaya açıklamaz.

Bu model, web sunucusunun ele geçirilmesi halinde anahtar dosyasının doğrudan kopyalanması riskini azaltabilir. Buna rağmen saldırgan, çalışan uygulamanın HSM oturumunu kullanabiliyorsa yetkisi sürdüğü süre boyunca imza isteği gönderebilir; bu nedenle HSM erişimi yalnız dosya koruması olarak görülmemelidir.

Uygulama ile HSM Arasındaki Bağlantı

Web sunucusu veya TLS sonlandırıcı, desteklediği kriptografik sağlayıcı ya da PKCS #11 gibi bir cihaz arayüzü üzerinden HSM'deki anahtar nesnesine erişir. Uygulama yapılandırması anahtarın kendisini değil, çoğu durumda cihazdaki anahtarı tanımlayan bir referans veya nesne kimliği taşır.

Entegrasyon sırasında sertifika, açık anahtar ve HSM'deki özel anahtarın aynı anahtar çiftine ait olduğu doğrulanmalıdır. Eşleşme hatası, TLS hizmetinin başlamamasına veya el sıkışma sırasında imza doğrulamasının başarısız olmasına yol açabilir.

Erişim Kontrolü, Denetim Kaydı ve Görev Ayrılığı

HSM'nin sağladığı koruma, hangi kimliğin hangi anahtarla hangi işlemi yapabildiğinin sınırlandırılmasına bağlıdır. TLS hizmet hesabına yalnız gerekli imzalama yetkisi verilmeli; anahtar silme, yedekleme, politika değiştirme ve kullanıcı yönetimi gibi görevler aynı hesaba bırakılmamalıdır.

  • En az yetki: Uygulama yalnız belirlenen TLS anahtarlarıyla imza üretebilmelidir.
  • Görev ayrılığı: HSM yöneticisi, uygulama yöneticisi ve güvenlik denetçisi rolleri mümkün olduğunca ayrılmalıdır.
  • Güçlü kimlik doğrulama: Uygulama ve yönetici erişimi, ortamın riskine uygun kimlik doğrulama yöntemleriyle korunmalıdır.
  • Denetim kaydı: Anahtar üretme, kullanma, silme, politika değiştirme ve başarısız erişim olayları kaydedilmelidir.
  • Kayıt bütünlüğü: Denetim kayıtları anahtar malzemesi içermemeli ve yetkisiz değişikliğe karşı korunmalıdır.

Kuruluş, kritik işlemlerde iki kişinin birlikte onayı veya yönetim yetkisinin birden fazla yetkiliye bölünmesi gibi yöntemler kullanabilir. Her HSM aynı kontrolleri desteklemez; kuruluş, gerekli yöntemi tehdit modeline ve cihazın özelliklerine göre seçmelidir.

Yedeklilik ve Anahtar Kaybı Riski

Dışa aktarılamayan bir anahtar kaybolursa sunucu, ilgili sertifikayla yeni TLS bağlantısı kurmak için gereken imzayı üretemez. Bu nedenle anahtar gizliliği ile hizmet sürekliliği birlikte planlanmalıdır; yalnız tek cihazda bulunan ve kurtarma yolu olmayan anahtar, donanım arızasında kesintiye neden olabilir.

Kuruluş, risk ve süreklilik hedeflerine göre HSM kümesi, üreticinin güvenli çoğaltma mekanizması, korumalı yedek veya önceden hazırlanmış ikinci anahtar ve sertifika seçeneklerinden birini seçebilir. İmza anahtarının yedeği ek bir kopya ve erişim yolu oluşturduğu için yedekleme her kurulumda zorunlu kabul edilmemelidir. Hangi yöntemin seçileceği, özel anahtarın yedeklenmesine izin verilip verilmediğine, kurtarma süresi hedefine ve anahtarın kullanım amacına bağlıdır.

Yedek alınacaksa bu kopya da özel anahtarla aynı koruma düzeyinde tutulmalı, erişim yetkisi sınırlanmalı ve geri yükleme düzenli olarak test edilmelidir. Yedekleme mümkün değilse yeni anahtar üretme, yeni sertifika alma, dağıtma ve eski sertifikayı devreden çıkarma adımları önceden hazırlanmalıdır.

HSM ile TLS Anahtar Korumasını Uygulama Planı

  1. TLS sonlandıran sistemleri, sertifikaları, özel anahtarları ve sorumlu ekipleri envantere alın.
  2. Her anahtar için kullanım amacı, dışa aktarım politikası, kullanım süresi, anahtar yenileme ve olay müdahalesi kurallarını belirleyin.
  3. HSM ile TLS bileşeni arasındaki desteklenen entegrasyonu seçin ve erişimi ayrı bir hizmet kimliğiyle sınırlandırın.
  4. Anahtar çiftini HSM içinde üretin, açık anahtarı içeren sertifika isteğini HSM'de imzalayın ve alınan sertifikayı doğru anahtarla eşleştirin.
  5. Normal trafik, yeniden başlatma, yetki kaybı, HSM erişim hatası ve yedek sisteme geçiş senaryolarını test edin.
  6. Denetim kayıtlarını izleyin; anahtar yenileme, sertifika yenileme ve olası ihlal durumunda iptal ile yeni anahtar oluşturma adımlarını uygulayın.

Plan yalnız TLS bağlantısının açılmasıyla başarılı sayılmaz. Yetkisiz bir hesabın imza üretemediği, anahtarın beklenmeyen yollarla dışarı alınamadığı ve tek cihaz arızasında belirlenen kurtarma süresinin karşılandığı da doğrulanmalıdır.

HSM'nin Tek Başına Önleyemediği Riskler

HSM zayıf web uygulaması kodunu, ele geçirilmiş yönetici hesabını, yanlış sertifika zincirini veya hatalı TLS yapılandırmasını kendiliğinden düzeltmez. Cihaz, özel anahtarın saklanması ve kriptografik işlemlerin denetlenmesi için bir güvenlik katmanıdır; çevresindeki sistemlerin güvenliği ayrı kontroller gerektirir.

Ayrıca bir ürünün belirli bir standarda göre doğrulanmış olması, bütün kurulumun güvenli veya belirli bir mevzuata uyumlu olduğunu tek başına kanıtlamaz. Kuruluş, doğrulama kapsamını, kullanılan modül sürümünü, çalışma modunu, erişim politikalarını ve işletim süreçlerini birlikte değerlendirmelidir.