Укажите учетные данные приложения, если пользователя нет

Когда вы, как разработчик, создаёте приложения, не предназначенные для пользователей, у вас нет пользователя, от которого можно запросить имя пользователя и пароль или многофакторную аутентификацию (MFA). Необходимо предоставить идентификатор приложения самостоятельно. В этой статье объясняется, почему управляемые удостоверения для ресурсов Azure являются лучшей практикой использования учетных данных клиента Zero Trust для служб (непользовательских приложений) в Azure.

Проблемы с учетными записями служб

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

Параметры учетных данных клиента

Существует четыре типа учетных данных клиента, которые могут идентифицировать приложение.

• Секретный ключ
• Сертификат
• Управляемые удостоверения для ресурсов Azure
• Федеративные учетные данные

Секретный ключ или сертификат?

Секретные ключи допустимы в сложных инфраструктурах управления секретами (например, Azure Key Vault). Однако вы не можете правильно защитить секретные ключи в сценариях, когда ИТ-специалист создает секретный ключ, а затем отправляет его разработчику по электронной почте.

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

Лучшие практики: использование управляемых удостоверений для ресурсов Azure

При разработке служб (непользовательских приложений) в Azure, Управляемые удостоверения для ресурсов Azure предоставляют автоматически управляемое удостоверение в Microsoft Entra ID. Приложение может пройти проверку подлинности в любой службе, которая поддерживает проверку подлинности Microsoft Entra без управления учетными данными. Вам не нужно управлять секретами. Вам не нужно устранять возможность потери или неправильного их использования. Злоумышленники не способны перехватывать секреты, которые не передаются по сети. Управляемые удостоверения для ресурсов Azure являются оптимальной практикой при создании служб в Azure.

Дальнейшие действия

• Поддерживаемые типы удостоверений и учетных записей для отдельных и мультитенантных приложений объясняют, как вы можете выбрать, разрешает ли ваше приложение доступ только пользователям из вашего клиента Microsoft Entra, из любого клиента Microsoft Entra, или пользователям с личными учетными записями Microsoft.
• Стратегия разрешений приложений помогает вам определиться с подходом к управлению учетными данными ваших приложений.
• Предоставьте учетные данные удостоверения приложения, если пользователь отсутствует объясняет, почему управляемые удостоверения Azure для ресурсов являются лучшей практикой для предоставления учетных данных клиентам для служб (непользовательских приложений) в Azure.
• Рекомендации по авторизации помогут реализовать лучшие модели авторизации, разрешения и согласия для приложений.
• Используйте лучшие практики разработки управления идентификацией и доступом по модели Zero Trust в жизненном цикле разработки приложений для создания безопасных приложений.
• Создание приложений с использованием подхода "Нулевое доверие" к удостоверениям предоставляет общие сведения о разрешениях и рекомендациях по доступу.