Поделиться через

Согласие приложения на предоставление согласия

  • Статья

В настоящей статье представлены рекомендации по выявлению и расследованию атак на согласие приложений, защите информации и минимизации дальнейших рисков.

Эта статья состоит из следующих разделов:

  • Предварительные требования: охватывает перечень конкретных требований, которые необходимо выполнить перед началом расследования. Например, необходимо включить ведение журнала, среди прочего, требуются роли и разрешения.
  • Рабочий процесс: отображает логический процесс, которому необходимо следовать, чтобы провести расследование.
  • Контрольный список: содержит список задач для каждого из этапов блок-схемы. Этот контрольный список может быть полезным в строго регулируемых средах, чтобы проверить действия, предпринятые или просто как качественный шлюз для себя.
  • Этапы расследования: включает подробное пошаговое руководство для целей конкретного расследования.
  • Восстановление: содержит подробные инструкции по восстановлению/смягчению последствий атаки на предоставление согласия на незаконное приложение.
  • Ссылки: содержит дополнительные справочные материалы и материалы.

Необходимые компоненты

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

Данные клиентов

Чтобы начать расследование, вам понадобятся следующие данные:

  • Детализация индикаторов взлома (IoCs)
  • Дата и время обнаружения инцидента
  • Диапазон дат
  • Количество скомпрометированных учетных записей
  • Имя скомпрометированных учетных записей
  • Роли скомпрометированной учетной записи
  • Являются ли учетные записи привилегированными (GA Microsoft Exchange, SharePoint)?
  • Имеются ли какие-либо корпоративные приложения, связанные с возникновением инцидента?
  • Сообщали ли пользователи о любых приложениях, запрашивающих разрешения на данные от их имени?

Требования к системе

Убедитесь, что вы выполнили следующие требования к установке и настройке:

  • Устанавливается модуль AzureAD PowerShell.
  • У вас есть права глобального администратора на клиенте, на который выполняется скрипт.
  • На компьютере, используемом для запуска скриптов, назначена роль локального администратора.

Примечание.

Модули Azure AD и MSOnline PowerShell устарели с 30 марта 2024 г. Дополнительные сведения см. в обновлении об отмене. После этой даты поддержка этих модулей ограничена поддержкой миграции в пакет SDK Для Microsoft Graph PowerShell и исправления безопасности. Устаревшие модули будут продолжать функционировать до 30 марта 2025 года.

Рекомендуется перенести в Microsoft Graph PowerShell для взаимодействия с идентификатором Microsoft Entra (ранее — Azure AD). Часто задаваемые вопросы о миграции см. в разделе "Вопросы и ответы о миграции". Примечание. Версии 1.0.x MSOnline могут возникнуть сбоем после 30 июня 2024 г.

Установка модуля AzureAD

Воспользуйтесь данной командой для установки модуля AzureAD.

Install-Module -Name AzureAD -Verbose

Примечание.

Если вам будет предложено установить модули из ненадежного репозитория, введите Y и нажмите клавишу ВВОД.

Установите модуль MSOnline PowerShell

  1. Запустите приложение Windows PowerShell с повышенными привилегиями (запускайте от имени администратора).

  2. Воспользуйтесь данной командой, чтобы позволить PowerShell запускать подписанные сценарии.

    Set-ExecutionPolicy RemoteSigned

  3. Установите модуль MSOnline посредством данной команды.

    Install-Module -Name MSOnline -Verbose

    Примечание.

    Если вам будет предложено установить модули из ненадежного репозитория, введите Y и нажмите клавишу ВВОД.

Загрузите сценарий AzureADPSPermissions с GitHub

  1. Скачайте скрипт Get-AzureADPSPermissions.ps1 из GitHub в папку, из которой выполняется скрипт. Выходной файл "permissions.csv" также записывается в ту же папку.

  2. Откройте экземпляр PowerShell от имени администратора и откройте папку, в которой вы сохранили скрипт.

  3. Подключитесь к своему каталогу с помощью командлета Connect-AzureAD. Рассмотрим пример.

    Connect-AzureAD -tenantid "2b1a14ac-2956-442f-9577-1234567890ab" -AccountId "user1@contoso.onmicrosoft.com"

  4. Запустите данную команду PowerShell.

    Get-AzureADPSPermissions.ps1 | Export-csv -Path "Permissions.csv" -NoTypeInformation

    Отключите сеанс AzureAD при помощи данной команды.

    Disconnect-AzureAD

Согласие — это процесс предоставления авторизации приложению для доступа к защищенным ресурсам от имени пользователей. Администратора или пользователя можно попросить предоставить согласие на доступ к данным своей организации/отдельным лицам.

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

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

Примечание.

Позволяя пользователям предоставлять приложениям доступ к данным, вы даете им возможность легко получать полезные приложения и работать продуктивно. Однако в некоторых ситуациях эта конфигурация может представлять опасность, если она не отслеживается и не контролируется тщательно.

Чтобы предоставить согласие администратора на уровне клиента, необходимо войти по крайней мере с одной из следующих ролей:

  • Администратор приложений
  • Администратор облачных приложений
  • Администратор - означает, что согласие было предоставлено администратором (от имени организации)
  • Отдельный пользователь— указывает, что согласие предоставлено пользователем и имеет доступ только к данным этого пользователя.
  • Допустимые значения
    • AllPrincipals - с согласия администратора на весь объем владения
    • Principal - согласие отдельного пользователя на данные, относящиеся исключительной к данной учетной записи

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

  • Процесс предоставления согласия пользователем - Разработчик приложения направляет пользователей к конечной точке авторизации с целью зафиксировать согласие только для текущего пользователя.

  • Процесс получения согласия администратора - Разработчик приложения направляет пользователей к конечной точке авторизации администратора с целью зафиксировать согласие для всего клиента. Для правильной работы процесса предоставления согласия администратора разработчики приложений должны перечислить все разрешения в свойстве RequiredResourceAccess в манифесте приложения.

Делегированные разрешения и разрешения приложений

Делегированные разрешения используются приложениями, в которых присутствует вошедший в систему пользователь и которые могут иметь согласие, примененное администратором или пользователем.

Разрешения приложений используются приложениями, которые работают без вошедшего в систему пользователя. Например, приложения, которые работают как фоновые службы или управляющие программы. Разрешения приложения могут быть подтверждены только администратором.

Дополнительные сведения см. в разделе:

Классификация рискованных разрешений

В системе существуют тысячи (по крайней мере) разрешений, и невозможно перечислить или проанализировать все из них. В следующем списке рассматриваются часто неправильные разрешения и другие, которые будут создавать катастрофические последствия при неправильном использовании.

На высоком уровне корпорация Майкрософт наблюдала следующие делегированные разрешения (App+User) при фишинге согласия. Корень соответствует высшему уровню. Например, Contacts.* означает, что все делегированные перемутации разрешений контактов: Contacts.Read, Contacts.ReadWrite, Contacts.ReadWrite, Contacts.Read.Shared и Contacts.ReadWrite.Shared.

  1. Mail.* (включая Mail.Send*, но не Mail.ReadBasic*)
  2. Контакты. *
  3. MailboxSettings.*
  4. Народ.*
  5. Файлы.*
  6. Примечания.*
  7. Directory.AccessAsUser.All
  8. User_Impersonation

Первые семь разрешений в предыдущем списке предназначены для Microsoft Graph и эквивалентов устаревших API, таких как Azure Active Directory (Azure AD) Graph и Outlook REST. Восьмое разрешение предназначено для Azure Resource Manager (ARM) и может быть опасным для любого API, который предоставляет конфиденциальные данные с этой областью олицетворения.

На основе наблюдений группы реагирования на инциденты Майкрософт злоумышленники используют сочетание первых шести разрешений в 99% от фишинговых атак согласия. Большинство людей не считают делегированную версию Mail.Read или Files.Read как разрешение на высокий риск, однако атаки обычно широко распространены и целевые пользователи, а не копье фишинга от администраторов, которые могут на самом деле согласиться с опасными разрешениями. Рекомендуется пузырьковые приложения с этими "критически важными" уровнями разрешений влияния. Даже если приложения не имеют злонамеренных намерений, и если плохой субъект должен был скомпрометировать удостоверение приложения, то вся ваша организация может быть подвержена риску.

Для получения разрешений на максимальное воздействие риска начните с нижеперечисленного:

  • Разрешение приложения (AppOnly/AppRole) версии всех вышеперечисленных разрешений, если применимо

Делегированные версии и версии AppOnly следующих разрешений:

  • Application.ReadWrite.All
  • Directory.ReadWrite.All;
  • Domain.ReadWrite.All*
  • EduRoster.ReadWrite.All*
  • Group.ReadWrite.All;
  • Member.Read.Hidden*
  • RoleManagement.ReadWrite.Directory
  • User.ReadWrite.All*
  • User.ManageCreds.All
  • Все остальные разрешения AppOnly, разрешающие доступ на запись

Чтобы просмотреть список разрешений с минимальным воздействием риска, начните с нижеперечисленного:

  • User.Read
  • User.ReadBasic.All
  • Open_id
  • Эл. почта
  • Профиль
  • Offline_access (только если они связаны с другими разрешениями в этом списке "самый низкий риск")

Просмотр разрешений

  1. Чтобы просмотреть разрешения, перейдите на экран Регистрация в корпоративном приложении.

    Снимок экрана: просмотр различных разрешений.

  2. Выберите Просмотр разрешений API.

    Снимок экрана: просмотр и добавление разрешений API.

  3. Выберите Добавить разрешение, в результате чего отобразится следующий экран.

    Снимок экрана: запрос разрешений API.

  4. Выберите Microsoft Graph, чтобы просмотреть различные типы разрешений.

    Снимок экрана: различные типы разрешений API.

  5. Выберите тип разрешений, которые использует зарегистрированное приложение: Делегированные разрешения или разрешения для приложения. На вышеприведенном изображении выбрано Разрешения приложения.

  6. Вы можете выполнить поиск по одному из разрешений с высоким уровнем риска, например EduRoster.

    Снимок экрана: пример запроса на разрешение API.

  7. Выберите EduRoster и разверните разрешения.

    Снимок экрана: элемент разрешения API с подсказкой.

  8. Теперь вы можете назначить или просмотреть данные разрешения.

    Дополнительные сведения см . в разделе "Разрешения Graph".

Рабочий процесс

[Блок-схема рабочего процесса предоставления согласия приложения.]

Кроме того, вы можете сделать следующее:

  • Скачайте рабочие процессы сборника схем со способами реагирования на предоставление согласия для приложения и другие инциденты в виде PDF-файла.
  • Скачайте рабочие процессы сборника схем со способами реагирования на предоставление согласия для приложения и другие инциденты в виде файла Visio.

Контрольный список

Используйте данный контрольный список для проверки предоставления согласия приложения.

  • Индикаторы компрометации (IoC)

    Проверьте следующие индикаторы компрометации (IoC):

    • В какой момент вы обнаружили инцидент?
    • Диапазон дат инцидента (насколько крайним левым является целевой показатель?)
    • Количество скомпрометированных учетных записей
    • Имена скомпрометированных учетных записей
    • Роли скомпрометированных учетных записей
    • Имеют ли скомпрометированные учетные записи высокий уровень привилегий, уровень привилегий стандартного пользователя или какое-либо сочетание таких привилегий?

  • Роли

    Вам должны быть назначены следующие роли:

    • Роль локального администратора на компьютере, с которого выполняется скрипт

  • Настройка PowerShell

    Настройте среду PowerShell следующим образом:

    1. Установите модуль Azure AD PowerShell.
    2. Запустите приложение Windows PowerShell с повышенными привилегиями. (Запустите от имени администратора).
    3. Настройте PowerShell для запуска подписанных сценариев.
    4. Загрузите сценарий Get-AzureADPSPermissions.ps1.

  • Триггеры расследования

    • Компрометация учетной записи
    • Настройки согласия приложения на клиенте изменены
    • Причина статуса события оповещения/аудита "Обнаружено опасное приложение"
    • Были замечены странно выглядящие приложения

Другие контрольные списки сборника схем со способами реагирования на предоставление согласия для приложения и другие инциденты можно также скачать в виде файла Excel.

Шаги для исследования

Вы можете использовать следующие два метода для исследования предоставления согласия приложения:

  • Портал Azure
  • Сценарий PowerShell

Примечание.

Использование портал Azure позволяет просматривать только разрешения администратора за последние 90 дней и на основе этого рекомендуется использовать метод скрипта PowerShell только для уменьшения шагов расследования злоумышленников.

Метод 1 – Использование портала Azure

Центр администрирования Microsoft Entra можно использовать для поиска приложений, которым отдельные пользователи предоставили разрешения.

  1. Выполните вход на портал Azure в качестве администратора.
  2. Выберите значок идентификатора Microsoft Entra.
  3. Выберите Пользователи.
  4. Выберите пользователя, которого хотите просмотреть.
  5. Выберите пункт Заявления.
  6. Вы можете увидеть список приложений, которые назначены пользователю, и какие разрешения у этих приложений.

Метод 2 - Использование PowerShell

Существует несколько инструментов PowerShell, которые можно использовать для расследования незаконных случаев предоставления согласия, например следующие:

  • Инструмент HAWK
  • Модуль реагирования на инциденты AzureAD
  • Скрипт Get-AzureADPSPermissions.ps1 из GitHub

PowerShell — это самый простой инструмент и не требует изменения ничего в клиенте. Мы будем основывать наше расследование на общественной документации из нападения на незаконное предоставление согласия.

Запустите Get-AzureADPSPermissions.ps1, чтобы экспортировать все разрешения на согласие OAuth и приложения OAuth для всех пользователей вашего клиента в файл .csv. См. раздел Предварительные требования, чтобы загрузить и запустить сценарий Get-AzureADPSPermissions.

  1. Откройте экземпляр PowerShell от имени администратора и откройте папку, в которой вы сохранили скрипт.

  2. Подключитесь к своему каталогу при помощи следующей команды Connect-AzureAD. Рассмотрим пример.

    Connect-AzureAD -tenantid "2b1a14ac-2956-442f-9577-1234567890ab" -AccountId "user1@contoso.onmicrosoft.com"

  3. Запустите данную команду PowerShell.

    Get-AzureADPSPermissions.ps1 | Export-csv c:\temp\consentgrants\Permissions.csv -NoTypeInformation

  4. После завершения скрипта рекомендуется отключить сеанс Microsoft Entra с этой командой.

     Disconnect-AzureAD

    Примечание.

    Выполнение скрипта может занять несколько часов в зависимости от размера и разрешений, настроенных, а также подключения.

  5. Сценарий создает файл с именем Permissions.csv.

  6. Откройте файл, а затем отфильтруйте или отформатируйте данные в таблицу и сохраните его в виде .xlxs файла.

    На указанном изображении показаны заголовки столбцов для вывода.

    Снимок экрана: заголовки столбцов Excel.

  7. В столбце ConsentType (G) найдите значение AllPrinciples. Разрешение AllPrincipals позволяет клиентскому приложению получать доступ к любому контенту в рамках клиента. Наличие данного разрешения требуется для правильной работы собственных приложений Microsoft 365. Все приложения сторонних производителей с данным типом разрешения должны быть тщательно проверены.

  8. В столбце Разрешение (F) просмотрите разрешения, которые есть у каждого делегированного приложения. Найдите разрешение на чтение и запись или *. Все разрешения и внимательно просмотрите эти разрешения, так как они могут быть не подходящими. Снимок экрана: разрешения приложения в столбце F.

    Примечание.

    Просмотрите конкретных пользователей, получивших согласие. Если высокопоставленные или влиятельные пользователи предоставили ненадлежащее согласие, вам следует провести дополнительное расследование.

  9. В столбце ClientDisplayName(C) найдите приложения, которые кажутся подозрительными, например:

    • Приложения с именами с ошибками Снимок экрана: пример неправильного имени.

    • Необычные или мрачные имена Снимок экрана: пример необычного имени.

    • Имена звуковых сигналов хакера. Вам необходимо внимательно просмотреть данные имена. Снимок экрана: пример имени хакера.

Пример выходных данных: AllPrincipals и чтение, запись все. Приложения могут не иметь каких-либо подозрительных имен, таких как bland name и использовать MS Graph. Тем не менее, необходимо провести проверку и определить назначение приложений и фактические разрешения, которые приложения имеют в клиенте, как показано в данном примере.

Снимок экрана: пример приложений с параметром AllPrincipals ConsentType.

Ниже приведены несколько полезных советов по проверке расследований политики информационной безопасности (ISP):

  • ReplyURL/RedirectURL
    • Обращайте внимание на подозрительные URL
  • URL-адрес размещен в подозрительном домене?
    • Скомпрометирован ли он?
    • Домен недавно зарегистрирован?
    • Является ли домен временным?
  • Существуют ли условия соглашения об обслуживании и обслуживании в регистрации приложения?
  • Является ли содержимое уникальным и характерным для приложения или издателя?
  • Клиент зарегистрировал приложение как недавно созданный или скомпрометированный (например, приложение, зарегистрированное пользователем с риском)?

Методы атак

Несмотря на то, что каждая атака имеет свой тенденцию, основные методики атак представлены следующими:

  • Злоумышленник регистрирует приложение с помощью поставщика OAuth 2.0, например идентификатора Microsoft Entra.

  • Приложения настроены таким образом, чтобы они выглядели законными. Например, злоумышленники могут использовать название популярного продукта, доступного в той же экосистеме.

  • Злоумышленник получает ссылку непосредственно от пользователей, которые могут выполняться с помощью обычного фишинга на основе электронной почты, компрометируя невредимый веб-сайт или с помощью других методов.

  • Пользователь выбирает ссылку, и ему отображается запрос подлинного согласия с просьбой предоставить вредоносному приложению разрешения на доступ к данным.

  • Если пользователь выбирает "Принять", он предоставляет приложению разрешения на доступ к конфиденциальным данным.

  • Приложение получает код авторизации, который используется для получения маркера доступа и, возможно, маркера обновления.

  • Маркер доступа используется для выполнения вызовов API от имени пользователя.

  • Если пользователь принимает, злоумышленник может получить доступ к почте пользователя, переадресации правил, файлов, контактов, примечаний, профилей и других конфиденциальных данных и ресурсов.

    Снимок экрана: пример запроса разрешений.

Обнаружение признаков атаки

  1. На портале https://security.microsoft.comMicrosoft 365 Defender перейдите в раздел "Аудит". Или перейти непосредственно на страницу аудита , используйте https://security.microsoft.com/auditlogsearch.

  2. На странице аудита выполните поиск всех действий и всех пользователей, введите дату начала и дату окончания при необходимости, а затем нажмите кнопку "Поиск".

    Снимок экрана: пример поиска в журнале аудита.

  3. Выберите результаты Фильтр и в поле Действия введите Согласие в приложении.

    Снимок экрана: пример фильтрации поиска в журнале аудита.

  4. Если у вас есть действие, предоставленное согласием, перейдите к следующему шагу.

  5. Выберите результат, чтобы просмотреть подробную информацию о действии. Выберите Дополнительная информация, чтобы получить подробную информацию о действии.

  6. Проверьте, задано ли значение IsAdminContent значение True.

    Примечание.

    Процедура проверки может занять от 30 минут до 24 часов для отображения соответствующей записи журнала аудита в результатах поиска после возникновения события.

    Продолжительность времени, в течение которого запись аудита сохраняется и доступна для поиска в журнале аудита, зависит от вашей подписки на Microsoft 365 и, в частности, от типа лицензии, назначенной конкретному пользователю. Если это значение имеет значение true, это означает, что у кого-то может быть широкий доступ к данным. Если это непредвиденное, выполните немедленные шаги для подтверждения атаки.

Как подтвердить атаку?

Если у вас есть один или несколько экземпляров ранее перечисленных ioCs, необходимо выполнить дальнейшее исследование, чтобы подтвердить, что произошла атака.

Инвентаризация приложений, к которым имеется доступ в вашей организации

Вы можете инвентаризации приложений для пользователей с помощью Центра администрирования Microsoft Entra, PowerShell или отдельно перечислить доступ к приложению.

  • Используйте Центр администрирования Microsoft Entra для инвентаризации приложений и их разрешений. Указанный метод является весьма тщательным, однако вы можете проверять только одного пользователя за раз, что может занять много времени, если вам нужно проверить разрешения нескольких пользователей.
  • Используйте PowerShell для инвентаризации приложений и их разрешений. Данный метод является самым быстрым и тщательным, с наименьшими накладными расходами.
  • Поощряйте своих пользователей индивидуально проверять свои приложения и разрешения и сообщать о результатах администраторам для исправления.

Инвентаризация приложений, назначенных пользователям

Центр администрирования Microsoft Entra можно использовать для просмотра списка приложений, которым предоставили отдельные пользователи разрешения.

  1. Войдите на портал Azure с правами администратора.
  2. Выберите значок идентификатора Microsoft Entra.
  3. Выберите Пользователи.
  4. Выберите пользователя, которого хотите просмотреть.
  5. Выберите пункт Заявления.

Вы можете увидеть список приложений, назначенных пользователю, и разрешения, предоставленные данным приложениям.

Определите масштаб атаки

После завершения доступа к приложению инвентаризации просмотрите журнал аудита, чтобы определить полную область нарушения. Найдите затронутых пользователей, сроки, в течение которых незаконное приложение имело доступ к вашей организации, и разрешения, которые было у приложения. Журнал аудита можно выполнить в microsoft 365 Security и Портал соответствия требованиям Microsoft Purview.

Внимание

Если аудит не был включен до возможной атаки, вы не сможете исследовать, так как данные аудита недоступны.

Как предотвратить атаки и снизить риски?

Если у вашей организации имеется соответствующая лицензия:

  • Используйте дополнительные функции аудита приложений OAuth в Microsoft Defender для облака Apps.
  • Используйте книги Azure Monitor для отслеживания действий, связанных с разрешениями и согласием. Книга Consent Insights позволяет просматривать список приложений по количеству неподтвержденных запросов на согласие. Это может быть полезно для определения приоритетов приложений, которые администраторы могут просматривать и решать, давать ли им согласие администратора.

После идентификации приложения с незаконными разрешениями немедленно отключите приложение , следуя инструкциям в разделе "Отключить приложение". Затем обратитесь к служба поддержки Майкрософт, чтобы сообщить о вредоносном приложении.

После отключения приложения в Microsoft Entra он не может получить новые маркеры для доступа к данным, а другие пользователи не могут войти или предоставить согласие приложению.

Примечание.

Если вы подозреваете, что вы столкнулись с вредоносным приложением в вашей организации, лучше отключить его, чем удалить его. При удалении приложения он может вернуться позже, если другой пользователь предоставляет согласие. Вместо этого отключите приложение, чтобы убедиться, что он не может вернуться позже.

Этапы защиты вашей организации

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

Чтобы предотвратить атаки на согласие, повлиять на идентификатор Microsoft Entra и Office 365, ознакомьтесь со следующими рекомендациями.

Установка политик

  • Этот параметр имеет последствия для пользователя и может не применяться для среды. Если вы собираетесь разрешить какие-либо разрешения, убедитесь, что администраторы утверждают запросы.

  • Предоставьте согласие для приложений только от проверенных издателей и определенные типы разрешений, классифицируемые как незначительные.

    Примечание.

    Вышеприведенные рекомендации основаны на наиболее идеальных и безопасных конфигурациях. Однако, поскольку безопасность является тонким балансом между функциональными возможностями и операциями, наиболее безопасные конфигурации могут привести к большей нагрузке администраторам. Лучше всего принять решение после консультаций с администраторами.

    Настроить согласие на повышение с учетом рисков - включено по умолчанию, если разрешено согласие пользователя на предоставление грантов

  • Повышение уровня согласия на основе рисков позволяет снизить уязвимость пользователей для вредоносных приложений, которые делают незаконные запросы на согласие. Если корпорация Майкрософт обнаруживает рискованные запросы на согласие пользователей, запросу требуется "шаг", чтобы предоставить согласие администратора. Эта возможность включена по умолчанию, но она приводит только к изменению поведения при включении согласия конечного пользователя.

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

    AADSTS90094: <clientAppDisplayName> требует разрешения на доступ к ресурсам в организации, которым может предоставить только администратор. Попросите администратора предоставить разрешение для этого приложения, прежде чем его можно будет использовать. В этом случае событие аудита также будет зарегистрировано с помощью категории "ApplicationManagement" типа действия "Согласие на приложение", а также причину состояния "Обнаружено рискованное приложение".

Примечание.

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

Снимок экрана: пример разрешений согласия.

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

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

Обучите свою организацию тактике согласия (тактика фишинга, согласие администратора и пользователя ):

  • Проверьте орфографию и грамматику. Если сообщение электронной почты или экран согласия приложения имеет орфографические и грамматические ошибки, скорее всего, это подозрительное приложение.
  • Внимательно следите за именами приложений и URL-адресами доменов. Злоумышленники любят подделывать названия приложений, которые создают впечатление, что они принадлежат законным приложениям или компаниям, но вынуждают вас дать согласие на использование вредоносного приложения.
  • Убедитесь, что вы узнали имя приложения и URL-адрес домена, прежде чем соглашаться на приложение.

Повышайте уровень и разрешайте доступ к приложениям, которым вы доверяете

  • Повышение использования приложений, проверенных издателем. Проверка издателя помогает администраторам и конечным пользователям понять подлинность разработчиков приложений. До сих пор проверяются более 660 приложений на 390 издателей.
  • Настройте политики согласия приложений, разрешив пользователям давать согласие только на определенные приложения, которым вы доверяете, например приложения, разработанные вашей организацией или от проверенных издателей.
  • Расскажите своей организации о том, как работает наша структура разрешений и согласия.
  • Разберитесь, какие данные и разрешения запрашивает приложение, и поймите, как разрешения и согласие работают на нашей платформе.
  • Убедитесь, что администраторы знают, как управлять запросами на согласие и оценивать их.

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

Устранение проблем

  • Обучите клиентов и обеспечьте осведомленность и обучение по защите разрешение не предоставление согласия приложений
  • Упростите процедуру предоставления согласия приложений с помощью организационной политики и технических средств контроля
  • Настройте Составьте расписание для просмотра одобренных приложений
  • PowerShell можно использовать для отключения подозрительных или вредоносных приложений, отключив приложение.

Связанный контент

Дополнительные инструкции по реагированию на инциденты

Изучите руководство по выявлению и расследованию этих дополнительных типов атак:

Ресурсы по реагированию на инциденты