Liberar sem medo na infraestrutura própria

O que a norma exige, e o que não exige

Muitas instituições mantêm sistemas e dados em infraestrutura própria, por causa do modelo de risco, dos contratos ou dos sistemas legados. Não são minoria: na pesquisa de 2024 da CNCF, 59% dos participantes usam infraestrutura própria autogerenciada, o mesmo que nuvem pública autogerenciada (750 participantes da comunidade). Operar em casa não é desculpa para liberar sem disciplina.

Uma precisão que convém ter clara diante de qualquer comitê: em geral, a regulamentação mexicana não impõe que a infraestrutura esteja em casa. As disposições da CNBV para bancos admitem infraestrutura própria ou de terceiros, inclusive no exterior, com requisitos que dependem do serviço: aviso ou autorização prévia, continuidade diante de falhas do provedor e acesso da autoridade à informação. A lei de dados pessoais também não fixa uma localização obrigatória, embora estabeleça condições para o tratamento e as transferências. O detalhe se valida para cada entidade e cada serviço.

O que esses marcos pedem, sim, é que se demonstre controle: evidência e rastreabilidade proporcionais ao risco. Ter a infraestrutura em casa não garante isso. O que muda é a responsabilidade: em casa, todo o controle e toda a mitigação são da própria instituição. Se o caminho até a produção estiver bem feito, esse controle se demonstra com evidência e não com promessas.

A infraestrutura atual permite demonstrar esse controle com a mesma disciplina de uma nuvem pública? Nuvem e infraestrutura

O que já vem inseguro de fábrica

Um cluster que passa nos testes funcionais pode reprovar numa auditoria de segurança se mantiver a configuração de fábrica. Segundo a documentação oficial do Kubernetes e o guia de endurecimento da NSA e da CISA, várias coisas vêm assim por padrão:

• Os segredos são guardados sem criptografia no banco do cluster.
• O registro de auditoria está desligado.
• Os namespaces não isolam a rede: sem políticas explícitas, tudo fala com tudo.
• Em clusters criados com kubeadm, os certificados de cliente vencem em um ano por padrão. São renovados com as atualizações ou com um procedimento explícito; se ninguém o fizer, o cluster deixa de responder num dia qualquer.

E há um físico que quase ninguém mede: o armazenamento de estado do cluster (etcd) é muito sensível à latência do disco. O guia de hardware do etcd dá como referência 50 operações sequenciais por segundo, e 500 para clusters com carga, e recomenda disco de estado sólido. Com latência alta ou muito variável, o sintoma não é “está lento”: são tempos de espera esgotados, eleições de líder e quedas de disponibilidade. Mede-se com testes de carga representativos, antes da produção.

Alguém da equipe saberia dizer hoje, sem procurar, quando vencem os certificados do cluster?

Um só caminho até a produção

Da mudança do programador até a produção, tudo passa pelo mesmo caminho, e cada portão pode interromper a liberação:

1. Testes que freiam. Os testes obrigatórios bloqueiam a promoção; os sinais inconclusivos são registrados e tratados com uma política explícita. Para uma emergência há um procedimento de exceção, com aprovação e rastro.
2. Qualidade com o motivo à vista. O portão não se contenta com “terminou bem”: diz qual condição falhou.
3. Varredura por categorias: código, dependências, segredos expostos, imagens e configuração, com limites e exceções rastreáveis. E distingue “encontrou algo” de “não terminou de verificar”: as duas coisas interrompem a liberação.
4. Construir uma vez, promover o mesmo. O que foi testado é o que chega à produção; não se recompila por ambiente. A configuração e os segredos de cada ambiente são controlados à parte, com versão e rastro.
5. Falhar cedo e com clareza. Se faltar algo ao servidor de construção, ele falha no primeiro passo dizendo o que falta.

O que o processo verifica hoje antes de chegar à produção, e o que deixa passar sem que ninguém perceba? DevSecOps

Sem internet, o scanner também envelhece

Numa rede isolada, a parte mais descuidada é a mais silenciosa: a base de vulnerabilidades do scanner. Se ninguém a atualiza, o scanner continua dizendo “sem achados” porque não conhece o que é novo. Algumas ferramentas se recusam a rodar com uma base de mais de cinco dias; outras seguem no verde com a base congelada. Um caminho isolado bem feito traz o próprio espelho dessas bases, com data visível e um alerta quando ela envelhece.

O scanner conhece as vulnerabilidades publicadas esta semana? DevSecOps

Três destinos, o mesmo critério

Os portões e a evidência se reaproveitam entre destinos; cada destino mantém os próprios requisitos de implantação, identidade, monitoramento e recuperação, e passar para Kubernetes exige redesenhar vários deles.

Qual dos três é o da empresa hoje, e qual deveria ser em dois anos?

Falhas que vemos com frequência

• Processos de liberação duplicados e sem governança. Quando cada equipe mantém a própria cópia, as cópias divergem em silêncio e a evidência deixa de ser comparável. Melhor um único molde compartilhado e versionado.
• Instalar à mão a partir da ferramenta de construção. Misturar “quem constrói” com “quem instala” deixa mudanças sem rastro. Melhor separá-los e descrever o ambiente como código.
• Exceções temporárias que se tornam permanentes. Um controle omitido “só em desenvolvimento” é o que depois falha em produção.
• Identidades soltas. O diretório próprio do orquestrador, separado do da empresa, acumula contas órfãs com privilégios altos (NIST SP 800-190).

Outros controles que costumam ser relevantes —gestão de segredos, assinatura e inventário do que se libera, aprovação humana para produção, segregação de funções, recuperação e retenção— se definem conforme o modelo de risco.