Terça-feira a tarde e uma reunião de rotina com um de nossos clientes, uma empresa financeira de cartão de crédito.

O assunto era como implementar DevOps e adotar um AKS.

Chamou a atenção a presença de um servidor de identidade, quando analisamos a aplicação percebemos que a chave de criptografia estava em um diretório público.

Este artigo aborda uma experiência real da equipe da AzureBrasil.

Em um cenário de transformação digital, a migração para a nuvem é um passo crítico para quem busca flexibilidade e escalabilidade. No entanto, migrar não se trata apenas de mover aplicações. É uma jornada onde é necessário avaliar o ambiente como um todo, incluindo práticas de segurança, especialmente quando se trata da adoção de um Kubernetes gerenciado, como o AKS.

O trabalho da AzureBrasil não se limita a realizar a migração dos workloads para a nuvem. Nossa abordagem vai além. Nós temos especialistas em Infra, Aplicação, DevOps e FinOps. Nossa busca é oferecer uma visão 360 do ambiente do cliente.

Isso significa avaliar aspectos críticos como segurança, práticas DevOps, monitoramento, governança e otimização de custos.

Essa postura holística é nosso diferencial, conseguimos identificar potenciais gargalos e oferecer soluções que realmente fazem a diferença na operação do cliente em um ambiente de produção em nuvem.

O Desafio: Adoção do AKS e práticas DevOps

Durante a reunião, analisamos as aplicações em execução nas VM's do cliente.

Chamou a atenção a presença de um servidor de identidade. Servidores de identidade, por natureza, lidam com informações sensíveis e requerem cuidados especiais com chaves de criptografia, principalmente em ambientes que escalam horizontalmente, como em um cluster AKS.

Quando um servidor de identidade é escalado, ele pode ser distribuído em múltiplos nós. Nesse cenário, a gestão de chaves de criptografia se torna um desafio, pois cada instância precisa ter acesso a essas chaves de maneira segura e consistente. Uma má gestão pode resultar em falhas de autenticação, comprometimento de dados e até mesmo violações de conformidade.

Descobrimos que o servidor de identidade utilizado era um IdentityServer. Ao analisar como estava sendo feita a gestão da chave de criptografia, identificamos que a chave não havia sido rotacionada há 5 anos. Segundo as recomendações do NIST, as chaves de criptografia devem ser rotacionadas a cada 1 ano, no entanto as boas práticas do mercado recomendam uma rotação a cada 3 meses para garantir maior segurança e integridade.

Além disso, um ponto crítico que identificamos foi que a chave de criptografia estava salva no diretório wwwroot do ASP.NET MVC, o que representava uma grave vulnerabilidade.

Como resultado, qualquer na internet poderia efetuar o download da chave privada, comprometendo a segurança de todas as informações protegidas pelo IdentityServer.

Solução

Recomendamos o uso do componente NetDevPack.Security.JWT. desenvolvido por nossa equipe da Azure Brasil e utilizado em milhares de projetos empresariais ao redor do mundo.

Este componente é projetado para gerenciar as chaves de criptografia de um projeto ASP.NET MVC e possui uma extensão para IdentityServer. O componente faz a rotação automática das chaves a cada 3 meses, seguindo as melhores práticas do NIST. Além disso, ele oferece extensões específicas para a gestão de chaves de criptografia em ambientes distribuidos, incluindo o AKS.

O NetDevPack.Security.JWT adere às melhores práticas do conjunto de especificações do JWT (JOSE) e às recomendações do NIST, como a prática de remover a chave privada anterior ao realizar a rotação e manter apenas a parte pública.

Conclusão

Quem diria que um simples café sobre DevOps terminaria com um bug crítico em produção, com a necessidade de uma correção ontem, né?

Que tal ter uma conversa dessas conosco? Agende um café gratuitamente e vamos juntos explorar o potencial do seu ambiente!