Przeniesienie do Microsoft 365 zostało zakończone. SharePoint działa. Teams jest domyślną platformą komunikacji. Exchange Online obsługuje pocztę. Entra ID jest dostawcą tożsamości. Twój zespół IT oddycha z ulgą.
Tymczasem Twoja chmurowa warstwa tożsamości może być Twoją najbardziej odsłoniętą powierzchnią ataku — a większość ryzyka wynika z wyborów konfiguracyjnych dokonanych podczas migracji, pod presją czasu, bez wystarczającej analizy bezpieczeństwa.
Błąd 1: Wciąż włączone uwierzytelnianie przestarzałe
Przestarzałe protokoły uwierzytelniania — POP3, IMAP, SMTP Auth, Basic Auth — całkowicie omijają dostęp warunkowy. Nie obsługują MFA. Microsoft wyłączył je domyślnie w 2022 roku, ale wiele dzierżaw włączyło je ponownie podczas migracji na potrzeby przestarzałych aplikacji i nigdy ich nie wyłączyło. Jeśli uwierzytelnianie przestarzałe jest włączone, Twoje zasady dostępu warunkowego zapewniają niepełną ochronę.
Naprawa: Użyj dzienników logowania Entra ID, aby zidentyfikować aktywność uwierzytelniania przestarzałego. Wyłącz je dla wszystkich kont, dla których nie istnieje uzasadnione zastosowanie.
Błąd 2: Aplikacje firmowe z nadmiernymi uprawnieniami
Aplikacje podmiotów trzecich z tokenami OAuth często żądają znacznie szerszych uprawnień niż potrzeba. Aplikacja żądająca Mail.ReadWrite.All i Files.ReadWrite.All ma dostęp do wszystkiego w Twojej dzierżawie. Większość organizacji ma dziesiątki takich nadmiernie uprawnionych aplikacji i nie potrafiłaby powiedzieć, czym one są.
Naprawa: Przejrzyj uprawnienia aplikacji firmowych. Usuń nieużywane aplikacje. Ogranicz zgody OAuth udzielane przez użytkowników. Wymagaj zatwierdzenia administratora dla nowych żądań zgody.
Błąd 3: Brak zasad dostępu warunkowego
Bez dostępu warunkowego dowolne ważne dane uwierzytelniające mogą uzyskać dostęp do Twojego środowiska z dowolnego miejsca i z dowolnego urządzenia. Dojrzała postawa dostępu warunkowego obejmuje: wymagane MFA dla wszystkich użytkowników, blokowanie dostępu z niezaufanych lokalizacji/urządzeń, wymaganie zgodnych urządzeń dla wrażliwych aplikacji, blokowanie uwierzytelniania przestarzałego oraz odporne na phishing MFA dla kont administracyjnych.
Naprawa: Przeprowadź przegląd zasad dostępu warunkowego. Zmapuj zasięg, wykluczenia i zachowanie w przypadku braku dopasowania.
Błąd 4: Administratorzy globalni bez ochrony
Wiele organizacji ma kilku użytkowników ze stałym przypisaniem roli Global Admin, korzystających ze swojego codziennego konta pocztowego, chronionych standardowym MFA. Przejęcie konta Global Admin to w praktyce całkowite przejęcie dzierżawy.
Naprawa: Ogranicz stałe role Global Admin do dwóch kont awaryjnych (break-glass) ze sprzętowym MFA. Używaj Entra PIM do dostępu administracyjnego na żądanie. Oddziel konta administracyjne od kont codziennego użytku.
Błąd 5: Niepełny proces odejścia w środowiskach hybrydowych
W środowiskach hybrydowych wyłączenie lokalnego konta AD może nie unieważnić tokenów Entra ID. Byli pracownicy mogą zachować dostęp do Teams, SharePoint i aplikacji SaaS podmiotów trzecich, które używają M365 jako dostawcy tożsamości.
Naprawa: Sprawdź, czy wyłączenie konta AD uruchamia unieważnienie sesji Entra ID. Wdróż unieważnianie tokenów jako element listy kontrolnej procesu odejścia.
Błąd 6: Ignorowanie sygnałów ataku w dziennikach
Dzienniki logowania Entra ID zawierają dowody ataków odbywających się właśnie teraz w większości firmowych dzierżaw — niemożliwe podróże, wzorce rozpylania haseł, uwierzytelnianie przestarzałe z nietypowych lokalizacji, ataki typu token replay. Większość organizacji nie zagląda do tych dzienników.
Naprawa: Podłącz dzienniki Entra ID do SIEM. Utwórz reguły detekcji dla niemożliwych podróży, dużej liczby nieudanych uwierzytelnień i uwierzytelniania przestarzałego z nowych lokalizacji.