„Outlook Web App“ saugumas: „Exchange“ apsauga naudojant daugiafaktorių autentifikavimą (MFA)

Įvadas

Dauguma diskusijų apie nuotolinio prisijungimo saugumą prasideda nuo VPN. Beveik nė viena iš jų neprasideda nuo „Outlook Web App“ (OWA), o tai yra keista spraga, atsižvelgiant į tai, kas iš tiesų yra OWA: prisijungimo forma prie įmonės el. pašto, esanti atvirame internete, prieinama iš bet kurio naršyklės bet kuriame įrenginyje, bet kur. Nereikia konfigūruoti jokio VPN kliento, apeiti jokių ugniasienės taisyklių, pereiti per jokį tinklo segmentą – tik vartotojo vardo laukelis, slaptažodžio laukelis ir viskas, ką nusprendžia priimti „Exchange“ serveris.

Piktadariui tai yra beveik tiesioginis kelias į pašto dėžutę. Sukompromituotas OWA prisijungimas nereikalauja šoninio judėjimo, kad taptų pavojingas – jis jau yra pavojingas iš karto, nes pats pašto dėžutė yra tikslas. Verslo el. pašto kompromitavimui nereikia kenkėjiškų programų, nereikia pažeidžiamumo išnaudojimo ir jis neaktyvina daugumos aptikimo įrankių, sukurtų tinklo įsibrovimams aptikti. Jam reikia vieno galiojančių prisijungimo duomenų rinkinio ir prisijungimo puslapio, kuris neprašo nieko daugiau.

Kodėl „On-Prem“ ir hibridinė „Exchange“ versijos negauna MFA nemokamai

Ši painiava yra suprantama, nes „Microsoft 365“ nuomininkai, naudojantys „Exchange Online“, iš tiesų gauna stiprų autentifikavimą beveik automatiškai – „Entra ID“ sąlyginės prieigos taisyklės gali reikalauti daugiafaktoriaus autentifikavimo tapatybės lygmenyje dar prieš išduodant sesijos žetoną, o ši apsauga apima „Outlook“ žiniatinklyje be jokios specialios „Exchange“ konfigūracijos. Saugumo komandos, kurios visą laiką dirbo tik grynoje debesų aplinkoje, pagrįstai mano, kad daugiafaktoriaus autentifikavimas internetiniam paštui yra tiesiog įprastas „Exchange“ veikimo būdas.

Lokaliose ir hibridinėse „Exchange“ aplinkose šis elgesys neperimamas. „Exchange Server“ autentiškumo patvirtinimo sistema – „Client Access Services“ vaidmuo, tvarkantis OWA ir „Exchange Admin Center“ – patikrina vartotojo vardą ir slaptažodį pagal „Active Directory“, ir, jei nėra papildomų nustatymų, tai yra vienintelis autentiškumo patvirtinimo sprendimas. Į vietinį „OWA“ prisijungimą nėra įdiegtas joks integruotas antrasis autentifikavimo veiksnys. Hibridiniai diegimai dar labiau komplikuoja šią situaciją: kai kurios pašto dėžutės gali būti jau perkeltos į „Exchange Online“ ir apsaugotos sąlygine prieiga, o kitos lieka vietinėje aplinkoje ir vis dar gali remtis „Exchange Server“ nuosavu autentifikavimo procesu, nebent būtų aiškiai sukonfigūruotas „Hybrid Modern Authentication“ arba kitas MFA sprendimas. Gali visiškai atsitikti, kad organizacija manys, jog jos el. paštas yra „apsaugotas MFA“, nes tai tiesa nuomininko atžvilgiu, o reikšminga pašto dėžučių dalis vis dar veikia vietiniame OWA, kur naudojamas tik slaptažodis.

Tai yra spraga, kuri svarbi operaciniu požiūriu ne todėl, kad vietinis „Exchange“ iš esmės yra mažiau saugus dėl savo konstrukcijos, bet todėl, kad ji visą atsakomybę už antrojo autentifikavimo veiksnio pridėjimą perkelia tiesiai ant „Exchange“ administratoriaus pečių, be jokio numatytojo sprendimo, kuriuo būtų galima pasiremti.

Ką iš tikrųjų užpuolikas gauna, jei OWA arba EAC paskyra yra pažeista

Vieno OWA prisijungimo duomenų vertę lengva nuvertinti, jei apie juos galvojate kaip apie „tik elektroninį paštą“. Praktikoje įsilaužta pašto dėžutės paskyra yra atsparos taškas, iš kurio išsišakoja keli skirtingi atakos keliai.

Verslo el. pašto kompromitavimas (BEC) yra finansiškai tiesiogiausias.

Verslo el. pašto kompromitavimas (BEC) yra finansiškai tiesiogiausias. FTB Internetinių nusikaltimų skundų centras užregistravo 3,046 mlrd. JAV dolerių pranešimų apie BEC nuostolius Jungtinėse Valstijose 2025 m. – tai antra pagal dydį nuostolių kategorija po investicinių sukčiavimų, pasiskirsčiusi tarp maždaug 24 768 skundų – vidutinis nuostolis viršijo 120 000 JAV dolerių už kiekvieną patvirtintą incidentą. BEC atakoms būdinga tai, kad jose nenaudojama jokia kenkėjiška programinė įranga ir nėra jokių kenkėjiškų nuorodų, kurias galėtų užfiksuoti saugumo filtras; užpuolikas yra teisėtame pašto dėžutėje, siunčia laiškus iš teisėto adreso, dažnai atsakydamas esamoje pokalbių grandinėje, nurodydamas pakeistą banko maršruto numerį arba persiųstą sąskaitą. Pašto srauto taisyklės apsunkina šios technikos aptikimą po fakto – užpuolikas, turintis prieigą prie pašto dėžutės, gali sukurti įeinančių laiškų taisyklę, kuri tyliai persiunčia arba ištrina pranešimus, kuriuose yra žodžiai kaip „sąskaita“, „pervedimas“ ar „mokėjimas“, taip paslėpdamas įsilaužimą nuo paskyros savininko, o sukčiavimo pokalbis tuo metu tęsiasi lygiagrečiai.

Prieigos delegavimas dar labiau padidina pažeidžiamumą.

Prieigos delegavimas dar labiau padidina pažeidžiamumą. Vadovų asistentai ir finansų komandos nariai dažnai turi deleguotas arba „siųsti kaip“ teises vadovų pašto dėžutėse kaip įprastą darbo eigos dalį, o tai reiškia, kad viena pažeista asistento paskyra gali būti panaudota siųsti pranešimus, kurie atrodo esantys tiesiogiai iš finansų direktoriaus ar generalinio direktoriaus, net nepalietus to vadovo prisijungimo duomenų.

Duomenų paviešinimas yra tylesnė rizika

Duomenų atskleidimas yra tylesnė rizika, o reguliuojamoms organizacijoms dažnai – ir turinti didesnes pasekmes. Pašto dėžutėje per metus susikaupia priedai, vidiniai pranešimai, personalo korespondencija ir susirašinėjimas su klientais – visa tai tampa prieinama per pačią OWA sąsają, kai tik įsilaužėlis autentiškai prisijungia – nereikia jokių atskirų duomenų išgavimo įrankių, nes įsilaužėlis gali pasiekti ir atsisiųsti pašto dėžutės turinį naudodamas teisėtas OWA funkcijas.

1-asis metodas: daugiafaktorių autentifikavimas (MFA), taikomas tiesiogiai prisijungimui prie OWA ir EAC

Tiksliausias sprendimas pašalina konkrečią pažeidžiamą vietą, nekeisdamas nieko kito, kas susiję su „Active Directory“. Daugialypio autentifikavimo (MFA) funkcija, skirta „Outlook Web App“ ir „Exchange Admin Center“, įdiegiama kaip „Exchange“ kliento prieigos paslaugų vaidmens komponentas, kuris veikia priešais esamus OWA ir EAC prisijungimo puslapius, o ne visiškai pakeičia „Exchange“ autentifikavimo mechanizmą. Įdiegus šią funkciją, vartotojai pirmiausia autentiškumą patvirtina naudodami įprastą „AD“ vartotojo vardą ir slaptažodį, o tada, prieš suteikiant sesiją, atlieka antrąjį autentiškumo patvirtinimo žingsnį – pavyzdžiui, įvedant vienkartinį slaptažodį (OTP) iš autentiškumo patvirtinimo programėlės ar aparatinio žymens arba patvirtindami „push“ pranešimą.

Taikymo sritis nustatoma per „Active Directory“ grupės narystę diegimo metu: administratorius gali iš karto reikalauti MFA visų vartotojų atžvilgiu arba iš pradžių ją įjungti vienai „AD“ grupei – bandomajai grupei arba konkrečiai grupei, turinčiai prieigą prie „Exchange“ administravimo centro – kol planuojamas platesnis diegimas. Šis skirtumas praktikoje yra svarbus, nes „EAC“ paskyros kelia žymiai didesnę organizacinę riziką nei atskiras pašto dėžutė; administratoriaus paskyra su prieiga prie „EAC“ gali kurti pašto srauto taisykles, keisti leidimus arba eksportuoti duomenis visoje „Exchange“ aplinkoje, būtent todėl „EAC“ prisijungimų apsauga paprastai yra prioritetas, net jei visiškas diegimas visiems vartotojams užtrunka ilgiau.

Sesijos elgsena yra konfigūruojama, o ne fiksuota. Administratoriai nustato, kaip dažnai vartotojams bus vėl prašoma įvesti naują vienkartinį slaptažodį (OTP) – pavyzdžiui, kartą per 12 valandų nepertraukiamo „OWA“ naudojimo – taip suderindami pakartotinio autentifikavimo nepatogumus su rizika, susijusia su ilgai trunkančia, be priežiūros sesija bendrai naudojamame arba nevaldomame įrenginyje. Šis komponentas palaiko HOTP, TOTP ir „challenge-response“ OCRA, suteikdamas lankstumą organizacijoms, naudojančioms skirtingų tipų OTP žetonus.

2-asis metodas: MFA „Active Directory“ lygmenyje, apimantis OWA kartu su viskuo kitu

Prieš diegiant OWA skirtą komponentą verta užduoti siauresnį klausimą: ar OWA iš tiesų yra vienintelė su „Active Directory“ susieta paslauga, kuri vis dar autentiškumą patvirtina vien tik slaptažodžiu? Daugumoje lokalių aplinkų sąžiningas atsakymas yra „ne“ – „Winlogon“, RDP ir dažnai vidinės su LDAP susietos programos yra tokioje pačioje padėtyje, apsaugotos tik tuo, ką numato „Active Directory“ taikoma slaptažodžių politika.

Daugialypė autentifikacija katalogų lygmenyje pašalina šią didesnę pažeidžiamybę, integruodamasi pačiame „Active Directory“, o ne kiekvienos atskiros paslaugos prisijungimo puslapyje. Vietoj atskirų daugiafaktoriaus autentifikavimo (MFA) diegimų serijos – vieno komponento OWA, kito agento RDP, RADIUS tarpinio serverio VPN, kurių kiekvienas įdiegiamas, konfigūruojamas ir prižiūrimas atskirai – integracija katalogų lygmenyje keičia vartotojo prisijungimo duomenų veikimą „Active Directory“, pakeisdama statinius slaptažodžius laiko pagrįstais dinaminiais slaptažodžiais, todėl su AD susietos paslaugos gali naudoti tuos pačius dinamiškus prisijungimo duomenis, nereikalaujant atskirų MFA komponentų kiekvienai paslaugai. OWA įtraukiama ne todėl, kad ji buvo konkrečiai pasirinkta, o todėl, kad ji, kaip ir viskas, kas nukreipta į „AD“, dabar turi atitikti tą patį dinamiškų prisijungimo duomenų patikrinimą.

Šis kompromisas veikia priešinga kryptimi nei 1-asis metodas: platesnis aprėptis mainais į didesnį AD autentifikavimo veikimo pokytį visoje aplinkoje, o tai paprastai reikalauja kruopštesnių bandymų ir etapinio diegimo nei vienos paslaugos OWA komponento atveju. Teisingas pasirinkimas tarp šių dviejų variantų iš tiesų priklauso nuo taikymo srities – organizacijai, kurios vienintelis neapsaugotas su AD susijęs taškas yra OWA, nereikia liesti katalogo, kad tai ištaisytų; organizacija, kuri nustato, kad OWA, RDP ir „Winlogon“ visi naudoja autentiškumo patvirtinimą tik slaptažodžiu, susiduria su platesne problema, kurios nepavyks išspręsti vienos paslaugos pataisa.

Kaip veikia katalogo lygio mechanizmas be galinių įrenginių agentų

Verta atskirai suprasti katalogo lygio MFA mechanizmą, nes jis paaiškina, kodėl jis pasiekia kiekvieną su AD susietą paslaugą, nieko neįdiegiant atskiruose darbo kompiuteriuose ar serveriuose.

Dinaminis stipraus slaptažodžio autentifikavimas veikia keičiant pačiame „Active Directory“ saugomą slaptažodį, o ne perimant autentifikavimo srautą kiekviename galiniame įrenginyje. Vartotojo statinis slaptažodis pakeičiamas besikeičiančiu, TOTP pagrįstu dinamišku slaptažodžiu, kuris automatiškai keičiasi administratoriaus nustatytu intervalu – šis laikas turi būti 30 sekundžių kartotinis. Dabartinis dinaminis slaptažodis generuojamas naudojant TOTP algoritmą ir vartotojui prieinamas per „Protectimus SMART“ programėlę arba palaikomą pokalbių botą. Kadangi pakeitimas vyksta tiesiogiai kataloge, bet kuris klientas ar paslauga, autentiškumą patvirtinanti per AD – „Winlogon“, RDP, OWA, su LDAP susietos programos – automatiškai naudoja dabartinį dinaminį slaptažodį, ir tai daroma netgi be to, kad ta paslauga žinotų, jog kažkas pasikeitė.

Būtent tai lemia, kad šis metodas yra „be agentų“ ta prasme, kuri yra svarbi: nei nešiojamajame kompiuteryje, nei RDP serveryje, nei „Exchange“ kliento prieigos serveryje neveikia jokia programinė įranga, tikrinanti antrąjį autentifikavimo veiksnį. Pats katalogas yra vykdymo taškas. Atitinkamas kompromisas yra tai, kad šis komponentas veikia kaip vietinio diegimo dalis, o ne kaip išskirtinai debesyje teikiama paslauga, nes jam reikalinga tiesioginė integracija su domeno valdytoju.

Apimties pasirinkimas: tik internetinė pašto programa ar visa „AD“ aplinka

Abu metodai išsprendžia pagrindinę problemą – vien slaptažodžio nebepakanka autentifikavimui – tačiau jie ją sprendžia skirtinguose sistemos sluoksniuose, o teisingas pasirinkimas priklauso nuo sąžiningo esamos situacijos įvertinimo, o ne nuo numatytųjų preferencijų.

Jei OWA ir EAC iš tiesų yra vienintelės paslaugos, kurios vis dar atlieka autentifikavimą AD tinkle naudodamos vien tik slaptažodį – VPN jau apimtas per RADIUS, RDP jau užrakintas, nėra kitų senesnių programų, tyliai pasitikinčių AD prisijungimo duomenimis – tikslinis OWA komponentas užpildo tą konkrečią spragą, minimaliai trikdydamas viską, kas veikia su katalogu. Jei inventorizacijos metu nustatoma daugiau nei viena pažeidžiama paslauga – o tai dažniausiai pasitaiko, kai IT komandos iš tikrųjų pradeda ieškoti – katalogo lygio daugiafaktorius autentifikavimas (MFA) uždaro jas visas iš vieno integracijos taško, o ne kaupia atskirą MFA produktą kiekvienai iš jų.

Bet kuriuo atveju, FTB pateikiami duomenys apie nuostolius dėl BEC nusikaltimų rodo tą patį esminį faktą: prisijungimas prie įmonės pašto dėžutės, esančios atvirame internete, naudojant vien tik slaptažodį, nebėra priimtina pozicija jokiai organizacijai, naudojančiai „Exchange“ – vietinėje, hibridinėje ar kitokioje aplinkoje.