Gestão de Chaves Criptográficas

1. Objetivo

Definir o processo de gestão das chaves criptográficas utilizadas pela plataforma Jogaê, incluindo geração, armazenamento seguro, uso, rotação periódica e revogação de emergência.

2. Inventário de Chaves

Chave	Uso	Armazenamento	Rotação
APP_KEY	Criptografia AES-256-CBC (encrypted casts, cookies, sessions)	.env (não versionado)	Anual ou após comprometimento
JWT_SECRET	Assinatura de tokens JWT para autenticação API	.env (não versionado)	Anual ou após comprometimento
API Keys Asaas	Autenticação com gateway de pagamento (por academia)	Banco de dados (cast: encrypted)	Sob demanda ou após comprometimento
Webhook Secrets	Validação de assinatura de webhooks recebidos	Banco de dados (cast: encrypted)	Sob demanda
SSH Keys	Acesso ao servidor de produção e deploy	CI/CD (variáveis protegidas) + máquina autorizada	Anual
DO_KEY / DO_SECRET	Acesso ao DigitalOcean Spaces (storage)	.env (não versionado)	Anual

3. Geração

• APP_KEY: Gerada via php artisan key:generate (AES-256-CBC, 32 bytes aleatórios).
• JWT_SECRET: Gerada via php artisan jwt:secret.
• API Keys Asaas: Geradas pelo painel Asaas do cliente, importadas via interface administrativa.
• Webhook Secrets: Gerados automaticamente pelo sistema com entropia criptográfica.

4. Armazenamento

• Chaves de infraestrutura armazenadas em variáveis de ambiente (.env), nunca no código-fonte.
• Arquivo .env incluído no .gitignore — nunca versionado.
• Chaves de API por academia armazenadas com encrypted cast (AES-256-CBC) no banco de dados.
• Campos sensíveis marcados como $hidden para não aparecer em serializações JSON.

5. Rotação

• Rotação programada: Anual para APP_KEY, JWT_SECRET, SSH Keys e credenciais de infraestrutura.
• Rotação emergencial: Imediata em caso de suspeita de comprometimento (ver seção 6).
• API Keys Asaas: Rotação sob demanda pela academia via painel, com atualização no sistema.

6. Revogação de Emergência

Em caso de comprometimento confirmado ou suspeito:

1. Revogar/rotacionar imediatamente a chave comprometida.
2. Se APP_KEY: gerar nova chave e re-criptografar dados afetados.
3. Se JWT_SECRET: gerar novo secret (invalida todos os tokens ativos — usuários precisam fazer login novamente).
4. Se API Key Asaas: desativar conta Asaas afetada e criar nova com nova chave.
5. Se SSH Key: remover chave pública do servidor, gerar novo par.
6. Registrar o incidente conforme Plano de Gestão de Incidentes.
7. Investigar como o comprometimento ocorreu e implementar medidas preventivas.

Versão: 1.0 | Aprovação: Agosto/2026 | Próxima revisão: Agosto/2027