Фишинг согласия в Microsoft 365

By Mirko Peters · 2026-04-26 · Updated 2026-07-18

Узнайте, как фишинг согласия в Microsoft 365 обходит традиционные механизмы защиты на основе MFA, злоупотребляет разрешениями OAuth, а также как его обнаружить и предотвратить.

Automatically translated with AI from the original post. Read the English original

Cover: Stop OAuth Consent Attacks in Microsoft Entra ID

Фишинг согласия — одна из самых быстро растущих угроз в средах Microsoft 365 и Azure. Он застаёт организации врасплох, обходя даже самые надёжные механизмы аутентификации. В отличие от классического фишинга, который пытается украсть пароль, фишинг согласия позволяет злоумышленникам пробраться через «чёрный ход» — используя именно те механизмы, которые призваны делать вход безопасным. Этот приём опирается на доверие пользователей и использует OAuth, ту же платформу авторизации, на которой работают легитимные решения единого входа и интеграции приложений в облаке.

Злоумышленники могут использовать фишинг согласия для поддержания постоянного, незаметного доступа к конфиденциальным бизнес-данным, даже в средах, защищённых многофакторной аутентификацией (MFA). В этом руководстве подробно разбирается, как и почему фишинг согласия обходит традиционные средства защиты, рассматриваются реальные атаки и приводятся практические шаги по обнаружению, предотвращению и локализации угроз, связанных с согласием. Работаете ли вы с Microsoft 365 для небольшой команды или отвечаете за безопасность тысяч пользователей, понимание того, как злоумышленники действуют в потоках согласия OAuth, сегодня становится обязательным навыком.

Что такое фишинг согласия и почему MFA его не останавливает

Прежде чем погружаться в технические детали, важно понять общую картину: почему фишинг согласия постоянно попадает в заголовки в сфере облачной безопасности. Речь не о привычных уловках, которые пытаются перехватить ваш логин и перебрать защиту. Фишинг согласия относится к более новому и незаметному классу атак — он использует удобство против вас, превращая легитимные разрешения приложений и потоки авторизации в оружие.

В облачных платформах вроде Microsoft 365 и Azure OAuth повсюду. Именно через него пользователи подключают сторонние приложения, открывают доступ к данным и автоматизируют задачи, часто одним кликом. К сожалению, злоумышленники знают, что пользователи обычно доверяют всему, что выглядит официально, и активно используют моменты, когда запрос разрешения мелькает на экране, а никто не задаёт лишних вопросов. Ключевой момент в том, что такие атаки не требуют кражи паролей: они заставляют реальных пользователей самостоятельно отдать ключи от королевства. Взлом не нужен, достаточно социальной инженерии и продуманной маскировки.

Особая опасность фишинга согласия в том, что он способен обойти многофакторную аутентификацию (MFA) и традиционные меры безопасности. Злоумышленнику не нужно ломать защиту: он вежливо просит доступ, а торопливый или невнимательный пользователь добровольно предоставляет его вредоносному приложению. Это руководство поможет понять, как и почему такие атаки особенно опасны для системы идентификации Microsoft. Если посмотреть на проблему правильно, становится ясно, что защита от фишинга согласия требует совсем другого подхода, чем старая защита учётных данных.

Что такое фишинг согласия и почему он обходит многофакторную аутентификацию?

Фишинг согласия — это вид атаки, при котором пользователя обманом заставляют предоставить приложению, контролируемому злоумышленником, доступ к его облачным ресурсам, одобрив запрос разрешения OAuth, который выглядит легитимно. В отличие от классического фишинга, здесь не нужно красть или подбирать учётные данные: всё держится на том, что пользователь сам авторизует вредоносное приложение. Именно поэтому этот вид атаки особенно опасен в облачной среде.

Самое интересное здесь вот что: когда вы подтверждаете экран согласия, приложение получает от поставщика идентификации (например, Microsoft Entra ID, ранее Azure AD) токены доступа и обновления. С их помощью можно получить доступ к данным Microsoft 365 — почте, файлам, календарю и не только — при этом не зная вашего пароля и не вызывая запроса MFA. Злоумышленнику не нужно обходить защиту входа: он просто использует доступ, который вы добровольно предоставили и который платформа считает полностью легитимным.

Разница между фишингом учётных данных и фишингом согласия тонкая, но принципиальная. Фишинг учётных данных пытается получить имя пользователя и пароль (от которых MFA во многих случаях защищает), тогда как фишинг согласия работает в рамках официального потока авторизации OAuth 2.0. Даже при полностью включённой MFA злоумышленники обходят её целиком, заставляя пользователя пройти процесс согласия в его текущей сессии. После выдачи токенов OAuth присутствие злоумышленника сохраняется, даже если жертва меняет пароль или отзывает сеанс.

Для более глубокого разбора ознакомьтесь с этим обзором атак с согласием OAuth в Entra ID, в котором подробно описаны реальные риски и стратегии защиты, которым организациям стоит отдавать приоритет. Главный вывод: если организации хотят пресечь эти атаки в самом начале, им необходимо выходить за рамки одной только защиты учётных данных и MFA.

Как фишинг с согласием OAuth злоупотребляет доверием для компрометации данных

Злоумышленники, проводящие кампании фишинга с согласием, создают сторонние приложения или выдают себя за них, а затем побуждают пользователей предоставить этим приложениям широкие разрешения, часто используя потоки OAuth 2.0, которые выглядят привычно и «безопасно». Пользователь видит стандартный запрос на согласие с такими формулировками, как «Читать вашу почту» или «Получать доступ к вашим файлам». Если пользователь нажимает «Принять», вредоносное приложение получает настоящие токены OAuth и прямой доступ к указанным ресурсам Microsoft 365 или Azure.

После этого злоумышленникам не нужны ни пароли, ни коды, ни обходные пути. Токены OAuth (в частности, токены доступа и обновления) обеспечивают непрерывный доступ за кулисами. Эти токены действуют до тех пор, пока их не отзовут вручную или пока срок их действия не истечёт, а значит, злоумышленники могут продолжать получать данные, отправлять письма и выполнять действия от имени жертвы, даже если пароли были изменены или пользователи вышли из системы на других устройствах.

Этот метод использует неявное доверие пользователей к диалоговым окнам согласия, особенно в средах, где интерфейс выглядит официально, а времени мало. Поскольку потоки OAuth используют настоящие процессы поставщика удостоверений, подозрительного входа, который можно было бы отметить, не возникает, и злоумышленнику не нужно преодолевать запрос MFA. Атаки разворачиваются незаметно, используя те же API, которым доверяют для повседневных бизнес-операций.

Чтобы разобраться в реальной утечке и получить практические выводы о таких цепочках атак, изучите этот пошаговый разбор злоупотребления OAuth в Microsoft 365. В итоге такой устойчивый доступ становится головной болью для защитников: злоумышленники остаются незамеченными, а путь к полному восстановлению данных и устранению последствий в приложениях может быть долгим и запутанным.

Распространённые техники и реальные атаки фишинга с согласием

Фишинг с согласием далеко не теоретическая угроза: он уже использовался в ряде громких кампаний против Microsoft 365, Google Workspace и других облачных экосистем. Злоумышленники постоянно совершенствуют методы, используя всё: от убедительных названий приложений до незаметных запросов разрешений с minimальными правами. В итоге команды безопасности сталкиваются с постоянно развивающимся набором инструментов, где новые приёмы бросают вызов защитникам на каждом шагу.

Этот раздел показывает, что происходит, когда теория встречается с практикой. Вы увидите жизненный цикл атаки, то, что пользователи реально видят при типичных попытках фишинга, и то, как злоумышленники наращивают доступ или переходят между платформами. От медленного «расползания» разрешений («low and slow») до громких кампаний вроде ConsentFix: приёмы здесь наглядно показывают, насколько изобретательными и настойчивыми стали злоумышленники в обходе обычных средств контроля.

Главное, эти реальные примеры подчёркивают, почему нужно выходить за рамки общих рекомендаций «просто включите MFA». Фишинг с согласием требует, чтобы защитники учитывали одновременно психологию людей и техническую профилактику, понимали, как тонкая социальная инженерия, недостатки дизайна запросов согласия и пробелы в управлении приложениями создают окна возможностей для атакующих. Разбирая практические атаки, этот раздел помогает вашей команде безопасности выработать более точное чутьё и более эффективные плейбуки по снижению рисков.

Пять основных техник фишинга с согласием, которые должны знать команды безопасности

Подмена издателя: злоумышленники создают приложения с названиями, похожими на названия законных поставщиков, например «Microsoft Secure Suite» или «HR Docs Cloud». Пользователи доверяют знакомому брендингу, и поэтому они с большей вероятностью одобрят запрос. Всегда изучайте сведения об издателе и проверяйте источник.
Искажение разрешений: вредоносные приложения часто выделяют безобидные разрешения на экране согласия, но незаметно добавляют области с высокими привилегиями, такие как «read/write all mailboxes» или «full access to files». Пользователи, приученные смотреть только на выделенный жирным текст, могут не заметить реальных рисков, которые они разрешают.
Ограниченные разрешения для последующей эскалации: Некоторые злоумышленники запрашивают базовые разрешения (например, доступ к вашему профилю), чтобы не вызвать подозрений. Затем они используют полученный初始 токен как «ногу в дверях» и пытаются получить более опасные согласия с помощью поэтапного фишинга или повышения привилегий.
Боковое перемещение с постоянными токенами OAuth: Попав внутрь, злоумышленники используют токены и разрешения приложений для перемещения по сети: получают доступ к общим дискам, событиям календаря или повышают свои права в Microsoft 365. Токены могут сначала дать «минимально достаточный» доступ, а затем быть расширены или обновлены.
Скомпрометированные сторонние приложения: Вместо того чтобы создавать собственные инструменты, злоумышленники иногда взламывают или переиспользуют доверенные приложения независимых поставщиков программного обеспечения (ISV), которым многие клиенты уже предоставили широкие разрешения. Такие атаки на цепочку поставок особенно трудно обнаружить, и они могут быстро распространяться между организациями.

Технические подробности о базовых механизмах и о том, как можно укрепить Entra ID против таких схем, вы найдёте в этом подробном разборе злоупотребления согласием OAuth. Это лишь некоторые из множества изобретательных способов, которыми злоумышленники научились обходить устаревшие средства защиты и MFA.

Как работает кампания ConsentFix: пошагово

Первое фишинговое письмо: Атака начинается с убедительного письма, в котором пользователя призывают «исправить проблему с политикой» или «защитить свой почтовый ящик». Письмо содержит ссылку, замаскированную под официальный ресурс Microsoft.
Перенаправление на вредоносную страницу согласия приложения: После перехода по ссылке пользователь попадает на запрос согласия OAuth. Интерфейс выглядит знакомым, с фирменным оформлением и внешне легитимным, но приложение за ним контролируется злоумышленниками, часто с клонированным или обманчивым названием.
Предоставление согласия и выдача токенов: Пользователь просматривает запрошенные разрешения, которые обычно описаны как необходимые для «безопасности» или «соответствия требованиям», и нажимает «Принять». Это передаёт злоумышленнику токены доступа и обновления для учётной записи пользователя.
Злоумышленник получает постоянный доступ: Используя эти токены, злоумышленники получают доступ к почтовым ящикам Microsoft 365, файлам, календарям и другим API с конфиденциальными данными. Сеанс переживает смену паролей и даже большинство сбросов MFA, пока согласие не будет отозвано вручную.
Незаметный сбор данных и монетизация: Злоумышленник тихо выкачивает содержимое почты, конфиденциальные документы или переходит к боковому перемещению в подключённые сервисы. Поскольку всё выглядит «авторизованным», обнаружить атаку сложно, если только ваша команда не отслеживает необычную активность приложений или новые согласия.

Если вы хотите увидеть, как злоумышленники объединяют эти шаги в Microsoft 365 с помощью Entra ID, ознакомьтесь с этим техническим разбором атак согласия OAuth.

Почему ConsentFix важна для безопасности Microsoft 365 и облачной инфраструктуры

Кампания ConsentFix показала, насколько быстро и незаметно злоумышленники могут скомпрометировать клиенты Microsoft 365, Google Workspace и других SaaS-сред, злоупотребляя легитимными потоками OAuth. Организации из разных отраслей столкнулись с несанкционированным доступом к почте, утечками файлов и длительным сохранением доступа злоумышленника даже после принудительного сброса паролей и включения MFA. Эти атаки подчёркивают важность многоуровневой защиты: осведомлённости пользователей, мониторинга согласий в реальном времени и строгого управления приложениями. Всё это не «желательно», а критически необходимо для предотвращения масштабных утечек данных в облаке.

Обнаружение вредоносных приложений и мониторинг подозрительных согласий

Выявлять и реагировать на угрозы, связанные с OAuth, непросто: атака сливается с обычным деловым трафиком. К моменту, когда вы замечаете последствия, вредоносное приложение может незаметно собирать конфиденциальные данные в течение дней или недель. Поэтому так важны проактивные стратегии обнаружения. Службам безопасности нужно больше, чем превентивные меры контроля: им необходим реальный взгляд на то, как пользователи дают согласия, как ведут себя приложения и что считается «нормой» во всей организации.

Этот раздел посвящён практическим подходам к раннему обнаружению и расследованию. Вы узнаете, как использовать поведенческие сигналы, мониторинг аномалий и встроенные корпоративные инструменты Microsoft, чтобы выявлять рискованные события согласия до того, как они выйдут из-под контроля. Необычная активность API или всплеск регистраций новых приложений — правильные признаки помогут заметить атаку на ранней стадии и быстро всё заблокировать.

Представьте это как «камеры видеонаблюдения» вашей облачной среды. Непрерывный мониторинг, автоматическое журналирование и умные оповещения дают реальный шанс сократить время пребывания злоумышленника в системе и minimизировать ущерб. А если вам нужна автоматизация соответствия требованиям или интеграция с более широким управлением рисками, такие инструменты, как Microsoft Defender for Cloud, помогут вывести ваши усилия на новый уровень. О том, как поддерживать соответствие требованиям и безопасность среды с помощью автоматизации, читайте в этом руководстве по мониторингу соответствия в Microsoft Defender for Cloud.

Как обнаружить вредоносные приложения с помощью поведенческих сигналов и сигналов согласия

Отслеживайте неожиданные предоставления согласия: Следите за новыми согласиями OAuth, особенно теми, которые одобрены вне обычного рабочего времени или исходят от незнакомых издателей. Большое количество новых авторизованных приложений может быть тревожным сигналом.
Анализируйте подозрительные шаблоны вызовов API: Ищите аномальное поведение, например, высокоскоростной доступ к файлам, массовое чтение почтовых ящиков или нехарактерное использование административных API. Злоумышленники часто «переиспользуют» разрешения по сравнению с обычными приложениями.
Следите за необычной активностью токенов: Отслеживайте быструю или повторяющуюся генерацию токенов обновления и странные закономерности в жизненном цикле токенов. Вредоносные приложения могут злоупотреблять токенами обновления, чтобы сохранять доступ long после первоначальной компрометации.
Используйте журналы Microsoft и Defender: Применяйте продукты для безопасности облачных приложений и журналы Entra ID, чтобы составить инвентарь всех авторизованных приложений и выявить рискованные или теневые приложения, которые обошли обычные процедуры согласования ИТ. Такие инструменты, как Microsoft Defender for Cloud Apps, обеспечивают видимость и оповещения о подозрительном поведении приложений.
Реагируйте на результаты поиска теневых ИТ: Многие инциденты возникают из-за несанкционированного или неуправляемого доступа приложений. Регулярно проверяйте свой клиент, отслеживайте находки рискованных приложений и очищайте избыточно привилегированные предоставления OAuth. Подробнее о борьбе с теневыми ИТ и контроле несанкционированных приложений читайте в этом руководстве по управлению теневыми ИТ в Microsoft 365.

Расследование фишинговых атак с согласием с помощью Microsoft 365 Defender и Entra ID Protection

Поиск угроз: Начните с поиска в журналах Entra ID и оповещениях Microsoft 365 Defender недавних событий согласия, подозрительного создания приложений или аномальных шаблонов входа, связанных с приложениями OAuth.
Целевое расследование: Изучите историю отдельных пользователей и приложений: какие разрешения были предоставлены, когда и кем. Сопоставьте эту активность с обычными базовыми показателями и временем выполнения бизнес-процессов.
Устранение последствий: Если обнаружено вредоносное согласие, немедленно отзовите токены приложений и предоставления согласия. Microsoft 365 Defender позволяет выполнять массовый отзыв и может отмечать дополнительные рискованные сеансы. Это не даёт злоумышленникам использовать постоянные токены для сохранения доступа.
Непрерывный мониторинг и автоматизация: Настройте автоматические оповещения о новых согласиях на приложения с высоким уровнем риска, повторных запросах административного согласия или известных идентификаторах вредоносных издателей. Задайте автоматические политики для более быстрого реагирования и сокращения времени пребывания злоумышленника в системе.
Интегрируйте соответствие требованиям и применение политик: Используйте Microsoft Defender for Cloud для непрерывного мониторинга соответствия требованиям наряду с реагированием на инциденты, а также ознакомьтесь с подходами к управлению идентификацией в Entra ID, чтобы политики безопасности оставались применимыми со временем. Это позволяет выявлять как атаки в реальном времени, так и предотвращать будущий дрейф конфигурации и «долг идентификации», которые могут открыть новые риски.

Защита среды с помощью политик согласия и ограничений для приложений

Если вы хотите остановить фишинг через согласие (consent phishing) в самом зародыше, нужно обратиться к первоисточнику: к политикам и настройкам, которые определяют, как приложения запрашивают и получают согласие пользователей. Настройка этих элементов требует тонкого баланса: пользователи должны оставаться продуктивными благодаря доверенным интеграциям, но при этом никто не должен по ошибке (или намеренно) впустить волка в овечьей шкуре.

Этот раздел служит практической дорожной картой для облачных администраторов и CISO: здесь разбираются ключевые технические инструменты, которые есть в вашем распоряжении, от проектирования политики согласия и проверки издателя до жесткого управления сроками жизни токенов OAuth. Если всё сделано правильно, эти стратегии минимизируют риски и ограничат последствия, если злоумышленник всё же получит доступ. Последовательное управление особенно важно по мере роста числа SaaS-интеграций и когда теневая ИТ-инфраструктура становится всё сложнее игнорировать.

Управление — это не отказ от инноваций, а контроль доступа, определение доверенных рабочих процессов и соблюдение границ, которые поддерживают здоровье вашей среды по мере её роста. Если вы работаете над более широкими рамками безопасности, выводы из этого материала применимы далеко за пределами Microsoft 365, распространяясь на Power Platform и другие бизнес-SaaS. Для дополнительных сведений о лучших практиках см. руководство по управлению и безопасности Power Platform.

Как настроить политики согласия и ограничить пользовательское согласие

Ограничьте пользовательское согласие по умолчанию: В Microsoft Entra ID настройте параметры на уровне клиента так, чтобы только администраторы могли одобрять согласия для приложений с высоким уровнем риска. Конечные пользователи должны видеть окна согласия только для приложений с низким уровнем риска, что сводит к минимуму случайные одобрения.
Включите рабочие процессы одобрения администратором: Требуйте административной проверки и подтверждения для любого приложения, которое запрашивает широкие или чувствительные разрешения. Это предотвращает «скрытое» предоставление доступа рискованным приложениям и формирует официальную запись о действиях по согласию.
Гранулярная область действия разрешений: Не используйте общие разрешения «разрешить всё». Ограничивайте согласие только тем, что действительно необходимо для бизнес-задач. Пользовательские определения областей затрудняют злоумышленникам незаметное получение опасных привилегий.
Регулярно проверяйте предоставленные согласия: Просматривайте, какие приложения сейчас имеют доступ к вашему клиенту, особенно те, которые были предоставлены пользователями без контроля ИT-отдела. Отзывайте устаревшие или ненужные согласия, чтобы сократить поверхность атаки.
Используйте политики условного доступа: Сочетайте ограничения согласия с надёжными политиками условного доступа, включая принудительное применение на основе местоположения, устройства или уровня риска, чтобы блокировать перехват сеансов и доступ с неуправляемых устройств.

Подробные практические советы по укреплению Entra ID и минимизации рискованных потоков согласия вы найдёте в этом подробном разборе.

Обеспечение проверки издателя и ограничение доступа к приложениям первой стороны

Требуйте проверку издателя: Разрешайте запрашивать согласие пользователя или администратора в вашей среде только приложениям от проверенных издателей. Это подтверждает, что разработчики приложения проверили свою личность, что добавляет дополнительный уровень доверия и блокирует большинство откровенных попыток подмены.
Блокируйте непроверенных издателей: В Entra ID и других платформах задайте базовые политики, которые автоматически отклоняют запросы согласия для приложений, не соответствующих требованиям проверки издателя. Регулярно проверяйте статус издателей для всех существующих и новых приложений.
Ограничьте согласие доверенными приложениями первой стороны: Настройте конфигурацию так, чтобы запрашивать новые согласия могли только приложения первой стороны (например, официальные приложения Microsoft) или специально одобренные сторонние приложения. Это существенно снижает риск горизонтального перемещения от одного скомпрометированного приложения к другому.
Аудит и инвентаризация доступа издателей: Сделайте статус издателей и инвентаризацию приложений постоянным пунктом регулярных циклов проверки безопасности ИТ-отдела, используя автоматизированные инструменты для выявления новых или неодобренных издателей.
Применяйте ко всем подключённым платформам: Распространите проверку издателей и ограничения для приложений на Power Platform, приложения Teams и подключённые SaaS. Подробнее о том, как сделать это в более широком масштабе, читайте в этом руководстве по управлению Power Platform.

Управление сроками жизни токенов и непрерывный мониторинг безопасности OAuth

Настройка более коротких сроков жизни токенов OAuth сокращает окно, в котором злоумышленник может использовать украденные или выданные согласием токены. Настройте политики истечения срока токенов так, чтобы токены доступа истекали быстро, а токены обновления периодически ротировались. Внедрите привязку токенов (token binding) и отзыв на основе оценки рисков, чтобы прерывать подозрительные или злоупотребляемые сеансы. Сочетайте это с непрерывным мониторингом использования токенов и событий согласия, чтобы выявлять необычные шаблоны, — для этого используйте такие инструменты, как Microsoft Defender for Office 365 и политики условного доступа Entra, — чтобы скомпрометированные токены не превратились в постоянные, незаметные угрозы. Практические настройки и стратегии непрерывного мониторинга описаны в этих рекомендациях Microsoft по безопасности.

Укрепление управления и повышение осведомленности пользователей для защиты от фишинга согласий

Технические средства контроля дают ограниченный эффект против эволюционирующих атак в облаке. Долгосрочная устойчивость требует культуры безопасности, в которой надежное управление, регулярные аудиты и обучение пользователей усиливают друг друга. Фишинг согласий использует человеческую психологию в не меньшей степени, чем технологии, поэтому успех зависит и от формальной политики, и от повседневной внимательности вашей команды.

В этом разделе подробно рассматриваются построение системы управления OAuth и аудит существующих выданных разрешений для приложений, практические стратегии обучения, которые помогают пользователям распознавать подозрительные запросы согласия, а также настройка рабочих процессов, создающих реальные препятствия между злоумышленниками и вашими данными. Цель: чтобы ваша защита не останавливалась на пороге ИT-отдела, а охватывала весь бизнес.

Для организаций со сложной экосистемой приложений ставки еще выше: ошибки в любом звене цепочки поставок могут распространиться дальше. Проактивное, постоянное управление и осведомленность необходимы, чтобы сохранять конфиденциальность данных и соответствие требованиям, даже когда число пользователей и приложений продолжает расти. Для более продвинутых рекомендаций по управлению, включая DLP и расширенный аудит в средах Microsoft, см. это подробное руководство по управлению Copilot и материал об аудите действий пользователей с помощью Microsoft Purview Audit.

Построение системы управления OAuth и аудит существующих разрешений

Определите политики согласия и использования приложений: Установите четкие правила, в которых указано, какие пользователи и приложения могут запрашивать согласие, а также допустимые типы разрешений и бизнес-сценарии. Опубликуйте эти правила, чтобы все в организации знали, как действовать.
Ведите полный реестр приложений: Составьте каталог всех приложений, подключенных по OAuth, в Entra ID, с указанием того, кто предоставил согласие, издателя, запрошенных областей доступа (scopes) и бизнес-обоснования. Автоматизированное обнаружение с помощью API Entra или Microsoft Defender поможет ускорить этот процесс и выявить теневые приложения.
Проводите регулярные аудиты выданных разрешений: Планируйте проверки ежеквартально или раз в полгода, чтобы выявлять устаревшие, дублирующиеся или рискованные разрешения. Сверяйте статус верификации издателя приложения и удаляйте разрешения для приложений, которые больше не используются, или тех, которые стали подозрительными.
Отслеживайте отклонения и устраняйте их: Настройте оповещения о нарушениях политик, например, когда пользователи предоставляют широкие разрешения неутвержденным издателям, и запускайте кампании по устранению нарушений сразу после обнаружения пробелов. Регулярные аудиты поддерживают вашу защиту в актуальном состоянии и экосистему приложений в порядке.
Интегрируйте управление с соответствием требованиям и DLP: Для сред с высоким уровнем риска или регулируемых сред связывайте управление OAuth с Microsoft Purview DLP и журналированием аудита. Практические способы мониторинга действий пользователей и границ коннекторов в масштабе см. в этом руководстве по управлению в Purview.

Совершенствование обучения осведомленности и процессов утверждения приложений

Целевое обучение пользователей рискам OAuth: Проводите регулярные семинары или модули электронного обучения, чтобы объяснить сотрудникам опасность подозрительных запросов приложений, вводящих в заблуждение разрешений и чрезмерного доверия к брендированным интерфейсам. Приводите реальные примеры — фишинговые письма и окна согласия, — чтобы пользователи могли распознавать тревожные признаки.
Проводите имитации фишинга через согласие: Запускайте учебные фишинговые атаки, связанные с потоками OAuth, чтобы выработать у пользователей рефлексы и готовность к угрозам. Поощряйте пользователей сообщать о подозрительных запросах без страха.
Формализуйте процессы утверждения приложений: Требуйте, чтобы любая интеграция стороннего приложения, особенно запрашивающего чувствительные разрешения, проходила процесс согласования под руководством ИT-отдела до того, как кто-либо сможет предоставить согласие.
Кампании по информированию о политиках: Дополняйте техническое обучение плакатами, регулярными напоминаниями и обновлением политик. Сделайте безопасные решения о согласии постоянной темой, а не разовой настройкой «и забыть».
Отслеживайте теневые ИT со стороны пользователей: Сочетайте принудительное соблюдение процессов с технологиями, которые выявляют и блокируют попытки использовать несанкционированные SaaS-сервисы или неконтролируемых ИИ-агентов. Подробнее о решении проблемы теневого ИИ-ИT читайте в этом руководстве по управлению.

Гигиена разработки и рекомендации по безопасности приложений для ISV и CISO

Верификация издателя: Регистрируйте и верифицируйте издателей, чтобы повысить прозрачность приложений и доверие корпоративных покупателей.
Понятные и минимальные разрешения: Запрашивайте только минимально необходимые области доступа для работы функциональности. Избегайте избыточных запросов разрешений, которые вызывают подозрение у пользователей и риск отклонения.
Безопасные потоки согласия: Проектируйте страницы согласия с честными названиями приложений, понятными описаниями и явно указанной целью, чтобы предотвратить путаницу у пользователей и случайное одобрение.
Внедряйте практики безопасной разработки: Регулярно устанавливайте обновления для компонентов приложений и внедряйте конвейеры тестирования безопасности, чтобы блокировать уязвимости цепочки поставок.
Политика CISO: Требуйте внутренних проверок безопасности приложений, ведите актуальный реестр приложений и закрепляйте в документах позицию организации по рискам сторонних издателей до утверждения новых интеграций.

Также рекомендуем послушать

Если вы изучаете фишинг через согласие в Microsoft 365, эти выпуски добавят практического контекста по безопасному внедрению Microsoft 365, защите данных, управлению и управлению рисками ИИ.

Microsoft Purview – Simply Explained — Узнайте, как классификация, хранение, соответствие требованиям и защита вписываются в единую модель управления данными Microsoft.
Microsoft Defender XDR – Simply Explained — Свяжите средства защиты данных с обнаружением, расследованием и реагированием.
Conditional Access – Simply Explained — Поймите, как сигналы идентичности и риска добавляют контекст к решениям о доступе.
Microsoft AI Agent Harness – Simply Explained — Изучите средства контроля, которые делают автоматизацию с ИИ более надёжной, наблюдаемой и безопасной.

Эти выпуски помогут превратить идеи статьи в практические решения по проектированию и внедрению.