Imagine esse cenário. Você está criando um aplicativo e precisa de uma chave de API para se conectar a um serviço, uma senha de banco de dados ou uma chave de conta de armazenamento. Então, você insere diretamente no seu código, talvez um arquivo de configuração e uma variável de ambiente. Funciona e tudo corre bem até que você envia esse código para o GitHub ou compartilhe o notebook com um colega de equipe. E, de repente, seu segredo já não é mais tão secreto. Se esse código cair em mãos erradas, todo o seu sistema estará exposto. O Azure Key Vault é a ferramenta que resolve esse problema. Ele oferece um local seguro para armazenar segredos para que eles nunca cabem no seu código. Mas aqui está o que a maioria das pessoas faz errado. Apenas ter um Key Vault não torna você seguro automaticamente. A maneira como você o configura, controla o acesso e atribui permissões é tão importante quanto.

Ao final deste episódio, você saberá o que é o Key Vault, o que pode armazenar nele, como o acesso funciona e o maior erro que poderia deixar seus segredos expostos. Tudo em uma linguagem simples, sem jargões, apenas com a isso é preciso. Então, o que exatamente é o Azure Key Vault? O que é o Azure Key Vault? Aqui está a definição mais simples. O Azure Key Vault é um cofre digital baseado em nuvem para seu segredo. É um serviço gerenciado da Microsoft para chaves de API, senhas de banco de dados, strings de conexão, chaves de criptografia e certificados em um só lugar. Você não precisa se preocupar com a infraestrutura, pois o Azure cuida de patches, tempo de atividade e segurança. Você apenas o utiliza. Pense nele como um prédio comercial. Você tem estações de trabalho, salas de reunião e arquivos, mas em algum lugar no subsolo, existe um cofre seguro onde você guarda as coisas importantes.

Chaves mestras, dinheiro, documentos legais. Ninguém entra sem permissão e autenticação. E toda vez que alguém abre a porta, você registra. Isso é o Key Vault. A sala segura no subsolo da sua arquitetura Azure. Agora, contraste isso com a maneira antiga. Há 20 anos, se você precisasse de uma senha de banco de dados, você a codificava diretamente em um arquivo de configuração, talvez em uma variável de ambiente, ou pior, a deixava em texto simples no código fonte. Se alguém tivesse acesso ao servidor, teria tudo. E se você precisasse rotacionar essa senha, teria que atualizar em todos os lugares. Cada arquivo de configuração, cada ambiente, cada implantação. É um pesadelo. O Key Vault muda tudo isso. Em vez de espalhar segredos pelo código e arquivos de configuração, você os armazena em um único lugar central. Seus aplicativos os solicitam em tempo de execução apenas quando precisam. E como tudo está centralizado, você pode rotacionar um segredo em um só lugar, e cada aplicativo que utiliza recebe um novo valor, automaticamente, sem alterações de código ou reimplantações, sem alterações.

Mas aqui está o ponto. O Key Vault não é apenas um gerenciador de senhas para esse aplicativo. É um serviço central de segurança. Todos os serviços do Azure podem se integrar a ele. Apps, Service, Functions, AKS, Data Factory, Synapse, Logic Apps e Pipelines de DevOps todos sabem como interagir com o Key Vault. Ele se torna a espinha dorsal da sua arquitetura de número em segundo. E uma vez configurado corretamente, você para totalmente de se preocupar com gerenciamentos de credenciais. Você pode armazenar. Então, agora que você sabe o que é o Key Vault, vamos falar sobre o que você pode colocar dentro dele. Existem três categorias principais. Segredos, chaves e certificados. Cada uma faz algo diferente, e entender a diferença ajuda a usar o Key Vault da maneira correta. Vamos começar pelos segredos. Este é o item mais comum que as pessoas armazenam. Segredos são strings de conexão, chaves de API, senhas de banco de dados, chaves de conta de armazenamento, basicamente todas as credenciais cotidianas que seus aplicativos precisam para conversar com outro serviço.

Em vez de colocá-los em seu código ou arquivo de configuração, você os coloca no Key Vault. Seu aplicativo os busca em tempo de execução, e ninguém nunca os vê em texto simples. Pense nisso como uma gaveta trancada no seu arquivo digital. As chaves. Essas são chaves de criptografia POSCO. Se você estiver usando chaves gerenciadas pelo cliente para o Azure Storage, banco de dados SQL ou criptografia de discos de máquinas virtuais, essas chaves podem ficar no Key Vault. Isso lhe dá controle total sobre quem pode usá-las e quando. E se você precisar de chaves protegidas por hardware para conformidade, a camada Premium oferece proteção via HSN. Depois temos certificados. Certificados TLS e SL para seus aplicativos web, APIs e serviços internos. O Key Vault pode armazená-lo, gerenciar seu ciclo de vida e até renová-los automaticamente quando estiver em pré-SSP. Isso é uma salvação para qualquer um que já teve um certificado expirando às 3 da manhã de um domingo.

Este é um exemplo real. Imagine que você tem um aplicativo web que precisa de uma string de conexão de banco de dados e uma chave de API para um serviço terceiro. Do jeito antigo, você colocaria ambos no seu arquivo JSON de configurações do aplicativo. Provavelmente, se esse arquivo for para o seu repositório, qualquer pessoa com acesso ao código poderá ver suas credenciais de banco de dados. Com o Key Vault, você armazena ambos os valores com um segredo. Seu aplicativo os busca na inicialização e eles nunca aparecem no seu código fonte. Se eu rotacionar a senha do banco de dados, atualiza no Key Vault. O aplicativo obtém um novo valor automaticamente na próxima reinicialização. Sem alterações de código, sem replantação. Algo que pega as pessoas de surpresa é que o versionamento é integrado. Quando você atualiza um segredo, o Key Vault não sobrescreve o valor antigo. Ele cria uma nova versão.

As versões antigas são preservadas para que você possa reverter caso algo dê errado. Isso é extremamente útil durante incidentes. Você pode reverter rapidamente para um segredo anterior sem precisar lembrar qual era o valor antigo. Você pode armazenar todos os três tipos segredos, chaves e certificados no mesmo cofre. Mas a melhor prática é separar por ambiente. Tem um cofre para desenvolvimento, um para testes e um para produção. Isso evita que alguém use acidentalmente um segredo de produção em um ambiente de dev e limita o raio de impacto se um cofre for comprometido. Mas armazenar segredos é apenas metade da história. A verdadeira questão é quem pode acessá-los. Como funciona o controle de acesso? Agora vamos falar sobre quem tem missão de novo. E Vault possui duas maneiras diferentes de controlar o acesso ao que está dentro e a que você escolhe importa muito. O primeiro modelo são as políticas de acesso ligadas.

Essa é a maneira antiga. Você cria políticas diretamente no cofre e atribui permissões aos usuários ou grupos específicos para tipos específicos de dados, segredos, chaves ou certificados. O problema é que essas políticas estão vinculadas diretamente ao cofre. Se você tiver vários cofres, precisará gerenciar as políticas em cada um separadamente. Não é escalável. A Microsoft agora recomenda não utilizá-las pois possuem problemas de segurança conhecidos. Elas não suportam o gerenciamento de identidade privilegiada e podem criar caminhos inesperados de escalonamento de privilégios. O segundo modelo é o Azure RBXC, controle de acesso baseado em função. Essa é a maneira moderna. Ele usa identidades do EntryD e é consistente com a forma como você gerencia permissões em todo o resto do Azure. Se você já sabe como dar a alguém acesso a uma conta de armazenamento ou a uma máquina virtual, você já sabe como dar acesso ao Key Vault.

Mesmo sistema, mesmo padrões. Aqui está a regra de ouro, privilégio mínimo. Dê apenas o acesso mínimo que alguém precisa, nada mais. Se alguém precisa apenas ler segredos, não dê permissão para criá-los ou excluí-los. Se alguém precisa apenas gerenciar certificados, não dê acesso às chaves. Deixe-me explicar as funções principais. Você tem um leitor do Key Vault. Isso permite que alguém lhe segredos, mas não lê seu usuário. Usuário de segredos, o Key Vault. Isso permite que alguém leia efetivamente os valores do segredo. E o oficial de segredos, o Key Vault. Isso permite que alguém crie, atualize e escolha segredos. Observe o padrão. Cada função é específica para os dados dentro do cofre, não para o cofre em si. Agora compare isso com as funções amplas, proprietário, colaborador e leitor. Elas se aplicam ao cofre como um recurso, não aos dados dentro dele. Um proprietário pode excluir o cofre inteiro.

O colaborador pode modificar as coisas do cofre. Mas nenhuma dessas funções, por si só, dá acesso aos segredos contidos nele. Essa é uma camada de permissão separada. Esse é o ponto principal. Controle de acesso é como um bom em camada. Você precisa de acesso ao cofre em si. Essa é a primeira camada. E precisa de acesso aos dados dentro dele. Essa é a segunda. Ambas devem ser concedidas separadas. A maioria dos iniciantes pensa apenas na primeira camada e esquece a segunda. É aí que os programas começam. O erro de segurança número 1. O ponto é o seguinte. A maioria das pessoas olha para a função de colaborador o Key Vault e acha que é segura. Elas veem a palavra colaborador e presumem que podem gerenciar as configurações do cofre, mas não tocar no segredo interno. A própria documentação da Microsoft dizia exatamente isso hoje não mesmo. Esta função não permite que você acesse segredos, chaves ou certificados.

Exceto que isso não é totalmente verdade. Um usuário com a função de colaborador do Key Vault pode modificar políticas de acesso no cofre. E se esse cofre ainda usa políticas de acesso legadas, o que muitos fazem, eles podem simplesmente conceder a si mesmos acesso total de leitura a cada segredo, chave e certificado dentro dele. Nenhuma exploração especial é necessária. Nenhuma vulnerabilidade para corrigir. É apenas assim que as permissões funcionam. Pesquisadores de segurança da Datadog provaram isso em 2024. Eles mostraram que um colaborador poderia escalar para acesso total aos dados em qualquer cofre usando políticas de acesso legadas. A resposta da Microsoft foi interessante. Eles disseram que isso não é uma vulnerabilidade porque colaboradores são projetados para gerenciar políticas de acesso, mas também atualizaram a documentação para avisar explicitamente que a função pode conceder a si mesmo e que a função pode conceder a si mesmo acesso ao plano de dados.

Portanto, isso não é um bug no Key Vault em si a uma armadilha de configuração. E ela pega até equipes experientes porque o nome da função soa inofensivo. O colaborador não parece alguém que pode ler suas senhas de banco de dados, mas, na prática, pode. Pense no risco. Se um invasor comprometer uma conta com a função de colaborador no seu cofre de chaves, ele não precisa invadir o cofre. Ele não precisa quebrar a criptografia. Eles apenas modificam a política de acesso, concedem a si mesmo os acessos de leitura e esfiltram silenciosamente todos os segredos que você armazenou. Strings de conexão, chaves de API, certificados, tudo. E como alterações na política de acesso são atividades administrativas normais, isso pode não disparar nenhum alerta. Qual é a solução? Primeiro, use o Azure RBAC para acesso ao plano de dados em vez de políticas de acesso legadas. O RBAC separa o gerenciamento do cofre e dos dados contidos nele.

Segundo, nunca conceda a função de colaborador de cofre de chaves a ninguém que não precise dela absolutamente. Terceiro, se você já tem usuários com essa função, faça uma auditoria hoje mesmo. Substitua o colaborador por funções mais específicas, como usuário de segredos de cofre de chaves ou oficial de segredos de cofre de chaves. Há um segundo erro que agrava este primeiro. Colocar todos os seus segredos em um único cofre. Se você tem um cofre para todo desenvolvimento, teste, homologação, produção em todas as suas aplicações e esse cofre é comprometido, tudo fica exposto. É um ponto unifalha. Falaremos mais sobre a estratégia de múltiplos cofres em breve, mas o princípio é simples. Não coloque todos os ovos na mesma cesta, especialmente quando essa cesta guarda as chaves de toda a sua infraestrutura. Identidade gerenciada ou padrão ouro. Então, como fazer isso da maneira correta? Vamos falar sobre a melhor forma de acessar o Key Vault.

Existe uma ideia fundamental. Para obter credenciais do Key Vault, sua aplicação precisa se autenticar, mas para se autenticar, ela precisa de credenciais onde você armazena as credenciais que seu aplicativo usa para obter credenciais. É o problema do ovo e da galinha. A resposta antiga era um service principal com um segredo de cliente. Mas esse segredo precisa ficar em algum lugar. Talvez em um arquivo de configuração, variável de ambiente ou um pipeline de implantação. E agora você voltou ao mesmo problema. Você apenas moveu o segredo para outro lugar. A identidade gerenciada resolve isso completamente. Veja como funciona. Ao habilitar a identidade gerenciada em um recurso do Azure, como um aplicativo web, uma função ou uma máquina virtual, o Azure cria automaticamente uma identidade para esse recurso no EntraID. Essa identidade é gerenciada inteiramente pelo Azure. Sem credenciais para criar, sem segredos para rotacionar nada para armazenar.

O recurso simplesmente possui uma identidade que o Azure reconhece. Existem dois tipos. A identidade gerenciada atribuída pelo sistema está vinculada a um recurso específico. Se você excluir o recurso, a identidade também desaparece. Elas compartilham o ciclo de vida, o que simplifica a administração. A identidade gerenciada atribuída pelo usuário é uma identidade independente que você pode atribuir a vários recursos. Ela não compartilha o ciclo de vida com nenhum deles, por isso é útil quando você precisa da mesma identidade em vários serviços. Veja como isso funciona na prática. Você tem um aplicativo web que precisa ler uma string de conexão de banco de dados do Key Vault se habilita a identidade gerenciada atribuída pelo sistema no aplicativo web. Então você concede a essa identidade a função de usuário de segredos do Key Vault no seu cofre. Nada de string de conexão no código, nada de segredos de cliente em arquivos de configuração.

O aplicativo web se autentica no Key Vault usando sua identidade gerenciada e o Azure cuida de todo o gerenciamento de credenciais nos bastidores. Isso é o mais próximo de uma autenticação sem credenciais que você terá no Azure. É uma mudança radical para a segurança, pois elimina o vetor de ataque mais comum, credenciais roubadas.

roubar não é nada para um invasor comprometer. Deixe-me dar um exemplo do mundo real. Imagine um pipeline de dados no Synapse que precisa acessar uma conta de armazenamento. Do modo antigo, você armazenaria a chave da conta de armazenamento na configuração do pipeline. Se alguém obtivesse acesso a esse pipeline, teria a chave. Com a identidade gerenciada, o workspace do Synapse possui uma identidade. Essa identidade recebe permissão de acesso ao Key Vault onde a chave da conta de armazenamento está armazenando. O pipeline busca a chave em tempo de execução, usa e nunca armazena em lugar nenhum. Sem chaves no código,

combinar a identidade gerenciada com RBS e privilégio mínimo, você obtém uma base segura para qualquer carga de trabalho no Azure. Seus aplicativos se autenticam sem credenciais. Eles acessam apenas o que precisam e cada acesso é registrado e auditável. É o padrão que a Microsoft recomenda para quase todos os cenários. Depois de começar a usar, você vai se perguntar por que fez de outra forma antes. Custo e estratégia de múltiplos cofres. Então, vamos falar sobre custo. É aqui que a maioria das pessoas se surpreende. Quanto custa o Azure que volte, afinal? O modelo de precificação é simples. Não há taxa de armazenamento por segredo. Você não paga por cada senha ou chefe de API que armazena. Em vez disso, você paga por operação. Para a camada padrão, custa cerca de 3 centavos a cada 10 mil operações. Uma chamada de busca de segredo conta como uma operação. O mesmo vale para criar um segredo ou listar o que está no cofre.

Para um aplicativo típico de pequena ou média ou forte, isso resulta em centavos por mês. Centavos literais. Compare isso com a AWS Secrets Manager. Eles cobram 40 centavos por segredo ao mês apenas para armazená-lo, além de taxas extras por chamada de API. Se você tiver sem segredo, são 40 dólares por mês antes mesmo de ler um dedo. Com o Azure Equivolt, sem segredos, com o uso moderado, podem custar 15 centavos. A diferença cresce rapidamente em escala. Bem, existe uma camada premium. Ela adiciona chaves baseadas em HSM para cargas de trabalho que precisam do mais alto nível de garantia criptográfica. Pense em transações financeiras, dados de saúde e sistemas governamentais. O custo por operação é mais alto, cerca de 15 centavos por 10 mil operações para tipos de chave avançados, mais uma taxa mensal por chave HSM. Mas para a maioria das aplicações, a camada padrão é mais do que suficiente.

Para um aplicativo web típico com alguns segredos e alguns milhares de operações por mês, o que vale te custa menos de um dólar, você gastará mais no café que toma enquanto configura. Mas existe uma estratégia que importa mais do que o... Quantos cofres você usa? A abordagem inteligente é uma estratégia de múltiplos cofres. Use cofres separados para desenvolvimento, teste, homologação e produção. Isso evita o acidente mais comum. Alguém executando um script de teste que acidentalmente lê um banco de dados de produção porque a string de conexão estava no mesmo cofre. Quando os ambientes são separados, esse erro se torna impossível. deve separar por unidade de negócio ou domínio de conformidade. Se você lida com dados de cartões de pagamento, coloque esses segredos em seu próprio... Cargas de trabalho gerais de negócio vão em outro, dados de saúde em um terceiro. Não se trata de ser difícil, trata-se de limitar o raio de impacto.

Se um cofre for comprometido, apenas os segredos nele contidos são expostos. O restante da sua infraestrutura permanece seguro. Duas redes de segurança integradas que você deve sempre abrir. A exclusão temporária significa que se alguém excluir um segredo, ele não será perdido permanentemente. Ele entra em estado recuperável por um período de retenção que você escolhe até 90 dias. A proteção contra a limpeza vai um passo. Ninguém pode excluir permanentemente o cofre do seu conteúdo até que esse período de retenção expire. Juntos, eles evitam o tipo de perda acidental de dados que tira o sono das equipes de segurança. Como tudo se conecta. Vamos unir tudo isso e ver como as peças se encaixam. O Key Vault não é uma ilha. Ele é o sistema nervoso central para segredos na sua arquitetura azule. Quando você entende como todo sistema flui, tudo se encaixa. Aqui está o que acontece quando um aplicativo precisa de um segredo.

O aplicativo solicita usando sua identidade gerenciada. Essa identidade já está registrada no EntraID. O Azure a criou automaticamente quando você habilitou a identidade gerenciada no recurso. O EntraID valida se a identidade é legítima e em seguida encaminha a solicitação ao Key Vault. Verifica as permissões RBS que você atribuiu. Se a identidade tiver a função correta, digamos, o usuário de segredos do Key Vault o segredo é retornado. Do isso acontece em milissegundos. O aplicativo nunca vê uma credencial. Ele nunca armazena uma senha. Ele apenas obtém o valor de que precisa. Agora pense em quantos serviços do Azure podem se conectar a isso. App Service, Functions, AKS, Data Factory, Synapse, Logic Apps, DevOps Pipelines. Todos eles sabem como falar com o Key Vault. Você pode configurar um aplicativo web para referenciar um segredo diretamente nas configurações do aplicativo. Você pode configurar um pipeline do Data Factory para buscar uma chave de conta e armazenamento no Key Vault e Neto.

Você pode configurar um cluster Kubernetes para extrair segredos usando o driver CSE do Key Vault. Todo serviço se integra da mesma forma, usando o mesmo sistema de identidade, as mesmas funções RBS e o mesmo registro de auditoria. O padrão de CI e CD é especialmente poderoso. Seus pipelines buscam segredos no Key Vault e no momento da implantação. Eles nunca os armazenam em variáveis de pipeline ou segredos de repositório. Se você precisar rotacionar uma senha de banco de dados, basta atualizá-la no Key Vault. Na próxima vez que seu pipeline for executado, ele buscará um novo valor automaticamente. Sem alterações no pipeline, sem alterações no código, sem reimplementação. Aqui está o ponto principal que faz tudo se encaixar. Uma vez configurado o Key Vault com identidade gerenciada, RBQ, você para de se preocupar totalmente com gerenciamento de credenciais. Suas aplicações simplesmente funcionam.

Segredos são rotacionados sem que ninguém perceba. Certificados são renovados sem emergência no meio da noite. O sistema cuida de tudo em segundo plano. Essa é a postura de segurança que realmente importa. A identidade é o perímetro, não a rede. Não importa se alguém está dentro ou fora da sua rede virtual. O que importa é se eles possuem uma identidade válida com as permissões corretas. O Key Vault impõe-se por design. Cada solicitação de acesso passa pela autenticação do EntraID e autorização RBA que independentemente de onde a solicitação venha. E tudo é registrado. Cada leitura de segredo, cada operação de chave, cada recuperação de certificado. Você pode ver quem acessou o que e quando. Se algo parecer suspeito, você tem os dados necessários para investigar. Isso é crítico para conformidade, resposta a incidentes e para saber exatamente o que está acontecendo no seu ambiente. Essa é a beleza de dois.

Key Vault, EntraID, RBA, C, identidade gerenciada trabalham juntos como uma estrutura de segurança unificada. Cada peça reforça as outras. Quando tudo está configurado corretamente, você tem um sistema de gerenciamento de credenciais que é mais seguro e simples de operar do que qualquer coisa que você pudesse criar. Conclusões práticas. Então o que se deve fazer agora mesmo? Vamos transformar esse conhecimento em ação. Aqui estão as coisas que você pode abordar essa semana. Comece pelo seu modelo de permissão. Abra seu Key Vault no portal, vá para a configuração de acesso e verifique o que ela indica. Se você vir em política de acesso ao cofre, esse é o método antigo. Você deve preferir o controle de acesso baseado em função do Azure. A migração é assim. Alterne o modelo de permissão e atribua funções RBA que as mesmas pessoas que já possuíam políticas de acesso. Faça isso. A Microsoft recomenda e a pesquisa que discutimos mostrou exatamente o porquê.

Em seguida, audite todas as contas que possuem a função de colaborador do Key Vault. Abra a folha M do seu cofre e veja quem tem acesso de colaborador. Cada pessoa com essa função precisa ter um bom motivo para ter. Na maioria das vezes não precisam. Substitua colaborador por algo mais específico. Se alguém precisa apenas ler segredos, use o ar de segredos do Key Vault. Se precisarem gerenciar segredos, use o oficial de segredos do Key Vault. O objetivo é fechar totalmente esse caminho de escalonamento. Em seguida, aproveite a identidade gerenciada. Qualquer serviço do Azure que precise de acesso ao Key Vault deve usá-la. Se você tem um aplicativo web, uma função, um data factory ou uma máquina virtual usando o service principal com client secret, mude para a identidade gerenciada. É mais simples, mais seguro e resolve o problema do ovo e da galinha que discutimos. O Azure cuida do gerenciamento credenciais para você nos bastidores.

Mais uma coisa, habilite a exclusão reversível e a proteção contra limpeza em cada cofre. A exclusão reversível é padrão para novos cofres, mas a proteção contra limpeza não é. Ative. Essa configuração impede que alguém exclua permanentemente um cofre ou seu conteúdo durante o período de retenção. Isso salvou mais de uma equipe de um erro desastroso. Aqui está a sua chamada para a ação. Analise sua abordagem atual e deseja em segredo. Encontre um segredo que ainda esteja em um arquivo de configuração variável de ambiente ou codificado no código Mova-o para o Key Vault esta semana. Apenas. Assim que vir como é simples, você vai querer mover o restante. Segurança não é uma configuração única, é uma prática. O Key Vault torna essa prática mais fácil, mas apenas quando usado corretamente. As ferramentas puníveis, os padrões são comprovados. Agora cabe a você implementá-lo. Esse é o sistema. O Key Vault é seu cofre digital, mas é tão seguro quanto os controles de acesso que você coloca ao redor dele.

Comece com a auditoria que acabei de escrever. Verifique seu modelo de permissão. Verifique suas atribuições de colaborador e mova um segredo para um cofre esta semana. Inscreva-se para mais dicas de segurança na nuvem em linguagem simples e compartilhe isto com alguém que ainda armazena segredos em arquivos de configuração.