Credential Guard i Device Guard: Jak chronić dane uwierzytelniające i integralność systemu na Windows Server

Współczesne zagrożenia cybernetyczne ewoluują w zastraszającym tempie, zmuszając organizacje do ciągłego doskonalenia swoich strategii obronnych. Ataki ukierunkowane na kradzież danych uwierzytelniających oraz manipulację integralnością systemu stanowią jedne z najbardziej dewastujących wektorów zagrożeń. Na szczęście, Windows Server oferuje zaawansowane mechanizmy zabezpieczeń, takie jak Credential Guard i Device Guard, które stanowią kluczowe elementy w budowaniu odpornej infrastruktury IT.

Ten obszerny artykuł ma na celu dostarczenie eksperckiej wiedzy na temat tych technologii, ich implementacji, optymalizacji oraz integracji w kompleksowej strategii bezpieczeństwa.

1. Wprowadzenie do Architektury Zabezpieczeń Windows Server

Zanim zagłębimy się w szczegóły Credential Guard i Device Guard, kluczowe jest zrozumienie fundamentalnych filarów architektury bezpieczeństwa Windows Server. System ten został zaprojektowany z myślą o warstwowym podejściu do ochrony, gdzie każda warstwa wzmacnia poprzednią.

• Izolacja Procesów: Windows Server wykorzystuje mechanizmy izolacji procesów, aby zapobiegać wzajemnemu wpływowi aplikacji i usług, ograniczając potencjalne rozprzestrzenianie się złośliwego oprogramowania.
• Kontrola Dostępu: Lista kontroli dostępu (ACL) na poziomie obiektów systemu plików i rejestru zapewnia granularną kontrolę nad uprawnieniami użytkowników i procesów.
• Kryptografia: Wbudowane narzędzia kryptograficzne, takie jak BitLocker, TLS/SSL oraz mechanizmy podpisu cyfrowego, chronią dane w spoczynku i w transporcie.
• Audyt i Logowanie: Szczegółowe logi zdarzeń bezpieczeństwa umożliwiają monitorowanie aktywności systemu i wykrywanie anomalii.

Credential Guard i Device Guard wznoszą te podstawowe zabezpieczenia na wyższy poziom, wprowadzając mechanizmy oparte na wirtualizacji, które znacząco podnoszą poprzeczkę dla atakujących.

2. Credential Guard: Fortyfikowanie Danych Uwierzytelniających

2.1. Geneza Problemu: Ataki Pass-the-Hash (PtH) i Pass-the-Ticket (PtT)

Tradycyjnie, dane uwierzytelniające użytkowników, takie jak skróty NTLM (NT LAN Manager) i bilety Kerberos, przechowywane były w pamięci procesów systemu operacyjnego, głównie LSA (Local Security Authority). To podejście, choć funkcjonalne, stwarzało poważne luki bezpieczeństwa. Ataki typu Pass-the-Hash (PtH) i Pass-the-Ticket (PtT) wykorzystywały właśnie tę podatność:

• Pass-the-Hash (PtH): Atakujący, uzyskując dostęp do skrótu NTLM hasła użytkownika przechowywanego w pamięci LSA, mogli użyć go do uwierzytelnienia się w innych systemach bez znajomości oryginalnego hasła. Narzędzia takie jak Mimikatz stały się de facto standardem w środowisku ofensywnym do ekstrakcji tych skrótów.
• Pass-the-Ticket (PtT): Podobnie, bilety Kerberos, wykorzystywane do uwierzytelniania w środowiskach Active Directory, mogły zostać skradzione z pamięci i ponownie użyte, umożliwiając nieuprawniony dostęp do zasobów.

Te ataki są niezwykle skuteczne w scenariuszach lateral movement (przesuwania się w bok) w sieci, gdzie atakujący, po początkowym naruszeniu jednego systemu, wykorzystuje skradzione dane uwierzytelniające do uzyskania dostępu do kolejnych maszyn, aż do osiągnięcia celu, często konta z uprawnieniami administratora domeny.

2.2. Rewolucja: Izolacja Oparta na Wirtualizacji (VBS)

Credential Guard radykalnie zmienia ten krajobraz, wprowadzając izolację opartą na wirtualizacji (VBS – Virtualization-based Security). Kluczową ideą jest odseparowanie kluczowych danych uwierzytelniających od reszty systemu operacyjnego za pomocą dedykowanego, chronionego środowiska.

👉 Jak to działa:

1. Odizolowana Pamięć: LSA jest przeniesiona do chronionego obszaru pamięci, który jest izolowany od reszty systemu operacyjnego. Ten obszar jest zarządzany przez hypervisor (np. Hyper-V) i jest niedostępny nawet dla procesów działających z najwyższymi uprawnieniami w standardowym systemie operacyjnym.
2. Uniemożliwienie Eksfiltracji: Skróty NTLM i bilety Kerberos nigdy nie są przechowywane w odsłoniętej formie w pamięci głównego systemu operacyjnego. Zamiast tego, procesy systemowe komunikują się z LSA w chronionym obszarze pamięci za pośrednictwem bezpiecznych kanałów.
3. Wirtualizacja i Bezpieczeństwo: Credential Guard wykorzystuje funkcje sprzętowe, takie jak rozszerzenia wirtualizacji (Intel VT-x, AMD-V) oraz jednostka zarządzania pamięcią we/wy (IOMMU), aby zapewnić integralność i poufność chronionego obszaru pamięci.

Dzięki temu, nawet jeśli atakujący zdoła przejąć kontrolę nad systemem operacyjnym i uruchomi złośliwe oprogramowanie z uprawnieniami SYSTEM, nie będzie w stanie uzyskać dostępu do wrażliwych danych uwierzytelniających, ponieważ są one przechowywane poza jego zasięgiem.

2.3. Wymagania i Implementacja Credential Guard

Wdrożenie Credential Guard wymaga spełnienia szeregu precyzyjnych wymagań sprzętowych i programowych, aby zapewnić pełną skuteczność mechanizmu VBS:

2.3.1. Wymagania Sprzętowe

• Procesor 64-bitowy: Wymagany jest procesor 64-bitowy z rozszerzeniami wirtualizacji (Intel VT-x lub AMD-V).
• Rozszerzenia Wirtualizacji (Intel VT-x/AMD-V): Muszą być włączone w oprogramowaniu układowym (firmware/UEFI) serwera.
• Drugi Poziom Adresowania (SLAT): Procesor musi obsługiwać SLAT (Second Level Address Translation), znany również jako EPT (Extended Page Tables) dla Intel lub NPT (Nested Page Tables) dla AMD.
• Trusted Platform Module (TPM) 2.0: Zalecany, choć nie zawsze obligatoryjny w przypadku niektórych konfiguracji, TPM 2.0 zapewnia bezpieczne przechowywanie kluczy i pomiary integralności rozruchowej, co znacząco wzmacnia bezpieczeństwo VBS.
• UEFI z Secure Boot: UEFI (Unified Extensible Firmware Interface) z włączoną funkcją Secure Boot jest niezbędne. Secure Boot zapewnia, że system uruchamia tylko zaufane oprogramowanie, chroniąc przed rootkitami i bootkitami.
• IOMMU (Intel VT-d lub AMD-Vi): Jednostka zarządzania pamięcią wejścia/wyjścia (IOMMU) jest kluczowa dla ochrony pamięci przed bezpośrednim dostępem urządzeń peryferyjnych (DMA attacks). Musi być włączona w UEFI.

2.3.2. Wymagania Oprogramowania

• Windows Server 2016 lub nowszy: Credential Guard jest dostępny w systemach Windows Server 2016, 2019 i 2022.
• Funkcja Hyper-V: Mimo że Credential Guard nie wymaga pełnej roli Hyper-V z maszynami wirtualnymi, sama funkcja Hyper-V (podsystem wirtualizacji) musi być zainstalowana, ponieważ to ona udostępnia hypervisor.

2.3.3. Metody Wdrażania

Credential Guard może być wdrożony za pomocą kilku metod, zależnie od skali środowiska i preferowanych narzędzi zarządzania:

• Zasady Grupy (Group Policy): Najpopularniejsza metoda dla środowisk domenowych. Wymaga skonfigurowania odpowiednich zasad w GPO, które następnie zostaną zastosowane do docelowych serwerów.
  • Computer Configuration -> Administrative Templates -> System -> Device Guard -> Turn On Virtualization Based Security
  • Wybierając tę opcję, można skonfigurować poziom ochrony VBS.
• Rejestr (Registry): Ręczna modyfikacja rejestru, choć możliwa, jest zalecana tylko w małych środowiskach lub do celów testowych.
• Microsoft Endpoint Configuration Manager (MECM) / Intune: Dla dużych, zarządzanych środowisk, MECM lub Intune oferują scentralizowane zarządzanie i wdrażanie ustawień Credential Guard.
• Skrypty PowerShell: Skrypty PowerShell mogą być używane do zautomatyzowania procesu włączania Credential Guard na wielu serwerach.

# Przykład skryptu PowerShell do włączania Credential Guard
# Upewnij się, że spełnione są wszystkie wymagania sprzętowe i programowe.

# Sprawdź, czy funkcja Hyper-V jest zainstalowana
If (-Not (Get-WindowsFeature -Name Hyper-V)) {
    Write-Host "Instalowanie funkcji Hyper-V..."
    Add-WindowsFeature -Name Hyper-V -IncludeManagementTools
    # Może wymagać ponownego uruchomienia
    # Restart-Computer -Force
}

# Włącz Virtualization-based Security (VBS) i Credential Guard
# Ustawienie opcji 3 w SecurityBasedVirtualizationEnabled oznacza "Enable with UEFI lock"
# Opcja 1 dla CredentialGuardConfig oznacza "Enabled"

$path = "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa"
Set-ItemProperty -Path $path -Name "LsaCfgFlags" -Value 1 -Force
Set-ItemProperty -Path $path -Name "SecurityBasedVirtualizationEnabled" -Value 3 -Force

Write-Host "Credential Guard został włączony. Wymagane ponowne uruchomienie systemu."

2.3.4. Weryfikacja Działania

Po wdrożeniu kluczowe jest upewnienie się, że Credential Guard działa poprawnie.

• Podgląd Zdarzeń: Sprawdź dziennik zdarzeń systemowych:
  • Applications and Services Logs -> Microsoft -> Windows -> Kernel-Boot -> Operational
  • Szukaj zdarzeń z ID 12, 13, 51 dla potwierdzenia aktywacji VBS i Credential Guard.
  • Applications and Services Logs -> Microsoft -> Windows -> LSA -> Operational
  • Szukaj zdarzeń z ID 3072 (Credential Guard Enabled) lub 3073 (Credential Guard Disabled).
• Informacje o Systemie (msinfo32):
  • Uruchom msinfo32.
  • Przejdź do sekcji System Summary.
  • Sprawdź wiersze Virtualization-based security oraz Virtualization-based security running services. Powinno być widoczne Running.
• Skrypt PowerShell:

Get-CimInstance -ClassName Win32_DeviceGuard -Namespace "root\Microsoft\Windows\DeviceGuard"

Sprawdź wartość CredentialGuardEnabled i VirtualizationBasedSecurityEnabled.

3. Device Guard: Strażnik Integralności Systemu

3.1. Wyzwanie: Ewolucja Złośliwego Oprogramowania

Tradycyjne rozwiązania antywirusowe opierające się na sygnaturach stały się niewystarczające w obliczu zaawansowanych ataków typu zero-day i polimorficznego złośliwego oprogramowania. Zdolność złośliwego kodu do ukrywania się, modyfikowania sygnatur i omijania mechanizmów wykrywania stanowiła poważne wyzwanie dla bezpieczeństwa systemów. Złośliwe oprogramowanie, które zdołało uruchomić się na poziomie jądra systemu (kernel-mode rootkity), mogło skutecznie ukrywać swoją obecność i manipulować integralnością systemu.

3.2. Przełom: Kontrola Aplikacji Opierająca się na Hipernadzorcy

Device Guard (obecnie często określany jako Windows Defender Application Control – WDAC) to potężny mechanizm kontroli aplikacji, który wykorzystuje izolację opartą na wirtualizacji (VBS) do zapewnienia integralności systemu. Jego podstawową funkcją jest egzekwowanie polityk kodu (code integrity policies), które określają, jakie aplikacje, skrypty i sterowniki mogą być uruchomione w systemie.

👉 Jak to działa:

1. Polityki Integralności Kodu: Administratorzy tworzą i podpisują polityki integralności kodu, które precyzują, które pliki wykonywalne są dozwolone. Polityki te mogą opierać się na różnych kryteriach:
   • Certyfikat Podpisu Cyfrowego: Najbezpieczniejsza opcja. Dozwolone są tylko aplikacje podpisane cyfrowo przez zaufanych wydawców (np. Microsoft, zaufani dostawcy oprogramowania, własne certyfikaty organizacji).
   • Atrybuty Hash: Pliki są identyfikowane na podstawie ich kryptograficznych skrótów. Mniej elastyczne, ponieważ każda zmiana w pliku (nawet aktualizacja) zmienia skrót, wymagając aktualizacji polityki.
   • Ścieżka: Dozwolone są pliki z określonych ścieżek na dysku. Najmniej bezpieczna opcja, ponieważ złośliwe oprogramowanie może zostać umieszczone w zaufanej ścieżce.
2. Ochrona VBS: Silnik egzekwujący polityki integralności kodu działa w chronionym obszarze pamięci VBS, podobnie jak Credential Guard. To oznacza, że nawet jeśli system operacyjny zostanie skompromitowany, złośliwe oprogramowanie nie jest w stanie wyłączyć lub zmodyfikować tych polityk.
3. Wymuszanie na Poziomie Jądra: Kontrola aplikacji jest wymuszana na poziomie jądra systemu, co oznacza, że żaden niedozwolony kod nie może zostać załadowany lub uruchomiony, nawet jeśli działa z uprawnieniami SYSTEM.

W efekcie, Device Guard tworzy zamknięte środowisko, gdzie tylko zaufane aplikacje mogą działać, znacząco zmniejszając powierzchnię ataku i utrudniając wykonanie złośliwego oprogramowania, nawet w przypadku udanego naruszenia innych mechanizmów bezpieczeństwa.

3.3. Wymagania i Implementacja Device Guard (WDAC)

Wymagania dla Device Guard są bardzo podobne do Credential Guard, ponieważ obie technologie opierają się na VBS.

3.3.1. Wymagania Sprzętowe

• Procesor 64-bitowy z rozszerzeniami wirtualizacji (Intel VT-x/AMD-V) i SLAT.
• UEFI z Secure Boot.
• IOMMU (Intel VT-d lub AMD-Vi).
• TPM 2.0: Zalecany dla wzmocnienia integralności.

3.3.2. Wymagania Oprogramowania

• Windows Server 2016 lub nowszy.
• Funkcja Hyper-V (podsystem wirtualizacji).

3.3.3. Tworzenie i Wdrażanie Polityk WDAC

Proces wdrażania Device Guard (WDAC) jest bardziej złożony niż włączenie Credential Guard, ponieważ wymaga starannego tworzenia i testowania polityk.

1. Tryb Audytu (Audit Mode): Zawsze zaczynaj od trybu audytu. W tym trybie WDAC rejestruje wszystkie próby uruchomienia niezatwierdzonych aplikacji, ale ich nie blokuje. Pozwala to na identyfikację wszystkich legalnych aplikacji działających w środowisku i wyeliminowanie false positives.
   • Użyj New-CIPolicy do wygenerowania polityki z istniejącego systemu referencyjnego.
   • Użyj Set-RuleOption do skonfigurowania polityki w trybie audytu (np. opcja 0 Enable Audit Mode).
2. Generowanie Polityki:
   • Złoty Obraz/System Referencyjny: Najlepszą praktyką jest zbudowanie „złotego obrazu” serwera z wszystkimi niezbędnymi aplikacjami i sterownikami. Następnie, na tym obrazie, wygenerować politykę WDAC.
   • Skanowanie Aplikacji: New-CIPolicy -FilePath .\DeviceGuardPolicy.xml -Level Publisher -Fallback Hash -ScanPath C:\
     • Level Publisher: generuje reguły na podstawie podpisu wydawcy, co jest najbardziej elastyczne.
     • Fallback Hash: w przypadku braku podpisu, generuje reguły oparte na skrócie.
     • ScanPath: określa ścieżkę do skanowania w poszukiwaniu plików wykonywalnych.
3. Modyfikacja Polityki (PowerShell lub XML):
   • Polityki WDAC są plikami XML. Można je edytować ręcznie lub za pomocą poleceń PowerShell, aby dodać lub usunąć reguły, na przykład:
     • Dodanie konkretnego podpisu certyfikatu.
     • Dodanie reguł dla sterowników.
     • Wykluczenie konkretnych ścieżek (należy być ostrożnym).
4. Podpisywanie Polityki: Aby zapobiec manipulacji polityką przez złośliwe oprogramowanie, powinna być ona podpisana cyfrowo za pomocą zaufanego certyfikatu (np. z PKI organizacji).
   • Set-CIPolicyIdInfo -FilePath .\DeviceGuardPolicy.xml -PolicyId <GUID> -PolicyName "MyWDACPolicy"
   • ConvertFrom-CIPolicy -FilePath .\DeviceGuardPolicy.xml -BinaryFilePath .\MyWDACPolicy.bin
   • Sign-CIPolicy -FilePath .\MyWDACPolicy.bin -UserSigningCert <Certificate>
5. Wdrażanie Polityki:
   • Zasady Grupy (GPO): Najlepsza metoda dla środowisk domenowych. Skopiuj binarny plik polityki (.bin) do odpowiedniego folderu w GPO:
     • Computer Configuration -> Administrative Templates -> System -> Device Guard -> Deploy Code Integrity Policy.
   • Microsoft Endpoint Configuration Manager (MECM) / Intune: Zapewniają scentralizowane zarządzanie i wdrażanie polityk.
   • Lokalnie (PowerShell): Set-CIPolicy -FilePath .\MyWDACPolicy.bin -Enforced
6. Tryb Wymuszania (Enforced Mode): Po dokładnym przetestowaniu w trybie audytu i upewnieniu się, że wszystkie legalne aplikacje działają, przejdź do trybu wymuszania.

3.3.4. Monitorowanie i Zarządzanie

• Dziennik Zdarzeń: Monitoruj dzienniki zdarzeń w Applications and Services Logs -> Microsoft -> Windows -> CodeIntegrity -> Operational.
  • Zdarzenia z ID 3076 wskazują na zablokowane pliki w trybie wymuszania.
  • Zdarzenia z ID 3077 wskazują na audytowane pliki w trybie audytu.
• Skrypt PowerShell: Get-SystemDriver -Enforced | Select-Object FileName, Signed, DriverPath
• Narzędzia Zewnętrzne: Użyj narzędzi SIEM do centralizacji i analizy logów WDAC.

4. Integracja Credential Guard i Device Guard w Strategii Bezpieczeństwa

Credential Guard i Device Guard, choć potężne, nie są panaceum na wszystkie zagrożenia. Ich maksymalna efektywność osiągana jest w ramach kompleksowej strategii bezpieczeństwa, integrującej różne warstwy obrony.

4.1. Strategia Ochrony Przed Zaawansowanymi Zagrożeniami

• Podejście „Zero Trust”: Wdrażaj zasady „Zero Trust”, gdzie każda próba dostępu, niezależnie od źródła, jest weryfikowana. Credential Guard i Device Guard idealnie wpisują się w tę filozofię, ograniczając zaufanie do środowiska uruchomieniowego.
• Zarządzanie Tożsamością i Dostępem (IAM): Silne uwierzytelnianie (MFA), zarządzanie uprzywilejowanym dostępem (PAM) i regularne audyty uprawnień są kluczowe. Credential Guard chroni dane uwierzytelniające, ale PAM zapobiega ich nadużyciom.
• Segmentacja Sieci: Izoluj wrażliwe systemy i dane w oddzielnych segmentach sieci. To ogranicza zdolność atakującego do lateral movement, nawet jeśli zdoła naruszyć jeden z segmentów.
• Regularne Aktualizacje i Łatki (Patch Management): Utrzymywanie systemów operacyjnych i aplikacji w aktualnym stanie jest fundamentalne. Credential Guard i Device Guard chronią przed znanymi i nieznanymi zagrożeniami, ale nie zastępują higieny IT.
• Monitorowanie i Wykrywanie Zagrożeń (EDR/SIEM): Implementacja zaawansowanych systemów wykrywania i reagowania na punkty końcowe (EDR) oraz systemów zarządzania informacjami o bezpieczeństwie i zdarzeniami (SIEM) jest kluczowa. Logi z Credential Guard i Device Guard powinny być agregowane i analizowane w SIEM w celu wykrywania anomalii.
• Kopie Zapasowe i Odzyskiwanie Danych (Backup & Recovery): Regularne, zaszyfrowane kopie zapasowe danych i plan odzyskiwania po awarii są ostatnią linią obrony przed utratą danych.

4.2. Wpływ na Wydajność i Rozwiązywanie Problemów

Implementacja Credential Guard i Device Guard może mieć marginalny wpływ na wydajność, głównie ze względu na narzut związany z wirtualizacją. W większości współczesnych serwerów ten wpływ jest niezauważalny.

Rozwiązywanie Problemów:

• Problemy z rozruchem: Upewnij się, że Secure Boot jest włączony i wszystkie sterowniki są podpisane.
• Problemy z aplikacjami (Device Guard): W trybie wymuszania, niedozwolone aplikacje nie będą działać. Sprawdź dziennik zdarzeń CodeIntegrity w celu zidentyfikowania zablokowanych procesów. Dodaj reguły do polityki WDAC dla legalnych, ale blokowanych aplikacji. Rozważ podpisanie wewnętrznych aplikacji własnym certyfikatem.
• Problemy z kompatybilnością: Niektóre starsze aplikacje lub sterowniki mogą nie być kompatybilne z Credential Guard lub Device Guard. Wymaga to gruntownego testowania.

5. Przyszłość Zabezpieczeń Windows Server

Microsoft aktywnie rozwija funkcje bezpieczeństwa w Windows Server. Kierunki rozwoju obejmują:

• Większa integracja z chmurą: Ulepszone mechanizmy bezpieczeństwa dla środowisk hybrydowych i chmurowych, w tym Azure Stack HCI i Azure Arc.
• AI/ML w detekcji zagrożeń: Wykorzystanie sztucznej inteligencji i uczenia maszynowego do predykcyjnego wykrywania i reagowania na zagrożenia.
• Większa granularność kontroli: Rozwój WDAC w kierunku bardziej precyzyjnej kontroli nad komponentami systemu.
• Automatyzacja i orkiestracja: Ułatwienie wdrażania i zarządzania złożonymi politykami bezpieczeństwa.

Credential Guard i Device Guard są kluczowymi elementami w tej ewolucji, stanowiącymi fundament dla budowy bezpiecznych i odpornych środowisk serwerowych.

Podsumowanie

W świecie, gdzie ataki cybernetyczne są coraz bardziej wyrafinowane, Credential Guard i Device Guard oferują niezrównany poziom ochrony danych uwierzytelniających i integralności systemu na Windows Server. Ich implementacja, choć wymaga dogłębnego zrozumienia i starannego planowania, jest inwestycją, która znacząco redukuje ryzyko naruszeń i wzmacnia ogólną postawę bezpieczeństwa organizacji. Eksperci IT powinni traktować te technologie jako priorytet w swojej strategii ochrony danych i systemów.