Шаги по анализу использования субъектов-служб в клиенте Microsoft 365

By Mirko Peters · 2026-03-09 · Updated 2026-09-13

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

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

Анализ использования субъектов-служб с помощью Service Principal Analysis важен для защиты вашего клиента Microsoft 365. Мониторинг субъектов-служб помогает выявить потенциальные риски, например теневое ИТ и слабые настройки безопасности. На что стоит обратить внимание в первую очередь:

• Неуправляемые административные учётные записи

• Непоследовательное применение многофакторной аутентификации (MFA)

• Внешний обмен данными без контроля

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

Главное

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

• Убедитесь, что у вас есть необходимые разрешения, например AuditLog.Read.All, для эффективного анализа использования субъектов-служб.

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

• Автоматизируйте процессы мониторинга с помощью таких инструментов, как AdminDroid, чтобы упростить управление и повысить безопасность.

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

1. Субъекты-службы представляют идентичность приложения в вашем клиенте Microsoft 365: объект приложения задаёт глобальное определение, а субъект-служба является локальной идентичностью, которая используется для аутентификации, назначения ролей и контроля доступа в клиенте Microsoft 365. Поэтому мониторинг использования субъектов-служб в клиенте Microsoft 365 критически важен, чтобы понимать, кто и что может получать доступ к ресурсам.
2. Один объект приложения может соответствовать нескольким субъектам-службам: у одного объекта приложения может быть несколько разных субъектов-служб в разных клиентах, каждый с собственными учётными данными, согласиями и назначениями ролей. Поэтому один и тот же код приложения может вести себя по-разному в разных клиентах Microsoft 365.
3. Типы учётных данных влияют на поверхность атаки: субъекты-службы могут использовать клиентские секреты, сертификаты или федеративные удостоверения. Долгоживущие секреты расширяют поверхность атаки в вашем клиенте Microsoft 365, тогда как аутентификация на основе сертификатов или федерации при правильной настройке может снизить риски.
4. Делегированные разрешения и разрешения приложения создают разные риски: разрешения приложения, предоставленные субъекту-службе, дают доступ независимо от любого пользователя и могут быть мощнее делегированных разрешений. Ошибочно настроенные разрешения приложения — частая причина избыточных привилегий субъектов-служб в клиенте Microsoft 365.
5. Согласие пользователя и согласие администратора различаются по области действия: пользователи могут давать согласие на некоторые делегированные разрешения для приложений, но для разрешений приложений с более высоким риском требуется согласие администратора. Отслеживание событий согласия помогает выявлять неожиданное использование субъектов-служб в клиенте Microsoft 365.
6. Управляемые удостоверения упрощают жизненный цикл, но привязаны к клиенту: управляемые удостоверения Azure AD (системно назначаемые или назначаемые пользователем) автоматически создают субъекты-службы для ресурсов, что упрощает управление учётными данными в вашем клиенте Microsoft 365. Однако их нельзя перенести между клиентами, поэтому при перемещении ресурсов потребуется перенастройка.
7. Условный доступ и управление правами доступа (entitlement management) распространяются и на приложения: Вы можете применять политики условного доступа и использовать entitlement management для контроля использования субъектов-служб (service principal) в вашем клиенте Microsoft 365. Однако политики необходимо явно проверять в контексте приложений, чтобы предотвратить несанкционированный доступ к приложениям и боковое перемещение.

Предварительные требования для анализа субъектов-служб

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

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

Для анализа активности субъектов-служб в Microsoft Entra и Microsoft 365 требуются определённые разрешения. В следующей таблице перечислен необходимый набор разрешений:

Без нужных разрешений могут возникнуть ошибки. Например, если вы видите сообщение "Insufficient privileges to complete the operation", это означает, что у вас нет необходимого доступа. Такое ограничение может помешать эффективно управлять субъектами-службами и анализировать их работу.

Инструменты и ресурсы

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

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

1. Подключитесь к Microsoft Graph PowerShell с помощью команды: Connect-MgGraph -Scopes "AuditLog.Read.All"

2. Выполните команду для аудита входов субъектов-служб:

   Get-MgBetaAuditLogSignIn -Filter "signInEventTypes/any(t:t eq 'servicePrincipal')" -All | Select-Object CreatedDateTime, Id, ServicePrincipalId, ServicePrincipalName, ResourceDisplayName, ResourceId, @{Name = "Status"; Expression = { if ($_.Status.ErrorCode -eq 0) { "Success" } else { "Failed" } }} | Format-Table
   

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

Создание субъекта-службы в Microsoft Entra

Создание субъекта-службы в Microsoft Entra предполагает регистрацию приложения. Этот процесс позволяет приложению проходить аутентификацию и безопасно получать доступ к ресурсам. Вот как зарегистрировать приложение:

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

Чтобы зарегистрировать приложение в Microsoft Entra, выполните следующие шаги:

1. Войдите в центр администрирования Microsoft Entra.

2. Перейдите в раздел Приложения и выберите Новая регистрация.

3. Заполните обязательные поля, например имя приложения и URI перенаправления.

4. Выберите подходящий тип учётной записи в зависимости от ваших потребностей.

5. Нажмите Регистрация, чтобы завершить процесс.

После регистрации можно создать субъект-службу. Этот субъект-служба выступает в роли идентификатора вашего приложения при взаимодействии с другими сервисами.

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

• Загрузка доверенного сертификата, выданного центром сертификации.

• Создание и загрузка самоподписанного сертификата для тестирования.

• Создание нового секрета клиента.

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

Определение инициатора

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

1. Войдите в центр администрирования Microsoft Entra.

2. Перейдите в раздел Мониторинг и работоспособность и выберите Журналы аудита.

3. Установите для параметра Категория значение ApplicationManagement и примените фильтр.

4. Отфильтруйте Действие по значению Add service principal и примените фильтр.

5. Выберите событие и разверните раздел Additional details. Найдите свойства вроде ServicePrincipalProvisioningType, SubscribedSkus и AppOwnerOrganizationId.

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

Вот краткое описание атрибутов, которые можно найти в журналах аудита:

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

Просмотр активности входа с помощью Microsoft Graph

Доступ к Microsoft Graph API

Для доступа к журналам входа субъектов служб можно использовать Microsoft Graph API. Чтобы получить нужные данные, выполните следующие шаги:

1. Используйте Microsoft Graph API для формирования отчета об активности входа субъектов служб.

2. Выполните команду Get-MgServicePrincipal, чтобы получить субъекты служб в вашем клиенте.

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

4. Выполните Get-MgBetaReportServicePrincipalSignInActivity, чтобы найти активность входа субъектов служб, дата последнего входа которых старше одного года.

5. Создайте отчет о субъектах служб и экспортируйте данные в CSV-файл.

6. Сформируйте статистику, например, по клиентам, которым принадлежат приложения, и общему количеству субъектов служб.

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

Анализ журналов входа

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

Вот некоторые распространенные аномалии, которые могут обнаружиться в журналах входа субъектов служб:

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

• Неожиданные доверительные отношения, добавленные в Azure AD.

• Изменения учетных данных субъектов служб, включая изменения разрешений.

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

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

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

3. Используйте такие инструменты, как Microsoft Entra и PowerShell, для детального анализа журналов входа.

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

Эффективное управление субъектами служб

Рекомендуемые методы управления

Для эффективного управления субъектами служб следуйте нескольким рекомендуемым методам. Их применение повысит безопасность и упростит операции в вашем клиенте:

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

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

• Мониторинг активности: следите за активностью субъектов-служб на предмет подозрительного поведения. Это помогает на ранней стадии выявлять попытки несанкционированного доступа.

• Надежная аутентификация: используйте надежные методы аутентификации, например многофакторную аутентификацию (MFA). Это добавляет дополнительный уровень защиты.

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

• Документирование: документируйте назначение и разрешения каждого субъекта-службы. Эта практика помогает понимать их роли в вашем клиенте.

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

Автоматизация мониторинга

Автоматизация мониторинга субъектов-служб может существенно повысить уровень вашей безопасности. Вот несколько инструментов и стратегий, которые стоит рассмотреть:

• AdminDroid: этот инструмент предлагает функцию мониторинга входов. Она помогает отслеживать шаблоны входа субъектов-служб и предоставляет подробные отчеты об использовании и трендах доступа.

• Отчет об изменениях субъектов-служб: AdminDroid также предоставляет отчет, который отслеживает изменения субъектов-служб. Этот отчет содержит данные о добавлении, обновлении и удалении, а также о действиях входа: время, имя приложения, статус и местоположение.

Автоматизируя мониторинг, вы получаете несколько преимуществ:

Внедрение этих практик и инструментов поможет эффективно управлять субъектами-службами и поддерживать безопасную среду в вашем клиенте Microsoft 365.

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

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

Часто задаваемые вопросы

Что такое субъект-служба в Microsoft 365?

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

Как отслеживать активность субъекта-службы?

Вы можете отслеживать активность субъекта-службы с помощью Microsoft Graph API или таких инструментов, как AdminDroid. Эти инструменты дают представление о шаблонах входа и трендах использования.

Почему важно анализировать использование субъектов-служб?

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

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

Для анализа активности субъектов-служб в Microsoft Entra и Microsoft 365 нужно разрешение AuditLog.Read.All. Оно даёт доступ к необходимым журналам.

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

Автоматизировать мониторинг можно с помощью таких инструментов, как AdminDroid. Они формируют отчёты о входах и изменениях субъектов-служб, что упрощает управление.

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

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

Субъект-служба — это принципал безопасности, который представляет приложение или службу в вашем клиенте Microsoft Entra. Он соответствует объекту приложения (глобальному определению), а субъект-служба — это экземпляр, созданный в вашем клиенте при регистрации приложения или предоставлении согласия на него. Идентификатор приложения (application ID) и идентификатор клиента (client ID) связывают эти два объекта. Если субъект-служба был создан, в Microsoft Entra вы увидите и объект приложения, и объект субъекта-службы.

Как создать субъект-службу в моём клиенте Microsoft 365?

Субъект-службу можно создать, зарегистрировав приложение в центре администрирования Microsoft Entra или с помощью Azure CLI либо Microsoft Graph PowerShell SDK. Обычно порядок такой: сначала создаётся приложение (объект приложения), затем субъект-служба в домашнем или владеющем клиенте, после этого назначаются разрешения и создаются учётные данные (секрет клиента или сертификат). Для автоматизированных скриптов используйте azure cli az ad sp create-for-rbac или Microsoft Graph PowerShell SDK для создания субъекта-службы.

Где найти сведения о субъекте-службе и проанализировать его активность входа?

Сведения о субъекте-службе доступны в центре администрирования Microsoft Entra: в разделе «Корпоративные приложения» или «Регистрации приложений» в зависимости от типа. Можно просмотреть такие свойства, как имя субъекта-службы, идентификатор приложения, идентификатор клиента и назначенные роли. Чтобы проанализировать активность входа субъекта-службы, используйте журналы входа в Microsoft Entra или запросите отчёты о входах через Microsoft Graph. Так можно просмотреть события аутентификации, события создания субъектов-служб и телеметрию входов.

Как политики доступа и настройки аутентификации влияют на новый субъект-службу?

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

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

Да. Приложения Microsoft первой стороны и службы Microsoft часто создают объекты субъектов-служб в Microsoft Entra ID, когда используются в вашем клиенте. Они могут отображаться как приложения Entra или приложения Microsoft первой стороны. Некоторые службы Microsoft создают субъекты-службы автоматически при подключении. Вы можете просматривать и контролировать их в центре администрирования Microsoft Entra, а также применять доступ just-in-time там, где это поддерживается.

Как управлять разрешениями и объектами субъектов в Microsoft Entra, чтобы снизить риски?

Аудитируйте события создания субъектов-служб, проверяйте разрешения, выданные объектам субъектов-служб в Microsoft Entra ID, и удаляйте избыточные привилегии. Используйте назначения ролей, где уместно — разрешения приложений вместо делегированных. Внедряйте условный доступ и just-in-time-предоставление доступа или назначение субъекта-службы с правом just-in-time там, где это возможно, и регулярно меняйте учётные данные. Для подробных рекомендаций по безопасности и процедур технической поддержки используйте Microsoft Learn и другие дополнительные ресурсы.

Какие инструменты можно использовать для автоматизации проверки и создания субъектов-служб (PowerShell, Azure CLI)?

Для автоматизации создания и проверки субъектов-служб (service principal) можно использовать Microsoft Graph PowerShell SDK, Azure CLI или API Microsoft Graph. Такие команды, как az ad sp create-for-rbac и их аналоги в Microsoft Graph PowerShell SDK, позволяют создать субъект-службу и вывести client id, application id и tenant id. Скрипты также могут перечислять объекты субъектов-служб в Microsoft Entra и собирать данные о входах или разрешениях для отчётов.

Как узнать, был ли субъект-служба создан клиентским приложением или учётной записью Microsoft?

Изучите сведения о субъекте-службе в центре администрирования Microsoft Entra или запросите их через Microsoft Graph. Посмотрите такие свойства, как владелец приложения, издатель и тип исходного приложения. Субъекты-службы, созданные клиентским приложением, ссылаются на application id или client id и обычно показывают создавший их субъект и время создания. Субъекты-службы Microsoft, созданные для служб Microsoft или приложений Microsoft первой стороны, как правило, содержат издателя или известные идентификаторы Microsoft.

Где найти дополнительные материалы и рекомендации по Office 365 for IT Pros и лучшим практикам работы с субъектами-службами?

Используйте Microsoft Learn, документацию по центру администрирования Microsoft Entra, руководства по платформе удостоверений Microsoft и статьи, адресованные Office 365 for IT Pros. Также полезны документация Microsoft Graph, справочники по Azure CLI и Microsoft Graph PowerShell SDK, а также публикуемые Microsoft обновления по безопасности. Для сложных сценариев обратитесь в техническую поддержку или изучите лабораторные работы Microsoft Learn по объектам приложений и субъектов-служб в вашем клиенте.