SafeNet’ten Thales Luna PCIe HSM’e: Anahtar Yönetimi, PKCS#11 ve Üretim Mimarisi

SafeNet adıyla bilinen PCIe HSM ürün ailesi bugün Thales Luna PCIe HSM olarak devam ediyor. Bu cihazlar, uygulama sunucusunun PCI Express yuvasına takılarak kriptografik anahtarların yaşam döngüsünü donanım içinde yönetir; imzalama, doğrulama, şifreleme ve anahtar türetme işlemlerini güvenli sınır içerisinde gerçekleştirir.

Bir HSM’i yalnızca “özel anahtarın tutulduğu kart” şeklinde düşünmek eksik kalır. Doğru kurulan bir Luna PCIe HSM mimarisi; rol ayrımı, partition tasarımı, anahtar politikaları, denetim kayıtları, yedekleme, yüksek erişilebilirlik ve uygulama entegrasyonunun birlikte yönetildiği bir güven köküdür.

SafeNet PCIe HSM mi, Thales Luna PCIe HSM mi?

SafeNet markası sektörde hâlâ yaygın olarak kullanılsa da güncel ürün ve dokümantasyon adı Thales Luna PCIe HSM 7’dir. Eski kurulumlarda Luna 5 veya Luna 6 ifadeleriyle karşılaşılabilir. Yeni bir mimari tasarlanırken donanım modeli kadar firmware, Luna HSM Client ve kullanılacak API sürümleri de birlikte değerlendirilmelidir.

Luna PCIe HSM, doğrudan uygulama sunucusuna takılan yerel bir HSM’dir. Network HSM’den temel farkı, kriptografik modüle ağ üzerinden değil aynı host içinden erişilmesidir. Bu yaklaşım düşük gecikme ve yüksek işlem kapasitesi sağlayabilir; buna karşılık fiziksel sunucu bağımlılığı, bakım pencereleri ve felaket kurtarma tasarımı daha fazla önem kazanır.

HSM gerçekte neyi korur?

HSM’in temel görevi hassas anahtar materyalini genel amaçlı işletim sisteminden ayırmaktır. Dışarı çıkarılamaz olarak tanımlanmış bir özel anahtar HSM içinde oluşturulur; uygulama anahtarın kendisini değil, PKCS#11 nesne tanıtıcısını veya etiketini kullanır. İmzalanacak veri HSM’e gönderilir, işlem güvenli sınır içinde yapılır ve yalnızca sonuç geri döner.

Uygulama
   │  veri özeti + mekanizma + anahtar referansı
   ▼
PKCS#11 / JCA-JCE / CNG / OpenSSL
   ▼
Luna HSM Client
   ▼
Luna PCIe HSM
   └── Özel anahtar donanım sınırından çıkmadan imza üretir

Bu koruma önemli olsa da sınırsız değildir. HSM, yetkili bir uygulamanın kötü niyetli veriyi imzalamasını kendiliğinden anlayamaz. Uygulama hesabı ele geçirilirse saldırgan anahtarı dışarı çıkaramasa bile izin verilen imzalama operasyonlarını kötüye kullanabilir. İş kuralı, kimlik doğrulama, yetkilendirme, oran sınırlama ve imzalanan içeriğin doğrulanması HSM dışında da güçlü olmalıdır.

PCIe mimarisinin avantajları ve sınırları

Avantajlar

• Düşük gecikme: Uygulama ile HSM aynı fiziksel host üzerinde bulunur.
• Kriptografik hızlandırma: RSA, ECC ve simetrik işlemler özel donanımda çalıştırılır.
• Anahtar izolasyonu: Özel anahtar materyali işletim sistemi dosyası olarak tutulmaz.
• Standart API desteği: PKCS#11 yanında Java JCA/JCE, Microsoft CAPI/CNG ve OpenSSL entegrasyon yolları bulunur.
• Rol ve politika yönetimi: HSM ve application partition seviyelerinde görev ayrımı uygulanabilir.

Sınırlar

• PCIe kart fiziksel sunucuya bağlıdır; sunucu değişimi ve veri merkezi operasyonları planlanmalıdır.
• Tek kart yüksek erişilebilirlik sağlamaz; donanım arızası imzalama servisini durdurabilir.
• Teorik TPS değeri tek başına yeterli değildir; oturum yönetimi, mekanizma ve uygulama eşzamanlılığı sonucu değiştirir.
• HSM, kötü anahtar politikalarını veya zayıf uygulama yetkilendirmesini telafi etmez.

Partition ve rol modeli

Luna PCIe HSM 7, yönetim işlemleriyle uygulama anahtarlarını birbirinden ayırır. HSM seviyesindeki roller donanımın yapılandırılmasından; partition seviyesindeki roller kriptografik nesnelerden sorumludur.

HSM Security OfficerHSM’i başlatır, global politikaları ve application partition’ı yönetir. AuditorDenetim kayıtlarının yapılandırılması ve kontrolünden sorumludur. Partition Security OfficerPartition politikalarını ve Crypto Officer rolünü yönetir. Crypto OfficerAnahtar nesnelerini oluşturur, değiştirir; backup/restore işlemlerini yürütür. Crypto UserMevcut anahtarlarla kriptografik işlem yapar; yönetim yetkisi sınırlıdır.

Üretimde uygulamanın günlük imzalama işlemleri için yönetici yetkili Crypto Officer yerine, ihtiyacı karşılıyorsa daha kısıtlı Crypto User rolünün kullanılması en az yetki ilkesine daha uygundur. Anahtar oluşturma ve silme yetkisi ile imza üretme yetkisi aynı servis hesabında toplanmamalıdır.

Password ve PED tabanlı doğrulama

Luna PCIe ailesinde parola doğrulamalı A serisi ile PED tabanlı çok faktörlü/quorum doğrulamalı S serisi modeller bulunur. PED mimarisinde farklı roller fiziksel anahtarlarla yönetilebilir ve M-of-N yaklaşımıyla kritik işlemler birden fazla görevlinin katılımına bağlanabilir.

Seçim yalnızca “hangisi daha güvenli?” sorusuyla yapılmamalıdır. Otomasyon ihtiyacı, anahtar töreni prosedürleri, vardiya yapısı, felaket kurtarma lokasyonu ve uyumluluk profili birlikte değerlendirilmelidir. İnsan katılımı gerektiren bir kontrol operasyon tarafından sürdürülemiyorsa kâğıt üzerinde güçlü, pratikte kırılgan bir sürece dönüşür.

Uygulama entegrasyonu: PKCS#11 akışı

Luna SDK’nın ana arayüzü, PKCS#11 standardına dayanan Chrystoki kütüphanesidir. Tipik imzalama akışı şöyledir:

1. PKCS#11 kütüphanesini başlat.
2. Uygun slot ve token’ı bul.
3. Application partition üzerinde session aç.
4. Gerekli kullanıcı rolüyle doğrulan.
5. Etiket veya nesne kimliğiyle özel anahtar referansını bul.
6. Algoritma ve parametrelerle imza işlemini başlat.
7. Veriyi veya önceden hesaplanmış özeti imzala.
8. Session’ı ve geçici hassas verileri güvenli biçimde kapat.

Temel C akışı aşağıdaki gibidir. Kod öğretici bir iskelettir; tüm dönüş kodları ve cleanup yolları üretimde ayrıca uygulanmalıdır:

CK_FUNCTION_LIST_PTR p11;
CK_SESSION_HANDLE session;
CK_OBJECT_HANDLE private_key;

p11->C_Initialize(NULL_PTR);
p11->C_OpenSession(
    slot_id, CKF_SERIAL_SESSION,
    NULL_PTR, NULL_PTR, &session
);

/* PIN kaynak kodda tutulmamalı, güvenli secret kaynağından alınmalıdır. */
p11->C_Login(session, CKU_USER, pin, pin_length);

CK_OBJECT_CLASS object_class = CKO_PRIVATE_KEY;
CK_ATTRIBUTE query[] = {
    {CKA_CLASS, &object_class, sizeof(object_class)},
    {CKA_LABEL, "document-signing-key", 20}
};

p11->C_FindObjectsInit(session, query, 2);
p11->C_FindObjects(session, &private_key, 1, &object_count);
p11->C_FindObjectsFinal(session);

CK_MECHANISM mechanism = {CKM_ECDSA, NULL_PTR, 0};
p11->C_SignInit(session, &mechanism, private_key);
p11->C_Sign(
    session, digest, digest_length,
    signature, &signature_length
);

p11->C_Logout(session);
p11->C_CloseSession(session);
p11->C_Finalize(NULL_PTR);

En kritik ayrıntılardan biri mekanizma seçimidir. Bazı mekanizmalar hashing işlemini HSM içinde yaparken bazıları ham digest bekler. ECDSA imzasının ham r || s biçiminde mi yoksa ASN.1 DER dizisi olarak mı işlendiği entegrasyon katmanında doğrulanmalıdır. Yanlış mekanizma veya format, anahtar doğru olsa bile birlikte çalışabilirliği bozar.

Güvenli belge sisteminde örnek kullanım

Pasaport veya kimlik kişiselleştirme sisteminde HSM, belgeye yazılacak güvenlik nesnesinin imzalanmasında kullanılabilir:

1. Kişiselleştirme sistemi veri gruplarının hash değerlerini üretir.
2. Hash’ler ilgili ICAO/PKI profilinin tanımladığı yapıda birleştirilir.
3. İmzalanacak veri canonical byte gösterimine dönüştürülür.
4. İmza servisi belge talebini, operatörü ve iş emri yetkilerini doğrular.
5. HSM içindeki Document Signer özel anahtarıyla imza üretilir.
6. İmza ve sertifika zinciri güvenlik nesnesine eklenir.
7. Sonuç bağımsız doğrulanır; yalnızca başarılıysa çipe yazılır.

Document Signer anahtarını HSM’de tutmak anahtarın dosya olarak kopyalanmasını önler; ancak yanlış veri grubunun imzalanmasını engellemez. Bu nedenle sign before write yanında verify after sign ve mümkünse kişiselleştirme sonrası read back kontrolleri uygulanmalıdır.

Anahtar yaşam döngüsü

• Oluşturma: Anahtar HSM içinde üretilmeli, export politikası baştan belirlenmelidir.
• Etiketleme: Label yanında değişmeyen nesne kimliği ve sahiplik kaydı tutulmalıdır.
• Yetkilendirme: Hangi servis, rol ve ortamın anahtarı kullanabileceği sınırlandırılmalıdır.
• Aktivasyon: Üretim anahtarı kontrollü bir anahtar töreniyle devreye alınmalıdır.
• Rotasyon: Sertifika süresi, algoritma politikası ve olay senaryolarına göre planlanmalıdır.
• Yedekleme: Felaket sonrası geri yükleme düzenli olarak test edilmelidir.
• İptal ve imha: Kullanım durdurulmalı, sertifika iptal edilmeli ve nesne denetlenebilir biçimde yok edilmelidir.

“Non-extractable” anahtar ile “yedeklenemez” anahtar aynı şey değildir. Luna’nın yetkili cloning ve backup mekanizmaları, anahtarı açık metin olarak dışarı çıkarmadan güvenli başka bir HSM’e aktarabilir. Bunun çalışması cloning domain, politika, rol ve hedef uyumluluğuna bağlıdır.

Yüksek erişilebilirlik ve felaket kurtarma

Tek PCIe HSM tek hata noktasıdır. Luna HSM Client, birden fazla HSM partition’ını uygulamaya tek mantıksal HA grubu gibi gösterebilir; çağrılar grup üyeleri arasında dengelenebilir ve session ayrıntıları istemci kütüphanesince yönetilebilir.

• HA, bir cihaz kaybında servisin işlem üretmeye devam etmesini hedefler.
• Backup, silinme, bozulma veya lokasyon kaybından sonra anahtarın geri getirilmesini hedefler.
• Disaster recovery, sertifikaları, yapılandırmayı, uygulamayı, yetkileri ve prosedürleri de kapsar.

HA grubunun varlığı geri yükleme testinin yerine geçmez. Backup HSM veya uygun yedekleme hedefindeki arşivin, ayrı ve kontrollü ortamda hedeflenen RTO/RPO içinde geri getirilebildiği kanıtlanmalıdır.

Performans testi nasıl yapılmalı?

Ürün modeline ait RSA, ECC veya AES TPS değerleri kapasite planlamasına başlangıç sağlar; gerçek uygulama testi değildir. Tek session ile session pool, anahtar boyutları, P50/P95/P99 gecikmeleri, HA üyesi kaybı, eşzamanlı session sınırları ve yeniden başlatma sonrası toparlanma ayrı ayrı ölçülmelidir.

Session açma ve login işlemini her imzada tekrarlamak ciddi ek yük oluşturabilir. Session pool tasarımında ise thread güvenliği, oturum ömrü, HSM yeniden başlatma ve hata sonrasında geçersiz handle temizliği doğru ele alınmalıdır.

FIPS 140‑3 ve PCI DSS aynı şey değildir

FIPS 140‑3, kriptografik modülün belirli güvenlik gereksinimlerine göre doğrulanmasıyla ilgilidir. PCI DSS ise kart verisi ortamının tamamına uygulanan operasyonel ve teknik güvenlik standardıdır. FIPS doğrulamalı bir HSM kullanmak PCI DSS uyumuna katkı sağlayabilir; ağı, uygulamayı, erişim kontrolünü, logları ve süreçleri otomatik olarak uyumlu hale getirmez.

Sertifikasyon ürün adı üzerinden genellenmemelidir. Kesin durum; donanım modeli, firmware sürümü, çalışma modu ve güvenlik politikasına göre kontrol edilmelidir. FIPS modunda desteklenen mekanizmaların veya bazı operasyonların değişebileceği hesaba katılmalıdır.

Sık yapılan hatalar

1. PIN veya partition parolasını kaynak kodda ya da düz metin yapılandırmada tutmak.
2. Uygulamayı Crypto Officer gibi gereğinden geniş yetkiyle çalıştırmak.
3. Anahtarı yalnızca label ile bulup label tekrarını ve yanlış slot seçimini kontrol etmemek.
4. PKCS#11 dönüş kodlarını yok saymak ve her hatayı aynı şekilde yeniden denemek.
5. Bağlantı koptuğunda geçersiz session ve object handle’larını kullanmayı sürdürmek.
6. İmza mekanizmasıyla hash/encoding sorumluluğunu karıştırmak.
7. Üretim ve test anahtarlarını aynı partition veya yetki alanında toplamak.
8. HA’yı backup sanmak ve geri yükleme tatbikatı yapmamak.
9. Loglarda PIN, kişisel veri veya imzalanan hassas içeriği bırakmak.
10. Ürün TPS tablosunu gerçek uygulama kapasitesi kabul etmek.
11. Firmware/client uyumluluğunu doğrulamadan sürüm yükseltmek.
12. HSM güvenli diye host işletim sistemini ve uygulama yetkilendirmesini ihmal etmek.

Üretime çıkış kontrol listesi

• Model, firmware ve Luna HSM Client uyumluluk matrisi doğrulandı mı?
• Roller farklı kişiler ve servis hesapları arasında ayrıldı mı?
• Export, wrap, delete ve kullanım politikaları belgelendi mi?
• Uygulama en düşük yetkili rolle çalışıyor mu?
• PIN ve sırlar güvenli secret yönetim sistemi üzerinden veriliyor mu?
• İmza isteği HSM’e ulaşmadan iş kuralı ve yetki kontrolünden geçiyor mu?
• HA üye kaybı ve yeniden bağlanma testi yapıldı mı?
• Backup alındı ve bağımsız geri yükleme testi tamamlandı mı?
• Audit log bütünlüğü, saklama süresi ve alarm kuralları tanımlandı mı?
• Anahtar rotasyonu ve acil iptal prosedürü tatbik edildi mi?

Sonuç

Thales Luna PCIe HSM, özel anahtarları uygulama sunucusunun dosya sisteminden ayırmak ve yüksek hacimli kriptografik işlemleri donanım güvenlik sınırı içinde yürütmek için güçlü bir platformdur. Gerçek güvenlik kazanımı kartın sunucuya takılmasıyla değil; partition tasarımı, rol ayrımı, doğru PKCS#11 mekanizması, anahtar yaşam döngüsü, HA, doğrulanmış backup ve uygulama yetkilendirmesinin birlikte uygulanmasıyla elde edilir.

Güvenli belge üretiminde HSM, Document Signer gibi kritik imza anahtarının güven kökü olabilir. Yine de HSM’in “neyi imzaladığına” uygulama karar verir. Temel ilke şudur: anahtar HSM’den çıkmamalı, imza talebi denetimsiz biçimde HSM’e girmemeli ve üretilen sonuç bağımsız olarak doğrulanmalıdır.

Resmî kaynaklar

• Thales — Luna PCIe HSM ürün sayfası
• Thales — Luna PCIe HSM 7 güncel dokümantasyonu
• Thales — Luna SDK API Overview
• Thales — User Access Control
• Thales — High Availability Implementations
• Thales — Partition Backup and Restore