Identidade gerenciada para autenticação sem senha

Tradicionalmente, os aplicativos conectam-se a serviços do Azure, como Storage ou Key Vault, usando cadeias de conexão ou chaves de API armazenadas em arquivos de configuração ou variáveis de ambiente. Essas credenciais podem ser incluídas acidentalmente no controle de versão, expostas em registros ou roubadas em uma violação de segurança. A Identidade Gerenciada elimina completamente a necessidade de os aplicativos armazenarem credenciais — em vez disso, o próprio Azure emite e alterna um token em nome do recurso, e o aplicativo simplesmente solicita ao Azure o token atual durante a execução.

Uma Identidade Gerenciada é uma entidade de serviço gerenciada automaticamente no Microsoft Entra ID, vinculada a um recurso do Azure, como uma VM, um App Service ou um Function App. A plataforma Azure cria e mantém as credenciais da identidade, alternando-as regularmente, para que seu código nunca manipule uma senha ou um segredo. Os aplicativos executados no recurso chamam o ponto de extremidade do Azure Instance Metadata Service (IMDS) em http://169.254.169.254 para obter um token OAuth de curta duração, que depois apresentam aos serviços do Azure.

Há dois tipos de identidade gerenciada: a atribuída pelo sistema está vinculada a um único recurso do Azure; ela é criada quando habilitada no recurso e excluída automaticamente quando o recurso é excluído. A atribuída pelo usuário é uma identidade independente do Entra ID que você cria separadamente e depois anexa a um ou mais recursos do Azure. As identidades atribuídas pelo usuário são úteis quando vários serviços, como diversos Function Apps, precisam compartilhar a mesma identidade e as mesmas permissões de RBAC, evitando a duplicação de atribuições de funções.

Depois de habilitar uma identidade gerenciada, você deve conceder a ela permissões de RBAC no recurso do Azure de destino. Por exemplo, para permitir que um App Service leia blobs, atribua a função Storage Blob Data Reader à identidade gerenciada do App Service na conta de armazenamento. As atribuições de RBAC seguem o princípio do menor privilégio — conceda apenas as permissões mínimas necessárias. Nunca atribua Owner ou Contributor a uma identidade gerenciada, a menos que isso seja absolutamente necessário.

O SDK do Azure fornece uma classe DefaultAzureCredential que tenta automaticamente vários métodos de autenticação em ordem: variáveis de ambiente, identidade de carga de trabalho, identidade gerenciada, Azure CLI, Visual Studio e outros. Quando o aplicativo é executado no Azure (App Service, VM, Function App), DefaultAzureCredential usa automaticamente a identidade gerenciada sem nenhuma alteração no código. Localmente, os desenvolvedores autenticam-se por meio da sessão da CLI do Azure. Essa única classe de credencial funciona em todos os ambientes sem lógica condicional.

Um padrão comum é usar uma identidade gerenciada para acessar segredos do Azure Key Vault durante a execução. Em vez de armazenar uma senha de banco de dados nas configurações do aplicativo, armazene-a no Key Vault e atribua à identidade gerenciada do aplicativo a função Key Vault Secrets User nesse cofre. Na inicialização, o aplicativo busca o segredo no Key Vault usando DefaultAzureCredential. Esse padrão garante que os segredos nunca sejam armazenados no código, nos arquivos de configuração ou nas variáveis de ambiente — eles existem somente no Key Vault e são buscados de forma efêmera.

O Azure SQL Database é compatível com a autenticação do Entra ID, o que significa que uma identidade gerenciada pode autenticar-se no SQL sem nome de usuário e senha. Para habilitar esse recurso: defina um administrador do Entra ID no servidor SQL, execute uma instrução CREATE USER no banco de dados de destino para o nome de exibição da identidade gerenciada e conceda a ela a função de banco de dados apropriada. O aplicativo conecta-se usando o DefaultAzureCredential do SDK do Azure e um token de acesso com escopo https://database.windows.net/, totalmente sem senha.

No Serviço de Kubernetes do Azure, pods individuais podem obter tokens de identidade gerenciada usando a Identidade de Carga de Trabalho, sucessora do AAD Pod Identity. Você cria uma identidade gerenciada atribuída pelo usuário, estabelece uma federação com o emissor OIDC do AKS, anota a conta de serviço do Kubernetes e o webhook do Azure Workload Identity injeta as variáveis de ambiente necessárias para que o DefaultAzureCredential do pod obtenha um token. Isso estende a autenticação sem senha a microsserviços conteinerizados sem armazenar segredos em objetos Secrets do Kubernetes.

Embora as credenciais de identidade gerenciada sejam invisíveis para os desenvolvedores, todos os eventos de emissão de tokens e de acesso a recursos são registrados. Os registros de entrada do Entra ID registram cada solicitação de token feita por uma identidade gerenciada, incluindo o recurso acessado, o horário e se a solicitação foi bem-sucedida. Os registros de atividades do Azure Storage e os registros de auditoria do Key Vault registram as operações específicas realizadas usando o token. Esses registros são essenciais para auditorias de segurança e investigações de incidentes envolvendo identidades gerenciadas.

Se o seu aplicativo usa atualmente cadeias de conexão ou chaves de API, migre para uma identidade gerenciada em três etapas: Etapa 1 — Habilite uma identidade gerenciada no recurso de computação. Etapa 2 — Atribua funções de RBAC apropriadas à identidade em cada serviço de destino. Etapa 3 — Atualize o código do aplicativo para usar DefaultAzureCredential em vez da cadeia de conexão. Remova a cadeia de conexão da configuração do App Service e do Key Vault assim que a migração for verificada. Essa migração normalmente pode ser concluída com poucas alterações de código em aplicativos modernos que usam o SDK do Azure.

A Identidade Gerenciada oferece quatro benefícios essenciais de segurança em comparação com a autenticação baseada em credenciais: Nenhum armazenamento de credenciais — nada para roubar ou incluir acidentalmente. Rotação automática — o Azure alterna os certificados subjacentes sem indisponibilidade. Permissões com escopo — as identidades recebem apenas as funções de RBAC necessárias, seguindo o princípio do menor privilégio. Trilha de auditoria completa — todas as tentativas de acesso são registradas no Entra ID e nos registros de auditoria do serviço acessado. Para qualquer nova integração de serviço do Azure, a identidade gerenciada deve ser a abordagem de autenticação padrão.

Nesta lição, você aprendeu que: a identidade gerenciada elimina credenciais armazenadas ao fornecer aos recursos do Azure uma identidade do Entra ID gerenciada automaticamente; DefaultAzureCredential no Azure SDK usa de forma transparente a identidade gerenciada no Azure e as credenciais do desenvolvedor localmente; e as atribuições de funções do RBAC nos serviços de destino controlam o que a identidade pode acessar. A seguir, exploraremos o Azure Service Bus para a troca de mensagens desacoplada entre componentes de aplicativos.