Zabezpieczenia aplikacji Outlook Web App: ochrona serwera Exchange za pomocą uwierzytelniania wieloskładnikowego (MFA)

Wprowadzenie

Większość dyskusji na temat bezpieczeństwa zdalnego dostępu zaczyna się od sieci VPN. Prawie żadna z nich nie dotyczy aplikacji Outlook Web App (OWA), co jest dziwną luką, biorąc pod uwagę, czym faktycznie jest OWA: formularzem logowania do firmowej poczty elektronicznej, umieszczonym w otwartej sieci internetowej, dostępnym z dowolnej przeglądarki na dowolnym urządzeniu, z dowolnego miejsca. Nie ma tu żadnego klienta VPN do skonfigurowania, żadnej reguły zapory sieciowej do obejścia, żadnego segmentu sieci, przez który trzeba by się przedostać — tylko pole nazwy użytkownika, pole hasła i to, co serwer Exchange zdecyduje się zaakceptować.

Dla atakującego jest to niemal jak najprostsza droga do skrzynki pocztowej. Włamanie do OWA nie wymaga przemieszczania się w sieci, by stać się niebezpieczne — jest niebezpieczne od razu, ponieważ celem jest sama skrzynka pocztowa. Atak typu Business Email Compromise nie wymaga złośliwego oprogramowania, nie wymaga wykorzystania luki w zabezpieczeniach i nie uruchamia większości narzędzi wykrywających włamania do sieci. Wymaga jedynie jednego zestawu prawidłowych danych uwierzytelniających oraz strony logowania, która nie prosi o nic więcej.

Dlaczego lokalne i hybrydowe rozwiązania Exchange nie otrzymują uwierzytelniania wieloskładnikowego (MFA) za darmo

To zamieszanie jest zrozumiałe, ponieważ dzierżawcy Microsoft 365 korzystający z Exchange Online rzeczywiście otrzymują silne uwierzytelnianie niemal automatycznie — zasady warunkowego dostępu Entra ID mogą wymagać uwierzytelniania wieloskładnikowego (MFA) na poziomie tożsamości, zanim zostanie wydany token sesji, a ochrona ta rozciąga się na Outlooka w sieci bez żadnej konfiguracji specyficznej dla Exchange. Zespoły ds. bezpieczeństwa, które dotychczas pracowały wyłącznie w środowisku czysto chmurowym, słusznie zakładają, że uwierzytelnianie wieloskładnikowe (MFA) dla poczty internetowej jest po prostu standardem działania Exchange.

Lokalne i hybrydowe wersje Exchange nie dziedziczą tego zachowania. Własny stos uwierzytelniania serwera Exchange — rola usług dostępu klienckiego obsługująca OWA i Centrum administracyjne Exchange — weryfikuje nazwę użytkownika i hasło w Active Directory i, o ile nie ma dodatkowej konfiguracji, na tym kończy się cała decyzja dotycząca uwierzytelniania. W lokalnym logowaniu do OWA nie ma wbudowanego natywnego drugiego czynnika uwierzytelniającego. Wdrożenia hybrydowe jeszcze bardziej komplikują tę sytuację: niektóre skrzynki pocztowe mogą być już przeniesione do Exchange Online i objęte dostępem warunkowym, podczas gdy inne pozostają w środowisku lokalnym i mogą nadal opierać się na własnej ścieżce uwierzytelniania serwera Exchange, chyba że wyraźnie skonfigurowano hybrydowe nowoczesne uwierzytelnianie (Hybrid Modern Authentication) lub inne rozwiązanie MFA. Całkiem możliwe jest, że organizacja uważa, iż jej poczta elektroniczna jest „chroniona przez uwierzytelnianie wieloskładnikowe”, ponieważ tak jest w przypadku dzierżawcy, podczas gdy znaczna część skrzynek pocztowych nadal korzysta z lokalnego OWA opartego wyłącznie na haśle.

Jest to luka, która ma znaczenie operacyjne – nie dlatego, że lokalny serwer Exchange jest z natury mniej bezpieczny, ale dlatego, że nakłada ona odpowiedzialność za dodanie drugiego czynnika uwierzytelniającego wyłącznie na administratora serwera Exchange, bez domyślnego rozwiązania, na które można by się oprzeć.

Co faktycznie daje atakującemu przejęte konto OWA lub EAC

Łatwo jest nie docenić wartości pojedynczych danych logowania do OWA, jeśli traktuje się je jako „tylko pocztę elektroniczną”. W praktyce przejęte konto skrzynki pocztowej stanowi punkt oparcia, z którego rozgałęzia się kilka różnych ścieżek ataku.

Najbardziej bezpośrednie skutki finansowe ma atak typu Business Email Compromise (BEC).

Najbardziej bezpośrednim zagrożeniem finansowym jest atak typu Business Email Compromise (BEC). Centrum Skarg Dotyczących Przestępstw Internetowych FBI odnotowało w 2025 r. w Stanach Zjednoczonych zgłoszone straty związane z atakami BEC w wysokości 3,046 mld dolarów – była to druga co do wielkości kategoria strat, zaraz po oszustwach inwestycyjnych, obejmująca około 24 768 skarg – co daje średnią stratę przekraczającą 120 000 dolarów na każdy potwierdzony incydent. Ataki typu BEC zazwyczaj nie wykorzystują złośliwego oprogramowania ani złośliwych linków, które mogłyby zostać wykryte przez filtry bezpieczeństwa; atakujący znajduje się wewnątrz legalnej skrzynki pocztowej, wysyła wiadomości z legalnego adresu, często odpowiadając w ramach istniejącej wymiany korespondencji, podając zmodyfikowany numer rozliczeniowy banku lub przekierowaną fakturę. Reguły przepływu poczty utrudniają wykrycie tej techniki po fakcie — atakujący mający dostęp do skrzynki pocztowej może utworzyć regułę skrzynki odbiorczej, która w tle przekierowuje lub usuwa wiadomości zawierające słowa takie jak „faktura”, „przelew” lub „płatność”, dzięki czemu właściciel konta nie zauważa naruszenia bezpieczeństwa, podczas gdy oszukańcza korespondencja toczy się równolegle.

Dostęp delegowany zwiększa ryzyko naruszenia bezpieczeństwa.

Dostęp delegowany zwiększa ryzyko narażenia. Asystenci kadry kierowniczej i członkowie zespołów finansowych często posiadają uprawnienia delegowane lub uprawnienia „wyślij jako” do skrzynek pocztowych kadry kierowniczej w ramach normalnego przepływu pracy, co oznacza, że pojedyncze przejęte konto asystenta może zostać wykorzystane do wysyłania wiadomości, które wydają się pochodzić bezpośrednio od dyrektora finansowego lub dyrektora generalnego, bez konieczności korzystania z danych uwierzytelniających tej osoby.

Ujawnienie danych to mniej widoczne ryzyko

Ujawnienie danych to cichsze zagrożenie, a często także bardziej poważne dla organizacji podlegających regulacjom. W skrzynce pocztowej gromadzą się przez lata załączniki, notatki wewnętrzne, korespondencja kadrowa i komunikacja z klientami – wszystko to jest dostępne za pośrednictwem interfejsu OWA po uwierzytelnieniu się atakującego — nie są potrzebne żadne oddzielne narzędzia do wycieku danych, ponieważ atakujący może uzyskać dostęp do zawartości skrzynki pocztowej i pobrać ją, korzystając z legalnych funkcji OWA.

Podejście 1: Uwierzytelnianie wieloskładnikowe (MFA) stosowane bezpośrednio przy logowaniu do OWA i EAC

Najbardziej ukierunkowane rozwiązanie zajmuje się konkretnym obszarem narażonym na ryzyko, nie ingerując w żadne inne elementy powiązane z usługą Active Directory. Uwierzytelnianie wieloskładnikowe (MFA) dla aplikacji Outlook Web App i Centrum administracyjnego Exchange instaluje się jako komponent w ramach roli usług dostępu klienckiego Exchange, działając przed istniejącymi stronami logowania do OWA i EAC, zamiast całkowicie zastępować mechanizm uwierzytelniania Exchange. Po zainstalowaniu użytkownicy najpierw uwierzytelniają się przy użyciu swojej zwykłej nazwy użytkownika i hasła z AD, a następnie wykonują drugi etap uwierzytelniania — na przykład poprzez wprowadzenie jednorazowego hasła (OTP) z aplikacji uwierzytelniającej lub tokena sprzętowego albo poprzez zatwierdzenie powiadomienia push — zanim sesja zostanie przyznana.

Zakres jest ustalany poprzez przynależność do grupy Active Directory w momencie instalacji: administrator może natychmiast wymagać uwierzytelniania wieloskładnikowego (MFA) dla całej populacji użytkowników lub początkowo włączyć je dla pojedynczej grupy AD — grupy pilotażowej lub konkretnie grupy posiadającej dostęp do Centrum administracyjnego Exchange — podczas gdy planowane jest szersze wdrożenie. To rozróżnienie ma znaczenie w praktyce, ponieważ konta EAC wiążą się ze znacznie większym ryzykiem dla organizacji niż pojedyncza skrzynka pocztowa; konto administratora z dostępem do EAC może tworzyć reguły przepływu poczty, modyfikować uprawnienia lub eksportować dane w całym środowisku Exchange, co właśnie sprawia, że ochrona logowań do EAC jest zazwyczaj priorytetem, nawet jeśli pełne wdrożenie dla wszystkich użytkowników trwa dłużej.

Zachowanie sesji jest konfigurowalne, a nie stałe. Administratorzy ustalają, jak często użytkownicy są ponownie proszeni o podanie nowego kodu OTP — na przykład raz na 12 godzin ciągłego korzystania z OWA — równoważąc utrudnienia związane z powtarzającym się uwierzytelnianiem z ryzykiem długotrwałej, nienadzorowanej sesji na urządzeniu współdzielonym lub niezarządzanym. Komponent obsługuje algorytmy HOTP, TOTP oraz OCRA typu „wyzwanie-odpowiedź”, zapewniając elastyczność organizacjom korzystającym z różnych typów tokenów OTP.

Podejście 2: Uwierzytelnianie wieloskładnikowe (MFA) na poziomie Active Directory, obejmujące OWA wraz ze wszystkimi innymi usługami

Warto zadać sobie bardziej szczegółowe pytanie przed wdrożeniem komponentu przeznaczonego specjalnie dla OWA: czy OWA jest rzeczywiście jedyną usługą połączoną z Active Directory, która nadal uwierzytelnia wyłącznie na podstawie hasła? W przypadku większości środowisk lokalnych szczera odpowiedź brzmi „nie” — Winlogon, RDP i często wewnętrzne aplikacje powiązane z LDAP znajdują się w tej samej sytuacji, chronione jedynie przez zasady dotyczące haseł egzekwowane przez Active Directory.

Uwierzytelnianie wieloskładnikowe na poziomie katalogu rozwiązuje problem tego szerszego narażenia poprzez integrację z samym Active Directory, a nie ze stroną logowania każdej pojedynczej usługi. Zamiast szeregu oddzielnych wdrożeń uwierzytelniania wieloskładnikowego — jednego komponentu dla OWA, innego agenta dla RDP, serwera proxy RADIUS dla VPN, z których każdy jest instalowany, konfigurowany i utrzymywany niezależnie — integracja na poziomie katalogu zmienia sposób działania poświadczeń użytkowników w Active Directory poprzez zastąpienie statycznych haseł dynamicznymi hasłami opartymi na czasie, dzięki czemu usługi połączone z AD mogą korzystać z tych samych dynamicznych poświadczeń bez konieczności stosowania oddzielnych komponentów uwierzytelniania wieloskładnikowego dla każdej usługi. OWA jest objęta tym rozwiązaniem nie dlatego, że została specjalnie wytypowana, ale dlatego, że podobnie jak wszystkie inne usługi skierowane do AD, musi teraz spełniać te same wymagania dotyczące dynamicznej weryfikacji poświadczeń.

Kompromis ten przebiega w kierunku przeciwnym do podejścia 1: szerszy zakres ochrony w zamian za bardziej daleko idącą zmianę w sposobie działania uwierzytelniania AD w całym środowisku, co zazwyczaj wymaga bardziej przemyślanych testów i stopniowego wdrażania niż w przypadku komponentu OWA obsługującego jedną usługę. Właściwy wybór między tymi dwoma podejściami zależy rzeczywiście od zakresu — organizacja, której jedyną niezabezpieczoną powierzchnią połączoną z usługą AD jest OWA, nie musi ingerować w katalog, aby to naprawić; organizacja, która odkrywa, że OWA, RDP i Winlogon korzystają wyłącznie z uwierzytelniania opartego na hasłach, ma szerszy problem, którego nie rozwiąże naprawa dotycząca jednej usługi.

Jak działa mechanizm na poziomie katalogu bez agentów na punktach końcowych

Warto zrozumieć mechanizm stojący za uwierzytelnianiem wieloskładnikowym na poziomie katalogu, ponieważ wyjaśnia on, dlaczego obejmuje on każdą usługę połączoną z usługą Active Directory bez konieczności instalowania czegokolwiek na poszczególnych stacjach roboczych lub serwerach.

Dynamiczne uwierzytelnianie silnym hasłem działa poprzez modyfikację hasła przechowywanego w samym Active Directory, a nie poprzez przechwytywanie ruchu uwierzytelniającego w każdym punkcie końcowym. Statyczne hasło użytkownika jest zastępowane rotacyjnym hasłem dynamicznym opartym na algorytmie TOTP, które zmienia się automatycznie w odstępach czasu skonfigurowanych przez administratora — wartość ta musi być wielokrotnością 30 sekund. Aktualne hasło dynamiczne jest generowane przy użyciu algorytmu TOTP i jest dostępne dla użytkownika za pośrednictwem aplikacji Protectimus SMART lub obsługiwanej aplikacji chatbot. Ponieważ zmiana następuje bezpośrednio w katalogu, każdy klient lub usługa uwierzytelniająca się w usłudze AD — Winlogon, RDP, OWA, aplikacje korzystające z LDAP — automatycznie wykorzystuje aktualne hasło dynamiczne, bez konieczności informowania tej usługi o jakichkolwiek zmianach.

To właśnie sprawia, że podejście to jest bezagentowe w istotnym sensie: na laptopie, hoście RDP ani serwerze Exchange Client Access nie działa żadne oprogramowanie sprawdzające drugi czynnik uwierzytelniający. Sam katalog jest punktem egzekwowania. Odpowiednim kompromisem jest to, że komponent ten działa w ramach wdrożenia lokalnego, a nie wyłącznie w chmurze, ponieważ wymaga bezpośredniej integracji z kontrolerem domeny.

Wybór zakresu: tylko poczta internetowa czy całe środowisko AD

Oba podejścia rozwiązują podstawowy problem — samo hasło nie wystarcza już do uwierzytelnienia — ale robią to na różnych poziomach stosu, a właściwy wybór zależy raczej od rzetelnej analizy stanu niż od domyślnych preferencji.

Jeśli OWA i EAC rzeczywiście są jedynymi usługami, które nadal uwierzytelniają się w AD wyłącznie za pomocą hasła — VPN jest już obsługiwany przez RADIUS, RDP jest już zabezpieczone, a żadna inna starsza aplikacja nie korzysta w tle z poświadczeń AD — ukierunkowany komponent OWA wypełnia tę konkretną lukę przy minimalnym zakłóceniu działania pozostałych elementów korzystających z katalogu. Jeśli inwentaryzacja wykaże więcej niż jedną narażoną usługę – co jest częstszym wynikiem, gdy zespoły IT faktycznie rozpoczną poszukiwania – uwierzytelnianie wieloskładnikowe (MFA) na poziomie katalogu zabezpiecza je wszystkie z jednego punktu integracji, zamiast gromadzić oddzielne produkty MFA dla każdej z nich.

Tak czy inaczej, dane FBI dotyczące strat spowodowanych atakami BEC wskazują na ten sam podstawowy fakt: logowanie wyłącznie za pomocą hasła do firmowej skrzynki pocztowej, znajdującej się w otwartej sieci internetowej, nie jest już pozycją, której można bronić w przypadku żadnej organizacji korzystającej z Exchange — lokalnej, hybrydowej czy innej.