W pierwszym artykule tego cyklu wymieniliśmy krótką listę błędów powdrożeniowych. Tutaj rozwijamy temat: nie tylko technicznie (konfiguracja bezpieczeństwa), ale też organizacyjnie — bo środowisko, które działa poprawnie zaraz po migracji, po kilku miesiącach bez nadzoru zaczyna generować problemy zupełnie innego rodzaju. 

Część 1: Błędy bezpieczeństwa 

1. Legacy authentication wciąż aktywne mimo włączonego MFA 

Włączenie MFA nie oznacza automatycznie, że wszystkie protokoły logowania je respektują. Starsze protokoły – POP, IMAP, starszy Exchange ActiveSync, Remote PowerShell – historycznie potrafiły łączyć się do skrzynek metodą Basic Authentication, czyli przesyłając login i hasło bez żadnej dodatkowej weryfikacji. Microsoft trwale wyłączył Basic Authentication w Exchange Online dla większości tych protokołów, ale luka wciąż się pojawia tam, gdzie funkcjonują starsze aplikacje, drukarki wysyłające skany mailem przez SMTP AUTH czy systemy księgowe łączące się bezpośrednio ze skrzynką. 

Jak naprawić: wdrożenie reguły Conditional Access blokującej starsze uwierzytelnianie dla wszystkich użytkowników, z wyjątkami tylko dla kont serwisowych o ograniczonym zakresie (np. wyłącznie SMTP AUTH dla konkretnego adresu IP drukarki). 

2. MFA „włączone” nie znaczy „skutecznie chroniące” 

Częsty scenariusz: MFA jest wymuszone w polityce, ale rejestracja objęła tylko część zespołu, konta awaryjne (break-glass) mają wyłączone MFA na stałe „dla wygody”, a część kont wciąż korzysta ze słabszych metod weryfikacji, takich jak SMS. Microsoft Authenticator z number matching zapewnia wyższy poziom ochrony, natomiast dla kont o podwyższonym ryzyku warto stosować metody odporne na phishing, takie jak passkeys lub klucze bezpieczeństwa FIDO2. To rozmywa realną skuteczność zabezpieczenia. 

Ustawa o krajowym systemie cyberbezpieczeństwa (nowelizacja wdrażająca unijną dyrektywę NIS2) — Dz.U. 2026 poz. 252, weszła w życie 3 kwietnia 2026 r.  

NIS2 dotyczy  tylko podmiotów zakwalifikowanych jako „kluczowe” lub „ważne” w określonych sektorach (energetyka, transport, zdrowie, infrastruktura cyfrowa, część usług publicznych i in.). Obejmuje przede wszystkim podmioty prowadzące określone rodzaje działalności wskazane w załącznikach nr 1 i 2 do ustawy. W wielu przypadkach znaczenie ma również wielkość przedsiębiorstwa zgodnie z unijną definicją MŚP, ale ustawa przewiduje także wyjątki, w których podmiot podlega regulacji niezależnie od wielkości. NIS2 wymaga uwzględnienia MFA w stosownych przypadkach oraz wdrożenia polityk kontroli dostępu.

Jak naprawić: Warto zrobić przegląd kont wyłączonych z polityk Conditional Access. Włączyć MFA dla 100% kont (łącznie z kontami administracyjnymi i serwisowymi tam, gdzie to możliwe), udokumentowane i ograniczone konta break-glass, preferowanie metod odpornych na phishing tam, gdzie ryzyko jest wyższe (administratorzy, dostęp do danych finansowych). 

Statystyka: Ponad 99,9% przejętych kont nie miało włączonego MFA. Według badań Microsoft, MFA blokuje ponad 99,2% prób przejęcia konta. (źródło https://learn.microsoft.com/pl-pl/partner-center/security/security-at-your-organization) 

3. Niewidoczne reguły przekierowania poczty 

Atakujący, który raz zdobędzie dostęp do skrzynki (np. przez phishing sprzed wdrożenia MFA), może ustawić regułę przekazującą kopie wiadomości na zewnętrzny adres – bez żadnego dalszego logowania. Ofiara nic nie zauważa, a atakujący czeka na wiadomość z danymi do przelewu, hasłami czy danymi osobowymi. Reguły takie bywają celowo nazwane pojedynczą kropką lub średnikiem, żeby nie rzucały się w oczy na liście. 

Jak naprawić: domyślna blokada automatycznego przekazywania poczty na adresy zewnętrzne na poziomie tenanta, z wyjątkami zatwierdzanymi indywidualnie, oraz stałe alertowanie o nowych regułach przekierowań. 

4. Domyślne ustawienia udostępniania w SharePoint i OneDrive 

Domyślna konfiguracja udostępniania w wielu tenantach pozwala tworzyć linki typu „Każdy, kto ma link” – czyli dostęp bez logowania, możliwy do przekazania dalej bez kontroli. Po migracji, gdy zespół intensywnie przenosi dokumenty i uczy się nowego środowiska, tego typu linki powstają masowo i zostają na stałe, bo nikt ich potem nie przegląda. 

Jak sprawdzić: raport udostępniania w centrum administracyjnym SharePoint (Data Access Governance), przegląd witryn z aktywnymi linkami anonimowymi. 

Jak naprawić: ograniczenie domyślnego poziomu udostępniania do „nowi i istniejący goście” lub „tylko osoby w organizacji”, wymuszenie wygasania linków „Każdy” (30 dni lub mniej), a w miejscach z danymi wrażliwymi – całkowite wyłączenie udostępniania zewnętrznego. 

5. Brak cyklicznych przeglądów dostępu 

Migracja ustala dostępy raz – na starcie. Problem w tym, że od tego momentu środowisko żyje własnym życiem: powstają nowi goście, zmieniają się role, a nikt systematycznie nie sprawdza, czy dany dostęp jest wciąż potrzebny. Dotyczy to zwłaszcza kont z rolami uprzywilejowanymi (np. Global Administrator) i kont gościnnych po zakończonych projektach. 

Jak sprawdzić: liczba kont z aktywnymi rolami uprzywilejowanymi bez ograniczenia czasowego, liczba kont gościnnych bez właściciela lub bez logowania od kilku miesięcy. 

Jak naprawić: wdrożenie cyklicznych przeglądów dostępu (Access Reviews) w Entra ID – dla ról uprzywilejowanych i dla dostępu gości – oraz Privileged Identity Management (PIM), które nadaje uprawnienia administracyjne tylko na czas potrzebny do wykonania zadania, zamiast na stałe. 

6. Wskaźnik bezpieczeństwa (Secure Score) nieużywany po wdrożeniu 

Microsoft udostępnia wbudowane narzędzie oceniające konfigurację zabezpieczeń tenanta w punktach – Secure Score. W praktyce wiele firm nigdy go nie otwiera po zakończeniu migracji, mimo że to gotowa checklista rekomendacji, aktualizowana automatycznie w miarę zmian w środowisku. 

Jak sprawdzić: portal Microsoft Defender → Secure Score – aktualny wynik i lista niezaimplementowanych rekomendacji. 

Jak naprawić: ustalenie Secure Score jako stałego punktu cyklicznego przeglądu środowiska (np. raz na kwartał), z priorytetem dla rekomendacji dotyczących tożsamości i danych. 

Część 2: Błędy organizacyjne 

7. Niekontrolowany przyrost Teams i SharePoint (sprawl) 

Po migracji każdy może tworzyć nowe zespoły i witryny bez konwencji nazewnictwa, właściciela czy daty wygaśnięcia. Po kilku miesiącach większość takich obszarów jest nieaktywna, ale nikt nie wie, czy można je usunąć. Zgodnie z danymi od Microsoft: w typowym tenancie ok. dwie trzecie obszarów roboczych Teams i SharePoint jest nieaktywnych. 

Jak naprawić: ustalenie zasad tworzenia zespołów (szablony, zatwierdzanie), polityk wygasania nieaktywnych obszarów. 

8. Marnowanie licencji 

Firmy kupują nowe licencje dla nowych pracowników, zamiast odzyskiwać nieużywane po odejściu innych. Osobny problem: aktywni użytkownicy mają drogie licencje z funkcjami, których nigdy nie włączają. 

Jak naprawić: okresowy przegląd przypisań licencji, pula odzyskanych licencji do ponownego wykorzystania. 

9. Konta gości, które zostają po zakończonych projektach 

Gdy w firmie nie ma formalnego obowiązku zgłaszania zakończenia współpracy z gościem, firmą zewnętrzną czy zespołem, który tymczasowo realizował projekt, dostęp takiego konta trwa bezterminowo — nikt go nie wyłącza, bo nikt nie jest za to odpowiedzialny. To organizacyjna przyczyna problemu opisanego w punkcie 5. 

Jak naprawić: sponsor/ właściciel i data wygaśnięcia przypisane do każdego konta gościa już przy jego tworzeniu 

10. Brak właściciela tenanta i dokumentacji decyzji 

Migrację często prowadzi zewnętrzny wdrożeniowiec lub jedna osoba z IT, a po projekcie nikt formalnie nie przejmuje bieżącej odpowiedzialności. Decyzje konfiguracyjne giną — przy audycie nikt nie umie wyjaśnić, dlaczego coś jest ustawione tak, a nie inaczej. 

Jak naprawić: jasno przypisany właściciel tenanta, dokumentowanie decyzji i wyjątków w konfiguracji. 

Podsumowanie – tabela ryzyk 

Wspólny mianownik tych dziesięciu punktów: żaden nie wynika z błędnie przeprowadzonej migracji technicznej. Wszystkie pojawiają się później — bo migracja to projekt z datą zakończenia, a bezpieczeństwo i porządek w środowisku to proces, który trwa dalej i wymaga kogoś, kto systematycznie go pilnuje. 

FAQ 

1. Czy te błędy dotyczą tylko dużych firm?

Nie. Legacy authentication, brak przeglądów dostępu czy domyślne udostępnianie w SharePoint dotyczą każdego tenanta niezależnie od wielkości – różni się tylko skala ryzyka i liczba kont do przejrzenia. 

2. Ile czasu po migracji te problemy zaczynają być widoczne?

Sprawl w Teams i konta gości bez daty wygaśnięcia narastają zwykle po 3–6 miesiącach od migracji. Luki w MFA i legacy authentication mogą istnieć od pierwszego dnia, ale ujawniają się dopiero przy incydencie lub audycie bezpieczeństwa. 

3. Jak często warto przeprowadzać przegląd środowiska?

W praktyce sprawdza się kwartalny przegląd obejmujący kilka obszarów naraz: (a) role uprzywilejowane i dostęp gości, (b) wynik Secure Score i niezaimplementowane rekomendacje, (c) nieaktywne zespoły Teams/witryny SharePoint oraz przypisania licencji, (d) reguły przekierowania poczty i próby logowania przez legacy authentication. Te dwa ostatnie punkty dodatkowo warto objąć stałym monitoringiem (alerty), a nie czekać na przegląd kwartalny — to obszary, w których czas reakcji ma największe znaczenie. 

4. Czy Conditional Access i Access Reviews wymagają dodatkowej licencji?

Podstawowe polityki Conditional Access są dostępne w planach z Entra ID P1 (często w pakiecie z Business Premium). Access Reviews i Privileged Identity Management wymagają wyższego planu — Entra ID P2 lub Entra ID Governance.