Zabezpečení aplikace Outlook Web App: Ochrana služby Exchange pomocí MFA

Úvod

Většina diskuzí o bezpečnosti vzdáleného přístupu začíná tématem VPN. Téměř žádná z nich nezačíná aplikací Outlook Web App, což je podivná mezera, vezmeme-li v úvahu, co OWA ve skutečnosti je: přihlašovací formulář pro firemní e-mail, umístěný na otevřeném internetu, přístupný z jakéhokoli prohlížeče na jakémkoli zařízení a odkudkoli. Není třeba konfigurovat žádný VPN klient, obcházet žádná pravidla firewallu ani procházet žádné síťové segmenty – stačí pole pro uživatelské jméno, pole pro heslo a cokoli, co server Exchange rozhodne přijmout.

Pro útočníka je to prakticky přímá cesta do poštovní schránky. Kompromitované přihlášení do OWA nevyžaduje laterální pohyb, aby se stalo nebezpečným – je nebezpečné již okamžitě, protože cílem je samotná poštovní schránka. Kompromitace firemní e-mailové komunikace nepotřebuje malware, nepotřebuje exploit a nespustí většinu detekčních nástrojů vytvořených pro síťové vniknutí. Potřebuje pouze jednu sadu platných přihlašovacích údajů a přihlašovací stránku, která nepožaduje nic dalšího.

Proč on-premise a hybridní Exchange nemají MFA zdarma

Zmatek v této souvislosti je pochopitelný, protože nájemci Microsoft 365 využívající Exchange Online skutečně získávají silné ověřování téměř automaticky – zásady podmíněného přístupu Entra ID mohou vyžadovat MFA na úrovni identity ještě před vydáním tokenu relace a tato ochrana se vztahuje i na Outlook na webu bez jakékoli konfigurace specifické pro Exchange. Bezpečnostní týmy, které dosud pracovaly pouze v čistě cloudovém prostředí, logicky předpokládají, že MFA pro webovou poštu je standardní součástí fungování Exchange.

Lokální a hybridní Exchange toto chování nezdědí. Vlastní ověřovací stack serveru Exchange – role služeb Client Access, která zpracovává OWA a Exchange Admin Center – ověřuje uživatelské jméno a heslo proti Active Directory a bez další konfigurace je to celé ověřovací rozhodnutí. Do přihlášení k OWA v lokálním prostředí není zabudován žádný nativní druhý faktor. Hybridní nasazení situaci ještě více komplikují: některé poštovní schránky již mohou být přesunuty do Exchange Online a podléhat podmíněnému přístupu, zatímco jiné zůstávají v lokálním prostředí a mohou se stále spoléhat na vlastní autentizační cestu serveru Exchange, pokud nebylo výslovně nakonfigurováno hybridní moderní ověřování (Hybrid Modern Authentication) nebo jiné řešení MFA. Je zcela možné, že organizace věří, že její e-mail je „chráněn MFA“, protože to platí pro nájemce, zatímco významná část poštovních schránek stále využívá lokální OWA chráněnou pouze heslem.

Právě tato mezera má z provozního hlediska zásadní význam, a to nikoli proto, že by lokální Exchange byl ze své podstaty méně bezpečný, ale proto, že odpovědnost za přidání druhého ověřovacího faktoru klade výhradně na správce Exchange, aniž by existovalo výchozí řešení, na které by se dalo spolehnout.

Co vlastně napadený účet OWA nebo EAC útočníkovi poskytuje

Hodnotu jediného přihlašovacího údaje k OWA lze snadno podcenit, pokud o něm uvažujete jako o „pouhém e-mailu“. V praxi je kompromitovaný účet poštovní schránky opěrným bodem, z něhož se odvíjí několik různých cest útoku.

Nejpřímější finanční dopad má kompromitace firemní e-mailové komunikace (BEC).

Útok typu Business Email Compromise (BEC) je finančně nejpřímější. Centrum pro stížnosti na internetovou kriminalitu (IC3) FBI zaznamenalo v roce 2025 ve Spojených státech nahlášené ztráty způsobené útoky BEC ve výši 3,046 miliardy dolarů, což je druhá nejvyšší kategorie ztrát hned po investičních podvodech, rozložená do zhruba 24 768 stížností – průměrná ztráta přesahující 120 000 dolarů na jeden potvrzený incident. Útoky typu BEC se typicky obejdou bez malwaru a bez škodlivých odkazů, které by bezpečnostní filtr mohl zachytit; útočník se nachází uvnitř legitimní e-mailové schránky, odesílá zprávy z legitimní adresy a často odpovídá v rámci existujícího vlákna s upraveným bankovním směrovacím číslem nebo přesměrovanou fakturou. Pravidla pro tok pošty ztěžují odhalení této techniky až po jejím provedení – útočník s přístupem k poštovní schránce může vytvořit pravidlo pro doručenou poštu, které tiše přeposílá nebo maže zprávy obsahující slova jako „faktura“, „převod“ nebo „platba“, čímž zůstává narušení bezpečnosti pro majitele účtu skryté, zatímco podvodná konverzace pokračuje souběžně.

Riziko ještě zvyšuje delegovaný přístup.

Riziko se ještě zvyšuje v důsledku delegovaného přístupu. Asistenti vedení a členové finančního týmu často disponují oprávněními k delegaci nebo k odesílání „jako“ v poštovních schránkách vedoucích pracovníků v rámci běžného pracovního postupu, což znamená, že jediný napadený účet asistenta lze využít k odesílání komunikace, která vypadá, jako by pocházela přímo od finančního ředitele nebo generálního ředitele, aniž by bylo nutné použít přihlašovací údaje daného vedoucího pracovníka.

Zveřejnění dat je tišší riziko

Únik dat je tišší riziko a pro regulované organizace často i riziko s vážnějšími důsledky. V poštovní schránce se hromadí roky příloh, interních poznámek, korespondence s personálním oddělením a komunikace s klienty – to vše je přístupné prostřednictvím vlastního rozhraní OWA, jakmile se útočník autentizuje. Není zapotřebí žádný samostatný nástroj pro exfiltraci, protože útočník může k obsahu poštovní schránky přistupovat a stahovat jej pomocí legitimních funkcí OWA.

Přístup 1: MFA aplikovaná přímo na přihlášení do OWA a EAC

Nejcílenější řešení řeší konkrétní ohroženou plochu, aniž by zasahovalo do čehokoli jiného spojeného s Active Directory. MFA pro Outlook Web App a Exchange Admin Center se instaluje jako komponenta role služeb Exchange Client Access a je umístěna před stávající přihlašovací stránky OWA a EAC, místo aby přímo nahrazovala ověřovací mechanismus Exchange. Po instalaci se uživatelé nejprve ověří svým běžným uživatelským jménem a heslem z Active Directory a poté dokončí druhý krok ověření – například zadáním jednorázového kódu (OTP) z autentizační aplikace nebo hardwarového tokenu, případně schválením push notifikace – teprve poté je relace povolena.

Rozsah se nastavuje prostřednictvím členství ve skupině Active Directory v době instalace: správce může okamžitě vyžadovat MFA pro celou skupinu uživatelů, nebo ji zpočátku povolit pouze pro jednu skupinu AD – pilotní skupinu, nebo konkrétně skupinu s přístupem do Exchange Admin Center – zatímco se plánuje širší zavedení. Tento rozdíl má v praxi význam, protože účty EAC představují pro organizaci podstatně větší riziko než jednotlivé poštovní schránky; správcovský účet s přístupem k EAC může vytvářet pravidla toku pošty, upravovat oprávnění nebo exportovat data v celém prostředí Exchange, a právě proto bývá ochrana přihlášení do EAC prioritou, i když plné zavedení pro všechny uživatele trvá déle.

Chování relace je konfigurovatelné, nikoli pevně dané. Správci nastavují, jak často se uživatelům zobrazí výzva k zadání nového OTP – například jednou za 12 hodin nepřetržitého používání OWA – a vyvažují tak obtíže spojené s opakovaným ověřováním proti riziku dlouhodobé, bez dozoru ponechané relace na sdíleném nebo nespravovaném zařízení. Tato komponenta podporuje HOTP, TOTP a OCRA s výzvou a odpovědí, čímž poskytuje flexibilitu organizacím používajícím různé typy OTP tokenů.

Přístup 2: MFA na úrovni Active Directory, pokrývající OWA spolu se vším ostatním

Úžší otázka, kterou stojí za to si položit před nasazením komponenty specifické pro OWA: je OWA skutečně jedinou službou připojenou k AD, která se stále ověřuje pouze pomocí hesla? U většiny lokálních prostředí je upřímná odpověď „ne“ – Winlogon, RDP a často i interní aplikace vázané na LDAP jsou na tom stejně a nejsou chráněny ničím jiným než zásadami pro hesla, které vynucuje AD.

Vícestupňové ověřování na úrovni adresáře řeší tuto širší zranitelnost integrací přímo do Active Directory, nikoli na přihlašovací stránce každé jednotlivé služby. Místo řady samostatných nasazení MFA – jedna komponenta pro OWA, jiný agent pro RDP, proxy RADIUS pro VPN, z nichž každá se instaluje, konfiguruje a udržuje samostatně – integrace na úrovni adresáře mění způsob fungování uživatelských přihlašovacích údajů v Active Directory tím, že nahrazuje statická hesla časově vázanými dynamickými hesly, takže služby připojené k AD mohou používat stejné dynamické přihlašovací údaje, aniž by pro každou službu byly nutné samostatné komponenty MFA. OWA je zahrnuta nikoli proto, že by byla specificky zacílena, ale proto, že stejně jako vše ostatní směřující do AD nyní musí splňovat stejnou kontrolu dynamických přihlašovacích údajů.

Tento kompromis směřuje opačným směrem než přístup 1: širší pokrytí výměnou za rozsáhlejší změnu chování ověřování AD v celém prostředí, což obvykle vyžaduje pečlivější testování a postupné zavádění než v případě komponenty OWA pro jednu službu. Správná volba mezi těmito dvěma přístupy skutečně závisí na rozsahu – organizace, jejíž jedinou nechráněnou plochou připojenou k AD je OWA, nemusí k nápravě této situace zasahovat do adresáře; organizace, která zjistí, že OWA, RDP a Winlogon využívají ověřování pouze pomocí hesla, má širší problém, který oprava jedné služby nevyřeší.

Jak funguje mechanismus na úrovni adresáře bez agentů na koncových bodech

Stojí za to pochopit mechanismus MFA na úrovni adresáře sám o sobě, protože vysvětluje, proč se dostane ke všem službám připojeným k AD, aniž by bylo nutné cokoli instalovat na jednotlivé pracovní stanice nebo servery.

Dynamické silné ověřování heslem funguje tak, že upravuje heslo uložené přímo v Active Directory, namísto zachycování ověřovacího provozu na každém koncovém bodě. Statické heslo uživatele je nahrazeno rotujícím dynamickým heslem založeným na algoritmu TOTP, které se automaticky mění v intervalu nakonfigurovaném správcem – tato hodnota musí být násobkem 30 sekund. Aktuální dynamické heslo se generuje pomocí algoritmu TOTP a je uživateli k dispozici prostřednictvím aplikace Protectimus SMART nebo podporovaného chatbota. Jelikož ke změně dochází přímo v adresáři, jakýkoli klient nebo služba provádějící ověřování vůči AD – Winlogon, RDP, OWA, aplikace využívající LDAP – automaticky používá aktuální dynamické heslo, aniž by tato služba musela vědět, že došlo ke změně.

Právě to činí tento přístup bezagentovým v tom smyslu, na kterém záleží: na notebooku, hostiteli RDP ani na serveru Exchange Client Access neběží žádný software, který by kontroloval druhý faktor. Samotný adresář je místem vynucení. Odpovídající kompromis spočívá v tom, že tato komponenta běží jako součást lokálního nasazení, nikoli jako čistě cloudová služba, protože vyžaduje přímou integraci s řadičem domény.

Volba rozsahu: pouze webová pošta, nebo celé prostředí Active Directory

Oba přístupy řeší základní problém – heslo samo o sobě již nestačí k ověření – ale řeší jej v různých částech systému a správná volba závisí spíše na poctivém zhodnocení stávajícího stavu než na výchozích preferencích.

Pokud jsou OWA a EAC skutečně jedinými službami, které se stále ověřují proti AD pouze pomocí hesla – VPN je již pokryta prostřednictvím RADIUS, RDP je již uzamčeno a žádná jiná starší aplikace tiše nedůvěřuje přihlašovacím údajům AD –, cílená komponenta OWA tuto konkrétní mezeru uzavře s minimálním narušením všeho ostatního, co běží proti adresáři. Pokud inventarizace odhalí více než jednu zranitelnou službu – což je častější zjištění, jakmile se IT týmy skutečně pustí do hledání –, vícefaktorová autentizace (MFA) na úrovni adresáře je všechny zabezpečí z jediného integračního bodu, místo aby se pro každou z nich pořizoval samostatný produkt MFA.

Ať tak či onak, údaje FBI o ztrátách způsobených podvody typu BEC poukazují na stejný základní fakt: přihlášení pouze pomocí hesla k firemní e-mailové schránce, která je umístěna na otevřeném internetu, již není obhajitelnou pozicí pro žádnou organizaci provozující Exchange – ať už on-premises, hybridní nebo jinak.