Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Microsoft rozwija podejście „secure by default”, czyli model, w którym podstawowe mechanizmy ochrony są aktywowane automatycznie już na starcie działania środowiska. W praktyce ma to ograniczyć ryzyko przejęcia kont, nadużyć tożsamości oraz skuteczność ataków wykorzystujących słabe lub niekompletne konfiguracje bezpieczeństwa.
Zmiany dotyczą przede wszystkim usług Microsoft Entra ID i Microsoft 365, gdzie domyślne ustawienia bezpieczeństwa odgrywają kluczową rolę w ochronie dostępu do zasobów chmurowych. To istotne zwłaszcza dla organizacji, które nie wdrożyły jeszcze dojrzałych polityk IAM i Zero Trust.
W skrócie
Microsoft rozszerza zakres automatycznie stosowanych zabezpieczeń dla nowych dzierżaw oraz wzmacnia wykorzystanie takich mechanizmów jak MFA, blokowanie starszych protokołów uwierzytelniania i zarządzane polityki Conditional Access. Celem jest ograniczenie skuteczności phishingu, password spray, credential stuffing oraz ataków ukierunkowanych na konta uprzywilejowane.
- większy nacisk na wieloskładnikowe uwierzytelnianie,
- ograniczanie legacy authentication,
- szersze wykorzystanie zarządzanych polityk dostępu warunkowego,
- automatyczne podnoszenie bazowego poziomu ochrony nowych tenantów.
Kontekst / historia
Security Defaults zostały wprowadzone jako uproszczony, prekonfigurowany zestaw zabezpieczeń dla środowisk Entra ID. Ich celem było zapewnienie minimalnego poziomu ochrony organizacjom, które nie korzystają z rozbudowanych polityk Conditional Access lub nie posiadają wyspecjalizowanych kompetencji w obszarze zarządzania tożsamością.
W ostatnich latach Microsoft konsekwentnie przesuwa odpowiedzialność za część bazowych decyzji konfiguracyjnych na poziom usług zarządzanych przez dostawcę. Kierunek ten został dodatkowo wzmocniony przez Secure Future Initiative, w ramach której firma zapowiedziała dalsze podnoszenie bezpieczeństwa usług chmurowych i ograniczanie powierzchni ataku związanej z tożsamością.
Nie jest to przypadek. Warstwa IAM pozostaje jednym z głównych punktów wejścia dla cyberprzestępców. Kradzież poświadczeń, przejmowanie sesji, phishing i nadużywanie kont o wysokich uprawnieniach to dziś jedne z najczęstszych scenariuszy kompromitacji środowisk chmurowych.
Analiza techniczna
Technicznie rozszerzanie domyślnych zabezpieczeń oznacza, że część kluczowych kontroli bezpieczeństwa jest włączana bez konieczności ręcznej aktywacji przez administratora. Takie podejście zmniejsza ryzyko błędów wdrożeniowych i skraca czas, w którym środowisko pozostaje narażone na podstawowe typy ataków.
Najważniejsze elementy tego modelu obejmują:
- wymuszanie rejestracji i stosowania MFA, szczególnie dla kont uprzywilejowanych,
- blokowanie starszych metod uwierzytelniania niewspierających nowoczesnych mechanizmów ochrony,
- stosowanie zarządzanych polityk Conditional Access dla nowych dzierżaw,
- ograniczanie wyjątków konfiguracyjnych osłabiających bezpieczeństwo,
- podnoszenie bazowego poziomu ochrony bez dodatkowych działań po stronie klienta.
Z punktu widzenia obrony szczególne znaczenie ma MFA. Samo wieloskładnikowe uwierzytelnianie nie eliminuje każdego scenariusza przejęcia konta, ale wyraźnie utrudnia ataki oparte wyłącznie na skradzionym haśle. Równie ważne jest blokowanie starszych protokołów, takich jak basic authentication, które historycznie były wykorzystywane w kampaniach brute force i password spray.
Warto jednocześnie odróżnić Security Defaults od pełnego Conditional Access. Security Defaults zapewniają prosty, bazowy zestaw ochronny. Conditional Access umożliwia natomiast bardziej granularne reguły oparte na ryzyku użytkownika, lokalizacji, stanie urządzenia, kontekście aplikacji czy poziomie uprzywilejowania. Domyślne zabezpieczenia nie zastępują więc dojrzałej architektury IAM, ale tworzą jej minimalny fundament.
Konsekwencje / ryzyko
Dla wielu organizacji zmiany oznaczają realne ograniczenie powierzchni ataku. Środowiska, które wcześniej nie wymuszały MFA albo nadal dopuszczały starsze metody logowania, mogą odczuć wyraźny wzrost odporności na najczęstsze próby kompromitacji kont.
Korzyści obejmują przede wszystkim:
- mniejszą skuteczność prostych kampanii phishingowych,
- utrudnienie ataków credential stuffing i password spray,
- lepszą ochronę kont administracyjnych,
- zmniejszenie ryzyka wynikającego z błędnych konfiguracji początkowych.
Jednocześnie automatyczne włączanie nowych zabezpieczeń może powodować skutki uboczne operacyjne. Problemem mogą być starsze aplikacje, skrypty i procesy automatyczne korzystające z przestarzałych mechanizmów logowania. Możliwy jest również wzrost liczby zgłoszeń do helpdesku w momencie wymuszenia MFA lub zmian w sposobie uwierzytelniania użytkowników.
- problemy z kompatybilnością starszych klientów i aplikacji,
- zakłócenia w procesach opartych na legacy auth,
- większe obciążenie zespołów wsparcia przy pierwszych zmianach,
- ryzyko błędnego założenia, że ustawienia domyślne rozwiązują cały problem bezpieczeństwa tożsamości.
Największym zagrożeniem pozostaje nadmierne zaufanie do bazowych ustawień. Domyślne mechanizmy nie rozwiązują wszystkich problemów, takich jak phishing odporny na klasyczne MFA, przejęcie tokenów sesyjnych, nadużycia aplikacji OAuth czy brak segmentacji dostępu uprzywilejowanego.
Rekomendacje
Organizacje korzystające z Microsoft 365 i Entra ID powinny potraktować te zmiany jako impuls do przeglądu całej architektury tożsamości. Najlepsze efekty daje połączenie ustawień domyślnych z dodatkowymi politykami bezpieczeństwa dopasowanymi do rzeczywistego poziomu ryzyka.
- sprawdzić, czy Security Defaults są aktywne i czy nie kolidują z istniejącym Conditional Access,
- zinwentaryzować aplikacje oraz usługi korzystające ze starszych protokołów uwierzytelniania,
- przygotować plan migracji do nowoczesnego uwierzytelniania,
- wdrożyć phishing-resistant MFA dla administratorów i kont uprzywilejowanych,
- ograniczyć liczbę kont Global Administrator i stosować zasadę najmniejszych uprawnień,
- monitorować logowania, zdarzenia ryzyka i nietypowe rejestracje metod MFA,
- testować wpływ nowych ustawień na procesy biznesowe przed szerokim wdrożeniem,
- rozszerzać ochronę o polityki ryzyka, kontrolę urządzeń i mechanizmy Zero Trust.
W środowiskach o podwyższonych wymaganiach bezpieczeństwa ustawienia domyślne powinny być traktowane wyłącznie jako warstwa startowa. Pełna ochrona wymaga segmentacji administracji, kontroli sesji, monitorowania anomalii i regularnych przeglądów metod dostępu.
Podsumowanie
Rozszerzanie domyślnych zabezpieczeń w Microsoft Entra ID i Microsoft 365 to ważny krok w stronę ograniczenia najczęstszych ataków na tożsamość w chmurze. Strategia „secure by default” może znacząco poprawić poziom ochrony zwłaszcza tam, gdzie organizacje nie wdrożyły jeszcze zaawansowanych polityk IAM.
Nie oznacza to jednak końca pracy po stronie administratorów. Największą wartość nowe ustawienia przynoszą wtedy, gdy stają się punktem wyjścia do dalszego rozwoju ochrony tożsamości, wdrażania MFA odpornego na phishing oraz budowy dojrzałej architektury Zero Trust.
Źródła
- Automatic Conditional Access policies in Microsoft Entra streamline identity protection — https://www.microsoft.com/en-us/security/blog/2023/11/06/automatic-conditional-access-policies-in-microsoft-entra-streamline-identity-protection/
- Configure Security Defaults for Microsoft Entra ID — https://learn.microsoft.com/en-in/entra/fundamentals/security-defaults
- Update to security defaults — https://techcommunity.microsoft.com/blog/microsoft-entra-blog/update-to-security-defaults/4044868
- Expanding Microsoft’s Secure Future Initiative (SFI) — https://www.microsoft.com/en-us/security/blog/2024/05/03/security-above-all-else-expanding-microsofts-secure-future-initiative/
- How effective is multifactor authentication at deterring cyberattacks? — https://arxiv.org/abs/2305.00945