O que são as identidades gerenciadas no Azure SQL Server [Papo de Arquiteto Cloud]

 

• Área de tecnologia principal: Identity & Access
• Áreas de tecnologia adicional: Security | Cloud Security (Microsoft Defender for Cloud, Azure Network Security)

Este é um post mais avançado, direcionado aos arquitetos de TI que constroem ambientes seguros ou que ajustam a segurança de ambientes já operacionais. Hoje vamos falar de identidades gerenciadas dentro do Microsoft Azure. 

A Identidade Gerenciada (Managed Identity) é um recurso do Azure que permite que aplicações e serviços se autentiquem em outros serviços da própria plataforma de forma segura, sem a necessidade de senhas, chaves ou segredos armazenados em código.

Em termos simples, é como se o Azure dissesse:

“Esse serviço é quem ele diz ser, eu confio nele — e vou cuidar da identidade e da autenticação para você.”

O problema que a identidade gerenciada resolve

Tradicionalmente, aplicações precisam de:

• Usuário e senha
• Chaves de API
• Client Secret de aplicações
• Tokens armazenados em variáveis de ambiente ou cofre externo

Esse modelo traz riscos conhecidos:

• Vazamento de credenciais
• Segredos expostos em código ou pipelines
• Rotação manual de chaves
• Maior complexidade operacional e de auditoria

A identidade gerenciada surge exatamente para eliminar esses riscos.

Existem dois tipos:

Identidade Gerenciada atribuída pelo Sistema

• Criada automaticamente quando habilitada em um recurso (App Service, VM, Function, SQL Server etc.)
• Está vinculada exclusivamente àquele recurso
• É removida automaticamente se o recurso for deletado

Identidade Gerenciada atribuída pelo Usuário

• Criada como um recurso independente
• Pode ser reutilizada por múltiplos serviços
• Oferece mais controle e flexibilidade em arquiteturas maiores

Como funciona o fluxo de autenticação

1. O serviço (ex.: App Service, Power BI Embedded, Function App) solicita acesso a outro recurso
2. O Azure valida a identidade gerenciada no Entra ID
3. Um token de acesso é emitido dinamicamente
4. O serviço de destino (SQL, Storage, Key Vault, etc.) valida o token
5. O acesso é concedido com base nas permissões configuradas

Nenhuma senha ou chave é exposta à aplicação

Exemplo prático: Power BI Embedded com Azure SQL Database

Imagine um cenário em que uma aplicação corporativa utiliza o Power BI Embedded para exibir relatórios analíticos dentro de um sistema próprio. Nesse contexto, os dados consumidos pelos relatórios estão armazenados em um Azure SQL Database, e a aplicação precisa acessar essas informações de forma contínua e segura. Por exigências de compliance e boas práticas de segurança, não é permitido o uso de usuário e senha fixos diretamente no código da aplicação, o que elimina abordagens tradicionais de autenticação.

A figura abaixo ilustra uma infraestrutura direcionada para o Power BI Embedded que utiliza bancos de dados SQL Server no Microsoft Azure. Logo mais farei um post sobre a construção deste ambiente.

Para atender a esse requisito, a solução mais adequada é o uso de Identidade Gerenciada. Nesse modelo, o recurso que hospeda o Power BI Embedded — ou a aplicação responsável por consumi-lo — possui uma identidade própria atribuída pelo Azure. Essa identidade é criada automaticamente e registrada no Microsoft Entra ID, funcionando como uma identidade confiável, sem necessidade de credenciais explícitas.

No Azure SQL Database, essa identidade gerenciada é reconhecida como uma entidade válida. A partir disso, é criado um usuário no banco de dados diretamente associado a essa identidade, sem a existência de senha ou de um login SQL tradicional. As permissões concedidas a esse usuário são restritas e controladas, normalmente limitadas apenas à leitura dos dados necessários para os relatórios.

Como resultado, o Power BI Embedded consegue acessar o banco de dados sem o uso de credenciais fixas, eliminando riscos de vazamento de senhas. Além disso, todo o acesso passa a ser rastreável e auditável, já que está vinculado a uma identidade do Entra ID. Caso seja necessário interromper o acesso por qualquer motivo, basta revogar ou ajustar as permissões dessa identidade, e o bloqueio ocorre de forma imediata e centralizada.

Para criar uma identidade gerenciável, você pode acessar diretamente o objeto em segurança. Ali você encontra as configurações de identidade. Pode seguir os seguintes passos:

Passo 1 — Acesse o recurso no Azure Portal

1. Entre no Azure Portal
2. Abra o recurso que irá usar a identidade
   (ex.: App Service, VM, Function App, SQL Server lógico)

Passo 2 — Habilite a Identidade Gerenciada

1. No menu lateral do recurso, clique em Identidade
2. Na aba Identidade atribuída pelo sistema, selecione Ativado
3. Clique em Salvar
4. Confirme a criação quando solicitado

Nesse momento:

• Uma identidade é criada automaticamente no Microsoft Entra ID
• O Azure passa a gerenciar a identidade (sem senhas, sem segredos)

Passo 3 — Validar no Microsoft Entra ID (opcional)

1. Vá em Microsoft Entra ID
2. Acesse Identidades Gerenciadas
3. Localize a identidade criada (normalmente com o nome do recurso)

Passo 4 — Conceder permissões ao recurso de destino

Agora você autoriza essa identidade a acessar outro serviço.

Exemplo A — Azure SQL Database

1. Conecte-se ao banco usando um usuário administrador
2. Crie o usuário baseado na identidade:

CREATE USER [Nome-da-Identidade] FROM EXTERNAL PROVIDER;

ALTER ROLE db_datareader ADD MEMBER [Nome-da-Identidade];

       3. O acesso passa a ser apenas leitura.

Outro exemplo comum: acesso ao Azure Key Vault

Um segundo cenário bastante comum envolve aplicações que precisam acessar informações sensíveis, como strings de conexão, certificados digitais ou outros segredos. Tradicionalmente, esses dados eram armazenados em arquivos de configuração ou variáveis de ambiente, o que representa um risco significativo de segurança.

Com o uso de identidade gerenciada, essa abordagem muda completamente. A aplicação passa a se autenticar diretamente no Azure Key Vault utilizando sua própria identidade no Entra ID. O Key Vault, por sua vez, confia nessa identidade e permite o acesso apenas aos segredos explicitamente autorizados para aquele serviço.

Dessa forma, não há segredos armazenados no código ou em arquivos de configuração. A aplicação solicita os dados diretamente ao Key Vault, de maneira autenticada e segura, sempre respeitando as permissões definidas. Isso reduz drasticamente a superfície de ataque, simplifica a gestão de credenciais e fortalece a postura de segurança da solução como um todo.

Exemplo B — Azure Key Vault

1. Acesse o Key Vault
2. Vá em Controle de acesso (IAM) ou Políticas de acesso
3. Adicione a identidade gerenciada
4. Conceda permissões como:
• Get Secrets
• Get Certificates (se necessário)