A nossa base WAF e OWASP, explicada
A segurança não devia ser um projeto que se começa depois do lançamento. Em cada instância Clonext, uma web application firewall gerida e uma base alinhada com o OWASP estão ligadas desde a primeira implementação — eis o que isso inclui na prática.
O que a WAF bloqueia
Na periferia, o Google Cloud Armor filtra cada pedido antes de ele chegar à sua aplicação — uma política gerida no balanceador de carga global da Google, para que o seu código nunca tenha de ser a última linha de defesa.
- Padrões do OWASP Top 10 — uma guarda aplicada contra as cargas clássicas de injeção e cross-site scripting, com os conjuntos de regras OWASP pré-configurados a avaliar cada pedido.
- Limites de tentativas no login, na periferia e na aplicação — as tentativas repetidas são bloqueadas antes de se tornarem força bruta.
- Exceções desenhadas por rota — os webhooks de pagamento e os editores avançados continuam a funcionar; nada é bloqueado por acidente.
- TLS com certificados geridos pela Google e HSTS, no seu próprio domínio.
Uma boa base é a segurança que recebe sem abrir um ticket para a ter.
OWASP como chão, não como teto
Os padrões OWASP dão-nos uma checklist comum, mas uma checklist é um ponto de partida. Ligamos cada controlo a algo concreto no core — gestão de sessões, codificação de saídas, política de dependências — e verificamo-lo no build, em vez de confiar que uma framework o fez por nós.
Afinado por instância
Como cada instância é isolada, podemos afinar regras ao seu tráfego sem pensar num vizinho. Um falso positivo na sua API é corrigido para si — não negociado através de um alojamento partilhado.
O edge completo à volta desta base — o balanceador global, DNSSEC, a porta por identidade — está contado em O edge da Google, explicado.
