Gestão de Incidentes e Continuidade de Serviços de TI no DETRAN

Conceitos essenciais: incidente, problema e continuidade

Incidente é qualquer interrupção não planejada, degradação ou risco iminente que afete um serviço de TI (ex.: indisponibilidade de agendamento, lentidão no atendimento digital, falha de integração com sistemas externos). O objetivo da Gestão de Incidentes é restaurar o serviço com segurança e rapidez, minimizando impacto ao cidadão e às áreas internas.

Problema é a causa subjacente (ou potencial) de um ou mais incidentes. Um incidente pode ser resolvido com contorno (workaround) sem remover a causa raiz; a investigação de causa raiz e prevenção de recorrência é tratada como problema, mas aqui o foco é o fluxo operacional do incidente e a produção do relatório técnico com causa raiz e plano de ação.

Continuidade de Serviços de TI é a capacidade de manter ou restaurar serviços críticos dentro de objetivos de tempo e perda de dados aceitáveis, mesmo após eventos severos (falhas amplas, indisponibilidade de datacenter, ransomware, vazamento de dados, indisponibilidade de fornecedor).

Processo operacional de gestão de incidentes (fim a fim)

1) Detecção e registro

Fontes comuns de detecção incluem: monitoramento (APM, logs, métricas), alertas de segurança, chamados do service desk, reclamações de usuários, falhas em jobs e integrações. O registro deve ser imediato e padronizado para permitir rastreabilidade e auditoria.

• Campos mínimos: data/hora, serviço afetado, sintomas, escopo (quantos usuários/unidades), ambiente (produção/homologação), evidências iniciais (prints, IDs de log), quem detectou, canal de entrada, severidade inicial, status e responsáveis.
• Boas práticas: vincular o incidente a itens de configuração (CMDB quando existir), anexar evidências desde o início e registrar todas as ações com carimbo de data/hora.

2) Triagem e classificação

A triagem decide prioridade, rota de atendimento e necessidade de escalonamento. Use uma matriz simples de Impacto x Urgência para definir a prioridade (P1 a P4, por exemplo).

Continue em nosso aplicativo

Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.

ou continue lendo abaixo...

Baixar o aplicativo

• Impacto: quantos serviços/unidades/cidadãos afetados, impacto em atendimento presencial/digital, risco regulatório e reputacional.
• Urgência: tempo tolerável até degradação maior, janelas críticas (ex.: picos de agendamento), dependências externas.
• Classificação: categoria (aplicação, integração, infraestrutura, identidade, dados), tipo (indisponibilidade, desempenho, segurança), e se há suspeita de incidente de segurança.

Critério prático: se houver indício de comprometimento (ransomware, exfiltração, credenciais vazadas), trate como incidente de segurança e acione imediatamente o fluxo de preservação de evidências e comunicação restrita.

3) Contenção (reduzir o dano e impedir propagação)

Contenção busca estabilizar o cenário e limitar impacto. Pode ser técnica (bloquear tráfego, isolar host) e operacional (congelar mudanças, restringir acessos).

• Exemplos de contenção: retirar nó problemático do balanceador, desabilitar funcionalidade específica via feature flag, bloquear IPs maliciosos, revogar tokens/sessões, isolar endpoint suspeito, pausar integrações para evitar dados inconsistentes.
• Cuidados: registrar justificativa, avaliar impacto colateral (ex.: bloquear integração pode afetar emissão de documentos), e preservar evidências antes de ações destrutivas (ex.: limpeza de logs).

4) Erradicação (remover a causa imediata)

Erradicação remove o elemento que mantém o incidente ativo: malware, configuração incorreta, credencial comprometida, componente defeituoso, regra de firewall errada, versão com bug.

• Passos típicos: identificar vetor (como ocorreu), remover artefatos, aplicar correção (patch/hotfix), eliminar persistência (tarefas agendadas, contas criadas), revisar permissões e chaves, corrigir configuração e validar integridade.
• Critério de segurança: se houver suspeita de comprometimento, considerar rotação de segredos (senhas, chaves, certificados) e revalidação de contas privilegiadas.

5) Recuperação (restaurar serviço e confiança)

Recuperação é devolver o serviço ao nível acordado e confirmar que o ambiente está estável e confiável.

• Checklist de recuperação: serviço responde, integrações funcionam, filas/processamentos normalizados, monitoramento sem alertas, usuários-chave validam, e não há sinais de reinfecção/recorrência.
• Dados: quando houver restauração, validar consistência e reconciliação (ex.: transações pendentes, registros duplicados, lacunas de processamento).
• Retorno gradual: em incidentes graves, liberar por etapas (unidades piloto, percentual de tráfego) para reduzir risco.

6) Lições aprendidas e melhoria contínua

Após estabilização, conduza uma revisão estruturada para capturar causa raiz, falhas de detecção, gaps de processo e ações preventivas.

• Entradas: linha do tempo, logs, mudanças recentes, evidências, decisões tomadas e comunicação realizada.
• Saídas: causa raiz, fatores contribuintes, ações corretivas/preventivas, atualização de runbooks, ajustes em SLAs/OLAs, melhorias de monitoramento e treinamento.

Runbooks: como construir e manter

Runbook é um guia operacional executável para responder a um tipo de incidente. Ele reduz tempo de resposta, padroniza decisões e facilita escalonamento.

Estrutura recomendada de runbook

• Identificação: nome, versão, data, responsáveis, serviços cobertos, pré-requisitos de acesso.
• Critérios de acionamento: sintomas, alertas, métricas/limiares, exemplos de mensagens de erro.
• Diagnóstico rápido (10–15 min): comandos/consultas, onde olhar logs, como confirmar escopo.
• Contenção: ações seguras e reversíveis, com riscos e impactos.
• Erradicação: correções possíveis, validações e rollback.
• Recuperação: passos para retorno, validação com usuários-chave, checklist pós-retorno.
• Escalonamento: quando acionar N2/N3, segurança, fornecedor, gestão; contatos e janelas.
• Comunicação: modelos de mensagem para áreas de negócio e status page interna.
• Evidências: o que coletar e como armazenar.

Exemplo de runbook (esqueleto) para indisponibilidade de serviço crítico

Runbook: Indisponibilidade do Serviço de Agendamento (Produção) - v1.3  Responsável: Operações/N2  Acionamento: Alerta 5xx > 5% por 5 min OU tempo de resposta p95 > 3s por 10 min  Diagnóstico rápido: 1) Verificar status do balanceador e health checks 2) Conferir erros no gateway/API (códigos, endpoints) 3) Verificar filas/jobs relacionados 4) Checar mudanças nas últimas 2h (deploy/config)  Contenção: - Retirar instância com erro do pool - Ativar página de contingência (se aplicável) - Desabilitar funcionalidade não essencial (feature flag)  Erradicação: - Reverter deploy se correlação com mudança - Corrigir configuração e reiniciar componente com janela controlada  Recuperação: - Validar endpoints críticos - Validar com usuário-chave do atendimento - Monitorar por 30 min sem regressão  Escalonamento: - Se suspeita de ataque, acionar Segurança imediatamente - Se falha em fornecedor, abrir chamado e registrar protocolo  Evidências: - Exportar logs do período T-30min a T+30min - Capturar métricas e IDs de correlação

SLAs e OLAs: acordos que sustentam a operação

SLA (Service Level Agreement) define o nível de serviço esperado pelo negócio (ex.: disponibilidade mensal, tempo de restauração por prioridade). OLA (Operational Level Agreement) define compromissos internos entre equipes para cumprir o SLA (ex.: tempo de atendimento do time de infraestrutura para incidentes P1).

Como definir na prática

• Catálogo de serviços: liste serviços e donos (service owner) e identifique quais são críticos ao atendimento.
• Prioridades: defina P1/P2/P3/P4 com critérios objetivos (impacto/urgência).
• Metas: para cada prioridade, estabeleça tempo de resposta (acknowledgement), tempo de contorno, tempo de restauração e janela de comunicação.
• OLAs: decomponha o SLA em tempos internos (triagem, diagnóstico, mudança emergencial, validação).
• Indicadores: MTTA (tempo para reconhecer), MTTR (tempo para restaurar), taxa de recorrência, % incidentes com RCA, cumprimento de comunicação.

Comunicação com áreas de negócio: clareza, cadência e controle

Em incidentes, comunicação é parte do controle do impacto. O objetivo é manter áreas de atendimento, gestão e comunicação institucional informadas sem expor dados sensíveis ou especulações.

Regras práticas

• Canal único: defina um canal oficial (sala de incidente) e um porta-voz técnico.
• Cadência: em P1, atualizações em intervalos fixos (ex.: a cada 15–30 min) mesmo sem novidade, informando o que está sendo feito.
• Mensagem orientada a impacto: o negócio precisa saber “o que está fora”, “quem é afetado”, “alternativas”, “previsão” e “próxima atualização”.
• Controle de informação: em suspeita de vazamento/ataque, restringir detalhes técnicos a grupos necessários e registrar quem recebeu o quê.

Modelo de atualização de status (interno)

Incidente: [P1] Indisponibilidade do Serviço X  Início: 10:12  Impacto: Unidades A/B e portal externo com falha de acesso  Situação atual: Contenção aplicada (instância removida do pool). Investigação em andamento.  Próximos passos: Validar correlação com mudança das 09:50 e executar rollback se confirmado.  Alternativa operacional: Atendimento orientado a usar fluxo Y temporariamente.  Próxima atualização: 10:45  Responsável técnico: Nome/Equipe

Preservação de evidências (cadeia de custódia operacional)

Preservar evidências é essencial para auditoria, responsabilização, investigação forense e suporte a medidas administrativas/legais. A regra é: coletar antes de alterar quando houver suspeita de incidente de segurança.

O que coletar

• Logs: aplicação, autenticação, proxy/gateway, firewall, EDR/antimalware, sistemas operacionais, auditoria.
• Artefatos: hashes de arquivos suspeitos, amostras (quando permitido), lista de processos, conexões de rede, tarefas agendadas, usuários e grupos.
• Contexto: mudanças recentes, contas usadas, IPs, horários, IDs de correlação, tickets e decisões.

Como preservar

• Integridade: exportar em formato imutável quando possível, registrar hash (SHA-256) e horário.
• Armazenamento: repositório com controle de acesso e trilha de auditoria.
• Registro: quem coletou, quando, de onde, como, e onde foi armazenado.

Continuidade de serviços: BIA, estratégias e planos

BIA (Business Impact Analysis) na prática

BIA identifica serviços críticos, impactos de indisponibilidade e define objetivos de continuidade.

• Passo a passo:
• 1) Listar processos de negócio suportados por TI (ex.: atendimento digital, emissão/consulta, integrações).
• 2) Para cada processo, estimar impacto por tempo de parada (financeiro, operacional, legal, reputacional).
• 3) Definir RTO (tempo máximo para restaurar) e RPO (perda máxima de dados aceitável).
• 4) Mapear dependências: sistemas, integrações, identidade, links, fornecedores, equipes.
• 5) Priorizar serviços e aprovar com donos do negócio.

Planos de contingência e recuperação

Com base no BIA, construa planos que descrevem como operar durante a falha e como recuperar.

• Plano de contingência: procedimentos para manter atendimento com degradação controlada (ex.: filas, agendamento alternativo, operação manual temporária, restrição de funcionalidades).
• Plano de recuperação: passos técnicos para restaurar componentes, dados e integrações, com ordem de dependências.
• Critérios de acionamento: quando declarar desastre/contingência, quem autoriza e quais comunicações são disparadas.

Testes de continuidade

Planos não testados tendem a falhar. Testes devem ser programados e gerar evidências.

• Tipos: teste de mesa (tabletop), simulação parcial (failover de componente), teste completo (quando viável), teste de restauração de backup, teste de comunicação.
• Roteiro mínimo: objetivo, escopo, pré-requisitos, métricas (RTO/RPO), papéis, critérios de sucesso, riscos e rollback.
• Saídas: relatório de teste, gaps encontrados, ações e prazos.

Resposta a ransomware: fluxo operacional recomendado

Ransomware exige rapidez e disciplina: conter propagação, preservar evidências, avaliar impacto em dados e restaurar com segurança.

Passo a passo (visão operacional)

• 1) Detecção: alertas de EDR, arquivos criptografados, picos de I/O, notas de resgate, falhas em serviços.
• 2) Contenção imediata: isolar máquinas/servidores suspeitos da rede, bloquear credenciais comprometidas, segmentar tráfego, suspender compartilhamentos afetados.
• 3) Preservação: coletar logs, memória (quando aplicável), artefatos e indicadores (IOCs) antes de limpeza.
• 4) Erradicação: remover persistência, corrigir vetor (phishing, RDP exposto, vulnerabilidade), rotacionar segredos, revisar privilégios.
• 5) Recuperação: restaurar a partir de backups confiáveis (testados), validar integridade e ausência de reinfecção, reintroduzir serviços por etapas.
• 6) Comunicação: atualizações regulares ao negócio; comunicação externa somente por canais autorizados.

Ponto crítico: não confiar em backups sem teste de restauração e verificação de integridade. A recuperação deve considerar o risco de reinfecção por credenciais e persistências não removidas.

Resposta a vazamento de dados: contenção e avaliação de exposição

Em vazamento, o foco é interromper a exfiltração, entender o que foi exposto e reduzir danos.

Passo a passo (visão operacional)

• 1) Detecção: alertas de tráfego anômalo, acessos incomuns, consultas massivas, credenciais em uso indevido.
• 2) Contenção: revogar sessões/tokens, bloquear origem, desabilitar conta suspeita, aplicar regras temporárias de WAF/firewall, limitar endpoints sensíveis.
• 3) Preservação: exportar logs de acesso, trilhas de auditoria, evidências de consultas e transferências.
• 4) Análise de escopo: identificar período, contas, endpoints, volume, tipos de dados e possíveis destinos.
• 5) Erradicação: corrigir falha (configuração, permissão, vulnerabilidade), rotacionar segredos, reforçar controles.
• 6) Recuperação: reabilitar acessos com validações, monitorar recorrência, aumentar alertas temporariamente.

Comunicação deve ser coordenada com áreas responsáveis (jurídico, comunicação, governança), mantendo registro do que foi informado e quando.

Simulações (tabletop) com linha do tempo do incidente

Simulações treinam tomada de decisão, comunicação e execução de runbooks. A seguir, um modelo de exercício com linha do tempo e entregáveis.

Simulação 1: indisponibilidade crítica com suspeita de ataque

• Objetivo: praticar triagem, contenção, comunicação e preservação de evidências.
• Participantes: service desk, N2/N3, segurança, dono do serviço, representante do negócio.
• Regras: registrar tudo no ticket, usar canal único, atualizações a cada 20 min.

Linha do tempo (exemplo)

• T+0: alerta de 5xx e reclamações de usuários.
• T+10: triagem define P1; abre sala de incidente; inicia coleta de logs.
• T+20: identifica tráfego anômalo; aplica contenção (bloqueio e isolamento de instância).
• T+40: serviço estabiliza parcialmente; decide rollback de mudança recente.
• T+60: serviço normaliza; inicia varredura de indicadores e rotação de credenciais críticas.
• T+90: validação com negócio; mantém monitoramento reforçado.

Relatório técnico do incidente: causa raiz e plano de ação

O relatório deve ser objetivo, rastreável e acionável. Ele serve para auditoria, aprendizado e prevenção.

Template recomendado

• Identificação: ID do incidente, datas/horas (início, detecção, contenção, restauração), prioridade, serviços afetados.
• Impacto: escopo, duração, efeitos no atendimento, integrações e usuários.
• Linha do tempo: eventos com horários e responsáveis (incluindo decisões e comunicações).
• Diagnóstico: hipóteses testadas, evidências coletadas, correlações com mudanças.
• Causa raiz: descrição clara (técnica e operacional) e fatores contribuintes.
• Correção aplicada: o que foi feito para restaurar e por que funcionou.
• Riscos remanescentes: pendências, monitoramento adicional, limitações temporárias.
• Plano de ação: ações corretivas e preventivas com responsável, prazo, prioridade e critério de aceite.
• Anexos: logs, gráficos, hashes, prints, tickets relacionados, runbook atualizado.

Exemplo de plano de ação (formato prático)

Ação | Tipo | Responsável | Prazo | Critério de aceite  Implementar alerta de anomalia de tráfego no endpoint /login | Preventiva | Operações | 10 dias | Alerta dispara em teste controlado  Revisar permissões de conta de serviço X | Corretiva | Segurança | 5 dias | Conta com menor privilégio e rotação concluída  Atualizar runbook de P1 com checklist de evidências | Preventiva | N2 | 3 dias | Runbook v1.4 publicado e validado em simulação  Agendar teste de restauração (RTO/RPO) do serviço crítico | Preventiva | Continuidade | 20 dias | Relatório de teste com RTO/RPO medidos