Microsoft Entra ID (dawniej Azure Active Directory) jest centrum tożsamości dla większości organizacji korzystających z Microsoft 365, Azure i aplikacji SaaS. Badania Microsoft Digital Threat Intelligence (2025) pokazują, że 93% incydentów w chmurze wiąże się z przejęciem tożsamości. Domyślna konfiguracja Entra ID nie jest zahardowana — wymaga świadomych decyzji i wdrożenia licznych zabezpieczeń, aby stać się odporną na ataki bramą do zasobów firmy.
Dlaczego Entra ID jest celem numer jeden
Entra ID jest atrakcyjnym celem dla atakujących z kilku powodów. Po pierwsze, kontroluje dostęp do praktycznie wszystkich zasobów organizacji korzystającej z ekosystemu Microsoft — poczty Exchange, Teams, SharePoint, aplikacji line-of-business, zasobów Azure i zewnętrznych aplikacji SaaS przez protokół SAML/OIDC. Przejęcie konta administratora globalnego oznacza pełną kontrolę nad całym środowiskiem chmurowym.
Po drugie, domyślna konfiguracja Entra ID pozostawia aktywne starsze protokoły uwierzytelniania: SMTP AUTH, POP3, IMAP, podstawowe uwierzytelnianie HTTP. Protokoły te nie obsługują uwierzytelniania wieloskładnikowego — nawet jeśli włączyłeś MFA dla użytkownika, atakujący może obejść MFA, używając właśnie tych protokołów z wykradzionymi hasłami. To najczęstszy wektor ataku na konta Microsoft 365 w 2025 roku.
Po trzecie, wiele organizacji wciąż korzysta z domyślnych ustawień zabezpieczeń Entra ID (Security Defaults) lub ma włączone MFA per użytkownik — mechanizm starszy i mniej elastyczny niż zasady dostępu warunkowego (Conditional Access). Security Defaults to dobry punkt wyjścia dla małych firm, ale dla organizacji ze środowiskami enterprise są zdecydowanie niewystarczające. Brak zaawansowanych zasad Conditional Access oznacza, że uwierzytelnianie nie uwzględnia ryzyka, lokalizacji, stanu urządzenia ani wrażliwości aplikacji.
Fundamenty hardeningu Entra ID
Pierwszym i najważniejszym krokiem jest wymuszenie MFA dla wszystkich użytkowników — nie tylko administratorów. Prawidłowym mechanizmem są zasady dostępu warunkowego (Conditional Access), nie starszy mechanizm MFA per użytkownik. Conditional Access pozwala na granularną kontrolę: MFA wymagane zawsze dla aplikacji wrażliwych, MFA wymagane przy logowaniu z urządzeń niezarządzanych, obniżony wymóg dla urządzeń zgodnych z polityką z sieci firmowej.
Blokada starszych protokołów uwierzytelniania to jeden z najważniejszych kroków hardeningu, który można wykonać w ciągu godziny. W zasadach Conditional Access utwórz regułę blokującą wszystkich klientów korzystających ze starszego uwierzytelniania (Legacy Authentication clients). Przed wdrożeniem sprawdź w dziennikach logowania, czy żadne aplikacje produkcyjne nie korzystają z tych protokołów — jeśli tak, zaadresuj to najpierw.
Zasady dostępu warunkowego powinny uwzględniać nazwane lokalizacje (named locations): adresy IP sieci firmowych i partnerskich traktowane jako zaufane, wszystkie pozostałe jako niezaufane. Dostęp z niezaufanych lokalizacji powinien wymagać MFA i/lub urządzenia zgodnego z polityką. Wymóg urządzenia zgodnego (compliant device) zapewnia, że dostęp mają tylko urządzenia zarejestrowane w Intune i spełniające politykę zgodności — np. zaszyfrowane, aktualizowane, z aktywnym EDR.
Warto też wdrożyć zasadę Conditional Access wymuszającą rejestrację MFA wyłącznie z zaufanej lokalizacji lub urządzenia. Bez tej zasady atakujący, który zdobył hasło nowego pracownika, może samodzielnie zarejestrować swój numer telefonu jako metodę MFA przed właściwym użytkownikiem.
Privileged Identity Management (PIM)
Privileged Identity Management to jedna z najważniejszych funkcji Entra ID P2, która eliminuje jedną z największych słabości konfiguracji środowisk chmurowych: stałe przypisania ról uprzywilejowanych. W większości organizacji bez PIM konta z rolą Administratora Globalnego lub Administratora Exchange mają te uprawnienia przypisane na stałe — 24 godziny na dobę, 7 dni w tygodniu, nawet gdy nikt z nich aktywnie nie korzysta.
PIM zastępuje stałe przypisania rolami kwalifikowalnymi (eligible assignments): użytkownik ma prawo do aktywacji danej roli, ale nie posiada jej na co dzień. Aktywacja roli wymaga uzasadnienia (justification), może wymagać zatwierdzenia przez inną osobę (approval workflow) i jest ograniczona czasowo (np. do 8 godzin). Każda aktywacja jest logowana i może być alertowana do SOC.
Kluczowe praktyki PIM to: wymaganie uzasadnienia i zatwierdzenia dla aktywacji roli Administratora Globalnego, kwartalny przegląd dostępu (access review) dla wszystkich posiadaczy ról uprzywilejowanych z automatycznym cofaniem dostępu dla nieaktywnych kont, oraz stosowanie oddzielnych kont tylko w chmurze (cloud-only accounts) dla administratorów — niepowiązanych z kontami synchronizowanymi z lokalnego Active Directory. Synchronizowane konta administracyjne stanowią wektor ataku: skompromitowanie lokalnego AD daje dostęp do kont chmurowych.
PIM powinien być skonfigurowany dla wszystkich ról uprzywilejowanych, nie tylko Administratora Globalnego: Administrator Exchange, Administrator SharePoint, Administrator Bezpieczeństwa, Administrator Dostępu Warunkowego. Każda z tych ról daje znaczące możliwości atakującemu i powinna podlegać kontroli just-in-time.
Ochrona kont globalnego administratora
Konta Administratora Globalnego wymagają szczególnej ochrony ze względu na ich absolutne uprawnienia w środowisku Entra ID. Rekomendowana liczba kont Administratora Globalnego to minimum 2 (aby uniknąć pojedynczego punktu awarii) i maksimum 5 — każde dodatkowe konto to dodatkowa powierzchnia ataku.
Konta awaryjne (break-glass accounts) to specjalne konta Administratora Globalnego używane wyłącznie w sytuacjach kryzysowych — np. gdy standardowe konta administratorów są niedostępne z powodu awarii mechanizmu MFA. Hasła do tych kont powinny być przechowywane offline (wydrukowane, przechowywane w sejfie), a samo konto nie powinno podlegać żadnym zasadom Conditional Access ani PIM, które mogłyby uniemożliwić dostęp awaryjny. Logowania na te konta powinny generować krytyczny alert w SIEM.
Stacje robocze uprzywilejowanego dostępu (PAW — Privileged Access Workstations) to dedykowane, zahardowane urządzenia używane wyłącznie do czynności administracyjnych. Nie należy używać tych samych urządzeń do codziennej pracy, przeglądania internetu i administrowania środowiskiem. Dla operacji administracyjnych Entra ID zalecane jest oddzielne urządzenie lub co najmniej oddzielny profil przeglądarki z rygorystyczną izolacją.
MFA odporne na phishing jest obowiązkowe dla wszystkich kont administracyjnych. Standardowe MFA oparte na SMS lub aplikacji mobilnej jest podatne na ataki MFA fatigue (bombardowanie zatwierdzeniami) i adversary-in-the-middle (AiTM). Dla kont administratorów należy wymagać wyłącznie kluczy bezpieczeństwa FIDO2 lub Windows Hello for Business — metod odpornych na phishing.
Monitoring i detekcja zagrożeń
Entra ID Protection to wbudowana usługa oceny ryzyka, która wykrywa podejrzane wzorce logowania i działania użytkowników. Należy skonfigurować dwie kluczowe zasady: zasadę ryzyka logowania (blokuj lub wymagaj MFA, gdy ryzyko logowania wynosi Wysoki lub Średni) oraz zasadę ryzyka użytkownika (wymagaj zmiany hasła, gdy ryzyko użytkownika jest Wysokie). Te zasady automatycznie reagują na wykryte anomalie bez potrzeby ręcznej interwencji analityka.
Ustawienia diagnostyczne Entra ID (Diagnostic Settings) powinny kierować dzienniki inspekcji (audit logs) i dzienniki logowania (sign-in logs) do Log Analytics Workspace lub bezpośrednio do firmowego SIEM. Bez tego wszystkie zdarzenia bezpieczeństwa są niedostępne po upływie domyślnego okresu przechowywania (30 dni dla P1, 90 dni dla P2).
Kluczowe alerty do skonfigurowania to: aktywacja roli Administratora Globalnego (każde zdarzenie wymaga weryfikacji), niemożliwa podróż (impossible travel — logowanie z dwóch odległych lokalizacji w krótkim czasie), próby użycia starszych protokołów uwierzytelniania, masowe zmiany uprawnień i logowania z nowych krajów lub anonimowych adresów IP.
Microsoft Secure Score to wskaźnik dostępny w Microsoft Defender portal, który mierzy dojrzałość konfiguracji bezpieczeństwa Entra ID i Microsoft 365. Każda rekomendacja jest opisana, ponumerowana i ma przypisaną wartość punktową. Ustal kwartalny cel poprawy Secure Score i przypisz jego wzrost konkretnemu właścicielowi w zespole IT. Regularny przegląd Secure Score to prosty mechanizm utrzymywania ciągłości hardeningu.
Jak ExColo może pomóc
Hardening Entra ID wymaga zarówno wiedzy technicznej, jak i doświadczenia operacyjnego — błędna konfiguracja zasad Conditional Access może zablokować dostęp do krytycznych systemów. Zespół ExColo specjalizuje się w zabezpieczaniu tożsamości w środowiskach Microsoft 365 i Azure.
Oferujemy: ocenę aktualnej konfiguracji Entra ID (Entra ID Security Review), wdrożenie zasad Conditional Access dostosowanych do środowiska klienta, konfigurację PIM dla ról uprzywilejowanych, wdrożenie Entra ID Protection i integrację logów z SIEM, a także opracowanie procedur zarządzania kontami awaryjnymi i PAW. Każde wdrożenie poprzedzamy analizą istniejącego środowiska, aby uniknąć zakłócenia działania produkcyjnego.
Skontaktuj się z nami, aby zaplanować przegląd bezpieczeństwa Entra ID: formularz kontaktowy ExColo.
