# Tipos de identidades no Azure 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: ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1698628548832/f965c330-53c3-4e60-bb4f-b04d39862d53.png align="center") 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: ![Selecionamos qual role desejamos que seja atribuída](https://cdn.hashnode.com/res/hashnode/image/upload/v1698628550968/26740404-ba91-4827-a26e-b5a477be5c2d.png align="center") ![Nessa etapa selecionamos qual a identidade receberá a role](https://cdn.hashnode.com/res/hashnode/image/upload/v1698628553371/e5a89d8f-1f98-4ce0-adb2-680696f334da.png align="left") 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***. ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1698628555485/c3a8076d-8c8a-48d0-ae73-a16e081464a6.png align="center") 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!