Microsoft AZ-801: Szyfrowanie, certyfikaty i PKI — Przewodnik do nauki

By Laurynas Brazys · 7 August 2026 · #microsoft #az-801 #certification #exam-prep #study-guide

Część Microsoft Windows Server Hybrid Administrator Associate AZ-801 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Microsoft, albo rozwiąż testy na czas na ExamRoll.io.

Przegląd

Szyfrowanie i infrastruktura klucza publicznego (PKI) stanowią fundament zaufania w środowisku hybrydowym opartym na Windows Server. Administratorzy muszą być w stanie zabezpieczać dane w spoczynku za pomocą BitLocker i EFS, tworzyć i obsługiwać korporacyjne PKI z AD CS i Online Responder, automatyzować cykl życia certyfikatów poprzez szablony i automatyczną rejestrację oraz integrować natywne dla chmury zarządzanie certyfikatami za pośrednictwem Azure Key Vault. Poniższe sekcje szczegółowo opisują architekturę, wymagania wstępne, wzorce wdrożeniowe i mechanizmy kontroli operacyjnej, które konsekwentnie pojawiają się w rzeczywistych środowiskach hybrydowych Windows Server.

BitLocker i EFS na Windows Server

Szyfrowanie dysków BitLocker chroni woluminy za pomocą kombinacji modułu TPM i mechanizmów ochrony klucza. TPM 2.0 jest aktualnym podstawowym zaleceniem; TPM 1.2 pozostaje wspierany, ale TPM 2.0 z UEFI i Secure Boot zapewnia silniejsze powiązanie łańcucha rozruchowego z rejestrami konfiguracji platformy (PCR) modułu TPM. W przypadku serwerów należy wymagać użycia TPM+PIN na woluminach systemu operacyjnego, aby dodać czynnik online, łagodząc ataki typu cold-boot i offline. Skonfiguruj to za pomocą zasad grupy (Group Policy) w sekcji BitLocker Drive Encryption (zasady Require additional authentication at startup; Allow enhanced PINs for startup). Gdy moduł TPM nie jest dostępny, możliwe jest użycie klucza startowego USB, ale jest to rozwiązanie gorsze pod względem operacyjnym i mniej bezpieczne.

Zarządzanie kluczami odzyskiwania jest obowiązkowe. W środowiskach AD DS należy deponować informacje o odzyskiwaniu w obiektach komputerów (msFVE-RecoveryInformation) za pomocą zasad grupy (zasady Choose how BitLocker-protected operating system drives can be recovered; Back up recovery passwords and key packages to AD DS). W scenariuszach urządzeń dołączonych do Azure AD klucze odzyskiwania są deponowane w obiekcie urządzenia Azure AD i są dostępne dla autoryzowanych administratorów w bloku Devices; zasady Intune mogą wymagać deponowania w Azure AD. Zweryfikuj deponowanie przed włączeniem szyfrowania na dużą skalę.

Funkcja Network Unlock eliminuje konieczność ręcznego wprowadzania kodu PIN dla serwerów dołączonych do domeny w bezpiecznych podsieciach centrum danych podczas ponownych uruchomień bez nadzoru. Wymagania wstępne obejmują woluminy systemu operacyjnego chronione przez TPM, oprogramowanie układowe UEFI, łączność przewodową bez bramkowania 802.1X w fazie przedrozruchowej, osiągalność rozgłoszeń DHCP oraz serwer Windows Deployment Services z funkcją Network Unlock i certyfikatem uwierzytelniania serwera wydanym przez korporacyjny urząd certyfikacji (CA) przy użyciu szablonu Network Unlock. Skonfiguruj obiekty GPO funkcji BitLocker, aby włączyć Network Unlock i upewnij się, że punkty OCSP/CRL urzędu certyfikacji są osiągalne dla serwera WDS. Funkcja Network Unlock nie ma zastosowania do hostów mobilnych ani bezprzewodowych.

Wstępna aprowizacja (pre-provisioning) przyspiesza wdrożenia na dużą skalę poprzez szyfrowanie zajętego miejsca już na etapie Windows PE podczas tworzenia obrazu. W sekwencjach zadań MDT/Configuration Manager użyj kroku Pre-provision BitLocker (manage-bde -on C: -used -skiphardwaretest), aby rozpocząć szyfrowanie przed wdrożeniem pełnego systemu operacyjnego; przełącz na pełną ochronę po dołączeniu do domeny i zastosowaniu zasad.

Zarządzaj centralnie funkcją BitLocker za pomocą Microsoft Endpoint Manager. Intune (MDM) wymusza szyfrowanie w tle z mechanizmami ochrony opartymi wyłącznie na TPM dla urządzeń dołączonych do Azure AD i deponuje klucze w Azure AD; wymaganie kodu PIN przy uruchamianiu wyklucza szyfrowanie w tle i wymaga interakcji użytkownika. Dla serwerów dołączonych do domeny i w środowiskach mieszanych użyj Configuration Manager BitLocker Management (następcy MBAM) do raportowania zgodności, deponowania, portali i rotacji kluczy. Zawsze projektuj system pod kątem audytowalnego deponowania i mapowania właścicieli.

EFS to szyfrowanie na poziomie plików, powiązane z certyfikatami EFS użytkownika. Dla każdego pliku generowany jest klucz szyfrowania pliku (FEK), który jest szyfrowany kluczem publicznym EFS użytkownika. W przypadku braku korporacyjnego urzędu certyfikacji (CA), system Windows wydaje certyfikat EFS z podpisem własnym, co utrudnia odzyskiwanie i centralną kontrolę. We wdrożeniach korporacyjnych wydawaj certyfikaty EFS z AD CS przy użyciu szablonu Basic EFS i wyznaczaj agentów odzyskiwania danych (DRA) za pomocą GPO (Public Key Policies, Encrypting File System), aby zapewnić możliwość odzyskania plików zaszyfrowanych przez użytkowników. Narzędzie wiersza poleceń cipher pozostaje kluczowe: cipher /e i /d szyfrują lub deszyfrują; cipher /r generuje pary kluczy DRA; cipher /u aktualizuje zaszyfrowane pliki, aby używały bieżącego certyfikatu EFS. Używaj funkcji BitLocker do ochrony na poziomie woluminu, a EFS tylko wtedy, gdy wymagana jest separacja na poziomie użytkownika lub pliku, pamiętając, że EFS wymaga zalogowania użytkownika i dostępności certyfikatu.

Hierarchia AD CS i usługa Online Responder

Odporna infrastruktura PKI w przedsiębiorstwie wykorzystuje hierarchię urzędów certyfikacji (CA) zorganizowaną warstwowo. Główny urząd certyfikacji (root CA) w trybie offline jest kotwicą zaufania i musi być fizycznie oraz logicznie odizolowany. Jest on włączany tylko w celu podpisywania żądań podrzędnych urzędów certyfikacji i publikowania list CRL. Należy stosować długi okres ważności (np. 10–20 lat), duże rozmiary kluczy RSA (co najmniej 4096, jeśli to możliwe) oraz publikować punkty CDP/AIA pod wysoko dostępnymi adresami URL o spójnej ścieżce. Nigdy nie należy wystawiać certyfikatów końcowych (end-entity) bezpośrednio z głównego urzędu certyfikacji.

Podrzędne (wystawiające) urzędy certyfikacji są przyłączone do domeny, działają w trybie online i mają krótki okres ważności (np. 3–5 lat) z ograniczonym zastosowaniem kluczy (key usage) i rozszerzeniami EKU. Wystawiają one certyfikaty dla komputerów, użytkowników i usług oraz publikują często listy CRL z nakładającymi się okresami ważności (overlap), aby uniknąć przerw w działaniu w przypadku opóźnień w publikacji. Preferowane jest używanie kluczy prywatnych chronionych przez HSM na wystawiających urzędach certyfikacji, aby zmniejszyć ryzyko eksfiltracji kluczy. Należy skonfigurować ograniczenia oparte na rejestrze lub zasadach (policy-based) dla szablonów i procesu wystawiania certyfikatów, aby wymusić zasadę najmniejszych uprawnień.

Weryfikacja odwołania certyfikatów musi być szybka i niezawodna. Usługa Online Responder (OCSP) zmniejsza opóźnienia po stronie klienta, odpowiadając na zapytania o status pojedynczych certyfikatów, zamiast wymagać pobierania pełnych list CRL. Należy zainstalować usługę roli Online Responder, zarejestrować respondery w celu uzyskania certyfikatu OCSP Response Signing za pomocą dedykowanego szablonu v3 oraz skonfigurować Revocation Configuration, która wskazuje na wystawiający urząd certyfikacji i jego listy CRL, używając dostawcy Microsoft CRL-based Revocation Provider. Należy upewnić się, że urząd certyfikacji umieszcza adres URL usługi OCSP w rozszerzeniu Authority Information Access, aby klienci wiedzieli, gdzie kierować zapytania.

W celu zapewnienia skalowalności i odporności należy wdrożyć farmę OCSP (OCSP array). Należy wyznaczyć kontroler farmy (array controller) do replikowania konfiguracji odwołań do responderów będących jej członkami. Należy równoważyć obciążenie farmy za pomocą Windows NLB lub zewnętrznego load balancera z sondą kondycji (health probe), która potwierdza responsywność OCSP i aktualność certyfikatów podpisujących. Należy stosować krótkie okresy ważności dla certyfikatów podpisujących OCSP i skonfigurować automatyczne odnawianie (autoenrollment), aby zminimalizować ekspozycję na ryzyko. Należy monitorować aktualność list CRL i czas życia pamięci podręcznej OCSP, aby zapobiegać nieaktualnym odpowiedziom.

Szablony, automatyczna rejestracja, archiwizacja kluczy i Credential Roaming

Szablony certyfikatów określają ograniczenia żądań, nazwę podmiotu (subject name), zastosowania kluczy (key usages) i wymagania dotyczące wystawiania. Szablony w wersji 2 (wprowadzone w Windows Server 2003 Enterprise) pozwalają na dostosowywanie i obsługują automatyczną rejestrację (autoenrollment) z kluczami opartymi na CSP. Szablony w wersji 3 (Windows Server 2008 i nowsze) dodają obsługę CNG, ECC i algorytmów Suite B. Wybierz v3, gdy potrzebujesz CNG/ECC; wybierz v2 dla maksymalnej kompatybilności ze starszymi systemami. Powiąż szablony z jednym zestawem wystawiających urzędów certyfikacji, aby ograniczyć promień rażenia (blast radius) w razie incydentu.

Automatyczna rejestracja (autoenrollment) przekształca cykl życia certyfikatu w proces sterowany zasadami. Skonfiguruj zasady grupy (Group Policy) w ścieżce Computer Configuration lub User Configuration, Windows Settings, Security Settings, Public Key Policies, Certificate Services Client – Auto-Enrollment. Włącz ją, zaznaczając opcje Renew expired certificates, Update certificates that use certificate templates oraz Remove revoked/expired certificates. Automatyczna rejestracja wymaga odpowiednich uprawnień do szablonu: podmioty zabezpieczeń (principals) muszą mieć uprawnienia Read i Autoenroll; uprawnienie Enroll wystarcza tylko do rejestracji ręcznej. Ogranicz zasięg do grup zabezpieczeń, aby uniknąć nieoczekiwanego wystawiania certyfikatów i kontrolować ich liczbę.

Archiwizacja kluczy chroni dane w przypadku utraty klucza prywatnego. Włącz opcję Archive the subject’s encryption private key w szablonie dla certyfikatów przeznaczonych wyłącznie do szyfrowania (np. EFS, S/MIME). Wyznacz agentów odzyskiwania kluczy (Key Recovery Agents, KRA), wystawiając im certyfikaty KRA z szablonu Key Recovery Agent, i skonfiguruj urząd certyfikacji do archiwizowania kluczy. Odzyskiwanie jest ograniczone do typów kluczy, które można archiwizować; tradycyjnie obsługiwany jest RSA Key Exchange (starszy CSP), podczas gdy archiwizacja kluczy prywatnych CNG/ECC nie jest wspierana przez mechanizm archiwizacji kluczy w AD CS. Nie włączaj archiwizacji dla szablonów przeznaczonych wyłącznie do podpisywania.

Funkcja Credential Roaming synchronizuje certyfikaty użytkownika, klucze prywatne i klucze główne DPAPI między urządzeniami przyłączonymi do domeny, przechowując je w AD. Włącz ją za pomocą zasad grupy (Group Policy) w ścieżce User Configuration, Administrative Templates, System, Credential Roaming i ogranicz jej zasięg do zaufanych użytkowników. Poprawia to doświadczenie użytkownika w przypadku certyfikatów EFS, S/MIME i uwierzytelniania klienta na wielu maszynach bez konieczności używania profili mobilnych (roaming profiles). Zweryfikuj obsługę przez schemat katalogu i zaplanuj interakcję z Windows Hello for Business oraz menedżerami poświadczeń innych firm, aby uniknąć konfliktów lub duplikacji.

Cykl życia TLS/SSL i integracja z Azure Key Vault

Nowoczesny TLS zależy od poprawnej semantyki certyfikatów. Zawsze dołączaj EKU Server Authentication i preferuj podpisy SHA-256 lub silniejsze z co najmniej 2048-bitowym kluczem RSA lub odpowiednimi krzywymi eliptycznymi (ECC). Pole Subject Alternative Name (SAN) musi zawierać każdą nazwę hosta używaną przez klientów; przestarzałe pole Subject CN jest niewystarczające dla nowoczesnych klientów. Certyfikaty typu wildcard (*.contoso.com) upraszczają wdrożenia na wielu hostach w jednej strefie DNS, ale nie obejmują nazw wielopoziomowych (app.dev.contoso.com) ani różnych stref; należy dokładnie ocenić koncentrację ryzyka, gdy klucze prywatne certyfikatów wildcard są szeroko wdrażane. W przypadku potrzeby obsługi wielu stref, preferuj certyfikaty SAN lub wiele dedykowanych certyfikatów.

Standaryzuj żądania CSR za pomocą certreq lub IIS, utrzymuj zasady przechowywania kluczy (key custody) i automatyzuj odnawianie na długo przed datą NotAfter, aby umożliwić etapowe wdrożenia (staged rollouts) oraz propagację OCSP/CRL. Na serwerach WWW przyłączonych do domeny, automatyczna rejestracja (autoenrollment) z szablonem Web Server v3 może zautomatyzować wydawanie i odnawianie; użyj opcji dostarczania nazwy podmiotu w żądaniu (subject name supply in the request) z odpowiednimi zatwierdzeniami. Stosuj konfiguracje serwera obsługujące wyłącznie TLS 1.2/1.3, włącz pakiety szyfrów ECDHE dla zapewnienia poufności przekazywania (forward secrecy) i usuń przestarzałe szyfry SHA-1 oraz szyfry klasy eksportowej (export-grade).

Azure Key Vault rozszerza cykl życia certyfikatów na chmurę. Możesz importować istniejące certyfikaty PFX/PEM, generować nowe za pomocą urzędu certyfikacji zintegrowanego z Key Vault (na przykład DigiCert), używając polityki certyfikatów, i ustawić automatyczną rotację (auto-rotation), aby Key Vault żądał odnowienia i utrzymywał najnowszą wersję. Obiekt certyfikatu opakowuje klucz i sekret Key Vault, umożliwiając przepływy pracy z eksportowalnymi plikami PFX lub nieeksportowalnymi kluczami chronionymi przez HSM, w zależności od polityki. Aplikacje i usługi pobierają aktualne wersje za pomocą RBAC lub polityk dostępu oraz tożsamości zarządzanych (managed identities). Referencje Key Vault pozwalają usługom takim jak Azure App Service i Azure Functions pobierać certyfikaty i sekrety przez odwołanie, bez umieszczania ich w konfiguracji. Dla obciążeń Windows Server w Azure lub środowiskach hybrydowych, użyj rozszerzenia Azure Key Vault VM lub niestandardowej automatyzacji z tożsamościami zarządzanymi, aby pobierać i instalować zaktualizowane certyfikaty w magazynie certyfikatów systemu Windows oraz wyzwalać restarty usług, zapewniając bezdotykowe odnawianie (zero-touch renewals) na serwerach WWW, odwrotnych proxy i bramach aplikacyjnych.

Praktyczny scenariusz problemu

Firma Adobe Inc. musi ustandaryzować szyfrowanie i PKI w dwóch lokalnych centrach danych oraz dla obciążeń Windows Server hostowanych w Azure. Wymagają nienadzorowanych restartów serwerów w centrach danych, automatycznego odnawiania certyfikatów WWW, odzyskiwania szyfrowania na poziomie plików oraz minimalnych utrudnień dla użytkowników.

1. Zbuduj dwuwarstwową infrastrukturę PKI z urzędem certyfikacji root w trybie offline i dwoma urzędami wydającymi w trybie online

• Dlaczego: Urząd certyfikacji root w trybie offline tworzy kotwicę zaufania o wysokim poziomie pewności, podczas gdy urzędy wydające o krótkim okresie życia ograniczają ryzyko i wspierają wysoką dostępność. Hierarchia umożliwia rozdzielenie obowiązków, skalowalne definiowanie zakresu szablonów oraz bezpieczną publikację list CRL/AIA.

2. Wdróż farmę responderów online OCSP za load balancerem

• Dlaczego: OCSP dostarcza odpowiedzi o unieważnieniu z niskim opóźnieniem dla serwerów WWW i aplikacji na dużą skalę. Farma z równoważeniem obciążenia i sprawdzaniem stanu (health-checked) zapobiega pojedynczym punktom awarii i zapewnia, że klienci otrzymują aktualny status bez konieczności pobierania dużych list CRL.

3. Utwórz szablony certyfikatów v3 dla Web Server, OCSP Response Signing i Computer Authentication; szablony v2 dla EFS i S/MIME z archiwizacją kluczy

• Dlaczego: Wersja v3 umożliwia użycie CNG/ECC dla nowoczesnego TLS i podpisywania odpowiedzi respondera; wersja v2 maksymalizuje kompatybilność klientów dla EFS/S/MIME i wspiera archiwizację kluczy szyfrujących. Definiowanie zakresu szablonów wymusza wydawanie certyfikatów zgodnie z zasadą najmniejszych uprawnień.

4. Włącz automatyczną rejestrację (autoenrollment) przez Group Policy i przypisz uprawnienia Read/Autoenroll na szablonach do dedykowanych grup bezpieczeństwa

• Dlaczego: Automatyczna rejestracja eliminuje kroki ręczne, obsługuje odnawianie przed wygaśnięciem i czyści unieważnione/wygasłe certyfikaty. Ograniczenie do grup bezpieczeństwa zapobiega nadmiernemu wydawaniu certyfikatów i jest zgodne z zasadą najmniejszych uprawnień.

5. Zaimplementuj BitLocker na wszystkich serwerach z TPM+PIN dla woluminów systemowych; przechowuj klucze odzyskiwania w AD DS

• Dlaczego: TPM+PIN zwiększa odporność na ataki offline; przechowywanie w AD DS gwarantuje możliwość odzyskania. Serwery spełniają cele dostępności (uptime), zapewniając jednocześnie audytowalność przechowywania kluczy na poziomie wymaganym przez zgodność z przepisami.

6. Skonfiguruj Network Unlock używając WDS z funkcją Network Unlock w podsieciach centrum danych

• Dlaczego: Umożliwia to nienadzorowane restarty po instalacji poprawek bez dostępu do lokalnej konsoli, zachowując jednocześnie mechanizmy bezpieczeństwa TPM+PIN poza centrum danych. Wymaganiami technicznymi są UEFI+TPM i przewodowe połączenie DHCP.

7. Zarządzaj stanem BitLocker za pomocą Configuration Manager BitLocker Management i raportowania

• Dlaczego: Configuration Manager zapewnia dojrzałe wsparcie dla serwerów, pulpity nawigacyjne zgodności oraz przepływy pracy samoobsługi/odzyskiwania, redukując obciążenie operacyjne w mieszanym środowisku lokalnym i Azure.

8. Wydawaj certyfikaty EFS z AD CS i konfiguruj agentów odzyskiwania danych (DRA) przez GPO; wymagaj od użytkowników tworzenia kopii zapasowych certyfikatów EFS

• Dlaczego: Centralne wydawanie w połączeniu z DRA gwarantuje ciągłość biznesową dla szyfrowania na poziomie plików. Klucze DRA są ściśle kontrolowane, aby zapobiec nadużyciom, przy jednoczesnym zachowaniu opcji odzyskiwania.

9. Scentralizuj certyfikaty TLS dla obciążeń dostępnych z internetu w Azure Key Vault z integracją z zarządzanym CA i automatyczną rotacją; dystrybuuj je do serwerów Windows Server za pomocą automatyzacji opartej na tożsamościach zarządzanych

• Dlaczego: Key Vault odciąża proces odnawiania, centralizuje sekrety, wspiera wersjonowanie i umożliwia bezpieczne, zautomatyzowane wdrażanie na serwerach. Automatyczna rotacja eliminuje problem wygasania certyfikatów i jest zgodna z koncepcją operacji bezdotykowych (zero-touch).

10. Włącz Credential Roaming dla określonej grupy użytkowników, którzy potrzebują EFS i S/MIME na wielu urządzeniach

• Dlaczego: Credential Roaming synchronizuje certyfikaty i klucze DPAPI, zapewniając, że użytkownicy mogą odszyfrowywać i podpisywać dane na różnych stacjach roboczych bez ręcznego eksportu/importu, co poprawia produktywność i zmniejsza liczbę zgłoszeń do pomocy technicznej.

← Azure Arc i zarządzanie serwerami hybrydowymi · Wszystkie domeny · Aktualizacje Windows Server i zarządzanie poprawkami →

Przećwicz te pytania → · Testy na czas na ExamRoll.io →

Przeglądaj Microsoft →