Delen via

Meld u niet interactief aan bij Azure PowerShell voor automatiseringsscenario's

  • Artikel

Een beheerde identiteit in Azure biedt een veilige en naadloze manier voor toepassingen, services en automatiseringsprogramma's voor toegang tot Azure-resources zonder referenties op te slaan in code of configuratie. In tegenstelling tot service-principals, waarvoor handmatig referentiebeheer is vereist, verwerkt Azure automatisch beheerde identiteiten en worden er geen gevoelige geheimen weergegeven. Het gebruik van een beheerde identiteit is de best practice voor het schrijven van scripts voor beveiligde automatisering, omdat hiermee de verificatie wordt vereenvoudigd en het risico op referentielekken wordt geminimaliseerd. Beheerde identiteiten helpen ook beheertaken veilig te automatiseren zonder afhankelijk te zijn van gebruikersidentiteiten. Machtigingen voor beheerde identiteiten worden beheerd via Microsoft Entra, zodat ze alleen de benodigde toegang tot resources hebben, waardoor zowel beveiliging als onderhoud worden verbeterd.

Belangrijk

Vanaf begin 2025 vereist verificatie bij Azure vanuit Azure PowerShell met behulp van een Microsoft Entra ID-gebruikersidentiteit meervoudige verificatie (MFA). Zie Planning voor verplichte meervoudige verificatie voor Azure- en andere beheerportalsvoor meer informatie.

Voorwaarden

Aanmelden met een beheerde identiteit

Beheerde identiteiten zijn een speciaal type service-principal die Azure-services met een automatisch beheerde identiteit biedt. Als u dit type identiteit gebruikt, hoeft u geen referenties op te slaan in de configuratie of code om te authenticeren bij elke Azure-service die beheerde identiteiten ondersteunt.

Er zijn twee typen beheerde identiteiten:

  • Door het systeem toegewezen beheerde identiteit
  • Door de gebruiker toegewezen beheerde identiteit

Beheerde identiteiten bieden een veilige manier om te communiceren met andere Azure-services zonder dat ontwikkelaars referenties hoeven te beheren. Ze helpen ook bij het beperken van het risico op referentielekken.

Zo werken beheerde identiteiten in praktijkscenario's:

  • Azure beheert automatisch het aanmaken en verwijderen van de inloggegevens die door de beheerde identiteit worden gebruikt.
  • Een Azure-service die is ingeschakeld met een beheerde identiteit, heeft mogelijk veilig toegang tot andere services, zoals Azure Key Vault, Azure SQL Database, Azure Blob Storage, enzovoort, met behulp van Microsoft Entra-tokens.
  • Deze identiteit wordt rechtstreeks binnen Azure beheerd zonder dat u extra inrichting nodig hebt.

Beheerde identiteiten vereenvoudigen het beveiligingsmodel door te voorkomen dat referenties moeten worden opgeslagen en beheerd, en ze spelen een cruciale rol bij veilige cloudbewerkingen door het risico te verminderen dat gepaard gaat met het afhandelen van geheimen.

Door het systeem toegewezen beheerde identiteit

Azure maakt automatisch een door het systeem toegewezen beheerde identiteit voor een Azure-service-exemplaar (zoals een Azure-VM, App Service of Azure Functions). Wanneer het service-exemplaar wordt verwijderd, worden de referenties en de identiteit die aan de service gekoppeld zijn, automatisch opgeruimd.

In het volgende voorbeeld wordt verbinding gemaakt met behulp van een door het systeem toegewezen beheerde identiteit van de hostomgeving. Als deze wordt uitgevoerd op een virtuele machine met een toegewezen beheerde identiteit, kan de code zich aanmelden met behulp van de toegewezen identiteit.

 Connect-AzAccount -Identity

Door de gebruiker toegewezen beheerde identiteit

Een door de gebruiker toegewezen beheerde identiteit is een identiteit die u in Microsoft Entra maakt en beheert. Deze kan worden toegewezen aan een of meer Azure-service-exemplaren. De levenscyclus van een door de gebruiker toegewezen beheerde identiteit wordt afzonderlijk beheerd van de service-exemplaren waaraan deze is toegewezen.

Wanneer u een door de gebruiker toegewezen beheerde identiteit gebruikt, moet u de parameter AccountId en de parameter Identity opgeven, zoals wordt weergegeven in het volgende voorbeeld.

 Connect-AzAccount -Identity -AccountId <user-assigned-identity-clientId-or-resourceId>

De volgende opdrachten maken verbinding met behulp van de beheerde identiteit van myUserAssignedIdentity. Hiermee wordt de door de gebruiker toegewezen identiteit toegevoegd aan de virtuele machine en wordt vervolgens verbinding gemaakt met behulp van de ClientId van de door de gebruiker toegewezen identiteit.

$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

Zie Beheerde identiteiten configureren voor Azure-resources op een Azure-VM-voor meer informatie.

Aanmelden met een service-principal

Als u zich wilt aanmelden met een service-principal, gebruikt u de parameter ServicePrincipal van de Connect-AzAccount-cmdlet. U hebt ook de volgende informatie nodig voor de service-principal:

  • AppId
  • Aanmeldingsreferenties of toegang tot het certificaat dat wordt gebruikt om de serviceprincipal te maken
  • Tenant-ID

Hoe u zich aanmeldt met een service-principal, is afhankelijk van of deze is geconfigureerd voor verificatie op basis van certificaten of wachtwoorden.

Verificatie op basis van certificaten

Zie Een Azure-service-principal maken met Azure PowerShellvoor meer informatie over het maken van een service-principal voor Azure PowerShell.

Verificatie op basis van certificaten vereist Dat Azure PowerShell informatie ophaalt uit een lokaal certificaatarchief op basis van een vingerafdruk van een certificaat.

Connect-AzAccount -ApplicationId $appId -Tenant $tenantId -CertificateThumbprint <thumbprint>

Wanneer u een service-principal gebruikt in plaats van een geregistreerde toepassing, geeft u de parameter ServicePrincipal op en geeft u de AppId van de service-principal op als de waarde voor de parameter ApplicationId.

Connect-AzAccount -ServicePrincipal -ApplicationId $servicePrincipalId -Tenant $tenantId -CertificateThumbprint <thumbprint>

In Windows PowerShell 5.1 kan het certificaatarchief worden beheerd en geïnspecteerd met de module PKI. Voor PowerShell 7.x en hoger is het proces anders. De volgende scripts laten zien hoe u een bestaand certificaat importeert in het certificaatarchief dat toegankelijk is voor PowerShell.

Een certificaat importeren in PowerShell 7.x en hoger

# 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()

Een certificaat importeren in 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

Verificatie op basis van een wachtwoord

Maak een service-principal voor gebruik met de voorbeelden in deze sectie. Zie Een Azure-service-principal maken met Azure PowerShellvoor meer informatie over het maken van service-principals.

$sp = New-AzADServicePrincipal -DisplayName ServicePrincipalName

Voorzichtigheid

Het opgegeven service-principalgeheim wordt opgeslagen in het AzureRmContext.json-bestand in uw gebruikersprofiel ($env:USERPROFILE\.Azure). Zorg ervoor dat deze map over de juiste beveiliging beschikt.

Gebruik de Get-Credential-cmdlet om de referenties van de service-principal op te halen als een object. Deze cmdlet vraagt om een gebruikersnaam en wachtwoord. Gebruik de AppId van de service-principal voor de gebruikersnaam en converteer de bijbehorende secret naar tekst zonder opmaak voor het wachtwoord.

# 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

Voor automatiseringsscenario's moet u referenties maken vanuit AppId en SecretTextvan een service-principal.

$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

Gebruik de juiste procedures voor wachtwoordopslag bij het automatiseren van service-principalverbindingen.

Zie ook