ATALAIAA maioria dos conjuntos de políticas de segurança é escrita para auditores e lida por mais ninguém. Têm dezenas de páginas, descrevem ferramentas que foram substituídas há dois anos e são atualizadas à pressa antes de cada certificação. Os engenheiros aprendem que as políticas são algo que lhes acontece uma vez por ano.
Achamos que isso está ao contrário. Uma política só é útil se as pessoas que constroem e operam os sistemas a conseguirem ler em poucos minutos, reconhecerem nela o seu próprio trabalho e virem que é verificada automaticamente. Eis como as escreveríamos.
Curto vale mais que completo
Uma boa política de engenharia cabe num ecrã. Diz o que tem de ser verdade, quem é o responsável e como vai saber. Deixa o como para standards e runbooks, que podem mudar sem uma revisão da política.
Policy: Source code changes
Owner: Head of Engineering
Applies to: all repositories that build or deploy production software
1. Changes to default branches go through a pull request.
2. At least one reviewer who is not the author approves the change.
3. Secrets are never committed; CI blocks commits that contain them.
4. Exceptions are recorded with an owner and an expiry date.
Checked by: branch protection export and CI job results, monthly.É essa a política toda. Qualquer pessoa percebe num minuto se o seu repositório cumpre. Uma versão longa, com contexto, definições e nomes de ferramentas, pertence a um standard separado que remete para aqui.
Mapear declarações para controlos
Cada linha numerada de uma política deve corresponder a pelo menos um controlo, e cada controlo a um responsável e a uma verificação. Se uma linha não tem controlo por trás, acrescente um ou apague a linha.
| Linha da política | Controlo | Dono | Verificação |
|---|---|---|---|
| As alterações passam por um pull request | Proteção de branches nas branches por omissão | Equipa de plataforma | Exportação pela API do controlo de versões |
| Revisão independente | Aprovações obrigatórias, sem autoaprovação | Equipa de plataforma | A mesma exportação, definições de revisão |
| Sem secrets em commits | Gitleaks na CI, push protection | Segurança | Resultados dos jobs de CI por repositório |
| Exceções registadas | Registo de exceções com expiração | Segurança | Revisão do registo, itens expirados sinalizados |
Esta tabela é também aquilo que os auditores querem realmente ver. Mostra design, responsabilidade e operação num só sítio.
Evidências do pipeline, não screenshots
A pior parte da maioria das auditorias é a recolha de evidência: capturas de ecrã de páginas de definições, reunidas à mão, verdadeiras numa tarde. As suas plataformas já sabem as respostas. Pergunte-lhes de forma agendada e guarde o output.
- RecolherUm job agendado consulta as APIs do controlo de versões, do CI e da cloud para obter as definições de que cada controlo depende.
- AvaliarOs resultados são comparados com a política, produzindo aprovado, falhado ou exceção por ativo.
- GuardarO output em bruto e os resultados são escritos num bucket append-only, com uma data no caminho.
- ReportarOs responsáveis veem as falhas como tickets; os auditores veem o histórico.
# evidence: default-branch protection, one JSON file per run
gh api repos/your-org/payments-api/branches/main/protection \
> "evidence/$(date -u +%F)/payments-api-branch-protection.json"Quando as evidências vêm da própria linha, a política deixa de ser um documento e passa a ser um conjunto de verificações com um dono.
Onde entram os frameworks
As equipas costumam partir de um framework e descer até à política. Normalmente é mais fácil ao contrário. O SOC 2 e a ISO 27001 esperam ambos políticas documentadas, responsabilidades atribuídas e evidência de que os controlos funcionam ao longo do tempo. A NIS2 traz obrigações de gestão de risco e de reporte de incidentes para as organizações no seu âmbito. O EU Cyber Resilience Act acrescenta requisitos para produtos com elementos digitais, incluindo gestão de vulnerabilidades e desenvolvimento seguro durante todo o período de suporte do produto.
Políticas curtas e mapeadas, com evidências automáticas, servem todos estes, porque todos recompensam a mesma coisa: controlos que comprovadamente funcionam. Se um determinado framework se aplica a si, e o que exige exatamente, é uma questão para os seus consultores jurídicos e de compliance. Este artigo não é aconselhamento jurídico.
O que faríamos
- Escolha as suas três políticas mais importantes, tipicamente alterações ao código-fonte, gestão de acessos e tratamento de vulnerabilidades, e reescreva cada uma para caber num ecrã.
- Construa a tabela de mapeamento para esses três. Apague qualquer linha que não tenha controlo.
- Automatize uma verificação de evidências este mês, guarde o resultado com data e mostre-o ao responsável.
- Defina uma data de revisão em cada política e ponha-a num calendário, não no rodapé do documento.
Quando os engenheiros conseguem ler a política, ver a verificação e corrigir a falha sozinhos, a auditoria passa a ser uma revisão de trabalho já feito.
Onde isto fica na linha
Na torre (em desenvolvimento):