Практический аудит разрешений корпоративного приложения: сопоставляем выданные Graph permissions, фактические HTTP-запросы, service principal и функции продукта, не принимая вход в систему за использование каждого права.
Разделите потенциальный и наблюдаемый доступ
В Enterprise applications выпишите выданные delegated и application permissions, их тип, необходимость согласия администратора и владельца бизнес-функции. Этот список показывает, что приложение вправе запросить, но не доказывает, что каждый scope или app role использовался в выбранный период. Отдельно отметьте разрешения с широким доступом. Не публикуйте AppId, tenant ID и названия внутренних приложений. Цель первого шага — создать инвентаризацию для проверки, а не сразу отзывать всё, что кажется лишним.
Используйте журнал Graph-запросов, а не только входов
Microsoft Graph activity logs содержат аудит HTTP-запросов, которые Graph принял и обработал для tenant, и позволяют группировать данные по AppId и ServicePrincipalId. Настройка требует поддерживаемой роли, лицензии и места назначения журналов. Обычный service principal sign-in подтверждает аутентификацию к ресурсу, но не перечисляет автоматически каждое использованное разрешение. Поэтому журнал входов полезен для времени и идентичности, а activity logs — для URI, метода, статуса и объёма запросов.
Сопоставьте URI с минимальным разрешением
Для каждого наблюдаемого RequestUri нормализуйте ресурс без пользовательских идентификаторов и найдите метод в официальной документации Graph. В разделе Permissions сравните least privileged permission с тем, что выдано приложению. Учитывайте тип вызова: delegated действует в контексте пользователя, application — без вошедшего пользователя. Один URI может встречаться редко, поэтому выберите период, включающий месячные, квартальные и аварийные сценарии. Отсутствие события в коротком окне не является доказательством ненужности права.
Добавьте доказательства из кода и владельца функции
Сопоставьте телеметрию с конфигурацией клиента, используемыми SDK-вызовами, документацией поставщика и картой функций. Для внешнего приложения запросите у поставщика перечень endpoint, permission и сценариев без передачи своих журналов. Для собственного приложения найдите, какая функция формирует конкретный вызов, и проверьте её в тестовой среде. Microsoft рекомендует принцип наименьших привилегий, но безопасное уменьшение требует понять последствия: журнал не видит будущий или редко выполняемый сценарий.
Отзывайте только по контролируемому плану
Сформируйте таблицу permission — наблюдаемые URI — функция — владелец — последняя дата — решение. Сначала измените запросы приложения или конфигурацию, затем отзовите кандидатное право в непроизводственной среде и прогоните критические сценарии. Подготовьте способ быстрого возврата согласия и окно наблюдения. Немедленно остановитесь, если приложение стороннее, журналирование не покрывает нужный период, владелец функции неизвестен или разрешение участвует в аварийном процессе. Сам факт отсутствия запросов сегодня недостаточен для production-отзыва.
Материал подготовлен самостоятельно с автоматизацией и редакционно проверен 30 июля 2026 года по обезличенному сигналу Microsoft Q&A и официальной документации Microsoft; tenant, AppId и журналы автора вопроса не использовались.
Источники и проверка
- Microsoft Learn — журналы активности Microsoft Graph проверено 2026-07-30
- Microsoft Learn — лучшие практики разрешений Microsoft Graph проверено 2026-07-30
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.