Defesa em profundidade

Intermediário12 min de leituraseguranca

A premissa é pessimista e correta: alguma camada vai falhar. O firewall terá uma regra errada, a biblioteca terá uma vulnerabilidade, alguém clicará no link, a credencial vazará.

Defesa em profundidade é projetar admitindo isso. Cada camada assume que a anterior já foi vencida e pergunta: o que impede o atacante de avançar a partir daqui?

O oposto é a “casca dura, miolo mole”: um perímetro forte e nenhuma restrição interna — modelo em que um único comprometimento entrega tudo.

As camadas, na prática

Seguindo o caminho de um atacante:

Identidade — SSO, MFA resistente a phishing, sem credencial permanente.
Rede — o que é exposto à internet, segmentação interna, negação por padrão.
Aplicação — validação de entrada, autorização por requisição, limite de taxa.
Workload — container sem root, sem capabilities, sistema de arquivos somente leitura.
Dados — criptografia em repouso e em trânsito, acesso mínimo, mascaramento.
Detecção — log de auditoria, alerta de comportamento anômalo.
Recuperação — backup imutável, testado, em conta separada.

O teste de cada camada é sempre o mesmo: se a anterior falhar completamente, esta segura? Se a resposta for não, ela não é uma camada — é decoração.

Preventivo, detectivo e corretivo

Uma classificação que ajuda a encontrar buracos:

Preventivo impede que aconteça: MFA, NetworkPolicy, política de admissão, RBAC.
Detectivo avisa que aconteceu: log de auditoria, alerta de anomalia, varredura, detecção de drift.
Corretivo limita e reverte o dano: rotação de credencial, isolamento do host, restore de backup, rollback.

Programas de segurança tendem a ser ricos em preventivo e pobres nos outros dois — e é aí que o tempo de exposição se estende por meses. A pergunta a fazer: quanto tempo levaria para percebermos, e quanto para reverter?

Onde as camadas se anulam

Camadas que parecem independentes e não são. É aqui que os programas de segurança falham com mais frequência:

Backup na mesma conta que produção. A credencial comprometida alcança os dois.
Log de auditoria gravável por quem opera o sistema auditado.
Segredo do cofre acessível pela mesma identidade que roda a aplicação, sem escopo.
MFA com fator recuperável por e-mail que só depende de senha.
Segmentação de rede com uma regra “permitir tudo do escritório”, e VPN para todos.
Cluster com política de admissão que qualquer administrador de namespace desliga.

Todas têm o mesmo formato: duas camadas que compartilham o mesmo ponto de falha. Ao desenhar, procure o denominador comum — uma credencial, uma conta, uma pessoa.

Raio de explosão

O conceito que amarra tudo. Para cada componente, pergunte: se este for comprometido, o que o atacante alcança?

Um Pod comprometido tem: token da ServiceAccount, acesso à rede interna, variáveis de ambiente, volumes montados e, se não estiver bloqueado, o endpoint de metadados do provedor — que pode entregar credencial da instância. Reduzir esse alcance é o trabalho: sem token montado quando não se usa, NetworkPolicy negando por padrão, segredo montado só onde é necessário, metadados bloqueados.

O mesmo raciocínio vale em escala maior, e é o principal argumento da landing zone: separar contas e ambientes é a forma mais barata de limitar o alcance de qualquer comprometimento.

O limite honesto

Camadas custam. Cada uma adiciona configuração, diagnóstico mais difícil e um lugar a mais para errar — e uma camada mal configurada pode causar indisponibilidade sem impedir ataque nenhum.

Também existe o risco do teatro: acumular controles porque estão numa lista, sem modelo de ameaça que justifique. Cinco camadas contra um adversário que não existe, e nenhuma contra o phishing que vai acontecer.

Por isso, defesa em profundidade não substitui priorização. Comece pelo modelo de ameaça, escolha poucas camadas com alto retorno, verifique que elas realmente são independentes, e só então acrescente. Duas camadas eficazes e testadas valem mais que sete que ninguém validou.