Azure Active Directory i Zero Trust - wdrożenie zarządzania tożsamościami w chmurze

W tradycyjnym modelu bezpieczeństwa granicę stanowiła sieć - kto był w środku, miał dostęp. VPN, firewall, segmentacja VLAN. W chmurze ta granica nie istnieje. Użytkownicy logują się z domu, z kawiarnianego Wi-Fi, z telefonu w tramwaju. Aplikacje działają w wielu regionach, dane przepływają między subskrypcjami.

Zero Trust zastępuje pytanie “czy jesteś w naszej sieci?” pytaniem “czy masz dowód, że jesteś tym, za kogo się podajesz, i czy w tym momencie potrzebujesz tego dostępu?”. Microsoft Entra ID (dawniej Azure Active Directory) to narzędzie, które pozwala to pytanie zadawać przy każdym żądaniu.

Czym jest Microsoft Entra ID (Azure Active Directory)

Microsoft Entra ID to chmurowa usługa zarządzania tożsamościami i dostępem (Identity and Access Management). Do marca 2024 roku znana była jako Azure Active Directory (Azure AD). Zmiana nazwy nie zmieniła funkcjonalności - to ten sam produkt z nowym brandingiem w ramach rodziny Microsoft Entra.

Kluczowe możliwości:

• Uwierzytelnianie użytkowników - SSO do aplikacji SaaS, aplikacji wewnętrznych i zasobów Azure
• Conditional Access - polityki dostępu warunkowego bazujące na lokalizacji, urządzeniu, ryzyku
• Privileged Identity Management (PIM) - zarządzanie dostępem uprzywilejowanym just-in-time
• External Identities - współpraca B2B z partnerami bez tworzenia osobnych kont
• Workload Identities - tożsamości dla aplikacji, serwisów i pipeline CI/CD (managed identity, federated credentials)

Dla polskich organizacji istotne jest to, że Entra ID przechowuje dane tożsamości w regionie EU (datacenter w Holandii i Irlandii), co upraszcza zgodność z RODO/GDPR. Rezydencja danych katalogu mieści się w UE, jeśli tenant został utworzony z lokalizacją europejską.

Model Zero Trust - trzy zasady

Zero Trust to nie produkt do kupienia. To architektura bezpieczeństwa oparta na trzech zasadach:

1. Weryfikuj jawnie (Verify explicitly)

Każde żądanie dostępu musi być uwierzytelnione i autoryzowane na podstawie wszystkich dostępnych sygnałów:

• Tożsamość użytkownika (kto?)
• Lokalizacja i adres IP (skąd?)
• Stan urządzenia (czy spełnia politykę compliance?)
• Aplikacja docelowa (do czego?)
• Kontekst ryzyka (czy sesja wygląda normalnie?)

2. Stosuj zasadę minimalnych uprawnień (Least privilege access)

Użytkownik dostaje dokładnie tyle uprawnień, ile potrzebuje - nie więcej. Uprawnienia są:

• Ograniczone czasowo (just-in-time zamiast stałych ról)
• Ograniczone zakresem (konkretna subskrypcja, konkretny resource group)
• Regularnie weryfikowane (access reviews)

3. Zakładaj naruszenie (Assume breach)

Projektuj systemy tak, jakby atakujący już był w środku. To oznacza:

• Mikrosegmentację (nie ufaj ruchowi sieciowemu nawet wewnątrz VNet)
• Szyfrowanie end-to-end
• Ciągłe monitorowanie i automatyczną reakcję na anomalie

Wdrożenie Zero Trust na Entra ID - plan krok po kroku

Krok 1: Audyt obecnego stanu tożsamości

Zanim cokolwiek wdrożysz, musisz wiedzieć, od czego zaczynasz.

Co sprawdzić:

• Ile kont ma rolę Global Administrator? (powinno być max 2-3, nigdy więcej niż 5)
• Ile kont serwisowych używa haseł zamiast managed identity?
• Czy MFA jest wymuszone dla wszystkich użytkowników, czy tylko dla adminów?
• Ile starych kont gości (B2B) wciąż ma aktywny dostęp?
• Czy istnieją konta z hasłami niewygasającymi (password never expires)?

Narzędzia:

• Microsoft Entra admin center → Identity Governance → Access Reviews
• Microsoft Secure Score (dashboard w portalu Microsoft 365)
• az ad user list --filter "accountEnabled eq true" w Azure CLI

Dla wielu polskich firm, które migrowały do Azure w latach 2020-2022 podczas pandemii, audyt ujawnia dziesiątki kont o zbyt szerokich uprawnieniach. To normalny stan wyjściowy - ważne jest, żeby go poprawić.

Krok 2: Wymuszenie MFA dla wszystkich użytkowników

Wieloskładnikowe uwierzytelnianie (MFA) to absolutne minimum Zero Trust. Bez MFA nie ma sensu wdrażać kolejnych warstw, bo jedno skradzione hasło otwiera drzwi.

Zalecana konfiguracja:

Ważne: Od 2024 roku Microsoft wymusza MFA dla wszystkich ról administracyjnych w Entra ID (tzw. security defaults v2). Jeśli jeszcze tego nie skonfigurowałeś świadomie - prawdopodobnie działa to w trybie domyślnym, ale bez pełnej kontroli nad wyjątkami.

Krok 3: Conditional Access - serce Zero Trust

Conditional Access to silnik decyzyjny, który przy każdym logowaniu ocenia sygnały i podejmuje decyzję: zezwól, wymuś dodatkową weryfikację, lub zablokuj.

Zalecane polityki startowe (minimum viable Zero Trust):

1. Wymagaj MFA dla wszystkich użytkowników, wszystkich aplikacji - polityka bazowa
2. Blokuj legacy authentication - protokoły IMAP, POP3, SMTP Basic Auth nie obsługują MFA. Wyłącz je.
3. Wymagaj compliant device dla dostępu do danych wrażliwych - urządzenie musi być zarejestrowane w Intune i spełniać politykę (szyfrowanie dysku, aktualny OS, antywirus)
4. Blokuj logowanie z krajów, w których firma nie operuje - jeśli działasz w Polsce i UE, zablokuj logowania z Rosji, Chin, Nigerii (najczęstsze źródła ataków brute-force)
5. Wymagaj ponownego uwierzytelnienia dla operacji wrażliwych - zmiana ról, reset hasła, dostęp do Azure Portal

{
  "displayName": "Require MFA for all users - all cloud apps",
  "state": "enabled",
  "conditions": {
    "users": { "includeUsers": ["All"] },
    "applications": { "includeApplications": ["All"] },
    "clientAppTypes": ["browser", "mobileAppsAndDesktopClients"]
  },
  "grantControls": {
    "operator": "OR",
    "builtInControls": ["mfa"]
  }
}

Porządek ewaluacji: Polityki Conditional Access ewaluowane są równolegle (nie sekwencyjnie). Jeśli jakiekolwiek dwie polityki powodują konflikt - wygrywa bardziej restrykcyjna. To oznacza, że jedna polityka “Block” nadpisuje dziesięć polityk “Allow”.

Krok 4: Privileged Identity Management (PIM)

PIM eliminuje stałe role administracyjne. Zamiast dawać komuś rolę “Owner” na subskrypcję na stałe, dajesz mu uprawnienie eligible - może je aktywować na żądanie, na określony czas, po dodatkowej weryfikacji.

Jak to działa w praktyce:

1. Inżynier DevOps potrzebuje roli Contributor na resource group produkcyjny
2. Loguje się do portalu Entra → Privileged Identity Management → My Roles
3. Klika “Activate” przy roli Contributor
4. Podaje uzasadnienie (ticket Jira, opis problemu)
5. Przechodzi dodatkowe MFA
6. Rola aktywuje się na 4 godziny (konfigurowalny czas)
7. Po 4 godzinach - automatyczna deaktywacja

Rekomendowana konfiguracja PIM dla polskich organizacji:

PIM wymaga licencji Microsoft Entra ID P2 (lub Microsoft Entra ID Governance). Koszt: ~$9/użytkownika/miesiąc. Dla organizacji 50-200 osób to $450-$1800/miesiąc - niewielka kwota w porównaniu z kosztem incydentu bezpieczeństwa.

Krok 5: Workload Identity - tożsamości dla aplikacji i pipeline

Ludzie to nie jedyne tożsamości w organizacji. Aplikacje, pipeline CI/CD, skrypty automatyzacji - wszystkie potrzebują dostępu do zasobów Azure. Zero Trust wymaga, żeby te tożsamości też były zarządzane.

Hierarchia preferencji (od najbezpieczniejszej):

1. Managed Identity (system-assigned) - Azure tworzy i zarządza tożsamością automatycznie. Nie ma hasła, nie ma certyfikatu do rotacji. Najlepsza opcja dla zasobów działających w Azure (App Service, AKS pods, Azure Functions).

2. Managed Identity (user-assigned) - jak wyżej, ale współdzielona między zasobami. Używaj, gdy wiele zasobów potrzebuje tego samego dostępu.

3. Workload Identity Federation (federated credentials) - dla zasobów spoza Azure (GitHub Actions, GitLab CI, AWS). Eliminuje statyczne sekrety dzięki OIDC. Pipeline wymienia swój token na token Entra ID bez przesyłania hasła.

4. Service Principal z certyfikatem - gdy federation nie jest możliwa. Certyfikat rotowany co 6-12 miesięcy.

5. Service Principal z hasłem (client secret) - ostateczność. Hasło w Key Vault, rotacja co 90 dni. Unikaj, jeśli to możliwe.

Dla pipeline CI/CD na GitHub Actions, workload identity federation to standard, który opisaliśmy szczegółowo w runbooku konfiguracji AKS Workload Identity. Analogiczna konfiguracja działa dla każdego zasobu Azure.

Monitoring i reakcja na incydenty

Zero Trust bez monitoringu to fikcja. Musisz widzieć, co się dzieje, i reagować automatycznie.

Microsoft Entra ID Protection

Silnik ML, który analizuje logowania i przypisuje im poziom ryzyka:

• Low risk - logowanie z nowego urządzenia, ale znanej lokalizacji
• Medium risk - logowanie z innego kraju niż zwykle (impossible travel)
• High risk - logowanie z anonimowego IP, znane poświadczenia w wycieku (leaked credentials)

Integracja z Conditional Access: Możesz stworzyć politykę “jeśli ryzyko sesji = high → wymuś reset hasła i MFA”. Reakcja jest automatyczna - nie czekasz, aż SOC przeanalizuje alert ręcznie.

Audit Logs i Sign-in Logs

Entra ID generuje dwa rodzaje logów:

• Sign-in logs - każde logowanie (sukces i porażka), z informacją o IP, urządzeniu, aplikacji, wyniku Conditional Access
• Audit logs - każda zmiana konfiguracyjna (dodanie użytkownika, zmiana roli, modyfikacja polityki)

Rekomendacja: Eksportuj logi do Azure Log Analytics Workspace (retencja 90 dni w Entra, ale w Log Analytics - konfigurowalnie do 2 lat). Dla wymagań KNF lub UODO dotyczących przechowywania logów dostępu - 2 lata to bezpieczne minimum.

Alert rules (minimum)

Skonfiguruj alerty na:

• Aktywację roli Global Administrator
• Więcej niż 5 nieudanych logowań z jednego IP w ciągu 10 minut
• Logowanie z kraju spoza listy dozwolonych
• Dodanie nowej federacji do tenanta (krytyczne - atak na poziomie tenanta)
• Usunięcie polityki Conditional Access

Zgodność z polskimi regulacjami

RODO/GDPR

Entra ID z tenant w regionie EU przechowuje dane katalogu (imię, email, członkostwo w grupach) w europejskich datacenter. Dodatkowe dane diagnostyczne mogą przepływać do US - jeśli to problem, wyłącz telemetrię diagnostyczną lub skonfiguruj EU Data Boundary (dostępny od 2024).

KNF (sektor finansowy)

Komisja Nadzoru Finansowego wymaga:

• Silnego uwierzytelniania dla dostępu do systemów bankowych → MFA spełnia wymaganie
• Logowania i monitorowania dostępu do danych klientów → Sign-in logs + Audit logs
• Okresowych przeglądów uprawnień → Access Reviews w Entra ID Governance

NIS2

Dyrektywa NIS2 (transpozycja do prawa krajowego trwa - termin upłynął w październiku 2024, ale wiele elementów wciąż wymaga ustaw wykonawczych) wymaga od podmiotów kluczowych i ważnych:

• Zarządzania ryzykiem w łańcuchu dostaw IT → kontrola tożsamości partnerów B2B
• Mechanizmów uwierzytelniania i kontroli dostępu → Conditional Access + MFA
• Planu reagowania na incydenty → Entra ID Protection + automated response

Nawet jeśli pełne egzekwowanie jeszcze nie nastąpiło, wdrożenie tych mechanizmów teraz oznacza gotowość na moment, gdy przepisy zaczną być stosowane.

Koszt wdrożenia Zero Trust na Entra ID

Co dostajesz w każdym tier:

• Free/P1: SSO, MFA, Conditional Access (podstawowy), Application Proxy
• P2: + PIM (Privileged Identity Management), Identity Protection (risk-based CA), Access Reviews
• Governance: + Lifecycle Workflows, Entitlement Management, automatyzacja onboarding/offboarding

Dla polskiej organizacji 100 osób na planie M365 E3 (który zawiera P1):

• Conditional Access + MFA = $0 dodatkowych kosztów (już opłacone)
• Upgrade do P2 (PIM + Identity Protection) = ~$900/miesiąc ($9 × 100 użytkowników)

Koszt jednorazowego wdrożenia (konsulting + konfiguracja) dla organizacji 50-200 osób: typowo 3-5 dni pracy inżyniera.

Typowe błędy przy wdrożeniu

1. Brak break-glass accounts - jeśli jedyny Global Admin zapomni hasła lub zgubi klucz FIDO2, kto odblokuje tenanta? Zawsze utrzymuj 2 konta emergency access, wyłączone z Conditional Access, z mocnymi hasłami w sejfie fizycznym.

2. Zbyt agresywna polityka Conditional Access bez testów - włączenie “block all countries except PL” bez sprawdzenia, czy partner z Niemiec wciąż się zaloguje. Używaj trybu “Report-only” przez 2-4 tygodnie przed przełączeniem na “Enabled”.

3. Ignorowanie kont serwisowych - pipeline CI/CD z client secret, który nie był rotowany od 18 miesięcy. Konta serwisowe NIE powinny być wyłączone z MFA i Conditional Access - powinny używać managed identity.

4. Security defaults + Conditional Access jednocześnie - to się wzajemnie wyklucza. Jeśli tworzysz polityki Conditional Access, wyłącz security defaults. W przeciwnym razie zachowanie jest nieprzewidywalne.

5. Brak planu komunikacji - wdrożenie MFA bez poinformowania pracowników generuje falę ticketów i frustrację. Przygotuj instrukcję krok po kroku, sesję Q&A, i daj tydzień na rejestrację metod MFA przed wymuszeniem.

Jak możemy pomóc

W Devopsity wdrażamy Zero Trust na Entra ID dla polskich organizacji w sektorze finansowym, e-commerce i SaaS. Typowe zaangażowanie obejmuje:

• Audyt obecnego stanu tożsamości i uprawnień (1 dzień)
• Zaprojektowanie polityk Conditional Access i PIM (1-2 dni)
• Wdrożenie i testowanie w trybie report-only (1-2 dni)
• Przełączenie na tryb produkcyjny + szkolenie zespołu (1 dzień)

Jeśli Twoja firma jest na M365 E3 lub E5, ale Conditional Access wciąż działa w trybie domyślnym - prawdopodobnie przepłacasz za licencje, z których nie korzystasz w pełni.

Potrzebujesz audytu tożsamości w Azure?

Umów się na bezpłatną 30-minutową rozmowę. Bez sprzedaży - techniczna dyskusja o Twoim środowisku.

Umów rozmowę

Najczęściej zadawane pytania

Czy Azure Active Directory to to samo co Microsoft Entra ID?

Tak. Microsoft zmienił nazwę w 2023 roku (rebrand zakończony w 2024). Wszystkie funkcjonalności pozostały identyczne. Jeśli w Twojej dokumentacji wewnętrznej pojawia się “Azure AD” - to ten sam produkt, który teraz nazywa się Entra ID.

Czy Zero Trust wymaga wymiany całej infrastruktury?

Nie. Zero Trust to model iteracyjny. Zaczynasz od MFA i Conditional Access (tydzień pracy), potem dodajesz PIM (kolejny tydzień), potem workload identities (w miarę modernizacji aplikacji). Każdy krok daje natychmiastową poprawę bezpieczeństwa.

Ile kosztuje wdrożenie Zero Trust dla firmy 100 osób?

Jeśli masz M365 E3 - sam Conditional Access i MFA jest darmowy (już opłacony w licencji). Upgrade do P2 (PIM + Identity Protection) to ~$900/miesiąc. Koszt konsultingu wdrożeniowego: 3-5 dni pracy. Łączny koszt pierwszego roku: ~$12,000-15,000 (licencje + konsulting).

Czy Conditional Access działa dla aplikacji on-premise?

Tak, przez Application Proxy lub Azure AD Connect z Hybrid Azure AD Join. Aplikacje lokalne mogą korzystać z tych samych polityk Conditional Access co aplikacje chmurowe. Wymaga to konfiguracji konektora Application Proxy na serwerze w sieci lokalnej.

Jak długo trwa wdrożenie?

Minimum viable Zero Trust (MFA + basic Conditional Access) - 1-2 tygodnie. Pełne wdrożenie z PIM, Identity Protection i workload identities - 4-6 tygodni. Najbardziej czasochłonna jest migracja kont serwisowych z haseł na managed identity.