Udostępnij za pośrednictwem

Przewodnik planowania chronionej infrastruktury i chronionej maszyny wirtualnej dla dostawców usług hostingowych

W tym temacie opisano decyzje dotyczące planowania, które należy podjąć, aby umożliwić uruchamianie osłoniętych maszyn wirtualnych w Twojej infrastrukturze. Niezależnie od tego, czy uaktualniasz istniejącą sieć Hyper-V, czy tworzysz nową, działające maszyny wirtualne z osłoną składają się z dwóch głównych składników:

  • Usługa Host Guardian Service (HGS) oferuje uwierzytelnianie i ochronę klucza, dzięki czemu można się upewnić, że chronione maszyny wirtualne będą działać tylko na zatwierdzonych i w dobrej kondycji hosty Hyper-V. 
  • Zatwierdzone i w dobrej kondycji Hyper-V hosty, na których można uruchamiać chronione maszyny wirtualne (i zwykłe maszyny wirtualne) — są one nazywane hostami chronionymi.

Diagram przedstawiający zaświadczanie H G S i usługi ochrony kluczy są połączone z chronionymi hostami funkcji Hyper V maszyny wirtualnej z osłoną.

Decyzja nr 1: Poziom zaufania w infrastrukturze

Sposób implementacji usługi Guardian Host i chronionych hostów Hyper-V zależy głównie od siły zaufania, którą chcesz osiągnąć w strukturze. Siła zaufania podlega trybowi zaświadczania. Istnieją dwie wzajemnie wykluczające się opcje:

  1. Zaufana atestacja TPM

    Jeśli Twoim celem jest pomóc w ochronie maszyn wirtualnych przed złośliwymi administratorami lub skompromitowaną infrastrukturą, to użyjesz zaświadczania zaufanego przez moduł TPM. Ta opcja działa dobrze w scenariuszach hostingu z wieloma dzierżawami, a także w przypadku zasobów o wysokiej wartości w środowiskach przedsiębiorstwa, takich jak kontrolery domeny lub serwery zawartości, takie jak SQL lub SharePoint. Zasady integralności kodu chronionego przez funkcję Hypervisor (HVCI) są mierzone i ich ważność wymuszana przez usługę HGS przed zezwoleniem hosta na uruchamianie chronionych maszyn wirtualnych.

  2. Zaświadczanie klucza hosta

    Jeśli twoje wymagania są przede wszystkim podyktowane wymogami zgodności, które wymagają szyfrowania maszyn wirtualnych zarówno w spoczynku, jak i podczas przesyłania, będziesz używać zaświadczania klucza hosta. Ta opcja sprawdza się dobrze w centrach danych ogólnego przeznaczenia, gdzie jest akceptowalne, że administratorzy hostów i infrastruktury sieciowej Hyper-V mają dostęp do systemu operacyjnego gościa maszyn wirtualnych w celu wykonywania codziennych czynności konserwacyjnych i operacyjnych.

    W tym trybie administrator sieciowej infrastruktury jest odpowiedzialny wyłącznie za zapewnienie prawidłowego działania hostów Hyper-V. Ponieważ usługa HGS nie odgrywa żadnej roli w podejmowaniu decyzji o tym, co jest lub nie może działać, złośliwe oprogramowanie i debugery będą działać zgodnie z założeniami.

    Jednak debugery próbujące dołączyć bezpośrednio do procesu (na przykład WinDbg.exe) są blokowane dla chronionych maszyn wirtualnych, ponieważ proces roboczy maszyny wirtualnej (VMWP.exe) jest chronionym procesem light (PPL). Alternatywne techniki debugowania, takie jak te używane przez LiveKd.exe, nie są blokowane. W przeciwieństwie do chronionych maszyn wirtualnych, proces roboczy maszyn wirtualnych z obsługą szyfrowania nie działa jako PPL, więc tradycyjne debugery, takie jak WinDbg.exe, będą nadal działać normalnie.

    Podobny tryb zaświadczania o nazwie Zaświadczenie zaufane przez administratora (oparte na usłudze Active Directory) jest przestarzały począwszy od systemu Windows Server 2019.

Wybrany poziom zaufania będzie ustanawiać wymagania sprzętowe dla hostów Hyper-V oraz zasady stosowane w infrastrukturze. W razie potrzeby można wdrożyć chronioną infrastrukturę przy użyciu istniejącego sprzętu i zaświadczenia zaufanego przez administratora, a następnie przekonwertować ją na zaświadczenie zaufane przez TPM, gdy sprzęt zostanie zaktualizowany i należy zwiększyć bezpieczeństwo infrastruktury.

Decyzja nr 2: Istniejąca sieć szkieletowa Hyper-V a nowa oddzielna sieć szkieletowa Hyper-V

Jeśli masz istniejącą infrastrukturę (Hyper-V lub inną), jest wysoce prawdopodobne, że możesz użyć jej do uruchamiania chronionych maszyn wirtualnych wraz ze zwykłymi maszynami wirtualnymi. Niektórzy klienci wybierają integrację chronionych maszyn wirtualnych z istniejącymi narzędziami i sieciami szkieletowymi, podczas gdy inni oddzielają sieć szkieletową ze względów biznesowych.

Planowanie przez administratora usługi HGS dla usługi Ochrona hosta

Wdróż Usługę Ochrony Hostów (HGS) w wysoce bezpiecznym środowisku, niezależnie od tego, czy znajduje się na dedykowanym serwerze fizycznym, osłoniętej maszynie wirtualnej, maszynie wirtualnej na izolowanym hoście Hyper-V (oddzielonym od chronionej infrastruktury) lub logicznie oddzielonym przy użyciu innej subskrypcji platformy Azure.

Obszar Szczegóły
Wymagania dotyczące instalacji
  • Jeden serwer (klaster z trzema węzłami zalecany w celu zapewnienia wysokiej dostępności)
  • W przypadku powrotu wymagane są co najmniej dwa serwery HGS
  • Serwery mogą być wirtualne lub fizyczne (zalecany serwer fizyczny z modułem TPM 2.0; Obsługiwany jest również moduł TPM 1.2)
  • Instalacja Server Core systemu Windows Server 2016 lub nowszego
  • Widok sieciowy do sieci szkieletowej zezwalający na konfigurację rezerwową HTTP lub
  • Certyfikat HTTPS zalecany do weryfikacji dostępu
Rozmiar Każdy węzeł serwera HGS o średnim rozmiarze (8 rdzeni/4 GB) może obsługiwać 1000 hostów Hyper-V.
Zarządzanie Wyznaczanie konkretnych osób, które będą zarządzać usługą HGS. Powinni być oddzieleni od administratorów infrastruktury. Dla porównania klastry HGS można traktować w taki sam sposób, jak urząd certyfikacji pod względem izolacji administracyjnej, wdrożenia fizycznego i ogólnego poziomu poufności zabezpieczeń.
Usługa Active Directory ochrona hosta Domyślnie usługa HGS instaluje własną wewnętrzną usługę Active Directory do zarządzania. Jest to samodzielnie zarządzany las i jest zalecaną konfiguracją, która pomaga odizolować HGS od struktury.

Jeśli masz już wysoce uprzywilejowany las usługi Active Directory używany do izolacji, możesz użyć tego lasu zamiast domyślnego lasu usługi HGS. Należy pamiętać, że HGS nie jest przyłączone do domeny w tym samym lesie co hosty Hyper-V ani narzędzia do zarządzania infrastrukturą. Dzięki temu administrator sieci może przejąć kontrolę nad HGS.
Odzyskiwanie po awarii Dostępne są trzy opcje:
  1. Zainstaluj oddzielny klaster usługi HGS w każdym centrum danych i autoryzuj maszyny wirtualne z osłoną do uruchamiania zarówno w głównych centrach danych, jak i w centrach danych kopii zapasowych. Pozwala to uniknąć konieczności rozciągnięcia klastra przez sieć WAN i umożliwia odizolowanie maszyn wirtualnych tak, aby działały tylko w wyznaczonej lokacji.
  2. Zainstaluj usługę HGS w klastrze rozproszynym między dwoma (lub więcej) centrami danych. Zapewnia to odporność na wypadek awarii sieci WAN, ale testuje granice klastra w trybie przełączenia awaryjnego. Nie można odizolować obciążeń do jednej lokacji; maszyna wirtualna autoryzowana do uruchamiania w jednej lokacji może działać w dowolnej innej.
  3. Zarejestruj hosta Hyper-V przy użyciu innej usługi HGS jako trybu failover.
Należy również utworzyć kopię zapasową każdej usługi HGS, eksportując jej konfigurację, aby zawsze można było odzyskać lokalnie. Aby uzyskać więcej informacji, zobacz Export-HgsServerState i Import-HgsServerState.
Klucze usługi Strażnika hosta Usługa Ochrona hosta używa dwóch par kluczy asymetrycznych — klucza szyfrowania i klucza podpisywania — każdy reprezentowany przez certyfikat SSL. Istnieją dwie opcje generowania tych kluczy:
  1. Wewnętrzny urząd certyfikacji — te klucze można wygenerować przy użyciu wewnętrznej infrastruktury PKI. Jest to odpowiednie dla środowiska centrum danych.
  2. Publicznie zaufane urzędy certyfikacji — użyj zestawu kluczy uzyskanych z publicznie zaufanego urzędu certyfikacji. Jest to opcja, która powinna być używana przez hosterów.
Należy pamiętać, że chociaż istnieje możliwość używania certyfikatów z podpisem własnym, nie zaleca się używania scenariuszy wdrażania innych niż laboratoria weryfikacji koncepcji.

Oprócz posiadania kluczy usługi HGS, hoster może zastosować zasadę "przynieś swój własny klucz", gdzie dzierżawcy mogą dostarczyć własne klucze, aby niektórzy (lub wszyscy) mogli mieć swoje unikalne klucze usługi HGS. Ta opcja jest odpowiednia dla hostów, którzy mogą zapewnić niezależny proces dla dzierżawców w celu przesłania swoich kluczy.
Magazyn kluczy usługi Host Guardian Service W przypadku najsilniejszych możliwych zabezpieczeń zalecamy utworzenie i zapisanie kluczy HGS wyłącznie w sprzętowym module zabezpieczeń (HSM). Jeśli nie używasz modułów HSM, zdecydowanie zaleca się stosowanie funkcji BitLocker na serwerach HGS.

Planowanie przez administratora infrastruktury dla hostów chronionych

Obszar Szczegóły
Sprzęt
System operacyjny Zalecamy użycie opcji Server Core dla systemu operacyjnego hosta Hyper-V.
Implikacje dotyczące wydajności Na podstawie testów wydajnościowych przewidujemy około 5% różnicę gęstości między uruchomionymi maszynami wirtualnymi z osłoną a maszynami wirtualnymi bez osłony. Oznacza to, że jeśli dany host Hyper-V może uruchamiać 20 niechłoniętych maszyn wirtualnych, oczekujemy, że może uruchomić 19 chronionych maszyn wirtualnych.

Upewnij się, że weryfikujesz wielkość w kontekście typowych obciążeń roboczych. Na przykład mogą istnieć pewne wartości odstające z intensywnymi obciążeniami we/wy zorientowanymi na zapis, które dodatkowo wpłyną na różnicę gęstości.
Zagadnienia dotyczące biura oddziału Począwszy od systemu Windows Server w wersji 1709, można określić rezerwowy adres URL zwirtualizowanego serwera HGS działającego lokalnie jako maszynę wirtualną z osłoną w oddziale. Rezerwowy adres URL może być używany, gdy oddział utraci łączność z serwerami HGS w centrum danych. W poprzednich wersjach systemu Windows Server host Hyper-V działający w oddziale potrzebuje łączności z usługą Host Guardian Service, aby uruchomić lub przeprowadzać migrację na żywo ekranowanych maszyn wirtualnych. Aby uzyskać więcej informacji, zobacz Zagadnienia dotyczące biura oddziału.