Aprovações de Deploy

Regras claras sobre quem pode promover um build, com que funções, e que evidências vê antes de a produção desbloquear.

Marcar uma chamada →Percorrer a linha

Quatro ambientes, quatro portões

O que tem de estar verde antes de cada porta abrir, e quem a pode abrir.

DEVqualquer programador
- Testes unitários verdes
- SAST: sem bloqueadores
QAsó o pipeline
- Pack de testes de segurança verde
- Matriz de autorização aprovada
STAGINGfunção de release
- DAST limpo
- Sem descobertas altas de pentest em aberto
PRODfunção de aprovador + janela
- Imagem assinada com SBOM
- Revisão de IAM feita
- Ticket de alteração associado

Break-glass: expira em 2 horas, cada comando registado, revisto no dia útil seguinte.

No portão

Escolha um passo, ou deixe correr. Cada fala é o que alguém na sala diz de facto.

Passo 1Mapear quem pode fazer deploy

Pessoas, funções, tokens e pipelines que chegam a cada ambiente.

ATALAIAQuem pode fazer push para produção neste momento?

PLATAFORMATrinta e uma pessoas, e quatro tokens que ninguém se lembra de criar.

Sai da sala31 pessoas e 4 tokens chegam a prod

Passo 2Definir os portões

O que tem de estar verde em cada passo, e quem assina.

ATALAIACada passo tem um portão. QA exige testes verdes, prod exige uma função de aprovador.

DEV LEADUma função, não uma pessoa? As pessoas vão de férias.

ATALAIAUma função. Duas pessoas detêm-na, e o pipeline verifica.

Sai da salaDEV → QA → STAGING → PROD, portões definidos

Passo 3Anexar as evidências

Scans, testes e estado de revisão visíveis no momento da aprovação.

GESTORQuando aprovo, para o que estou realmente a olhar?

ATALAIAScans, testes e estado do pentest, na própria aprovação.

GESTORPentest verde, testes verdes. Aprovado para a janela das 14:00.

Sai da salaEvidências na aprovação

Passo 4Rever as chaves

Acesso à produção revisto antes de cada envio, e de forma periódica.

PLATAFORMAE o break-glass, quando prod está a arder?

ATALAIAFunciona, expira em duas horas e é revisto na manhã seguinte.

Sai da salaBreak-glass: 2 horas, registado, revisto

PLATAFORMA
ATALAIA
DEV LEAD
MANAGER

Antes e depois

Antes

Quando todos podem fazer deploy, ninguém aprova. Quando as aprovações são um clique sem evidências, são um atraso, não um controlo.

O acesso à produção é dado por pessoa, não por função
As aprovações não mostram resultados de testes, scans ou pentest
O acesso de emergência nunca expira

Depois

Um fluxo de promoção de DEV para QA, staging e prod
Aprovações por função com evidências anexadas
Acesso break-glass que expira e fica registado
Um checkpoint de revisão de IAM antes da release

Formato típico: duas a três semanas, muitas vezes em paralelo com a auditoria do pipeline.

A seguir na linha

Todas as estações reportam à mesma torre. Estas são as vizinhas.

Estação 09 · Release e testesRegistry e Assinatura

SBOM, proveniência, builds assinados

Ver a estação →Estação 11 · Release e testeTestes de Segurança em QA

Verificações que a sua equipa de QA pode assumir

Ver a estação →Estação 12 · Release e testePentest

Com âmbito, manual, retestado

Ver a estação →

Vamos conversar

Uma chamada de 30 minutos. Sem slides, sem tabela de preços, e um próximo passo em qualquer caso.

Marcar uma chamada →Percorra cada estação