Configurar o Azure Service Principal: Guia de Acesso Não Assistido

Quando precisa automatizar tarefas no Azure com scripts e ferramentas, consideraria o uso de contas de serviço ou princípios de serviço do Azure? Não é incomum para alguns apenas criarem uma nova conta de serviço, atribuírem todas as funções de administrador desejadas e excluírem-na da autenticação multifator.

I know what you’re thinking – “that is a horrible idea”. Of course, it is! And for sure, your IT Sec will give you a lot of grief if you did all that.

Mas qual é a alternativa? Como pode usar uma credencial privilegiada com um escopo limitado que não precisa ser excluída da autenticação multifator? Tem sorte, porque é isso que este artigo vai ensinar.

Neste artigo, vai aprender o que é um Princípio de Serviço do Azure. Vai aprender como criar princípios de serviço com diferentes tipos de credenciais, como senhas, chaves secretas e certificados.

Há muitas ferramentas para criar Princípios de Serviço do Azure. Estas incluem o uso do Portal do Azure, Centro de Administração do Azure Active Directory, Azure AD PowerShell, Azure CLI, e Azure PowerShell. A ferramenta que será o foco deste artigo é o Azure PowerShell.

Ainda interessado? Continue lendo e vamos começar!

Requisitos

Uma vez que este é um artigo de aprender fazendo, aqui estão alguns pré-requisitos para que você possa acompanhar.

• Acesso a uma assinatura Azure. Seria melhor se você estivesse trabalhando em um inquilino de teste. Se você não tiver um, você pode se inscrever para um teste gratuito.
• Acesso a um computador que esteja executando o Windows 10 com o PowerShell 5.1.
• O módulo Azure PowerShell deve estar instalado.

Azure Service Principal vs. Service Account

Ferramentas e scripts de automação frequentemente precisam de acesso administrativo ou privilegiado. Por exemplo, provisionar contas de armazenamento ou iniciar e parar máquinas virtuais em um cronograma. E a maioria dos administradores provavelmente usa uma conta de usuário totalmente privilegiada (chamada de conta de serviço) para configurar os requisitos de credenciais para os scripts.

A service account is essentially a privileged user account used to authenticate using a username and password. And, if used with automation, a service account is most likely excluded from any conditional access policies or multi-factor authentication.

Por outro lado, um Azure service principal pode ser configurado para usar um nome de usuário e senha ou um certificado para autenticação. Pense nele como uma identidade de usuário sem um usuário, mas sim uma identidade para uma aplicação.

Um Azure service principal pode ser atribuído com acesso apenas ao mínimo necessário, como um recurso Azure específico. Por exemplo, você pode criar um Azure service principal que tenha acesso baseado em funções a uma assinatura inteira ou somente a uma única máquina virtual Azure.

Considerações principais para criar Azure Service Principals

Antes de criar um Azure service principal, você deve conhecer os detalhes básicos que precisa planejar. Esses detalhes podem parecer simples, mas tornarão a criação de um Azure service principal o mais eficiente e fácil possível.

O nome de exibição. Tudo começa com um nome, e um Azure service principal deve ter um nome. Não há regras aqui, mas sua organização pode ter uma convenção de nomenclatura prescrita.

• O tipo de credencial a ser usado. Você pode optar por criar um Azure service principal que usará uma senha ou certificado para autenticação. Isso não significa que você só possa escolher um, você pode usar ambos.

Para service principals, o nome de usuário e a senha são mais apropriadamente chamados de ID do aplicativo e chave secreta.

• O período de validade da(s) credencial(ais). Seja atribuindo uma senha ou uma credencial de certificado, você deve definir uma data de início e término para sua validade. Por quanto tempo uma credencial será válida geralmente depende de com que frequência você está disposto a girar/renew certificados e senhas.

• O escopo de acesso. Você está criando um Azure service principal que terá acesso a uma assinatura, grupo de recursos ou recursos selecionados?

• O papel. Existem vários papéis disponíveis, como Contributor, Reader e Owner, para citar alguns. Você precisa definir qual papel é “suficiente” para o service principal.

Criando um Azure Service Principal com Chave Secreta Atribuída Automaticamente

O cerne da criação de um novo service principal no Azure é o cmdlet New-AzAdServicePrincipal. Neste exemplo, será criado um novo service principal com estes valores:

DisplayName: AzVM_Reader

Scope: AzVM1 (Máquina Virtual)

Função: Reader

Senha: <atribuída automaticamente>

Validade das Credenciais: 1 ano

Obtendo o ID do Escopo Alvo (Máquina Virtual)

Como pode ver, o escopo deste novo service principal é apenas para a máquina virtual chamada AzVM1. No entanto, o parâmetro -Scope não aceita apenas o nome, mas o ID completo do recurso. Portanto, neste exemplo, a primeira coisa a fazer é obter o ID da máquina virtual AzVM1. Para isso, utilize o código abaixo.

Get-AzVM | Format-Table Name, ID

Ao executar o código acima no PowerShell, deverá ver a lista de nomes e IDs de VM, semelhante à captura de ecrã abaixo.

Criando o Azure Service Principal com Chave Secreta

Agora que tem o ID do escopo alvo, que é o ID da máquina virtual AzVM1, pode utilizar o comando abaixo para criar o novo service principal que tem a função de reader. As propriedades do novo service principal serão armazenadas na variável $sp.

$sp = New-AzAdServicePrincipal `
	-DisplayName AzVM_Reader `
	-Scope '/subscriptions/5e252811-b376-4136-b8ae-d3b8abe2c9c3/resourceGroups/ATA/providers/Microsoft.Compute/virtualMachines/AzVM1'
	-Role 'Reader'

Como resultado do comando acima, o service principal foi criado com estes valores abaixo.

Descriptografando a Chave Secreta

Agora você tem o ID do Aplicativo e o Segredo, que é o nome de usuário e a senha do principal de serviço. No entanto, o valor do Segredo é mostrado como System.Security.SecureString. Você vai querer saber qual é o segredo. Para isso, use o comando abaixo para converter o segredo em texto simples.

# Converter a senha criptografada para texto simples
[System.Runtime.InteropServices.Marshal]::PtrToStringAuto(
    [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR(
        $sp.Secret
    )
)

O comando acima converte o valor da string segura de $sp.Secret para texto simples. Veja a imagem abaixo para referência.

Verificando a Atribuição de Função Principal de Serviço do Azure

Como você sabe se isso funcionou? Você pode verificar a lista de controle de acesso do recurso usando o Portal do Azure. Por exemplo, na imagem abaixo, você pode ver que o principal de serviço AzVM_Reader agora tem acesso de Leitor à máquina virtual AzVM1.

Também, você pode usar o comando Get-AzRoleAssignment -ObjectID $sp.id para obter as atribuições de função do principal de serviço do Azure. Veja a captura de tela abaixo como exemplo.

Criando um Principal de Serviço do Azure com Senha

Se você deseja ter mais controle sobre qual senha ou chave secreta é atribuída ao seu principal de serviço do Azure, use o parâmetro -PasswordCredential durante a criação do principal de serviço. Isso é especialmente útil se a senha precisar atender a um requisito de complexidade.

Neste exemplo, o novo principal de serviço do Azure será criado com estes valores:

NomeExibição: ATA_RG_Contributor

Escopo: ATA (Grupo de Recursos)

Função: Contribuidor

Senha: Comprimento de 20 caracteres com 6 caracteres não alfanuméricos

Validade das Credenciais: 5 anos

Obtendo o ID do Escopo Alvo (Grupo de Recursos)

O escopo deste novo principal de serviço abrange todo o grupo de recursos chamado ATA. A primeira coisa a fazer é obter o ID do grupo de recursos ATA. Para fazer isso, use o código abaixo, mas certifique-se de alterar o valor do parâmetro -Name para o nome do seu grupo de recursos.

# Obter o valor do ResourceId do grupo de recursos
$Scope = (Get-AzResourceGroup -Name ATA).ResourceId
$Scope

Em seguida, você deve ver o ResourceID do grupo de recursos que agora está armazenado na variável $Scope.

Gerando a String de Senha

O próximo passo é gerar a senha que segue a complexidade de 20 caracteres de comprimento com 6 caracteres não alfanuméricos. Para isso, você pode utilizar o método estático do .NET GeneratePassword().

# Gerar uma Senha Aleatória usando o método estático GeneratePassword()
Add-Type -AssemblyName 'System.Web'
$password = [System.Web.Security.Membership]::GeneratePassword(20, 6)
$password

No código acima GeneratePassword(20, 6), o primeiro valor significa o comprimento da senha e o segundo valor significa o número de caracteres não alfanuméricos a serem incluídos. O resultado é mostrado na captura de tela abaixo.

Criando o Objeto de Credencial de Senha

Agora que você tem a string de senha, o próximo passo é criar o objeto Microsoft.Azure.Commands.ActiveDirectory.PSADPasswordCredential. Este objeto conterá a string de senha armazenada na variável $password e o período de validade de 5 anos. Copie o código abaixo e execute-o em sua sessão do Azure PowerShell.

# Criar o Objeto de Credencial de Senha
[Microsoft.Azure.Commands.ActiveDirectory.PSADPasswordCredential]`
    $PasswordCredential = @{
    StartDate = Get-Date;
    EndDate   = (Get-Date).AddYears(5);
    Password  = $password
}
$PasswordCredential

A execução do código acima no PowerShell resultará no armazenamento do objeto de credencial na variável $PasswordCredential. O resultado esperado será semelhante ao mostrado abaixo.

Criando o Principal de Serviço com Senha

Agora você tem os valores dos parâmetros necessários prontos para criar o principal de serviço Azure. O código abaixo criará o principal de serviço com o nome de exibição ATA_RG_Contributor e usando a senha armazenada na variável $PasswordCredential.

# Criar o Principal de Serviço com uma Credencial de Senha
$sp = New-AzAdServicePrincipal `
    -DisplayName 'ATA_RG_Contributor' `
    -PasswordCredential $PasswordCredential
$sp

Após executar o código, o novo principal de serviço deve ser criado, e as propriedades são armazenadas na variável $sp. Veja o exemplo de resultado abaixo.

Atribuindo a Função e o Escopo

O principal de serviço Azure foi criado na seção anterior, mas sem Função e Escopo. Isso ocorre porque os parâmetros -Role e -Scope não podem ser usados junto com o parâmetro -PasswordCredential. Isso significa que um passo adicional é necessário para atribuir a função e o escopo ao principal de serviço.

O código abaixo utiliza o cmdlet New-AzRoleAssignment para atribuir o escopo e a função do principal de serviço do Azure.

# Atribuir a função ao recurso alvo
New-AzRoleAssignment -$azSubscription = Get-AzSubscription -SubscriptionName VSE3
$Scope = "/subscriptions/$($azSubscription.ID)"
$TenantID = $azSubscription.TenantID$sp.ApplicationId `
    -Scope $Scope `
    -RoleDefinitionName 'Contributor'

A captura de tela abaixo mostra o resultado esperado após a atribuição da função e do escopo ao principal de serviço do Azure.

Sempre certifique-se de salvar a senha do principal de serviço, pois não há como recuperá-la se você não conseguir salvá-la ou se a esquecer.

Conectando ao Azure com uma Senha de Principal de Serviço

Agora, para usar o principal de serviço. Em vez de fazer login no Azure PowerShell usando uma conta de usuário, o código abaixo utiliza as credenciais do principal de serviço.

# Obter o principal de serviço com o nome de exibição ATA_RG_Contributor
$sp = Get-AzADServicePrincipal -DisplayName ATA_RG_Contributor

# Obter o ID do locatário
$TenantID = (Get-AzContext).Tenant.ID

# Obter o primeiro nome do principal de serviço
$user = $sp.ServicePrincipalNames[0]

# Converter a senha em uma string segura
$secPassword = $password | ConvertTo-SecureString -AsPlainText -Force

# Criar o objeto PSCredential
$credential = [PSCredential]::New($user,$secPassword)

# Conectar-se ao Azure
Connect-AzAccount -ServicePrincipal -Credential $credential -Tenant $TenantID
# Obter o principal de serviço com o nome de exibição ATA_RG_Contributor
$sp = Get-AzADServicePrincipal -DisplayName ATA_RG_Contributor

# Obter o ID do locatário
$TenantID = (Get-AzContext).Tenant.ID

# Obter o primeiro nome do principal de serviço
$user = $sp.ServicePrincipalNames[0]

# Converter a senha em uma string segura
$secPassword = $password | ConvertTo-SecureString -AsPlainText -Force

# Criar o objeto PSCredential
$credential = [PSCredential]::New($user,$secPassword)

# Conectar-se ao Azure
Connect-AzAccount -ServicePrincipal -Credential $credential -Tenant $TenantID# Obter o principal de serviço com o nome de exibição ATA_RG_Contributor
$sp = Get-AzADServicePrincipal -DisplayName ATA_RG_Contributor

# Obter o ID do locatário
$TenantID = (Get-AzContext).Tenant.ID

# Obter o primeiro nome do principal de serviço
$user = $sp.ServicePrincipalNames[0]

# Converter a senha em uma string segura
$secPassword = $password | ConvertTo-SecureString -AsPlainText -Force

# Criar o objeto PSCredential
$credential = [PSCredential]::New($user,$secPassword)

# Conectar-se ao Azure
Connect-AzAccount -ServicePrincipal -Credential $credential -Tenant $TenantID

Depois de executar o código acima, você deverá estar autenticado no Azure PowerShell usando o principal de serviço ATA_RG_Contributor e credencial de senha.

Criando um Principal de Serviço do Azure com Certificado

Além de credenciais de senha, um principal de serviço do Azure também pode ter uma credencial baseada em certificado. O certificado associado pode ser emitido por uma autoridade de certificação ou autoassinado.

Neste exemplo, o novo principal de serviço do Azure será criado com estes valores:

DisplayName: VSE3_SUB_OWNER

Escopo: VSE3 (Assinatura)

Função: Proprietário

Validade do Certificado: 2 anos

Obtendo o ID do Escopo de Destino (Assinatura)

O escopo deste novo principal de serviço abrange a assinatura Azure chamada VSE3. A primeira coisa a fazer é obter o ID da assinatura VSE3. Para fazer isso, use o código abaixo, mas certifique-se de alterar o valor do parâmetro -SubscriptionName para o nome do seu grupo de recursos.

# Obter o ID do escopo da Assinatura e o ID do Inquilino
$azSubscription = Get-AzSubscription -SubscriptionName VSE3
$Scope = "/subscriptions/$($azSubscription.ID)"
$TenantID = $azSubscription.TenantID

Em seguida, especifique o nome do novo principal de serviço do Azure e o certificado autoassinado a serem criados.

# O nome do novo principal de serviço do Azure e o certificado autoassinado
$DisplayName = 'VSE3_SUB_OWNER'

Criando o Certificado Autoassinado

O código abaixo cria o certificado autoassinado no armazenamento de certificados pessoais com o nome CN=VSE3_SUB_OWNER. A validade do certificado é definida para dois anos. As propriedades do certificado são salvas na variável $cert.

# Gerar um Certificado Autoassinado
$cert = New-SelfSignedCertificate -CertStoreLocation "cert:\CurrentUser\My" `
    -Subject "CN=$($DisplayName)" `
    -KeySpec KeyExchange `
    -NotBefore ((Get-Date).AddDays(-1)) `
    -NotAfter ((Get-Date).AddYears(2))
$cert

A captura de tela abaixo mostra que o certificado foi criado.

Se você deseja ver o novo certificado em uma visualização mais familiar (GUI), pode encontrá-lo no console de Certificados (certmgr.mmc). Consulte a imagem abaixo que mostra o certificado.

O próximo passo é obter o valor codificado em Base64 do certificado autoassinado e salvá-lo na variável $keyValue.

# Obter o valor em base64 do certificado autoassinado
$keyValue = [System.Convert]::ToBase64String($cert.GetRawCertData())

Criando o Principal de Serviço com Certificado

Agora que o certificado foi criado, o próximo passo é criar o novo principal de serviço do Azure. O código abaixo criará o principal de serviço do Azure que usará o certificado autoassinado como sua credencial. O período de validade da credencial coincide com o período de validade do certificado.

$sp = New-AzADServicePrincipal -DisplayName $DisplayName `
    -CertValue $keyValue `
    -EndDate $cert.NotAfter `
    -StartDate $cert.NotBefore
$sp

Você obterá uma saída semelhante, como mostrado na imagem abaixo.

Atribuindo a Função e o Escopo

O principal de serviço do Azure foi criado, mas ainda não foram atribuídos Função e Escopo. Isso significa que é necessário um passo adicional para atribuir a função e o escopo ao principal de serviço.

O código abaixo utiliza o cmdlet New-AzRoleAssignment para atribuir a função de proprietário à assinatura VSE3 do principal de serviço.

# Atribuir função e escopo
New-AzRoleAssignment -ApplicationId $sp.ApplicationId `
    -Scope $Scope `
    -RoleDefinitionName 'Owner'

Ao executar o código, a captura de tela abaixo mostra a confirmação de que a atribuição da função foi realizada.

Conectando ao Azure com um Certificado de Principal de Serviço

Agora você criou o principal de serviço com uma credencial baseada em certificado. Isso significa que você pode usá-lo para se conectar ao Azure sem usar uma senha. Em vez disso, você usará o certificado disponível em seu computador como método de autenticação.

Neste exemplo, o nome de exibição do principal de serviço é VSE3_SUB_OWNER, e o nome do certificado é CN=VSE3_SUB_OWNER. O código abaixo obterá a impressão digital do certificado da loja de certificados pessoais e a usará como credencial de login.

# Obter o certificado com o assunto CN=VSE3_SUB_OWNER
$cert = Get-ChildItem Cert:\CurrentUser\My\ | Where-Object { $_.Subject -eq 'CN=VSE3_SUB_OWNER' }

# Conectar ao Azure
Connect-AzAccount -ServicePrincipal -CertificateThumbprint $cert.ThumbPrint -ApplicationID $sp.ApplicationID -Tenant $TenantID

A captura de tela abaixo mostra que usando o código acima, o login no Azure PowerShell foi bem-sucedido usando apenas ApplicationID, Tenant e Impressão digital do Certificado.

Conclusão

Os Principais de Serviço do Azure são os principais de segurança que devem ser considerados ao criar credenciais para tarefas de automação e ferramentas que acessam recursos do Azure. O escopo e a função a serem aplicados podem ser selecionados para fornecer permissões de acesso “suficientes”.

Neste artigo, você aprendeu como criar Azure Service Principals usando apenas o PowerShell. Os Azure Service Principals podem ter uma senha, uma chave secreta ou credenciais baseadas em certificado. Cada um desses tipos de credenciais tem suas vantagens e cenários de uso aplicáveis.

Os service principals com uma senha ou credencial de chave secreta são mais portáteis, mas considerados menos seguros porque a credencial pode ser compartilhada como texto simples. Por outro lado, as credenciais baseadas em certificado são a opção mais segura, mas exigem um pouco mais de esforço para serem mantidas.

As técnicas que você aprendeu neste artigo cobriram apenas o básico para começar a usar service principals do Azure em sua automação. Existem muitas outras maneiras de configurar service principals do Azure, como adicionar, remover e redefinir credenciais. Depende de você descobri-las conforme avança.

Obrigado por ler!

Recursos de Aprendizagem Adicionais

Aqui estão alguns recursos que você pode achar úteis para acompanhar este artigo.

• Connect-AzAccount: Seu Portal Para o Azure com PowerShell
• Connect-AzAccount: Seu Portal Para o Azure com PowerShell
• Como Gerar uma Senha Aleatória com PowerShell
• O que é o controle de acesso baseado em funções do Azure (Azure RBAC)?
• Desmistificando os Princípios de Serviço do Azure AD
• Como Criar um Principal de Serviço do Azure Via Azure CLI 2.0
• Como Controlar o Acesso aos Serviços do Office 365 com MFA