Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Ten artykuł pomaga ustanowić podstawowe zasady ładu i zabezpieczeń, dzięki czemu każde obciążenie robocze w usłudze Rozwiązanie Azure VMware dziedziczy spójne mechanizmy kontrolne i ogranicza ryzyko przed wdrożeniem.
Ten artykuł pomaga decydentom ustalić bazowy poziom ładu i zabezpieczeń, dziedziczony domyślnie przez każde obciążenie Rozwiązanie Azure VMware. Poziom bazowy to minimalny zestaw zabezpieczeń, który dziedziczy każde obciążenie robocze Rozwiązanie Azure VMware przed wdrożeniem jakiegokolwiek zespołu odpowiedzialnego za obciążenie. Utworzysz i zachowasz te punkty odniesienia. Utwórz dodatkowe mechanizmy kontroli, aby spełnić potrzeby organizacji, takie jak zgodność z przepisami lub zarządzanie ryzykiem specyficznym dla obciążenia.
Niniejsze wytyczne bazowe opierają się na założeniu, że używane jest rozwiązanie Rozwiązanie Azure VMware Generation 2 (Gen 2), w którym chmura prywatna jest domyślnie wdrażana w sieci wirtualnej platformy Azure, co zapewnia natywną łączność z usługami Azure oraz natywne mechanizmy kontroli platformy Azure. Generacja 1 (Gen 1) stanowi wyjątek dotyczący starszej wersji i jest wymieniana tylko tam, gdzie jej możliwości się różnią.
Zastosuj te same punkty odniesienia ładu i zabezpieczeń do środowisk nieprodukcyjnych co w środowiskach produkcyjnych. Posiadanie spójnych punktów odniesienia oznacza mniejsze ryzyko słabych stron w całym majątku i upraszcza przenoszenie obciążeń z jednego środowiska do drugiego.
Zalecenie: Określ bazowy poziom ładu i zabezpieczeń, który musi obowiązywać dla każdego obciążenia uruchamianego w Rozwiązanie Azure VMware zarówno w środowisku Azure, jak i w prywatnej chmurze VMware, przed wdrożeniem aplikacji lub włączeniem zespołów operacyjnych.
1. Zakres bazowy ładu organizacyjnego
Rozwiązanie Azure VMware wymaga nadzoru w dwóch obszarach, a bazowy poziom zabezpieczeń obejmujący tylko jeden z tych obszarów pozostawia luki w zakresie kontroli i zarządzania ryzykiem.
Ład platformy Azure:obszar platformy Azure to zestaw zasobów platformy Azure, które obsługują chmurę prywatną, takich jak subskrypcja, sieć wirtualna, monitorowanie i przypisania ról platformy Azure. Zarządzasz nim za pomocą Azure narzędzi natywnych.
Nadzór nad chmurą prywatną:Powierzchnia VMware to sama chmura prywatna, taka jak segmenty sieci, zasady zapory, role vCenter i NSX oraz zasady magazynu. Większość z nich można zarządzać za pomocą narzędzi natywnych dla oprogramowania VMware wewnątrz chmury prywatnej.
Bazowy model ładu, obejmujący wyłącznie środowisko Azure albo wyłącznie środowisko VMware, powoduje luki w kontroli operacyjnej i zarządzaniu ryzykiem.
2. Wymuszanie ładu
Wymuś wymagania punktu odniesienia za pośrednictwem strefy docelowej platformy, jeśli jest to możliwe. Użyj ręcznych procesów operacyjnych, aby obsługiwać wymuszanie, gdy kontrolki techniczne nie są dostępne.
Zastosuj Azure Policy na poziomie grupy zarządzania, subskrypcji lub grupy zasobów, aby określić obowiązkowe wymagania dotyczące każdego wdrożenia Rozwiązanie Azure VMware. Korzystając z Azure Policy, można zapewnić spójność w Rozwiązanie Azure VMware chmurach prywatnych, szczególnie w przypadku delegowania administracji programu VMware do właścicieli obciążeń. Dostosuj te wymagania do standardów już stosowanych w całym środowisku platformy Azure. Niektóre standardowe zasady i mechanizmy wymuszania obejmują:
Granice wdrożenia:Dozwolone lokalizacje
SKU usługi Rozwiązanie Azure VMware:Dozwolone typy zasobów (dostosowane do usługi Rozwiązanie Azure VMware)
Ochrona chmury prywatnej: blokady zasobów (nie definicja Azure Policy)
3. Punkt odniesienia zabezpieczeń
Każde wdrożenie Rozwiązanie Azure VMware powinno opierać się na zatwierdzonej bazowej konfiguracji zabezpieczeń przed wdrożeniem obciążeń. Zacznij od bazowego poziomu zabezpieczeń platformy Azure dla usługi Rozwiązanie Azure VMware, który mapuje możliwości usługi Rozwiązanie Azure VMware na wzorzec zabezpieczeń chmury firmy Microsoft i zawiera zalecenia firmy Microsoft dotyczące zabezpieczeń. Microsoft Defender dla Chmury mogą stale oceniać środowisko pod kątem odpowiednich zaleceń i mechanizmów kontroli regulacyjnej. Definicje usługi Azure Policy skojarzone z mechanizmami kontroli wzorców odniesienia są dostępne w obszarze Zgodność z przepisami w Microsoft Defender dla Chmury. Zobacz Rozwiązanie Azure VMware zalecenia dotyczące zabezpieczeń.
4. punkt odniesienia tożsamości dla Rozwiązanie Azure VMware
Rozwiązanie Azure VMware korzysta z istniejących usług tożsamości, dlatego punkt odniesienia odnosi się do sposobu nawiązywania połączenia i zasobów, takich jak maszyny wirtualne, a nie wdrażania nowych usług tożsamości. Ten punkt odniesienia odnosi się do usług tożsamości używanych przez samą Rozwiązanie Azure VMware i nie ma wpływu na usługi tożsamości używane przez poszczególne obciążenia aplikacji działające w programie VMware.
4.1 Dostawca tożsamości
Użyj zewnętrznego źródła tożsamości na potrzeby dostępu do programu vCenter, a nie wbudowanego konta CloudAdmin. Rozwiązanie Azure VMware obsługuje zarówno Microsoft Entra ID, jak i Active Directory (LDAPS) jako zewnętrzne źródła tożsamości dla programu vCenter Server.
Opcja 1. Microsoft Entra ID (zalecane). Organizacje, które już korzystają ze standardu Microsoft Entra ID, powinny wybrać federację Entra ID, ponieważ centralizuje ona nadzór nad tożsamościami, Dostęp warunkowy i uwierzytelnianie wieloskładnikowe w administracji środowiskami Azure i VMware.
Opcja 2. Active Directory Domain Services za pośrednictwem protokołu LDAPS. Organizacje zależne operacyjnie od administracji VMware zintegrowanej z usługą Active Directory mogą nadal korzystać z protokołu LDAPS. Zapewnia ciągłość z istniejącymi przepływami pracy administratora VMware zintegrowanymi z usługą AD. Uruchamiasz kontrolery domeny AD na platformie Azure centralnie, w subskrypcji tożsamości platformy.
4.2 Uprawnienia użytkownika
Decyzje dotyczące dostępu użytkowników określają podstawę bezpiecznego administrowania Rozwiązanie Azure VMware. Przed dołączaniem zespołów operacyjnych zdefiniuj sposób uzyskiwania dostępu przez administratorów, ról, których mogą używać, oraz sposobu przeglądania dostępu w czasie.
Przypisanie oparte na grupach: Zdefiniuj grupy administratorów przed dołączaniem zespołów operacyjnych. Przypisz użytkowników do grup i przypisz grupy do ról. Unikaj bezpośrednich przypisań użytkowników z wyjątkiem wyjątków tymczasowych.
Role programu vCenter z najmniejszymi uprawnieniami: Użyj niestandardowych ról programu vCenter, gdy rola CloudAdmin udziela więcej dostępu niż potrzebuje zespół. Rozwiązanie Azure VMware obsługuje role niestandardowe w programie vCenter z uprawnieniami równymi lub niższym niż rola CloudAdmin. Nie oferuje ról niestandardowych w portalu Rozwiązanie Azure VMware.
Takie samo podejście do rozwiązania NSX Manager: Zastosuj ten sam proces zarządzania dostępem do rozwiązania NSX Manager. Definiowanie zatwierdzonych ról administracyjnych, stosowanie najniższych uprawnień i przeprowadzanie okresowych przeglądów dostępu. Nie każda wstępnie zdefiniowana rola NSX jest obsługiwana, dlatego zdefiniuj niewielki zestaw zatwierdzonych ról NSX i regularnie je przegląda.
4.3 Rola Administratora chmury
Rola CloudAdmin w usłudze Rozwiązanie Azure VMware działa inaczej niż dostęp administratora VMware w środowisku lokalnym, a traktowanie jej jak konta administratora używanego na co dzień to częsty błąd. Traktuj CloudAdmin jako poświadczenie awaryjne typu break-glass, regularnie zmieniane, monitorowane i używane wyłącznie w sytuacjach awaryjnych. Udziel codziennego dostępu za pośrednictwem grup tożsamości zewnętrznych mapowanych na role z najmniejszymi uprawnieniami.
Tylko do użycia awaryjnego: Nie używaj wbudowanego konta CloudAdmin do codziennego administrowania ani integracji usług. Zarezerwuj go jako konto break-glass na potrzeby dostępu awaryjnego. Przechowuj dane uwierzytelniające w ramach procesu zarządzania dostępem uprzywilejowanym, regularnie je zmieniaj zgodnie z określonym harmonogramem i ustaw alerty dotyczące ich pobrania lub użycia.
Brak dostępu na poziomie hosta: Rozwiązanie Azure VMware administratorzy nie otrzymują konta programu vCenter Server administrator@vsphere.local ani konta głównego ESXi. Administratorzy mogą jednak przypisywać użytkowników i grupy Active Directory do roli CloudAdmin w programie vCenter Server.
Domena zarządzanego logowania jednokrotnego: Domena logowania jednokrotnego vsphere.local jest zasobem zarządzanym , który obsługuje operacje platformy. Nie można jej używać do tworzenia lokalnych użytkowników i grup poza kontami domyślnymi udostępnianymi w chmurze prywatnej ani zarządzania nimi.
Dodawanie źródła tożsamości: Rola CloudAdmin nie może bezpośrednio dodać źródła tożsamości (takiego jak LDAP/LDAPS). Użyj poleceń „Run”, aby dodać zewnętrzne źródło tożsamości i przypisać rolę CloudAdmin użytkownikom i grupom.
5. punkt odniesienia sieci Rozwiązanie Azure VMware
Każda chmura prywatna używa oprogramowania VMware NSX jako warstwy sieciowej zdefiniowanej programowo, zastępując model oparty na sieci VLAN z lokalnego oprogramowania VMware. Twoje zespoły tworzą segmenty NSX dla obciążeń roboczych, kierują ruch przez bramy Tier-0 i Tier-1 NSX oraz definiują reguły rozproszonej zapory. Zaplanuj wczesne podejście zabezpieczeń sieci i określ wyraźną granicę:
Użyj NSX dla ruchu wewnątrz środowiska Rozwiązanie Azure VMware (wschód-zachód).
Użyj natywnych dla platformy Azure lub lokalnych mechanizmów zabezpieczeń do obsługi ruchu, który przechodzi przez granicę usługi Rozwiązanie Azure VMware (północ–południe).
5.1 Punkt odniesienia ruchu wschód-zachód
Kontrolki wschód-zachód zarządzają ruchem między obciążeniami wewnątrz chmury prywatnej. Wymusza mikrosegmentację za pomocą rozproszonej zapory NSX dla każdego obciążenia. Dodaj element vDefend tylko wtedy, gdy wymagany jest określony cel kontrolki.
Opcja 1. Zapora NSX. Zawsze używaj rozproszonej zapory NSX, aby wymusić mikrosegmentację między obciążeniami. Mikrosegmentacja ogranicza ruch boczny, jeśli osoba atakująca osiągnie jedno obciążenie, takie jak zatrzymanie naruszonego serwera internetowego przed dotarciem do bazy danych. Zespoły często nie wykorzystują w pełni tej funkcji zaraz po migracji, dlatego uwzględnij ją w standardzie bazowym.
Opcja 2. Zapora NSX i zapora VMware vDefend. Jeśli rozproszona zapora nie spełnia określonego wymagania, oceń opcjonalny dodatek zapory VMware vDefend dla funkcji, które sam serwer NSX nie zapewnia, takich jak wykrywanie włamań i filtrowanie adresów URL. Stosuj je tylko wtedy, gdy te możliwości odpowiadają celowi kontrolnemu, który musisz spełnić.
Zastosuj tę samą zasadę najmniejszych uprawnień w NSX, ograniczając liczbę osób, które mogą zmieniać reguły zapory, segmenty i routing. Wdróż kontrolę zmian i audyt, ponieważ aktualizacje NSX mogą wpływać na współdzieloną łączność i zakłócać działanie wielu obciążeń.
5.2 Punkt odniesienia ruchu północno-południowy
Kontrole północno-południowe zarządzają ruchem wchodzącym i opuszczającym środowisko Rozwiązanie Azure VMware. Odpowiednie narzędzie zależy od szerszego projektu sieci Azure.
Opcja 1.Azure Firewall lub wirtualne urządzenie sieciowe (NVA) innej firmy. Wiele organizacji inspekcjonuje ten ruch za pomocą usługi Azure Firewall lub wirtualnego urządzenia sieciowego innej firmy umieszczonego w scentralizowanej subskrypcji platformy „Łączność”.
Opcja 2.Zapora bramy NSX na granicy sieci. Użyj zapory bramy NSX na brzegu środowiska Rozwiązanie Azure VMware, jeśli wolisz inspekcjonować ruch na granicy chmury prywatnej.
Opcja 3.Zapora lokalna. Niektóre kierują ruch wychodzący z Internetu przez istniejącą lokalną zaporę.
W przypadku Gen 2 dodaj grupy zabezpieczeń sieciowych platformy Azure (NSG) na poziomie sieci wirtualnej platformy Azure, aby dodać dodatkową, natywną dla platformy Azure warstwę zabezpieczeń uzupełniającą NSX. Gen 1 nie oferuje sieciowych grup zabezpieczeń.
Jeśli zastosujesz mechanizmy kontrolne na więcej niż jednej warstwie, zaplanuj, jak zapewnić ich spójność. Kontrolki podzielone między warstwy dodają złożoność, utrudniają rozwiązywanie problemów i mogą tworzyć niezamierzone ścieżki ruchu. Jeśli używasz zautomatyzowanych narzędzi sieciowych, z góry zdecyduj, jak będziesz synchronizować zasady między środowiskami VMware i Azure. Udokumentuj wymagania dotyczące łączności sieciowej obciążenia roboczego i upewnij się, że administratorzy VMware oraz nadrzędne zespoły administratorów sieci stosują ten sam proces dokumentowania i powiadamiania o zmianach.
6. plan bazowy kosztów Rozwiązanie Azure VMware
Zarządzanie kosztami określa zabezpieczenia finansowe dziedziczone przez każde wdrożenie Rozwiązanie Azure VMware. Potrzebujesz co najmniej budżetu z alertami, wymaganego standardu tagowania oraz wyznaczonej osoby zatwierdzającej zmiany pojemności dla każdej subskrypcji usługi Rozwiązanie Azure VMware.
Budżety i alerty: Za pomocą usługi Microsoft Cost Management ustaw progi budżetowe i alerty wydatków, aby przekroczenie budżetu było widoczne odpowiednio wcześnie. Wymagaj od zespołów obciążeń skonfigurowania alertów dotyczących progów użycia procesora CPU, pamięci i sieci vSAN oraz kierowania tych alertów do nazwanego właściciela operacji, aby odpowiedź nie była niejednoznaczna. Centralnie ustaw wartości progowe, na przykład uruchamianie alertu przy utrzymującym się wykorzystaniu CPU na poziomie 75% dla klastrów produkcyjnych, dzięki czemu decyzje dotyczące planowania pojemności opierają się na tych samych danych we wszystkich zespołach. Zobacz Konfigurowanie alertów dla Rozwiązanie Azure VMware.
Tagowanie: Wymagaj stosowania tagów do zasobów Rozwiązanie Azure VMware, aby można było przypisać koszty do właścicieli i obciążeń roboczych oraz je raportować. Zobacz Definicje zasad dotyczące tagowania zasobów.
Pojemność: Traktuj dodawanie hostów jako celową, zatwierdzoną akcję. Zdecyduj, kto może zatwierdzić nową pojemność. Określ standardy minimalnego i maksymalnego rozmiaru klastra oraz zatwierdzone regiony wdrażania, a także wymagaj bufora zapasu pojemności, aby magazyn danych nigdy nie był nadmiernie zapełniony. Zażądaj limitu przydziału hosta przed potrzebą. Wnioski o zwiększenie limitu nie wiążą się z żadnymi kosztami, ale zwiększenie dostępnej pojemności może potrwać kilka dni. Upewnij się, że proces obejmuje uzyskanie niezbędnych licencji programu VCF dla nowo dodanych hostów Rozwiązanie Azure VMware.
7. Plan bazowy maszyny wirtualnej gościa w usłudze Rozwiązanie Azure VMware
Microsoft zarządza infrastrukturą Rozwiązanie Azure VMware, w tym hostami ESXi, serwerem vCenter i serwerem NSX. Użytkownik pozostaje odpowiedzialny za systemy operacyjne gościa, aplikacje i mechanizmy kontroli zabezpieczeń, które działają wewnątrz każdej maszyny wirtualnej.
Rozszerz nadzór na systemy operacyjne gości, wdrażając maszyny wirtualne w rozwiązaniu VMware vSphere z obsługą usługi Azure Arc. Zobacz program VMware vSphere z obsługą usługi Azure Arc.
Gdy maszyna wirtualna jest obsługiwana przez usługę Arc, organizacje mogą korzystać z usługi Azure Policy Machine Configuration, usług Microsoft Defender, usługi Update Manager i innych funkcji zarządzania platformy Azure, przy użyciu tych samych procesów nadzoru, które są stosowane w przypadku maszyn wirtualnych platformy Azure. Zobacz Wbudowane definicje zasad dla serwerów z obsługą Azure Arc i Jak utworzyć niestandardowe definicje zasad konfiguracji maszyny.
7.1 Bazowa konfiguracja gościnna
Wymagaj wdrożenia usługi Azure Arc w ramach procesu aprowizacji maszyny wirtualnej. Wczesne wdrożenie zapewnia, że mechanizmy nadzoru obowiązują od pierwszego dnia, zamiast być dodawane później w wyniku ręcznej pracy. Azure Arc umożliwia korzystanie z funkcji, takich jak Inventory, Change Tracking i Machine Configuration.
Te usługi działają w Rozwiązanie Azure VMware tak samo jak w przypadku maszyn wirtualnych Azure po włączeniu usługi Arc przez gościa. Organizacje mogą następnie stosować te same standardy konfiguracji w środowiskach Azure, lokalnych oprogramowania VMware i Rozwiązanie Azure VMware.
7.2 Ochrona punktu końcowego
Standardy programu Endpoint Protection powinny pozostać spójne niezależnie od tego, gdzie działa maszyna wirtualna. W przypadku maszyn wirtualnych usługi Rozwiązanie Azure VMware rozwiązanie Azure Arc-enabled VMware vSphere zapewnia ścieżkę integracji niezbędną do wdrożenia usługi Ochrona punktu końcowego w usłudze Microsoft Defender i innych usług zabezpieczeń platformy Azure. Takie podejście umożliwia zespołom ds. zabezpieczeń zachowanie ujednoliconego widoku stanu zabezpieczeń punktu końcowego w środowisku hybrydowym. Zobacz Integrowanie Microsoft Defender dla Chmury z Rozwiązanie Azure VMware.
7.3 Punkt odniesienia stosowania poprawek
Microsoft odpowiada za stosowanie poprawek infrastruktury Rozwiązanie Azure VMware. W organizacji zazwyczaj za instalowanie poprawek gościnnych systemów operacyjnych i aplikacji odpowiada zespół ds. operacji IT lub zespoły administratorów obciążeń. Jeśli Twoja organizacja zależy od ustanowionych rozwiązań do stosowania poprawek dla przedsiębiorstw, kontynuuj korzystanie z tych narzędzi, w których istnieją zaawansowane wymagania dotyczące planowania lub aranżacji. Te wymagania mogą obejmować usługę Menedżer aktualizacji platformy Azure na maszynach wirtualnych rozwiązania Rozwiązanie Azure VMware z włączoną usługą Arc.
7.4 Punkt odniesienia rozszerzenia maszyny wirtualnej
Rozszerzenia maszyn wirtualnych zapewniają funkcje, takie jak monitorowanie zabezpieczeń, zbieranie danych telemetrycznych i zarządzanie operacyjne. Bez ładu wdrażanie rozszerzeń może stać się fragmentowane i trudne do kontrolowania.
Zdefiniuj zatwierdzony wykaz rozszerzeń i wymagaj, aby zespoły ds. obciążeń używały tylko autoryzowanych rozszerzeń. Połącz nadzór nad rozszerzeniami z usługą Azure Policy, aby wymuszać zgodność i wykrywać nieautoryzowane konfiguracje.