Luna PCIe HSM mimarisini; anahtar yaşam döngüsü, partition ve rol modeli, PKCS#11 entegrasyonu, HA, yedekleme, FIPS/PCI DSS ayrımı ve güvenli belge imzalama örneğiyle inceliyoruz.
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 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’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.
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.
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.
Luna SDK’nın ana arayüzü, PKCS#11 standardına dayanan Chrystoki kütüphanesidir. Tipik imzalama akışı şöyledir:
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.
Pasaport veya kimlik kişiselleştirme sisteminde HSM, belgeye yazılacak güvenlik nesnesinin imzalanmasında kullanılabilir:
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.
“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.
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 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.
Ü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, 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.
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.
Üretim sistemlerinde güncel sürümleri ve kurumunuzun onaylı politikalarını esas alın.
Bu makaleyi nasıl değerlendirirsin?
Geri bildirimin sonraki içerikleri geliştirmeme yardımcı olur.
PKI, HSM VE AKILLI KARTLAR
EF.SOD içindeki Document Signer sertifikasının güvenilir CSCA ile eşleştirilmesini, PKIX zincir doğrulamasını, SOD imzasını ve Data Group hash sonuçlarını Java ve jMRTD örnekleriyle adım adım ele alıyoruz.
PKI, HSM VE AKILLI KARTLAR
SoftHSM token’ında P-256 anahtarı üretme, izole ES256 imzalama servisi, sunucuda yönetim ve Mac XCA bağlantısının sınırları; çalışan dijital kimlik demosundan örneklerle.
DİJİTAL KİMLİK VE CÜZDANLAR
Registra'nın kimlik kartı ve pasaport çipinden doğrulanmış veriyi web'de hazırlanan şablonlarla birleştirip PDF'i telefonda üretme akışını; biyometrik giriş, ekranlar, kullanım senaryoları ve teknik sınırlarıyla inceliyoruz.