Предоставление учетных данных удостоверения приложения при отсутствии пользователя
При создании приложений, отличных от пользователей, у вас нет пользователя, которого можно запрашивать для имени пользователя и пароля или многофакторной проверки подлинности (MFA). Необходимо предоставить удостоверение приложения самостоятельно. В этой статье объясняется, почему лучшие учетные данные клиента Zero Trust для служб (не пользовательских приложений) в Azure — это управляемые удостоверения для ресурсов Azure.
Проблемы с учетными записями служб
Использование учетной записи службы (создание учетной записи пользователя и его использование для службы) не является хорошим решением. Идентификатор Microsoft Entra не имеет концепции учетной записи службы. Когда администраторы создают учетные записи пользователей для службы, а затем обмениваются паролями с разработчиками, это небезопасно. Это не может быть без пароля или многофакторной проверки подлинности. Вместо использования учетной записи пользователя в качестве учетной записи службы лучше всего использовать один из вариантов учетных данных клиента, описанных ниже.
Параметры учетных данных клиента
Существует четыре типа учетных данных клиента, которые могут идентифицировать приложение.
- Секретный ключ
- Сертификат
- Управляемые удостоверения для ресурсов Azure
- Федеративные учетные данные
Секретный ключ или сертификат?
Секретные ключи приемлемы, если в вашей организации есть сложная инфраструктура управления секретами (например , Azure Key Vault). Однако секретные ключи в сценариях, когда ИТ-специалист создает секретный ключ, а затем отправляет его разработчику, который затем может хранить его в небезопасном расположении, например в электронной таблице, приводит к неправильной защите секретных ключей.
Учетные данные клиента на основе сертификатов более безопасны, чем секретные ключи. Сертификаты лучше управляются, так как они не являются секретом. Секрет не является частью передачи. При использовании секретного ключа клиент отправляет фактическое значение секретного ключа в идентификатор Microsoft Entra. При использовании сертификата закрытый ключ сертификата никогда не покидает устройство. Даже если кто-то перехватывает, декодирует и расшифровывает передачу, секрет по-прежнему защищен, так как перехватывающая сторона не имеет закрытого ключа.
Рекомендация. Использование управляемых удостоверений для ресурсов Azure
При разработке служб (непользовательских приложений) в Azure управляемые удостоверения для ресурсов Azure предоставляют автоматическое управляемое удостоверение в идентификаторе Microsoft Entra. Приложение может пройти проверку подлинности в любой службе, которая поддерживает проверку подлинности Microsoft Entra без управления учетными данными. Вам не нужно управлять секретами; Вам не нужно устранять возможность потери или неправильного их использования. Секреты не могут быть перехвачены, так как они не перемещаются по сети. Управляемые удостоверения для ресурсов Azure — это рекомендация, если вы создаете службы в Azure.
Следующие шаги
- Поддерживаемые типы удостоверений и учетных записей для приложений с одним и несколькими клиентами объясняют, разрешен ли ваше приложение только пользователям из клиента Microsoft Entra, любого клиента Microsoft Entra или пользователей с личными учетными записями Майкрософт.
- Разработка стратегии разрешений приложений помогает решить подход к управлению учетными данными приложения.
- Предоставление учетных данных удостоверения приложения, когда нет пользователя, объясняет, почему лучшие учетные данные клиента Zero Trust для служб (не пользовательских приложений) в Azure — управляемые удостоверения для ресурсов Azure.
- Рекомендации по авторизации помогут реализовать лучшие модели авторизации, разрешения и согласия для приложений.
- Используйте рекомендации по разработке удостоверений и управления доступом в жизненном цикле разработки приложений для создания безопасных приложений.
- Создание приложений с использованием подхода "Нулевое доверие" к удостоверениям предоставляет общие сведения о разрешениях и рекомендациях по доступу.
Обратная связь
https://aka.ms/ContentUserFeedback.
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделеОтправить и просмотреть отзыв по