Segurança da informação não é apenas sobre achar e corrigir bugs no código que causam falhas de segurança, existe muito mais além disso. Um erro muito comum que iniciantes em segurança cometem é achar que seu sistema é "invulnerável" ou que, havendo falha de segurança, não há mais nada a ser feito.

Seja um extremo ou outro, os dois erros resultam na mesma coisa: não fazer nada. Seja porque acha que foi a primeira pessoa no planeta a transcender as limitações humanas e fazer um sistema perfeito; ou seja porque acha que falha de segurança é sinônimo de fim do mundo.

Bons profissionais de segurança não se preocupam apenas com a superfície de ataque, se preocupam também com o cenário onde o sistema tem uma falha de segurança e um atacante conseguiu explorá-la com sucesso.

Defesa em profundidade

Defesa em profundidade (defense in depth) é uma estratégia na área de Cibersegurança baseado na estratégia militar homônima. A estratégia militar consiste em atrapalhar os avanços do adversário de forma que se ganha tempo. O objetivo não é tornar o ataque "impossível", mas sim torná-lo difícil, demorado e cansativo.

A estratégia em Cibersegurança segue o mesmo princípio. Você não defende o sistema assumindo que sua defesa é "absoluta" e "impenetrável", mas sim assumindo que o atacante conseguirá explorar uma vulnerabilidade com sucesso. Mas após conseguir isso, o atacante não conseguirá acesso total ao sistema mas sim se depará com mais uma camada de defesa que exige que ele, novamente, explore mais alguma vulnerabilidade para prosseguir.

Se quiser pensar em uma analogia no mundo físico, seria algo como você tentar proteger a sua casa. Digamos que você tem um muro com cerca elétrica, mas se um ladrão conseguir pular o muro ele terá que lidar com cães de guarda. Se ele der um jeito nos cães, ele ainda terá que arrombar uma fechadura eletrônica na porta da casa. Se ele conseguir, ele terá que desligar um alarme. Se ele der um jeito de desligar o alarme, ele vai ter que enfrentar o dono com uma espingarda na mão. Isso é defesa em profundidade.

Redução da área de impacto

Vou falar de um único princípio na defesa em profundidade, que é a redução da área de impacto; que eu diria que é o ponto principal, a propósito. A área de impacto, também chamada informalmente de "blast radius", é o quanto um atacante consegue comprometer um sistema caso ele explore uma vulnerabilidade com sucesso.

Você pode pensar nisso de uma maneira bem simples: «Se alguém conseguir explorar uma vulnerabilidade na minha aplicação, o quão ferrado eu estou?»

Quanto mais ferrado você estiver, maior a área de impacto daquela vulnerabilidade. :D

Isolamento de serviços

Isolar serviços é uma maneira de reduzir a área de impacto de uma vulnerabilidade. É simples de entender, mas nem tão simples de configurar (com segurança): Isolar serviços é você fazer com que cada serviço de rede da sua infraestrutura rode isolados um do outro. Assim, caso um seja comprometido, isso não dá acesso automático aos outros.

Exemplo: Digamos que você tem um web app que precisa de nginx, PHP-FPM, PostgreSQL e Redis.

Você pode configurar tudo isso pra rodar em uma instância do seu cloud provider e tudo certo. Mas, digamos, que alguém explora uma vulnerabilidade RCE no nginx e consegue uma shell no servidor. Isso significa que o atacante tem acesso ao seu banco de dados? Se sim, agora você entendeu porque isolar serviços é importante.

Veja como a área de impacto de uma vulnerabilidade no nginx é grande o suficiente para afetar o banco de dados. Podemos reduzir essa área de impacto simplesmente isolando o nginx dos demais serviços e, inclusive, da própria aplicação web.

Não cabe ao escopo deste post ensinar infra, mas o jeito mais simples e barato de isolar serviços é rodar eles em containers (usando Docker, por exemplo). Você provavelmente já sabe usar Docker, então é só uma questão de aprender a configurar direitinho com segurança.

Mas esse não é o máximo de segurança que é possível obter, pois vale deixar claro que container escape existe, isto é, é possível um atacante explorar uma vulnerabilidade para conseguir sair do container e obter acesso completo ao sistema. E isso pode ser tanto causado por uma vulnerabilidade no Docker, um erro de configuração da sua parte ou até mesmo uma vulnerabilidade no kernel Linux.

Mas isso já é defesa em profundidade, pois após explorar uma vulnerabilidade no nginx o atacante teria que explorar outra vulnerabilidade para fazer container escape.

Se quiser mais segurança do que isso, veja soluções onde você roda cada imagem de container em uma MicroVM isolada, como AWS Fargate, ou faça sua própria solução usando VM/MicroVM. A regra é: MicroVM > VM > sandbox > container > nada.

• MicroVM é mais seguro que VM (tem menor superfície de ataque para um VM escape);
• VM é mais seguro que sandbox;
• Sandbox é mais seguro que container;
• Container é mais seguro que nada.

Sistemas distribuídos

As pessoas normalmente falam sobre sistemas distribuídos, como microsserviços, pensando em escalabilidade, mas sistemas distribuídos também são bons para a redução de impacto e, portanto, são mais seguros do que sistemas monolíticos.

Imagine que você tem uma API monolítica com uma vulnerabilidade em um endpoint como POST /posts/{id}/comments. Nesse endpoint tem um SQLi e devido a um erro de configuração no MySQL o atacante conseguiu uma shell no sistema operacional.

Esse endpoint está no escopo de posts e comentários, mas como seu sistema é monolítico o atacante conseguiu acesso geral ao sistema e ao banco de dados. Portanto ele pode exfiltrar todos os dados da aplicação, não apenas posts e comentários.

Se fosse um sistema distribuído, o atacante conseguiria apenas comprometer o serviço da aplicação que diz respeito aos posts e não teria acesso a mais nada.

Repare como a área de impacto de uma vulnerabilidade em um sistema monolítico é muito maior comparado a um sistema distribuído.

Zero trust

Zero trust é uma estratégia de segurança onde você não assume nenhum sistema como confiável.

Normalmente o que as pessoas fazem é configurar a infraestrutura do sistema assumindo que sistemas internos e inacessíveis por pessoal não autorizado é "confiável". Isso funciona, até que o sistema é comprometido...

A ideia do zero trust é justamente assumir que um atacante já comprometeu com sucesso algum sistema e pode estar tentando fazer movimentação lateral na rede interna. Com isso em mente, você configura todo servidor e serviço não confiando que ninguém, mesmo que venha de um servidor interno, tem acesso liberado imediatamente.

Nota: Movimentação lateral é obter acesso a outros sistemas na mesma rede.

Então mesmo para servidores e sistemas internos, você precisa configurá-los de forma que exijam autenticação de um usuário autorizado à acessar aquele sistema. Também é importante registrar em logs essas autenticações para futura auditoria, em caso de incidente de segurança.

Isso diminui a área de impacto que um atacante consegue ter, pois mesmo que ele consiga comprometer um servidor com sucesso, isso não dá acesso automático à toda a rede.

Vou simplificar caso não esteja claro: Proteja seus sistemas internos tão bem quanto você protegeria se ele estivesse exposto à internet... e não o deixe exposto à internet. Trate sua rede interna como não confiável do mesmo jeito que você trata a internet como não confiável.