Рекомендации по обеспечению безопасности свойств приложения в идентификаторе Microsoft Entra

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

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

В этой статье описаны рекомендации по безопасности для следующих свойств и сценариев приложения:

• Тип идентификации
• Подтверждение компетенции
• URI перенаправления
• Неявная конфигурация потока
• URI идентификатора приложения (также известный как URI идентификатора)
• Версия маркера доступа
• Блокировка экземпляра приложения
• Владение приложением

Тип идентификации

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

Управляемые удостоверения Azure по умолчанию защищены и не требуют постоянного обслуживания или накладных расходов. Рекомендуется использовать управляемое удостоверение вместо приложения Microsoft Entra для удостоверения приложения, если все следующие условия верны.

• Служба выполняется в облаке Azure
• Приложению не нужно выполнять вход пользователей
• Приложению не нужно выступать в качестве ресурса в потоке маркеров (это не веб-API).
• Приложению не нужно работать в нескольких клиентах.

Обратите внимание, что управляемые удостоверения можно использовать для доступа к ресурсам за пределами Azure, включая Microsoft Graph.

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

Учетные данные (включая сертификаты и секреты)

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

Обратите внимание на следующие рекомендации, связанные с сертификатами и секретами:

• По возможности используйте управляемое удостоверение в качестве учетных данных. Это настоятельно рекомендуется, так как управляемые удостоверения являются наиболее безопасным вариантом и не требуют постоянного управления учетными данными. Следуйте этому руководству, чтобы настроить управляемое удостоверение в качестве учетных данных для доступа. Однако эта опция может быть возможной только в случае, если служба, где приложение используется, работает на Azure.
• Если служба, в которую приложение используется, не запускается в Azure, но выполняется на другой платформе, которая предлагает автоматическое управление учетными данными, рассмотрите возможность использования удостоверения из этой платформы в качестве учетных данных. Например, рабочий процесс действий GitHub можно настроить как учетные данные, устраняя необходимость управления и защиты учетных данных для конвейера действий GitHub. Используйте осторожность с этим подходом и настройте только федеративные учетные данные на платформах, которым вы доверяете. Приложение обладает такой же степенью безопасности, как и платформа удостоверений, настроенная в качестве учетных данных.
• Если использование управляемого удостоверения или другого защищенного внешнего поставщика удостоверений невозможно, используйте сертификатные учетные данные. Не используйте учетные данные пароля, также известные как секреты. Хотя удобно использовать секреты паролей в качестве учетных данных, учетные данные паролей часто неуправляемы и могут быть легко скомпрометированы.
• Если сертификат должен использоваться вместо управляемого удостоверения, сохраните этот сертификат в безопасном хранилище ключей, например Azure Key Vault.
• Если сертификат должен использоваться вместо управляемого удостоверения, используйте сертификат из доверенного центра сертификации (ЦС) вместо самозаверяющего сертификата. Настройте политику для принудительного применения сертификатов из доверенных издателей. Однако если использование доверенного ЦС невозможно, самозаверяющий сертификат по-прежнему предпочтителен по сравнению с паролями.
• Настройте политики управления приложениями для управления использованием секретов, ограничив их время существования или блокируя их использование полностью.
• Если приложение используется только как общедоступный или установленный клиент (например, мобильные или классические приложения, установленные на конечном компьютере), убедитесь, что в объекте приложения нет учетных данных.
• Проверяйте актуальность и срок действия учетных данных, используемых в приложении. Неиспользуемые учетные данные в приложении могут привести к нарушению безопасности. Часто выполняйте смену учетных данных и не используйте одни и те же учетные данные в разных приложениях. Не используйте много учетных данных для одного приложения.
• Наблюдайте за рабочими конвейерами, чтобы предотвратить фиксацию любых учетных данных в репозиториях кода. Сканер учетных данных — это средство статического анализа, с помощью которого можно обнаруживать учетные данные (и другое конфиденциальное содержимое) в исходном коде и выходных данных сборки.

URI перенаправления

Важно поддерживать коды URI перенаправления для приложения в актуальном состоянии. В разделе Проверка подлинности для приложения на портале Azure необходимо выбрать платформу для приложения. Затем можно определить свойство URI перенаправления.

Воспользуйтесь следующими рекомендациями для URI перенаправления:

• Поддерживайте права владения всеми URI. Провал владения одним из URI перенаправления может привести к компрометации приложений.
• Убедитесь, что все записи DNS обновляются и отслеживаются периодически для изменений.
• Не используйте подстановочные знаки в URL-адресах ответов и небезопасных схем URI, например HTTP или URN.
• Поддерживайте небольшой размер списка. Обрезайте ненужные URI. При возможности переводите URL-адреса со схемы HTTP на HTTPS.

Неявная конфигурация потока

В сценариях, требовавших использовать неявный поток, теперь можно применять поток кода авторизации, чтобы снизить риск компрометации, вызванной неправильным использованием неявных потоков. В разделе Проверка подлинности для приложения на портале Azure необходимо выбрать платформу для приложения. Затем можно определить свойство Маркеры доступа (используемые для неявных потоков).

Обратите внимание на следующие рекомендации, связанные с неявным потоком:

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

URI идентификатора приложения (также известный как URI идентификатора)

Свойство URI идентификатора приложения определяет глобальный уникальный URI, используемый для идентификации веб-API. Это префикс значения области в запросах к Microsoft Entra. Это также значение утверждения аудитории (aud) в токенах доступа версии 1.0. Для мультитенантных приложений значение также должно быть глобально уникальным. Он также называется URI идентификатора . В разделе Предоставление API для приложения на портале Azure можно определить свойство URI идентификатора приложения.

Лучшие практики для определения URI идентификатора приложения меняются в зависимости от того, выдаются ли приложению маркеры доступа версии 1.0 или версии 2.0. Если вы не уверены, выдается ли приложению токены доступа версии 1.0, проверьте requestedAccessTokenVersion манифеста приложения . Значение null или 1 указывает, что приложение получает маркеры доступа версии 1.0. Значение 2 указывает, что приложение получает маркеры доступа версии 2.0.

Для приложений, выданных маркерами доступа версии 1.0, следует использовать только URI по умолчанию. URI по умолчанию — api://<appId> и api://<tenantId>/<appId>. — Настройте nonDefaultUriAddition ограничение в политиках управления приложениями , чтобы применить эту рекомендацию для будущих обновлений приложений в вашей организации.

Для приложений, выданных маркерами доступа версии 2.0, используйте следующие рекомендации при определении URI идентификатора приложения:

• Рекомендуется использовать схемы URI api или https. Задавайте свойство в поддерживаемых форматах, чтобы избежать конфликтов URI в организации. Не используйте подстановочные знаки.
• Используйте проверенный домен вашей организации.
• Храните данные инвентаризации URI в своей организации, чтобы повысить уровень безопасности.

Поддерживаются следующие форматы URI идентификатора приложения на основе схемы HTTP и API. Замените значения заполнителей, как описано в списке, что находится под таблицей.

• <appId> — свойство идентификатора приложения (appId) объекта приложения.
• <string> — строковое значение для узла или сегмента пути к API.
• <tenantId> — идентификатор GUID, созданный Azure для представления клиента в Azure.
• <tenantInitialDomain> - <tenantInitialDomain>.onmicrosoft.com, где <tenantInitialDomain> — это исходное доменное имя, которое создатель клиента задает при создании клиента.
• <verifiedCustomDomain> — проверенный личный домен , настроенный для клиента Microsoft Entra.

Версия маркера доступа

Этот раздел применим только к приложениям ресурсов, то есть приложениям, которые действуют в качестве аудитории в маркерах доступа. Приложения ресурсов обычно являются веб-API. Если приложение действует только как клиент (то есть получает маркеры для отправки в ресурсы, такие как Microsoft Graph), этот раздел не применяется.

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

Если какие-либо значения настроены не в формате api://{appId} или api://{tenantId}/{appId}, то приложение должно использовать маркеры доступа версии 2.0.

Чтобы обновить маркеры доступа версии 2.0, сначала убедитесь, что приложение может обрабатывать утверждения маркеров версии 2.0. Затем обновите версию маркера доступа, выпущенную приложением с помощью редактора манифеста.

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

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

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

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

Разрешения

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

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

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

Владельцы могут управлять всеми аспектами зарегистрированного приложения. Важно регулярно проверять права владения всеми приложениями в организации. Дополнительные сведения см. в обзоре доступа Microsoft Entra. В разделе Владельцы для приложения на портале Azure можно управлять владельцами приложения.

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

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

Проверка рекомендаций Entra

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