Fortress — vault de alta segurança

Fortress é um vault paralelo aos Secrets normais, projetado para credenciais de criticidade extrema (chaves master de produção, credenciais de root, chaves PIX, JWKs de assinatura).

A diferença para Secrets é que Fortress aplica 8 camadas criptográficas a cada valor — o trade-off é: leitura mais cara (reconstrução Shamir + multi-decrypt), em troca de garantias muito mais fortes contra exfil parcial.

As 8 camadas

#	Camada	Propósito
1	Shamir Secret Sharing 3-of-5	Plaintext dividido em 5 shards; 3 reconstroem. Vazamento parcial não compromete
2	Blind Index HMAC-SHA256	Busca por valor ou nome sem decriptar
3	KMS envelope encryption (pluggable)	Local (default) ou AWS KMS — DEK único por shard
4	HKDF-SHA256 + Pepper	Chave contextual derivada de DEK ‖ pepper, info bound ao contexto (tenant + service + env)
5	AES-256-GCM com AAD	Camada 1 autenticada por tenant + context + shard + version
6	Layer 2 AES-GCM	Tenant key isolation (opt-out via FORTRESS_MULTI_LAYER=false)
7	Versionamento imutável	INSERT-only em fortress_secret_versions; preserva histórico completo para rollback/auditoria
8	Armazenamento segregado	Shards em fortress_shards, metadata em fortress_secrets, histórico em fortress_secret_versions, blind indexes inline

Quando usar

Critério	Secret normal	Fortress
Latência de leitura	ms	dezenas de ms
Custo computacional	baixo	alto (Shamir + multi-decrypt)
Rotação	manual ou auto	manual com motivo + nova versão
Auditoria	logs	logs + INSERT-only versionado
Reveal	sem motivo	motivo obrigatório
Search por valor	não	sim (blind index, sem decriptar)
Casos de uso	API keys, tokens, env vars	Master keys, root creds, JWK signing, PIX keys

A UI exibe banner violeta no SecretForm orientando o usuário a usar Fortress para credenciais críticas e Secrets como "staging para sync com cloud/PAM".

Funcionalidades de UI

• Lista com badges de versão ativa + quantidade total de versões
• Context chips visíveis (env, service — parte do AAD)
• Criar: aviso explícito sobre as camadas, motivo obrigatório, dropdown de cofre alvo (pessoal ★ ou shared) — atribuição validada por canAccessVault('write') antes de cifrar e executada na mesma transação
• Revelar: motivo obrigatório (registrado em audit_logs com severity=high), seletor de versão
• Rotacionar: nova versão com motivo, versões antigas ficam para rollback/auditoria
• Busca: por nome ou por valor (blind index — backend nunca decripta para buscar)
• Histórico: lista ordenada por versão, quem criou, motivo de cada rotação
• Excluir: confirmação por digitação do nome exato + (em tenants Enterprise) dual-control via Approvals

Controle por IAM

Permissões granulares:

• ver_fortress — listar e ler metadados
• acessar_fortress — POST /fortress/:id/view (revelar valor)
• criar_fortress — POST de novo Fortress
• gerenciar_fortress — editar / rotacionar / excluir

Sem essas permissões, sidebar oculta a página /Fortress e route guard bloqueia acesso direto via URL.

API

# Criar
POST /fortress
{
  "name": "stripe-master-prod",
  "value": "sk_live_...",
  "context": { "env": "prd", "service": "billing" },
  "vault_id": 12,
  "reason": "Setup inicial — billing API"
}

# Listar (sem valores)
GET /fortress

# Revelar (motivo obrigatório)
POST /fortress/:id/view
{ "reason": "Investigação incidente SEC-1234", "version": 7 }

# Rotacionar (cria nova versão)
POST /fortress/:id/rotate
{ "value": "sk_live_NOVO...", "reason": "Rotação trimestral" }

# Histórico
GET /fortress/:id/versions

# Excluir (com Approvals em produção)
DELETE /fortress/:id
{ "reason": "Substituído pela secret_id=42" }

Pepper rotation

A partir de v1.4, é possível rotacionar FORTRESS_PEPPER em runtime sem re-deploy — o backend reencripta as versões ativas com o novo pepper. Útil para responder a incidentes ou cumprir requisitos de rotação periódica de chaves mestras (ISO 27001, PCI DSS).

Boas práticas

• Master keys, sempre Fortress — chaves cuja revelação compromete vários sistemas.
• Context AAD bem usado — encripta {env, service}. Vazamento de cifra de produção não permite uso em staging mesmo com a chave certa.
• Nunca loga reason sem revisar — em tenants com PII no motivo, sanitizar antes de export SIEM.
• Dual-control para fortress_delete — habilite no tenant Enterprise via Approvals.
• Backup do pepper offline — perda do pepper inviabiliza decrypt mesmo com DB completo.