Você conhece todos os tipos de identidades existentes no Azure? Para que eles servem e quais suas peculiaridades? Hoje vamos falar sobre as identidades de usuários e os diferentes tipos de identidade para os workloads!
Para que são usadas?
As identidades são utilizadas para identificar algo, seja um usuário ou um recurso/aplicação e para termos uma maneira de controlar o acesso aos recursos da plataforma.
Dentre as identidades existentes no Azure, temos 3 tipos:
Identidades de usuário;
Identidades gerenciadas;
Service principals.
O funcionamento dos 3 tipos é muito parecido, seu propósito é o mesmo porém as características são muito diferentes.
Nas próximas seções, vamos entender seus usos, suas características e como criá-las.
Usuários
Os usuários somos nós. Eu, você, nossos amigos e colegas que usam a plataforma. As identidades de usuário são utilizadas para representar uma pessoa no Entra ID. Esse usuário tem um nome, endereço de e-mail e também uma senha. Ele representa um funcionário, um terceiro, colaborador, ou qualquer outro usuário que vá acessar um recurso da plataforma.
Antes da criação as Service Principals era comum encontrarmos nos ambientes identidades de usuário que eram utilizadas por aplicações para controlar o acesso aos recursos. Com a criação das SPs, hoje temos uma alternativa mais simples e que faz mais sentido para esse caso de uso.
Um usuário não tem a característica dos outros tipos de identidade, ele deve representar apenas uma pessoa. Para representarmos aplicações e outros objetos, temos possibilidades distintas e que se assemelhem mais aos respectivos casos de uso.
Um usuário tem propriedades como: endereço, data de nascimento, cargo, informações pessoais (como número de telefone), entre outras informações, então para distinguirmos um user dentro de todos os outros objetos de identidade existentes na plataforma, podemos nos atentar à algumas informações como essas.
Managed Identity
As Managed Identities (ou Identidades Gerenciadas) são um tipo específico de identidade do Azure que nos permite autorizar o consumo de recursos da plataforma a partir de outros recursos. Ficou confuso? Vamos ao exemplo:
Na arquitetura apresentada acima nós temos uma Azure Functions recebendo requisições HTTP/HTTPS e inserindo os eventos dentro de um tópico do Azure Service Bus. Temos também uma outra Azure Functions consumindo os eventos inseridos no tópico pelo Function App A e inserindo algumas informações dentro de um Azure CosmosDB.
Como bem sabemos, é uma péssima prática de segurança deixar nossos serviços expostos abertamente para consumo, é necessário que tenhamos um processo de autorização para utilização dos mesmos. As Managed Identities nos permitem fazer uso do RBAC (Role-Based Access Control) para controlar o acesso aos recursos!
Uma vez que criamos um recurso e atribuímos a ele uma Managed Identity (isso pode ser feito em alguns recursos durante a criação e também após) nós poderemos navegar até os recursos de destino e atribuir à identidade uma role que nos permita operar aquele recurso. As imagens a seguir mostram como isso é feito.
Dentro da aba de IAM do recurso, nós:
Dessa forma nós temos um recurso que consome outro da maneira correta, sendo autorizado e seguindo as melhores práticas seguidas pelas empresas.
Um outro ponto importante para mencionarmos quando falamos sobre as Managed Identities são os dois tipos existentes.
System-Assigned x User-Assigned
O conceito das Managed Identities se mantém para qualquer um dos dois tipos, o que muda neles é o seu ciclo de vida.
As System-Assigned Managed Identities são criadas diretamente no recurso (no momento de criação dele ou após criado) e estarão atreladas a esse recurso por todo seu ciclo de vida. Isso implica em:
Enquanto o recurso existir, a identidade existirá com ele, caso ele seja excluído, a identidade será excluída junto.
As identidades System-Assigned podem ser utilizadas em apenas um recurso, não podendo ser reaproveitadas em qualquer outro recurso do mesmo tipo. Elas são dedicadas apenas ao recurso em que foram criadas e como mencionei anteriormente, serão afetadas quando o recurso tiver seu ciclo de vida encerrado.
Agora, as User-Assigned Managed Identities acabam por outro lado podendo ser utilizadas em mais de um recurso e não acompanharão todo o ciclo de vida do recurso.
Elas são criadas como recursos separados, podendo ser visualizadas dentro do Portal do Azure na página de Managed Identities ou pelo Cloud Shell utilizando o comando:
az identity list
O comando acima listará todas as identidades gerenciadas que você tem criadas na plataforma.
Para aplicações, as Managed Identities são as mais seguras e quando seu uso é possível, são as mais recomendadas, pela facilidade no gerenciamento e também pela ausência de um segredo. As System-Assigned Managed Identities fornece o maior conforto para os administradores pois o objeto será gerido completamente no seu recurso “pai”. As User-Assigned Managed Identities ainda que não façam o uso de segredos, perdem para as System-Assigned devido ao seu ciclo de vida ser gerenciado fora dos recursos, de maneira independente.
Service Principal
Chegando para nosso último tipo de identidade, temos as Service Principals.
O conceito das Service Principals é tão simples quanto os outros modelos, no final das contas ela é uma identidade utilizada para recursos não humanos, ou seja, quase tudo que não seja usuário, mas diferente das Managed Identities, elas são criadas e gerenciadas em um local e de uma maneira diferente.
As Service Principals são um objeto do Azure AD (Entra ID). Elas não tem um painel específico para elas onde podemos criar e gerenciar as mesmas dentro do Azure. Elas podem ser criadas através do Portal do Azure, Azure CLI, Powershell, Graph API, entre outras ferramentas.
Elas serão utilizadas para que aplicações possam se autenticar e ter o consumo dos recursos autorizado. Para realizar a autorização do consumo, poderemos utilizar as roles dos recursos para atribuir à Service Principal as permissões necessárias para realizar as operações desejadas.
Uma diferença importante das Service Principals para os outros modelos é a forma de autenticação. As Managed Identities não necessitam a gestão dos segredos da identidade, não é nem possível visualizar essa informação pois ela é gerida completamente pela plataforma. Já nas SPs nós precisamos nos preocupar com essa questão, pois para utilizar das roles atribuídas será necessário no nível do código inserir as informações da Service Principal para uso do SDK do recurso. Essas informações são:
Object ID — identificador único utilizado para identificar o objeto dentro do tenant;
Secret (opcional) — chave secreta utilizada como “senha” para autenticação das aplicações no consumo de recursos.
O secret está marcado como opcional pois também é possível autenticar uma Service Principal através de certificado, mas essa questão não é o escopo do nosso artigo.
A criação de uma Service Principal pode ser realizada através do Portal do Azure na seção do Azure AD em “App Registration” ou pode ser feita através do seguinte comando no Cloud Shell:
az ad sp create-for-rbac --skip-assignment
O comando acima cria uma Service Principal e retorna no próprio output do Cloud Shell as informações do objeto criado. Com a propriedade “ — skip-assignment” não é necessário atribuir uma role à identidade no momento de criação.
Dentro dos tipos de identidade de aplicação que apresentamos, essa é a que gera mais riscos de segurança ao seu ambiente, por conta da necessidade de gerenciamento do segredo (quando utilizado) e por conta da necessidade do gerenciamento do ciclo de vida. Como as SPs não contém nenhum tipo de vínculo com o recurso que a utilizará, é necessário uma boa gestão desse objeto visando evitar que suas credenciais caiam em mãos erradas!
Quando falamos sobre estratégia Zero Trust é importante pensarmos nos temas relacionados à identidade. Para garantir o Privilégio Mínimo é necessário gerenciar corretamente as identidades e as permissões atribuídas a elas.
Espero que tenha gostado do texto e que eu tenha conseguido te explicar as diferenças entre os modelos, seus usos, benefícios e também possíveis riscos à segurança do seu ambiente.
Estou à disposição para responder quaisquer perguntas que você tiver.
Até logo!