Quando estamos consntruindo nossas soluções em nuvem, nos deparamos constantemente com questões relacionadas a segurança. "Onde devo armazenar as credenciais do meu banco de dados?", "Como posso implementar meu certificado para estabelecer uma comunicação segura", "De que forma devo armazenar a chave utilizada para criptografar meus arquivos em um blob storage?", são alguns questionamentos que nos ocorrem. Para responder esses questionamentos, a resposta é a mesma: utilizando o Azure Key Vault.
Para que serve?
Na introdução do texto, mencionei algumas funções para qual o Azure Key Vault pode ser utilizado, porém nessa sessão vamos descrevê-as de maneira mais detalhada.
Os vaults (não restritos apenas ao Azure Key Vault, mas também soluções com o Hashicorp Vault) são utilizados para armazenarmos e acessarmos credenciais sensíveis de maneira segura e protegermos o acesso à elas.
O Azure Key Vault é utilizado majoritariamente sob 3 tipos de recursos: chaves (keys), segredos (secrets) e certificados (certificates).
Chaves - são informações utilizadas para criptografar dados em outros serviços (ex: storage accounts, cosmos db, sql database, etc);
Segredos - podem ser várias coisas diferentes, como senhas, API Keys e outras informações que devem ter seu acesso público protegido;
Certificados - utilizados para estabelecer comunicações seguras e autenticações, podemos gerenciar o ciclo de vida dos objetos dentro do vault.
Os objetos mencionados acima e gerenciados pelo Key Vault poderão ter seu ciclo de vida controlado pelo recurso (dentro das limitações existentes). Certificados poderão ser criados e excluídos, chaves poderão ser criadas, rotacionadas e excluídas, segredos poderão ser atualizados, e por aí vamos.
Entendemos os recursos básicos do Azure Key Vault, mas agora, para que ele serve?
O desenho acima mostra o cenário mais comum de uso do Azure Key Vault. Vemos uma aplicação consumindo não apenas um segredo armazenado no vault (e utilizado para acessar um banco de dados) mas também o consumo de um certificado (utilizado para estabelecimento de comunicação TLS).
No segundo cenário, demonstrado acima, vemos uma Azure Storage Account consumindo uma chave armazenada no Azure Key Vault para criptografar os blobs existentes dentro de si.
Esses são dois dos cenários mais comuns de uso do vault, mas não se limitam apenas a esses. Você pode utilizar um vault como bem entender, desde que a solução proposta atenda a sua demanda.
Arquitetura
Sendo um PaaS (Platform as a Service) não temos o que gerenciar em relação à infraestrutura do Key Vault, porém suas funções são segregadas de forma a termos um painel de gerenciamento e um de acesso aos dados contidos no cofre.
Essa divisão entre management plane e data plane não é visível pelos usuários finais (desenvolvedores, arquitetos, engenheros, etc), porém é altamente influente quando pensamos no controle de acesso (assunto da próxima sessão).
A arquitetura desenhada para o Azure Key Vault nos permite ter maior controle e segurança dos nossos dados e de quem os acessa.
Controle de acesso
Ainda no tema que finalizou a última sessão, o modelo de controle de acesso ao Azure Key Vault é um pouco diferente do que estamos acostumados a encontrar nos outros recursos.
Da forma que foi projetado, é possível separar o uso dos gestores do vault e dos consumidores, dessa maneira estabelecendo um controle granular mais efetivo das responsabilidades de cada um dos atores.
O management plane é responsável por gerenciar todos os aspectos de funcionamento do vault, como suas propriedades, permissões de acesso, configurações de segredos, chaves e certificados. Já o data plane habilita o acesso às informações valiosas do recurso, como os valores dos segredos, as chaves e os certificados armazenados.
Como podemos ver no simples desenho acima, a granularidade das permissões existentes no data plane permite maior controle sobre o que uma identidade pode fazer em um determinado tipo de objeto. Essa granularidade não existe no RBAC do management plane, pois o mesmo implementa grande parte das roles existentes nos outros recursos do Azure (ex: contributor, reader, admin, etc).
Esse modelo permite que as aplicações recebam apenas os acessos necessários para realizarem as operações no objeto em questão. Não é necessário fornecer à aplicação visibilidade sobre as outras coisas que estão no cofre e muito menos do cofre em si. O acesso é feito diretamente ao recurso necessário, sem passar por qualquer outra "barreira".
As soluções de cofre são de extrema utilidada quando estamos montando nossas soluções em nuvem. Soluções como o Hashicorp Vault, AWS KMS e o Azure Key Vault oferecem maneiras de manter o acesso às informações seguro, seguindo as boas práticas da arquitetura de soluções em nuvem.
Espero que tenha gostado do texto e que de alguma forma eu tenha conseguido te ajudar no entendimento das funcionalidades do vault bem como as formas com que ele possa utilizado nas suas soluções.
Até logo!