Segurança

Arquitetura de segurança multicamadas, autenticação, criptografia, boas práticas e resposta a incidentes.

Arquitetura de Segurança

O HestiaShield adota o modelo de defesa em profundidade (Defense in Depth), com controles de segurança independentes em cinco camadas distintas. A falha em uma camada não compromete as demais.

• 1

  Rede

  NGINX reverse proxy com rate limiting por IP. Cloudflare WAF (Web Application Firewall) na borda. Bloqueio de IPs suspeitos e geofencing configuráveis.

• 2

  Transporte

  TLS 1.3 obrigatório em todas as conexões. HSTS preload ativo (max-age=63072000). HPKP em avaliação para pins de certificado.

• 3

  Aplicação

  FastAPI com validação Pydantic em todos os endpoints. CORS configurado para origens permitidas. Content Security Policy (CSP) e headers de segurança no NGINX.

• 4

  Autenticação

  Keycloak 26.1 como Identity Provider central. OAuth2/OIDC com PKCE. JWT com rotação de chaves RSA256. Tokens de curta duração (1h access, 7d refresh).

• 5

  Dados

  PostgreSQL 16 com Row Level Security (RLS). Campos sensíveis criptografados via pgcrypto. Backups criptografados com AES-256. Retenção conforme LGPD.

Diagrama de arquitetura

Autenticação e Autorização

O Keycloak 26.1 atua como Identity Provider (IdP) central, centralizando autenticação para todos os componentes da plataforma.

Flows de autenticação

• App (Android/iOS): Device flow → registro de FCM token → autenticação com JWT bearer em cada request
• Dashboard admin: Authorization Code Flow com PKCE → session JWT com renovação automática
• API B2B (parceiros): API Key estática (sk_live_*) combinada com IP whitelist por parceiro

Propriedades dos tokens JWT

• Algoritmo: RS256 (RSA com SHA-256)
• Access token: validade de 1 hora, renovável via refresh token
• Refresh token: validade de 7 dias, rotacionado a cada uso
• Claims: sub, roles, device_id, partner_id (quando aplicável)

Papéis RBAC

Criptografia

Em trânsito

• Protocolo: TLS 1.3 (TLS 1.2 como fallback mínimo)
• Cipher suite preferencial: ECDHE-RSA-AES256-GCM-SHA384
• HSTS: max-age=63072000; includeSubDomains; preload
• Certificados: Let's Encrypt (renovação automática via certbot)

# Cipher suites configurados no NGINX
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:
            ECDHE-RSA-AES128-GCM-SHA256:
            ECDHE-ECDSA-AES256-GCM-SHA384:
            ECDHE-RSA-AES256-GCM-SHA384:
            ECDHE-ECDSA-CHACHA20-POLY1305:
            ECDHE-RSA-CHACHA20-POLY1305;

Em repouso

• PostgreSQL: pgcrypto para campos sensíveis (tokens, dados de identificação)
• Firebase / Firestore: criptografia at rest gerenciada pelo Google (AES-256)
• FCM tokens: nunca registrados em texto plano em logs — armazenados com prefixo de hash para referência
• Backups: criptografados com AES-256, chave gerenciada pelo operador, armazenados em local separado

Boas Práticas para Parceiros

Parceiros que integram com a API HestiaShield devem seguir as práticas abaixo para garantir a segurança de ponta a ponta:

• Armazenar API keys em variáveis de ambiente — nunca no código fonte ou versionamento
• Implementar verificação HMAC em todos os webhooks recebidos antes de processar o payload
• Rotacionar API keys a cada 90 dias como mínimo de segurança operacional
• Configurar IP whitelist no momento da integração e mantê-la atualizada
• Usar TLS 1.2+ nas chamadas para a API (TLS 1.3 recomendado)
• Monitorar rate limits e implementar retry com exponential backoff para resiliência
• Não compartilhar API key entre ambientes — usar keys distintas para dev, staging e prod
• Auditar regularmente as permissões e revogar acessos de colaboradores desligados

Resposta a Incidentes

A HestiaShield mantém processo estruturado de resposta a incidentes com SLAs definidos por severidade:

Canais de notificação

• Status público: status.hestiashield.com.br (Uptime Kuma — disponibilidade em tempo real)
• E-mail para parceiros: notificações automáticas para parceiros cadastrados em incidentes P1/P2
• Reportar vulnerabilidade: faleconosco@hestiashield.com.br com assunto SECURITY DISCLOSURE