Criar uma entidade de serviço e uma chave

Concluído

Agora que entende o conceito de principal de serviço, pode questionar-se como ele comprova a sua identidade ao Microsoft Entra ID. Nesta unidade, vais aprender sobre o processo de autenticação e as credenciais dos principais de serviço. Você também aprenderá a criar um principal de serviço e atribuir-lhe uma chave.

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

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

Em termos gerais, esse processo é semelhante a como as coisas funcionam quando você mesmo entra no Azure como usuário. No entanto, em comparação com os usuários, as entidades de serviço têm um tipo ligeiramente diferente de credencial para provar sua identidade. As entidades de serviço usam duas credenciais principais: chaves e certificados.

Observação

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

Chaves

As chaves são semelhantes às 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 chaves para garantir que:

• As chaves são criptograficamente aleatórias. Ou seja, são extremamente difíceis de adivinhar.
• Os seres humanos não usam acidentalmente senhas fracas como chaves.

As entidades de serviço geralmente têm permissões altamente privilegiadas, por isso é essencial que sejam seguras. Normalmente, você só precisa lidar brevemente com a chave ao configurar pela primeira vez o serviço principal e o seu pipeline. Assim, a chave não precisa ser memorável ou fácil 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. Tal como as palavras-passe, as chaves têm uma data de validade. Você aprenderá mais sobre isso em breve.

Observação

Pense em chaves como senhas muito importantes, semelhantes às chaves de conta de armazenamento. Deve tratá-los com o mesmo nível de segurança e atenção.

Certificados

Os certificados são outra maneira de autenticar 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 certificados neste módulo. No entanto, se trabalhar com um principal de serviço que usa autenticação por certificado, funciona basicamente da mesma maneira que qualquer outro principal de serviço em termos de gestão e atribuição de permissões ao seu pipeline.

Observação

Os certificados são uma boa opção quando você pode usá-los. São mais difíceis para os atacantes roubarem. Também é mais difícil intercetar 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 se cria uma entidade de serviço, geralmente pede-se ao Azure que crie uma chave ao mesmo tempo. O Azure normalmente gera uma chave aleatória para você.

Observação

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

O Azure mostra a chave quando você cria a entidade de serviço. Esta é a única vez que o Azure lhe mostrará a chave. Depois disso, você não pode mais recuperá-lo. É importante que você copie a chave com segurança para que possa usá-la ao configurar seu pipeline. Não partilhe a chave por e-mail ou outro meio não seguro. Se você perder uma chave, deverá excluí-la e criar uma nova.

Gerenciar entidades de serviço para Pipelines do Azure

Quando se cria uma chave para a entidade de serviço de um pipeline, é recomendável copiar a chave imediatamente para a configuração do pipeline. Dessa forma, você evita armazenar ou transmitir a chave desnecessariamente.

As ferramentas de pipeline incluem maneiras seguras de especificar o ID e a chave do aplicativo da 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 quando trabalhar com o Azure Pipelines. Neste módulo, discutimos 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

Os Pipelines do Azure podem criar entidades de serviço para você automaticamente. Neste módulo, você criará e gerenciará manualmente suas entidades de serviço para obter uma melhor compreensão 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 requer ter as permissões relacionadas no Microsoft Entra ID. Em algumas organizações, você pode precisar de um administrador para executar essas etapas para você.

Para criar um principal do 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 ao principal de serviço. Você aprenderá sobre esse assunto mais adiante neste módulo. Por enquanto, aqui está um exemplo que ilustra como criar um principal 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. Esta propriedade é a chave da entidade de serviço. Você não pode obter essa chave novamente, então certifique-se de usá-la imediatamente ou salvá-la em algum lugar com segurança.

Observação

O comando az ad sp create-for-rbac cria um registo de aplicação no Microsoft Entra ID, adiciona uma entidade de serviço ao inquilino do Microsoft Entra e cria uma chave para o registo da aplicação. Outro comando, az ad sp create, cria apenas a entidade de serviço no seu inquilino (e não o registo da aplicação). Ao criar entidades de serviço para pipelines, geralmente az ad sp create-for-rbac é o melhor comando a utilizar.

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 requer que tenha as permissões relacionadas no Microsoft Entra ID. Em algumas organizações, você pode precisar de 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 pode, opcionalmente, atribuir funções ao principal do serviço. Você aprenderá sobre esse assunto mais adiante neste módulo. Por enquanto, aqui está um exemplo que ilustra como criar um principal de serviço sem atribuições de funções no Azure.

$servicePrincipal = New-AzADServicePrincipal -DisplayName MyPipeline

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

$servicePrincipalKey = $servicePrincipal.PasswordCredentials.SecretText

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

Observação

O cmdlet New-AzADServicePrincipal cria um registo de aplicação no Microsoft Entra ID, adiciona um principal de serviço ao tenant do Microsoft Entra e cria uma chave de acesso para o registo da aplicação.

Identificar uma entidade de serviço

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

• ID do aplicativo: O registro do aplicativo tem um identificador exclusivo, muitas vezes chamado de ID de aplicativo ou, às vezes, um ID de cliente . Normalmente, usas isso como o nome de utilizador quando o principal de serviço entra no Azure.
• Identificador do objeto: O registo da aplicação e a entidade de serviço têm identificadores de objeto distintos, que são únicos e atribuídos pelo Microsoft Entra ID. Ocasionalmente, você precisará usar essas IDs de objeto ao gerenciar uma entidade de serviço.
• Nome para exibição: Este é um nome legível por humanos 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 a sua equipa a entender para que serve o principal de serviço, para que ninguém a exclua por engano ou altere as suas permissões.

Atenção

Um nome para exibição não é exclusivo. Várias entidades de serviço podem compartilhar o mesmo nome para 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 acidentalmente dar permissões para o principal de serviço errado. É uma boa prática usar o ID do aplicativo.

Quando crias um principal de serviço, normalmente defines apenas o nome para 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 tempo de expiração. Por padrão, o tempo de expiração é definido como um ano. Após esse tempo de expiração, a chave não funciona mais e o pipeline não pode entrar no Microsoft Entra ID. Você precisa renovar ou girar teclas regularmente.

Atenção

Pode ser tentador definir longos tempos de expiração para as suas chaves, mas não deve fazê-lo. As entidades de serviço são protegidas apenas pelas suas credenciais. Se um invasor obtiver a chave de uma entidade de serviço, ele pode causar muitos danos. A melhor abordagem para minimizar o período que um ataque pode durar é mudar regularmente as suas chaves. Você também deve excluir e recriar chaves se suspeitar que elas foram vazadas.

Para redefinir uma chave para um principal de serviço, use o comando az ad sp com a ID da aplicação, como neste exemplo:

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

Você também pode remover e recriar a chave do principal de serviço em dois passos distintos usando os comandos az ad sp credential delete e depois az ad sp credential reset --append.

Para redefinir uma chave para uma entidade de serviço, primeiro utilize o cmdlet Remove-AzADServicePrincipalCredential para remover a credencial existente. Em seguida, use o cmdlet New-AzADServicePrincipalCredential para adicionar uma nova credencial. Ambos os cmdlets usam a ID do objeto da entidade de serviço para identificá-lo. 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 com segurança seu aplicativo para usar uma nova chave enquanto a chave antiga ainda estiver válida e, em seguida, excluir a chave antiga quando ela não estiver mais em uso. Esta técnica evita a indisponibilidade causada pela expiração da chave.

Gerir o ciclo de vida do seu principal de serviço

É importante considerar todo o ciclo de vida de cada entidade de serviço criada. Quando se cria uma entidade de serviço para um pipeline, o que acontecerá se o pipeline for eliminado ou deixar de ser usado?

As entidades principais de serviço não são removidas automaticamente, pelo que deve auditar e remover as entidades principais 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 boa prática documentar seus diretores de serviço em um local que você e sua equipe possam acessar facilmente. Você deve incluir as seguintes informações para cada entidade de serviço:

• Informações de identificação essenciais, incluindo o seu nome e ID de aplicação.
• A finalidade da entidade de serviço.
• Quem o criou, quem é responsável por gerenciá-lo e suas chaves e quem pode ter respostas se houver um problema.
• As permissões de que necessita e uma justificação clara para o motivo pelo qual precisa delas.
• Qual é a sua vida útil esperada.

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