İki haftadır SPBM ve izleme konularını işledim. Bu hafta Modül 3'e geçiyorum: vSAN şifreleme ve güvenlik. Modül kısa ama içerik yoğun. Şifreleme konuları genelde "evet, şifreleyelim" deyip geçilen yerler değil; anahtar yönetimi, reboot davranışı ve performans etkisi gibi detaylar production'da gerçekten fark ediyor.
Bu yazıda iki ana konu var: data-in-transit (aktarım sırasında) şifreleme ve data-at-rest (durağan veri) şifreleme. İkisi birbirinden bağımsız, ayrı ayrı açılıp kapatılabiliyor.
İki Şifreleme Türü, İki Farklı Amaç
vSAN iki tür şifreleme sunuyor:
Data-in-transit encryption: Host'lar arasında akan tüm vSAN verisi ve metadata trafiğini şifreliyor.
Data-at-rest encryption: Veriyi, deduplikasyon gibi diğer işlemler tamamlandıktan sonra şifreliyor. Bir disk cluster'dan fiziksel olarak çıkarılsa bile üzerindeki veri korunmuş oluyor.
Bu ayrımı net tutmak önemli: birini açmak diğerini otomatik açmıyor. Tehdit modeline göre ikisi farklı senaryoları kapatıyor. Data-in-transit, ağ üzerinde dinleme (sniffing) riskine karşı; data-at-rest, fiziksel disk hırsızlığına veya yanlış imha edilen donanıma karşı.
Data-In-Transit Encryption: Detaylar
Bu özelliğin birkaç teknik özelliği var, not almaya değer:
- AES-256 bit şifreleme kullanılıyor.
- Data-at-rest şifrelemesiyle ilişkisi yok; ikisi bağımsız açılıp kapatılabiliyor.
- Forward secrecy uygulanıyor (yani bir anahtar ele geçirilse bile geçmiş trafiği deşifre etmek için kullanılamıyor).
- Data host'ları ile witness host'ları arasındaki trafik de şifreleniyor.
- File service trafiği (VDFS proxy ile VDFS server arası) de kapsam içinde.
En dikkat çeken kısım şu: şifreleme için bir Key Management Server'a ihtiyaç yok. Host'lar bir bağlantı kurduklarında dinamik olarak simetrik bir anahtar üretiyor ve bu anahtarla aralarındaki trafiği şifreliyorlar. Bir host cluster'a katıldığında doğrulanıyor, cluster'dan çıkarıldığında ise sertifikası kaldırılıyor.
Bu, data-at-rest şifrelemesine kıyasla operasyonel olarak çok daha hafif bir özellik. Tek bir toggle, anahtar yönetimi derdi yok. Bu yüzden "neden açmayalım ki" sorusuna cevap vermek daha kolay.
Etkinleştirme Adımları
vSphere Client üzerinden:
-
cluster-esa-01aseçiliyor - Configure
- vSAN > Services
- Data Services bölümü genişletilip EDIT'e tıklanıyor
Açılan ekranda Data-In-Transit Encryption toggle'ı açılıyor ve APPLY'a basılıyor. Bir de "rekey interval" var; varsayılan 1 gün, ihtiyaca göre özelleştirilebiliyor. Bu rekey periyodu, anahtarların ne sıklıkla yenileneceğini belirliyor.
Data-At-Rest Encryption: Anahtar Hiyerarşisi
Burası modülün biraz daha karmaşık kısmı, ama mantığını anladığınızda aslında oldukça temiz bir tasarım.
Üç seviyeli bir anahtar hiyerarşisi var:
KEK (Key Encryption Key): vCenter, KMS'ten AES-256 bir KEK talep ediyor. Ama vCenter bu anahtarın kendisini saklamıyor, sadece ID'sini tutuyor.
DEK (Data Encryption Key): ESX host, diski AES-256 XTS modunda şifrelerken DEK kullanıyor. OSA'da her disk için ayrı, rastgele üretilmiş bir DEK var. ESA'da ise cluster'daki tüm diskler aynı DEK'i kullanıyor.
Host Key: Core dump'ları şifrelemek için kullanılıyor, veri için değil. Aynı cluster'daki tüm host'lar aynı host key'i paylaşıyor. Support bundle toplarken core dump'lar rastgele bir anahtarla yeniden şifreleniyor; bu anahtara bir şifre de atayabiliyorsunuz.
Burada OSA-ESA farkı dikkatimi çekti. OSA'da disk başına ayrı DEK varken ESA'da tüm cluster için tek bir DEK kullanılması, anahtar yönetimini basitleştiriyor ama "tek anahtar = tek başarısızlık noktası" sorusunu da aklımıza getiriyor. Tabii bu DEK zaten KEK ile şifrelenmiş halde diskte duruyor, host KEK'i almadan DEK'i kullanamıyor; yani anahtarın kendisi tek başına bir şey ifade etmiyor.
Reboot Davranışı: Dikkat Edilmesi Gereken Bir Nokta
Şunu production açısından önemli buluyorum: Host reboot olduğunda, disk grup'ları KEK'i alana kadar mount edilmiyor. Bu işlem birkaç dakika veya daha uzun sürebiliyor. Yani bir host restart sonrası "neden disk grupları hemen görünmüyor" diye panik yapmadan önce, bu sürecin normal olduğunu bilmek gerekiyor. Durumu vSAN health service > Physical disks > Software state health üzerinden takip edebiliyorsunuz.
Bu, KMS'in erişilebilirliğinin de ne kadar kritik olduğunu gösteriyor. KMS'e erişilemiyorsa host KEK'i alamaz, disk grupları mount olmaz. KMS'in yüksek erişilebilirlikli olması bu yüzden boş bir öneri değil.
DISA STIG ve FIPS 140-2
vSAN, vSAN 6.7'den itibaren FIPS 140-2 doğrulamalı ilk yazılım tabanlı çözüm olma iddiasında. vSAN doğrudan hypervisor'a entegre olduğu için vSphere'in kullandığı kernel modülünü kullanıyor ve bu modül FIPS 140-2 doğrulamasına sahip.
Bu, ABD federal hükümeti gibi belirli regülasyon gereksinimleri olan kurumlar için önemli bir kutu işaretleme maddesi. Aynı zamanda DISA onaylı bir STIG'e (Security Technical Implementation Guide) sahip olan ilk HCI çözümü olarak konumlandırılıyor.
Türkiye'deki bir okuyucu için bu spesifik sertifikasyonlar doğrudan bir gereksinim olmayabilir, ama "bu seviyede bir doğrulamadan geçmiş" bilgisi, ürünün güvenlik mimarisinin ne kadar olgun olduğu konusunda bir gösterge.
Key Management Server: Native Key Provider Kurulumu
vSAN encryption, harici bir Key Management Server, vCenter Server ve ESXi host'ları arasında çalışıyor. vCenter, KMS'ten anahtar talep ediyor; KMS anahtarları üretip saklıyor, vCenter ise sadece anahtar ID'lerinin listesini tutuyor.
HOL'da harici bir KMS kurmak yerine vSAN'ın "Native Key Provider" özelliğini kullanıyoruz. Bu, vCenter'a gömülü bir key provider; ayrı bir KMS sunucusu kurmaya gerek kalmıyor.
Kurulum Adımları
-
vc-mgmt-a.site-a.vcf.labvCenter'ı seçiliyor - Configure
- Security > Key Providers
- ADD
- Add Native Key Provider
Sonra şu bilgiler giriliyor:
- İsim:
vSAN-Native-KP - "Use key provider only with TPM..." kutusu işaretsiz bırakılıyor (nested bir lab ortamı olduğu için TPM mevcut değil)
- ADD KEY PROVIDER
Key Provider eklendiğinde Type "Native", Status ise "Not backed up" olarak görünüyor.
Yedekleme: Atlanmaması Gereken Adım
Burada gerçekten önemli bir nokta var. Key Provider eklendikten sonra BACK-UP butonuna basıp "BACK UP KEY PROVIDER" seçeneği seçiliyor.
Yedekleme tamamlandığında status "Active" oluyor.
Bu adımın HOL'da bir formalite gibi görünmesi mümkün ama gerçek ortamda kritik: Native Key Provider'ın yedeği yoksa ve vCenter kaybedilirse, şifrelenmiş veriye erişim de kaybedilebilir. "Not backed up" durumundaki bir key provider, encryption'ı aktif etmeden önce mutlaka yedeklenmesi gereken bir uyarı sinyali.
vSAN Encryption'ı Etkinleştirmek
vSAN Encryption, vSAN 6.6'dan beri mevcut ve ilk native HCI şifreleme çözümü olarak tanıtılıyor. Birkaç tıkla tüm vSAN datastore için açılıp kapatılabiliyor; ekstra bir adım gerekmiyor.
Hypervisor seviyesinde çalıştığı için VM'den bağımsız (VM Encryption gibi VM'e özgü değil). Donanımdan bağımsız olduğu için de Self-Encrypting Drive (SED) gibi özel ve daha maliyetli donanımlara ihtiyaç yok.
HOL'da data-at-rest encryption zaten önceden etkinleştirilmiş durumda. Bu bölümde yapılan, "shallow rekey" denilen bir işlem; bu, encryption'ı ilk kez açmakla aynı adımları takip ediyor.
Adımlar
-
cluster-esa-01aseçiliyor - Configure
- vSAN > Services
- Data Services altında EDIT
Açılan ekranda:
- Data-at-rest Encryption zaten açık görünüyor
- Key Provider,
nk1'denvSAN-Native-KP'ye değiştiriliyor (her seçenek için bilgi (i) butonuna tıklanarak detay görülebiliyor) - APPLY
İşlem tamamlandığında Data Services genişletilip Key Provider'ın vSAN-Native-KP olarak ayarlandığı doğrulanıyor. Bu noktadan sonra vSAN datastore'a eklenen tüm veri şifreleniyor. Bir anahtar süresi dolarsa veya ele geçirilirse yeni anahtar üretme seçeneği de burada.
Burada dikkatimi çeken şey, bu işlemin "shallow rekey" olarak tanımlanması. Yani mevcut şifrelenmiş veri tamamen yeniden şifrelenmiyor (bu "deep rekey" olurdu, çok daha pahalı bir operasyon); sadece anahtar değişiyor. Production'da deep rekey'in I/O üzerindeki etkisini ayrıca araştırmak gerekir, ama bu HOL bunun ayrımını yapmamıza yardımcı oluyor.
vSAN Encryption Health Check
vSAN, encryption'ın etkin ve sağlıklı olduğunu doğrulamak için health check'lere sahip. Bunlara erişim:
-
cluster-esa-01aseçili, Monitor - vSAN > Skyline Health
- Health findings altında ALL seçiliyor
- Category sütunundaki filtre ikonuna tıklanıyor
- "Data-at-rest encryption" işaretleniyor
Bu kategoride iki health check var.
Kontrol 1: KMS Bağlantısı
"vCenter and all hosts are connected to Key Management Servers" bulgusunun yanındaki üç noktalı menüden "View Current Result" seçiliyor.
Bu kontrol, ESX Key Provider durumunu, bağlantı durumunu ve anahtar durumunu (key state) listeliyor.
Kontrol 2: AES-NI
Aynı kategori altında "CPU AES-NI is enabled on hosts" bulgusunun üç noktalı menüsünden "View Current Result" seçiliyor.
Bu kontrol, cluster'daki ESX host'ların CPU AES-NI özelliğine sahip olup olmadığını doğruluyor. AES-NI, Intel ve AMD işlemcilerde AES şifreleme/deşifreleme işlemlerini hızlandırmak için tasarlanmış bir donanım uzantısı.
Bu kontrolün burada olması mantıklı: AES-NI olmadan şifreleme yazılımsal olarak yapılır ve bu CPU üzerinde belirgin bir yük oluşturur. Modern sunucu işlemcilerinin büyük çoğunluğunda AES-NI zaten var, ama eski donanımla çalışan ortamlarda bu kontrolün kırmızı çıkması, "şifrelemeyi açtık ama performans neden düştü" sorusunun cevabı olabilir.
Genel Değerlendirme
Bu modül, önceki ikisine göre daha "arka plan" bir konuyu işliyor; şifreleme açıldıktan sonra günlük operasyonda görünür bir şey değişmiyor, ama yanlış yapılandırıldığında ya da KMS erişilemez olduğunda etkisi çok görünür hale geliyor.
Benim için en dikkat çekici üç nokta şunlardı:
Birincisi, data-in-transit encryption'ın KMS gerektirmemesi ve tamamen dinamik anahtarlarla çalışması. Bu, "açmamak için bahane bulmak zor" bir özellik; operasyonel yük neredeyse sıfır.
İkincisi, host reboot sırasında disk gruplarının KEK'i bekleyerek mount olması. Bu, KMS'in yüksek erişilebilirlik gereksinimini soyut bir "best practice" maddesinden çıkarıp somut bir bağımlılığa dönüştürüyor. KMS düşerse, sadece yeni anahtar talepleri değil, reboot sonrası disk mount süreçleri de etkileniyor.
Üçüncüsü, Native Key Provider'ın "Not backed up" uyarısı. HOL'da bu adım hızlıca geçiliyor ama gerçek bir ortamda bu, encryption'ı açmadan önce check-list'in en üstünde olması gereken bir madde gibi duruyor.
vSAN'ın şifreleme tarafı, "aç ve unut" gibi pazarlanıyor ve büyük ölçüde de öyle. Ama anahtar yönetimi her zaman böyle; basit görünen arayüzün ardında, bir şeyler ters gittiğinde önemli hale gelen bir bağımlılık zinciri var.
Bir sonraki hafta Modül 4'e geçiyorum.
Bu seri VMware HOL ortamı (HOL-2634-01-VCF-L) üzerinden yürütülmektedir. Buradaki gözlemler lab bağlamında değerlendirilmeli, production ortamı kararları için mutlaka resmi VMware dokümantasyonu ve deneyimli mühendisler referans alınmalıdır.
Top comments (0)