Защо „имате ли MFA“ не е въпрос
Контролът върху корпоративната сигурност се премести от мрежовия периметър към самоличността. Това променя какво трябва да придобие нападателят. Не маршрут към вашата мрежа, а акаунт — или артефактът, който доставчикът ви на самоличност издава, след като е приключил с проверката на акаунта.
Регулацията отразява това преместване. Чл. 21, параграф 2, буква „й“ от NIS2 посочва сред минималните мерки „използването на многофакторни решения за удостоверяване на автентичността или непрекъснато удостоверяване на автентичността ... в рамките на субекта, когато е целесъобразно“. Финансовите субекти имат същото в чл. 9, параграф 4, буква „г“ от DORA — политики и протоколи за стабилни механизми за удостоверяване на автентичността по съответните стандарти. Делегираният регламент го прави конкретно: чл. 21, буква „е“, подточка ii) от Регламент (ЕС) 2024/1774 изисква сигурни методи за удостоверяване при отдалечен достъп до мрежата, при привилегирован достъп и при достъп до активи на ИКТ, поддържащи критични или важни функции или публично достъпни.
Организацията включва MFA, попълва въпросника и удовлетворява одитора. Нападателят не е засегнат от нищо от това, защото нищо от него не е било тест.
Прочетете и буква „е“ от същия параграф на NIS2: „политики и процедури за оценяване на ефективността на мерките за управление на риска в областта на киберсигурността“. Директивата изисква контрола и в следващото изречение пита дали той работи. Чл. 25, параграф 1 от DORA е още по-пряк — изброява тестване на различни сценарии и тестване за проникване в програмата за тестване на устойчивостта. Задължението за проверка вече е записано. Точно то обикновено липсва.
Разликата между деклариран и изпитан контрол определя практическия ми подход. Авторският профил води към докторския запис и научните публикации; резултат в една среда не доказва защитата на друга.
Какво остава извън „имаме MFA“
Започнете с покритието. Прегледайте следните пътища за удостоверяване и действителната им конфигурация.
Базово удостоверяване и други пътища с един фактор. Проверявайте механизма, не само името на протокола: даден протокол може да поддържа модерно OAuth удостоверяване. Намерете достъпа само с парола извън предвидената политика и определете как да го прекратите или защитите.
Служебни и приложни идентичности. Автоматизираните процеси изискват подходящи мерки: управлявани идентичности или защитени удостоверителни данни, ограничени права и наблюдение. Интерактивната MFA подкана не е универсално решение за задачи без човек. Отделно проверете потребителските акаунти, използвани като служебни.
Аварийни акаунти. Проектирайте ги да работят при отказ на нормалния достъп, с независимо удостоверяване, устойчиво на фишинг, и наблюдение на използването. Изключване от блокиращи Conditional Access политики не означава оставяне само с парола. Следвайте актуалните указания на доставчика и тествайте възстановяването.
Гостуващи и партньорски идентичности. Проверете политиките на приемащия тенант и доверието между тенантите. Приемащата организация може да изисква MFA или да приема подходящи потвърждения от домашния тенант; проверете действителното поведение.
Отдалечен достъп извън доставчика на самоличност. VPN концентратор с локални акаунти, устройство със собствена база от потребители, инструмент за отдалечена помощ с отделен вход. Нито един не вижда правилата ви за условен достъп.
Административен достъп на трети лица. Конзолата на доставчика, акаунтът на доставчика на управлявани услуги, фирмата, която поддържа ERP системата — влиза и в разговора с банка или съществен субект, и във вашия собствен преглед.
Четири начина покрай включена MFA
Фишинг страницата, която е истинската страница за вход. Комплектът с посредник не имитира екрана за влизане — той го препраща. Жертвата вижда автентичната страница, защото това е автентичната страница, минала през проксито на нападателя. Паролата е вярна, вторият фактор е верен, услугата издава сесийна бисквитка — и проксито запазва копие. Нападателят я използва повторно и е вътре, без нито една подкана. ENISA Threat Landscape 2025 отчита фишинга с 60% от проникванията и назовава FlowerStorm — платформа за фишинг като услуга, която имитира портали на Microsoft 365 и заобикаля MFA. Вторият фактор е бил изпълнен правилно. В това е смисълът на техниката.
Кражба и повторно използване на токени. Същият резултат без никакъв фишинг. Зловреден софтуер на устройството чете хранилището на бисквитките в браузъра или кеша с токени и ги изнася; ENISA описва инструментите за кражба на данни като средство преди всичко за кражба на идентификационни данни, отвличане на сесии и посредничество при достъп. В MITRE ATT&CK това е T1550.004: сесията вече е удостоверена, така че стъпката по автентикация отпада. Ако сесиите са дълги и нищо не проверява откъде се използва токенът, кражбата струва повече, отколкото някога е струвала паролата.
Съгласие за OAuth приложение. Приложение може да получи делегиран достъп след привидно легитимно одобрение. Разрешението може да остане и след смяна на парола; проверявайте отделно съгласията, удостоверителните данни и издадените токени. Прегледайте политиката и приложенията в собствения тенант, вместо да предполагате, че всеки може да одобрява всичко.
Умора от подкани, записване и възстановяване. Повтарящи се заявки за потвърждение, докато някой не приеме една — в два часа през нощта или по средата на среща; ATT&CK я води като T1621. Човешкият фактор тук не е глупост, а дизайн: подканата иска от човек решение за сигурност без никакъв контекст, десетки пъти седмично, и го обучава да я изчиства. Записването и възстановяването са още по-меки. Убедителен обаждащ се моли сервизното звено да нулира загубен фактор и записва свой. SMS и гласовите кодове добавят подмяната на SIM карта и злоупотребата със сигналните мрежи — информационният лист на CISA изброява и двете, а ENISA отчита продължаваща експлоатация на SS7 и Diameter.
Какво наистина отказва тези атаки
Различните мерки покриват различни пътища. Изпитвайте комбинацията спрямо приложенията, които действително използвате.
Удостоверяване, устойчиво на фишинг. Удостоверенията FIDO2/WebAuthn обвързват удостоверяването с доверяващата се страна и произхода. Това противодейства на фишинг сайт, който препраща входа. Не прави сесийния токен неуязвим за кражба след легитимно влизане.
Изисквания към устройството и обвързване на токена. Изискване за съответстващо устройство в Conditional Access не е равнозначно на криптографско обвързване на токен с това устройство. Microsoft Entra Token Protection има конкретна поддръжка по платформи, приложения и ресурси. Проверете дали съответната сесия е покрита, преди да заявите, че повторното използване е блокирано.
Живот на сесията и отнемане. Честотата на входа, непрекъснатата оценка на достъпа и отнемането на токени могат да намалят експозицията. Ефектът зависи от клиента, ресурса и вида токен. Не обещавайте незабавно отнемане навсякъде; измерете кога спира достъпът в поддържаните приложения.
Управление на съгласието. Ограничете потребителското съгласие до одобрен нискорисков обхват, въведете административен преглед за останалите права и проверете съществуващите разрешения. Премахвайте ненужния достъп след проверка на бизнес зависимостите.
Откриване и възстановяване на случилото се. Съпоставяйте входове, устройства, съгласия за приложения и действия с пощата. Непознат IP адрес или „невъзможно пътуване“ е следа, а не доказателство за компрометиране. Оценката на ефективността на SIEM трябва да установи дали нужните записи са налични и дали сигналът води до действие.
| Път | Подходящ контрол | Какви доказателства да съберете |
|---|---|---|
| Човешки достъп само с парола | Прилагане на предвидената политика | Детайли за удостоверяване, резултат от политиката и изключения |
| Препратен фишинг вход | Удостоверяване, устойчиво на фишинг | Разрешен тест с тестов акаунт |
| Кражба на сесия | Защита на устройството, поддържано обвързване, отнемане | Покритие и измерен достъп след отнемане |
| Прекомерни права на приложение | Управление на съгласия и права | Инвентар на разрешенията, отговорници и записи за отнемане |
| Злоупотреба с възстановяването | Проверка на самоличността и защитено възстановяване | Контролирано упражнение и запис от сервизното звено |
Мерките се допълват. Таблица с включени настройки не установява действителното им покритие.
Как изглежда проверката като работа
Полезният въпрос не е „имате ли MFA“. Той е: пускал ли е някой атаката срещу вашата конфигурация и гледал ли е какво е записала телеметрията ви. Като работа това има три части и писмено разрешение преди всяка от тях.
Първо, контролиран тест на маршрутите за заобикаляне срещу вашата собствена конфигурация — пропуските в прилагането, препратено влизане през реалната ви страница за вход, повторно използване на сесия от втора машина, заявка за съгласие от приложение, което ние контролираме, нулиране на фактор по вашата документирана процедура. Договорен обхват, договорени акаунти, договорен прозорец.
Второ, откриването. Задейства ли се нещо, за колко време и стигна ли известието до човек или до опашка, която никой не чете. Контрол, който се проваля тихо, и контрол, който се проваля шумно, са различни рискове.
Трето, възстановяването на случилото се. Установете акаунта и приложението, какво показват наличните записи за сесии и устройства и кои действия могат да бъдат доказани. Липсващите записи може да изискват нов източник, лиценз или промяна на съхранението; работата не е непременно само настройка.
Резултатът е списък от отворени маршрути, затворени маршрути и какво е видяла телеметрията. Не оценка в точки и без обещан изход: находката спокойно може да бъде, че конфигурацията ви издържа, а записите ви не.
Какво да направите първо
- Прегледайте представителен период от дневниците по механизъм и вид акаунт. Проверявайте детайлите: предишно MFA потвърждение може да удовлетвори политика без нова подкана. „Един фактор“ в отделно събитие сам по себе си не доказва заобикаляне.
- Опишете пътищата извън основния доставчик на идентичност и определете отговорник за всеки.
- Тествайте отнемането с разрешен тестов акаунт, договорени приложения и план за връщане. Измерете колко продължава достъпът.
- Прегледайте делегираните и приложните права, включително отговорниците и зависимостите.
- Дайте приоритет на администраторите за удостоверяване, устойчиво на фишинг, с изпитан авариен достъп преди налагането.
- Изберете съхранение на записи според забавянето на откриването, нуждите на разследването, задълженията, поверителността и цената. Проверете, че записите действително се извличат.
Уговорете правомощията при инцидент, преди тест или реално събитие да наложи спешно решение за достъп.
При вече засегнат акаунт следвайте проверките при компрометиран Microsoft 365. При планирано прекратяване използвайте процеса за проверка при напускане.
Границата
Този текст не покрива автентикацията на клиенти, където компромисът с изоставените сесии е друга дисциплина, нито автентикацията при плащания по PSD2. Не решава и какво ще приеме вашият надзорен орган: „когато е целесъобразно“ в буква „й“ е преценка, която подписва управителният орган, а не техническа настройка.
Дали тези задължения изобщо ви засягат е предходният въпрос — започнете от разликата между DORA и NIS2. Ако ви трябват същите контроли, описани като доказателства, които надзорен орган или клиент може да прочете, това е пакетът с доказателства. А ако самоличността ви е силната страна, останалата част от веригата може да не е: как реално влизат при ransomware описва маршрутите, които не минават през страница за вход.
Усилието за въвеждане зависи от приложенията, устройствата, лицензите и възстановяването на достъпа. Изпитайте представителна група, преди да фиксирате цена или срок.
Ако искате маршрутите за заобикаляне да бъдат пуснати срещу вашата конфигурация и телеметрията да бъде прегледана след това, вместо описани, това е ангажиментът практически подобрения.
Бележка. Обща информация, не правен съвет. Приложимото зависи от конкретния субект, дейността, лиценза, размера, груповата структура и националното прилагане.