No último artigo falamos sobre o que são os cofres de senha, apresentamos o Azure Key Vault, comentamos sobre algumas das suas caracterísicas e sobre sua arquitetura. Hoje, olharemos para ele com um olhar de cibersegurança, pensando em como podemos realizar o acesso seguro a esse componente quando estivermos desenvolvendo nossas aplicações.

Exposição segura

Por ser uma solução PaaS (Platform as a Service), o Azure Key Vault permite que seus usuários se beneficiem do uso dos Service Endpoints e Private Endpoints, recursos disponíveis no Azure e que incrementam a segurança do tráfego roteado para certos recursos. A grande diferença entre eles:

• Service Endpoints: permitem a restrição do consumo do serviço através das virtual networks do Azure. O recurso (Azure Key Vault) identifica que o tráfego está vindo da sua virtual network e avalia o consumo de acordo com as políticas cadastradas. Com essa funcionalidade habilitada, o tráfego será roteado através do backbone global da Microsoft até o recurso de destino, porém o endpoint utilizado para acessar o componente, é o endpoint público;

• Private Endpoints: suportados pelo Azure Private Link, os private endpoints oferecem uma maneira de deixar o consumo dos seus recursos completamente privado. O tráfego não será direcionado para fora da Virtual Network em momento algum, permanecendo completamente privado o caminho todo.

O desenho acima mostra de maneira simplificada a utilização dos private endpoints no consumo do Azure Key Vault.

Sendo o principal recurso para proteção à níve de plataforma, uso dos private endpoints pode gerar muitos benefícios para as organizações em geral. Alguns deles são:

• Redução da superfície de ataque: pelo fato do vault estar protegido do acesso externo e disponível apenas para os recursos existentes dentro da Virtual Network em questão, a possibilidade de vazamento de informações sensíveis é reduzida drásticamente;

• Restrição/Controle do Uso: permitindo o controle de acesso via origem, os times de segurança conseguem controlar quem pode acessar o cofre também na camada de rede, garantindo a proteção do consumo além da camada de identidade.

Ainda na camada de networking, o consumo do recurso pode ser protegido através do Resource Firewall, funcionalidade disponível no vault e que nos permite restringir o acesso à ranges de IP e endereços IP específicos.

Quando falamos de proteção de plataforma, não temos muito a explorar além da camada de networking, porém quando pensamos nas ações relacionadas à identidade, é possível controlarmos o acesso de muitas outras formas, como veremos na próxima seção.

Uso de identidades

"Pulando" de camada, temos as identidades, que são a porta de entrada para qualquer ambiente em nuvem.

Dentro do Azure, nós temos diferentes tipos de identidade que podem ser utilizadas na autorização do consumo dos recursos da plataforma. Em sua grande maioria, a função delas é a mesma, o que diferencia é o modelo de uso:

• Managed Identities: é o modelo mais seguro, porém o mais "limitado". As Managed Identities só podem ser utilizadas quando estamos autorizando um recurso da plataforma a consumir outro (ex: uma aplicação sendo executada via Azure Functions precisa consumir uma secret existente em um Azure Key Vault, para facilitar a gestão dessa identidade, nós atribuímos uma managed identity ao recurso consumidor e então atrelamos as permissões necessárias à ela);

• Service Principals: sendo o modelo que oferece mais flexibilidade, as Service Principals são utilizadas nos casos onde não conseguimos/devemos autorizar um sserviço de plataforma a consumir o recurso em questão (ex: uma aplicação executada no Azure Kubernetes Service precisa consumir o Azure Key Vault para recuperar uma chave utilizada para criptografar os dados manipulados pela solução, como a aplicação executada no AKS não é um recurso de plataforma "tangível", utilizamos as Service Principals);

Os dois tipos de identidade podem ser utilizadas para consumir o Vault, porém caso as service principals sejam escolhidas, temos 2 maneiras de realizar a autenticação:

• Certificados: dentro do Entra ID é possível realizar o upload de um certificado para ser utilizado como a credencial da identidade para a autenticação;

• Secrets: no momento de cadastramento da identidade, podemos criar uma secret para servir de "senha", funcionando da mesma maneira que o certificado.

O grande impasse entre utilizar certificados e segredos é a necessidade de se ter um processo bem estabelecido para realizar a atualização/rotação dessas credenciais, que podem gerar problemas ao ambiente se não forem bem gerenciadas.

O uso das Managed Identities é recomendado pelos guidelines de segurança da Microsoft, porém sua limitação à autorização apenas através dos recursos de plataforma restringem sua utilização. Em casos onde não se é possível utilizar esse tipo de identidade, devemos seguir com as service principals e o fator de autenticação de sua escolha.

RBAC

Seguindo para a última sessão do texto, temos o RBAC (Role Based Access Control), recurso que falamos no artigo anterior (neste link).

O modelo de RBAC do Azure Key Vault é um pouco diferente do modelo encontrado nos outros recursos do Azure. Primeiro, o vault é divido em management plane e data plane e o controle de acesso é realizado de maneira segregada nos dois paineis.

Essa arquitetura permite que os times de desenvolvimento tenham acesso exclusivamente aos dados que serão utilizados por eles. Com a criação das políticas de acesso ao data plane, todos os recursos exisitentes no vault e não pertencentes ao projeto em questão, estarão seguros dos acessos indevidos possívelmente realizados por outras equipes e até por agentes mal intencionados.

Os vaults são extremamente úteis para armazenar informações sensíveis e sua segurança deve sempre ser pensada meticulosamente.

Espero que tenha gostado do texto e que de alguma forma eu tenha conseguido contribuir com a segurança do seu ambiente.

Até mais!