Microsoft 365: правилна защита — Conditional Access, изключения за MFA и Break‑Glass акаунти в ежедневната работа

Който иска да защити Microsoft 365 правилно, не може да избегне Conditional Access (политики за контрол на достъпа в Entra ID, преди Azure AD) и многофакторна автентикация (MFA, т.е. влизане с най-малко два фактора). В много компании MFA и първите Conditional-Access правила се активират бързо – и тогава работата едва започва: трябва да се обосноват изключенията, да се организират аварийни достъпи по прозрачен начин и да се оформят оперативните процеси така, че сигурността да не предизвика лавина от заявки за поддръжка.

На практика „защитата на M365“ рядко се проваля заради основната технология, но често заради ежедневни проблеми: сервизни акаунти за интерфейси, наследени протоколи, полеви екипи без надеждна мобилна връзка, администратори с прекалено широки права или инцидент, при който точно мярката за защита блокира достъпа на ИТ. Тази публикация обяснява как Conditional Access, MFA-Ausnahmen и Break-Glass-Accounts взаимодействат – и как да управлявате всичко това така, че да остане надеждно и след въвеждането в експлоатация.

Защо Conditional Access е ключът – и защо само MFA не стига

MFA значително намалява риска от откраднати пароли, но MFA не е цялостна концепция за контрол на достъпа. Conditional Access (CA) взема контекстно решение при кои условия даден достъп е разрешен: например само от управлявани устройства, само от определени държави, само след оценка на риска или само с определени клиентски приложения. Това е решаващата стъпка към Zero Trust (модел на сигурността, при който достъпът по подразбиране не се доверява, а се проверява непрекъснато).

Типични причини защо само MFA в Microsoft 365 не е достатъчно:

• Токени вместо пароли: Модерната автентикация работи с токени (временни билети за достъп). Откраднат токен може да заобиколи MFA, ако CA не изисква допълнителни условия (напр. състояние на устройството или контрол на сесията).
• Риск при администраторите: Административните акаунти са особено атрактивни за атакуващите. Без CA правила за администраторския достъп (напр. само от административни работни станции или само с MFA, устойчиво на фишинг) най-голямата повърхност за атаки остава отворена.
• „Разрешено“ е твърде широко: Ако CA не прави разграничение между приложения, класове данни и видове достъп, сигурността бързо става или прекалено слаба, или прекалено рестриктивна – и в двата случая се появяват проблеми.

Оперативната същност е следователно: CA като слой за политики, MFA като негов компонент, плюс прозрачно управление на изключенията и надеждни аварийни пътища.

Преглед на архитектурата: Какво точно управлява Conditional Access в Entra ID

За ИТ ръководството и отдела за експлоатация е важно да не се възприема CA като „една политика“, а като верига от решения. Entra ID оценява при всяко влизане сигнали и прилага политики. Важни сигнали са:

• Идентичност: потребители, групи, роли (напр. привилегировани роли като Global Administrator).
• Целеви ресурс: облачно приложение (Exchange Online, SharePoint/OneDrive, Teams, но също и доставчици от трети страни чрез Enterprise App).
• Тип клиент: браузър, модерни клиенти, мобилни приложения, както и „Legacy Authentication“ (по-стари протоколи без модерни токени, напр. по-стари варианти на IMAP/POP/SMTP автентикация).
• Състояние на устройството: „Compliant“ или „hybrid joined“ (управлявано устройство, обикновено чрез Intune или присъединяване към домейн с индикация за състоянието на устройството).
• Мрежа/Местоположение: Named Locations (определени IP диапазони), държави/региони, индикатори за риск.
• Условия на сесията: Session Lifetime, App-Enforced RESTrictions, Continuous Access Evaluation (непрекъсната преоценка при възникване на рискови събития).

От оперативна гледна точка качеството на вашата CA-конфигурация зависи в голяма степен от това дали тези сигнали са надеждни. Именувано местоположение е толкова добро, колкото и хигиената на вашите IP адреси. Понятието „Compliant“ е толкова добро, колкото и управлението на устройствата ви и дефиницията за съответствие. А оценката на риска е полезна само ако действително работите със създадените в резултат събития.

Правилна защита на Microsoft 365 с Conditional Access: практичен комплект политики

Вместо една „голяма“ политика в ежедневната експлоатация по-добре работи набор от няколко ясно разграничени политики. Това намалява страничните ефекти и улеснява откриването на грешки при инцидент. Утвърден базов модел се състои от:

1) Базова линия за всички потребители: задължително MFA, блокиране на остарялата автентикация

За обикновените потребителски акаунти базовата настройка е: изискване за MFA и блокиране на остарялата автентикация. „Legacy“ тук не означава „старомодно“, а е технически проблематично: тези протоколи често не поддържат съвременни MFA-изисквания и затова са класическа входна точка за масови опити за пробване на пароли.

Важно: Не блокирайте остарялата автентикация „в един момент“, а планирайте преходен период с измерване. Проверявайте през логовете за влизане кои клиенти все още използват legacy. В предприятията към тях често са свързани многофункционални принтери, функции за сканиране към имейл или по-стари пощенски клиенти в специални среди.

2) Политика за администратори: значително по-строга от базовата

Привилегированите роли трябва да имат собствена политика: достъп само от определени администраторски крайни устройства (например „compliant‘‘ и евентуално отделна стратегия за администраторска работна станция), MFA с висока степен на защита (устойчива на фишинг, напр. FIDO2/Passkey или базирано на сертификат), и, където е възможно, ограничения за рискови държави/локации. Дори ако не всяка организация веднага въведе пълна архитектура за привилегирован достъп (PAM, т.е. управление на привилегирования достъп), тази диференциация има незабавна стойност: компрометиран администраторски акаунт поражда друг мащаб на щетите в сравнение с компрометиран потребителски акаунт.

3) Политика за външно сътрудничество и гости

Достъпите за гости (B2B Collaboration) често създават неочаквани пътища за данни: гостите свалят файлове от SharePoint, работят в Teams или имат достъп до проектни портали. Определете тук целенасочено дали гостите могат да влизат само с MFA, кои приложения са изключени и колко дълго сесиите са валидни. За проектна работа често е целесъобразно по-кратко време на сесия, за да се намали рискът от „забравени влизания“.

4) Политика за чувствителни пътища на данни: защита на устройството или сесията

В практиката има различни потребности от защита: търговският представител може да чете имейли от всяко устройство, но не и да изтегля големи обеми данни от SharePoint без управлявано устройство. Подобни разлики не моделирате чрез общи „разрешено/забранено“ решения, а чрез CA-комбинации: „достъп разрешен, ако устройството е compliant“ или „достъп само през браузър с ограничена сесия“. Това е по-меко от пълно блокиране — и въпреки това ефективно.

Изключения от MFA: къде са реалистични — и как да ги контролирате

Изключенията от MFA не са знак за слабост, стига да са съзнателно дефинирани и оперативно контролирани. Без контролирани изключения възникват сенчести решения: потребителите заобикалят процесите, администраторите прибързано изключват правила и в крайна сметка наборът от политики става непроследим.

Важна е разликата: изключението от MFA рядко означава „MFA изключено“, по-често е „MFA по друг начин“ или „достъп само при други условия“. Типични категории изключения:

Изключение 1: Нейнтерактивен достъп и интерфейси

Много процесно-близки софтуерни решения интегрират M365 услуги: изпращане на имейли, достъп до календари, файлово хранилище на SharePoint, известия в Teams или достъп чрез Graph-API. Такива интеграции не бива да минават през потребителски акаунти с деактивирано MFA. По-добре е технически достъп чрез регистрация на приложения (приложение в Entra ID) с ясни разрешения и жизнен цикъл на тайни/сертификати. Това не е „MFA-изключение“, а различен начин на удостоверяване, който е по-подлежащ на одит.

Оперативни последици: тайните трябва да се ротираят, сертификатите изтичат и разрешенията трябва да бъдат ресертифицирани. Ако планирате интеграции, дефинирайте собственост/отговорност (кой подновява сертификати/тайни) и мониторинг (напр. предупреждения преди изтичане). В противен случай от „сигурно“ удостоверяване на приложение може да се получи непланиран отказ.

Изключение 2: Устройства без модерен вход (напр. скенери, принтери, системи за зали)

Тук възникват класическите дискусии около SMTP-Relay, Scan-to-Mail или пощенски кутии за зали. Грешното решение почти винаги е „потребителски акаунт без MFA“. По-добри са технически пътища, които не зависят от интерактивно влизане: централен Mail-Relay с IP-рестрикция, подходи със сертификати или конектори, или отделни системни пощенски кутии с ограничени права. Ключовото е: самото устройство не може да работи с MFA, затова дизайнът трябва да осигури защита на транспортния и мрежовия път.

Изключение 3: Аварийна експлоатация и ограничена достъпност

Работа в полето, производство или смяна имат ситуации без мобилен обхват или без лични мобилни устройства. Тук си струва рано да се обмислят алтернативни MFA методи: хардуерни токени, FIDO2 сигурни ключове, или Windows Hello for Business (вписване, обвързано с устройството). „Временно MFA изключено“ е оперативно примамливо, но лошо скалира и трудно се поддава на одит.

Изключение 4: Автоматизирани задачи с потребителски контекст

Някои стари системи стартират задачи „като потребител“, например за качвания в SharePoint или отчети. Това е днес рисково, защото смесва роли и права за достъп. Ако замяната не е възможна веднага, работете с междинни мерки: ограничени служебни акаунти, ясни Named Locations, строги политики за пароли/тайни и последователно регистриране на логове. И: планирайте миграцията към идентичности на приложения като отделен работен пакет, а не като „по-късно“.

Как да документирате, одобрите и премахнете изключенията

Изключенията са приемливи в експлоатацията само ако имат жизнен цикъл. На практика се е доказал един лек, но одитируем подход, който избягва бюрокрация, но остава проследим:

1. Обосновка в едно изречение: Коя бизнес или оперативна функция зависи от това (напр. „Scan-to-Mail за локация X“)?
2. Техническо класиране: Кое приложение/кои протоколи, кои акаунти, кои пътища за данни?
3. Компенсиращи контроли: Какво ограничава риска (IP-рестрикция, минимално необходими права, мониторинг)?
4. Срок на валидност: Всяко изключение получава дата за преглед. Без преглед то се премахва или се одобрява наново.
5. Отговорник: Кой е отговорен, ако възникнат проблеми или ако изключението изтече?

Така изключенията не стават „добри“, но стават управляеми. И точно това е в практиката разликата между стабилна M365-основа за сигурност и безконтролно разрастване на политики.

Break-Glass акаунти: аварийен достъп без пробив в сигурността

Break-Glass акаунти са аварийни акаунти за достъп до тенанта, когато обичайните администраторски входове не работят – например поради грешна конфигурация в Conditional Access, отказ на MFA доставчик или инцидент, свързан с идентичността. Целта е ясна, но изпълнението крие типични капани: Break-Glass акаунт, който никога не се тества, няма да помогне в реална ситуация. Break-Glass акаунт, който е твърде леснодостъпен, е привлекателна цел за атака.

Какво не представлява Break-Glass

• Не е ежедневен администраторски акаунт: Не бива да се използва в нормалната експлоатация.
• Не е резервоар за изключения: Не замества чист дизайн на Conditional Access.
• Не е „имаме го, стига така“: Без процес, тестове и алармиране е само теоретичен план.

Основни принципи за Break-Glass в експлоатация

Практично решение се ръководи от три цели: достъпно в аварийна ситуация, трудно за атакуване в нормален режим и ясно проследимо.

• Поне два акаунта: Редундантност срещу блокиране, човешка грешка или компрометирани данни за достъп.
• Силно защитени: Дълги, случайни пароли; без пренасочване на имейли; без използване за приложения/интеграции.
• Целенасочено изключени от CA – но стеснено: Обичайно се прави изключение от определени CA политики, за да не бъдете заключени от собствените си правила в спешен случай. В същото време трябва да действат други мерки за сигурност: аларми при използване, рестриктивно разпределение на роли, отделно съхранение на данните за достъп.
• Логване и алармиране: Всяко влизане трябва да предизвика незабавен сигнал (SIEM/SOC или поне имейл/Teams аларма към инцидентна пощенска кутия). Използването на Break-Glass по дефиниция е събитие за сигурността.

Един ключов момент: Решете съзнателно дали Break-Glass ще се експлоатира с или без MFA. Много организации го оставят без MFA, за да останат оперативни при отказ на MFA. В такъв случай компенсиращите контроли трябва да са особено строги (съхранение, достъп до паролата, алармиране, редовна смяна). Алтернативно, Break-Glass може да бъде оборудван с хардуерно базирано MFA (напр. FIDO2), което е независимо от мобилни мрежи. Не е важна „правилната“ идеология, а аварийният път, който реално функционира във вашия контекст.

Реалност при внедряването: Как да избегнете заключвания и пикове в поддръжката

Много CA-/MFA внедрявания не се провалят по технически причини, а организационно: твърде бързо, твърде широко, без телеметрия и без ясен процес на поддръжка. Стабилно внедряване работи на вълни и с измервателни точки.

Стъпка 1: Създайте видимост (преди да блокирате)

Използвайте Sign-in Logs и анализи, за да установите: Кои приложения се използват? Кои клиенти са „Legacy“? Кои локации/IP обхвати са реални? Кои потребители имат особено много проблеми с влизането? Без тези данни всяка политика е полет на сляпо.

Стъпка 2: Пилотни групи с реални специални случаи

Пилотите не трябва да са само „IT и няколко доброволци“. Включете умишлено гранични случаи: полеви екипи, производствени обекти, проектни служители с гост достъп и поне едно звено с типични инструменти на трети страни. Целта не е хармония, а ранно откриване на реалните капани.

Стъпка 3: Определете ръководства за Helpdesk (Playbooks)

Когато MFA бъде налагана, броят на тикетите се увеличава: смяна на устройства, загубени телефони, нови служители, акаунт блокиран след твърде много опити. Задайте какво може да реши First-Level (напр. нулиране на MFA след проверка на идентичността) и кога се ескалира. Без Playbooks всичко се ескалира – и администраторите се превръщат във фалш-пойнт.

Schritt 4: Technische Nacharbeiten als eigenes Backlog

CA прави видими скритите технически дългове: остарели mail-клиенти, недокументирани скенери, скриптове с пароли в Task Scheduler, или интеграции, които все още използват Basic Auth. Планирайте тези доработки като видими работни пакети. В противен случай те остават като „постоянно изключение“.

Typische Fehlerbilder aus dem Betrieb – und wie man sie schneller einordnet

В ежедневната работа важат бързи хипотези. Някои модели се повтарят:

„Plötzlich geht Outlook nicht mehr“

Чести причини: legacy клиент, стар профил или CA-блок поради липса на оборудвано състояние. Проверете: тип клиент в Sign-in Log, приложена CA-Policy и дали устройството е маркирано като compliant. Оперативното решение рядко е „изключи политиката“, а по-скоро „модернизирай клиента“ или „подреди управлението на устройствата“.

„Service XY kann keine E-Mails mehr senden“

Често причината е промяна в SMTP-автентикацията, променена Relay-Policy или ново CA-правило, което неволно обхваща и технически акаунти. Тук помага ясен архитектурен избор: изпращане през Relay/Connector вместо потребителско логване, с IP-рестрикция и логване (проследимост при инцидент).

„Admin kommt nicht mehr in den Tenant“

Това е моментът, за който е предназначен Break-Glass. Ако и Break-Glass достъпът не работи, обикновено липсва тестван аварийен път или изключението е сгрешено. Затова: упражнявайте използването редовно (с документация кой, кога и как тества, и как изглежда алармата).

„Zu viele Ausnahmen – niemand blickt durch“

Това е проблем на Governance. Консолидирайте политиките, дефинирайте ритуал за преглед (напр. месечно 30 минути) и премахнете изключения, които нямат вече owner или цел. Технически това не е гламурно, но е разликата между контролирана сигурност и исторически натрупани специални права.

Monitoring und Nachvollziehbarkeit: Was Sie wirklich brauchen

CA и MFA генерират много евенти. Ако събирате всичко, ще потънете; ако не анализирате нищо, ще забележите проблемите твърде късно. Практически полезни са три нива:

• Alarmиране при критични евенти: Break-Glass вход, администраторско влизане от необичайни държави, блок-събития върху критични приложения.
• Редовни прегледи: топ причини за блокиране, топ потребители с проблеми при MFA, опити за legacy auth, нови приложения/Enterprise Apps.
• Audit-път за изключения: кой е одобрил кое изключение, с каква дата на изтичане и кога е прегледано?

Ако вече имате централни логване- и инцидентни процеси (SIEM, Ticketing, Change-Management), вградете CA-промените там. Conditional Access не е „малка настройка“, а продукционно критичен слой за достъп.

Aufwand und Verantwortlichkeiten: Wer muss was liefern?

CA-/MFA-проекти се подценяват, защото изглеждат като чиста конфигурация. В действителност това са междусистемни проекти между идентичност, крайни устройства, мрежа и бизнес процеси. Ясен модел на отговорности намалява триенето:

• Identity-Team / Entra Admins: Policy-Design, модел на роли, Break-Glass, регистриране на приложения.
• Client-Management (z. B. Intune): дефиниране на compliance, състояние на устройствата, разгръщане на Authenticator/Passkeys, жизнен цикъл на устройствата.
• Netzwerk: IP обхвати за Named Locations, изключения за Proxy/TLS-Inspection, смяна на местоположение.
• Service Owner von Business-Anwendungen: интеграционни пътища (Graph/SMTP/SharePoint), преход от Legacy-Auth, ротация на секрети.
• Helpdesk: стандартни процеси за нулиране на MFA, смяна на устройства, Onboarding/Offboarding.

Най-важното управленско решение често не е „MFA да/не“, а: Имаме ли време и ресурси за последващите дейности (премахване на Legacy, модернизация на интеграциите, стабилизиране на управлението на устройствата)? Без тази работа печалбата от сигурността ще остане под очакванията – или експлоатацията ще стане ненужно тежка.

Fazit: Sicherheit gewinnt, wenn Notfall und Ausnahme zum System gehören

Правилното обезопасяване на Microsoft 365 означава да се управлява Conditional Access като централния слой за управление – не като еднократна конфигурация. MFA е задължително, но реалното качество на експлоатацията се постига чрез чисто дефинирани изключения (с краен срок, собственик и компенсиращи контроли) и чрез Break-Glass-Accounts, които са тествани, наблюдавани и организационно внедрени. Който обмисля тези три елемента заедно, намалява рисковете по акаунтите, постига одитируемост без излишен административен товар и предотвратява правилата за сигурност да се превърнат във враг по време на инцидент.

Обсъдете проект или модернизационно начинание с Net-Base.