Zrozumienie przypadków brzegowych przestarzałych protokołów w ekosystemie Microsoft

By Mirko Peters · 2026-04-26

Przestarzałe protokoły uwierzytelniania — jak NTLM, SMTP AUTH czy nawet archaiczny FTP — mogą brzmieć jak problemy z innej epoki, ale uparcie utrzymują się w dzisiejszych, zdominowanych przez Microsoft przedsiębiorstwach…

Automatically translated with AI from the original post. Read the English original

Przestarzałe protokoły uwierzytelniania — jak NTLM, SMTP AUTH czy nawet archaiczny FTP — mogą brzmieć jak problemy z innej epoki, ale uparcie utrzymują się w dzisiejszym, zdominowanym przez Microsoft środowisku przedsiębiorstw. Nowoczesne organizacje migrują do Microsoft 365 i Azure, a mimo to przypadki brzegowe związane z tymi protokołami po cichu podkopują założenia modelu zero trust i strategie bezpieczeństwa. Można zamknąć drzwi frontowe za pomocą uwierzytelniania wieloskładnikowego, ale czasem w piwnicy wciąż otwarte pozostaje stare okno.

Dlaczego te przypadki brzegowe wciąż przysparzają problemów? Prawda jest taka, że modernizacja IT nie zawsze może odbyć się z dnia na dzień. Wiele krytycznych systemów biznesowych, integracji z dostawcami zewnętrznymi, a nawet urządzeń technologii operacyjnej jest na stałe skonfigurowanych do korzystania ze starszych protokołów. Atakujący doskonale o tym wiedzą — dlatego atakują wszystko, co wciąż działa, omijają nowoczesne mechanizmy kontroli i wykorzystują luki tam, gdzie zespoły bezpieczeństwa spodziewają się ich najmniej.

Ten artykuł wyjaśnia, dlaczego i w jaki sposób ryzyko związane z przestarzałymi protokołami utrzymuje się w miarę ewolucji środowisk Microsoft w firmach. Zdefiniujemy kluczowe elementy techniczne, przyjrzymy się zagrożeniom krytycznym dla biznesu i opiszemy, co można zrobić — od wykrywania po zarządzanie — aby raz na zawsze zamknąć te uporczywe luki. Zacznijmy od zrozumienia, skąd naprawdę biorą się zagrożenia i jak zamknąć te tylne drzwi na dobre.

Podatności przestarzałych protokołów a rzeczywiste wykorzystywanie ataków

Mimo natywnych dla chmury zabezpieczeń i uwierzytelniania wieloskładnikowego atakujący nadal czerpią korzyści ze słabych ogniw pozostałych z minionych dekad. Przestarzałe protokoły — jak NTLM do uwierzytelniania, SMTP AUTH do poczty czy podstawowe FTP lub POP3 do przesyłania danych — utrzymują się, ponieważ rzeczywiste systemy muszą działać bez przerwy w trakcie modernizacji firm. Atakujący to wykorzystują, ponieważ często pozwala im to bezkarnie ominąć najlepiej chronione systemy firmy.

W dzisiejszych środowiskach hybrydowych te stare protokoły nie występują jedynie na jednym serwerze ukrytym w centrum danych — są wplecione w chmurowe platformy tożsamości, aplikacje biznesowe, a nawet urządzenia OT i IoT, które w ogóle nie obsługują nowoczesnego uwierzytelniania. Wycofanie ich jest trudne, ponieważ całkowite zablokowanie może przerwać działanie krytycznych elementów, a wykrywanie w tak wielu obszarach nie zawsze jest spójne.

Efekt? Incydenty, takie jak wycieki danych z Vercel i Orange España, pokazują, że wystarczy jeden przeoczony protokół, aby otworzyć drzwi do kradzieży danych lub przejęcia sieci. Atakujący wykorzystują te starsze ścieżki, aby ominąć MFA, przekazywać dalej poświadczenia lub podnosić uprawnienia zarówno w obciążeniach chmurowych, jak i lokalnych. Szczegółowo omówimy, jak dokładnie działają te ataki, dlaczego same protokoły są z założenia wadliwe i gdzie czają się najbardziej uporczywe zagrożenia dla biznesu.

Omówimy także nawyki operacyjne, które sprawiają, że ryzyko się utrzymuje — na przykład poleganie na zaniedbanej higienie zasad czy dziedziczenie lat długu technicznego po integracjach typu „byle działało”. Kolejne podrozdziały szczegółowo opiszą, jak wykorzystuje się podatności przestarzałych rozwiązań, systemowe wady protokołów oraz miejsca, w których nowoczesne mechanizmy obrony napotykają ślepe zaułki. Jeśli szukasz naprawdę bezpiecznego środowiska Microsoft, musisz dokładnie wiedzieć, gdzie kryją się te stare zagrożenia — i jak wciąż przenikają, mimo że logi pokazują, iż wszystko jest „bezpieczne”. Więcej o tym, jak te ataki łączą się ze sobą w realnym świecie, znajdziesz w tym szczegółowym omówieniu łańcuchów ataków na Microsoft 365.

Jak wyciek danych z Vercel i wyciek z Orange España ujawniły ryzyko przestarzałych protokołów

Wycieki danych z Vercel i Orange España mocno uwidoczniły, że ryzyko związane z przestarzałymi protokołami nie jest jedynie hipotetycznym problemem. W obu incydentach przestarzałe metody uwierzytelniania odegrały kluczową rolę, dając atakującym klucze do dalszego przenikania w głąb firmowych sieci. W przypadku Vercel atakujący zdołali wykraść zmienne środowiskowe i sekrety od setek znanych klientów, ponieważ w tle wciąż używano poświadczeń powiązanych z przestarzałymi procesami uwierzytelniania.

Przypadek Orange España wykazał podobny schemat. Tym razem atakujący ominęli pierwszą linię obrony, używając skradzionych, ważnych poświadczeń. Wiele z nich nie zadziałałoby, gdyby dla poczty nie włączono starszych protokołów, takich jak POP3/IMAP, czy niezabezpieczonego SMTP AUTH. Raport IBM o zagrożeniach wskazuje, że kradzież poświadczeń nadal jest najczęstszym wektorem początkowego dostępu w incydentach w przedsiębiorstwach, zwłaszcza gdy organizacje nie wyłączają z wyprzedzeniem przestarzałych metod uwierzytelniania.

Eksperci analizujący te przypadki podkreślają jedną kluczową kwestię: podatności starszych protokołów to nie tylko techniczne pozostałości. Często są głęboko zakorzenione w skryptach automatyzacji, narzędziach do tworzenia kopii zapasowych, a nawet w urządzeniach wbudowanych, które na co dzień po cichu korzystają z przestarzałego uwierzytelniania. Przykładowo w łańcuchu ataków na Vercel protokoły takie jak basic auth oraz źle zagnieżdżone tokeny dostępu pozwoliły atakującym ominąć nowoczesne zasady kontroli i po włamaniu przemieszczać się boczne w sieci.

Czego mogą nauczyć się organizacje? Głośne incydenty wciąż pokazują, że samo zabezpieczenie najnowszych punktów wejścia do chmury nie wystarcza. Odporność wymaga wyeliminowania ukrytych, starszych ścieżek dostępu. Dopóki tego nie zrobimy, atakujący będą wybierać najłatwiejsze, najsłabiej chronione drogi dostępu, często działające w tle konfiguracji hybrydowych i wielochmurowych.

Relaye NTLM i problem podstawowego uwierzytelniania: omijanie nowoczesnych mechanizmów zabezpieczeń

Starsze protokoły, takie jak NTLM i podstawowe uwierzytelnianie (Basic Authentication), sprawiają zespołom bezpieczeństwa mnóstwo kłopotów, ponieważ nie przestrzegają nowoczesnych zasad uwierzytelniania wieloskładnikowego (MFA). Oto, jak podmioty zagrożeń wykorzystują te słabości do obchodzenia zabezpieczeń:

1. Ataki typu relay NTLM:
2. Atakujący przechwytują hashe NTLM na przejętym urządzeniu i „przekazują” je (relay) do innych usług, do których ofiara ma dostęp. Ponieważ NTLM nie wymaga znajomości oryginalnego hasła, atakujący może podszywać się pod użytkowników bez łamania jakiegokolwiek hasła. Takie relaye często biegną od lokalnego AD do chmury, zwłaszcza w słabo segmentowanych konfiguracjach tożsamości hybrydowej.
3. Omijanie MFA:
4. Protokoły takie jak SMTP AUTH i IMAP w ogóle nie obsługują MFA. Jeśli atakujący zdobędzie ważne poświadczenia, może logować się tymi protokołami, nawet gdy na kontach użytkowników wymuszone jest MFA. Oznacza to, że słabe, powtórnie używane hasła stają się pojedynczym punktem awarii w środowiskach, które miały być bezpieczne.
5. Ruch boczny i eskalacja uprawnień:
6. Po wejściu do sieci atakujący wykorzystują starsze protokoły, aby się przemieszczać. Na przykład, wykorzystując basic auth w przeoczonej aplikacji, mogą przejść na systemy o wyższych uprawnieniach. Dostęp do jednej niezabezpieczonej usługi SMB lub Exchange często prowadzi do przejęcia całej sieci.
7. Obchodzenie dostępu warunkowego:
8. Wiele zasad dostępu warunkowego w Azure AD dotyczy wyłącznie klientów korzystających z nowoczesnego uwierzytelniania. Starsze protokoły mogą prześlizgnąć się mimo tych reguł, zostawiając niebezpieczne „listy dozwolonych” lub luki w zasadach, których aktywnie szukają atakujący. Chcesz poznać więcej o pętlach bezpieczeństwa tożsamości i naprawianiu chaosu w dostępie warunkowym? Posłuchaj tego odcinka podcastu o skalowalnym ograniczaniu ryzyka w środowiskach Microsoft.

Krótko mówiąc, możesz konfigurować i wzmacniać nowoczesne mechanizmy kontroli, ale jeśli starsze protokoły wciąż funkcjonują, atakujący prawie zawsze znajdą sposób na obejście nowych zabezpieczeń.

Błędy systemowe: od podatności MCP po zagrożenia LLMNR i NetBIOS

Starsze protokoły Microsoft są obciążone wadami, które nie są zwykłymi błędami, lecz wpisane są w ich konstrukcję. Oto, dlaczego te słabości stanowią uporczywe ryzyko:

1. Wady MCP (Microsoft Connector Platform):
2. Niektóre platformy i konektory używane przez agentów zewnętrznych oraz skrypty automatyzacji nadal opierają się na starszym przekazywaniu poświadczeń, bez odpowiedniego wiązania tokenów czy szczegółowej kontroli dostępu. Atakujący wykorzystują to do eskalacji uprawnień, zwłaszcza gdy zasady dla agentów nie są ściśle nadzorowane.
3. Słabości LLMNR (Link-Local Multicast Name Resolution):
4. Protokół LLMNR zaprojektowano z myślą o łatwym rozpoznawaniu nazw w sieci, ale bardzo łatwo go nadużyć do kradzieży poświadczeń. Atakujący rozgłaszają sfałszowane odpowiedzi, nakłaniając pobliskie systemy do wydania skrótów NetNTLM, które następnie można złamać lub przekazać dalej (relay).
5. Zagrożenia związane z nazewnictwem NetBIOS:
6. Stare sieci Windows nadal używają protokołu NetBIOS do rozpoznawania nazw — kolejnego protokołu, który nigdy nie został zaprojektowany z myślą o bezpieczeństwie. Atakujący mogą przechwytywać i modyfikować ruch, podszywać się pod usługi lub zbierać wrażliwe informacje o sieci, co pozwala im przygotować kolejne ataki.
7. Luki w podpisywaniu SMB:
8. Podpisywanie SMB zostało wprowadzone, aby zabezpieczać udziały plików, ale jego egzekwowanie jest niekonsekwentne, szczególnie w sieciach hybrydowych i środowiskach OT. Atakujący wykorzystują to, przekazując dalej poświadczenia lub podszywając się pod odpowiedzi między systemami — często przechodząc z przestarzałej infrastruktury OT do nowoczesnej infrastruktury IT.

Wyłączenie protokołów takich jak LLMNR oraz wymuszenie podpisywania SMB to absolutne minimum dla każdego rzeczywistego wdrożenia modelu Zero Trust. Aby lepiej zrozumieć, jak skoordynowana kontrola i adaptacyjne zabezpieczenia mogą pomóc zamknąć te luki protokołów, posłuchaj odcinka podcastu Zero Trust by Design — to praktyczne omówienie zunifikowanej tożsamości i kontroli sesji.

Nowoczesne uwierzytelnianie a rozwiązania legacy: wyzwania przy przejściu i przypadki brzegowe

Przejście z dotychczasowego uwierzytelniania na nowoczesne to proces, a nie szybka zmiana. Zamykając tę lukę, napotkasz różne przypadki brzegowe. Protokoły takie jak OAuth 2 i MFA podnoszą poziom bezpieczeństwa, ale potrzeba zachowania zgodności wstecznej często pozostawia tylne drzwi uchylone. „Półnowoczesne” przepływy uwierzytelniania — na przykład modele hybrydowe lub protokoły udające nowoczesne — pojawiają się wszędzie, mącąc obraz zarówno pod kątem zgodności, jak i ochrony.

Dlaczego organizacje kończą z takimi konfiguracjami hybrydowymi? Odpowiedź jest prosta: krytyczne aplikacje, usługi i integracje z dostawcami zewnętrznymi nie zawsze są gotowe, by z dnia na dzień wyłączyć starsze uwierzytelnianie. Czasem prosty proces biznesowy lub odziedziczony przepływ automatyzacji zależy od metod uwierzytelniania sprzed kilkunastu lat. Pochopne ich wyłączenie może zakłócić działanie biznesu lub naruszyć zgodność, dlatego tworzy się wyjątki — i właśnie tam wkraczają atakujący.

Prawdziwy model Zero Trust oznacza zamknięcie każdej luki, a nie tylko dokładanie efektownych nowych warstw. Problem polega na tym, że podczas modernizacji uwierzytelniania niektóre „ulepszenia” po prostu zawijają stare podatności w nowszy pakiet, jak BAV2ROPC czy inne przepływy hasła właściciela zasobu. Luki w zasadach oraz przeoczone wyjątki w warunkowym dostępie mogą sprawić, że zabezpieczenia wyglądają nowocześnie na papierze, a jednocześnie pozostawiają otwarte ścieżki starego uwierzytelniania.

Kolejne sekcje szczegółowo omawiają techniczne niuanse tych półnowoczesnych konfiguracji i pokazują, gdzie nawet najlepsze plany usprawnień natrafiają na realne przeszkody. Jeśli planujesz prawdziwą transformację — lub po prostu chcesz utrzymać atakujących z dala — warto wiedzieć, dlaczego wsparcie dla starych rozwiązań tak trudno wygasa i gdzie Twoja strategia wciąż może pozostawiać Cię wystawionym na ryzyko. Wskazówki dotyczące budowy niezawodnych bazowych zasad warunkowego dostępu znajdziesz w tym artykule o problemach z zaufaniem do zasad.

Zagadka BAV2ROPC i pułapki półnowoczesnego uwierzytelniania

BAV2ROPC to skrót od "Basic Authentication Version 2 Resource Owner Password Credential". Brzmi nowocześnie, ale w rzeczywistości to nowa otoczka dla starego problemu. Ten protokół, często spotykany w środowiskach chmurowych Microsoft, łączy dawne i nowe metody uwierzytelniania, pozwalając aplikacjom programowo przekazać nazwę użytkownika i hasło w celu uzyskania tokenu zasobu — bez przeglądarki i bez nowoczesnego przepływu zgody.

To „półnowoczesne” podejście wprowadza w błąd wiele organizacji. Na pierwszy rzut oka BAV2ROPC korzysta z nowoczesnych punktów końcowych i przepływów OAuth 2. Pod spodem jednak opiera się na tej samej podstawowej wymianie nazwy użytkownika i hasła, z której korzystają starsze protokoły, takie jak POP3, IMAP czy SMTP AUTH — i rzadko obsługuje MFA lub warunkowy dostęp. Pozostawia to furtkę dla atakujących, którzy mogą przeprowadzać ataki typu password stuffing, replay poświadczeń lub ataki przekaźnikowe z infrastruktury lokalnej do chmury.

Wykrycie tego jest trudne. W logach ruch BAV2ROPC trudno odróżnić od prawdziwego nowoczesnego uwierzytelniania. Atakujący doskonale o tym wiedzą i celowo atakują aplikacje lub konta usługowe korzystające z tych przepływów, ponieważ próby włamania nie uruchamiają takich samych alarmów jak klasyczne Basic Auth. Organizacje w praktyce mają trudności z odejściem od BAV2ROPC, zwłaszcza w przypadku bezobsługowych zadań automatyzacji i skryptów integracyjnych, które wciąż są używane w codziennej działalności.

Dla zespołów bezpieczeństwa największą pułapką jest założenie, że wszystko oznaczone jako „OAuth 2” lub „resource owner” jest domyślnie bezpieczne. BAV2ROPC i podobne protokoły pokazują niewygodną prawdę: nawet eleganckie, nowoczesne interfejsy API mogą narażać na te same słabości, co protokoły, które miały zastąpić. Dopóki nie przeprowadzisz pełnego audytu i nie zmigrujesz każdego przypadku brzegowego, te półnowoczesne luki pozostają otwartymi celami dla atakujących.

Gdy ulepszenia uwierzytelniania nie wystarczają: śmierć strategii bezpieczeństwa przez wsparcie dla starych protokołów

Uaktualnienie do OAuth 2 i wdrożenie MFA we wszystkich miejscach brzmi jak idealne rozwiązanie – dopóki wsparcie dla starych protokołów nie wprowadzi fatalnej luki. Badania pokazują, że w ostatnim roku ponad 60% przejęć kont w chmurze obejmowało użycie poprawnych poświadczeń przez stare protokoły. Nawet najbardziej zaawansowane zasady dostępu warunkowego przestają działać, jeśli przeoczono wyjątek albo stara aplikacja nadal korzysta z uwierzytelniania podstawowego w tle.

Eksperci ostrzegają, że modernizacja stosu uwierzytelniania to nie tylko odhaczanie kolejnych funkcji na liście. Trwałe wsparcie dla starych protokołów, błędnie skonfigurowane zasady i niezarządzane konta usługowe pozwalają atakującym omijać nawet solidne mechanizmy obrony. Jedynym sposobem, by nadążyć, jest kompleksowy plan przejścia, który aktywnie wycofuje stare ścieżki, audytuje wyjątki w zasadach i nadzoruje każdy punkt końcowy. Aby zobaczyć, jak atakujący wykorzystują zgody OAuth i stare ścieżki w praktyce, przeczytaj tę szczegółową analizę ataków z wykorzystaniem zgód w Entra ID, a dlaczego dobre zarządzanie nie działa automatycznie, sprawdź w tym podcaście o iluzji zarządzania w Microsoft 365.

Wykrywanie i monitorowanie użycia starych protokołów w środowiskach przedsiębiorstw

Wykrywanie i monitorowanie użycia starego uwierzytelniania przypomina szukanie ukrytych wycieków w rozległej instalacji wodociągowej. Łatwo przeoczyć utrzymujące się połączenia protokołów, ponieważ nie zawsze są one widoczne na nowoczesnych pulpitach. Każdy pominięty przypadek – czy to stary skrypt kopii zapasowej, drukarka, czy czujnik IoT – daje atakującym kolejną szansę na wejście.

Aby sobie z tym poradzić, środowiska Microsoft 365 i Azure oferują zestaw dzienników i narzędzi analitycznych zaprojektowanych z myślą o głębokiej widoczności. Trzeba jednak wiedzieć, gdzie szukać i jak interpretować wyniki, które nie zawsze wyraźnie sygnalizują „stare uwierzytelnianie tutaj”. Łącząc dzienniki logowania, ścieżki audytu i niestandardową telemetrię z narzędzi takich jak PowerShell i Python, uzyskujesz pełniejszy obraz tego, gdzie przenikają stare protokoły. Korelowanie danych z zasobów chmurowych i lokalnych jest kluczowe, ponieważ w środowiskach hybrydowych raportowanie często bywa niespójne.

Co jeszcze utrudnia to zadanie? Niektóre urządzenia firm trzecich i urządzenia OT nadal po cichu korzystają ze starych protokołów i rzadko są uwzględniane w standardowych skanowaniach bezpieczeństwa czy raportach analitycznych. Zespoły bezpieczeństwa muszą warstwowo łączyć różne techniki monitorowania – od skoroszytów analitycznych logowań w Azure po pobieranie Unified Audit Log – aby wychwycić każdy ślad użycia protokołów. Praktyczne omówienie audytowania działań w dzierżawie i tego, dlaczego bogatsze sygnały mają znaczenie dla zgodności i bezpieczeństwa, znajdziesz w tym przewodniku po Microsoft Purview Audit.

Poniższe podrozdziały krok po kroku pokażą, jak wykryć i zbadać ślady starego uwierzytelniania w Twoim środowisku, wraz z praktycznymi wskazówkami dotyczącymi generowania użytecznej telemetrii – dzięki temu ukryte podatności nie pozostaną ukryte na długo.

Wykrywanie starego uwierzytelniania w dziennikach logowania Azure i skoroszytach analitycznych

Wykrycie starego uwierzytelniania w dziennikach logowania Azure i analityce Entra ID wymaga proaktywnego podejścia. Oto praktyczna lista kontrolna, która pomoże wychwycić te ukryte, ryzykowne protokoły w działaniu:

1. Filtruj według typu aplikacji klienckiej:
2. Zacznij od dzienników logowania Azure AD w portalu Azure. Filtruj wpisy według pola „Aplikacja kliencka”, aby wyświetlić połączenia wykonane starymi protokołami, takimi jak IMAP, POP3, SMTP oraz „Inne klienty”. Te wpisy zwykle się wyróżniają, ponieważ nie korzystają z przepływów uwierzytelniania opartych na przeglądarce ani z nowoczesnego uwierzytelniania.
3. Szukaj metod uwierzytelniania:
4. Przeanalizuj szczegółowo zdarzenia logowania, w których „Metoda uwierzytelniania” ma wartość „Hasło”, a brakuje „MFA” lub „Nowoczesnego uwierzytelniania”. Często wskazuje to na protokoły omijające dostęp warunkowy, zwłaszcza w przypadku starszych urządzeń lub skryptów automatyzacji.
5. Skonfiguruj skoroszyty analityczne:
6. Użyj Azure Monitor lub skoroszytów analitycznych Entra ID, aby wizualizować trendy w czasie. Utwórz niestandardowy skoroszyt, który pokaże na wykresie wykorzystanie protokołów, wyróżni nagłe skoki uwierzytelniania starszego typu oraz oznaczy niezgodne z zasadami połączenia klientów.
7. Korelacja z danymi o urządzeniach i lokalizacji:
8. Zestaw zdarzenia uwierzytelniania starszego typu z informacjami o urządzeniu i geolokalizacją logowania. Nietypowe kombinacje, na przykład logowanie starym protokołem z kraju, w którym Twoja firma nie prowadzi działalności, warto dokładnie przeanalizować.
9. Wskazówki dotyczące rozwiązywania problemów:
10. Jeśli wyniki wydają się skąpe, sprawdź, czy nie ma luk w zasadach lub w przechowywaniu dzienników. Niektóre zdarzenia mogą zostać odfiltrowane lub pominięte, jeśli ustawienia audytu nie są kompleksowe albo jeśli w zasadach dostępu warunkowego istnieją wyłączenia.

Powtarzając te kroki, zbudujesz wiarygodny wgląd w środowisko. Pamiętaj, że nawet kilka wpisów dotyczących protokołów starszego typu w dziennikach może wskazywać na większe zagrożenia w innych miejscach, dlatego kopnij głęboko i podążaj za danymi, dokąd cię prowadzą.

Generowanie telemetrii za pomocą PowerShell, Pythona i ujednoliconych dzienników audytu: przykłady i dobre praktyki

Aby wychwycić każdy ślad aktywności starych protokołów, nie ma nic lepszego niż własna telemetria. Oto jak ją skonfigurować przy użyciu PowerShell, Pythona i ujednoliconego dziennika audytu Microsoft:

1. Zapytania PowerShell dla protokołów starszego typu:
2. Użyj cmdletów Get-Mailbox i Get-CASMailbox w usłudze Exchange Online, aby wyświetlić listę użytkowników z włączonym protokołem IMAP, POP3 lub SMTP AUTH. Umieść je w skryptach generujących raporty dzienne lub tygodniowe, które porównasz z analizami z dzienników logowania.
3. Automatyzacja w Pythonie na potrzeby korelacji dzienników:
4. Użyj skryptów w Pythonie, aby połączyć się z interfejsem Microsoft Graph API i pobrać rekordy logowania oraz audytu skrzynek pocztowych. Przeanalizuj typy aplikacji klienckich i flagi protokołów uwierzytelniania, a następnie wyświetl anomalie, na przykład konta usług bez interfejsu użytkownika korzystające z uwierzytelniania starszego typu.
5. Ujednolicony dziennik audytu do scentralizowanego monitorowania:
6. Włącz usługę Microsoft Purview Audit (dawniej Unified Audit Log), aby agregować aktywność z usług Exchange, SharePoint, Teams i innych. Przeszukuj pola Operation związane z połączeniami klientów starszego typu lub nieudanymi próbami uwierzytelniania starszego typu, aby zbudować spójny potok wykrywania.
7. Interaktywne wizualizacje i alerty:
8. Eksportuj telemetrię lub przesyłaj ją strumieniowo do usługi Microsoft Sentinel lub Power BI. Twórz pulpity z regułami alertów, które uruchamiają się przy nowym użyciu protokołów starszego typu lub po wykryciu ujawnienia poświadczeń.
9. Uważaj na pułapki:
10. Zwróć uwagę na niekompletne dane wynikające z ograniczonego przechowywania dzienników, luk w domyślnej konfiguracji lub zdarzeń, które nie są rejestrowane domyślnie. Zawsze sprawdzaj pokrycie, wykonując testowe logowania protokołami starszego typu, zanim uznasz sprawę za zamkniętą.

Więcej o łączeniu telemetrii z zarządzaniem i automatyzacją (gdy treść wróci) znajdziesz na stronie this missing PowerShell automation page — lub sprawdź ostatnie odcinki podcastu o architekturze przedsiębiorstwa, aby poznać kierunek rozwoju strategii telemetrii.

Strategie łagodzenia ryzyka: blokowanie i wyłączanie protokołów starszego typu

Wiedza, że działają protokoły starszego typu, to dopiero pierwsza bitwa; zwycięstwo oznacza wyłączenie tych kanałów bez paraliżowania działalności firmy. Właściwe podejście polega na zrównoważeniu redukcji ryzyka z ciągłością operacyjną. Microsoft 365 i Azure AD oferują potężne narzędzia, takie jak dostęp warunkowy i przełączniki administracyjne, które pozwalają na masowe wyłączenie przestarzałych metod uwierzytelniania, ale wdrażać je trzeba z rozwagą.

Dwie główne taktyki to: użycie dostępu warunkowego do blokowania uwierzytelniania starszego typu we wszystkich miejscach oraz wyłączenie protokołów takich jak SMTP AUTH, IMAP i POP3 w dostępie do poczty i urządzeń. Kluczem jest znalezienie każdego wyjątku i każdego zagrożonego procesu, zanim odłączysz wtyczkę, szczególnie w przypadku kont usługowych, hybrydowych lokalnych systemów pocztowych lub integracji zewnętrznych, których nie da się łatwo zmodernizować. Wdrożenia etapowe i ukierunkowane zmiany zasad pomagają upewnić się, że nie przerwiesz krytycznych procesów, a jednocześnie ograniczysz narażenie na kradzież poświadczeń i nadużycia związane ze spamem.

Równie ważne jest połączenie zmian w zasadach z przygotowaniem biznesu. Komunikuj się z interesariuszami, testuj na mniejszych grupach i wykorzystuj analitykę, aby wykazać, że zmiana nie sparaliżuje działania organizacji. W poniższych sekcjach znajdziesz instrukcje krok po kroku oraz uwagi dotyczące wymuszania dostępu warunkowego i wyłączania starszych protokołów w centrum administracyjnym Microsoft 365. Ciekawi Cię, jakie ukryte ryzyka pojawiają się, gdy nie mierzy się nawyków biznesowych? Posłuchaj tego podcastu o dryfie zgodności i wymuszaniu zasad, aby poznać więcej szczegółów.

Przy dobrze przemyślanym planie blokowanie starszych protokołów nie tylko odhacza wymagania zgodności — znacznie utrudnia atakującym znalezienie tych jednych, zapomnianych otwartych drzwi.

Jak blokować starsze uwierzytelnianie za pomocą dostępu warunkowego

Blokowanie starszego uwierzytelniania za pomocą dostępu warunkowego w Azure AD jest skuteczne i precyzyjne, jeśli zostanie wykonane właściwie. Oto, co warto wiedzieć:

Zasady dostępu warunkowego pozwalają organizacjom jawnie blokować próby uwierzytelnienia przy użyciu starszych protokołów, takich jak SMTP AUTH, IMAP, POP3 i klientów podstawowego uwierzytelniania. Zasady można ograniczyć do użytkowników, grup lub urządzeń, a potencjalny wpływ na biznes monitorować w trybie „tylko raport” przed wdrożeniem. Takie etapowe podejście daje szansę na wykrycie zależności, które mogłyby przestać działać po zablokowaniu bez przygotowania.

Microsoft zaleca utworzenie co najmniej dwóch podstawowych zasad: jednej blokującej starsze uwierzytelnianie dla wszystkich użytkowników oraz drugiej z wykluczeniami czasowymi dla kont usługowych lub znanych wyjątków. Testowanie jest kluczowe — zacznij od trybu monitorowania, aby zobaczyć, które konta i aplikacje próbują logować się starszymi metodami, a następnie przejdź do wymuszania, gdy będziesz pewien, że zakłócone zostaną jedynie niekrytyczne procesy.

Pamiętaj o przeglądzie i ograniczeniu szerokich wpisów na listach dozwolonych oraz dziedziczonych wyjątków — tworzą one niewidoczne luki w zabezpieczeniach. Ciągłe monitorowanie i alerty dotyczące prób starszego uwierzytelniania pomogą wychwycić nowe zagrożenia w miarę zmian w środowisku IT. Więcej sprawdzonych praktyk i solidnych zasad bazowych znajdziesz w tym omówieniu eksperta dotyczącym dostrajania dostępu warunkowego pod kątem przewidywalnego i bezpiecznego zarządzania dostępem.

Podsumowując: zaostrzenie dostępu warunkowego to Twoja pierwsza linia obrony. Pamiętaj tylko, aby wprowadzać zmiany metodycznie — zawsze równoważąc potrzeby biznesowe z celami bezpieczeństwa.

Wyłączanie SMTP AUTH i starszych protokołów poczty e-mail w centrum administracyjnym Microsoft 365

Wyłączenie SMTP AUTH i innych starszych protokołów poczty e-mail to jeden z najszybszych sposobów na ograniczenie kradzieży poświadczeń i uniemożliwienie atakującym rozsyłania spamu przez Twoją dzierżawę. Oto jak to zrobić krok po kroku:

1. Audyt bieżącego użycia:
2. Zacznij od programu Exchange Online PowerShell (Get-TransportConfig i Get-Mailbox). Zidentyfikuj skrzynki pocztowe z włączonym SMTP AUTH oraz aktywnymi jeszcze protokołami IMAP/POP3 dla użytkowników lub kont usługowych.
3. Wyłączenie na poziomie dzierżawy:
4. Centrum administracyjne Microsoft 365 umożliwia teraz wyłączenie SMTP AUTH dla całej dzierżawy jednym ustawieniem. Blokuje to wszystkie nowe próby uwierzytelnienia, chyba że dla konkretnych skrzynek utworzono wyjątki.
5. Ukierunkowane czyszczenie zasad:
6. Dla użytkowników lub aplikacji, które rzeczywiście potrzebują SMTP AUTH, ogranicz dostęp w sposób jawny i uważnie je monitoruj. Usuń uprawnienia IMAP/POP3 ze wszystkich kont poza najbardziej niezbędnymi — najlepiej ze wszystkich.
7. Testowanie i komunikacja:
8. Zanim wyłączysz to na szeroką skalę, przeprowadź testy i poinformuj użytkowników lub właścicieli systemów. Obserwuj zgłoszenia do helpdesku związane z przerwanymi automatyzacjami, a następnie współpracuj z tymi zespołami, aby zaktualizować ich procesy lub przenieść je na nowoczesne uwierzytelnianie.
9. Monitorowanie po wdrożeniu:
10. Sprawdzaj dzienniki audytu pod kątem nieudanych prób korzystania ze starszych protokołów. Uporczywe błędy mogą świadczyć o próbach ataku lub o przeoczonych zależnościach biznesowych, którymi trzeba się zająć.

Ten plan skutecznie powstrzymuje większość typowych ataków na poświadczenia za pośrednictwem poczty e-mail i znacznie odciąża zespół ds. zgodności. Solidne kontrole na początku oznaczają mniej pracy porządkowej w przyszłości.

Zarządzanie bezpieczeństwem i nadzór strategiczny nad ryzykiem starszych protokołów

Blokowanie starszych protokołów to nie tylko przełączanie ustawień technicznych. Prawdziwe zarządzanie ryzykiem zaczyna się na szczeblu kierowniczym, gdzie kadra zarządzająca, zespoły operacji bezpieczeństwa i architekci IT wspólnie nadzorują cykl życia zarówno technologii, jak i zasad. Problem w tym, że większość dużych organizacji opiera się na łatanym zestawie mechanizmów kontrolnych, zasad i zewnętrznych dostawców, przez co trudno jest zapewnić spójny nadzór na dużą skalę.

Dobra strategia governance odpowiada na trudne pytania: Jak zarządzać ryzykiem, gdy integracje zewnętrzne, narzędzia agentowe i shadow IT działają według różnych reguł? Jak stosować jednolite mechanizmy kontrolne, gdy połowa Twoich „zaufanych” partnerów lub urządzeń IoT nie potrafi nawet obsługiwać nowoczesnego uwierzytelniania? I jak stale monitorować dryf zasad w miarę zmian w biznesie, zatrudnieniu i krajobrazie bezpieczeństwa?

Tu właśnie wchodzą w grę wirtualne ramy governance, dyscyplina w zakresie zasad i zaawansowana inteligencja. Kierownictwo nie tylko musi wyznaczać ton od góry, ale też wdrażać realne kontrole: od weryfikacji najbardziej ryzykownych dostawców usług, przez prowadzenie audytów, po wdrażanie automatyzacji do wykrywania i usuwania zagrożeń. Wraz z tym, jak AI i automatyzacja przyspieszają bardziej niż kiedykolwiek, chodzi o to, by narzędzia, zasady i ludzie działali w zgodzie.

W kolejnych sekcjach przyjrzymy się skutecznym sposobom, na jakie CISO i decydenci mogą budować modele governance nastawione przede wszystkim na pracę zdalną, zarządzać najtrudniej przewidywalnym ryzykiem związanym z podmiotami trzecimi i agentami oraz wykorzystać nowoczesną inteligencję, by na dobre zamknąć luki związane z protokołami. Więcej o równoważeniu innowacji z nadzorem znajdziesz w tych wskazówkach dotyczących governance dla Power Platform, a o tym, jak nadążyć za tym, że automatyzacje i agenci poruszają się szybciej niż Twoje zasady, dowiesz się w tym odcinku z praktycznymi ramami governance.

Jak liderzy bezpieczeństwa chronią się przed najbardziej ryzykownymi podmiotami trzecimi w ramach wirtualnych ram governance

Wiodące organizacje stosują warstwowe, proaktywne podejście do zarządzania ryzykiem związanym ze starszymi protokołami, zwłaszcza tym pochodzącym od podmiotów trzecich. Oto cztery praktyczne strategie:

• Wdrożenie nadzoru nad agentami: Monitoruj i audytuj wszystkie konta usługowe, agentów i integracje zewnętrzne, które wchodzą w interakcje z Twoim środowiskiem. Stosuj unikalne tożsamości (takie jak Entra Agent ID) dla agentów i egzekwuj ścisłe umowy za pośrednictwem platform takich jak Microsoft Connector Platform (MCP). Pomaga to zapobiegać dryfowi tożsamości i utracie odpowiedzialności, szczególnie w przypadku integracji opartych na AI (więcej o governance agentów znajdziesz tutaj).
• Egzekwowanie bezpiecznych zasad uwierzytelniania: Wymagaj od wszystkich dostawców i partnerów korzystania z nowoczesnego uwierzytelniania – bez wyjątków w imię „zgodności z legacy”, chyba że zastosowano zatwierdzone kompensujące mechanizmy kontrolne. Regularnie przeglądaj wykluczenia z Conditional Access dla urządzeń zewnętrznych i przepływów opartych na łącznikach.
• Segregacja i monitorowanie urządzeń OT/IoT oraz urządzeń, których nie można załatać: Jeśli masz technologie operacyjne lub urządzenia IoT ograniczone do starszych protokołów, wydziel je do odizolowanych sieci. Stosuj kompensujące mechanizmy kontrolne, takie jak monitorowanie sieci i białe listy dostępu, aby ograniczyć narażenie na zagrożenia bocznego przemieszczania się.
• Przeprowadzanie zdalnych i wirtualnych przeglądów governance: Wdrażaj wirtualne ramy governance, aby monitorować, naprawiać i zarządzać z dowolnego miejsca. Ramy te kładą nacisk na regularne przeglądy, zautomatyzowane audyty i jasną komunikację między interesariuszami – co jest niezbędne, gdy coraz więcej operacji przechodzi na model hybrydowy lub zdalny.

Koncentrując się na warstwowym nadzorze, a nie tylko na kontrolach technicznych, CISO i liderzy IT mogą ograniczać ryzyko płynące z najtrudniej dostępnych zakątków swojego ekosystemu.

Wykorzystanie zaawansowanej inteligencji do wzmocnienia operacji bezpieczeństwa przeciwko zagrożeniom związanym z legacy

Narzędzia inteligencji opartej na AI i zaawansowana analityka zagrożeń dają organizacjom nową przewagę w wykrywaniu, badaniu i reagowaniu na nadużycia starszych protokołów na dużą skalę. Platformy te wykorzystują uczenie maszynowe do identyfikowania anomalnych zachowań uwierzytelniania, szybkiego filtrowania podejrzanego użycia starszych protokołów oraz automatycznego usuwania zagrożeń bez ludzkiego opóźnienia.

Nowoczesne zespoły ds. bezpieczeństwa operacji integrują dane z usług Microsoft Sentinel, Purview Audit oraz analityki behawioralnej opartej na sztucznej inteligencji, aby zbudować scentralizowany widok aktywności uwierzytelniania, zarówno nowoczesnego, jak i starszego. Zautomatyzowane playbooki mogą uruchamiać reakcje na wyjątki od zasad, konta usług wysokiego ryzyka lub zdarzenia przekazywania poświadczeń — zamykając luki, zanim atakujący zdążą je wykorzystać.

Integracja automatyzacji i analityki to konieczność, a nie opcja. Platformy orkiestracji pomagają łączyć dane z środowisk chmurowych, lokalnych i hybrydowych, dzięki czemu nawet mało znane starsze przepływy uwierzytelniania nie pozostają niezauważone. Jest to tym bardziej istotne, że wraz z rozwojem agentów AI i rozbudowanych automatyzacji rosną zarówno korzyści, jak i ryzyka operacyjne.

Na koniec egzekwowanie dostępu zgodnie z zasadą najmniejszych uprawnień, etykietowanie poufnych treści oraz rozszerzanie monitorowania audytu pozwalają kontrolować zarówno użytkowników ludzkich, jak i maszynowych. Praktyczny schemat wykorzystania zaawansowanej analityki i sztucznej inteligencji do ochrony przed zagrożeniami ze starszych mechanizmów w środowiskach Microsoft — w tym w usłudze Copilot oraz w botach firm trzecich — znajdziesz w szczegółowym przewodniku po zarządzanej sztucznej inteligencji i zgodności.