Säkerhet i Outlook Web App: Skydda Exchange med MFA

Inledning

De flesta diskussioner om säkerhet vid fjärråtkomst börjar med VPN. Nästan ingen av dem börjar med Outlook Web App, och det är en märklig lucka med tanke på vad OWA egentligen är: ett inloggningsformulär för företagets e-post, som finns på det öppna internet och kan nås från vilken webbläsare som helst på vilken enhet som helst, var som helst. Det finns ingen VPN-klient att konfigurera, inga brandväggsregler att kringgå, inga nätverkssegment att ta sig igenom – bara ett fält för användarnamn, ett fält för lösenord och vad Exchange-servern än väljer att acceptera.

För en angripare är det så nära en rak väg in i en e-postlåda som det går att komma. En komprometterad OWA-inloggning behöver inte någon lateral rörelse för att bli farlig – den är redan farlig, omedelbart, eftersom själva e-postkontot är målet. Business Email Compromise behöver varken skadlig kod eller någon sårbarhet, och utlöser inte de flesta av de detekteringsverktyg som är utvecklade för nätverksintrång. Det krävs bara en uppsättning giltiga inloggningsuppgifter och en inloggningssida som inte begär något annat.

Varför lokalt installerad och hybrid Exchange inte får MFA gratis

Förvirringen här är förståelig, eftersom Microsoft 365-kunder som använder Exchange Online faktiskt får stark autentisering nästan automatiskt – Entra ID:s policyer för villkorad åtkomst kan kräva MFA på identitetsnivån innan ett sessionstoken överhuvudtaget utfärdas, och det skyddet sträcker sig till Outlook på webben utan någon Exchange-specifik konfiguration. Säkerhetsteam som bara har arbetat i en ren molnmiljö antar rimligen att MFA för webbmail är precis så som Exchange fungerar.

Lokalt installerad och hybrid Exchange ärver inte det beteendet. Exchange Servers egen autentiseringsstack – rollen Client Access Services som hanterar OWA och Exchange Admin Center – validerar ett användarnamn och lösenord mot Active Directory, och utan ytterligare konfiguration är det hela autentiseringsbeslutet. Det finns ingen inbyggd andra faktor i inloggningen till OWA på plats. Hybridinstallationer komplicerar detta ytterligare: vissa postlådor kan redan ha flyttats till Exchange Online och omfattas av villkorad åtkomst, medan andra finns kvar på plats och fortfarande kan förlita sig på Exchange Servers egen autentiseringsväg, såvida inte Hybrid Modern Authentication eller en annan MFA-lösning uttryckligen har konfigurerats. Det är fullt möjligt att en organisation tror att dess e-post är ”skyddad av MFA” eftersom det stämmer för hyresgästen, medan en betydande del av postlådorna fortfarande ligger bakom lokal OWA som endast kräver lösenord.

Det är denna lucka som är av betydelse ur ett driftsperspektiv, inte för att Exchange på plats i sig är mindre säker till sin utformning, utan för att den lägger ansvaret för att lägga till en andra autentiseringsfaktor helt och hållet på Exchange-administratören, utan någon standardinställning att falla tillbaka på.

Vad ett komprometterat OWA- eller EAC-konto faktiskt ger en angripare

Värdet av en enda OWA-inloggning är lätt att underskatta om man betraktar den som ”bara e-post”. I praktiken är ett komprometterat postlådekonto en fotfäste med flera olika attackvägar som utgår från det.

Business Email Compromise (BEC) är den mest direkt ekonomiskt skadliga typen.

Business Email Compromise (BEC) är den mest direkt ekonomiskt skadliga. FBI:s Internet Crime Complaint Center registrerade 3,046 miljarder dollar i rapporterade BEC-förluster i USA år 2025, den näst högsta förlustkategorin efter investeringsbedrägerier, fördelat på ungefär 24 768 anmälningar – en genomsnittlig förlust på över 120 000 dollar per bekräftad incident. BEC-attacker kännetecknas av att de inte involverar någon skadlig programvara eller någon skadlig länk som ett säkerhetsfilter kan upptäcka; angriparen befinner sig inuti en legitim e-postlåda, skickar från en legitim adress och svarar ofta i en befintlig tråd med ett ändrat bankkontonummer eller en omdirigerad faktura. Regler för e-postflödet gör tekniken svårare att upptäcka i efterhand – en angripare med åtkomst till e-postkontot kan skapa en regel i inkorgen som i det tysta vidarebefordrar eller raderar meddelanden som innehåller ord som ”faktura”, ”överföring” eller ”betalning”, vilket gör att intrånget förblir osynligt för kontoägaren medan den bedrägliga konversationen fortsätter parallellt.

Delegering av åtkomst förvärrar risken.

Delegerad åtkomst förvärrar risken. Chefsassistenter och medlemmar i ekonomiavdelningen har ofta delegerade behörigheter eller ”skicka som”-behörigheter till ledande befattningshavares e-postkonton som en del av det normala arbetsflödet, vilket innebär att ett enda komprometterat assistentkonto kan användas för att skicka meddelanden som verkar komma direkt från en ekonomichef eller VD utan att någonsin röra den ledande befattningshavarens egna inloggningsuppgifter.

Dataexponering är den mer dolda risken

Dataexponering är den mer dolda risken, och ofta den som får störst konsekvenser för reglerade organisationer. En e-postlåda ackumulerar år av bilagor, interna memon, HR-korrespondens och kundkommunikation, allt tillgängligt via OWA:s eget gränssnitt så snart en angripare har autentiserats – inga separata verktyg för dataexfiltrering krävs, eftersom angriparen kan komma åt och ladda ner innehållet i e-postlådan med hjälp av OWA:s legitima funktioner.

Metod 1: MFA tillämpas direkt på inloggningen till OWA och EAC

Den mest målinriktade lösningen hanterar just den specifika utsatta ytan utan att påverka något annat som är kopplat till Active Directory. MFA för Outlook Web App och Exchange Admin Center installeras som en komponent i rollen Exchange Client Access Services och placeras framför de befintliga inloggningssidorna för OWA och EAC, istället för att helt ersätta Exchanges autentiseringsmekanism. När den väl är installerad autentiserar sig användarna först med sitt vanliga AD-användarnamn och lösenord, och genomför sedan ett andra autentiseringssteg – till exempel genom att ange en engångskod (OTP) från en autentiseringsapp eller en hårdvarutoken, eller genom att godkänna en push-notis – innan sessionen beviljas.

Omfattningen ställs in genom medlemskap i Active Directory-grupper vid installationstillfället: en administratör kan kräva MFA för hela användargruppen omedelbart, eller inledningsvis aktivera det för en enskild AD-grupp – en pilotgrupp, eller specifikt den grupp som har åtkomst till Exchange Admin Center – medan en bredare utrullning planeras. Denna distinktion är viktig i praktiken, eftersom EAC-konton medför betydligt större organisatorisk risk än en enskild postlåda; ett administratörskonto med åtkomst till EAC kan skapa regler för e-postflödet, ändra behörigheter eller exportera data i hela Exchange-miljön, vilket är precis anledningen till att skyddet av EAC-inloggningar ofta prioriteras även när den fullständiga utrullningen till alla användare tar längre tid.

Sessionsbeteendet är konfigurerbart snarare än fastställt. Administratörer ställer in hur ofta användarna ombeds ange en ny engångskod – till exempel en gång var 12:e timme vid kontinuerlig användning av OWA – och balanserar därmed besväret med upprepad autentisering mot risken för en långvarig, obevakad session på en delad eller ohanterad enhet. Komponenten stöder HOTP, TOTP och utmaning-svar-metoden OCRA, vilket ger flexibilitet för organisationer som använder olika typer av OTP-tokens.

Metod 2: MFA på Active Directory-nivå, som omfattar OWA tillsammans med allt annat

En mer avgränsad fråga som är värd att ställa innan den OWA-specifika komponenten driftsätts: är OWA verkligen den enda AD-anslutna tjänsten som fortfarande autentiserar enbart med lösenord? För de flesta lokala miljöer är det ärliga svaret nej – Winlogon, RDP och ofta interna LDAP-bundna applikationer befinner sig i samma situation, skyddade av ingenting utöver den lösenordspolicy som AD tillämpar.

Multifaktorautentisering på katalognivå hanterar den bredare exponeringen genom att integreras i själva Active Directory snarare än på varje enskild tjänsts inloggningssida. I stället för en rad separata MFA-implementeringar – en komponent för OWA, en annan agent för RDP, en RADIUS-proxy för VPN, var och en installerad, konfigurerad och underhållen separat – förändrar en integration på katalognivå hur användaruppgifterna fungerar i Active Directory genom att ersätta statiska lösenord med tidsbaserade dynamiska lösenord, så att AD-anslutna tjänster kan använda samma dynamiska inloggningsuppgifter utan att behöva separata MFA-komponenter för varje tjänst. OWA omfattas inte för att det specifikt var målet, utan för att det, precis som allt annat som pekar mot AD, nu måste uppfylla samma kontroll av dynamiska inloggningsuppgifter.

Avvägningen går i motsatt riktning jämfört med tillvägagångssätt 1: bredare täckning i utbyte mot en mer genomgripande förändring av hur AD-autentisering fungerar i hela miljön, vilket vanligtvis kräver mer noggranna tester och en stegvis implementering än vad en OWA-komponent för en enskild tjänst gör. Vilket av de två alternativen som är rätt beror verkligen på omfattningen – en organisation vars enda oskyddade yta ansluten till AD är OWA behöver inte röra katalogen för att åtgärda det; en organisation som upptäcker att OWA, RDP och Winlogon alla använder autentisering enbart med lösenord har ett bredare problem som inte kan lösas med en åtgärd för en enskild tjänst.

Hur mekanismen på katalognivå fungerar utan agenter på slutpunkterna

Mekanismen bakom MFA på katalognivå är värd att förstå i sig själv, eftersom den förklarar varför den når alla AD-anslutna tjänster utan att installera något på enskilda arbetsstationer eller servrar.

Dynamisk stark lösenordsautentisering fungerar genom att modifiera det lösenord som lagras i själva Active Directory, snarare än att avlyssna autentiseringstrafiken vid varje slutpunkt. En användares statiska lösenord ersätts med ett roterande, TOTP-baserat dynamiskt lösenord som ändras automatiskt med ett intervall som konfigureras av administratören – ett värde som måste vara en multipel av 30 sekunder. Det aktuella dynamiska lösenordet genereras med hjälp av TOTP-algoritmen och är tillgängligt för användaren via Protectimus SMART-appen eller en stödd chatbot. Eftersom ändringen sker direkt i katalogen använder alla klienter eller tjänster som autentiserar sig mot AD – Winlogon, RDP, OWA, LDAP-bundna applikationer – automatiskt det aktuella dynamiska lösenordet, utan att tjänsten behöver veta att något har ändrats.

Det är detta som gör metoden agentlös i den avgörande bemärkelsen: det finns ingen programvara som körs på den bärbara datorn, RDP-värden eller Exchange Client Access-servern som kontrollerar efter en andra faktor. Katalogen i sig är den punkt där kontrollen sker. Den motsvarande avvägningen är att denna komponent körs som en del av en lokal installation snarare än en ren molntjänst, eftersom den kräver direkt integration med domänkontrollanten.

Att välja omfattning: endast webbmail eller hela AD-miljön

Båda metoderna löser det underliggande problemet – ett lösenord i sig räcker inte längre för att autentisera – men de löser det på olika nivåer i systemstacken, och det rätta valet handlar om en ärlig inventering snarare än en förutbestämd preferens.

Om OWA och EAC verkligen är de enda tjänsterna som fortfarande autentiserar mot AD med enbart ett lösenord – VPN täcks redan via RADIUS, RDP är redan låst, inga andra äldre applikationer litar i det tysta på AD-autentiseringsuppgifter – täcker den riktade OWA-komponenten just den specifika luckan med minimal störning för allt annat som körs mot katalogen. Om inventeringen visar att det finns mer än en utsatt tjänst – vilket är det vanligaste resultatet när IT-team faktiskt börjar leta – stänger MFA på katalognivå alla dessa från en enda integrationspunkt istället för att man måste skaffa en separat MFA-produkt för var och en.

Hur som helst pekar FBI:s siffror över BEC-förluster på samma underliggande faktum: en inloggning med enbart lösenord till en företags-e-postlåda, som finns på det öppna internet, är inte längre en hållbar lösning för någon organisation som kör Exchange – vare sig det är lokalt, i hybridform eller på annat sätt.