Pular para o conteúdo principal

🔒 Segurança

Este guia cobre exclusivamente aspectos de segurança na integração com APIs da Credsystem. Para implementação técnica, veja o Passo 4: Usando o Token.

⚠️ Segurança Crítica

NUNCA exponha suas credenciais (client_id e client_secret) em:

  • ❌ Código client-side (frontend, aplicativos móveis)
  • ❌ Repositórios públicos (GitHub, GitLab, etc.)
  • ❌ Logs ou mensagens de erro
  • ❌ URLs ou query parameters
  • ❌ Código JavaScript no navegador
  • ❌ Apps móveis (podem ser decompilados)
  • ❌ Emails, mensagens ou documentação pública

Armazene credenciais APENAS em servidores backend seguros com acesso restrito


🔐 1. Armazenamento Seguro de Credenciais

Variáveis de Ambiente

✅ Configuração Recomendada:

# .env (NUNCA commitar este arquivo)
CREDSYSTEM_CLIENT_ID=seu_client_id_aqui
CREDSYSTEM_CLIENT_SECRET=seu_client_secret_aqui
CREDSYSTEM_AUTH_URL=https://ssoprd.credsystem.com.br/auth/realms/seu-realm/protocol/openid-connect/token
CREDSYSTEM_API_URL=https://api.credsystem.com.br

Adicione ao .gitignore:

.env
.env.local
.env.*.local
*.secret
*.key

Uso no código:

// Node.js
require('dotenv').config();
const clientId = process.env.CREDSYSTEM_CLIENT_ID;
const clientSecret = process.env.CREDSYSTEM_CLIENT_SECRET;
const authUrl = process.env.CREDSYSTEM_AUTH_URL;

Gerenciadores de Secrets (Produção)

Para ambientes de produção, use serviços especializados:

  • AWS Secrets Manager - Para infraestrutura AWS
  • Azure Key Vault - Para infraestrutura Azure
  • Google Secret Manager - Para infraestrutura GCP
  • HashiCorp Vault - Multi-cloud e on-premise
  • Kubernetes Secrets - Para ambientes containerizados

Benefícios:

  • 🔄 Rotação automática de credenciais
  • 📊 Auditoria completa de acessos
  • 🔐 Criptografia em repouso e em trânsito
  • 🎯 Controle de acesso granular (IAM)
  • 📜 Versionamento de secrets

🎯 2. Gerenciamento de Tokens

  • Cache de token válido (não gerar novo a cada requisição)

    # ✅ Reutilizar token enquanto válido
    if token_expiry > datetime.now():
    return cached_token
  • Renovação automática antes de expirar

    // ✅ Renovar 30s antes de expirar
    if (Date.now() > tokenExpiry - 30000) {
    await refreshToken();
    }
  • NUNCA armazenar token no frontend

    // ❌ ERRADO
    localStorage.setItem('token', accessToken);
    sessionStorage.setItem('token', accessToken);

    // ✅ CORRETO - Token fica apenas no backend
    // Frontend recebe apenas dados autorizados
  • Sempre usar campo expires_in da resposta

    // ✅ CORRETO - Usar expires_in dinâmico
    const tokenExpiry = Date.now() + (data.expires_in * 1000);

    // ❌ ERRADO - Assumir valor fixo
    const tokenExpiry = Date.now() + (300 * 1000); // Pode variar!

🛡️ 3. Proteção de Tokens em Uso

❌ Vulnerabilidades Comuns

1. Token em LocalStorage/SessionStorage

// ❌ NUNCA FAÇA ISSO - Vulnerável a XSS
localStorage.setItem('access_token', token);
sessionStorage.setItem('access_token', token);

// ✅ Token deve ficar apenas no backend
// Frontend nunca deve ter acesso ao token

2. Token em Cookies sem Segurança

// ❌ Cookie sem flags de segurança
document.cookie = 'token=' + token;

// ✅ Se usar cookies (HttpOnly + Secure + SameSite)
res.cookie('session', sessionId, {
httpOnly: true, // Não acessível via JavaScript
secure: true, // Apenas HTTPS
sameSite: 'strict' // Proteção CSRF
});

3. Token em URLs

// ❌ Token exposto em URLs
fetch(`/api/data?token=${token}`);

// ✅ Token em header Authorization
fetch('/api/data', {
headers: { 'Authorization': `Bearer ${token}` }
});

🔒 Proteções Essenciais

  • HTTPS obrigatório em todas as conexões
  • Token apenas no backend server-side
  • Headers HTTP corretos (Authorization: Bearer)
  • Timeout de requisições (evita tokens pendentes)
  • Validação de domínio nas chamadas de API

🌐 4. HTTPS/TLS Obrigatório

🚨 HTTPS é OBRIGATÓRIO

NUNCA faça requisições de autenticação ou API por HTTP não criptografado.

Configuração Mínima

✅ TLS 1.2 ou superior

// Node.js - Forçar TLS 1.2+
const https = require('https');
const agent = new https.Agent({
minVersion: 'TLSv1.2'
});

// Usar em requisições
fetch(url, { agent });

✅ Validação de certificados

// Node.js - Validar certificados
const https = require('https');

// ❌ ERRADO - Nunca desabilitar
const agent = new https.Agent({
rejectUnauthorized: false
});

// ✅ CORRETO - Sempre validar
const agent = new https.Agent({
rejectUnauthorized: true
});

🔄 5. Rotação de Credenciais

Rotação Emergencial:

  • 🚨 Suspeita de vazamento
  • 🚨 Funcionário com acesso saiu da empresa
  • 🚨 Sistema comprometido
  • 🚨 Credenciais expostas em logs/código
  • 🚨 Solicitação da equipe de segurança

Processo de Rotação

1. Solicitar novas credenciais à Credsystem (mesma forma do Passo 1)

2. Implementar estratégia dual:

// Manter ambas credenciais temporariamente
const PRIMARY_CLIENT_ID = process.env.CREDSYSTEM_CLIENT_ID;
const PRIMARY_SECRET = process.env.CREDSYSTEM_CLIENT_SECRET;
const SECONDARY_CLIENT_ID = process.env.CREDSYSTEM_CLIENT_ID_NEW;
const SECONDARY_SECRET = process.env.CREDSYSTEM_CLIENT_SECRET_NEW;

// Tentar primária, fallback para secundária
async function authenticate() {
try {
return await authWithCredentials(PRIMARY_CLIENT_ID, PRIMARY_SECRET);
} catch (error) {
console.log('Tentando credenciais secundárias...');
return await authWithCredentials(SECONDARY_CLIENT_ID, SECONDARY_SECRET);
}
}

3. Testar novas credenciais em ambiente de staging

4. Deploy gradual (canary/blue-green)

5. Revogar credenciais antigas após confirmação


🚦 6. Rate Limiting e Resiliência

📋 Implementação Completa em Boas Práticas

Rate limiting, retry com backoff exponencial e circuit breaker são padrões operacionais detalhados no guia de Boas Práticas:

Do ponto de vista de segurança, atente-se a:

  • Nunca desabilite rate limiting — protege contra abuso e ataques de força bruta
  • Respeite o header Retry-After — retornado pela API quando o limite é atingido (429)
  • Implemente jitter no retry — evita thundering herd (múltiplos clientes retentando simultaneamente)
  • Limite tentativas de autenticação — máximo 3-5 retries antes de gerar alerta
  • Monitore rate limit hits — picos podem indicar ataque ou mal uso

📊 7. Auditoria e Logging

O que Logar (✅)

// ✅ Informações permitidas
logger.info('Autenticação iniciada', {
timestamp: new Date().toISOString(),
client_id: clientId, // OK - não é secreto
environment: 'production',
ip_address: req.ip,
user_agent: req.headers['user-agent']
});

logger.info('Token obtido com sucesso', {
token_prefix: token.substring(0, 10) + '...', // Apenas início
expires_in: expiresIn,
token_type: 'Bearer'
});

logger.error('Falha na autenticação', {
status_code: response.status,
error_type: 'invalid_credentials',
// NUNCA logar client_secret ou token completo
});

O que NÃO Logar (❌)

// ❌ NUNCA logue informações sensíveis
logger.error('Erro:', {
client_secret: clientSecret, // ❌ NUNCA
access_token: fullToken, // ❌ NUNCA
refresh_token: refreshToken, // ❌ NUNCA
password: userPassword // ❌ NUNCA
});

Monitoramento de Segurança

Alertas Recomendados:

  • 🚨 Múltiplas falhas de autenticação (possível ataque de força bruta)
  • 🚨 Uso de credenciais de IPs não esperados
  • 🚨 Picos anormais de requisições
  • 🚨 Erros 401/403 acima do normal
  • 🚨 Tentativas de acesso fora do horário comercial (se aplicável)

👉 Ver implementação de métricas e logging estruturado em 6 linguagens


🔬 8. Separação de Credenciais por Ambiente

⚠️ Obrigatório

Cada ambiente DEVE ter credenciais separadas. Nunca reutilize credenciais de produção em desenvolvimento ou staging.

# Desenvolvimento → Usa SSO de homologação
CREDSYSTEM_AUTH_URL=https://ssohml.credsystem.com.br/...

# Staging → Usa SSO de homologação (credenciais diferentes)
CREDSYSTEM_AUTH_URL=https://ssohml.credsystem.com.br/...

# Produção → Usa SSO de produção
CREDSYSTEM_AUTH_URL=https://ssoprd.credsystem.com.br/...

Benefícios:

  • 🔒 Vazamento em dev não compromete produção
  • 🧪 Testes seguros sem risco
  • 🚨 Revogação de um ambiente não afeta outros
  • 📊 Auditoria separada por ambiente

👉 Ver configuração por ambiente em 6 linguagens — Inclui padrões de config com timeout, log level e SSL por ambiente.


💡 Arquitetura Recomendada

✅ Arquitetura Correta

┌─────────────────┐
│ Frontend │ ← NUNCA fazer auth aqui
│ (Browser) │ ← Não tem credenciais
└────────┬────────┘ ← Não tem tokens
│ HTTPS

┌─────────────────┐
│ Backend/API │ ← ✅ Autenticação aqui
│ Gateway │ ← ✅ Guarda credenciais
└────────┬────────┘ ← ✅ Cache do token


┌─────────────────┐
│ APIs │
│ Credsystem │
└─────────────────┘

❌ Arquitetura Insegura (NÃO FAÇA)

┌─────────────────┐
│ Frontend │ ← ❌ Credenciais expostas
│ (Browser) │ ← ❌ Token pode ser roubado
│ │ ← ❌ Fácil de inspecionar
└────────┬────────┘
│ DIRETO

┌─────────────────┐
│ APIs │ ← Cliente desprotegido
│ Credsystem │
└─────────────────┘

🔄 Fluxo de Autenticação Correto

Assim:

1. Frontend → Backend: "Preciso listar vendas"
2. Backend: Verifica se tem token válido em cache
3. Backend: Se não tem, gera novo token com suas credenciais
4. Backend → Credsystem API: GET /vendas + Authorization: Bearer {token}
5. Credsystem API → Backend: Response com dados
6. Backend → Frontend: Response (SEM expor token)

Benefícios:

  • ✅ Credenciais protegidas no backend
  • ✅ Token não exposto ao usuário final
  • ✅ Cache centralizado (performance)
  • ✅ Fácil rotação de credenciais
  • ✅ Logs seguros no backend

⏱️ Validade dos Tokens

⚠️ Validade Variável

IMPORTANTE: A validade dos tokens pode variar dependendo de:

  • Configurações específicas da sua integração
  • Políticas de segurança do ambiente (homologação vs produção)
  • Tipo de autenticação utilizado (Keycloak vs IDCS)

✅ SEMPRE use o campo expires_in retornado na resposta de autenticação. NUNCA assuma valores fixos no seu código.

// ✅ CORRETO - Usar expires_in da resposta
const tokenExpiry = Date.now() + (data.expires_in * 1000);

// ❌ ERRADO - Assumir valor fixo
const tokenExpiry = Date.now() + (300 * 1000); // Pode ser diferente!

✅ Checklist de Segurança

Antes de colocar em produção, verifique todos os itens:

🔐 Credenciais

  • Credenciais armazenadas em variáveis de ambiente (não em código)
  • Arquivo .env no .gitignore
  • Produção usa gerenciador de secrets (AWS, Azure, etc.)
  • Credenciais diferentes para cada ambiente (dev, staging, prod)
  • Acesso às credenciais restrito (apenas quem precisa)
  • Plano de rotação de credenciais definido (90-180 dias)

🔒 Tokens

  • Token NUNCA exposto no frontend/navegador
  • Token não armazenado em localStorage/sessionStorage
  • Token enviado apenas em header Authorization
  • Logs não expõem tokens completos (apenas 4 últimos caracteres)
  • Token em cache com expiração respeitada

🌐 Comunicação

  • HTTPS obrigatório em todas as conexões
  • TLS 1.2+ configurado
  • Certificados SSL validados (verify=True)
  • Timeout configurado para requisições
  • Rate limiting implementado (proteção contra abuso)

📊 Monitoramento

  • Alertas para múltiplas falhas de autenticação
  • Logs de auditoria com timestamp e IP
  • Métricas de taxa de sucesso/falha
  • Monitoramento de rate limit hits
  • Alertas para acessos de IPs inesperados

🧪 Testes de Segurança

  • Testado comportamento com credenciais inválidas
  • Testado rotação de credenciais em staging
  • Verificado que frontend não tem acesso a tokens
  • Code review focado em segurança
  • Scan de vulnerabilidades no código

📜 Compliance

  • Documentação de segurança atualizada
  • Equipe treinada em boas práticas
  • Processo de incident response definido
  • Conformidade com LGPD/GDPR se aplicável

🎯 Recursos Adicionais

Para mais informações sobre segurança:

👉 Boas Práticas Gerais - Guia completo de melhores práticas

👉 Troubleshooting - Problemas comuns e soluções

Ou volte para o Índice de Autenticação