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

  • Статья

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

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

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

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

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

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

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

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

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

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

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

Примечание.

Модули 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. Почтовый ящик Параметры.*
  4. Люди.*
  5. Файлы.*
  6. Заметки.*
  7. Directory.AccessAsUser.All
  8. User_Impersonation

Первые семь разрешений в списке выше предназначены для Microsoft Graph и эквивалентов устаревших API, таких как Graph Azure Active Directory (Azure AD) и 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.

    apipermissions

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

    api

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

    типы разрешений

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

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

    examplepermission

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

    eduroster

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

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

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

[Рабочий процесс расследования предоставления согласия приложения]

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

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

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

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

  • Требования

    Убедитесь, что у вас есть доступ к клиенту в качестве глобальной Администратор. Это облачная учетная запись, которая не входит в локальную среду.

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

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

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

  • Роли

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

    • Права глобального администратора на клиенте для выполнения сценария
    • Локальная роль Администратор istrator на компьютере, с которого выполняется скрипт

  • Настройка 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 (для фильтрации).

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

    Пример заголовков столбцов

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

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

    Примечание.

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

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

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

    • Необычные или мрачные имена Пример необычного имени

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

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

Пример приложений с AllPrincipals ConsentType

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

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

Методы атак

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

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

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

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

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

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

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

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

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

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

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

  1. Откройте Центр безопасности и соответствия требованиям.

  2. Перейдите в раздел Поиск и выберите Поиск в журнале аудита.

  3. Выполните поиск (все действия и все пользователи) и введите дату начала и дату окончания (если требуется), а затем выберите "Поиск".

    Пример поиска в журнале аудита

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

    Пример фильтрации поиска в журнале аудита

  5. Если у вас имеется деятельность, на которую вы согласны предоставить согласие, продолжайте согласно нижеприведенным инструкциям.

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

  7. Проверьте, имеет ли значение Is Администратор Content значение True.

    Примечание.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание.

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

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

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

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

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

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

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

    Примечание.

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

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

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

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

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

Примечание.

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

согласие

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

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

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

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

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

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

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

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

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

Ссылки

Источником содержания настоящей статьи является следующее:

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

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

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