0Pricing
Cyber Security Academy · Aula

Cofres e armazenamentos de segredos

Centralize segredos com ferramentas como o Vault.

Cofres e armazenamentos de segredos é uma aula grátis de Cyber Security Academy no CoddyKit. Esta é a aula 2 de 4. Você pode ler a aula completa abaixo gratuitamente — depois pratica ao vivo no navegador com um editor de código integrado e um tutor de IA 24/7. Faz parte do caminho de aprendizado de Cyber Security Academy, e seu progresso é sincronizado entre a web e o app CoddyKit. O curso de Cyber Security Academy inclui 4 aulas no total.

O que um repositório de secret resolve

Um repositório de secret (ou cofre) é um serviço centralizado e protegido cuja única função é armazenar secrets e controlar e auditar o acesso a eles. Ele substitui os arquivos dispersos e as variáveis de ambiente que causam proliferação.

Um bom gerenciador de segredos oferece quatro recursos essenciais:

  • Armazenamento centralizado uma única fonte de verdade autorizada.
  • Controle de acesso políticas detalhadas sobre quem e o que pode ler cada secret.
  • Registro de auditoria um registro de cada acesso para resposta a incidentes.
  • Criptografia secrets criptografados em repouso e em trânsito.

Alguns exemplos são HashiCorp Vault, AWS Secrets Manager, Azure Key Vault e GCP Secret Manager.

Como o HashiCorp Vault é estruturado

O HashiCorp Vault é um gerenciador de segredos de código aberto bastante popular. Ele organiza as funcionalidades em mecanismos de secrets montados em caminhos.

  • Mecanismo KV armazena secrets estáticos de chave-valor.
  • Mecanismo de banco de dados gera credenciais dinâmicas e de curta duração para bancos de dados.
  • Mecanismo PKI emite certificados TLS sob demanda.
  • Mecanismo Transit oferece criptografia como serviço sem expor as chaves.

Você interage com o Vault por meio de uma interface HTTP ou da CLI. Cada caminho é regido por políticas que determinam quem pode ler ou escrever nele.

# Enable a KV v2 secrets engine at the 'secret/' path
vault secrets enable -path=secret kv-v2

# Write and read a static secret
vault kv put secret/app/db password='S3cr3t' user='app'
vault kv get secret/app/db

O modelo de selagem e desselagem

O Vault protege seus dados com um mecanismo de selagem e desselagem. Quando o Vault é iniciado, ele está selado: sabe onde estão os dados criptografados, mas não consegue descriptografá-los.

A chave mestra que descriptografa o armazenamento é, por sua vez, criptografada por uma chave de desselagem. Usando o compartilhamento de secrets de Shamir, essa chave de desselagem é dividida em vários fragmentos distribuídos entre diferentes operadores.

Um limiar configurável, como 3 de 5 fragmentos, deve ser fornecido para reconstruir a chave e desselar o Vault. Ninguém consegue desselá-lo sozinho, o que protege contra o comprometimento interno.

# Initialize Vault: 5 key shares, threshold of 3 to unseal
vault operator init -key-shares=5 -key-threshold=3

# Each operator supplies one shard until threshold is met
vault operator unseal <shard-1>
vault operator unseal <shard-2>
vault operator unseal <shard-3>

Autenticação: quem é você?

Antes de ler qualquer secret, um cliente deve autenticar-se para obter uma credencial de acesso. O Vault oferece muitos métodos de autenticação adaptados a diferentes identidades:

  • AppRole para aplicações e sistemas de integração contínua, com ID da função e ID do secret.
  • Kubernetes usa a credencial da conta de serviço do pod.
  • AWS/GCP/Azure IAM confia na identidade da plataforma de nuvem.
  • OIDC/LDAP para usuários humanos por meio de SSO.

O princípio fundamental é: a identidade vem da plataforma, não de uma senha de longa duração. Um pod do Kubernetes prova quem é usando a própria credencial da conta de serviço; não há nenhum secret inicial para vazar.

# App authenticates via AppRole to receive a token
vault write auth/approle/login \
  role_id="db-app-role" \
  secret_id="$WRAPPED_SECRET_ID"
# Response includes client_token used for subsequent reads

Autorização com políticas

A autenticação comprova a identidade; as políticas determinam o que essa identidade pode fazer. As políticas do Vault são escritas em HCL e seguem o princípio do menor privilégio, concedendo apenas os caminhos e recursos de que uma carga de trabalho precisa.

Esta política permite que um serviço leia apenas seu próprio secret de banco de dados e nada mais:

As capacidades correspondem aos verbos da interface: read, create, update, delete e list. Negue por padrão; conceda explicitamente.

# policy: billing-app.hcl
path "secret/data/billing/*" {
  capabilities = ["read"]
}
path "database/creds/billing-readonly" {
  capabilities = ["read"]
}
# everything else is implicitly denied

Repositórios de secrets nativos da nuvem

Se você opera em uma única nuvem, o repositório gerenciado do provedor elimina a sobrecarga operacional: sem selagem ou desselagem, sem servidores para corrigir:

  • AWS Secrets Manager integra-se ao IAM e oferece funções Lambda integradas para substituição.
  • Azure Key Vault armazena secrets, chaves e certificados com RBAC.
  • GCP Secret Manager oferece secrets versionados protegidos por associações do IAM.

O acesso é governado pelo IAM da nuvem, portanto uma carga de trabalho lê um secret usando sua função existente; não é necessária uma senha separada. A desvantagem é a dependência do fornecedor e um suporte inferior a várias nuvens em comparação com o Vault.

# Read a secret from AWS Secrets Manager (workload uses its IAM role)
aws secretsmanager get-secret-value \
  --secret-id prod/billing/db \
  --query SecretString --output text

# GCP equivalent
gcloud secrets versions access latest --secret=billing-db

Criptografia como serviço

Às vezes, você não quer armazenar um secret de forma alguma: quer criptografar dados da aplicação sem que sua aplicação jamais mantenha a chave de criptografia. O mecanismo Transit do Vault faz exatamente isso.

A aplicação envia texto simples ao Vault, recebe texto cifrado de volta e nunca vê a chave. A descriptografia funciona da mesma forma. Isso é chamado de criptografia como serviço.

A vantagem é que as chaves vivem apenas dentro do Vault, podem ser substituídas centralmente e uma aplicação comprometida não consegue vazar uma chave que nunca possuiu.

# Encrypt data without the app ever seeing the key
vault write transit/encrypt/orders-key \
  plaintext=$(echo -n 'card=4111...' | base64)
# returns: ciphertext=vault:v1:abc123...

# Decrypt later
vault write transit/decrypt/orders-key ciphertext='vault:v1:abc123...'

Injetando secrets em cargas de trabalho

Um cofre só é útil se as aplicações puderem consumir secrets sem codificar diretamente o caminho ou a credencial. Padrões comuns de injeção:

  • Processo auxiliar/agente um Vault Agent é executado junto à aplicação, autentica-se e grava secrets em um volume compartilhado na memória.
  • Controlador CSI o Kubernetes monta secrets como arquivos por meio do controlador CSI do armazenamento de secrets.
  • Busca via SDK a aplicação chama diretamente a interface do cofre durante a inicialização.

Prefira montar em um sistema de arquivos na memória (tmpfs) em vez de usar variáveis de ambiente e evite gravar secrets no disco, onde eles podem permanecer.

# Vault Agent template renders a secret to an in-memory file
template {
  contents = "DB_PASS={{ with secret \"secret/app/db\" }}{{ .Data.data.password }}{{ end }}"
  destination = "/run/secrets/db.env"
}

Registro de auditoria e responsabilização

Cada evento de leitura, gravação e autenticação em um cofre deve ser registrado em um registro de auditoria. É isso que torna o gerenciamento de segredos defensável durante um incidente.

Os registros de auditoria respondem às perguntas críticas: quem acessou qual segredo, quando e de onde. O Vault calcula o resumo criptográfico dos valores sensíveis nos registros para que o próprio registro não vaze segredos.

Envie os registros de auditoria para um sistema separado e que evidencie adulterações (SIEM), para que um invasor que comprometa o host do Vault não consiga também apagar as evidências do que acessou.

# Enable a file audit device (HMAC-hashes secret values)
vault audit enable file file_path=/var/log/vault/audit.log

# Forward to a SIEM/syslog endpoint for tamper resistance
vault audit enable syslog tag="vault" facility="AUTH"

Protegendo o próprio Vault

Um armazenamento centralizado concentra o risco: se o Vault for comprometido, tudo será comprometido. Reforce-o como seu ativo mais crítico:

  • Execute-o com TLS em todos os pontos de acesso; nunca exponha a API sem criptografia.
  • Mantenha o Vault em uma rede privada, protegida por regras rigorosas de firewall.
  • Habilite a deslacração automática por meio de um KMS na nuvem para evitar o manuseio manual dos fragmentos, mas proteja rigorosamente essa chave do KMS.
  • Use TTLs curtos para tokens e concessões renováveis, para que tokens roubados expirem rapidamente.
  • Instale correções prontamente e monitore os registros de auditoria em busca de anomalias.

O Vault troca muitos pontos de falha por um único ponto extremamente bem protegido.

Escolhendo o armazenamento adequado

Não existe uma única ferramenta ideal; escolha o armazenamento de acordo com seu ambiente:

  • Uma única nuvem, necessidades simples: use o gerenciador nativo (AWS/Azure/GCP) para reduzir a sobrecarga operacional.
  • Multicloud ou ambiente local: o HashiCorp Vault oferece uma abstração consistente e portável.
  • Precisa de segredos dinâmicos ou de criptografia como serviço: os mecanismos do Vault são os mais completos.
  • Ambiente fortemente baseado em Kubernetes: combine um armazenamento com o driver CSI ou com um operador como o External Secrets.

Seja qual for sua escolha, o objetivo é o mesmo: uma única fonte de verdade, auditada e com acesso controlado, substituindo o texto sem criptografia espalhado.

Verificação rápida

Teste sua compreensão do modelo de proteção do Vault.

Recapitulação: cofres e armazenamentos de segredos

Você aprendeu a substituir segredos espalhados por um armazenamento centralizado e auditado.

  • Um armazenamento de segredos oferece armazenamento centralizado, controle de acesso, registro de auditoria e criptografia.
  • O HashiCorp Vault usa mecanismos de segredos conectáveis e um modelo de lacração/deslacração protegido pelo Compartilhamento de Segredos de Shamir.
  • Os métodos de autenticação obtêm a identidade da plataforma (Kubernetes, IAM, AppRole), e as políticas impõem o privilégio mínimo.
  • Os armazenamentos nativos da nuvem (AWS, Azure, GCP) trocam portabilidade por baixa sobrecarga operacional.
  • O mecanismo Transit oferece criptografia como serviço, para que os aplicativos nunca mantenham as chaves.
  • Injete segredos por meio de agentes ou do CSI em um armazenamento na memória, registre cada acesso e reforce o Vault como seu ativo mais crítico.

Em seguida, tornaremos os segredos ainda mais seguros, gerando-os dinamicamente e com curta duração.

Perguntas Frequentes

A aula “Cofres e armazenamentos de segredos” é grátis?

Sim — o texto completo de “Cofres e armazenamentos de segredos” é grátis para ler aqui na web. Para praticá-la interativamente (um editor de código integrado e um tutor de IA 24/7) e desbloquear o restante do curso de Cyber Security Academy, atualize para CoddyKit PRO. O curso de Cyber Security Academy inclui 4 aulas no total.

O que vou aprender em “Cofres e armazenamentos de segredos”?

Centralize segredos com ferramentas como o Vault. Você pratica Cyber Security Academy com código prático que executa diretamente no navegador, e um tutor de IA 24/7 responde suas dúvidas enquanto trabalha na aula.

Preciso ter experiência prévia para começar Cyber Security Academy?

Nenhuma experiência prévia é necessária. Cyber Security Academy no CoddyKit é estruturado para alunos iniciantes até avançados, então você pode começar aqui ou desde o início e aprender no seu ritmo. Esta é a aula 2 de 4.

Quanto tempo leva a aula “Cofres e armazenamentos de segredos”?

A maioria das aulas CoddyKit leva cerca de 5–10 minutos. Cada uma é compacta e interativa, então você faz progresso constante e retoma exatamente de onde parou entre web e app.

Posso escrever e executar código nesta aula de Cyber Security Academy?

Sim. Cada aula de Cyber Security Academy inclui um editor de código integrado, então você escreve e executa código real direto no navegador e recebe feedback de IA instantaneamente — nenhuma configuração local necessária.

Todas as aulas deste curso

  1. O problema da proliferação de segredos
  2. Cofres e armazenamentos de segredos
  3. Segredos dinâmicos e concessão temporária
  4. Rotação e detecção de chaves
← Voltar para Cyber Security Academy