O erro mais repetido
Quase todos os incidentes de segurança de origem interna começam da mesma forma: uma chave de acesso, um token ou uma palavra-passe que alguém deixou num ficheiro de configuração «só para testar». O repositório era privado, por isso parecia seguro. Mas um repositório clona-se, partilha-se, carrega-se para outros lugares e guarda o seu histórico para sempre. Apagar o ficheiro não apaga o segredo: continua no histórico.
Separar o nome do valor
A regra é simples e não tem exceções:
- No repositório (e no registo) escreve-se que segredos cada aplicação precisa, pelo seu nome: «a aplicação de encomendas precisa da palavra-passe da sua base de dados».
- Num gestor de segredos guarda-se o valor, cifrado, com controlo de quem o pode ler.
- Na implementação, a plataforma procura cada valor pelo seu nome e entrega-o à aplicação em execução. O valor nunca toca o repositório nem os registos.
O que vem com essa separação
- Rodar é fácil: muda-se o valor no gestor e reimplementa-se. O código não muda.
- Sabe-se quem acede: o gestor registra cada leitura.
- Cada ambiente tem os seus próprios valores com o mesmo nome, por isso o código é idêntico em desenvolvimento e em produção.
- O que não existe não se pode fugir: se alguém partilhar o repositório, partilha nomes, não chaves.
E uma verificação automática
Por muito clara que a regra seja, alguém a quebrará um dia por descuido. Por isso a plataforma revê cada mudança à procura de coisas com forma de segredo (chaves, tokens, palavras-passe) e rejeita-a antes de ser guardada. É mais barata uma recusa a tempo do que uma rotação de emergência.
Com o registo e os segredos resolvidos, falta a terceira fonte de verdade: a que conta o que aconteceu a cada aplicação.
Como o aplicamos: Engenharia de Plataforma.