Gerenciamento de segredos

Gerenciamento de segredos

1) Porquê e exatamente o que achamos «segredo»

Segredo - Qualquer material cuja divulgação comprometa o sistema ou dados: senhas, API-tokens, OAUTH/JWT private keys, chaves SSH, certificados, chaves de criptografia (KEK/DEK), chaves de assinatura de webhooks, banco de dados DSN/cachê, chaves de fornecedores (pagamentos, provedores de correio )/SMS), cookie-sal/pepper, tokens bots/bate-papos, licenças.
Segredos são vividos em código, configh, ambiente, imagens de contêineres, CI/CD, Terraform/Ansable, logs/dampas - a tarefa de gerenciar segredos: registro armazenamento entrega uso rotatividade revisão reciclagem.

2) Princípios da arquitetura

Centralização. Uma camada de confiança (Vault/Cloud Secret Management/KMS) para armazenamento, emissão e auditoria.
Os menores privilégios (PoLP). Acesso somente aos serviços/papéis desejados, por um período mínimo.
Uma vida curta. Segredos dinâmicos/temporais preferidos com TTL/lease.
Crypto-agility. Alteração de algoritmos/comprimentos de chave sem interrupção.
Separando segredos de código/imagem. Nem senhas nos repositórios, nem imagens Docker.
Observação e auditoria. Cada operação de emissão/leitura de segredos é logada e aumentada.
Rotatividade automática. Rotação é um processo em pipeline, não uma ação manual.

3) Soluções e papéis típicos de componentes

KMS/HSM. Credibilidade raiz, criptografia/embrulho de chave (envelope).
Secret Manager/Vault. Armazenamento de versões de segredos, LCA, auditoria, segredos dinâmicos (DB, cloud-IAM, PKI), modelos de rotação.
PKI/CA. Emite certificados mTLS/SSH/JWT de curta duração.
Agente/sidecar. Entrega de segredos em Rantaim (arquivos tmpfs, in-memory k/v, hot-reload).
Drivers/operadoras CSI. Integração com o Kubernetes (Secret Store CSI Driver, cert-management).
Camada de criptografia em Git. SOPS/age, git-crypt (para código de infraestrutura).

4) Classificação e política

• TTL/lease e rotatividade;
• método de emissão (dinâmica vs estático), formato, mídia;
• política de acesso (quem/onde/quando/porquê), requisitos de mTLS e autenticação mútua;
• auditoria (que logamos, quanto guardamos, quem revê);
• os procedimentos de break-glass e a revisão.

5) Ciclo de vida de segredo

1. Criação: através do API Secret Gerente com metadados (owner, tags, scope).
2. Armazenamento: encriptado (envelope: DEK envolto em KEK/HSM).
3. Entrega: a pedido de um sujeito autorizado (OIDC/JWT, SPIFFE/SVID, mTLS).
4. Uso: exclusivamente na memória/tmpfs; a proibição de logs/dampos.
5. Roteiro: por TTL ou evento (comprometimento); suporte a versões paralelas (N-1).
6. Revogação/bloqueio: caducidade imediata do lease, contábil/chave no sistema de destino.
7. Reciclagem: destruição de versões/material, cadeia de auditoria clara.

6) Segredos dinâmicos (recomendado por padrão)

• Credenciais da Base de Dados (Postgres/MySQL) com TTL 15-60 min.
• Chaves temporárias de nuvem (AWS/GCP/Azure) por função do serviço.
• Certificados SSH (prazo de 5 a 30 min), certificados X.509 (hora/dia).
• JWT temporário para assinatura de solicitações, sessão-tickets corretores.
• Os benefícios são um mínimo de blast radius, uma crítica simplificada (nada vai «ficar» no mundo).

7) Entrega de segredos no Runtaim

• Secret Store CSI Driver → a montagem de segredos de um gerente externo para pod como arquivos (tmpfs).
• Evitar Kubernetes Secret como única fonte (base64 ≠ criptografia); se necessário, ative o provedor KMS para o etCD.
• Agente Sidecar com lease e hot-reload.
• VM/Bare metal: agente de sistema + mTLS para Vault/Secret Gestor, kesh na memória, TCB mínimo.
• Serverless: integração de nuvem com substituição transparente de segredos como variáveis ambiente/arquivo, mas evitar envvars de longa duração - preferencialmente arquivos/memória.

Exemplo (Kubernetes + CSI, conceitualmente)

yaml apiVersion: v1 kind: Pod metadata: { name: app }
spec:
serviceAccountName: app-sa # is associated with a role in Secret Manager volumes:
- name: secrets csi:
driver: secrets-store. csi. k8s. io readOnly: true volumeAttributes:
secretProviderClass: app-spc containers:
- name: app volumeMounts:
- mountPath: /run/secrets name: secrets readOnly: true

8) Integração CI/CD e IaC

CI: Os workers recebem tocadores de alta duração através do OIDC (Workload Identity). Proibição dos segredos «mascarados» que entram nos logs; passo «escavação» (trufflehog/gitleaks).
CD: A depilação tira os segredos no momento do lançamento, não os registra nos artefatos.
IaC: O Terraform armazena variáveis no Secret Gerente; o estado (state) é encriptado e limitado por acesso.
SOPS/age: Para o repo, armazenar manifestos criptografados, chaves com KMS.

Exemplo (fatia SOPS)

yaml apiVersion: v1 kind: Secret metadata: { name: app }
data:
PASSWORD: ENC[AES256_GCM,data:...,sops:...]
sops:
kms:
- arn: arn:aws:kms:...
encrypted_regex: '^(data    stringData)$'
version: '3. 8. 0'

9) Políticas de acesso e autenticação de cargas de trabalho

Workload identity: SPIFFE/SPIRE, Kubernetes SA→OIDC→IAM-роль, mTLS.
Tocas temporárias: TTL curto, scope estreito.
ABAC/RBAC no Secret Gerente: «quem pode ler o segredo X no ambiente Y» está separado de «quem pode criar/rotular».
Multiplicidade: namespaces/key-rings por locador; políticas e relatórios individuais.

10) Rotação, versões e compatibilidade

Divida o ID de segredo e sua versão ('secret/app/db # v17').
Suporte duas versões ativas (N e N-1) para rotação sem interrupção.
Rotação é um evento, com demissão, comprometimento, mudança de provedor, migração de algoritmos.
Automatize: cron/backend rotativo em Vault/Secret Management + webhook desencadeadores de reinício de aplicativos/renal.

Mini-receita «duplo» rotação webhook

text
T0: we publish two secrets in the provider: current, next
T1: the application starts accepting signatures by both current and next
T2: external system switches signature to next
T3: we do next -> current, re-release new next

11) Armazenamento fora do rating: cópias de segurança e artefactos

Nunca entrar em artefatos (imagens, arquivos de logs, dampos).
Backaps Secret Gerente - criptografar, chaves de armazenamento fora do mesmo circuito (separação of duties).
Marcas e scans DLP: detecção de segredos em S3/Blob/GCS, Git, artefatos CI.

12) Observabilidade, auditoria e SLO

Métricas: número de emissões/segredo/serviço, proporção de lease vencida, média TTL, tempo de rotação, tempo de convergência (segundos/minutos antes da «adoção» da nova versão).
Auditoria-logs: quem/o/o/o/o/o/o/o/porquê; armazenamento separado, também encriptado.
SLO: 99% das emissões <200 ms; 0 fugas nos logs; 100% dos segredos têm owner/TTL/tags; 100% dos segredos críticos são dinâmicos ou rotativos ≤ 30 dias.
Alerts: segredo expira <7 dias (para estáticos), aumento de falhas de autenticação para armazenamento, nenhuma leitura de segredo> N dias (morto), fontes geo/ASN inesperadas.

13) Erros frequentes e como evitá-los

Segredos em Git/imagens. Use SOPS/age e scanners; A política é proibir linhas nuas.
Envvars como um hospedeiro de longo prazo. Dê preferência aos arquivos tmpfs/in-memory; limpa o ambiente com fork/dampas.
Segredos iguais para dave/estágio/prod. Divida por ambiente.
Senhas estáticas de longa duração. Passe para dinâmica/curta duração.
Uma única chave mestre para tudo. Divida por locatários/projetos/serviços.
Não há hot-reload. O aplicativo requer uma janela de restrição de vulnerabilidade na rotação.

14) Exemplos de integração (esquematicamente)

Acesso dinâmico ao Postgres Vault

hcl
Vault: role -> issues the user to the database with TTL 30m and privileges only to the app path "database/creds/app-role" {
capabilities = ["read"]
}
Application requests/database/creds/app-role -> receives (user, pass, ttl)

Assinatura de solicitação JWT (breve prazo)

A chave privada é armazenada no Secret Gerente; o serviço pede um sinal-token de curta duração e o agente local assina um payload (a chave não é transmitida para o aplicativo como uma linha).

certificados SSH para almirantes

Emissão de SSH-cert por 10 minutos por SSO (OIDC), sem distribuição de chaves permanentes.

15) Segurança nas bordas

Logs/trailers/métricas: sanitários, filtros para chaves conhecidas/pattern; campos «secretos» - camuflagem em APM.
Dampas/repostos de crash: desligar por omissão; se for preciso, criptografar e limpar.
Aplicativos de cliente/mobile: Minimizar segredos off-line, usar armazenamento de plataforma (Keychain/Keystore), referência ao dispositivo, pinning TLS.

16) Complaens

PCI DSS: proibição de armazenamento de segredos PAN/sem criptografia; controle rigoroso de acesso e rotatividade.
ISO 27001/SOC 2: requisitos de gerenciamento de ativos, registro, controle de acesso, alteração de configurações.
GDPR/reguladores locais: minimização, acesso, auditoria.

17) Processos e runbook

Entrada em funcionamento

1. Inventário de segredos (repositórios, CI, imagens, runtime, bacapes).
2. Classificação e tags (owner, ambiente, tenant, rotation-policy).
3. Escolha de armazenamento (Vault/Cloud SM) + integração com KMS/HSM.
4. Configurar a emissão por workload identity (OIDC/SPIRE).
5. Incluir segredos dinâmicos para BD/nuvens/PKI.
6. Roteiro automático e hot-reload; Alertas na exportação.
7. Configurar scanners de vazamento e Data Catalog/DC.

Cenários de emergência

Suspeita de fuga: lista de acesso parada, rotação imediata, revogação de certificados/chaves, reencaminhamento de tokens, ativação de auditoria avançada, RCA.
O Secret Gerente não está disponível: espaço de memória local com TTL pequeno, degradação de funções, limitação de novas conexões, passos de break-glass manual.
Comprometimento da chave raiz: regeneração key-hierarchy, rewrap de todos os DEK, verificação de todas as transferências por janela de risco.

18) Folhas de cheque

Antes de vender

• Os segredos foram removidos do código/imagem; os scanners de fuga estão ativados.
• Os mecanismos dinâmicos estão incluídos para segredos críticos.
• Entrega via sidecar/CSI/tmpfs com hot-reload, sem envvars duradouros.
• Políticas IAM/ABAC configuradas, associadas a workload identity.
• Rotatividade automática e duplas versões (N, N-1) para compatibilidade.
• Métricas/alertas/auditoria incluídas; testes de degradação superados.

Operação

• Relatório mensal: proprietários, TTL, segredos vencidos, não utilizados.
• Rotações periódicas e pentestais de rotas de fuga (logs, dampos, artefatos).
• Plano de crypto-agility e substituição de emergência da SA/raiz.

19) FAQ

Em: O Secret Gerente é suficiente sem KMS?
O: Para o nível básico sim, mas é melhor usar criptografia envelope: KEK em KMS/HSM, segredos - enrolados. Isso facilita a crítica e a complacência.

Em: O que escolher é estático ou dinâmico?
O padrão é dinâmico. Deixe o status apenas onde não houver provedores suportados e queime a TTL até dias/horas + rotação automática.

Como é seguro colocar segredos na microssérie?
О: Workload identity → mTLS к Secret Manager → sidecar/CSI → файлы в tmpfs + hot-reload. Sem logs, sem envvars «para sempre».

Em: É possível guardar segredos em Kubernetes Secret?
O: Somente com a criptografia do etCD com o KMS ativada e com políticas rígidas. Prefira armazenamento externo e CSI.

Como apagar o acesso do inquilino?
Ah: Retirar/bloquear suas políticas no Secret Gerente, inválir todos os leases, rotação/regeneração de chaves; ao usar o KMS - desativar a unwrap correspondente ao KEK.

• Criptografia At Rest
• Criptografia In Transit
• Gerenciamento de chaves e rotação
• Autenticação S2S
• «Assinatura e verificação de solicitações»