Безпека веб-додатку Outlook: захист Exchange за допомогою багатофакторної аутентифікації (MFA)

Вступ

Більшість розмов про безпеку віддаленого доступу починаються з VPN. Майже жодна з них не починається з Outlook Web App, і це дивна прогалина, враховуючи, чим насправді є OWA: це форма входу в корпоративну електронну пошту, розміщена у відкритому Інтернеті, доступна з будь-якого браузера на будь-якому пристрої, де б ви не були. Не потрібно налаштовувати VPN-клієнт, обходити правила брандмауера чи проникати через мережеві сегменти — лише поле для імені користувача, поле для пароля та те, що вирішить прийняти сервер Exchange.

Для зловмисника це майже прямий шлях до поштової скриньки. Зламаний обліковий запис OWA не потребує горизонтального переміщення, щоб стати небезпечним — він уже є небезпечним, одразу ж, оскільки сама поштова скринька є ціллю. Злом корпоративної електронної пошти не потребує шкідливого програмного забезпечення, не потребує експлойта і не спрацьовує більшість інструментів виявлення, створених для виявлення вторгнень у мережу. Для цього потрібен лише один набір дійсних облікових даних та сторінка входу, яка не вимагає нічого іншого.

Чому локальні та гібридні версії Exchange не отримують MFA безкоштовно

Плутанина тут цілком зрозуміла, оскільки користувачі Microsoft 365, які використовують Exchange Online, дійсно отримують надійну автентифікацію майже автоматично — політики умовного доступу Entra ID можуть вимагати MFA на рівні ідентифікації ще до видачі токена сеансу, і цей захист поширюється на Outlook у веб-версії без будь-яких налаштувань, специфічних для Exchange. Команди з безпеки, які завжди працювали виключно в чисто хмарному середовищі, цілком обґрунтовано припускають, що MFA для веб-пошти — це стандартна поведінка Exchange.

Локальні та гібридні версії Exchange не успадковують цю поведінку. Власний стек автентифікації Exchange Server — роль служб клієнтського доступу, що обробляє OWA та Центр адміністрування Exchange — перевіряє ім’я користувача та пароль у Active Directory, і, за відсутності додаткової конфігурації, це і є все рішення щодо автентифікації. У локальному вході в OWA немає вбудованого другого фактора. Гібридні розгортання ще більше ускладнюють ситуацію: деякі поштові скриньки можуть бути вже переміщені до Exchange Online і охоплені функцією «Умовний доступ», тоді як інші залишаються в локальному середовищі й можуть досі покладатися на власний шлях автентифікації Exchange Server, якщо не було явно налаштовано Hybrid Modern Authentication або інше рішення MFA. Цілком можливо, що організація вважає свою електронну пошту «захищеною за допомогою MFA», оскільки це дійсно так для орендаря, тоді як значна частина поштових скриньок все ще залишається за локальним OWA, що використовує лише пароль.

Саме ця прогалина має оперативне значення — не тому, що локальний Exchange за своєю суттю є менш безпечним за дизайном, а тому, що вона покладає відповідальність за додавання другого фактора автентифікації виключно на адміністратора Exchange, не надаючи жодного варіанту за замовчуванням, на який можна було б покластися.

Що насправді дає зловмиснику зламаний обліковий запис OWA або EAC

Цінність одного набору облікових даних OWA легко недооцінити, якщо розглядати його як «просто електронну пошту». На практиці зламаний обліковий запис поштової скриньки є плацдармом, від якого відгалужуються кілька різних шляхів атаки.

Найбільш прямим з фінансової точки зору є компрометація ділової електронної пошти (BEC).

Компрометація ділової електронної пошти (BEC) є найбільш прямим фінансовим загрозою. Центр скарг на інтернет-злочини ФБР зафіксував у 2025 році в США збитки від BEC на суму 3,046 млрд доларів — це друга за величиною категорія збитків після інвестиційного шахрайства, що розподілилася між приблизно 24 768 скаргами — середній збиток перевищує 120 000 доларів на кожен підтверджений інцидент. Атаки BEC, як правило, не передбачають використання шкідливого програмного забезпечення чи шкідливих посилань, які могли б виявити фільтри безпеки; зловмисник перебуває всередині легітимної поштової скриньки, надсилає листи з легітимної адреси, часто відповідаючи в існуючому листуванні, вказуючи змінений банківський код або перенаправлений рахунок-фактуру. Правила обробки пошти ускладнюють виявлення цієї техніки вже після факту — зловмисник, що має доступ до поштової скриньки, може створити правило для вхідної пошти, яке непомітно пересилає або видаляє повідомлення, що містять такі слова, як «рахунок», «переказ» або «платіж», завдяки чому власнику облікового запису залишається невідомо про злом, тоді як шахрайська переписка триває паралельно.

Доступ делегатів ще більше збільшує ризик.

Делегований доступ ще більше збільшує ризик витоку даних. Асистенти керівників та члени фінансової команди часто мають права делегата або права «надсилати від імені» щодо поштових скриньок керівників у рамках звичайного робочого процесу, що означає: один зламаний обліковий запис асистента можна використати для надсилання повідомлень, які, на перший погляд, начебто надходять безпосередньо від фінансового директора або генерального директора, навіть не торкаючись власних облікових даних цього керівника.

Витік даних — це менш помітний ризик

Витік даних — це прихований ризик, який часто має більш серйозні наслідки для організацій, що підлягають регулюванню. У поштовій скриньці накопичуються роками вкладення, внутрішні меморандуми, листування з відділом кадрів та комунікації з клієнтами, і все це стає доступним через власний інтерфейс OWA, щойно зловмисник пройде автентифікацію — окремі інструменти для викрадення даних не потрібні, оскільки зловмисник може отримати доступ до вмісту поштової скриньки та завантажити його, використовуючи легітимні функції OWA.

Підхід 1: застосування MFA безпосередньо до входу в OWA та EAC

Найбільш цілеспрямоване рішення усуває конкретну вразливу поверхню, не зачіпаючи нічого іншого, пов’язаного з Active Directory. MFA для Outlook Web App та Exchange Admin Center встановлюється як компонент у ролі служб клієнтського доступу Exchange, розміщуючись перед існуючими сторінками входу в OWA та EAC, а не повністю замінюючи механізм автентифікації Exchange. Після встановлення користувачі спочатку проходять автентифікацію за допомогою свого звичайного імені користувача та пароля AD, а потім виконують другий крок автентифікації — наприклад, вводячи одноразовий пароль (OTP) з додатка-аутентифікатора або апаратного токена, або підтверджуючи push-повідомлення — перед тим, як сесія буде надана.

Обсяг застосування встановлюється через членство в групах Active Directory під час інсталяції: адміністратор може одразу вимагати MFA для всіх користувачів або спочатку увімкнути її лише для однієї групи AD — пілотної групи або, зокрема, групи, що має доступ до Центру адміністрування Exchange — поки планується більш широке впровадження. На практиці це розрізнення має значення, оскільки облікові записи EAC несуть значно більший організаційний ризик, ніж окремі поштові скриньки; обліковий запис адміністратора з доступом до EAC може створювати правила потоку пошти, змінювати дозволи або експортувати дані в усьому середовищі Exchange, і саме тому захист входів до EAC, як правило, є пріоритетом, навіть якщо повне впровадження для всіх користувачів займає більше часу.

Поведінка сеансу є настроюваною, а не фіксованою. Адміністратори встановлюють, як часто користувачам буде повторно пропонуватися ввести новий одноразовий пароль (OTP) — наприклад, раз на 12 годин безперервного використання OWA — збалансовуючи незручності, пов’язані з повторною автентифікацією, та ризик тривалого, без нагляду сеансу на спільному або некерованому пристрої. Компонент підтримує HOTP, TOTP та алгоритм «запит-відповідь» OCRA, забезпечуючи гнучкість для організацій, що використовують різні типи токенів OTP.

Підхід 2: MFA на рівні Active Directory, що охоплює OWA разом з усім іншим

Перед розгортанням компонента, призначеного саме для OWA, варто поставити більш вузьке запитання: чи справді OWA є єдиною службою, підключеною до AD, яка досі використовує для автентифікації лише пароль? Для більшості локальних середовищ чесна відповідь — ні: Winlogon, RDP та часто внутрішні додатки, пов’язані з LDAP, перебувають у такому самому становищі, захищені лише тією політикою паролів, яку застосовує AD.

Багатофакторна автентифікація на рівні каталогу усуває цю широку вразливість завдяки інтеграції безпосередньо в Active Directory, а не на сторінці входу кожної окремої служби. Замість низки окремих розгортань MFA — одного компонента для OWA, іншого агента для RDP, проксі-сервера RADIUS для VPN, кожен з яких встановлюється, налаштовується та обслуговується незалежно — інтеграція на рівні каталогу змінює принцип роботи облікових даних користувачів в Active Directory, замінюючи статичні паролі динамічними паролями, що змінюються з часом, завдяки чому служби, підключені до AD, можуть використовувати ті самі динамічні облікові дані без необхідності встановлення окремих компонентів MFA для кожної служби. OWA охоплюється не тому, що вона була конкретно обрана ціллю, а тому, що вона, як і все інше, що спрямовано на AD, тепер має відповідати тій самій перевірці динамічних облікових даних.

Компроміс полягає в протилежному підході порівняно з Підходом 1: ширше охоплення в обмін на більш масштабні зміни в поведінці аутентифікації AD у всьому середовищі, що зазвичай вимагає більш ретельного тестування та поетапного впровадження, ніж у випадку з окремим компонентом OWA. Правильний вибір між цими двома підходами насправді залежить від масштабу — організації, єдиною незахищеною поверхнею якої, підключеною до AD, є OWA, не потрібно втручатися в каталог, щоб виправити це; організація, яка виявляє, що OWA, RDP та Winlogon використовують аутентифікацію лише за паролем, має ширшу проблему, яку виправлення для однієї служби не вирішить.

Як працює механізм на рівні каталогу без агентів на кінцевих точках

Механізм, що лежить в основі MFA на рівні каталогу, варто зрозуміти сам по собі, оскільки він пояснює, чому він охоплює кожну службу, підключену до AD, без встановлення будь-чого на окремі робочі станції чи сервери.

Динамічна аутентифікація за допомогою надійного пароля працює шляхом модифікації самого пароля, що зберігається в Active Directory, а не шляхом перехоплення трафіку аутентифікації на кожній кінцевій точці. Статичний пароль користувача замінюється динамічним паролем на основі TOTP, який автоматично змінюється з інтервалом, налаштованим адміністратором — це значення має бути кратним 30 секундам. Поточний динамічний пароль генерується за допомогою алгоритму TOTP і доступний користувачеві через додаток Protectimus SMART або підтримуваний чат-бот. Оскільки зміна відбувається безпосередньо в каталозі, будь-який клієнт або служба, що проходить автентифікацію через AD — Winlogon, RDP, OWA, додатки, пов’язані з LDAP — автоматично використовує поточний динамічний пароль, і цій службі не потрібно знати, що щось змінилося.

Саме це робить цей підхід «без агентів» у тому сенсі, що має значення: на ноутбуці, хості RDP або сервері клієнтського доступу Exchange не працює жодне програмне забезпечення, яке перевіряє наявність другого фактора. Сам каталог є точкою застосування. Відповідним компромісом є те, що цей компонент працює як частина локального розгортання, а не як суто хмарна служба, оскільки він вимагає прямої інтеграції з контролером домену.

Вибір сфери застосування: лише веб-пошта чи все середовище AD

Обидва підходи вирішують основну проблему — одного пароля вже недостатньо для автентифікації — але вони вирішують її на різних рівнях стеку, і правильний вибір залежить від реального аналізу ситуації, а не від стандартних уподобань.

Якщо OWA та EAC дійсно є єдиними службами, які досі здійснюють аутентифікацію в AD лише за допомогою пароля — VPN уже охоплено через RADIUS, RDP уже заблоковано, а жодна інша застаріла програма таємно не довіряє обліковим даним AD — то цільовий компонент OWA усуває цю конкретну вразливість із мінімальним втручанням у роботу інших систем, що використовують цей каталог. Якщо інвентаризація виявить більше ніж одну вразливу службу — що є більш типовим результатом, коли ІТ-команди починають ретельно перевіряти — багатофакторна автентифікація (MFA) на рівні каталогу закриває всі ці вразливості з єдиної точки інтеграції, замість того щоб накопичувати окремий продукт MFA для кожної з них.

У будь-якому разі, дані ФБР щодо збитків від BEC вказують на один і той самий факт: вхід у корпоративну поштову скриньку, розташовану у відкритому Інтернеті, лише за допомогою пароля більше не є безпечним рішенням для жодної організації, що використовує Exchange — локально, у гібридному режимі чи іншим чином.