Pular para o conteúdo
thiagoetipadrões

Contatos

apps/security/secrets-management

150 · Segurança & Auditoria · ≈ 6 min de estudo

Gerenciamento de Segredos

Centraliza credenciais num cofre (HashiCorp Vault) em vez de espalhá-las em .env e código. Cada serviço se autentica com a própria identidade, recebe um token de vida curta e lê só os caminhos que a sua política permite; segredos são versionados para rotação sem downtime e rollback; e toda requisição, permitida ou negada, vai para o audit log com os valores em HMAC.

passos
6
arquivos
5
testes
0
tecnologias
4
Infraestrutura realTypeScriptBunVaultDocker
CenárioRelaçõesComparar
Baixar cartão

Cenário

Os serviços de pagamentos e de relatórios guardam no Vault as credenciais dos seus bancos e a chave da API do BACEN. Pagamentos lê a credencial do PIX e recebe 403 ao tentar a do data warehouse de relatórios. A chave do BACEN é rotacionada para a v2 e a v1 continua legível para rollback; uma rotação feita a partir de uma leitura velha é recusada. Ao fim do job o serviço revoga o próprio token; o token de relatórios, com TTL de 2 s, morre sozinho.

Planta

Sequência
10/10
política payments: read secret/data/payments/*1AppRole payments (token_ttl 30s)2grava payments/pix-db v13POST auth/approle/login (role_id, secret_id)4token com lease de 30s5GET secret/data/payments/pix-db6v17GET secret/data/reports/warehouse-db8403, registrado no audit log9POST auth/token/revoke-self10Admin (setup)VaultServiço de pagamentos
10

10 passos — reproduza para seguir o fluxo

Como funciona

6 passos

Segredo no cofre, nunca no código.

Esconde cada passo: lembre antes de tocar para revelar.

  1. 01

    vaultSetup liga o audit device, a autenticação AppRole, uma política por serviço (só read no próprio caminho) e um papel com token_ttl

  2. 02

    O serviço faz login com role_id e secret_id e recebe um token com lease; a janela de exposição é o TTL, não a vida do processo

  3. 03

    secretRead lê a versão atual ou uma específica; fora da política o Vault responde 403 e registra a tentativa

  4. 04

    secretWrite grava nova versão com check-and-set na versão atual: nada é sobrescrito, e escritor com leitura velha é recusado

  5. 05

    serviceLogout revoga o token ao fim do job, sem esperar o TTL

  6. 06

    Nenhum valor é logado pela aplicação — só caminho e versão; no audit log do Vault os valores saem em HMAC

Trade-offs

O que se ganha, o que se paga

4 vantagenscada ganho tem um preço4 custos

Vantagens

  • Um lugar para rotacionar e auditar todas as credenciais

  • Política por caminho dá a cada serviço só o que ele usa

  • Token de vida curta limita a janela de um vazamento

  • Versões e CAS permitem rollback e barram escrita concorrente

Custos

  • O Vault vira dependência crítica: fora do ar, serviços não sobem

  • Políticas e papéis precisam ser mantidos a cada serviço novo

  • O secret_id do AppRole ainda precisa chegar ao serviço com segurança

  • Segredo lido fica na memória do processo e aparece em dump

apps/security/secrets-management

5 arquivos

src/

  • vault_admin.tsSetup: audit device, AppRole, políticas, papéis e escrita versionada com CAS
  • vault_service.tsLado do serviço: login AppRole, leitura por versão e revogação do token
  • vault_http.tsChamada à API HTTP do Vault e o 403 como ErrorVaultDenied
  • config_secrets.tsConfiguração validada do ambiente
  • demo.tsdemoLeitura permitida e negada, rotação e rollback, revogação e expiração

Executar · com Docker

  1. ./docker.sh up# sobe Vault
  2. cp .env.example .env# variáveis de ambiente
  3. bun install# dependências
  4. bun run demo# roda o cenário
  5. bun run test# integração contra o serviço real
  6. docker exec secrets-management-vault cat /vault/logs/audit.log
Requisitos
BunDocker
Sobe junto
Vault

Relações

Onde ele se encaixa

Mapa
  1. Secrets Management
  • Combina com5

Por que se relacionam

Combina com

Teste rápido

Qual destes combina com Secrets Management?

Próximo projeto · Segurança & AuditoriaValet Key
Esc

↑ ↓ navegarEnter abrir191 resultados