Udostępnij za pośrednictwem

Zarządzanie usługą Ochrona hosta

Host Guardian Service (HGS) jest centralnym elementem rozwiązania chronionej infrastruktury. Jest odpowiedzialny za to, aby hosty Hyper-V w strukturze były znane dostawcy usług hostingowych lub przedsiębiorstwu, za uruchamianie zaufanego oprogramowania oraz za zarządzanie kluczami używanymi do uruchamiania chronionych maszyn wirtualnych. Gdy najemca zdecyduje się powierzyć ci hosting swoich chronionych maszyn wirtualnych, pokładają zaufanie w twojej konfiguracji i zarządzaniu usługą Host Guardian. W związku z tym bardzo ważne jest stosowanie najlepszych praktyk podczas zarządzania usługą Ochrony hosta w celu zapewnienia bezpieczeństwa, dostępności i niezawodności ochranianej infrastruktury. Wskazówki opisane w poniższych sekcjach dotyczą najczęstszych problemów operacyjnych, z którymi borykają się administratorzy usługi HGS.

Ograniczanie dostępu administratora do usługi HGS

Ze względu na istotność bezpieczeństwa usługi HGS ważne jest, aby jej administratorzy byli wysoce zaufanymi członkami Twojej organizacji i, najlepiej, oddzieleni od administratorów zasobów infrastruktury. Ponadto zaleca się zarządzanie usługą HGS tylko z bezpiecznych stacji roboczych przy użyciu bezpiecznych protokołów komunikacyjnych, takich jak Usługa WinRM za pośrednictwem protokołu HTTPS.

Rozdzielenie obowiązków

Podczas konfigurowania usługi HGS można utworzyć izolowany las usługi Active Directory tylko dla usługi HGS lub dołączyć usługę HGS do istniejącej, zaufanej domeny. Ta decyzja, a także role, które przypisujesz administratorom w organizacji, określają granicę zaufania dla usługi HGS. Ktokolwiek ma dostęp do HGS, niezależnie od tego, czy jako bezpośredni administrator, czy też pośrednio jako administrator innych systemów (np. Active Directory), które mogą wpływać na HGS, ma kontrolę nad chronioną infrastrukturą. Administratorzy usługi HGS wybierają, które hosty Hyper-V są autoryzowane do uruchamiania chronionych maszyn wirtualnych i zarządzania certyfikatami niezbędnymi do uruchamiania chronionych maszyn wirtualnych. Osoba atakująca lub złośliwy administrator, który ma dostęp do usługi HGS, może użyć tej możliwości, aby autoryzować naruszone hosty do uruchamiania chronionych maszyn wirtualnych, inicjować atak typu "odmowa usługi", usuwając materiał klucza i nie tylko.

Aby uniknąć tego ryzyka, zdecydowanie zaleca się ograniczenie nakładania się między administratorami usługi HGS (w tym domeny, do której jest przyłączona usługa HGS) i środowiskami Hyper-V. Dzięki zapewnieniu, że żaden administrator nie ma dostępu do obu systemów, osoba atakująca musi naruszyć 2 różne konta od 2 osób, aby ukończyć swoją misję zmiany zasad usługi HGS. Oznacza to również, że administratorzy domeny i korporacyjni dla dwóch środowisk Active Directory nie powinni być tą samą osobą, ani HGS nie powinien używać tego samego lasu Active Directory co hosty Hyper-V. Każdy, kto może udzielić sobie dostępu do większej liczby zasobów, stanowi zagrożenie bezpieczeństwa.

Używanie funkcji Just Enough Administration

Usługa HGS zawiera role Just Enough Administration (JEA), które umożliwiają zarządzanie nimi bardziej bezpiecznie. JeA pomaga, umożliwiając delegowanie zadań administratora do użytkowników niebędących administratorami, co oznacza, że osoby zarządzające zasadami usługi HGS nie muszą być administratorami całej maszyny lub domeny. JEA działa, ograniczając to, jakie polecenia użytkownik może uruchomić w sesji programu PowerShell, i korzystając z tymczasowego lokalnego konta w tle (unikatowego dla każdej sesji użytkownika) do uruchamiania poleceń, które normalnie wymagają podniesienia uprawnień.

Usługa HGS jest dostarczana ze wstępnie skonfigurowanymi rolami JEA 2:

  • Administratorzy HGS, którzy umożliwiają użytkownikom zarządzanie wszystkimi zasadami usługi HGS, w tym autoryzowanie nowych hostów do uruchamiania chronionych maszyn wirtualnych.
  • recenzentów HGS, którzy zezwalają tylko użytkownikom na audyt istniejących zasad. Nie mogą wprowadzać żadnych zmian w konfiguracji usługi HGS.

Aby użyć narzędzia JEA, należy najpierw utworzyć nowego użytkownika standardowego i utworzyć go jako członka grupy administratorów usługi HGS lub recenzentów usługi HGS. Jeśli użyto Install-HgsServer do skonfigurowania nowego lasu dla usługi HGS, te grupy będą mieć nazwę "nazwa usługiAdministratorzy" i "nazwa usługiRecenzenci", odpowiednio, gdzie nazwa usługi jest nazwą sieci klastra HGS. Jeśli usługa HGS została przyłączona do istniejącej domeny, należy odwołać się do nazw grup określonych w Initialize-HgsServer.

Tworzenie użytkowników standardowych dla ról administratora i recenzenta usługi HGS

$hgsServiceName = (Get-ClusterResource HgsClusterResource | Get-ClusterParameter DnsName).Value
$adminGroup = $hgsServiceName + "Administrators"
$reviewerGroup = $hgsServiceName + "Reviewers"

New-ADUser -Name 'hgsadmin01' -AccountPassword (Read-Host -AsSecureString -Prompt 'HGS Admin Password') -ChangePasswordAtLogon $false -Enabled $true
Add-ADGroupMember -Identity $adminGroup -Members 'hgsadmin01'

New-ADUser -Name 'hgsreviewer01' -AccountPassword (Read-Host -AsSecureString -Prompt 'HGS Reviewer Password') -ChangePasswordAtLogon $false -Enabled $true
Add-ADGroupMember -Identity $reviewerGroup -Members 'hgsreviewer01'

Zasady inspekcji przy użyciu roli recenzenta

Na maszynie zdalnej, która ma łączność sieciową z usługą HGS, uruchom następujące polecenia w programie PowerShell, aby wprowadzić sesję JEA przy użyciu poświadczeń recenzenta. Należy pamiętać, że ponieważ konto recenzenta jest tylko standardowym użytkownikiem, nie może być używane do zdalnej komunikacji za pomocą Windows PowerShell, zdalnego dostępu do Host Guardian Service (HGS) itp.

Enter-PSSession -ComputerName <hgsnode> -Credential '<hgsdomain>\hgsreviewer01' -ConfigurationName 'microsoft.windows.hgs'

Następnie możesz sprawdzić, które polecenia są dozwolone w sesji z Get-Command i uruchomić wszystkie dozwolone polecenia, aby przeprowadzić inspekcję konfiguracji. W poniższym przykładzie sprawdzamy, które zasady są włączone w usłudze HGS.

Get-Command

Get-HgsAttestationPolicy

Wpisz polecenie Exit-PSSession lub jego alias, exit, po zakończeniu pracy z sesją JEA.

Dodawanie nowych zasad do usługi HGS przy użyciu roli administratora

Aby rzeczywiście zmienić politykę, musisz połączyć się z punktem końcowym JEA z tożsamością należącą do grupy „hgsAdministrators”. W poniższym przykładzie pokazano, jak można skopiować nowe zasady integralności kodu do usługi HGS i zarejestrować je przy użyciu narzędzia JEA. Składnia może się różnić od tego, do czego jesteś przyzwyczajony. Ma to na celu uwzględnienie niektórych ograniczeń w JEA, takich jak brak dostępu do pełnego systemu plików.

$cipolicy = Get-Item "C:\temp\cipolicy.p7b"
$session = New-PSSession -ComputerName <hgsnode> -Credential '<hgsdomain>\hgsadmin01' -ConfigurationName 'microsoft.windows.hgs'
Copy-Item -Path $cipolicy -Destination 'User:' -ToSession $session

# Now that the file is copied, we enter the interactive session to register it with HGS
Enter-PSSession -Session $session
Add-HgsAttestationCiPolicy -Name 'New CI Policy via JEA' -Path 'User:\cipolicy.p7b'

# Confirm it was added successfully
Get-HgsAttestationPolicy -PolicyType CiPolicy

# Finally, remove the PSSession since it is no longer needed
Exit-PSSession
Remove-PSSession -Session $session

Monitorowanie usługi HGS

Źródła zdarzeń i przekazywanie dalej

Zdarzenia z usługi HGS będą wyświetlane w dzienniku zdarzeń systemu Windows w 2 źródłach:

  • HostGuardianService-Attestation
  • HostGuardianService-KeyProtection

Możesz wyświetlić te zdarzenia, otwierając Podgląd zdarzeń i przechodząc do Microsoft-Windows-HostGuardianService-Attestation oraz Microsoft-Windows-HostGuardianService-KeyProtection.

W dużym środowisku często zaleca się przekazywanie zdarzeń do centralnego modułu zbierającego zdarzenia systemu Windows, aby ułatwić analizowanie zdarzeń. Aby uzyskać więcej informacji, zapoznaj się z dokumentacją przekazywania zdarzeń systemu Windows .

Korzystanie z programu System Center Operations Manager

Można również użyć programu Operations Manager w System Center 2016 do monitorowania usługi HGS i chronionych hostów. Chroniony pakiet administracyjny sieci szkieletowej zawiera monitory zdarzeń umożliwiające sprawdzenie typowych błędów konfiguracji, które mogą prowadzić do przestoju centrum danych, w tym hostów, które nie przekazują zaświadczania i serwerów HGS zgłaszających błędy.

Aby rozpocząć, zainstalować i skonfigurować SCOM 2016 oraz pobrać pakiet zarządzania chronioną infrastrukturą. W dołączonym przewodniku po pakiecie administracyjnym wyjaśniono, jak skonfigurować pakiet administracyjny i zrozumieć zakres jego monitorów.

Tworzenie kopii zapasowych i przywracanie HGS

Planowanie odzyskiwania po awarii

Podczas tworzenia planów odzyskiwania po awarii należy wziąć pod uwagę unikatowe wymagania Host Guardian Service w chronionej infrastrukturze. W przypadku utraty niektórych lub wszystkich węzłów usługi HGS mogą wystąpić natychmiastowe problemy z dostępnością, które uniemożliwią użytkownikom uruchamianie chronionych maszyn wirtualnych. W scenariuszu, w którym utracisz cały klaster usługi HGS, należy utworzyć pełne kopie zapasowe konfiguracji usługi HGS pod ręką, aby przywrócić klaster usługi HGS i wznowić normalne operacje. W tej sekcji opisano kroki niezbędne do przygotowania się do takiego scenariusza.

Najpierw ważne jest, aby zrozumieć, co w HGS jest ważne do wykonania kopii zapasowej. Usługa HGS zachowuje kilka informacji, które pomagają określić, które hosty są autoryzowane do uruchamiania chronionych maszyn wirtualnych. Obejmuje to:

  1. Identyfikatory zabezpieczeń usługi Active Directory dla grup zawierających zaufane hosty (w przypadku korzystania z zaświadczania usługi Active Directory);
  2. Unikatowe identyfikatory modułu TPM dla każdego hosta w danym środowisku;
  3. Zasady modułu TPM dla każdej unikatowej konfiguracji hosta; i
  4. Zasady integralności kodu określające, które oprogramowanie może być uruchamiane na hostach.

Te artefakty zaświadczania wymagają koordynacji z administratorami infrastruktury hostingowej w celu ich uzyskania, co może potencjalnie utrudnić ponowne zdobycie tych informacji po awarii.

Ponadto usługa HGS wymaga dostępu do 2 lub większej liczby certyfikatów używanych do szyfrowania i podpisywania informacji wymaganych do uruchomienia chronionej maszyny wirtualnej (ochrony klucza). Te certyfikaty są dobrze znane (używane przez właścicieli chronionych maszyn wirtualnych do autoryzowania infrastruktury do uruchamiania ich maszyn wirtualnych) i muszą zostać przywrócone po awarii w celu zapewnienia bezproblemowego odzyskiwania. Jeśli usługa HGS nie zostanie przywrócona z tymi samymi certyfikatami po awarii, każda maszyna wirtualna musi zostać zaktualizowana, aby autoryzować nowe klucze w celu odszyfrowania ich informacji. Ze względów bezpieczeństwa tylko właściciel maszyny wirtualnej może zaktualizować konfigurację maszyny wirtualnej, aby autoryzować te nowe klucze, co oznacza, że niepowodzenie przywracania kluczy po awarii spowoduje, że każdy właściciel maszyny wirtualnej będzie musiał podjąć działania w celu ponownego uruchomienia maszyn wirtualnych.

Przygotowanie na najgorsze

Aby przygotować się do całkowitej utraty usługi HGS, należy wykonać 2 kroki:

  1. Tworzenie kopii zapasowej zasad zaświadczania HGS
  2. Wykonaj kopię zapasową kluczy HGS

Wskazówki dotyczące wykonywania obu tych kroków podano w sekcji Tworzenie kopii zapasowej usługi HGS.

Ponadto jest to zalecane, ale nie jest wymagane, aby utworzyć kopię zapasową listy użytkowników autoryzowanych do zarządzania usługą HGS w domenie usługi Active Directory lub samej usłudze Active Directory.

Należy regularnie wykonywać kopie zapasowe, aby upewnić się, że informacje są aktualne i przechowywane w bezpieczny sposób, aby uniknąć naruszenia lub kradzieży.

Nie zaleca się tworzenia kopii zapasowej ani próby przywrócenia całego obrazu systemu węzła usługi HGS. W przypadku utraty całego klastra najlepszym rozwiązaniem jest skonfigurowanie zupełnie nowego węzła usługi HGS i przywrócenie tylko stanu usługi HGS, a nie całego systemu operacyjnego serwera.

Odzyskiwanie po utracie jednego węzła

Jeśli utracisz jeden lub więcej węzłów (ale nie każdy węzeł) w klastrze HGS, możesz po prostu dodać węzły do klastra zgodnie z przewodnikiem wdrażania. Zasady zaświadczania będą synchronizowane automatycznie, podobnie jak wszystkie certyfikaty, które zostały dostarczone do usługi HGS jako pliki PFX z towarzyszącymi hasłami. W przypadku certyfikatów dodanych do usługi HGS przy użyciu odcisku palca (certyfikaty wspierane przez sprzęt i certyfikaty, które nie można eksportować, często), należy upewnić się, że każdy nowy węzeł ma dostęp do klucza prywatnego każdego certyfikatu.

Odzyskiwanie po utracie całego klastra

Jeśli cały klaster usługi HGS ulegnie awarii i nie możesz przywrócić go z powrotem do trybu online, musisz przywrócić usługę HGS z kopii zapasowej. Przywracanie usługi HGS z kopii zapasowej obejmuje najpierw skonfigurowanie nowego klastra HGS zgodnie ze wskazówkami dotyczącymi w przewodniku wdrażania. Zdecydowanie zaleca się używanie tej samej nazwy klastra, ale nie jest to wymagane podczas konfigurowania środowiska odzyskiwania usługi HGS w celu ułatwienia rozpoznawania nazw z hostów. Użycie tej samej nazwy pozwala uniknąć konieczności ponownego konfigurowania hostów przy użyciu nowych adresów URL zaświadczania i ochrony kluczy. W przypadku przywrócenia obiektów do domeny usługi Active Directory obsługującej usługę HGS zaleca się usunięcie obiektów reprezentujących klaster HGS, komputery, konto usługi i grupy JEA przed zainicjowanie serwera HGS.

Po skonfigurowaniu pierwszego węzła usługi HGS (na przykład został on zainstalowany i zainicjowany), należy wykonać procedury opisane w Przywracanie usługi HGS z kopii zapasowej, aby przywrócić zasady uwierzytelniania oraz publiczne części certyfikatów ochrony kluczy. Należy ręcznie przywrócić klucze prywatne dla certyfikatów zgodnie ze wskazówkami dostawcy certyfikatów (np. zaimportować certyfikat w systemie Windows lub skonfigurować dostęp do certyfikatów opartych na module HSM). Po skonfigurowaniu pierwszego węzła można kontynuować instalację dodatkowych węzłów w klastrze, aż do osiągnięcia pożądanej wydajności i odporności.

Tworzenie kopii zapasowej usługi HGS

Administrator usługi HGS powinien regularnie odpowiadać za tworzenie kopii zapasowych usługi HGS. Kompletna kopia zapasowa będzie zawierać materiał klucza poufnego, który musi być odpowiednio zabezpieczony. Jeśli niezaufana jednostka uzyska dostęp do tych kluczy, może użyć tego materiału do skonfigurowania złośliwego środowiska HGS w celu naruszania chronionych maszyn wirtualnych.

Tworzenie kopii zapasowych zasad zaświadczania Aby utworzyć kopię zapasową zasad zaświadczania HGS, uruchom następujące polecenie w dowolnym działającym węźle serwera HGS. Zostanie wyświetlony monit o podanie hasła. To hasło służy do szyfrowania wszystkich certyfikatów dodanych do usługi HGS przy użyciu pliku PFX (zamiast odcisku palca certyfikatu).

Export-HgsServerState -Path C:\temp\HGSBackup.xml

Uwaga

Jeśli używasz zaświadczania zaufanego przez administratora, musisz oddzielnie utworzyć kopię zapasową członkostwa w grupach zabezpieczeń używanych przez usługę HGS do autoryzowania chronionych hostów. Usługa HGS utworzy kopię zapasową tylko identyfikatora SID grup zabezpieczeń, ale nie członkostwa tych grup. W przypadku utraty tych grup podczas awarii należy ponownie utworzyć grupy i ponownie dodać do nich każdego chronionego hosta.

tworzenie kopii zapasowych certyfikatów

Polecenie Export-HgsServerState utworzy kopię zapasową wszystkich certyfikatów opartych na formacie PFX dodanych do usługi HGS w momencie uruchomienia polecenia. Jeśli dodano certyfikaty do usługi HGS przy użyciu odcisku palca (typowe dla certyfikatów nienależących do eksportu i certyfikatów opartych na sprzęcie), należy ręcznie utworzyć kopię zapasową kluczy prywatnych dla certyfikatów. Aby określić, które certyfikaty są zarejestrowane w usłudze HGS i należy wykonać kopię zapasową ręcznie, uruchom następujące polecenie programu PowerShell w dowolnym działającym węźle serwera usługi HGS.

Get-HgsKeyProtectionCertificate | Where-Object { $_.CertificateData.GetType().Name -eq 'CertificateReference' } | Format-Table Thumbprint, @{ Label = 'Subject'; Expression = { $_.CertificateData.Certificate.Subject } }

Dla każdego z wymienionych certyfikatów należy ręcznie utworzyć kopię zapasową klucza prywatnego. Jeśli używasz certyfikatu opartego na oprogramowaniu, który nie jest eksportowalny, skontaktuj się z urzędem certyfikacji, aby upewnić się, że ma on kopię zapasową certyfikatu i/lub może go ponownie wystawiać na żądanie. W przypadku certyfikatów utworzonych i przechowywanych w sprzętowych modułach zabezpieczeń należy zapoznać się z dokumentacją urządzenia, aby uzyskać wskazówki dotyczące planowania odzyskiwania po awarii.

Kopie zapasowe certyfikatów należy przechowywać wraz z kopiami zapasowymi zasad zaświadczania w bezpiecznej lokalizacji, aby oba elementy mogły zostać przywrócone razem.

dodatkowa konfiguracja w celu tworzenia kopii zapasowej

Stan kopii zapasowej serwera HGS nie będzie zawierać nazwy klastra HGS, żadnych informacji z Active Directory ani żadnych certyfikatów SSL używanych do zabezpieczania komunikacji z interfejsami API HGS. Te ustawienia są ważne dla spójności, ale nie mają krytycznego znaczenia, aby klaster HGS wrócił do trybu online po awarii.

Aby przechwycić nazwę usługi HGS, uruchom Get-HgsServer i zanotuj uproszczoną nazwę w adresach URL atestacji i ochrony kluczy. Jeśli na przykład adres URL zaświadczania to "https://hgs.contoso.com/Attestation", "hgs" to nazwa usługi HGS.

Domena usługi Active Directory używana przez usługę HGS powinna być zarządzana jak każda inna domena usługi Active Directory. Podczas przywracania usługi HGS po awarii nie musisz ponownie utworzyć dokładnych obiektów znajdujących się w bieżącej domenie. Jednak proces odzyskiwania będzie łatwiejszy, jeśli wykonasz kopię zapasową Active Directory oraz będziesz prowadzić aktualną listę użytkowników JEA, którzy są autoryzowani do zarządzania systemem, a także członkostwo w dowolnych grupach zabezpieczeń używanych przez poświadczenia zaufane przez administratorów do autoryzacji chronionych hostów.

Aby zidentyfikować odcisk palca certyfikatów SSL skonfigurowanych dla usługi HGS, uruchom następujące polecenie w programie PowerShell. Następnie można utworzyć kopię zapasową tych certyfikatów SSL zgodnie z instrukcjami dostawcy certyfikatów.

Get-WebBinding -Protocol https | Select-Object certificateHash

Przywracanie usługi HGS z kopii zapasowej

W poniższych krokach opisano sposób przywracania ustawień usługi HGS z kopii zapasowej. Zarówno w sytuacjach, w których próbujesz cofnąć zmiany wprowadzone w już uruchomionych wystąpieniach usługi HGS, jak i gdy tworzysz nowy klaster HGS po całkowitej utracie poprzedniego, kroki są istotne.

Konfigurowanie zastępczego klastra usługi HGS

Przed przywróceniem usługi HGS musisz mieć zainicjowany klaster HGS, do którego można przywrócić konfigurację. Jeśli po prostu importujesz ustawienia, które zostały przypadkowo usunięte z istniejącego klastra (uruchomionego), możesz pominąć ten krok. W przypadku odzyskiwania po całkowitej utracie usługi HGS należy zainstalować i zainicjować co najmniej jeden węzeł usługi HGS zgodnie ze wskazówkami w przewodniku wdrażania.

W szczególności należy wykonać następujące kroki:

  1. Konfigurowanie domeny usługi HGS lub dołączanie usługi HGS do istniejącej domeny
  2. Zainicjuj serwer HGS przy użyciu istniejących kluczy lub zestawu kluczy tymczasowych. Można usunąć klucze tymczasowe po zaimportowaniu rzeczywistych kluczy z plików kopii zapasowych systemu HGS.
  3. Importowanie ustawień HGS z kopii zapasowej w celu przywrócenia zaufanych grup hostów, zasad integralności kodu, punktów odniesienia modułu TPM i identyfikatorów modułu TPM

Wskazówka

Nowy klaster usługi HGS nie musi używać tych samych certyfikatów, nazwy usługi lub domeny co wystąpienie usługi HGS, z którego został wyeksportowany plik kopii zapasowej.

Importowanie ustawień z kopii zapasowej

Aby przywrócić zasady zaświadczania, certyfikaty oparte na protokole PFX i klucze publiczne certyfikatów innych niż PFX do węzła usługi HGS z pliku kopii zapasowej, uruchom następujące polecenie w zainicjowanym węźle serwera HGS. Zostanie wyświetlony monit o wprowadzenie hasła określonego podczas tworzenia kopii zapasowej.

Import-HgsServerState -Path C:\Temp\HGSBackup.xml

Jeśli chcesz zaimportować tylko zasady zaświadczania zaufane przez administratora lub zasady zaświadczania zaufane przez moduł TPM, możesz to zrobić, określając flagi -ImportActiveDirectoryModeState lub -ImportTpmModeState do Import-HgsServerState.

Przed uruchomieniem programu Import-HgsServerStateupewnij się, że zainstalowano najnowszą aktualizację zbiorczą dla systemu Windows Server 2016. Niepowodzenie w tym celu może spowodować wystąpienie błędu importu.

Uwaga

Jeśli odtwarzasz zasady na istniejącym węźle usługi HGS, który ma już co najmniej jedną z tych zasad, polecenie importu zgłosi błąd dla każdej zduplikowanej zasady. Jest to oczekiwane zachowanie i można je bezpiecznie zignorować w większości przypadków.

Ponowne instalowanie kluczy prywatnych dla certyfikatów

Jeśli którykolwiek z certyfikatów używanych w usłudze HGS, z których utworzono kopię zapasową, zostały dodane przy użyciu odcisków palca, tylko klucz publiczny tych certyfikatów zostanie uwzględniony w pliku kopii zapasowej. Oznacza to, że należy ręcznie zainstalować i/lub udzielić dostępu do kluczy prywatnych dla każdego z tych certyfikatów, zanim usługa HGS będzie mogła obsługiwać żądania z Hyper-V hostów. Akcje niezbędne do wykonania tego kroku różnią się w zależności od tego, jak certyfikat został pierwotnie wystawiony. W przypadku certyfikatów opartych na oprogramowaniu wystawionych przez urząd certyfikacji należy skontaktować się z urzędem certyfikacji, aby uzyskać klucz prywatny i zainstalować go na każdym węźle usługi HGS zgodnie z instrukcjami. Podobnie, jeśli certyfikaty są obsługiwane przez sprzęt, należy zapoznać się z dokumentacją dostawcy sprzętowego modułu zabezpieczeń, aby zainstalować niezbędne sterowniki w każdym węźle usługi HGS w celu nawiązania połączenia z modułem HSM i udzielenia każdemu maszynie dostępu do klucza prywatnego.

Przypominamy, że certyfikaty dodane do usługi HGS przy użyciu odcisków palca wymagają ręcznej replikacji kluczy prywatnych do każdego węzła. Ten krok należy powtórzyć w każdym dodatkowym węźle dodanym do przywróconego klastra usługi HGS.

Przeglądanie zaimportowanych zasad zaświadczania

Po zaimportowaniu ustawień z kopii zapasowej zaleca się dokładne przejrzenie wszystkich zaimportowanych zasad przy użyciu Get-HgsAttestationPolicy, aby upewnić się, że tylko zaufane hosty do uruchamiania chronionych maszyn wirtualnych będą mogły pomyślnie potwierdzić. Jeśli znajdziesz jakiekolwiek zasady, które nie są już zgodne ze stanem zabezpieczeń, możesz wyłączyć lub usunąć je.

Uruchamianie diagnostyki w celu sprawdzenia stanu systemu

Po zakończeniu konfigurowania i przywracania stanu węzła usługi HGS należy uruchomić narzędzie diagnostyczne usługi HGS, aby sprawdzić stan systemu. W tym celu uruchom następujące polecenie w węźle usługi HGS, w którym przywrócono konfigurację:

Get-HgsTrace -RunDiagnostics

Jeśli "Ogólny wynik" nie jest "Pass", do ukończenia konfigurowania systemu są wymagane dodatkowe kroki. Sprawdź komunikaty zgłoszone w podtestach, które nie powiodły się, aby uzyskać więcej informacji.

Instalowanie poprawek HGS

Ważne jest, aby węzły usługi Host Guardian Service (HGS) były aktualne, instalując najnowszą aktualizację zbiorczą, gdy stanie się ona dostępna. Jeśli konfigurujesz zupełnie nowy węzeł HGS, zdecydowanie zaleca się zainstalowanie wszelkich dostępnych aktualizacji przed zainstalowaniem roli usługi HGS lub jego skonfigurowaniem. Zapewni to natychmiastowe zastosowanie nowych lub zmienionych funkcji.

W przypadku aktualizowania poprawek chronionej infrastruktury zaleca się najpierw uaktualnienie wszystkich hostów Hyper-V przed uaktualnieniem usługi HGS. Ma to na celu zapewnienie, że wszelkie zmiany zasad zaświadczania w usłudze HGS zostaną wprowadzone po aktualizacji hostów Hyper-V w celu dostarczenia wymaganych informacji. Jeśli aktualizacja zmieni zachowanie zasad, nie zostaną one automatycznie włączone, aby uniknąć zakłócania działania infrastruktury. Takie aktualizacje wymagają, aby postępować zgodnie ze wskazówkami w poniższej sekcji, aby aktywować nowe lub zmienione zasady zaświadczania. Zachęcamy do przeczytania informacji o wersji dla systemu Windows Server i wszelkich aktualizacji zbiorczych instalowanych w celu sprawdzenia, czy aktualizacje zasad są wymagane.

Aktualizacje wymagające aktywacji zasad

Jeśli aktualizacja usługi HGS wprowadza lub znacząco zmienia zachowanie zasad zaświadczania, wymagany jest dodatkowy krok aktywowania zmienionych zasad. Zmiany zasad są wdrażane tylko po wyeksportowaniu i zaimportowaniu stanu HGS. Nowe lub zmienione zasady należy aktywować tylko po zastosowaniu aktualizacji zbiorczej do wszystkich hostów i wszystkich węzłów usługi HGS w danym środowisku. Po zaktualizowaniu każdej maszyny uruchom następujące polecenia w dowolnym węźle usługi HGS, aby wyzwolić proces uaktualniania:

$password = Read-Host -AsSecureString -Prompt "Enter a temporary password"
Export-HgsServerState -Path .\temporaryExport.xml -Password $password
Import-HgsServerState -Path .\temporaryExport.xml -Password $password

Jeśli wprowadzono nowe zasady, zostanie ona domyślnie wyłączona. Aby włączyć nowe zasady, najpierw znajdź ją na liście zasad firmy Microsoft (poprzedzonych prefiksem "HGS_"), a następnie włącz ją przy użyciu następujących poleceń:

Get-HgsAttestationPolicy

Enable-HgsAttestationPolicy -Name <Hgs_NewPolicyName>

Zarządzanie zasadami zaświadczania

Usługa HGS utrzymuje kilka polityk atestacji, które definiują minimalny zestaw wymagań, jakie musi spełnić host, aby mógł być uznany za "zdrowy" i dopuszczony do uruchamiania chronionych maszyn wirtualnych. Niektóre z tych zasad są definiowane przez firmę Microsoft. Inne są dodawane przez Użytkownika w celu zdefiniowania zasad integralności kodu, punktów odniesienia modułu TPM i hostów w danym środowisku. Regularna konserwacja tych zasad jest niezbędna, aby hosty mogły kontynuować prawidłowe poświadczenie podczas ich aktualizowania i zastępowania oraz aby zapewnić, że wszystkie niezaufane hosty lub konfiguracje nie będą mogły pomyślnie dokonać poświadczenia.

W przypadku zaświadczania zaufanego przez administratora istnieje tylko jedna zasada określająca, czy host jest w dobrej kondycji: członkostwo w znanej zaufanej grupie zabezpieczeń. Atesty modułu TPM są bardziej skomplikowane i obejmują różne polityki dotyczące mierzenia kodu i konfiguracji systemu przed ustaleniem, czy jest w dobrej kondycji.

Pojedynczą instancję HGS można skonfigurować zarówno przy użyciu modułu Active Directory, jak i zasad modułu TPM, ale usługa sprawdzi tylko zasady dla bieżącego trybu, dla którego jest skonfigurowana podczas próby atestu hosta. Aby sprawdzić tryb serwera HGS, uruchom polecenie Get-HgsServer.

Domyślne zasady

W przypadku zaświadczania, do którego jest używany zaufany moduł TPM, istnieje kilka wbudowanych zasad skonfigurowanych w usłudze HGS. Niektóre z tych zasad są "zablokowane" — co oznacza, że nie można ich wyłączyć ze względów bezpieczeństwa. W poniższej tabeli wyjaśniono przeznaczenie poszczególnych zasad domyślnych.

Nazwa zasad Przeznaczenie
Hgs_SecureBootEnabled Wymaga, aby hosty miały włączony bezpieczny rozruch. Jest to konieczne do mierzenia plików binarnych startowych i innych ustawień zablokowanych przez UEFI.
Hgs_UefiDebugDisabled Gwarantuje, że hosty nie mają włączonego debugera jądra. Debugery trybu użytkownika są blokowane przy użyciu zasad integralności kodu.
Hgs_SecureBootSettings Polityka negatywna wymuszająca, aby hosty były zgodne z co najmniej jedną (zdefiniowaną przez administratora) bazą odniesienia TPM.
Hgs_CiPolicy Polityka negatywna mająca na celu zapewnienie, że hosty korzystają z jednej z administrowanych przez administratora polityk ciągłej integracji.
Hgs_HypervisorEnforcedCiPolicy (Polityka wymuszana przez hipernadzorcę) Wymaga, aby polisa integralności kodu była egzekwowana przez hypervisor. Wyłączenie tej polityki osłabia ochronę przed atakami na politykę integralności kodu trybu jądra.
Hgs_FullBoot Gwarantuje, że host nie wznowił pracy ze stanu uśpienia ani hibernacji. Aby spełnić wymagania tej polityki, hosty muszą być prawidłowo ponownie uruchomione lub zamknięte.
Hgs_VsmIdkPresent Wymaga, aby zabezpieczenia oparte na wirtualizacji działały na hoście. Klucz IDK reprezentuje klucz niezbędny do szyfrowania informacji wysyłanych z powrotem do bezpiecznego miejsca na pamięć hosta.
Hgs_PageFileEncryptionEnabled Wymaga szyfrowania plików stronicowania na hoście. Wyłączenie tej polityki może spowodować ujawnienie informacji, jeśli niezaszyfrowany plik stronicowania zostanie sprawdzony pod kątem tajemnic klienta.
Hgs_BitLockerEnabled (BitLocker włączony) Wymaga włączenia funkcji BitLocker na hoście Hyper-V. Te zasady są domyślnie wyłączone ze względu na wydajność i nie zaleca się ich włączania. Te zasady nie mają wpływu na szyfrowanie samych chronionych maszyn wirtualnych.
Hgs_IommuEnabled Wymaga, aby host miał używane urządzenie IOMMU, aby zapobiec bezpośrednim atakom na dostęp do pamięci. Wyłączenie tej polityki i używanie hostów bez włączonego interfejsu IOMMU może narażać tajemnice maszyny wirtualnej dzierżawcy na bezpośrednie ataki na pamięć.
Hgs_NoHibernation Wymaga wyłączenia hibernacji na hoście Hyper-V. Wyłączenie tych zasad może umożliwić hostom zapisywanie chronionej pamięci maszyny wirtualnej w niezaszyfrowanym pliku hibernacji.
Hgs_NoDumps Wymaga wyłączenia zrzutów pamięci na hoście Hyper-V. Jeśli te zasady zostaną wyłączone, zaleca się skonfigurowanie szyfrowania zrzutu, aby zapobiec zapisaniu chronionej pamięci maszyny wirtualnej do niezaszyfrowanych plików zrzutu awaryjnego.
Hgs_DumpEncryption Wymaga, aby zrzuty pamięci, jeżeli są włączone na hoście Hyper-V, były szyfrowane przy użyciu klucza szyfrowania uznawane przez usługę HGS. Te zasady nie mają zastosowania, jeśli zrzuty nie są włączone na hoście. Jeśli zarówno te zasady, jak i Hgs_NoDumps są wyłączone, pamięć maszyny wirtualnej z osłoną może zostać zapisana w niezaszyfrowanym pliku zrzutu.
Hgs_DumpEncryptionKey Zasady wykluczające w celu zapewnienia, że hosty skonfigurowane do zezwalania na zrzuty pamięci korzystają z klucza szyfrowania plików zrzutu zdefiniowanego przez administratora i znanego usłudze HGS. Te zasady nie mają zastosowania w przypadku wyłączenia Hgs_DumpEncryption.

Autoryzowanie nowych hostów chronionych

Aby autoryzować nowego hosta jako hosta chronionego (np. zaświadczać z powodzeniem), usługa HGS musi ufać hostowi oraz, jeśli skonfigurowana do używania zaświadczania zaufanego przez TPM, oprogramowaniu uruchomionemu na nim. Kroki autoryzacji nowego hosta różnią się w zależności od trybu zaświadczania, dla którego usługa HGS jest obecnie skonfigurowana. Aby sprawdzić tryb zaświadczania dla chronionej infrastruktury, uruchom Get-HgsServer na dowolnym węźle HGS.

Konfiguracja oprogramowania

Na nowym hoście Hyper-V upewnij się, że zainstalowano wersję Datacenter systemu Windows Server 2016. System Windows Server 2016 Standard nie może uruchamiać chronionych maszyn wirtualnych w chronionej sieci szkieletowej. Host może mieć zainstalowane Środowisko Pulpitu lub Server Core.

Na serwerze ze środowiskiem pulpitu i serwerem Server Core należy zainstalować role serwera Hyper-V i Ochrona hosta Hyper-V:

Install-WindowsFeature Hyper-V, HostGuardian -IncludeManagementTools -Restart

Uwierzytelnienie zaufane przez administratora

Aby zarejestrować nowego hosta w usłudze HGS podczas korzystania z zaświadczania zaufanego przez administratora, należy najpierw dodać hosta do grupy zabezpieczeń w domenie, do której jest przyłączony. Zazwyczaj każda domena będzie mieć jedną grupę zabezpieczeń dla hostów chronionych. Jeśli ta grupa została już zarejestrowana w usłudze HGS, jedyną akcją, którą należy wykonać, jest ponowne uruchomienie hosta w celu odświeżenia członkostwa w grupie.

Możesz sprawdzić, które grupy zabezpieczeń są zaufane przez usługę HGS, uruchamiając następujące polecenie:

Get-HgsAttestationHostGroup

Aby zarejestrować nową grupę zabezpieczeń w usłudze HGS, najpierw przechwyć identyfikator zabezpieczeń (SID) grupy w domenie hosta i zarejestrować identyfikator SID w usłudze HGS.

Add-HgsAttestationHostGroup -Name "Contoso Guarded Hosts" -Identifier "S-1-5-21-3623811015-3361044348-30300820-1013"

Instrukcje dotyczące konfigurowania zaufania między domeną hosta i usługą HGS są dostępne w przewodniku wdrażania.

Zaufane poświadczenie TPM

Gdy usługa HGS jest skonfigurowana w trybie modułu TPM, hosty muszą przekazywać wszystkie zablokowane zasady i "włączone" zasady z prefiksem "Hgs_", a także co najmniej jeden punkt odniesienia modułu TPM, identyfikator modułu TPM i zasady integralności kodu. Za każdym razem, gdy dodasz nowego hosta, musisz zarejestrować nowy identyfikator modułu TPM w usłudze HGS. Jeśli host korzysta z tego samego oprogramowania (i ma zastosowane te same zasady integralności kodu) i punkt odniesienia modułu TPM co inny host w danym środowisku, nie trzeba dodawać nowych zasad ciągłej integracji ani punktów odniesienia.

Dodanie identyfikatora modułu TPM dla nowego hosta Na nowym hoście uruchom następujące polecenie, aby przechwycić identyfikator modułu TPM. Pamiętaj, aby określić unikatową nazwę hosta, który pomoże Ci wyszukać go w usłudze HGS. Te informacje będą potrzebne w przypadku zlikwidowania hosta lub uniemożliwienia uruchamiania chronionych maszyn wirtualnych w usłudze HGS.

(Get-PlatformIdentifier -Name "Host01").InnerXml | Out-File C:\temp\host01.xml -Encoding UTF8

Skopiuj ten plik na serwer HGS, a następnie uruchom następujące polecenie, aby zarejestrować hosta w usłudze HGS.

Add-HgsAttestationTpmHost -Name 'Host01' -Path C:\temp\host01.xml

Dodanie nowego punktu odniesienia modułu TPM Jeśli nowy host korzysta z nowej konfiguracji sprzętu lub oprogramowania układowego dla danego środowiska, może być konieczne użycie nowego punktu odniesienia modułu TPM. W tym celu uruchom następujące polecenie na hoście.

Get-HgsAttestationBaselinePolicy -Path 'C:\temp\hardwareConfig01.tcglog'

Uwaga

Jeśli zostanie wyświetlony komunikat o błędzie informujący, że weryfikacja hosta nie powiodła się i nie będzie pomyślnie potwierdzana, nie martw się. Jest to sprawdzanie wymagań wstępnych, aby upewnić się, że host może uruchamiać maszyny wirtualne z osłoną i prawdopodobnie oznacza, że nie zastosowano jeszcze zasad integralności kodu ani innych wymaganych ustawień. Przeczytaj komunikat o błędzie, wprowadź wszelkie sugerowane przez niego zmiany, a następnie spróbuj ponownie. Alternatywnie możesz pominąć walidację w tej chwili, dodając flagę -SkipValidation do polecenia .

Skopiuj punkt odniesienia modułu TPM do serwera usługi HGS, a następnie zarejestruj go za pomocą następującego polecenia. Zachęcamy do korzystania z konwencji nazewnictwa, która pomaga zrozumieć konfigurację sprzętu i oprogramowania układowego tej klasy hosta Hyper-V.

Add-HgsAttestationTpmPolicy -Name 'HardwareConfig01' -Path 'C:\temp\hardwareConfig01.tcglog'

Dodanie nowych zasad integralności kodu Jeśli zmieniono zasady integralności kodu uruchomione na hostach Hyper-V, należy zarejestrować nowe zasady w usłudze HGS, zanim te hosty będą mogły pomyślnie potwierdzić. Na hoście odniesienia, który służy jako obraz główny dla zaufanych maszyn Hyper-V w Twoim środowisku, zapisz nową politykę CI przy użyciu polecenia New-CIPolicy. Zachęcamy do korzystania z poziomu funkcji FilePublisher oraz rezerwowego mechanizmu Hash dla polityk CI hosta Hyper-V. Najpierw należy utworzyć politykę CI w trybie inspekcji, aby upewnić się, że wszystko działa zgodnie z oczekiwaniami. Po zweryfikowaniu przykładowego obciążenia w systemie można wymusić zasady i skopiować wymuszoną wersję do usługi HGS. Aby uzyskać pełną listę opcji konfiguracji zasad integralności kodu, zapoznaj się z dokumentacją Device Guard.

# Capture a new CI policy with the FilePublisher primary level and Hash fallback and enable user mode code integrity protections
New-CIPolicy -FilePath 'C:\temp\ws2016-hardware01-ci.xml' -Level FilePublisher -Fallback Hash -UserPEs

# Apply the CI policy to the system
ConvertFrom-CIPolicy -XmlFilePath 'C:\temp\ws2016-hardware01-ci.xml' -BinaryFilePath 'C:\temp\ws2016-hardware01-ci.p7b'
Copy-Item 'C:\temp\ws2016-hardware01-ci.p7b' 'C:\Windows\System32\CodeIntegrity\SIPolicy.p7b'
Restart-Computer

# Check the event log for any untrusted binaries and update the policy if necessary
# Consult the Device Guard documentation for more details

# Change the policy to be in enforced mode
Set-RuleOption -FilePath 'C:\temp\ws2016-hardare01-ci.xml' -Option 3 -Delete

# Apply the enforced CI policy on the system
ConvertFrom-CIPolicy -XmlFilePath 'C:\temp\ws2016-hardware01-ci.xml' -BinaryFilePath 'C:\temp\ws2016-hardware01-ci.p7b'
Copy-Item 'C:\temp\ws2016-hardware01-ci.p7b' 'C:\Windows\System32\CodeIntegrity\SIPolicy.p7b'
Restart-Computer

Po utworzeniu, przetestowaniu i wymuszeniu zasady skopiuj plik binarny (.p7b) na serwer usługi HGS i zarejestruj zasadę.

Add-HgsAttestationCiPolicy -Name 'WS2016-Hardware01' -Path 'C:\temp\ws2016-hardware01-ci.p7b'

dodawanie klucza szyfrowania zrzutu pamięci

Po wyłączeniu zasad Hgs_NoDumps i włączeniu zasad Hgs_DumpEncryption chronione hosty mogą mieć zrzuty pamięci (w tym zrzuty awaryjne), o ile te zrzuty są szyfrowane. Chronione hosty będą przekazywać zaświadczanie tylko wtedy, gdy mają wyłączone zrzuty pamięci lub szyfrują je przy użyciu klucza znanego dla usługi HGS. Domyślnie w usłudze HGS nie są skonfigurowane żadne klucze szyfrowania zrzutu.

Aby dodać klucz szyfrowania zrzutu do usługi HGS, użyj polecenia cmdlet Add-HgsAttestationDumpPolicy, aby przekazać usługę HGS skrót klucza szyfrowania zrzutu. Jeśli przechwycisz bazowy punkt odniesienia modułu TPM na hoście Hyper-V skonfigurowanym za pomocą szyfrowania zrzutu, skrót zostanie uwzględniony w dzienniku tcglog i może zostać przekazany do polecenia cmdlet Add-HgsAttestationDumpPolicy.

Add-HgsAttestationDumpPolicy -Name 'DumpEncryptionKey01' -Path 'C:\temp\TpmBaselineWithDumpEncryptionKey.tcglog'

Alternatywnie możesz bezpośrednio podać reprezentację ciągu skrótu jako parametr cmdlet.

Add-HgsAttestationDumpPolicy -Name 'DumpEncryptionKey02' -PublicKeyHash '<paste your hash here>'

Pamiętaj, aby dodać każdy unikatowy klucz szyfrowania zrzutu do usługi HGS, jeśli zdecydujesz się używać różnych kluczy w chronionej infrastrukturze. Hosty szyfrujące zrzuty pamięci przy użyciu klucza, który nie jest znany usłudze HGS, nie przejdą atestacji.

Aby uzyskać więcej informacji na temat konfigurowania szyfrowania zrzutu na hostach , zapoznaj się z dokumentacją Hyper-V.

Sprawdź, czy system przeszedł atestację

Po zarejestrowaniu niezbędnych informacji w HGS należy sprawdzić, czy host przechodzi atestację. Na nowo dodanym hoście Hyper-V uruchom Set-HgsClientConfiguration i podaj poprawne adresy URL klastra usługi HGS. Te adresy URL można uzyskać, uruchamiając Get-HgsServer w dowolnym węźle usługi HGS.

Set-HgsClientConfiguration -KeyProtectionServerUrl 'https://hgs.bastion.local/KeyProtection' -AttestationServerUrl 'https://hgs.bastion.local/Attestation'

Jeśli wynikowy stan nie wskazuje wartości "IsHostGuarded : True", musisz rozwiązać problem z konfiguracją. Na hoście, który nie przeszedł atestacji, uruchom następujące polecenie, aby uzyskać szczegółowy raport o problemach, które mogą pomóc w rozwiązaniu nieudanej atestacji.

Get-HgsTrace -RunDiagnostics -Detailed

Ważne

Jeśli używasz systemu Windows Server 2019 lub Windows 10 w wersji 1809 i korzystasz z zasad integralności kodu, Get-HgsTrace może zwrócić błąd w ramach diagnostyki aktywnej zasad integralności kodu. Możesz bezpiecznie zignorować ten wynik, gdy jest to jedyna diagnostyka, która kończy się niepowodzeniem.

Przeglądanie zasad zaświadczania

Aby przejrzeć bieżący stan zasad skonfigurowanych w usłudze HGS, uruchom następujące polecenia w dowolnym węźle usługi HGS:

# List all trusted security groups for admin-trusted attestation
Get-HgsAttestationHostGroup

# List all policies configured for TPM-trusted attestation
Get-HgsAttestationPolicy

Jeśli znajdziesz zasady, które nie spełniają już wymagań dotyczących zabezpieczeń (np. stare zasady integralności kodu, które są obecnie uznawane za niebezpieczne), możesz ją wyłączyć, zastępując nazwę zasad w następującym poleceniu:

Disable-HgsAttestationPolicy -Name 'PolicyName'

Podobnie można użyć Enable-HgsAttestationPolicy, aby ponownie włączyć zasady.

Jeśli nie potrzebujesz już zasad i chcesz je usunąć ze wszystkich węzłów usługi HGS, uruchom Remove-HgsAttestationPolicy -Name 'PolicyName', aby trwale usunąć zasady.

Zmienianie trybów zaświadczania

Jeśli uruchomiłeś swoją chronioną infrastrukturę przy użyciu atestu zaufanego przez administratora, prawdopodobnie będziesz chciał zaktualizować do znacznie silniejszego trybu atestacji TPM, gdy tylko będziesz miał wystarczającą liczbę hostów zgodnych z TPM 2.0 w środowisku. Gdy będziesz gotowy do przełączenia, możesz załadować wszystkie artefakty zaświadczenia (polityki zgodności, punkty odniesienia modułu TPM i identyfikatory modułu TPM) do usługi HGS, jednocześnie kontynuując jej działanie z zaświadczeniem zaufanym przez administratora. Aby to zrobić, po prostu stosuj się do instrukcji w sekcji oznaczonej jako dotyczącej autoryzowania nowego chronionego hosta oznaczonego.

Po dodaniu wszystkich zasad do usługi HGS, następnym krokiem jest uruchomienie syntetycznej próby poświadczenia na hostach w celu sprawdzenia, czy przejdą one poświadczenie w trybie TPM. Nie ma to wpływu na bieżący stan operacyjny usługi HGS. Poniższe polecenia muszą być uruchamiane na maszynie, która ma dostęp do wszystkich hostów w środowisku i co najmniej jednego węzła usługi HGS. Jeśli zapora lub inne zasady zabezpieczeń temu zapobiegną, możesz pominąć ten krok. Jeśli to możliwe, zalecamy uruchomienie syntetycznego zaświadczania w celu wskazania, czy "przerzucanie" do trybu TPM spowoduje przestój maszyn wirtualnych.

# Get information for each host in your environment
$hostNames = 'host01.contoso.com', 'host02.contoso.com', 'host03.contoso.com'
$credential = Get-Credential -Message 'Enter a credential with admin privileges on each host'
$targets = @()
$hostNames | ForEach-Object { $targets += New-HgsTraceTarget -Credential $credential -Role GuardedHost -HostName $_ }

$hgsCredential = Get-Credential -Message 'Enter an admin credential for HGS'
$targets += New-HgsTraceTarget -Credential $hgsCredential -Role HostGuardianService -HostName 'HGS01.bastion.local'

# Initiate the synthetic attestation attempt
Get-HgsTrace -RunDiagnostics -Target $targets -Diagnostic GuardedFabricTpmMode

Po zakończeniu diagnostyki przejrzyj dane wyjściowe, aby ustalić, czy jakiekolwiek hosty nie przeszłyby atestacji w trybie TPM. Uruchom ponownie diagnostykę, dopóki nie uzyskasz "zaliczenia" z każdego hosta, a następnie przejdź do zmiany trybu HGS na TPM.

zmiana trybu modułu TPM zajmuje zaledwie sekundę. Uruchom następujące polecenie w dowolnym węźle usługi HGS, aby zaktualizować tryb zaświadczania.

Set-HgsServer -TrustTpm

Jeśli wystąpią problemy i trzeba wrócić do trybu usługi Active Directory, możesz to zrobić, uruchamiając Set-HgsServer -TrustActiveDirectory.

Po potwierdzeniu, że wszystko działa zgodnie z oczekiwaniami, należy usunąć wszystkie zaufane grupy hostów usługi Active Directory z usługi HGS i usunąć zaufanie między domenami HGS a domenami infrastruktury. Jeśli pozostawisz zaufanie Active Directory, ryzykujesz, że ktoś ponownie włączy to zaufanie i przełączy HGS na tryb Active Directory, co może umożliwić niekontrolowane uruchamianie niezaufanego kodu na twoich chronionych hostach.

Zarządzanie kluczami

Chronione rozwiązanie infrastrukturalne używa kilku par kluczy publicznych/prywatnych do weryfikacji integralności różnych elementów rozwiązania i szyfrowania danych tajnych najemcy. Usługa Ochrona hosta jest skonfigurowana z co najmniej dwoma certyfikatami (z kluczami publicznymi i prywatnymi), które są używane do podpisywania i szyfrowania kluczy używanych do uruchamiania chronionych maszyn wirtualnych. Te klucze muszą być starannie zarządzane. Jeśli klucz prywatny zostanie przejęty przez przeciwnika, będzie mógł odsłonić wszystkie maszyny wirtualne działające w Twojej infrastrukturze lub skonfigurować fałszywy klaster HGS, który używa słabszych zasad zaświadczania, aby obejść wprowadzone zabezpieczenia. Jeśli utracisz klucze prywatne podczas awarii i nie znajdziesz ich w kopii zapasowej, konieczne będzie skonfigurowanie nowej pary kluczy i ponowne przypisanie poszczególnych maszyn wirtualnych do autoryzowania nowych certyfikatów.

W tej sekcji opisano ogólne tematy dotyczące zarządzania kluczami, które ułatwiają konfigurowanie kluczy w celu ich funkcjonalności i bezpieczeństwa.

Dodawanie nowych kluczy

Chociaż usługa HGS musi zostać zainicjowana przy użyciu jednego zestawu kluczy, można dodać do usługi HGS więcej niż jeden klucz szyfrowania i podpisywania. Dwa najczęstsze przyczyny dodawania nowych kluczy do usługi HGS to:

  1. Aby obsługiwać scenariusze "przynieś własny klucz", w których dzierżawcy kopiują swoje klucze prywatne do sprzętowego modułu zabezpieczeń i autoryzują klucze tylko do uruchamiania chronionych maszyn wirtualnych.
  2. Aby zastąpić istniejące klucze dla usługi HGS, najpierw dodając nowe klucze i zachowując oba zestawy kluczy do momentu zaktualizowania każdej konfiguracji maszyny wirtualnej do używania nowych kluczy.

Proces dodawania nowych kluczy różni się w zależności od typu używanego certyfikatu.

Opcja 1: Dodanie certyfikatu przechowywanego w HSM

Naszym zalecanym podejściem do zabezpieczania kluczy HGS jest użycie certyfikatów utworzonych w sprzętowym module zabezpieczeń (HSM). Moduły HSM zapewniają, że korzystanie z kluczy jest powiązane z fizycznym dostępem do bezpiecznego urządzenia w centrum danych. Każdy moduł HSM jest inny i ma unikatowy proces tworzenia certyfikatów i rejestrowania ich w usłudze HGS. Poniższe kroki mają na celu przedstawienie przybliżonych wskazówek dotyczących używania certyfikatów wspieranych przez moduł HSM. Zapoznaj się z dokumentacją dostawcy modułu HSM, aby uzyskać szczegółowe instrukcje i możliwości.

  1. Zainstaluj oprogramowanie HSM w każdym węźle HGS w klastrze. W zależności od tego, czy masz urządzenie sieciowe, czy lokalnego modułu HSM, może być konieczne skonfigurowanie modułu HSM w celu udzielenia maszynie dostępu do jego magazynu kluczy.

  2. Tworzenie 2 certyfikatów w module HSM przy użyciu 2048-bitowych kluczy RSA na potrzeby szyfrowania i podpisywania

    1. Utwórz certyfikat szyfrujący z właściwością użycia klucza Szyfrowanie danych w swoim module HSM.
    2. Utwórz certyfikat podpisu za pomocą właściwości użycia klucza Podpis Cyfrowy w module HSM.

  3. Zainstaluj certyfikaty w lokalnym magazynie certyfikatów każdego węzła usługi HGS zgodnie ze wskazówkami dostawcy modułu HSM.

  4. Jeśli moduł HSM używa szczegółowych uprawnień w celu udzielenia określonym aplikacjom lub użytkownikom uprawnień do korzystania z klucza prywatnego, musisz udzielić konta usługi zarządzanej przez grupę HGS dostępu do certyfikatu. Nazwę konta gMSA usługi HGS można znaleźć, uruchamiając (Get-IISAppPool -Name KeyProtection).ProcessModel.UserName

  5. Dodaj certyfikaty podpisywania i szyfrowania do usługi HGS, zastępując odciski palca tymi z twoich certyfikatów w następujących poleceniach:

    Add-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint "AABBCCDDEEFF00112233445566778899"
Add-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint "99887766554433221100FFEEDDCCBBAA"

Opcja 2: dodawanie certyfikatów oprogramowania, które nie można eksportować,

Jeśli masz certyfikat oparty na oprogramowaniu wystawiony przez firmę lub publiczny urząd certyfikacji z nieeksportowalnym kluczem prywatnym, musisz dodać certyfikat do usługi HGS przy użyciu jego odcisku palca.

  1. Zainstaluj certyfikat na maszynie zgodnie z instrukcjami urzędu certyfikacji.

  2. Przyznaj kontu usługi zarządzanej przez grupę HGS dostęp do odczytu do klucza prywatnego certyfikatu. Nazwę konta HGS gMSA można znaleźć, uruchamiając (Get-IISAppPool -Name KeyProtection).ProcessModel.UserName

  3. Zarejestruj certyfikat w usłudze HGS przy użyciu następującego polecenia, podstawiając odcisk palca swojego certyfikatu (zmień Szyfrowanie na Podpis w przypadku certyfikatów podpisu):

    Add-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint "AABBCCDDEEFF00112233445566778899"

Ważne

Należy ręcznie zainstalować klucz prywatny i przyznać dostęp do odczytu do konta gMSA na każdym węźle HGS. Usługa HGS nie może automatycznie replikować kluczy prywatnych dla dowolnego certyfikatu zarejestrowanego za pomocą jego odcisku palca.

Opcja 3: dodawanie certyfikatów przechowywanych w plikach PFX

Jeśli masz certyfikat oparty na oprogramowaniu z eksportowalnym kluczem prywatnym, który może być przechowywany w formacie pliku PFX i zabezpieczony hasłem, usługa HGS może automatycznie zarządzać certyfikatami. Certyfikaty dodane z plikami PFX są automatycznie replikowane do każdego węzła klastra usługi HGS, a usługa HGS zabezpiecza dostęp do kluczy prywatnych. Aby dodać nowy certyfikat przy użyciu pliku PFX, uruchom następujące polecenia na dowolnym węźle usługi HGS (zmień Encryption na Signing dla certyfikatów podpisywania):

$certPassword = Read-Host -AsSecureString -Prompt "Provide the PFX file password"
Add-HgsKeyProtectionCertificate -CertificateType Encryption -CertificatePath "C:\temp\encryptionCert.pfx" -CertificatePassword $certPassword

Identyfikowanie i zmienianie certyfikatów podstawowych Podczas gdy usługa HGS może obsługiwać wiele certyfikatów podpisywania i szyfrowania, używa jednej pary jako certyfikatów "podstawowych". Są to certyfikaty, które będą używane, jeśli ktoś pobierze metadane strażnika dla tego klastra HGS. Aby sprawdzić, które certyfikaty są obecnie oznaczone jako certyfikaty podstawowe, uruchom następujące polecenie:

Get-HgsKeyProtectionCertificate -IsPrimary $true

Aby ustawić nowe podstawowe szyfrowanie lub certyfikat podpisywania, znajdź odcisk palca żądanego certyfikatu i oznacz go jako podstawowy przy użyciu następujących poleceń:

Get-HgsKeyProtectionCertificate
Set-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint "AABBCCDDEEFF00112233445566778899" -IsPrimary
Set-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint "99887766554433221100FFEEDDCCBBAA" -IsPrimary

Odnawianie lub zastępowanie kluczy

Podczas tworzenia certyfikatów używanych przez usługę HGS certyfikaty zostaną przypisane do daty wygaśnięcia zgodnie z zasadami urzędu certyfikacji i informacjami o żądaniu. Zwykle w scenariuszach, w których ważność certyfikatu jest ważna, na przykład zabezpieczanie komunikacji HTTP, certyfikaty muszą zostać odnowione przed wygaśnięciem, aby uniknąć zakłóceń usługi lub niepokojącego komunikatu o błędzie. Usługa HGS nie używa certyfikatów w tym sensie. Usługa HGS po prostu używa certyfikatów jako wygodnego sposobu tworzenia i przechowywania pary kluczy asymetrycznych. Wygasły certyfikat szyfrowania lub podpisywania w usłudze HGS nie wskazuje słabości ani utraty ochrony chronionych maszyn wirtualnych. Ponadto kontrole unieważnienia certyfikatów nie są wykonywane przez HGS. Jeśli certyfikat HGS lub certyfikat urzędu wystawiającego zostanie unieważniony, nie wpłynie to na użycie certyfikatu przez HGS.

Jedynym momentem, w którym musisz się martwić o certyfikat usługi HGS, jest to, że masz powód, aby sądzić, że jego klucz prywatny został skradziony. W takim przypadku integralność chronionych maszyn wirtualnych jest zagrożona, ponieważ posiadanie prywatnej części pary kluczy szyfrujących i podpisujących usługi HGS wystarczy, aby usunąć zabezpieczenia osłony na maszynie wirtualnej lub uruchomić fałszywy serwer HGS, który ma mniej restrykcyjne zasady zaświadczania.

Jeśli znajdziesz się w tej sytuacji lub są wymagane przez standardy zgodności do regularnego odświeżania kluczy certyfikatów, poniższe kroki przedstawiają proces zmiany kluczy na serwerze HGS. Należy pamiętać, że poniższe wskazówki stanowią znaczne przedsięwzięcie, które spowoduje zakłócenia w działaniu każdej maszyny wirtualnej obsługiwanej przez klaster HGS. Aby zminimalizować przerwy w działaniu usługi i zapewnić bezpieczeństwo maszyn wirtualnych dzierżawy, wymagane jest odpowiednie planowanie zmiany kluczy HGS.

W węźle usługi HGS wykonaj następujące kroki, aby zarejestrować nową parę certyfikatów szyfrowania i podpisywania. Zobacz sekcję dotyczącą dodawania nowych kluczy, aby uzyskać szczegółowe informacje na temat różnych sposobów dodawania nowych kluczy do usługi HGS.

  1. Utwórz nową parę certyfikatów szyfrowania i podpisywania dla serwera usługi HGS. W idealnym przypadku zostaną one utworzone w module zabezpieczeń sprzętu.

  2. Zarejestruj nowe certyfikaty szyfrowania i podpisywania przy użyciu Add-HgsKeyProtectionCertificate

    Add-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint <Thumbprint>
Add-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint <Thumbprint>

  3. Jeśli użyto odcisków cyfrowych, musisz przejść do każdego węzła w klastrze, aby zainstalować klucz prywatny i udzielić dostępu do klucza usłudze gMSA HGS.

  4. Ustaw nowe certyfikaty jako domyślne certyfikaty w usłudze HGS

    Set-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint <Thumbprint> -IsPrimary
Set-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint <Thumbprint> -IsPrimary

W tym momencie dane osłony utworzone za pomocą metadanych uzyskanych z węzła usługi HGS będą używać nowych certyfikatów, ale istniejące maszyny wirtualne będą nadal działać, ponieważ starsze certyfikaty nadal istnieją.

Aby zapewnić pracę wszystkich istniejących maszyn wirtualnych z nowymi kluczami, należy zaktualizować ochronę klucza na każdej maszynie wirtualnej.

Jest to akcja, która wymaga zaangażowania właściciela maszyny wirtualnej (osoby lub jednostki posiadającej "opiekuna właściciela"). Dla każdej chronionej maszyny wirtualnej wykonaj następujące kroki:

  1. Zamknij maszynę wirtualną. Nie można ponownie włączyć maszyny wirtualnej, dopóki pozostałe kroki nie zostaną ukończone lub trzeba będzie ponownie uruchomić proces.

  2. Zapisz bieżącą ochronę klucza w pliku: Get-VMKeyProtector -VMName 'VM001' | Out-File '.\VM001.kp'

  3. Przenieś KP do właściciela maszyny wirtualnej

  4. Niech właściciel pobierze zaktualizowane informacje o strażniku z usługi HGS i zaimportuje je na swoim lokalnym systemie.

  5. Wczytaj bieżący KP do pamięci, przyznaj nowemu opiekunowi dostęp do KP, i zapisz go w nowym pliku, uruchamiając następujące polecenia:

    $kpraw = Get-Content -Path .\VM001.kp
$kp = ConvertTo-HgsKeyProtector -Bytes $kpraw
$newGuardian = Get-HgsGuardian -Name 'UpdatedHgsGuardian'
$updatedKP = Grant-HgsKeyProtectorAccess -KeyProtector $kp -Guardian $newGuardian
$updatedKP.RawData | Out-File .\updatedVM001.kp

  6. Skopiuj zaktualizowany KP z powrotem do infrastruktury hostingowej.

  7. Zastosuj kluczowy wskaźnik wydajności do oryginalnej maszyny wirtualnej:

    $updatedKP = Get-Content -Path .\updatedVM001.kp
Set-VMKeyProtector -VMName VM001 -KeyProtector $updatedKP

  8. Na koniec uruchom maszynę wirtualną i upewnij się, że działa pomyślnie.

    Uwaga

    Jeśli właściciel maszyny wirtualnej ustawi niepoprawne zabezpieczenie klucza i nie autoryzuje infrastruktury do uruchomienia maszyny, nie będzie można uruchomić chronionej maszyny wirtualnej. Aby powrócić do ostatniego znanego dobrego zabezpieczenia klucza, uruchom Set-VMKeyProtector -RestoreLastKnownGoodKeyProtector

    Po zaktualizowaniu wszystkich maszyn wirtualnych w celu autoryzowania nowych kluczy ochrony można wyłączyć i usunąć stare klucze.

  9. Uzyskaj odciski palców starych certyfikatów z Get-HgsKeyProtectionCertificate -IsPrimary $false

  10. Wyłącz każdy certyfikat, uruchamiając następujące polecenia:

    Set-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint <Thumbprint> -IsEnabled $false
Set-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint <Thumbprint> -IsEnabled $false

  11. Po upewnieniu się, że maszyny wirtualne są nadal w stanie rozpocząć od wyłączonych certyfikatów, usuń certyfikaty z usługi HGS, uruchamiając następujące polecenia:

    Remove-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint <Thumbprint>`
Remove-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint <Thumbprint>`

Ważne

Kopie zapasowe maszyn wirtualnych będą zawierać informacje o starym zabezpieczeniu klucza, które pozwalają na użycie starych certyfikatów do uruchomienia maszyny wirtualnej. Jeśli wiesz, że klucz prywatny został naruszony, należy założyć, że kopie zapasowe maszyn wirtualnych mogą zostać naruszone, a także podjąć odpowiednie działania. Zniszczenie konfiguracji maszyny wirtualnej z kopii zapasowych (.vmcx) spowoduje usunięcie ochrony kluczy, co skutkuje koniecznością użycia hasła odzyskiwania BitLocker przy następnym uruchamianiu maszyny wirtualnej.

Replikacja kluczy między węzłami

Każdy węzeł w klastrze usługi HGS musi być skonfigurowany z użyciem tych samych certyfikatów szyfrowania, podpisywania oraz SSL (jeśli są skonfigurowane). Jest to konieczne, aby zapewnić, że hosty Hyper-V, które łączą się z dowolnym węzłem w klastrze, mogą mieć swoje żądania pomyślnie obsłużone.

Jeśli zainicjowano serwer HGS przy użyciu certyfikatów opartych na pfX usługa HGS będzie automatycznie replikować zarówno klucz publiczny, jak i prywatny tych certyfikatów w każdym węźle w klastrze. Wystarczy dodać tylko klucze w jednym węźle.

Jeśli zainicjowano serwer HGS z odwołaniami do certyfikatów lub odciskami palca, usługa HGS będzie replikować tylko klucz publiczny w każdym węźle. Ponadto usługa HGS nie może udzielić sobie dostępu do klucza prywatnego na żadnym węźle w tym scenariuszu. W związku z tym twoim obowiązkiem jest:

  1. Zainstaluj klucz prywatny na każdym węźle usługi HGS
  2. Udziel kontu usługi zarządzanej przez grupę HGS (gMSA) dostępu do klucza prywatnego w każdym węźle, te czynności dodają dodatkowy nakład pracy operacyjnej, jednak są one wymagane dla kluczy i certyfikatów z prywatnymi kluczami, które nie mogą być eksportowane.

Certyfikaty SSL nigdy nie są replikowane w żadnej formie. Twoim zadaniem jest zainicjowanie każdego serwera usługi HGS przy użyciu tego samego certyfikatu SSL i zaktualizowanie każdego serwera za każdym razem, gdy zdecydujesz się odnowić lub zastąpić certyfikat SSL. Podczas zastępowania certyfikatu SSL zaleca się użycie polecenia cmdlet Set-HgsServer.

Nieskonfigurowanie usługi HGS

Jeśli musisz zlikwidować lub znacznie ponownie skonfigurować serwer HGS, możesz to zrobić za pomocą poleceń cmdlet Clear-HgsServer lub Uninstall-HgsServer.

Czyszczenie konfiguracji usługi HGS

Aby usunąć węzeł z klastra usługi HGS, użyj polecenia cmdlet Clear-HgsServer. To polecenie cmdlet spowoduje wprowadzenie następujących zmian na serwerze, na którym jest uruchamiany:

  • Wyrejestrowuje usługi zaświadczania i ochrony kluczy
  • Usuwa punkt końcowy zarządzania JEA "microsoft.windows.hgs"
  • Usuwa komputer lokalny z klastra awaryjnego HGS

Jeśli serwer jest ostatnim węzłem usługi HGS w klastrze, klaster i odpowiadający mu zasób nazwy sieci rozproszonej również zostaną zniszczone.

# Removes the local computer from the HGS cluster
Clear-HgsServer

Po zakończeniu operacji czyszczenia serwer HGS można ponownie zainicjować za pomocą Initialize-HgsServer. Jeśli użyto Install-HgsServer do skonfigurowania domeny usług Domenowych Active Directory, ta domena pozostanie skonfigurowana i operacyjna po zakończeniu operacji czyszczenia.

Odinstalowywanie usługi HGS

Jeśli chcesz usunąć węzeł z klastra HGS i, obniż poziom kontrolera domeny Active Directory, który na nim działa, a następnie użyj polecenia cmdlet Uninstall-HgsServer. To polecenie cmdlet spowoduje wprowadzenie następujących zmian na serwerze, na którym jest uruchamiany:

  • Wyrejestrowuje usługi atestacji i ochrony kluczy
  • Usuwa punkt końcowy zarządzania JEA "microsoft.windows.hgs"
  • Usuwa komputer lokalny z klastra trybu failover usługi HGS
  • Obniża poziom kontrolera domeny usługi Active Directory, jeśli został skonfigurowany

Jeśli serwer jest ostatnim węzłem usługi HGS w klastrze, to domena, klaster przełączania awaryjnego oraz zasób rozproszonej nazwy sieci klastra również zostaną zniszczone.

# Removes the local computer from the HGS cluster and demotes the ADDC (restart required)
$newLocalAdminPassword = Read-Host -AsSecureString -Prompt "Enter a new password for the local administrator account"
Uninstall-HgsServer -LocalAdministratorPassword $newLocalAdminPassword -Restart

Po zakończeniu operacji odinstalowywania i ponownym uruchomieniu komputera można ponownie zainstalować usługę ADDC i usługę HGS przy użyciu Install-HgsServer lub dołączyć komputer do domeny i zainicjować serwer HGS w tej domenie przy użyciu Initialize-HgsServer.

Jeśli nie zamierzasz już używać komputera jako węzła usługi HGS, możesz usunąć rolę z systemu Windows.

Uninstall-WindowsFeature HostGuardianServiceRole