Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Управляемое удостоверение в Azure обеспечивает безопасный и удобный способ для приложений, служб и средств автоматизации для доступа к ресурсам Azure без хранения учетных данных в коде или конфигурации. В отличие от субъектов-служб, требующих ручного управления учетными данными, Azure автоматически обрабатывает управляемые удостоверения и не предоставляет конфиденциальные секреты. Использование управляемого удостоверения — это рекомендация по написанию скриптов безопасной автоматизации, так как она упрощает проверку подлинности и снижает риск утечки учетных данных. Управляемые удостоверения также помогают безопасно автоматизировать задачи управления без использования удостоверений пользователей. Разрешения для управляемых удостоверений задаются через Microsoft Entra, гарантируя предоставление только необходимого доступа к ресурсам, что повышает безопасность и поддерживаемость системы.
Important
Начиная с сентября 2025 года Azure PowerShell потребует многофакторной проверки подлинности (MFA) при входе с помощью удостоверения пользователя Microsoft Entra ID. Это изменение повышает безопасность, но может повлиять на рабочие процессы автоматизации, основанные на проверке подлинности имени пользователя и пароля. Дополнительные сведения см. в разделе Влияние многофакторной проверки подлинности на Azure PowerShell в сценариях автоматизации.
Необходимые условия
Вход с помощью управляемого удостоверения
Управляемые удостоверения — это особый тип субъекта-службы, который предоставляет службы Azure с автоматически управляемым удостоверением. Использование этого типа удостоверения не требует хранения учетных данных в конфигурации или коде для проверки подлинности в любой службе Azure, поддерживающей управляемые удостоверения.
Существует два типа управляемых учетных записей:
- Системно назначенная управляемая идентичность
- Управляемая идентификация, назначаемая пользователем
Управляемые удостоверения обеспечивают безопасный способ взаимодействия с другими службами Azure без необходимости управлять учетными данными. Они также помогают снизить риск утечки учетных данных.
Вот как работают управляемые идентификации в реальных сценариях:
- Azure автоматически управляет созданием и удалением учетных данных, используемых управляемым удостоверением.
- Служба Azure с поддержкой управляемого удостоверения может безопасно получить доступ к другим службам, таким как Azure Key Vault, База данных SQL Azure, Хранилище BLOB-объектов Azure и т. д., с помощью токенов Microsoft Entra.
- Это идентификатор управляется непосредственно в Azure без необходимости дополнительного предоставления.
Управляемые удостоверения упрощают модель безопасности, избегая необходимости хранить учетные данные и управлять ими, и они играют важную роль в безопасных облачных операциях, уменьшая риск, связанный с обработкой секретов.
Системно назначенная управляемая идентичность
Azure автоматически создает системно назначаемое управляемое удостоверение для экземпляра службы Azure (например, виртуальной машины Azure, службы приложений или функции Azure). При удалении экземпляра службы Azure автоматически очищает учетные данные и идентификацию, связанную со службой.
Следующий пример подключается, используя управляемое удостоверение, назначаемое системой, в хостовой среде. При выполнении на виртуальной машине с назначенным управляемым удостоверением код позволяет выполнить вход с помощью назначенного удостоверения.
Connect-AzAccount -Identity
Управляемая идентификация, назначаемая пользователем
Управляемое удостоверение, назначаемое пользователем, — это удостоверение, создаваемое и управляемое в Microsoft Entra. Его можно назначить одному или нескольким экземплярам службы Azure. Жизненный цикл пользователем назначаемого управляемого удостоверения управляется отдельно от экземпляров служб, которым он назначен.
При использовании управляемого удостоверения, назначаемого пользователем, необходимо указать параметры AccountId и Identity , как показано в следующем примере.
Connect-AzAccount -Identity -AccountId <user-assigned-identity-clientId-or-resourceId>
Следующие команды подключаются, используя управляемое удостоверение myUserAssignedIdentity. Он добавляет идентификатор, назначенный пользователем, в виртуальную машину, а затем подключается с помощью ClientId идентификатора, назначенного пользователем.
$identity = Get-AzUserAssignedIdentity -ResourceGroupName myResourceGroup -Name myUserAssignedIdentity
Get-AzVM -ResourceGroupName contoso -Name testvm | Update-AzVM -IdentityType UserAssigned -IdentityId $identity.Id
Connect-AzAccount -Identity -AccountId $identity.ClientId # Run on the virtual machine
Account SubscriptionName TenantId Environment
------- ---------------- -------- -----------
00000000-0000-0000-0000-000000000000 My Subscription 00000000-0000-0000-0000-000000000000 AzureCloud
Дополнительные сведения см. в разделе Настройка управляемых удостоверений для ресурсов Azure на виртуальной машине Azure.
Вход с помощью служебного принципала
Чтобы войти с помощью учетной записи службы, используйте параметр ServicePrincipal командлета Connect-AzAccount. Вам также потребуется следующая информация для субъекта-службы:
- AppId
- Учетные данные входа или доступ к сертификату, используемому для создания субъекта-службы
- Идентификатор арендатора
Метод входа с использованием учетной записи службы зависит от того, настроена ли она для аутентификации на основе сертификатов или паролей.
Проверка подлинности на основе сертификатов
Сведения о том, как создать сервисный принципал для Azure PowerShell, см. в статье Создание сервисного принципала Azure с использованием Azure PowerShell.
Для проверки подлинности на основе сертификатов требуется Azure PowerShell получить сведения из локального хранилища сертификатов на основе отпечатка сертификата.
Connect-AzAccount -ApplicationId $appId -Tenant $tenantId -CertificateThumbprint <thumbprint>
При использовании субъекта-службы вместо зарегистрированного приложения укажите параметр ServicePrincipal и укажите идентификатор приложения субъекта-службы в качестве значения параметра ApplicationId .
Connect-AzAccount -ServicePrincipal -ApplicationId $servicePrincipalId -Tenant $tenantId -CertificateThumbprint <thumbprint>
В Windows PowerShell 5.1 хранилище сертификатов можно управлять и проверять с помощью модуля PKI. Для PowerShell 7.x и более поздних версий процесс отличается. В следующих сценариях показано, как импортировать существующий сертификат в хранилище сертификатов, доступном PowerShell.
Импорт сертификата в PowerShell 7.x и более поздних версий
# Import a PFX
$storeName = [System.Security.Cryptography.X509Certificates.StoreName]::My
$storeLocation = [System.Security.Cryptography.X509Certificates.StoreLocation]::CurrentUser
$store = [System.Security.Cryptography.X509Certificates.X509Store]::new($storeName, $storeLocation)
$certPath = <path to certificate>
$credentials = Get-Credential -Message "Provide PFX private key password"
$flag = [System.Security.Cryptography.X509Certificates.X509KeyStorageFlags]::Exportable
$certificate = [System.Security.Cryptography.X509Certificates.X509Certificate2]::new($certPath, $credentials.Password, $flag)
$store.Open([System.Security.Cryptography.X509Certificates.OpenFlags]::ReadWrite)
$store.Add($Certificate)
$store.Close()
Импорт сертификата в Windows PowerShell 5.1
# Import a PFX
$credentials = Get-Credential -Message 'Provide PFX private key password'
Import-PfxCertificate -FilePath <path to certificate> -Password $credentials.Password -CertStoreLocation cert:\CurrentUser\My
Аутентификация на основе пароля
Создайте основной объект службы для использования в примерах этого раздела. Дополнительные сведения о создании учетных записей службы см. в разделе Создание учетной записи службы Azure с помощью Azure PowerShell.
$sp = New-AzADServicePrincipal -DisplayName ServicePrincipalName
Предостережение
Предоставленный секрет субъекта-службы хранится в файле AzureRmContext.json в профиле пользователя ($env:USERPROFILE\.Azure). Убедитесь, что этот каталог имеет соответствующие защиты.
Чтобы получить учетные данные служебного принципала как объект, используйте Get-Credential командлет. Этот командлет запрашивает имя пользователя и пароль. Используйте учетные данные службы AppId в качестве имени пользователя и преобразуйте его secret в обычный текст для пароля.
# Retrieve the plain text password for use with Get-Credential in the next command.
$sp.PasswordCredentials.SecretText
$pscredential = Get-Credential -UserName $sp.AppId
Connect-AzAccount -ServicePrincipal -Credential $pscredential -Tenant $tenantId
Для сценариев автоматизации необходимо создать учетные данные на основе учетной записи службы AppId и SecretText:
$SecureStringPwd = $sp.PasswordCredentials.SecretText | ConvertTo-SecureString -AsPlainText -Force
$pscredential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $sp.AppId, $SecureStringPwd
Connect-AzAccount -ServicePrincipal -Credential $pscredential -Tenant $tenantId
При автоматизации подключений основной службы используйте соответствующие методики хранения паролей.
См. также
- Создайте учетную запись службы Azure с помощью Azure PowerShell
- Что такое управляемые идентификации для ресурсов Azure?
- Назначение доступа к управляемому удостоверению к ресурсу с помощью PowerShell
- Просмотр служебного принципала управляемого идентификатора с помощью PowerShell
- Connect-AzAccount
- New-AzADServicePrincipal
- Get-Credential
Azure PowerShell