O que costuma aparecer
- Segredos em repositório, em variável de ambiente copiada entre máquinas ou numa mensagem de chat.
- Contas de ex-colaboradores e de ferramentas que ninguém lembra de ter criado.
- Permissões largas demais: o serviço que só deveria ler um bucket e pode apagar a conta inteira.
- Banco, fila e painel acessíveis pela internet sem necessidade.
- Dependências com vulnerabilidade conhecida e meses sem atualização.
- Nenhum plano escrito para o dia em que algo der errado.
Começamos pelo que seria mais caro perder
Antes de listar vulnerabilidades, perguntamos o que machucaria mais: a base de clientes, o acesso ao painel de pagamentos, o código-fonte. Com isso na mesa, a revisão deixa de ser uma lista sem fim e passa a seguir o que realmente dói.
Dali em diante percorremos os caminhos que levam a esses ativos: quem tem acesso, por onde entra, o que fica registrado e o que acontece se uma credencial vazar hoje.
Depois da revisão
Os achados saem ordenados por gravidade e por facilidade de correção, e o que se resolve numa tarde fica separado do que pede projeto. Junto vai um roteiro curto de resposta a incidente: quem avisar, o que desligar primeiro, onde estão os logs.
Limites do trabalho
Não é teste de intrusão, nem certificação. Se você precisa de ISO 27001 ou SOC 2 para fechar um contrato, a revisão ajuda a chegar lá, mas o selo sai de outro processo.
Se o seu gargalo é a nuvem em si, veja também a página de infraestrutura.