Mimari ve çalışma modeli
Secure Boot, VM'in UEFI başlangıcında yalnız güvenilen imzaya sahip bootloader ve sürücülerin yüklenmesini denetler. vTPM ise anahtar saklama ve ölçümlü başlatma için sanal TPM 2.0 işlevi sunar. İkisi aynı kontrol değildir: Secure Boot izin verilen kod zincirini, vTPM ise ölçüm ve anahtar bağlama yeteneklerini sağlar.
vTPM çoğu platformda VM şifreleme veya ayrı bir anahtar sağlayıcıya bağımlıdır. Bu nedenle VM dosyasını kopyalamak, vTPM kimliğini ve ona bağlı disk şifreleme anahtarlarını otomatik olarak taşımayabilir. Klon, snapshot, yedek, canlı geçiş ve farklı cluster'a taşıma iş akışları platform sürümüne göre test edilmelidir.
Güven zinciri fiziksel host firmware'i, hypervisor, anahtar sağlayıcı, yönetim düzlemi ve misafir işletim sistemini kapsar. vTPM eklemek host'u doğrulanmış hale getirmez; yalnız misafire sanal bir güven kökü sunar. Kurtarma anahtarları vTPM dışında, erişimi denetlenen bağımsız bir yerde tutulmadığında tek host veya KMS kaybı kurtarmayı engelleyebilir.
- 1UEFI firmware
- 2Secure Boot doğrulaması
- 3vTPM ölçümü ve anahtar
- 4Misafir işletim sistemi
Tasarım parametreleri
- Firmware modu
- Yeni VM'de UEFI/Generation 2 uyumluluğunu seçin; BIOS tabanlı eski iş yüklerini yerinde dönüştürmeden önce yedek ve geri dönüş planı hazırlayın.
- Anahtar sağlayıcı
- KMS veya platform anahtar hizmetinin yedeklilik, yetki ve audit yolunu VM'den ayrı tasarlayın.
- Taşınabilirlik
- vTPM kimliğinin klonlama ve migration sırasında kopyalanıp yenilenme davranışını hedef platformda doğrulayın.
- Kurtarma
- Disk şifreleme kurtarma anahtarını vTPM kaybından bağımsız erişilebilir kılın; erişimi iki kişi ve kayıtla sınayın.
Hesap ve uygulama örneği
Bir Windows Server pilotunda Generation 2, Secure Boot ve vTPM etkinleştirin; disk şifrelemeyi yalnız kurtarma anahtarı dışarıda saklandıktan sonra açın. VM'i aynı hostta yeniden başlatın, diğer cluster node'una canlı taşıyın, yedekten izole ortama döndürün ve her aşamada boot ile anahtar açılmasını kaydedin.
Yüz VM'lik ortamda aynı anda vTPM etkinleştirmek yerine işletim sistemi ve uygulama grubuna göre dalga planı kurun. Her dalgada migration, backup restore ve KMS kesintisi testi geçmeden sonraki gruba ilerlemeyin.
Örnek komutlar: laboratuvar değerlerini değiştirin; kullanmadan önce yetkiyi ve yazılım sürümünü doğrulayın.
# Windows misafir örneği
Confirm-SecureBootUEFI
Get-Tpm
manage-bde -status
# Linux misafir örneği
bootctl status
dmesg | grep -i -E 'secure boot|tpm'Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Secure Boot sonrası VM açılmıyor | Bootloader, sürücü veya template imzası güvenilen veritabanıyla uyuşmuyor. | Önce konsol olayını ve firmware template seçimini kontrol edin; korumayı körlemesine kapatmayın. |
| Migration vTPM nedeniyle engelleniyor | Hedef cluster anahtar sağlayıcıyı veya VM donanım sürümünü desteklemiyor. | Kaynak/hedef uyumluluk matrisi, key provider erişimi ve VM sürümünü karşılaştırın. |
| Restore sonrası BitLocker kurtarma istiyor | vTPM ölçümü veya kimliği önceki durumla aynı değil. | Kurtarma anahtarını kullanıp ölçüm değişikliğini audit edin; yanlış VM'e anahtar vermeyin. |
Kabul ve doğrulama kontrolleri
- İmzalanmamış boot medyasının beklenen biçimde engellendiğini doğrulayın.
- Misafir içinde TPM 2.0 görünürlüğünü kontrol edin.
- Canlı migration ve soğuk taşıma işlemlerini ayrı test edin.
- İzole yedek geri dönüşünde kurtarma anahtarını sınayın.
- Anahtar sağlayıcı kesintisinin mevcut ve yeni VM'lere etkisini ölçün.
- Klonlanan VM için yeni veya kopya vTPM kararını belgeleyin.
İlgili kavramlar
Güven sınırı ve hata alanı
Güven sınırı, aynı erişim kararlarını paylaşan bileşenleri ayırır; hata alanı ise tek bir olayın birlikte etkileyebileceği kaynakları tanımlar. İki VLAN kullanmak, aralarında serbest yönlendirme varsa güçlü bir güven sınırı kurmaz. İki yedek aynı yönetici hesabıyla silinebiliyorsa da farklı klasörlerde bulunmaları ayrı hata alanı sağlamaz. Tasarımda fiziksel yer, kimlik sağlayıcı, yönetim hesabı, ağ yolu ve enerji kaynağını ayrı ayrı değerlendirin. Bir bileşen kaybedildiğinde hangi erişimlerin ve kurtarma seçeneklerinin ayakta kalacağını sınayın.
Kimlik doğrulama ve oturum
Kimlik doğrulama kullanıcının veya iş yükünün kim olduğunu kanıtlar; yetkilendirme ise bu kimliğin ne yapabileceğini belirler. Başarılı oturum açma, bütün kaynaklara erişim izni anlamına gelmez. Kullanıcı oturumları, servis kimlikleri, API belirteçleri ve cihaz sertifikaları farklı yaşam döngülerine sahiptir. İlk giriş kadar oturum süresi, belirteç yenileme, işten ayrılma, kayıp cihaz ve acil erişim senaryolarını da tasarlayın. Kimlik sağlayıcı erişilemez olduğunda hangi oturumların süreceğini ve hangi yeni erişimlerin engelleneceğini ölçün.
Şifreleme ve anahtarın yaşam döngüsü
Şifreleme, verinin anahtar olmadan okunmasını zorlaştırır; erişim kontrolü, silinme koruması ve yedekleme farklı ihtiyaçları karşılar. Taşınan veri ile disk üzerindeki veri için hangi katmanın şifreleme sağladığını belirtin. Anahtarların oluşturulması, korunması, döndürülmesi ve acil geri kazanımı tasarımın parçasıdır. Yedeği kurtarmak için gereken anahtar yalnız felaket sırasında kaybedilecek sunucuda bulunmamalıdır. Test ortamında ayrı bir yöneticiyle veriyi açma ve anahtar erişimini geri kazanma adımlarını uygulayın; gerçek anahtarları dokümana veya destek mesajına koymayın.
Bağımlılık ve geri açılış sırası
Bir hizmet çoğu zaman kimlik, DNS, zaman, ağ, veritabanı ve lisans servislerine bağlıdır. Bağımlılıkları yalnız cihaz listesi olarak değil, hangi hizmetin hangi koşulla çalışabildiğini gösteren bir grafik olarak kaydedin. Geri açılış sırası buna göre belirlenir; bazı döngüsel bağımlılıklar özel acil erişim gerektirir. Çalışan altyapı bileşenleri ile işin yeniden başlayabildiği anı ayırın. Her bağımlılığa sorumlu, doğrulama yöntemi ve alternatif erişim yolu atayın. Uçtan uca testte bir bileşeni bilerek erişilemez hale getirerek varsayımları sınayın.
Yüksek erişilebilirlik ile kurtarma ayrımı
Yüksek erişilebilirlik, belirli arızalarda hizmetin kısa kesintiyle sürmesini hedefler; yedekleme, kaybolan veya bozulan veriyi önceki bir noktadan geri getirir. Bir küme yanlış silinen kaydı diğer düğüme de aktarabilir. Bu nedenle HA ve backup birbirinin yerine geçmez. Hizmetin DNS, kimlik, ağ, depolama ve enerji bağımlılıklarını birlikte düşünün. Başarılı düğüm geçişi tek başına yeterli değildir: kullanıcı oturumunun, uygulama yazmasının ve dış entegrasyonların geçiş sonrası davranışı da ölçülmelidir.
Sürüm ve destek yaşam döngüsü
Bir ürünün kurulabilir olması üretim için desteklendiğini kanıtlamaz. İşletim sistemi, uygulama, sürücü, eklenti ve yönetim aracının uyumluluk zincirini birlikte kontrol edin. Güncelleme planında paket sürümü, destek bitişi, yeniden başlatma gereksinimi ve geri alma yöntemi bulunmalıdır. Test ortamı üretimdeki bağımlılıkları temsil etmezse sonuç yanıltıcı olabilir. Değişiklik sonrası yalnız sürüm numarasını değil, hizmet sağlığını ve önceki iş akışlarını doğrulayın. Bir sürümü sabitlemenin gelecekteki güvenlik düzeltmelerini engelleyebileceğini de dikkate alın.
Birincil teknik dokümantasyon
Doz Teknoloji teknik ekibi tarafından aşağıdaki birincil kaynaklar temel alınarak hazırlanmıştır. Hesaplar ve laboratuvar senaryoları varsayımlarını belirtir; uygulamadan önce kullanılan ürün sürümünü doğrulayın.