Как эффективно управлять субъектами-службами в Entra ID

By Mirko Peters · 2026-03-22 · Updated 2026-03-24

Защитите субъекты-службы в Microsoft Entra ID для более надежного управления идентификацией. Узнайте об объектах приложений и субъектов-служб в вашем клиенте.

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

Управление субъектами-службами и регистрациями приложений в Entra ID имеет решающее значение для поддержания безопасности и контроля доступа. Грамотное управление помогает предотвращать серьезные инциденты безопасности, такие как повышение привилегий и компрометация клиента. Например, злоумышленники могут использовать плохо управляемые субъекты-службы, чтобы сбросить пароли администраторов и получить несанкционированный доступ к важным системам. Применяя надежные практики управления, вы можете снизить эти риски и обеспечить безопасность среды. Ключевые шаги включают понимание субъектов-служб, назначение подходящих разрешений и регулярную проверку политик доступа.

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

1. Субъекты-службы отличаются от объектов приложений: объект приложения представляет собой глобальное определение приложения, а субъект-служба — это локальная идентичность в клиенте. Один объект приложения может иметь несколько субъектов-служб в разных клиентах.
2. Их учетные данные могут не иметь срока действия: Entra ID позволяет создавать клиентские секреты или сертификаты без срока истечения, как по замыслу, так и из-за ошибки конфигурации, что повышает долгосрочный риск, если их не ротировать вручную.
3. Управляемые идентификаторы работают на основе субъектов-служб: И системно назначаемые, и пользовательски назначаемые управляемые идентификаторы представлены в каталоге как субъекты-службы, поэтому к ним могут применяться RBAC и политики условного доступа.
4. Субъекты-службы можно использовать в условном доступе: Хотя условный доступ в первую очередь ориентирован на пользователей, он может учитывать контекст приложений, и некоторые политики способны влиять на субъекты-службы, особенно в сочетании с контекстом аутентификации приложения.
5. Они одновременно поддерживают делегированные разрешения и разрешения приложения: Один субъект-служба может иметь как делегированные разрешения (от имени пользователя), так и разрешения приложения (только для приложения), что усложняет соблюдение принципа минимальных привилегий.
6. Журналы входа включают неинтерактивную аутентификацию приложений: Entra ID записывает входы субъектов-служб, что позволяет обнаруживать аномальную активность приложений, однако эти журналы часто упускают из виду по сравнению с входами пользователей.
7. Управление согласием и правами может создавать скрытые пути доступа: Корпоративные приложения и субъекты-службы, получившие доступ через согласие администратора или управление правами, могут создавать косвенные пути доступа, которые трудно обнаружить без тщательных проверок прав и разрешений.

Главное

• Поймите разницу между регистрациями приложений и субъектами-службами в Entra ID.
• Убедитесь, что у вас есть необходимые разрешения, прежде чем управлять субъектами-службами, чтобы избежать препятствий.
• Следуйте четкому процессу регистрации приложений в Entra ID, включая заполнение всех необходимых сведений.
• Используйте несколько методов аутентификации, чтобы повысить безопасность ваших приложений.
• Внедрите управление доступом на основе ролей (RBAC), чтобы назначать субъектам-службам подходящие разрешения.
• Регулярно проверяйте политики доступа, чтобы они соответствовали рекомендациям по безопасности.
• Проводите аудиты, чтобы отслеживать изменения и выявлять несанкционированный доступ или действия.
• Придерживайтесь принципа наименьших привилегий, предоставляя субъектам-службам только необходимые разрешения.

Предварительные требования для управления Entra ID

Понимание субъектов-служб

Прежде чем управлять субъектами-службами в Entra ID, необходимо освоить некоторые базовые понятия. Вот ключевые моменты, которые нужно понять:

• Регистрация приложения (App) — это глобально уникальный объект, представляющий приложение в Entra ID.
• Субъект-служба (SP) — это конкретный экземпляр объекта приложения в пределах одного клиента.
• Когда вы создаёте регистрацию приложения, в том же клиенте автоматически создаётся субъект-служба (service principal).
• У субъектов-служб есть собственные учётные данные и разрешения, которые отличаются от объекта приложения.
• Действия в клиенте, например создание пользователя, выполняются субъектом-службой.

Портал Entra ID может сбивать с толку. Субъекты-службы отображаются в разделе «Корпоративные приложения», а термин «Service Principal» используется редко. Из-за этого могут возникать недоразумения о связи между регистрациями приложений и субъектами-службами.

Необходимые разрешения

Чтобы эффективно управлять субъектами-службами, нужны соответствующие разрешения. Вот краткий обзор основных предварительных требований:

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

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

Регистрация приложений в Entra ID

Шаги регистрации приложения

Регистрация приложения в Entra ID — несложный процесс. Чтобы начать, выполните следующие шаги:

1. Войдите на портал Entra ID: используйте учётную запись Microsoft Entra, чтобы открыть портал.
2. Перейдите в раздел регистраций приложений: в меню слева выберите «Регистрации приложений».
3. Нажмите «Новая регистрация»: этот пункт позволяет создать новое приложение.
4. Заполните сведения о приложении:
   • Имя: выберите уникальное имя для вашего приложения.
   • Поддерживаемые типы учётных записей: укажите, кто может использовать приложение (например, только учётные записи в этом каталоге организации).
   • Redirect URI: укажите URI, на который пользователи будут перенаправлены после аутентификации. Это критически важно для веб-приложений.
5. Проверьте и зарегистрируйте: после заполнения необходимых сведений нажмите «Зарегистрировать», чтобы создать приложение.

После регистрации в одном клиенте с бесплатной редакцией можно создать до 50 000 ресурсов Microsoft Entra. Если вы подтвердите домен, этот лимит может быть увеличен до 300 000 ресурсов. Также можно настроить учётные данные для максимум 48 приложений с единым входом на основе пароля.

Настройка параметров приложения

После регистрации приложения нужно настроить его параметры для оптимальной безопасности и функциональности. Вот несколько рекомендаций:

1. Настройте несколько методов аутентификации Entra ID: используйте различные методы аутентификации, например многофакторную аутентификацию (MFA) и аутентификацию без пароля, чтобы повысить безопасность.
2. Используйте группы Entra ID для назначения разрешений: создавайте группы пользователей для эффективного управления доступом. Так пользователи получают только необходимые разрешения.
3. Используйте политики условного доступа (CAP): внедряйте CAP, чтобы задавать условия доступа к ресурсам. Это добавляет дополнительный уровень безопасности благодаря детальному контролю.

Кроме того, рассмотрите возможность проведения инвентаризации приложений. Определите и составьте каталог всех приложений, подключённых к Entra, для эффективного управления. Регулярно оценивайте разрешения, назначенные каждому приложению, чтобы строить стратегию безопасности. Отключайте неиспользуемые приложения, чтобы сократить поверхность атаки.

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

Назначение ролей для субъектов-служб

Обзор RBAC

Управление доступом на основе ролей (RBAC) — важная функция Entra ID. Она помогает контролировать, кто и к каким ресурсам организации может обращаться. С помощью RBAC вы можете назначать роли субъектам-службам, гарантируя, что у них есть нужные разрешения для выполнения задач, без ущерба для безопасности.

В Entra ID существуют два типа определений ролей:

• Встроенные роли: имеют фиксированный набор разрешений. Их нельзя изменить, но они покрывают типовые сценарии.
• Пользовательские роли: позволяют точно настроить разрешения под конкретные потребности. Создание пользовательской роли включает два этапа: определение роли и её назначение.

Понимание этих типов ролей поможет выбрать подходящий подход для ваших приложений. Подробнее об RBAC можно узнать в обзоре управления доступом на основе ролей.

Назначение ролей

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

1. Создание назначений ролей: используйте центр администрирования Microsoft Entra, Microsoft Graph PowerShell или Microsoft Graph API. Учтите, что Azure CLI для этой задачи не поддерживается.
2. Регистрация приложения: убедитесь, что вы зарегистрировали приложение Microsoft Entra и создали субъект-службу через портал Azure.
3. Выбор подходящей роли: изучите доступные роли, чтобы определить, какая из них предоставляет необходимые разрешения для вашего приложения.

Ниже — краткая справочная таблица с описанием процесса назначения ролей:

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

Методы аутентификации для Entra ID

Обзор аутентификации

При управлении субъектами-службами в Entra ID доступны два основных метода аутентификации: аутентификация по клиентскому секрету и аутентификация на основе сертификатов. У каждого метода есть свои преимущества и сценарии использования.

Аутентификация по клиентскому секрету

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

• Плюсы:

  • Легко реализовать.
  • Подходит для сред тестирования и разработки.

• Минусы:

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

Аутентификация на основе сертификатов

Аутентификация на основе сертификатов использует цифровой сертификат для аутентификации субъекта-службы. Этот метод безопаснее клиентских секретов и рекомендуется для производственных сред. Для максимальной безопасности используйте доверенный сертификат, выданный центром сертификации (ЦС). Самоподписанные сертификаты можно применять для тестирования, но для производственной среды они не рекомендуются.

• Плюсы:

  • Более высокий уровень безопасности.
  • Снижает риск кражи учётных данных.

• Минусы:

  • Более сложная настройка.
  • Требует управления сертификатами.

Настройка аутентификации

Чтобы настроить аутентификацию для вашего субъекта-службы в Entra ID, выполните следующие шаги:

1. Откройте главную страницу центра администрирования Microsoft Entra.
2. Перейдите в раздел Entra ID » Регистрации приложений и выберите ваше приложение.
3. На странице обзора приложения скопируйте значение «Идентификатор каталога (клиента)» и сохраните его в коде вашего приложения.
4. Скопируйте значение «Идентификатор приложения (клиента)» и сохраните его в коде вашего приложения.
5. Выберите между аутентификацией на основе сертификата или клиентского секрета. Рекомендуется загрузить доверенный сертификат, выданный центром сертификации.
6. Если вы используете сертификат, загрузите его через Entra ID » Регистрации приложений » Сертификаты и секреты » Отправить сертификат.
7. Если вы используете клиентский секрет, создайте его через Entra ID » Регистрации приложений » Сертификаты и секреты » Секреты клиента » Новый секрет клиента.

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

Политики доступа в Entra ID

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

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

• Требовать MFA для рискованных входов: эта политика предлагает пользователю пройти многофакторную аутентификацию, когда вход выглядит подозрительно.
• Блокировать или устранять последствия компрометации учётных записей: эта политика автоматически ограничивает доступ к учётным записям, у которых обнаружены признаки компрометации.

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

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

Настройка политик доступа для субъектов-служб в Entra ID несложна. Следуйте этим шагам, чтобы эффективно настроить политики:

1. Войдите в центр администрирования Microsoft Entra и перейдите в раздел Entra ID » Корпоративные приложения.
2. Выберите субъект-службу, который хотите ограничить, и откройте раздел Свойства на вкладке «Управление».
3. Установите для параметра Включено для входа пользователей? значение Нет и нажмите «Сохранить», чтобы отключить вход пользователей в приложение.
4. Чтобы создать политику условного доступа, войдите в центр администрирования Microsoft Entra и перейдите в раздел Entra ID » Условный доступ.
5. Нажмите +Создать политику и введите имя политики.
6. В разделе «Назначения» перейдите в Пользователи или удостоверения рабочей нагрузки.
7. Выберите Удостоверения рабочей нагрузки в поле «К чему применяется эта политика». В разделе «Включить» нажмите Выбрать субъекты-службы и выберите нужные субъекты-службы из списка.
8. В разделе «Целевые ресурсы» перейдите в «Включить» и выберите Все ресурсы (ранее «Все облачные приложения»).
9. В разделе «Условия» настройте конкретные требования, определяющие, когда должна срабатывать политика.
10. В разделе «Элементы управления доступом» перейдите к «Предоставление», выберите Блокировать доступ и нажмите «Выбрать».
11. Установите для параметра Включить политику значение Вкл. и нажмите «Создать», чтобы создать политику условного доступа для удостоверений рабочей нагрузки Microsoft Entra.

Следуя этим шагам, вы сможете гарантировать, что ваши субъекты-службы работают в условиях строгого контроля доступа. Это не только защищает ваши ресурсы, но и соответствует лучшим практикам в области безопасности и соответствия требованиям.

Лучшие практики для субъектов-служб

Рекомендации по безопасности

Чтобы защитить ваши субъекты-службы в Entra ID, следуйте этим рекомендациям по безопасности:

• Используйте клиентские сертификаты вместо клиентских секретов для повышения безопасности.
• Используйте Azure Key Vault для безопасного управления сертификатами и секретами.
• Применяйте для субъектов-служб принцип наименьших привилегий. Это означает предоставление только тех разрешений, которые необходимы для их задач.
• Отслеживайте входы субъектов-служб через журналы входа Microsoft Entra. Это помогает обнаруживать необычную активность.
• Используйте условный доступ, чтобы ограничить доступ из недоверенных расположений. Это добавляет дополнительный уровень защиты.
• Регулярно проверяйте состав участников ролей уровня 0, чтобы убедиться, что уровень привилегий соответствует задачам. Это предотвращает несанкционированный доступ к важным ресурсам.

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

Регулярные аудиты

Регулярные аудиты необходимы для поддержания безопасности и целостности ваших субъектов-служб. Ниже перечислены распространённые практики аудита, которые вам стоит внедрить:

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

Следуя этим лучшим практикам, вы сможете эффективно управлять субъектами-службами в Entra ID, повышая как безопасность, так и соответствие требованиям.

Итак, эффективное управление субъектами-службами в Entra ID включает несколько ключевых шагов и лучших практик. Вам следует:

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

Постоянное управление имеет решающее значение. Удобство самообслуживания увеличивает потребность в совершенствовании управления доступом. Регулярные проверки помогают сохранять контроль над правами доступа. Каждая гостевая учётная запись должна иметь внутреннего владельца, отвечающего за постоянное обоснование доступа. Применяя эти стратегии, вы повысите безопасность и обеспечите эффективное управление своими субъектами-службами.

Этот чек-лист поможет внедрить лучшие практики эффективного управления субъектами-службами в Entra ID.

• Инвентаризация и обнаружение: определите все субъекты-службы в клиентах и подписках (создайте регулярно повторяющееся сканирование или отчёт).
• Сопоставление с приложениями и владельцами: свяжите каждый субъект-службу с соответствующим приложением, бизнес-владельцем и контактом службы поддержки.
• Классификация доступа и назначения: задокументируйте назначение, среду (prod/dev/test) и необходимые разрешения для каждого субъекта-службы.
• Принцип наименьших привилегий: проверьте назначенные роли и разрешения; удалите или уменьшите разрешения до минимально необходимых.
• Предпочитайте управляемые идентификации: по возможности замените регистрации приложений и субъекты-службы управляемыми идентификациями для ресурсов Azure.
• Соблюдайте гигиену учётных данных: избегайте долгоживущих учётных данных, предпочитайте сертификаты клиентским секретам и регулярно обновляйте учётные данные.
• Применять политики учётных данных: внедрять условный доступ и политики паролей и секретов Azure AD для учётных данных приложений, где это уместно.
• Требовать MFA и условный доступ для интерактивного использования: блокировать или ограничивать учётные данные, которые позволяют интерактивный вход, если это не необходимо и не защищено.
• Включить just-in-time (JIT) или доступ с ограниченным сроком: по возможности предоставлять роли с высокими привилегиями субъектам-службам на ограниченное время.
• Соглашения об именовании и метаданные: применять понятные стандарты именования и помечать субъекты-службы метаданными об окружении, владельце и сроке действия.
• Политики срока действия и жизненного цикла: задавать срок действия для секретов и сертификатов и автоматизировать жизненный цикл (создание, обновление, отзыв, деактивация).
• Отключать неиспользуемые субъекты-службы: отключать или удалять субъекты-службы, не использовавшиеся в течение определённого периода, после подтверждения с владельцами.
• Мониторинг входов и рискованного использования: включить журналирование и оповещения о подозрительных входах, высокорисковой активности и повышении привилегий.
• Централизованное журналирование и интеграция с SIEM: передавать журналы аудита, события входа и изменения provisioning в вашу SIEM для корреляции и хранения.
• Проверки доступа и периодические аудиты: регулярно проводить проверки доступа, подтверждая необходимость каждого субъекта-службы и одобрение владельца.
• Укрепление API и разрешений: использовать делегированные разрешения с ограниченной областью действия или разрешения только для приложения, определённые максимально узко.
• Безопасное хранение секретов: хранить клиентские секреты и сертификаты в Azure Key Vault или аналогичном хранилище; ограничивать доступ к хранилищу только необходимыми субъектами.
• Автоматизированное устранение проблем: внедрить автоматизированные плейбуки для отключения скомпрометированных или просроченных субъектов-служб и ротации учётных данных.
• Применение политик: использовать условный доступ Azure AD / Entra ID, Microsoft Entra permissions management и Azure Policy для соблюдения стандартов.
• Документация и руководства: поддерживать runbook-инструкции для создания, экстренной ротации учётных данных и процедур деактивации.
• Проверка доступа и отказоустойчивости: проверять сценарии аутентификации приложений после ротации учётных данных или изменения конфигурации в непродуктивной среде.
• Безопасное подключение и отключение: интегрировать создание и удаление субъектов-служб в CI/CD и процессы управления изменениями.
• Учётные записи служб с минимальными привилегиями для автоматизации: использовать выделенные субъекты-службы для задач автоматизации с узко ограниченными правами и явно назначенным владельцем.
• Проверка внешнего и гостевого доступа: проводить аудит субъектов-служб, созданных внешними приложениями, и предоставлять доступ только после проверки безопасности.
• Сохранение доказательств соответствия: фиксировать одобрения, проверки и события ротации, чтобы подтверждать соответствие внутренним и внешним требованиям.
• Обучение команд и владельцев: обучать владельцев приложений и разработчиков эффективному управлению субъектами-службами в Entra ID и безопасным практикам работы с учётными данными.

Часто задаваемые вопросы: дополнительные ресурсы по субъектам-службам Microsoft Entra ID

Что такое субъект-служба Microsoft Entra ID и чем он отличается от объекта приложения?

Субъект-служба Microsoft Entra ID — это локальное представление экземпляра приложения в клиенте или каталоге. Он создаётся в каждом клиенте, где используется приложение, и ссылается на глобально уникальный объект приложения (объект приложения находится в домашнем клиенте). Объект приложения определяет приложение глобально, а субъект-служба определяет политику доступа и то, что это приложение может делать в конкретном клиенте.

Как создаются субъекты-службы и когда создаётся субъект-служба?

Субъект-служба обычно создаётся автоматически, когда вы регистрируете приложение Microsoft Entra и экземпляр приложения используется в клиенте, либо когда пользователь даёт согласие на разрешения для многоклиентского приложения. Также его можно создать вручную через портал Azure, Microsoft Graph или с помощью автоматизации, когда приложение развёртывается в клиенте, где ему нужен доступ к защищённым ресурсам.

Каковы рекомендации по защите субъектов-служб в Microsoft Entra?

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

Как управлять учётными данными субъектов-служб, такими как пароли и сертификаты?

Храните пароли и сертификаты в защищённом хранилище (Key Vault), задавайте сроки действия, по возможности используйте аутентификацию на основе сертификатов и автоматизируйте ротацию с помощью Microsoft Graph или конвейеров CI/CD. Для долгоживущих учётных данных настройте оповещения о приближающемся истечении срока и применяйте схему и политику, которые не дают появляться устаревшим или небезопасным секретам.

Как использовать Microsoft Graph для запросов и управления субъектами-службами (service principals) с помощью автоматизации?

Используйте API Microsoft Graph, чтобы получать список, фильтровать, создавать, обновлять и удалять объекты субъектов-служб Microsoft Entra ID. Можно выполнять запросы с фильтрами, чтобы найти субъекты по appId, displayName или владельцу, управлять предоставленными разрешениями, назначать владельцев и автоматизировать синхронизацию субъектов-служб между средами с помощью скриптов или коннекторов, которые ссылаются на глобально уникальные идентификаторы.

Какую роль играет назначение владельцев и как следует организовывать владение?

Назначение владельцев обеспечивает делегированное административное управление субъектом-службой: владельцы могут управлять учётными данными и разрешениями. Используйте ролевой доступ и несколько владельцев для обеспечения непрерывности бизнеса, фиксируйте в аудите изменения владельцев и не назначайте права владельца учётным записям пользователей, которые не связаны с долгосрочной идентичностью. Лучше выбрать команду или учётную запись службы, ограниченную политикой.

Как синхронизация и особенности клиента или каталога влияют на субъекты-службы?

Сценарии синхронизации, например синхронизация корпоративных приложений или удостоверений между клиентами, могут создавать субъекты-службы в целевых клиентах. Выясните, является ли приложение однопользовательским (single-tenant) или многопользовательским (multi-tenant), какой домашний клиент его зарегистрировал и требуется ли согласие пользователя из этого клиента. Планируйте синхронизацию так, чтобы не создавать дубликаты субъектов-служб, и используйте фильтрацию для исключения ненужных объектов.

Когда следует использовать управляемое удостоверение вместо созданного субъекта-службы?

Используйте управляемые удостоверения, когда рабочая нагрузка выполняется в Azure и может использовать управляемое платформой удостоверение для получения токенов без встроенных учётных данных. Управляемые удостоверения снижают необходимость управлять паролями, упрощают обновления безопасности и являются рекомендуемым способом защиты субъектов-служб в сценариях Microsoft там, где это поддерживается.

Как проверять и устранять неполадки доступа к ресурсам, защищённым субъектами-службами?

Включите и просматривайте журналы входа и журналы аудита в Microsoft Entra ID и Azure AD, используйте Microsoft Graph для получения событий, применяйте фильтры для сужения результатов и интегрируйте журналы с SIEM. Для технической поддержки или сложных проблем соберите objectId и appId субъекта-службы, временные метки и сообщения об ошибках, прежде чем обращаться в поддержку или использовать Microsoft Learn и дополнительные материалы для расследования.