„Outlook Web App“ drošība: Exchange aizsardzība ar daudzpakāpju autentifikāciju (MFA)

Ievads

Lielākā daļa sarunu par attālās piekļuves drošību sākas ar VPN. Gandrīz neviena no tām nesākas ar Outlook Web App, un tas ir dīvains trūkums, ņemot vērā to, kas OWA patiesībā ir: pieteikšanās forma uzņēmuma e-pastam, kas atrodas atklātā internetā un ir pieejama no jebkuras pārlūkas jebkurā ierīcē jebkurā vietā. Nav jākonfigurē nekāds VPN klients, nav jāapiet nekādi ugunsmūra noteikumi, nav jāšķērso nekādi tīkla segmenti — tikai lietotājvārda lauks, paroles lauks un viss, ko Exchange serveris nolemj pieņemt.

Uzbrucējam tas ir gandrīz kā taisna līnija uz pastkastīti. Kompromitēta OWA pieteikšanās nav jāveic sānu pārvietošanās, lai kļūtu bīstama — tā jau ir bīstama uzreiz, jo pats pastkastītes konts ir mērķis. Uzņēmuma e-pasta kompromitēšanai nav vajadzīga ļaunprogrammatūra, nav vajadzīgs ekspluatācijas kods, un tā neizraisa lielāko daļu no tīkla iebrukumu atklāšanas rīkiem. Tai ir vajadzīgs viens derīgu autentifikācijas datu komplekts un pieteikšanās lapa, kas neprasa neko citu.

Kāpēc lokālajai un hibrīdajai Exchange versijai MFA netiek nodrošināta bez maksas

Šī neskaidrība ir saprotama, jo Microsoft 365 lietotāji, kas izmanto Exchange Online, patiešām gūst spēcīgu autentifikāciju gandrīz automātiski — Entra ID nosacītās piekļuves politikas var pieprasīt MFA identitātes līmenī, pirms tiek izsniegts sesijas žetons, un šī aizsardzība attiecas arī uz Outlook tīmeklī bez jebkādas Exchange-specifiskas konfigurācijas. Drošības komandas, kas vienmēr ir strādājušas tikai tīrā mākoņa vidē, pamatoti pieņem, ka MFA tīmekļa pastam ir vienkārši Exchange darbības veids.

Lokālajam un hibrīda tipa Exchange šāda darbība nav raksturīga. Exchange Servera paša autentifikācijas slānis — klientu piekļuves pakalpojumu loma, kas apkalpo OWA un Exchange administrācijas centru — pārbauda lietotājvārdu un paroli, salīdzinot ar Active Directory, un, ja nav veikta papildu konfigurācija, tas ir viss autentifikācijas lēmums. Lokālajā OWA pieteikšanās procesā nav iebūvēts otrs autentifikācijas faktors. Hibrīdās ieviešanas situācijas to vēl vairāk sarežģī: daži pastkastītes var būt jau pārvietotas uz „Exchange Online” un uz tām attiecas nosacītā piekļuve, kamēr citas paliek lokālajā vidē un joprojām var paļauties uz „Exchange Server” paša autentifikācijas ceļu, ja vien nav skaidri konfigurēta hibrīdā modernā autentifikācija vai cits MFA risinājums. Ir pilnīgi iespējams, ka organizācija uzskata, ka tās e-pasts ir „aizsargāts ar MFA”, jo tas attiecas uz nomnieku, kamēr nozīmīga pastkastu daļa joprojām atrodas aiz lokālās OWA sistēmas, kurā tiek izmantota tikai parole.

Šī ir plaisa, kas ir nozīmīga darbības ziņā, nevis tāpēc, ka uz vietas esošais „Exchange” pēc savas būtības būtu mazāk drošs, bet tāpēc, ka tā pilnībā uzliek atbildību par otrā autentifikācijas faktora pievienošanu „Exchange” administratoram, nepiedāvājot nekādu noklusējuma risinājumu, uz kuru varētu paļauties.

Ko uzbrucējam faktiski sniedz kompromitēts OWA vai EAC konts

Vienas OWA autentifikācijas datu vērtību ir viegli novērtēt par zemu, ja to uztver kā „vienkārši e-pastu”. Praksē kompromitēts pastkastes konts ir atspēriena punkts, no kura atzarojas vairāki atšķirīgi uzbrukuma ceļi.

Uzņēmuma e-pasta kompromitēšana (BEC) ir finansiāli visvairāk tieša.

Uzņēmuma e-pasta kompromitēšana (BEC) ir finansiāli visvairāk tiešais uzbrukums. FBI Interneta noziegumu sūdzību centrs 2025. gadā reģistrēja 3,046 miljardus ASV dolāru ziņoto BEC zaudējumu apmēru ASV — otrā lielākā zaudējumu kategorija aiz ieguldījumu krāpšanas, kas sadalījās aptuveni 24 768 sūdzībās — vidējie zaudējumi pārsniedza 120 000 ASV dolāru par katru apstiprināto incidentu. BEC uzbrukumiem raksturīgi nav iesaistīta ļaunprogrammatūra vai ļaunprātīgas saites, ko drošības filtrs varētu pārtvert; uzbrucējs atrodas likumīgā e-pasta pastkastē, sūta ziņojumus no likumīgas adreses un bieži atbild esošajā sarakstē, norādot mainītu bankas maršrutēšanas numuru vai pāradresētu rēķinu. E-pasta plūsmas noteikumi padara šo paņēmienu grūtāk atklājamu pēc notikuma — uzbrucējs, kam ir piekļuve pastkastītei, var izveidot ienākošo ziņojumu noteikumu, kas nemanāmi pārsūta vai dzēš ziņojumus, kuros ir vārdi kā “rēķins”, “pārskaitījums” vai “maksājums”, tādējādi saglabājot uzbrukumu neredzamu konta īpašniekam, kamēr krāpnieciskā sarakste turpinās paralēli.

Pilnvarotā piekļuve vēl vairāk palielina risku.

Pilnvarotā piekļuve vēl vairāk palielina risku. Vadītāju asistentiem un finanšu komandas locekļiem bieži vien kā daļa no parastā darba plūsmas ir piešķirtas pilnvarotā vai „sūtīt kā” atļaujas vadītāju pastkastēm, kas nozīmē, ka vienu kompromitētu asistenta kontu var izmantot, lai sūtītu ziņojumus, kas šķiet nākuši tieši no finanšu direktora vai izpilddirektora, nemaz neizmantojot paša vadītāja autentifikācijas datus.

Datu noplūde ir klusāks risks

Datu noplūde ir klusāks risks un bieži vien nozīmīgāks regulētajām organizācijām. Pastkastē gadu gaitā uzkrājas pielikumi, iekšējie memi, personāla sarakste un saziņa ar klientiem, un viss tas kļūst pieejams caur pašu OWA saskarni, tiklīdz uzbrucējs ir autentificējies — nav nepieciešami atsevišķi datu eksfiltrācijas rīki, jo uzbrucējs var piekļūt pastkastes saturam un to lejupielādēt, izmantojot likumīgas OWA funkcijas.

1. pieeja: MFA piemērošana tieši OWA un EAC pieteikšanās procesam

Vismērķtiecīgākais risinājums novērš konkrēto riska zonu, neietekmējot neko citu, kas saistīts ar Active Directory. MFA Outlook Web App un Exchange Admin Center tiek instalēta kā komponents Exchange Client Access pakalpojumu lomā, atrodoties priekšā esošajām OWA un EAC pieteikšanās lapām, nevis pilnībā aizstājot Exchange autentifikācijas mehānismu. Pēc instalēšanas lietotāji vispirms autentificējas ar savu parasto AD lietotājvārdu un paroli, pēc tam veic otro autentifikācijas soli — piemēram, ievadot vienreizējo paroli (OTP) no autentifikatora lietotnes vai aparatūras žetona, vai apstiprinot push paziņojumu — pirms sesija tiek atļauta.

Darbības joma tiek noteikta, izmantojot Active Directory grupas piederību instalēšanas brīdī: administrators var nekavējoties pieprasīt MFA visiem lietotājiem vai sākotnēji to aktivizēt vienai AD grupai — izmēģinājuma grupai vai konkrēti grupai, kurai ir piekļuve Exchange administrācijas centram —, kamēr tiek plānota plašāka ieviešana. Šī atšķirība praksē ir nozīmīga, jo EAC kontiem ir ievērojami lielāks organizācijas risks nekā atsevišķai pastkastītei; administratora konts ar piekļuvi EAC var izveidot pasta plūsmas noteikumus, mainīt atļaujas vai eksportēt datus visā Exchange vidē, un tieši tāpēc EAC pieteikšanās aizsardzība parasti ir prioritāte, pat ja pilnīga ieviešana visiem lietotājiem aizņem vairāk laika.

Sesijas darbība ir konfigurējama, nevis fiksēta. Administratori nosaka, cik bieži lietotājiem tiek atkārtoti pieprasīts jauns OTP — piemēram, reizi 12 stundās, nepārtraukti lietojot OWA — līdzsvarojot atkārtotas autentifikācijas neērtības ar risku, ka koplietotā vai nepārvaldītā ierīcē paliks ilgstoša, bez uzraudzības atstāta sesija. Komponents atbalsta HOTP, TOTP un izaicinājuma-atbildes OCRA, nodrošinot elastīgumu organizācijām, kas izmanto dažāda veida OTP žetonus.

2. pieeja: MFA „Active Directory” līmenī, aptverot gan OWA, gan visu pārējo

Pirms OWA-specifiskās komponentes ieviešanas ir vērts uzdot šaurāku jautājumu: vai OWA patiešām ir vienīgais ar AD saistītais pakalpojums, kas joprojām autentificējas, izmantojot tikai paroli? Lielākajā daļā lokālo vidu godīgā atbilde ir „nē” — Winlogon, RDP un bieži vien arī iekšējās LDAP-saistītās lietojumprogrammas atrodas tajā pašā situācijā, un tās neaizsargā nekas cits kā vien AD piemērotā paroles politika.

Daudzfaktoru autentifikācija direktorija līmenī novērš šo plašāko neaizsargātību, integrējoties pašā Active Directory, nevis katra atsevišķā pakalpojuma pieteikšanās lapā. Tā vietā, lai veiktu virkni atsevišķu MFA ieviešanu — vienu komponentu OWA, citu aģentu RDP, RADIUS starpniekserveri VPN, katru no tiem neatkarīgi instalējot, konfigurējot un uzturot —, integrācija direktorija līmenī maina to, kā lietotāju autentifikācijas dati darbojas Active Directory, aizstājot statiskos parolus ar laika balstītiem dinamiskajiem parolēm, tādējādi AD savienotie pakalpojumi var izmantot tos pašus dinamiskos autentifikācijas datus, nepieprasot atsevišķus MFA komponentus katram pakalpojumam. OWA tiek iekļauts nevis tāpēc, ka tas tika īpaši izvēlēts, bet tāpēc, ka tam, tāpat kā visam pārējam, kas vērsts uz AD, tagad ir jāizpilda tā pati dinamiskā autentifikācijas datu pārbaude.

Šis kompromiss darbojas pretējā virzienā nekā 1. pieeja: plašāks segums apmaiņā pret plašākas ietekmes izmaiņām AD autentifikācijas darbībā visā vidē, kas parasti prasa apdomīgāku testēšanu un pakāpenisku ieviešanu nekā vienpakalpojuma OWA komponente. Pareizā izvēle starp abām pieejām patiesi ir atkarīga no darbības jomas — organizācijai, kuras vienīgā neaizsargātā ar AD saistītā virsma ir OWA, nav nepieciešams iejaukties direktorijā, lai to labotu; organizācijai, kas atklāj, ka OWA, RDP un Winlogon visi izmanto autentifikāciju tikai ar paroli, ir plašāka problēma, ko nevar atrisināt ar viena pakalpojuma labojumu.

Kā darbojas direktorija līmeņa mehānisms bez galapunktu aģentiem

Ir vērts izprast kataloga līmeņa MFA mehānismu tā pašā būtībā, jo tas izskaidro, kāpēc tas aptver katru ar AD savienoto pakalpojumu, neinstalējot neko atsevišķās darbstacijās vai serveros.

Dinamiskā stiprā paroles autentifikācija darbojas, modificējot pašu Active Directory uzglabāto paroli, nevis pārtverot autentifikācijas datplūsmu katrā galapunktā. Lietotāja statiskā parole tiek aizstāta ar mainīgu, uz TOTP balstītu dinamisko paroli, kas automātiski mainās pēc administratora konfigurētā intervāla — šai vērtībai jābūt 30 sekunžu daudzkārtnim. Pašreizējā dinamiskā parole tiek ģenerēta, izmantojot TOTP algoritmu, un lietotājam tā ir pieejama caur Protectimus SMART lietotni vai atbalstītu čatbotu. Tā kā izmaiņas notiek tieši direktorijā, jebkurš klients vai pakalpojums, kas autentificējas pret AD — Winlogon, RDP, OWA, ar LDAP saistītas lietojumprogrammas — automātiski izmanto pašreizējo dinamisko paroli, un šim pakalpojumam nav nepieciešams zināt, ka kaut kas ir mainījies.

Tieši tas padara šo pieeju bezagenta nozīmīgajā izpratnē: ne uz klēpjdatora, ne RDP uzņēmējā, ne arī Exchange klienta piekļuves serverī nedarbojas programmatūra, kas pārbaudītu otro autentifikācijas faktoru. Pats katalogs ir izpildes punkts. Attiecīgais kompromiss ir tas, ka šī sastāvdaļa darbojas kā daļa no uz vietas izvietojuma, nevis kā pakalpojums, kas pieejams tikai mākonī, jo tai ir nepieciešama tieša integrācija ar domēna kontrolieri.

Darbības jomas izvēle: tikai tīmekļa pasts vai visa AD vide

Abas pieejas atrisina pamatproblēmu — vairs nepietiek ar vienīgi paroli autentifikācijai —, taču tās to risina dažādos slāņos, un pareizā izvēle ir atkarīga no godīgas situācijas izvērtēšanas, nevis no standarta priekšroku.

Ja OWA un EAC patiešām ir vienīgie pakalpojumi, kas joprojām veic autentifikāciju pret AD, izmantojot tikai paroli — VPN jau ir nodrošināts ar RADIUS, RDP jau ir bloķēts, un nav citu novecojušu lietojumprogrammu, kas nemanāmi uzticētos AD autentifikācijas datiem —, tad mērķtiecīgā OWA komponente novērš šo konkrēto nepilnību, minimāli traucējot visu pārējo, kas darbojas saistībā ar direktoriju. Ja inventarizācijā atklājas vairāk nekā viens neaizsargāts pakalpojums — kas ir biežāk sastopama situācija, kad IT komandas sāk to meklēt —, MFA direktorija līmenī aizver tos visus no viena integrācijas punkta, nevis uzkrāj atsevišķu MFA produktu katram no tiem.

Jebkurā gadījumā FBI dati par BEC radītajiem zaudējumiem norāda uz to pašu pamatfaktu: pieteikšanās uzņēmuma e-pasta kastē, kas atrodas atklātā internetā, izmantojot tikai paroli, vairs nav aizstāvējama pozīcija nevienai organizācijai, kas izmanto Exchange — gan lokāli, gan hibrīdā vidē, gan citādi.