Plano de Gestão de Incidentes de Segurança

1. Objetivo

Estabelecer o processo formal para gestão de incidentes de segurança da informação, incluindo detecção, classificação, resposta, comunicação a partes interessadas e registro.

2. Definição de Incidente

Qualquer evento que comprometa ou possa comprometer a confidencialidade, integridade ou disponibilidade de dados, sistemas ou serviços da plataforma Jogaê.

3. Classificação de Severidade

Nível	Descrição	Exemplos	SLA de Resposta
Crítico	Comprometimento ativo de dados ou indisponibilidade total	Vazamento de dados pessoais, acesso não autorizado ao banco, sistema fora do ar	1 hora
Alto	Risco iminente de comprometimento ou degradação severa	Tentativa de brute force massiva, vulnerabilidade explorada, falha de criptografia	4 horas
Médio	Anomalia que requer investigação	Aumento atípico de erros, tentativas de acesso suspeitas, dependência com CVE conhecida	24 horas
Baixo	Evento registrado sem impacto imediato	Tentativa de login falha isolada, alerta de monitoramento pontual	72 horas

4. Detecção

Os incidentes são detectados por:

• Sentry: Monitoramento contínuo de erros, exceções e performance.
• Logs de auditoria: Canal "auditoria" com registro de logins, bloqueios, impersonação e ações sensíveis.
• Alertas Slack: Notificações automáticas para eventos críticos.
• Proteção anti-brute-force: Bloqueio automático após 10 tentativas com notificação por e-mail.
• Relato humano: Qualquer colaborador ou usuário que identifique comportamento anômalo.

5. Fluxo de Resposta

1. Triagem — Identificar e classificar a severidade do incidente.
2. Contenção — Isolar o problema (revogar credenciais comprometidas, bloquear IPs, desativar contas).
3. Investigação — Analisar logs de auditoria, user_actions_log e Sentry para determinar causa raiz e escopo.
4. Erradicação — Remover a causa (aplicar correção, rotacionar chaves, atualizar dependências).
5. Recuperação — Restaurar operação normal e validar integridade.
6. Lições aprendidas — Documentar o incidente e implementar melhorias para evitar recorrência.

6. Comunicação a Partes Interessadas

Parte Interessada	Quando Comunicar	Canal
Equipe técnica	Imediatamente na detecção	Slack (canal crítico)
Direção	Incidentes Críticos e Altos	Mensagem direta + e-mail
Clientes afetados	Quando dados pessoais forem comprometidos	E-mail + notificação no sistema
ANPD	Incidentes com dados pessoais (prazo legal: 2 dias úteis)	Formulário ANPD
Parceiros (Asaas, etc.)	Quando credenciais compartilhadas forem comprometidas	Canal oficial do parceiro

7. Preservação de Evidências

• Logs de auditoria retidos por 90 dias (arquivo) e indefinidamente no banco de dados.
• Em caso de incidente, criar snapshot dos logs relevantes antes de qualquer alteração.
• Registrar timeline completa do incidente com horários, ações tomadas e responsáveis.
• Preservar registros da tabela user_actions_log e adquirencia_requisicoes relevantes.

8. Registro de Incidentes

Todo incidente deve ser registrado com:

• Data/hora de detecção e resolução
• Classificação de severidade
• Descrição do incidente e impacto
• Ações de contenção e erradicação tomadas
• Causa raiz identificada
• Comunicações realizadas
• Melhorias implementadas para prevenir recorrência

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