Software · Segurança & Identidade

Gestão de Segredos na Nuvem: Azure Key Vault, Managed Identities e Rotação

Como eliminar senhas em texto puro de repositórios e configurações: a separação entre segredos, chaves e certificados no Azure Key Vault, integração com Managed Identities e rotação automatizada sem indisponibilidade.

Diagrama de segurança em nuvem mostrando o fluxo de autenticação sem senha com Managed Identity acessando segredos e chaves no Azure Key Vault
Neste artigo

O vazamento acidental de chaves de API e strings de conexão em repositórios de código é uma das causas mais frequentes de incidentes de segurança corporativos. Mesmo quando equipes instruem desenvolvedores a isolar credenciais em arquivos locais .env ou variáveis de ambiente de containers, essas credenciais continuam existindo de forma estática, raramente sofrem rotação periódica e permanecem vulneráveis a extrações em dumps de memória ou logs de execução.

Em arquiteturas em nuvem modernas, a resposta madura para esse problema baseia-se em dois pilares complementares: a centralização criptográfica em um cofre gerenciado como o Azure Key Vault e a eliminação completa de credenciais estáticas por meio de Managed Identities (Identidades Gerenciadas).

flowchart LR
    subgraph Compute["Ambiente de Execução (App Service / VM / AKS)"]
        App["Aplicação .NET / Node"]
        MSI["Managed Identity (Entra ID)"]
        App -->|Token OAuth sem senha| MSI
    end

    subgraph Vault["Azure Key Vault"]
        KV_Secrets["Segredos (API Keys, Strings)"]
        KV_Keys["Chaves Criptográficas (RSA / HSM)"]
        KV_Certs["Certificados Digitais (TLS / X.509)"]
    end

    subgraph Target["Recursos de Destino"]
        SQL["Azure SQL Database"]
        Storage["Blob Storage"]
    end

    MSI -->|Acesso autenticado via RBAC| Vault
    App -->|Conexão direta sem senha| SQL
    App -->|Token de acesso| Storage

A Tríade de Objetos do Key Vault

O Azure Key Vault não é apenas um repositório genérico de variáveis de ambiente. Ele isola as permissões de acesso em três tipos fundamentais de ativos criptográficos:

Tipo de Objeto Função Principal Exemplo de Aplicação Nível de Proteção
Secrets (Segredos) Armazenamento seguro de cadeias de caracteres em texto puro Tokens de terceiros, chaves privadas transitórias Protegido por criptografia em repouso AES-256
Keys (Chaves) Chaves assimétricas e simétricas manipuladas dentro do cofre Assinatura de payloads, criptografia de envelopes Operações criptográficas acontecem no HSM (FIPS 140)
Certificates (Certificados) Gerenciamento de ciclo de vida de certificados X.509 Terminação TLS e autenticação mútua (mTLS) Rotação automática integrada a autoridades certificadoras

Em operações de alta segurança, as Chaves (Keys) oferecem a vantagem de nunca deixarem o cofre: a aplicação envia os dados a serem criptografados ou assinados para a API do Key Vault, e o cofre realiza o processamento matemático internamente em módulos de segurança de hardware (HSM), devolvendo apenas o resultado.

Eliminando Senhas com Managed Identities

Uma Identidade Gerenciada atribui uma identidade oficial no Microsoft Entra ID ao recurso computacional (uma Máquina Virtual, um App Service ou um cluster Kubernetes AKS). A plataforma Azure gerencia automaticamente as credenciais e o ciclo de vida dos tokens em segundo plano, liberando o código consumidor de manipular qualquer segredo estático:

  • System-Assigned Identity: Vinculada estritamente ao ciclo de vida daquele recurso específico. Se o App Service for deletado, a identidade no Entra ID é excluída automaticamente.
  • User-Assigned Identity: Criada como um recurso independente da nuvem, podendo ser compartilhada entre múltiplos nós de uma mesma frota de processamento.

Consumindo o Key Vault sem Senhas no C#

Com o pacote oficial Azure.Identity, o cliente DefaultAzureCredential resolve a autenticação de forma inteligente: no ambiente de desenvolvimento local, ele reutiliza as credenciais da IDE ou da CLI do desenvolvedor logado; em produção, conecta-se diretamente à Managed Identity da infraestrutura:

using Azure.Identity;
using Azure.Security.KeyVault.Secrets;

var vaultUri = new Uri("https://kv-dxs-producao.vault.azure.net/");

// Autenticação sem senha: zero credenciais gravadas no código
var client = new SecretClient(vaultUri, new DefaultAzureCredential());

// Leitura pontual do segredo protegido
KeyVaultSecret secret = await client.GetSecretAsync("StripeApiKey");
string apiKey = secret.Value;

Referências Diretas no App Service (Key Vault References)

Quando a aplicação não pode ser modificada para incluir SDKs específicos de nuvem, o Azure App Service e o Azure Functions oferecem o recurso de Key Vault References. O runtime da nuvem resolve o segredo durante a inicialização e o injeta como uma variável de ambiente tradicional:

# Configuração de Aplicação no Azure Portal / Bicep
STRIPE_API_KEY = @Microsoft.KeyVault(SecretUri=https://kv-dxs-producao.vault.azure.net/secrets/StripeApiKey/)

O serviço busca o segredo periodicamente em segundo plano, atualizando o valor em memória quando uma nova versão é publicada sem exigir redeploy da aplicação.

Automação de Rotação com Event Grid e Serverless

Segredos devem expirar. A prática de manter a mesma senha de banco de dados ativa por anos contraria todos os preceitos de conformidade e auditoria. O Key Vault emite eventos nativos no Azure Event Grid quando um segredo atinge sua data de expiração iminente:

sequenceDiagram
    participant KV as Azure Key Vault
    participant EG as Azure Event Grid
    participant Fn as Azure Function de Rotação
    participant DB as Banco de Dados

    KV->>EG: Evento: SecretNearExpiry (30 dias antes)
    EG->>Fn: Dispara gatilho HTTP do evento
    Fn->>DB: Gera nova credencial secundária
    Fn->>KV: Salva nova versão do segredo
    Fn->>DB: Após validação, revoga credencial antiga

Esse padrão de dupla credencial garante rotação contínua com zero indisponibilidade: a aplicação passa a utilizar a nova credencial enquanto a anterior ainda possui um período de tolerância antes de ser revogada.

Proteção Contra Exclusão Acidental: Soft-Delete e Purge Protection

Em ambientes corporativos, dois controles devem permanecer obrigatoriamente habilitados no cofre:

  1. Soft-Delete: Quando um segredo ou o próprio cofre é excluído acidentalmente, ele entra em um estado de retenção (por padrão, 90 dias), permitindo recuperação imediata sem perda catastrófica de dados.
  2. Purge Protection: Impede que qualquer usuário (mesmo administradores com privilégio total de assinatura) force a destruição permanente do cofre durante o período de retenção, frustrando ações de atacantes ou rotinas desastradas de limpeza de infraestrutura.
Explorar este tema no Grafo de Conhecimento