Criar uma entidade de serviço e uma chave

Concluído

Agora que você entende o conceito de uma entidade de serviço, pode se perguntar como ela comprova sua identidade para o Microsoft Entra ID. Nesta unidade, você aprenderá sobre o processo de autenticação e credenciais para entidades de serviço. Você também aprenderá como criar uma entidade de serviço e fornecer uma chave para ela.

Entender como as entidades de serviço são autenticadas

Quando uma entidade de serviço precisa se comunicar com o Azure, ela se conecta ao Microsoft Entra ID. Depois que o Microsoft Entra ID verifica a identidade da entidade de serviço, ele emite um token que o aplicativo cliente armazena e usa quando faz qualquer solicitação para o Azure.

Em geral, esse processo funciona de forma semelhante a quando você entra no Azure por conta própria como um usuário. No entanto, comparando-se aos usuários, as entidades de serviço têm um tipo de credencial um pouco diferente para provar sua identidade. As entidades de serviço usam duas credenciais principais: as chaves e os certificados.

Observação

Lembre-se de que as identidades gerenciadas são entidades de serviço especiais que funcionam no Azure. Elas têm um tipo diferente de processo de autenticação que não exige que você conheça ou manipule credenciais.

simétricas

As chaves são semelhantes a senhas. No entanto, as chaves são muito mais longas e complexas. Na verdade, para a maioria das situações, o Microsoft Entra ID gera as próprias chaves para garantir que:

• As chaves sejam criptograficamente aleatórias. Ou seja, elas são extremamente difíceis de se adivinhar.
• As pessoas não usam acidentalmente senhas fracas como chaves.

As entidades de serviço geralmente têm permissões de alto privilégio, portanto, é essencial que elas sejam seguras. Normalmente, você só precisa lidar por um curto período de tempo com a chave ao configurar pela primeira vez a entidade de serviço e seu pipeline. Portanto, a chave não precisa ser fácil de lembrar ou de digitar.

Uma única entidade de serviço pode ter várias chaves ao mesmo tempo, mas os usuários não podem ter várias senhas. Como senhas, as chaves têm uma data de validade. Você aprenderá mais sobre isso em breve.

Observação

Considere as chaves como senhas muito importantes, semelhantes às chaves de conta de armazenamento. Você deve tratá-las com o mesmo nível de segurança e cuidado.

Certificados

Os certificados são outra maneira de autenticar as entidades de serviço. Eles são muito seguros, mas podem ser difíceis de gerenciar. Algumas organizações exigem o uso de certificados para determinados tipos de entidades de serviço.

Não discutiremos os certificados neste módulo. No entanto, se você trabalha com uma entidade de serviço que usa a autenticação de certificado, ela funciona basicamente da mesma forma que qualquer outra entidade de serviço em termos de gerenciamento e concessão de permissão para seu pipeline.

Observação

Os certificados são uma boa opção quando você pode usá-los. Eles são mais difíceis para invasores roubarem. Também é mais difícil interceptar e modificar solicitações que usam certificados. No entanto, os certificados exigem mais infraestrutura e têm alguma sobrecarga de manutenção contínua.

Trabalhar com chaves para entidades de serviço

Quando você cria uma entidade de serviço, geralmente solicita que o Azure crie, ao mesmo tempo, uma chave. O Azure normalmente gera uma chave aleatória para você.

Observação

Lembra da nossa discussão anterior sobre como as entidades de serviço funcionam? As chaves são armazenadas como parte do objeto de registro de aplicativo. Se você abrir o portal do Azure, procure na configuração do Microsoft Entra e, em seguida, vá para os registros de aplicativo. Você pode criar e excluir chaves por lá também.

O Azure mostra a chave quando você cria a entidade de serviço. Essa é a única vez que o Azure mostrará a chave a você. Depois disso, você não poderá mais recuperá-la. É importante que você a copie para um lugar seguro, para que possa usá-la ao configurar o pipeline. Não compartilhe a chave por email ou por outro meio não seguro. Se você perder uma chave, precisará excluí-la e criar uma nova.

Gerenciar entidades de serviço para o Azure Pipelines

Quando você cria uma chave para a entidade de serviço de um pipeline, uma boa ideia é copiá-la imediatamente na configuração do pipeline. Dessa forma, você evita armazenar ou transmitir a chave desnecessariamente.

As ferramentas de pipeline incluem maneiras seguras de especificar a ID do aplicativo e a chave da sua entidade de serviço. Nunca armazene credenciais de qualquer tipo no controle do código-fonte. Em vez disso, use conexões de serviço ao trabalhar com o Azure Pipelines. Neste módulo, discutiremos apenas como criar uma entidade de serviço e uma chave. Você aprenderá como configurar seu pipeline com a chave em um módulo posterior.

Dica

O Azure Pipelines pode criar entidades de serviço para você automaticamente. Neste módulo, você vai criar e gerenciar manualmente suas entidades de serviço para ter uma compreensão melhor do que está acontecendo. Em outros módulos, você usará o método de criação automática para simplificar.

Criar uma entidade de serviço e uma chave

Você pode usar a CLI do Azure para criar e gerenciar entidades de serviço.

Observação

Criar e modificar entidades de serviço exige que você tenha as permissões relacionadas no Microsoft Entra ID. Em algumas organizações, talvez seja necessário um administrador para executar essas etapas para você.

Para criar uma entidade de serviço e uma chave, use o comando az ad sp create-for-rbac. Este comando aceita vários argumentos e, opcionalmente, pode atribuir funções à entidade de serviço. Você aprenderá sobre esse assunto logo a seguir neste módulo. Por enquanto, aqui está um exemplo que ilustra como criar uma entidade de serviço sem nenhuma atribuição de função do Azure:

az ad sp create-for-rbac --name MyPipeline

Quando você executa esse comando, a CLI do Azure retorna uma resposta JSON com uma propriedade password. Essa propriedade é a chave da entidade de serviço. Você não consegue obter essa chave novamente, portanto, certifique-se de usá-la imediatamente ou salvá-la em algum lugar seguro.

Observação

O comando az ad sp create-for-rbac cria um registro de aplicativo no Microsoft Entra ID, adiciona uma entidade de serviço ao seu locatário do Microsoft Entra, e cria uma chave para o registro de aplicativo. Outro comando, az ad sp create, só cria a entidade de serviço em seu locatário (não o registro de aplicativo). Quando você cria entidades de serviço para pipelines, az ad sp create-for-rbac geralmente é o melhor comando a ser usado.

Você pode usar os cmdlets do Azure PowerShell para criar e gerenciar entidades de serviço.

Observação

Criar e modificar entidades de serviço exige que você tenha as permissões relacionadas no Microsoft Entra ID. Em algumas organizações, talvez seja necessário um administrador para executar essas etapas para você.

Para criar uma entidade de serviço e uma chave, use o cmdlet New-AzADServicePrincipal. Este cmdlet aceita vários argumentos e, opcionalmente, pode atribuir funções à entidade de serviço. Você aprenderá sobre esse assunto logo a seguir neste módulo. Por enquanto, aqui está um exemplo que ilustra como criar uma entidade de serviço sem nenhuma atribuição de função do Azure:

$servicePrincipal = New-AzADServicePrincipal -DisplayName MyPipeline

Quando você executa esse comando, o Azure PowerShell popula a variável servicePrincipal com informações sobre a entidade de serviço, incluindo a chave:

$servicePrincipalKey = $servicePrincipal.PasswordCredentials.SecretText

Você não consegue obter essa chave novamente, portanto, certifique-se de usá-la imediatamente ou salvá-la em algum lugar seguro.

Observação

O cmdlet New-AzADServicePrincipal cria um registro de aplicativo no Microsoft Entra ID, adiciona uma entidade de serviço ao seu locatário do Microsoft Entra e cria uma chave para o registro de aplicativo.

Identificar uma entidade de serviço

As entidades de serviço têm vários identificadores e nomes que você usará para identificá-las e trabalhar com elas. Os identificadores que você mais usará são:

• ID do aplicativo: o registro de aplicativo tem um identificador exclusivo, geralmente chamado de ID do aplicativo ou, às vezes, de ID do cliente. Normalmente, você o usa como o nome de usuário quando a entidade de serviço se conecta ao Azure.
• ID do Objeto: O registro de aplicativo e a entidade de serviço têm suas próprias IDs de objeto separadas, que são identificadores exclusivos atribuídos pelo Microsoft Entra ID. Ocasionalmente, você precisará usar essas IDs de objeto ao gerenciar uma entidade de serviço.
• Nome de exibição: este é um nome legível que descreve a entidade de serviço.

Dica

Use um nome de exibição claro e descritivo para sua entidade de serviço. É importante ajudar sua equipe a entender o que é a entidade de serviço, para que ninguém a exclua acidentalmente ou altere suas permissões.

Cuidado

Um nome de exibição não é exclusivo. Várias entidades de serviço podem compartilhar o mesmo nome de exibição. Tenha cuidado ao conceder permissões a uma entidade de serviço usando seu nome de exibição para identificá-la. Você pode conceder permissões acidentalmente à entidade de serviço errada. Em vez disso, é uma prática recomendada usar a ID do aplicativo.

Quando você cria uma entidade de serviço, normalmente você só define o nome de exibição. O Azure atribui os outros nomes e identificadores automaticamente.

Manipular chaves expiradas

As entidades de serviço não expiram, mas suas chaves sim. Ao criar uma chave, você pode configurar seu período de validade. Por padrão, o período de validade é definido como um ano. Após esse período, a chave não funcionará mais e o pipeline não poderá se conectar ao Microsoft Entra ID. Você precisa renová-las ou fazer a rotação das chaves regularmente.

Cuidado

Pode ser tentador definir períodos de validades mais longos para suas chaves, mas você não deve fazer isso. As entidades de serviço são protegidas somente por suas credenciais. Se um invasor obtiver a chave de uma entidade de serviço, poderá causar grandes danos. A melhor abordagem para minimizar o período de duração de um ataque é alterar regularmente suas chaves. Você também deve excluir e recriar as chaves se suspeitar que elas vazaram.

Para redefinir uma chave para uma entidade de serviço, use o comando az ad sp com a ID do aplicativo, como neste exemplo:

az ad sp credential reset --id "b585b740-942d-44e9-9126-f1181c95d497"

Você também pode remover e recriar a chave da entidade de serviço em duas etapas separadas usando os comandos az ad sp credential delete e az ad sp credential reset --append.

Para redefinir uma chave para uma entidade de serviço, primeiro use o cmdlet Remove-AzADServicePrincipalCredential para remover a credencial existente. Em seguida, use o cmdlet New-AzADServicePrincipalCredential para adicionar uma nova credencial. Esses cmdlets usam a ID de objeto da entidade de serviço para identificá-la. Antes de usar os cmdlets, você precisa obter essa ID da ID do aplicativo:

$applicationId = APPLICATION_ID
$servicePrincipalObjectId = (Get-AzADServicePrincipal -ApplicationId $applicationId).Id

Remove-AzADServicePrincipalCredential -ObjectId $servicePrincipalObjectId

$newCredential = New-AzADServicePrincipalCredential -ObjectId $servicePrincipalObjectId
$newKey = $newCredential.SecretText

Dica

Uma única entidade de serviço pode ter várias chaves. Você pode atualizar seu aplicativo com segurança para que ele use uma nova chave enquanto a chave antiga ainda for válida e, em seguida, excluir a chave antiga quando ela não estiver mais em uso. Essa técnica evita o tempo de inatividade de expiração da chave.

Gerenciar o ciclo de vida de sua entidade de serviço

É importante considerar todo o ciclo de vida de cada entidade de serviço que você criar. Quando você cria uma entidade de serviço para um pipeline, o que acontecerá se o pipeline for eventualmente excluído, ou não for mais utilizado?

As entidades de serviço não são removidas automaticamente, portanto, você precisa auditar e remover entidades de serviço antigas. É importante remover entidades de serviço antigas pelo mesmo motivo que você exclui contas de usuário antigas: os invasores podem obter acesso às suas chaves. É melhor não ter credenciais que não sejam usadas ativamente.

É uma prática recomendada documentar suas entidades de serviço em um lugar que você e sua equipe possam acessar facilmente. Você deve incluir as seguintes informações para cada entidade de serviço:

• Informações essenciais de identificação, incluindo nome e ID do aplicativo.
• A finalidade da entidade de serviço.
• Quem a criou, quem é responsável por gerenciar a entidade e suas chaves, e quem pode ter respostas caso ocorra algum problema.
• As permissões necessárias e uma justificativa clara para o motivo de precisar dessas permissões.
• Qual é o tempo de vida esperado.

Você deve auditar regularmente suas entidades de serviço para garantir que elas ainda estejam sendo usadas e que as permissões atribuídas ainda estejam corretas.