Wyzwanie i wymagania
Typowy scenariusz: telefony służbowe poza jakąkolwiek kontrolą — firmowe Wi-Fi na wspólnym kluczu PSK, VPN na kontach z hasłami, brak możliwości zdalnego czyszczenia urządzenia po zgubieniu. Do tego chęć oparcia nowej infrastruktury o Azure zamiast rozbudowy lokalnej serwerowni.
Kluczowe wymagania:
- Uwierzytelnianie certyfikatowe Wi-Fi 802.1X (EAP-TLS), VPN i poczty — zamiast haseł i wspólnych kluczy
- Automatyczne wystawianie i odnawianie certyfikatów na urządzeniach mobilnych
- Pełne zarządzanie mobilne — rejestracja urządzeń, polityki zgodności, zdalny wipe
- Katalog i PKI w Azure — z zachowaniem bezpiecznej łączności z lokalnym środowiskiem
Istotna decyzja projektowa: zarządzana domena Microsoft Entra Domain Services nie obsługuje ról AD CS ani NDES — dlatego wybieramy klasyczne ADDS uruchomione na maszynach wirtualnych Azure (IaaS), które daje pełną kontrolę nad PKI i usługami certyfikatów.
Architektura i wdrożenie
Fundament — sieć i ADDS w Azure
Infrastrukturę startuje się od sieci: wirtualna sieć (vNet) z podsieciami dla kontrolerów domeny, PKI/NDES i serwerów aplikacyjnych, grupy NSG per podsieć (wyłącznie wymagane porty AD: DNS, Kerberos, LDAP, RPC) oraz łączność hybrydowa (VPN site-to-site lub ExpressRoute) do LAN-u organizacji. Następnie dwa kontrolery domeny Windows Server na VM, rozmieszczone w różnych strefach dostępności, z systemem DNS i Azure Backup dla maszyn. Katalog jest fundamentem dla usług certyfikatów — to na nim opiera się PKI.
PKI — AD CS w architekturze dwupoziomowej
Wdrożenie opiera się o rolę Active Directory Certificate Services w architekturze hierarchicznej: offline root CA (nigdy niedostępna z sieci, wystawia wyłącznie certyfikat pośredni) oraz issuing CA w Azure, która faktycznie wydaje certyfikaty. Kluczowy szczegół w scenariuszu mobilnym: punkty CRL/AIA są publikowane pod publicznie dostępnym adresem (np. Azure Storage), żeby urządzenia poza biurem potrafiły zweryfikować ważność certyfikatu. Dla NDES przygotowywane są dedykowane szablony wydawania (w tym szablon agenta rejestracji i szablon SCEP).
NDES + łącznik Microsoft Intune
Usługa NDES (Network Device Enrollment Service) pracuje na osobnym serwerze Windows Server z zainstalowanym łącznikiem certyfikatów Microsoft Intune. Przepływ wygląda tak: Intune wysyła profil SCEP do urządzenia → urządzenie generuje parę kluczy i żądanie CSR z hasłem challenge wydanym przez Intune → NDES weryfikuje żądanie w usłuve Intune → CA wystawia certyfikat → certyfikat trafia na urządzenie. Warunek wstępny: przed profilem SCEP na urządzenia musi trafić profil zaufanego certyfikatu głównego (root CA) — Intune pilnuje tej zależności.
Intune — zarządzanie i profile certyfikatów
Urządzenia rejestrowane są w Intune (Android Enterprise, iOS/iPadOS, Windows), z politykami zgodności i dostępem warunkowym opartym o Entra ID — do zasobów logują się wyłącznie zgodne urządzenia. Rozdzielane profile:
- Trusted certificate — certyfikat główny PKI
- SCEP — unikalny certyfikat per użytkownik/urządzenie, z automatycznym odnawianiem
- Wi-Fi 802.1X — uwierzytelnianie EAP-TLS certyfikatem z profilu SCEP
- VPN — certyfikatowa autoryzacja maszyny/użytkownika
- E-mail / S/MIME — szyfrowanie i podpis korespondencji
INTUNE (chmura) AZURE (IaaS) URZĄDZENIE MOBILNE
profil trusted cert → Root CA (offline) Android Enterprise
profil SCEP (challenge)→ Issuing CA (AD CS) iOS / iPadOS
↕ NDES + łącznik Intune Windows
compliance + CA (Entra) → CSR → weryfikacja → wystawienie Wi-Fi 802.1X · VPN · S/MIME
Mierzalne rezultaty
Uruchomiona infrastruktura skaluje się wraz z organizacją: dopisanie kolejnego profilu Wi-Fi lub sieci VPN to operacja konfiguracyjna, a nie projekt. Architektura PKI pozostaje otwarta na kolejne zastosowania — uwierzytelnianie w sieci przewodowej 802.1X, podpisy elektroniczne, szyfrowanie dysków — a tożsamość w Azure pozwala konsekwentnie wdrażać model Zero Trust: nigdy nie ufaj, zawsze weryfikuj.
Źródła
- Microsoft Learn — Use SCEP certificate profiles with Microsoft Intune
- Microsoft Learn — Active Directory Certificate Services overview
- Microsoft — Microsoft Entra Domain Services