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

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

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

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

Предварительные требования

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

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

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

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

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

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

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

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

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

Install-Module -Name AzureAD -Verbose

Примечание

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

Загрузите сценарий 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 в манифесте приложения.

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

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

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

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

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

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

На высоком уровне мы наблюдали следующие «корневые» делегированные разрешения (приложение + пользователь), которые неправильно используются в фишинговых атаках по согласию. Корень соответствует высшему уровню. Например, Contacts.* означает включение всех делегированных перестановок разрешений на контакты: Contacts.Read, 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.

    apipermissions

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

    api

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

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

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

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

    examplepermission

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

    eduroster

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

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

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

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

Также можно:

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

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

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

  • Требования

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

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

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

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

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

    • Права глобального администратора на клиенте для выполнения сценария
    • Роль локального администратора на компьютере, с которого будет запускаться сценарий
  • Настройка PowerShell

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

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

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

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

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

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

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

Примечание

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

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

Вы можете использовать портал Azure Active Directory для поиска приложений, которым были предоставлены разрешения от лица любого отдельного пользователя.

  1. Войдите на портал Azure с использованием учетной записи администратора.
  2. Щелкните значок Azure Active Directory.
  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. После завершения сценария рекомендуется отключить сеанс Azure AD при помощи данной команды.

     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, такого как Azure AD.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  7. Проверьте, установлено ли для IsAdminContent значение «True».

    Примечание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание

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

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

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

Для предотвращения воздействия атак согласия на Azure AD и Office 365, см. следующие рекомендации:

Настройка политик

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

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

    Примечание

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

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

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

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

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

Примечание

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

согласие

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

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

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

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

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

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

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

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

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

Ссылки

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

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

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

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