Como as identidades gerenciadas eliminam senhas codificadas no Azure

By Mirko Peters · 2026-08-13

Bem-vindo de volta ao blog complementar do nosso podcast! Se você desenvolve aplicações há algum tempo, provavelmente já se deparou com o velho problema o…

Automatically translated with AI from the original post. Read the English original

Bem-vindo de volta ao blog complementar do nosso podcast! Se você desenvolve aplicações há algum tempo, provavelmente já enfrentou o velho problema de como conectar seu código a um banco de dados, a uma API ou a uma conta de armazenamento na nuvem. Historicamente, os desenvolvedores resolviam isso colocando uma cadeia de conexão, uma senha de banco de dados ou um segredo do cliente diretamente em um arquivo de configuração, em uma variável de ambiente ou, pior ainda, escrevendo-o diretamente no código-fonte do repositório. Enquanto a aplicação conseguisse ler esse segredo, ela podia se autenticar e fazer seu trabalho. Mas o que acontece quando esse código é enviado por engano para um repositório público no GitHub? O que acontece quando um funcionário insatisfeito sai da empresa ou um invasor obtém acesso de leitura às configurações da sua aplicação? Sua infraestrutura inteira fica comprometida instantaneamente. Na arquitetura de nuvem moderna, esse risco é inaceitável. Hoje, vamos aprofundar como as identidades gerenciadas no Microsoft Azure eliminam por completo a necessidade de senhas fixas no código, substituindo segredos estáticos por tokens de acesso dinâmicos e de curta duração.

Introdução à segurança em nuvem e segredos codificados

O modelo tradicional de segurança baseado em perímetro confiava fortemente na ideia de que, uma vez dentro da rede corporativa, você podia ser considerado confiável. Dentro desse perímetro, as aplicações se comunicavam usando contas de serviço estáticas, senhas codificadas e tokens de longa duração que raramente, ou nunca, expiravam. Se um invasor conseguisse violar o perímetro, teria acesso a um verdadeiro tesouro de credenciais estáticas que podiam ser reutilizadas indefinidamente.

A computação em nuvem derrubou completamente esse perímetro. Nossas cargas de trabalho agora abrangem ambientes multinuvem, datacenters locais, plataformas SaaS e funções serverless distribuídas. Nesse novo cenário, a segurança precisa acompanhar a identidade da própria carga de trabalho. Segredos codificados são bombas-relógio. Eles não são rotacionados automaticamente, são notoriamente difíceis de auditar e não deixam margem alguma para erro se forem expostos. Para alcançar uma verdadeira segurança Zero Trust, precisamos desvincular completamente as credenciais do nosso código-fonte. Precisamos de um mecanismo de autenticação em que as aplicações possam provar quem são sem nunca precisar conhecer ou armazenar uma senha.

Entendendo identidades de usuário vs. identidades de carga de trabalho no Entra ID

Para entender como a segurança em nuvem evoluiu, primeiro precisamos observar como o Microsoft Entra ID gerencia as entidades que acessam nossos sistemas. De modo geral, o Microsoft Entra ID classifica as identidades em dois grandes grupos: identidades de usuário e identidades de carga de trabalho.

Identidades de usuário representam seres humanos — funcionários, parceiros, prestadores de serviço e clientes. Pessoas interagem com os sistemas de forma dinâmica e se autenticam por meio de métodos pensados para humanos, como senhas, Windows Hello for Business, chaves de segurança FIDO2 e autenticação multifator. Pessoas esquecem senhas, caem em ataques de phishing e precisam de redefinições de senha feitas por administradores.

Já as identidades de carga de trabalho representam software. Isso inclui aplicações, serviços em segundo plano, scripts de automação, Azure Functions, Logic Apps, pipelines de implantação do DevOps e agentes de IA. Cargas de trabalho não tomam café, não clicam em e-mails de phishing e não conseguem concluir um prompt interativo de autenticação multifator em um smartphone. Elas precisam se autenticar de forma não interativa, programática e contínua. Tratar uma identidade de carga de trabalho como uma identidade de usuário, atribuindo a ela uma senha estática, é um dos erros mais comuns na arquitetura de nuvem. Identidades de carga de trabalho exigem modelos de governança próprios, gerenciamento de ciclo de vida específico e fluxos de autenticação automatizados.

Desmistificando registros de aplicativo, entidades de serviço e identidades gerenciadas

Se você já passou algum tempo configurando aplicações no Microsoft Entra ID, certamente esbarrou em três termos que costumam causar confusão: registros de aplicativo, entidades de serviço e identidades gerenciadas. Vamos detalhá-los de forma simples.

Um Registro de aplicativo é a definição global, ou o modelo, da sua aplicação. Ao registrar um aplicativo no Microsoft Entra ID, você está criando a identidade global dele em todo o ecossistema multilocatário. É aqui que você define quais permissões o aplicativo pode precisar, quais endpoints de autenticação ele usa e quais URIs estão associados a ele. Pense no Registro de aplicativo como o modelo do passaporte.

Uma Entidade de serviço é a instância local desse aplicativo dentro de um locatário específico. Se um aplicativo é multilocatário, ele terá um Registro de aplicativo no locatário do editor, mas uma Entidade de serviço separada em cada locatário de cliente onde for implantado e consentido. É na Entidade de serviço que os administradores realmente atribuem permissões, aplicam políticas de Acesso Condicional e controlam quem pode acessar o aplicativo localmente. Pense na Entidade de serviço como o passaporte carimbado, usado para entrar em um país específico.

Uma Identidade gerenciada leva esse conceito um passo adiante, especificamente para recursos executados no Microsoft Azure. Em vez de um desenvolvedor precisar criar manualmente um Registro de aplicativo, gerar um segredo de cliente, armazenar esse segredo em uma variável de ambiente e escrever código para lidar com o ciclo de vida da autenticação, o Azure cuida de todo o processo nos bastidores. O Azure cria, gerencia e rotaciona automaticamente as credenciais subjacentes para você. O desenvolvedor simplesmente instrui o recurso do Azure a usar a sua Identidade gerenciada, e o Azure cuida do resto.

Como as Identidades gerenciadas eliminam senhas e credenciais fixas no código

A mágica das Identidades gerenciadas está na forma como elas mudam fundamentalmente a transação de autenticação. Quando você usa uma Identidade gerenciada para um recurso do Azure, como um Azure App Service, uma máquina virtual ou uma Azure Function, não há literalmente nenhuma senha, segredo ou certificado armazenado no seu código ou nas configurações.

Quando sua aplicação precisa acessar um recurso protegido, como um banco de dados ou uma API, ela não busca uma senha armazenada. Em vez disso, a aplicação faz uma chamada local para o endpoint do Azure Instance Metadata Service (IMDS), que fica disponível com segurança apenas dentro desse recurso específico do Azure. A plataforma subjacente do recurso do Azure solicita diretamente ao Microsoft Entra ID, em nome da aplicação, um JSON Web Token (JWT) de curta duração.

O Microsoft Entra ID verifica a identidade do recurso do Azure, emite um token de acesso criptograficamente assinado com uma validade muito curta (normalmente cerca de uma hora) e o devolve à aplicação. Em seguida, a aplicação usa esse token para se autenticar no serviço de destino. Como o token expira rapidamente, mesmo que um invasor consiga interceptá-lo, a janela de vulnerabilidade é extremamente estreita. Além disso, como não há nenhuma senha estática escrita no código, não há nada que um desenvolvedor possa vazar acidentalmente em um repositório público.

Integrando o Azure Key Vault e tokens de acesso de curta duração

Embora as Identidades gerenciadas eliminem a necessidade de senhas de aplicação, você pode se perguntar como as aplicações lidam com segredos que são de fato externos, como chaves de API de serviços de terceiros que não oferecem suporte à autenticação do Microsoft Entra. É aqui que entra o Azure Key Vault, trabalhando em conjunto com as Identidades gerenciadas.

Em vez de deixar uma chave de API de terceiros fixa no código-fonte, você armazena esse segredo de forma segura dentro do Azure Key Vault. Depois, concede à Identidade gerenciada do seu recurso do Azure permissão para ler segredos desse Key Vault, usando o Azure RBAC (Controle de Acesso Baseado em Função) ou as políticas de acesso do Key Vault.

Quando sua aplicação é iniciada, ela usa sua Identidade gerenciada para se autenticar no Azure Key Vault, obtém dinamicamente na memória a chave de API de terceiros necessária e a utiliza. Em nenhum momento as credenciais são expostas no código-fonte. A aplicação usa um mecanismo seguro e baseado em identidade para buscar o segredo, em vez de depender de uma string estática incorporada em um arquivo de configuração.

Protegendo identidades de carga de trabalho com privilégio mínimo e governança

Eliminar senhas fixas no código é um grande ganho para a segurança, mas implantar Identidades gerenciadas não é um modelo operacional do tipo "configure e esqueça". As identidades de carga de trabalho exigem uma governança robusta, assim como as contas de usuários humanos.

Antes de tudo, é preciso seguir rigorosamente o princípio do privilégio mínimo. Não atribua funções de colaborador amplas nem permissões excessivas do Microsoft Graph a uma identidade de carga de trabalho só para fazer as coisas funcionarem rapidamente. Se um script de automação em segundo plano só precisa ler itens de um contêiner específico do Azure Storage, conceda a ele acesso de Leitor de Dados de Blob do Storage somente a esse contêiner exato, nada além disso. Se essa identidade de carga de trabalho for comprometida, o raio de impacto será mínimo.

Em segundo lugar, você precisa monitorar e auditar suas identidades de carga de trabalho continuamente. As organizações frequentemente criam entidades de serviço e identidades gerenciadas para projetos de prova de conceito, scripts de automação e integrações temporárias, e depois as deixam em execução indefinidamente com privilégios elevados. Implemente revisões de segurança regulares para identificar entidades de serviço órfãs, contas de automação não utilizadas e credenciais obsoletas. Aproveitar recursos como o Microsoft Entra ID Protection e configurar um registro robusto com o Azure Monitor garante visibilidade completa de quando e como suas identidades de carga de trabalho acessam o seu ambiente.

Escolhendo a estratégia de identidade certa para cada carga de trabalho na nuvem

Com tantas opções disponíveis no ecossistema de identidade da Microsoft, como você escolhe a estratégia de autenticação certa para a sua carga de trabalho específica? A decisão geralmente depende de onde sua aplicação é executada e de como ela é arquitetada.

Se o seu código for executado dentro do Microsoft Azure, seja no Azure App Services, Azure Functions, Virtual Machines, Container Instances ou Azure Kubernetes Service, sua primeira escolha deve sempre ser uma Identidade Gerenciada. Você pode escolher entre uma Identidade Gerenciada Atribuída pelo Sistema (que tem um ciclo de vida 1:1 diretamente vinculado ao recurso do Azure) ou uma Identidade Gerenciada Atribuída pelo Usuário (que pode ser criada de forma independente e atribuída a vários recursos do Azure, facilitando o gerenciamento).

Se a sua aplicação for executada fora do Azure, como em servidores locais, na AWS ou como parte de um pipeline de CI/CD no GitHub Actions, as Identidades Gerenciadas hospedadas diretamente na infraestrutura do Azure não são uma opção. Nesses cenários, você deve utilizar a Federação de Identidade de Carga de Trabalho. Ela permite que plataformas externas troquem tokens diretamente com o Microsoft Entra ID usando uma confiança OpenID Connect (OIDC), eliminando completamente a necessidade de gerenciar, rotacionar ou armazenar segredos de cliente de longa duração.

Por fim, para aplicações corporativas personalizadas tradicionais que exigem autenticação de cliente em que nem Identidades Gerenciadas nem federação são viáveis, certificados cuidadosamente gerenciados devem sempre ter precedência sobre segredos de cliente de longa duração. Combinando Identidades de Carga de Trabalho do Microsoft Entra, Azure Key Vault, princípios de Zero Trust e acesso com privilégio mínimo, sua organização pode eliminar por completo as senhas embutidas no código e construir uma arquitetura de nuvem notavelmente resiliente.

Conclusão e próximos passos para a segurança na nuvem moderna

Senhas embutidas no código e cadeias de conexão estáticas são relíquias de uma era ultrapassada na segurança de TI. Ao adotar as Identidades de Carga de Trabalho do Microsoft Entra e as Identidades Gerenciadas do Azure, podemos eliminar por completo os riscos associados a credenciais incorporadas, proteger nossos repositórios de código-fonte contra vazamentos acidentais e impor acesso com privilégio mínimo estrito em todas as nossas aplicações nativas da nuvem. Tokens de acesso de curta duração garantem que, mesmo que um token seja interceptado, sua validade seja curta demais para causar danos duradouros, mudando fundamentalmente nossa postura de segurança de uma defesa reativa para uma proteção proativa.

Para se aprofundar ainda mais neste tema e ouvir dicas práticas de implementação de quem está no dia a dia, não deixe de conferir o episódio de podcast relacionado: Entra Workload Identities - Simply Explained. Acompanhe enquanto detalhamos esses conceitos ainda mais, para ajudar você a proteger seus ambientes do Azure e do Microsoft 365 como um verdadeiro profissional!