DevOps - Gestão de Segredos¶
O que Nunca Deve Ir para Web ou Mobile¶
❌ Secrets Críticos¶
- Chaves de API:
JWT_SECRETJWT_REFRESH_SECRETSENDGRID_API_KEYR2_ACCESS_KEY_ID-
R2_SECRET_ACCESS_KEY -
Credenciais de Banco:
DATABASE_URL(com senha)-
DB_PASSWORD -
Tokens e Chaves Privadas:
- Qualquer chave privada
- Tokens de acesso
✅ O que Pode Estar em Web/Mobile¶
- URLs Públicas:
VITE_API_URL- URL da API (pública)-
EXPO_PUBLIC_API_URL- URL da API (pública) -
Configurações Públicas:
- IDs públicos (não secrets)
- URLs de endpoints públicos
Boas Práticas de Segurança¶
1. Variáveis de Ambiente¶
Nunca commitar:
- Arquivos .env com secrets
- Arquivos .env.local
- Arquivos .env.docker
- Arquivos .env.test
- Arquivos .env.production
Sempre commitar:
- .env.example (sem valores reais)
- Documentação de variáveis necessárias
2. Backend¶
Armazenamento: - Variáveis de ambiente no Railway - Nunca hardcoded no código - Nunca em logs
Exemplo de .env.example:
# Banco de dados
DATABASE_URL=postgresql://user:password@host:port/dbname
# Autenticação
JWT_SECRET=your-secret-key-change-in-production
JWT_REFRESH_SECRET=your-refresh-secret-key-change-in-production
# Storage
R2_ACCOUNT_ID=your-account-id
R2_ACCESS_KEY_ID=your-access-key
R2_SECRET_ACCESS_KEY=your-secret-key
3. Frontend Web¶
Armazenamento:
- Apenas variáveis públicas (prefixed com VITE_)
- Nunca secrets no código
- Nunca secrets no bundle
Exemplo de .env.example:
VITE_API_URL=https://api.billings-ease.com/api
4. Mobile¶
Armazenamento:
- Apenas variáveis públicas (prefixed com EXPO_PUBLIC_)
- Nunca secrets no código
- Nunca secrets no bundle
Exemplo de .env.example:
EXPO_PUBLIC_API_URL=https://api.billings-ease.com/api
Gestão de Secrets no Railway¶
Configuração¶
- Acessar projeto no Railway
- Ir em "Variables"
- Adicionar variáveis de ambiente
- Marcar como "Secret" (opcional, mas recomendado)
Rotação de Secrets¶
Quando rotacionar: - Vazamento suspeito - Período regular (ex: a cada 6 meses) - Mudança de equipe
Processo: 1. Gerar novos secrets 2. Atualizar no Railway 3. Reiniciar aplicação 4. Invalidar tokens antigos (se necessário)
Gestão de Secrets no Código¶
❌ Nunca Fazer¶
// ❌ ERRADO - Secret hardcoded
const API_KEY = "sk_live_1234567890"
// ❌ ERRADO - Secret em log
console.log("API Key:", process.env.API_KEY)
// ❌ ERRADO - Secret em resposta
return { apiKey: process.env.API_KEY }
✅ Sempre Fazer¶
// ✅ CORRETO - Secret em variável de ambiente
const API_KEY = process.env.API_KEY
// ✅ CORRETO - Log sem secret
console.log("API Key configured:", !!process.env.API_KEY)
// ✅ CORRETO - Nunca retornar secret
return { status: "ok" }
Segurança de Tokens JWT¶
Backend¶
Armazenamento:
- JWT_SECRET em variável de ambiente
- Nunca no código
- Nunca em logs
Geração:
# Gerar secret seguro
openssl rand -base64 32
Frontend/Mobile¶
Armazenamento: - Tokens recebidos do backend - Armazenados localmente (localStorage/SecureStore) - Nunca hardcoded - Nunca em logs
Segurança de Banco de Dados¶
Credenciais¶
Nunca: - Hardcoded no código - Em logs - Em mensagens de erro detalhadas
Sempre: - Em variáveis de ambiente - Rotacionar periodicamente - Usar conexões SSL em produção
Segurança de Storage (R2)¶
Credenciais¶
Nunca: - Expor em frontend/mobile - Hardcoded no código - Em logs
Sempre: - Apenas no backend - Em variáveis de ambiente - Rotacionar periodicamente
Checklist de Segurança¶
Antes de Fazer Commit¶
- [ ] Verificar que não há secrets no código
- [ ] Verificar que
.envestá no.gitignore - [ ] Verificar que
.env.local,.env.dockere.env.testestão no.gitignore - [ ] Verificar que não há secrets em logs
- [ ] Verificar que não há secrets em comentários
Antes de Deploy¶
- [ ] Verificar que todas as variáveis estão configuradas
- [ ] Verificar que secrets estão marcados como secretos
- [ ] Verificar que não há secrets expostos em frontend/mobile
- [ ] Verificar que conexões usam SSL
Após Deploy¶
- [ ] Verificar que aplicação está funcionando
- [ ] Verificar logs (sem secrets expostos)
- [ ] Verificar que autenticação está funcionando