Sikkerhed i Outlook Web App: Beskyt Exchange med MFA

Indledning

De fleste diskussioner om sikkerhed ved fjernadgang starter med VPN. Næsten ingen af dem starter med Outlook Web App, og det er en mærkelig mangel, når man tænker på, hvad OWA egentlig er: en login-formular til virksomhedens e-mail, der ligger på det åbne internet og kan nås fra enhver browser på enhver enhed, hvor som helst. Der er ingen VPN-klient, der skal konfigureres, ingen firewall-regel, der skal omgås, intet netværkssegment, der skal passeres – blot et felt til brugernavn, et felt til adgangskode og hvad Exchange-serveren nu beslutter at acceptere.

For en angriber er det så tæt på en direkte vej ind i en postkasse, som det overhovedet kan blive. Et kompromitteret OWA-login kræver ikke lateral bevægelse for at blive farligt – det er allerede farligt med det samme, fordi selve postkassen er målet. Kompromittering af virksomheds-e-mail kræver ikke malware, kræver ikke et exploit og udløser ikke de fleste af de detektionsværktøjer, der er udviklet til netværksindtrængninger. Det kræver ét sæt gyldige legitimationsoplysninger og en login-side, der ikke beder om noget andet.

Hvorfor On-Prem og Hybrid Exchange ikke får MFA gratis

Forvirringen her er forståelig, fordi Microsoft 365-kunder, der bruger Exchange Online, rent faktisk får stærk autentificering næsten automatisk – Entra ID-politikker for betinget adgang kan kræve MFA på identitetslaget, før der overhovedet udstedes et sessionstoken, og den beskyttelse gælder også for Outlook på nettet uden nogen Exchange-specifik konfiguration. Sikkerhedsteams, der kun har arbejdet i et rent cloud-miljø, antager med god grund, at MFA til webmail er sådan, Exchange fungerer.

On-premises og hybrid Exchange arver ikke denne adfærd. Exchange Servers egen godkendelsesstack – rollen »Client Access Services«, der håndterer OWA og Exchange Admin Center – validerer et brugernavn og en adgangskode mod Active Directory, og uden yderligere konfiguration er det hele godkendelsesbeslutningen. Der er ingen indbygget anden faktor i OWA-login på egne servere. Hybride installationer komplicerer dette yderligere: Nogle postkasser er muligvis allerede flyttet til Exchange Online og omfattet af betinget adgang, mens andre forbliver på egne servere og muligvis stadig er afhængige af Exchange Servers egen godkendelsesvej, medmindre Hybrid Modern Authentication eller en anden MFA-løsning er blevet eksplicit konfigureret. Det er fuldt ud muligt, at en organisation tror, at dens e-mail er »beskyttet af MFA«, fordi det er tilfældet for lejer, mens en betydelig del af postkasserne stadig er beskyttet af OWA på stedet, der kun kræver en adgangskode.

Det er denne kløft, der har betydning i den daglige drift – ikke fordi Exchange på egne servere i sig selv er mindre sikker i sin udformning, men fordi den lægger ansvaret for at tilføje en anden godkendelsesfaktor helt og holdent på Exchange-administratoren, uden at der er en standardindstilling at falde tilbage på.

Hvad en kompromitteret OWA- eller EAC-konto faktisk giver en angriber

Værdien af et enkelt OWA-adgangskode er let at undervurdere, hvis man betragter det som "bare e-mail". I praksis er en kompromitteret postkassekonto et fodfæste, hvorfra flere forskellige angrebsveje forgrener sig.

Business Email Compromise (BEC) er den mest direkte økonomiske trussel.

Business Email Compromise (BEC) er den mest direkte økonomiske trussel. FBI’s Internet Crime Complaint Center registrerede i 2025 anmeldte BEC-tab på 3,046 milliarder dollars i USA – den næsthøjeste tabskategori efter investeringssvindel – fordelt på cirka 24.768 klager – et gennemsnitligt tab på over 120.000 dollars pr. bekræftet hændelse. BEC-angreb involverer typisk hverken malware eller ondsindede links, som et sikkerhedsfilter kan opfange; angriberen befinder sig inde i en legitim mailboks, sender fra en legitim adresse og svarer ofte i en eksisterende tråd med et ændret bankkontonummer eller en omdirigeret faktura. Regler for e-mail-flow gør teknikken sværere at opdage efterfølgende – en angriber med adgang til postkassen kan oprette en regel i indbakken, der i al hemmelighed videresender eller sletter meddelelser, der indeholder ord som »faktura«, »overførsel« eller »betaling«, hvilket holder kompromitteringen usynlig for kontoejeren, mens den svigagtige korrespondance fortsætter sideløbende.

Adgang via fuldmagt forstærker risikoen.

Delegeret adgang forværrer risikoen. Ledelsesassistenter og medlemmer af økonomiteamet har ofte delegerede eller »send som«-rettigheder til ledernes postkasser som en del af det normale arbejdsforløb, hvilket betyder, at en enkelt kompromitteret assistentkonto kan bruges til at sende meddelelser, der ser ud til at stamme direkte fra en økonomidirektør eller administrerende direktør, uden nogensinde at røre ved den pågældende leders egne loginoplysninger.

Dataeksponering er den mere diskrete risiko

Dataeksponering er den mere diskrete risiko og ofte den med de største konsekvenser for regulerede organisationer. En postkasse akkumulerer års vedhæftede filer, interne notater, HR-korrespondance og kundekommunikation, alt sammen tilgængeligt via OWA’s egen grænseflade, så snart en angriber er godkendt – der kræves ingen separate værktøjer til dataeksfiltrering, da angriberen kan få adgang til og downloade indholdet af postkassen ved hjælp af legitim OWA-funktionalitet.

Tilgang 1: MFA anvendt direkte på OWA- og EAC-login

Den mest målrettede løsning adresserer det specifikke risikoområde uden at berøre noget andet, der er forbundet med Active Directory. MFA til Outlook Web App og Exchange Admin Center installeres som en komponent i Exchange Client Access-tjenesterollen og placeres foran de eksisterende OWA- og EAC-login-sider i stedet for at erstatte Exchanges godkendelsesmekanisme fuldstændigt. Når den er installeret, autentificerer brugerne sig først med deres normale AD-brugernavn og -adgangskode og gennemfører derefter et andet autentificeringstrin – for eksempel ved at indtaste en engangskode (OTP) fra en autentificeringsapp eller et hardwaretoken eller ved at godkende en push-besked – før sessionen godkendes.

Omfanget fastlægges via medlemskab af Active Directory-grupper ved installationen: En administrator kan straks kræve MFA for hele brugergruppen eller indstille det i første omgang til en enkelt AD-gruppe – en pilotgruppe eller specifikt den gruppe, der har adgang til Exchange Admin Center – mens den bredere udrulning planlægges. Denne skelnen har betydning i praksis, fordi EAC-konti udgør en betydeligt større organisatorisk risiko end en individuel postkasse; en administratorkonto med adgang til EAC kan oprette regler for mailflow, ændre tilladelser eller eksportere data på tværs af hele Exchange-miljøet, hvilket netop er grunden til, at beskyttelse af EAC-login ofte prioriteres, selv når den fulde udrulning til alle brugere tager længere tid.

Sessionens adfærd kan konfigureres og er ikke fastlagt. Administratorer indstiller, hvor ofte brugerne bliver bedt om en ny engangskode – for eksempel en gang hver 12. time ved kontinuerlig brug af OWA – og afvejer dermed ulejligheden ved gentagen godkendelse mod risikoen ved en langvarig, uovervåget session på en delt eller uadministreret enhed. Komponenten understøtter HOTP, TOTP og challenge-response-metoden OCRA, hvilket giver fleksibilitet for organisationer, der bruger forskellige typer OTP-tokens.

Tilgang 2: MFA på Active Directory-niveau, der dækker OWA sammen med alt andet

Et mere afgrænset spørgsmål, der er værd at stille, inden den OWA-specifikke komponent implementeres: Er OWA faktisk den eneste AD-forbundne tjeneste, der stadig autentificerer udelukkende via adgangskode? For de fleste on-prem-miljøer er det ærlige svar nej — Winlogon, RDP og ofte interne LDAP-bundne applikationer befinder sig i samme situation, beskyttet af intet ud over den adgangskodepolitik, som AD håndhæver.

Multifaktorautentificering på katalogniveau imødegår denne bredere sårbarhed ved at integrere i selve Active Directory i stedet for på hver enkelt tjenestes login-side. I stedet for en række separate MFA-implementeringer – én komponent til OWA, en anden agent til RDP, en RADIUS-proxy til VPN, som hver især skal installeres, konfigureres og vedligeholdes uafhængigt – ændrer en integration på katalogniveau den måde, brugeroplysningerne fungerer på i Active Directory ved at erstatte statiske adgangskoder med tidsbaserede dynamiske adgangskoder, så AD-forbundne tjenester kan bruge de samme dynamiske adgangskoder uden behov for separate MFA-komponenter til hver enkelt tjeneste. OWA er omfattet, ikke fordi den specifikt var målet, men fordi den, ligesom alt andet, der peger mod AD, nu skal opfylde den samme dynamiske legitimationskontrol.

Afvejningen går i den modsatte retning af tilgang 1: bredere dækning til gengæld for en mere vidtrækkende ændring af, hvordan AD-godkendelse fungerer på tværs af miljøet, hvilket typisk kræver mere omhyggelig testning og en trinvis implementering end en OWA-komponent, der kun omfatter én tjeneste. Det rigtige valg mellem de to afhænger reelt af omfanget — en organisation, hvis eneste ubeskyttede AD-forbundne overflade er OWA, behøver ikke at røre ved kataloget for at løse det; en organisation, der opdager, at OWA, RDP og Winlogon alle kører på autentificering udelukkende via adgangskode, har et bredere problem, som en løsning for en enkelt tjeneste ikke vil løse.

Sådan fungerer mekanismen på katalogniveau uden endpoint-agenter

Mekanismen bag MFA på katalogniveau er værd at forstå i sig selv, fordi den forklarer, hvorfor den når ud til alle AD-forbundne tjenester uden at installere noget på de enkelte arbejdsstationer eller servere.

Dynamisk stærk adgangskodegodkendelse fungerer ved at ændre den adgangskode, der er gemt i selve Active Directory, i stedet for at opfange godkendelsestrafikken ved hver enkelt endepunkt. En brugers statiske adgangskode erstattes med en roterende, TOTP-baseret dynamisk adgangskode, der skifter automatisk med et interval, der er konfigureret af en administrator – en værdi, der skal være et multiplum af 30 sekunder. Den aktuelle dynamiske adgangskode genereres ved hjælp af TOTP-algoritmen og er tilgængelig for brugeren via Protectimus SMART-appen eller en understøttet chatbot. Da ændringen sker direkte i kataloget, bruger enhver klient eller tjeneste, der autentificerer mod AD – Winlogon, RDP, OWA, LDAP-bundne applikationer – automatisk den aktuelle dynamiske adgangskode, uden at den pågældende tjeneste behøver at vide, at noget er ændret.

Det er netop dette, der gør tilgangen agentløs i den forstand, der betyder noget: Der kører ingen software på den bærbare computer, RDP-værten eller Exchange Client Access-serveren, der kontrollerer for en anden faktor. Selve kataloget er håndhævelsespunktet. Den tilsvarende ulempe er, at denne komponent kører som en del af en lokal installation i stedet for en ren cloud-tjeneste, da den kræver direkte integration med domænecontrolleren.

Valg af omfang: Kun webmail eller hele AD-miljøet

Begge tilgange løser det underliggende problem – en adgangskode alene er ikke længere tilstrækkelig til at autentificere – men de løser det på forskellige niveauer i stakken, og det rigtige valg afhænger af en ærlig statusopgørelse snarere end en standardpræference.

Hvis OWA og EAC virkelig er de eneste tjenester, der stadig autentificerer mod AD med intet andet end en adgangskode – VPN er allerede dækket via RADIUS, RDP er allerede låst ned, og ingen andre ældre applikationer stoler i al hemmelighed på AD-legitimationsoplysninger – lukker den målrettede OWA-komponent netop dette specifikke hul med minimal forstyrrelse af alt andet, der kører mod kataloget. Hvis inventarundersøgelsen afslører mere end én udsat tjeneste – hvilket er det mest almindelige fund, når it-teams først begynder at lede – lukker MFA på katalogniveau dem alle fra ét enkelt integrationspunkt i stedet for at anskaffe et separat MFA-produkt til hver enkelt.

Uanset hvad peger FBI’s tal for tab som følge af BEC på den samme underliggende kendsgerning: En login-metode, der udelukkende bygger på en adgangskode, til en virksomheds e-mail-postkasse, der befinder sig på det åbne internet, er ikke længere en forsvarlig løsning for nogen organisation, der kører Exchange – uanset om det er on-premises, hybrid eller på anden måde.