Um dos conceitos mais importantes quando falamos de cibersegurança é o Zero Trust. Esse "padrão" estabelece controles que devem ser implementados com o objetivo de deixar seu ambiente mais seguro e protegido contra os vetores de ataque mais comuns. Hoje vamos falar sobre como podemos aplicar a estratégia zero trust no seu ambiente Azure e quais serviços utilizar para cada um dos princípios!

Entendendo o Zero Trust

O Zero Trust é um framework de cibersegurança criado para direcionar a construção de ambientes seguros independente da plataforma. Permitiu direcionar as equipes de segurança das empresas na construção de soluções mais seguras e resilientes, declarando as preocupações que devem ser levadas em conta e como devem ser tratadas.

Acima temos as camadas protegidas pelo Zero Trust. Os pilares que vamos tratar na próxima seção devem ser aplicados a cada uma dessas camadas descritas acima.

Nesse texto falaremos sobre a aplicação do zero trust em nuvem pública (especificamente no Azure), porém o modelo é agnóstico à tecnologia e ambientes, permitindo sua aplicação nos espaços mais variados e com as mais diferentes soluções.

Pilares do Zero Trust

Nosso ambiente está aderente ao zero trust uma vez que respeitamos os 3 pilares determinantes desse princípio: verify explicitly, minimum privilege e assume breach.

• Verify Explicitly (verificar de maneira explícita): esse princípio guia a implementação de modo que todo e qualquer tipo de interação/consumo do seu ambiente deve ser verificado. Entraremos em detalhes mais para frente, porém serviços como o Microsoft Entra ID e o Microsoft Intune são utilizados amplamente para garantir a aplicação do princípio;

• Minimum Privilege (privilégio mínimo): consiste em fornecer apenas o mínimo de acesso necessário à identidade. O modelo de RBAC (Role-Based Access Control) disponível no Azure facilita a aplicação deste princípio e permite que os administradores forneçam apenas o acesso necessário aos usuários;

• Assume Breach (assuma brechas): não devemos em momento algum assumir que nosso ambiente é seguro, por esse motivo, devemos implementar segurança nas comunicações e nos dados, do começo ao final do nosso ambiente.

Os "pilares" declaram o que deve ser feito, os meios para se atingir aquele estado ficam completamente à critério dos times de segurança, arquitetura, sistemas e infraestrutura.

Por quê implementar o Zero Trust no seu ambiente?

Quando estamos criando novas soluções, é comum que os arquitetos e engenheiros se preocupem com os mais diversos pontos de segurança do projeto. Em quase todos os projetos nós temos: tráfego de dados, exposição de endpoints, interação de usuários, armazenamento de informações, entre outros pontos. Todos esses "tópicos" geram discussões em torno da segurança da solução, por exemplo: "meus dados em repouso devem estar criptografados?", "minha aplicação pode ser exposta para todos sem autenticação?" ou até "posso liberar acesso total aos meus recursos para os usuários?".

Como no Zero Trust nós criamos uma série de políticas para garantir que o nosso ambiente siga as melhores práticas de mercado e os padrões de compliance da nossa empresa, essas perguntas citadas no parágrafo anterior são respondidas rapidamente.

A aplicação do Zero Trust no seu ambiente fará com que o mesmo esteja preparado para possíveis falhas de segurança, que não comprometerão seus workloads pois os mesmos estarão resguardados por conta da aplicação dos princípios!

Zero Trust no Azure

Quando começamos a pensar na segurança do nosso ambiente Azure (ou qualquer outra nuvem) é importante pensarmos nas "camadas" existentes. Em cima dessas camadas é que nós aplicaremos os nossos controles e as validações de segurança necessárias para manter nosso ambiente protegido.

Vamos começar falando sobre o que devemos fazer para garantir a aplicação dos 3 pilares que comentamos anteriormente. Resolvendo cada um deles, teremos um ambiente bem estruturado e seguro, oferecendo mais tranquilidade para o desenvolvimento das soluções de negócio.

Minimum Privilege

Expandindo nosso entendimento desse princípio, o privilégio mínimo exige que o acesso fornecido aos recursos do nosso ambiente tenham o escopo estritamente necessário, nem mais, nem menos.

A correta aplicação desse princípio reduz a chance de problemas catastróficos aconteçam devido o vazamento de uma identidade super-privilegiada.

Não apenas relacionado ao comprometimento de credenciais, mas o privilégio mínimo também resguarda a organização de agentes mal intencionados e que querem causar algum prejuízo, seja financeiro ou a imagem da empresa.

Veja abaixo uma arquitetura que demonstra como o privilégio mínimo pode ser aplicado e quais serviços podem ser utilizados:

O vazamento de informações também é tratado quando aplicamos o privilégio mínimo, já que os acessos são fornecidos apenas no escopo necessário para desenvolvimento de certa atividade. Os níveis de aplicação do acesso costumam ser apenas ao recurso que o usuário em questão precisa acessar e as ações que podem ser realizadas são restritas às atividades que ele necessita realizar, não permitindo que o mesmo realize operações que não sejam as necessárias para a execução daquela tarefa.

No desenho acima nós temos ao lado esquerdo uma estrutura de ambiente Azure e do lado direito o nosso Microsoft Entra ID Tenant, responsável por controlar todo o acesso ao ambiente. Utilizando o Entra, nós conseguimos gerir nossas identidades e aplicar de maneira granular o acesso aos recursos, também representados nas setas vindas do tenant.

Acesso aos recursos é o melhor dos cenários, pois podemos controlar qual instância do recurso o usuário estará acessando e o que estará fazendo. Acesso ao resource group não é tão recomendado pois expõe a identidade à múltiplos recursos, as vezes sem a necessidade de acesso. Acesso a subscription é definitivamente o pior dos cenários e o mais desencorajado, pois habilita uma identidade comprometida a acessar tudo que está sendo executado ali.

O Microsoft Intune (solução de MDM - Mobile Device Management) permite avaliarmos os dispositivos que estão acessando nossas soluções, garantindo que estão em compliance com as regras da empresa e que tem todas as garantias de segurança aplicadas.

Abaixo do desenho também temos o Microsoft Defender for Identity, que nos permite ter visibilidade do nosso ambiente de identidade e fornece insights em identidades "superpoderosas", isso é, identidades com acesso a nível de administrador (que apresentam alto risco ao ambiente).

Verify Explicitly

Nesse princípio enxergamos a necessidade de garantir a avaliação da interação a qualquer momento. Nenhuma requisição é feita sem ser devidamente autenticada e autorizada.

A devida aplicação desse princípio garante a integridade de todas as requisições e interações realizadas no nosso ambiente, dando certeza de que o ator realizando as operações é confiável e reconhecido e não houve nenhum tipo de comprometimento de informações e credenciais.

Abaixo temos uma representação dos serviços que podem ser utilizados para aplicação desse princípio:

Assim como no princípio do privilégio mínimo, o componente central da adoção desse princípio são as identidades, representadas pelo Microsoft Entra ID. TODA interação dentro do nosso ambiente Azure deve ser devidamente autenticada e autorizada, levando em consideração as diferente informações capturadas pelo Entra.

Para componentes de plataforma, a autenticação e autorização será feita utilizando as capacidades das Managed identities, gerenciadas pelo Entra e que garantem a autenticidade do requisitor sem a necessidade de se passar credenciais de acesso.

Nossas aplicações serão representadas pelas Service Principals (ou Workload IDs), também governadas pelo Entra, mas que trafegam informações da identidade para autorizar a chamada aos recursos.

O Intune assim como no princípio anterior fornece uma camaada adicional de análise para permitir que as políticas implementadas no Entra consigam com mais assertividade avaliar o acesso e a tomada de decisão da requisição.

Do lado do Azure temos alguns componentes de rede que podem ser utilizados para proteção do nosso perímetro. Firewalls, WAF e NSGs são exemplos de recursos que nos permitem proteger nossos workloads e garantir a eficácia contra ataques cibernéticos.

Assume Breach

Falamos muito sobre identidade nos outros dois princípios, agora chegou a vez dos dados e da rede.

Para a implementação desse princípio é essencial termos nosso perímetro de rede bem configurado para evitar acessos indesejados e também criptografia de ponta a ponta em relação aos nosso dados.

Na camada de rede, utilizaremos recursos para garantir que o tráfego será roteado para o destino correto, manteremos abertas apenas as portas necessárias para o funcionamento das soluções e aplicaremos todos os gates de segurança de redes, independente da origem da chamada.

Com nossos dados o importante será mantê-los seguros. Para isso devemos aplicar criptografia nas informações trafegadas e armazenadas (at-rest). Os dados, independentemente de onde estiverem armazenados, deverão estar protegidos contra vazamentos acidentais, garantindo a confidencialidade das informações.

Na junção da camada de dados e de redes temos o "canal" de comunicação, que deverá implementar criptografia in-transit, garantindo assim que nenhum agente mal-intencionado tenha acesso às informações ali trafegadas. Essa necessidade pode ser cumprida com a apliação de mTLS, que não há um serviço próprio para sua configuração, mas fazemos uso do Azure Key Vault, que nos permite armazenar nossos certificados privados, necessários para estabelecimento da comunicação segura.

Uma etapa importante para cumprimento desse princípio é o monitoramento. É essencial que nosso ambiente esteja "visível" para os times de segurança, podendo tomar decisões apoiadas por informações verdadeiras sobre o estado da infraestrutura.

Para captarmos insights mais apurados e precisos, podemos fazer uso do Microsoft Defender for Cloud e suas diferentes capacidades. Infrastructure, Data, Applications e Identity são algumas das áreas que o Defender pode nos ajudar aumentar a cobertura do ambiente.

Evolução do seu ambiente

Nada na tecnologia dura pra sempre e é claro que a nossa estratégia de Zero Trust também sofre desse "problema".

Os times de segurança deverão aprender com os problemas captados no ambiente e atualizar toda sua postura e estratégia de políticas. As políticas de acesso condicional e as Azure Policies deverão ser "vivas" e sempre mantidas atualizadas com as principais recomendações de mercado e lições aprendidas com os incidentes gerados.

Zero Trust é um assunto denso mas extremamente importante. É essencial para a boa operação das empresas e desenvolvimento dos produtos que os ambientes estejam protegidos fim a fim, trazendo confiança para os times de desenvolvimento e stakeholders da organização.

Espero que tenha gostado do texto, estou à disposição para responder quaisquer dúvidas que tiver.

Até logo!