Plano de Contingência e Recuperação de Desastres

Sistema Acesso ao Emprego - Portal de Talentos

---

Informação	Detalhes
Versão do Documento	1.0.0
Data de Criação	Janeiro/2026
Última Atualização	Janeiro/2026
Classificação	Confidencial
Responsável	Equipe de Infraestrutura
Próxima Revisão	Julho/2026

---

1. Introdução

1.1 Objetivo

Este documento estabelece os procedimentos para garantir a continuidade operacional do Sistema Acesso ao Emprego em situações de falha, desastre ou interrupção de serviço, minimizando o impacto nas operações e assegurando a recuperação dos serviços dentro dos níveis acordados.

1.2 Escopo

Este plano abrange:

• Identificação e classificação de riscos
• Procedimentos de resposta a incidentes
• Estratégias de backup e recuperação
• Plano de comunicação
• Testes e manutenção do plano

1.3 Definições

Termo	Definição
RTO (Recovery Time Objective)	Tempo máximo tolerável para restauração do serviço
RPO (Recovery Point Objective)	Perda máxima aceitável de dados (em tempo)
MTTR (Mean Time To Repair)	Tempo médio para reparo
BCP (Business Continuity Plan)	Plano de Continuidade de Negócios
DR (Disaster Recovery)	Recuperação de Desastres

1.4 Metas de Recuperação

Serviço	RTO	RPO	Criticidade
API Backend	1 hora	4 horas	Crítica
Banco de Dados	2 horas	1 hora	Crítica
Frontend	30 minutos	N/A	Alta
Worker Celery	2 horas	4 horas	Média
Serviços de Email	4 horas	24 horas	Baixa

2. Análise de Riscos

2.1 Matriz de Riscos

ID	Risco	Probabilidade	Impacto	Nível
R01	Falha de hardware do servidor	Baixa	Alto	Médio
R02	Corrupção de banco de dados	Baixa	Crítico	Alto
R03	Ataque cibernético (DDoS/Ransomware)	Média	Crítico	Crítico
R04	Falha de rede/conectividade	Média	Alto	Alto
R05	Erro humano em produção	Média	Alto	Alto
R06	Falha de serviço de nuvem	Baixa	Alto	Médio
R07	Desastre natural (incêndio, inundação)	Muito Baixa	Crítico	Médio
R08	Falha de energia prolongada	Baixa	Alto	Médio
R09	Expiração de certificados SSL	Média	Médio	Médio
R10	Estouro de capacidade de disco	Média	Alto	Alto

2.2 Classificação de Incidentes

Severidade	Descrição	Tempo de Resposta	Escalação
Crítica	Sistema completamente indisponível	< 15 minutos	Imediata
Alta	Funcionalidade principal comprometida	< 30 minutos	30 minutos
Média	Funcionalidade secundária afetada	< 2 horas	4 horas
Baixa	Impacto mínimo na operação	< 8 horas	24 horas

3. Estrutura de Resposta a Incidentes

3.1 Equipe de Resposta

Função	Responsabilidade	Contato Principal	Backup
Coordenador de Crise	Coordenação geral, decisões críticas	[Nome] - [Telefone]	[Nome]
Líder Técnico	Diagnóstico e resolução técnica	[Nome] - [Telefone]	[Nome]
DBA	Recuperação de banco de dados	[Nome] - [Telefone]	[Nome]
Infraestrutura	Servidores e rede	[Nome] - [Telefone]	[Nome]
Comunicação	Comunicação com stakeholders	[Nome] - [Telefone]	[Nome]

3.2 Cadeia de Escalação

Nível 1: Equipe de Suporte (0-15 min)
    ↓ (se não resolvido)
Nível 2: Líder Técnico (15-30 min)
    ↓ (se não resolvido)
Nível 3: Coordenador de Crise (30-60 min)
    ↓ (se crítico)
Nível 4: Gestão Executiva

3.3 Canal de Comunicação de Emergência

Canal	Uso	Acesso
Grupo WhatsApp Emergência	Comunicação rápida	Equipe de resposta
Email Emergência	Documentação formal	emergencia@portal-talentos.gov.br
Telefone de Plantão	Contato direto	(XX) XXXXX-XXXX

4. Estratégia de Backup

4.1 Política de Backup

Tipo	Frequência	Retenção	Local	Criptografia
Backup Completo DB	Diário (03:00)	30 dias	S3 + Local	AES-256
Backup Incremental DB	A cada 6 horas	7 dias	S3	AES-256
Backup de Arquivos	Diário (04:00)	30 dias	S3	AES-256
Snapshot de Servidor	Semanal	4 semanas	Provider Cloud	Sim
Backup de Configurações	A cada alteração	90 dias	Git + S3	Sim

4.2 Scripts de Backup

4.2.1 Backup do Banco de Dados

#!/bin/bash
# /opt/scripts/backup-database.sh

set -e

DATE=$(date +%Y%m%d_%H%M%S)
BACKUP_DIR="/backups/database"
S3_BUCKET="s3://portal-talentos-backups/database"
RETENTION_DAYS=30

mkdir -p $BACKUP_DIR

echo "[$(date)] Iniciando backup do banco de dados..."

docker-compose -f /opt/portal-talentos/docker-compose.prod.yml exec -T postgres \
    pg_dump -U portal_talentos_user -Fc portal_talentos_db > $BACKUP_DIR/db_${DATE}.dump

gzip $BACKUP_DIR/db_${DATE}.dump

openssl enc -aes-256-cbc -salt -pbkdf2 \
    -in $BACKUP_DIR/db_${DATE}.dump.gz \
    -out $BACKUP_DIR/db_${DATE}.dump.gz.enc \
    -pass file:/opt/scripts/.backup_key

rm $BACKUP_DIR/db_${DATE}.dump.gz

aws s3 cp $BACKUP_DIR/db_${DATE}.dump.gz.enc $S3_BUCKET/

find $BACKUP_DIR -name "*.enc" -mtime +$RETENTION_DAYS -delete

echo "[$(date)] Backup concluído com sucesso: db_${DATE}.dump.gz.enc"

4.2.2 Backup de Arquivos de Mídia

#!/bin/bash
# /opt/scripts/backup-media.sh

set -e

DATE=$(date +%Y%m%d_%H%M%S)
BACKUP_DIR="/backups/media"
S3_BUCKET="s3://portal-talentos-backups/media"
MEDIA_DIR="/opt/portal-talentos/backend/media"

mkdir -p $BACKUP_DIR

echo "[$(date)] Iniciando backup de arquivos de mídia..."

tar -czf $BACKUP_DIR/media_${DATE}.tar.gz -C $MEDIA_DIR .

aws s3 sync $BACKUP_DIR/ $S3_BUCKET/ --delete

find $BACKUP_DIR -name "*.tar.gz" -mtime +30 -delete

echo "[$(date)] Backup de mídia concluído: media_${DATE}.tar.gz"

4.3 Agendamento de Backups (Cron)

# /etc/cron.d/portal-talentos-backup

0 3 * * * root /opt/scripts/backup-database.sh >> /var/log/backup-db.log 2>&1
0 4 * * * root /opt/scripts/backup-media.sh >> /var/log/backup-media.log 2>&1
0 */6 * * * root /opt/scripts/backup-incremental.sh >> /var/log/backup-incr.log 2>&1

4.4 Verificação de Integridade

#!/bin/bash
# /opt/scripts/verify-backup.sh

LATEST_BACKUP=$(ls -t /backups/database/*.enc | head -1)

openssl enc -aes-256-cbc -d -pbkdf2 \
    -in $LATEST_BACKUP \
    -out /tmp/test_restore.dump.gz \
    -pass file:/opt/scripts/.backup_key

gunzip -t /tmp/test_restore.dump.gz

rm /tmp/test_restore.dump.gz

echo "[$(date)] Verificação de integridade: OK"

5. Procedimentos de Recuperação

5.1 Recuperação de Falha Total do Sistema

Passo 1: Avaliação Inicial (0-15 min)

docker-compose -f docker-compose.prod.yml ps
docker-compose -f docker-compose.prod.yml logs --tail=100
ping -c 3 localhost
curl -I http://localhost:8080/api/v1/health/

Passo 2: Tentativa de Reinicialização (15-30 min)

docker-compose -f docker-compose.prod.yml down
docker system prune -f
docker-compose -f docker-compose.prod.yml up -d
sleep 30
docker-compose -f docker-compose.prod.yml ps

Passo 3: Verificação de Serviços (30-45 min)

docker-compose -f docker-compose.prod.yml exec backend python manage.py check
docker-compose -f docker-compose.prod.yml exec backend celery -A app status
curl -I https://seu-dominio.com.br/api/v1/health/

5.2 Recuperação de Banco de Dados Corrompido

Passo 1: Parar Serviços Dependentes

docker-compose -f docker-compose.prod.yml stop backend worker beat

Passo 2: Identificar Último Backup Válido

aws s3 ls s3://portal-talentos-backups/database/ --recursive | sort | tail -10

Passo 3: Download e Descriptografia do Backup

aws s3 cp s3://portal-talentos-backups/database/db_YYYYMMDD_HHMMSS.dump.gz.enc /tmp/

openssl enc -aes-256-cbc -d -pbkdf2 \
    -in /tmp/db_YYYYMMDD_HHMMSS.dump.gz.enc \
    -out /tmp/db_restore.dump.gz \
    -pass file:/opt/scripts/.backup_key

gunzip /tmp/db_restore.dump.gz

Passo 4: Restauração do Banco

docker-compose -f docker-compose.prod.yml exec postgres psql -U portal_talentos_user -d postgres -c "
    SELECT pg_terminate_backend(pid)
    FROM pg_stat_activity
    WHERE datname = 'portal_talentos_db' AND pid <> pg_backend_pid();"

docker-compose -f docker-compose.prod.yml exec postgres psql -U portal_talentos_user -d postgres -c "DROP DATABASE IF EXISTS portal_talentos_db;"
docker-compose -f docker-compose.prod.yml exec postgres psql -U portal_talentos_user -d postgres -c "CREATE DATABASE portal_talentos_db;"

cat /tmp/db_restore.dump | docker-compose -f docker-compose.prod.yml exec -T postgres pg_restore -U portal_talentos_user -d portal_talentos_db

Passo 5: Verificação e Reinicialização

docker-compose -f docker-compose.prod.yml exec postgres psql -U portal_talentos_user -d portal_talentos_db -c "SELECT COUNT(*) FROM accounts_user;"

docker-compose -f docker-compose.prod.yml start backend worker beat

docker-compose -f docker-compose.prod.yml exec backend python manage.py check

5.3 Recuperação de Ataque Ransomware

Passo 1: Isolamento Imediato

sudo ufw deny from any
docker-compose -f docker-compose.prod.yml down

Passo 2: Documentação do Incidente

• Capturar screenshots
• Salvar logs
• Registrar timeline

Passo 3: Análise Forense

docker logs portal-talentos-backend-1 > /evidence/backend_logs.txt
sudo cp -r /var/log /evidence/system_logs

Passo 4: Restauração em Ambiente Limpo

# Em servidor limpo/novo
git clone https://github.com/Tav-Web/portal-talentos.git /opt/portal-talentos

# Restaurar backup de data anterior ao ataque
# Aplicar patches de segurança antes de colocar online

Passo 5: Verificação de Segurança

• Trocar todas as senhas e tokens
• Revogar e regenerar certificados
• Verificar integridade do código

6. Plano de Comunicação

6.1 Templates de Comunicação

Template: Comunicação Inicial de Incidente

ASSUNTO: [SEVERIDADE] - Incidente no Sistema Acesso ao Emprego

SITUAÇÃO: [Em investigação / Identificado / Em resolução]

DATA/HORA: [Timestamp]

IMPACTO:
- Serviços afetados: [Lista de serviços]
- Usuários impactados: [Estimativa]
- Funcionalidades indisponíveis: [Lista]

AÇÕES EM ANDAMENTO:
- [Ação 1]
- [Ação 2]

PRÓXIMA ATUALIZAÇÃO: [Data/hora]

Equipe de Resposta a Incidentes

Template: Atualização de Status

ASSUNTO: [ATUALIZAÇÃO] - Incidente no Sistema Acesso ao Emprego

STATUS ATUAL: [Progresso]

TIMELINE:
- [HH:MM] - Ação realizada
- [HH:MM] - Ação realizada

PREVISÃO DE RESOLUÇÃO: [Estimativa]

PRÓXIMA ATUALIZAÇÃO: [Data/hora]

Template: Resolução de Incidente

ASSUNTO: [RESOLVIDO] - Incidente no Sistema Acesso ao Emprego

O incidente foi resolvido às [HH:MM].

CAUSA RAIZ:
[Descrição técnica da causa]

RESOLUÇÃO:
[Descrição das ações tomadas]

IMPACTO TOTAL:
- Duração: [X horas/minutos]
- Serviços afetados: [Lista]
- Dados perdidos: [Se aplicável]

AÇÕES PREVENTIVAS:
- [Ação 1]
- [Ação 2]

LIÇÕES APRENDIDAS:
[Breve descrição]

Equipe de Resposta a Incidentes

6.2 Lista de Distribuição

Grupo	Quando Notificar	Canal
Equipe Técnica	Todos os incidentes	Slack/WhatsApp
Gestão TI	Severidade Alta/Crítica	Email + Telefone
Usuários Internos	Impacto > 30 min	Email
Gestão Executiva	Severidade Crítica	Telefone

7. Testes do Plano

7.1 Cronograma de Testes

Tipo de Teste	Frequência	Responsável	Próxima Data
Restauração de Backup	Mensal	DBA	[Data]
Simulação de Failover	Trimestral	Infraestrutura	[Data]
Teste de DR Completo	Semestral	Coordenador	[Data]
Revisão do Plano	Anual	Todos	[Data]

7.2 Checklist de Teste de Recuperação

• Backup mais recente identificado
• Download do backup executado com sucesso
• Descriptografia do backup validada
• Restauração em ambiente de teste concluída
• Integridade dos dados verificada
• Aplicação funcionando corretamente
• Tempo de recuperação dentro do RTO
• Documentação do teste atualizada

7.3 Registro de Testes

Data	Tipo	Resultado	Tempo	Observações
[Data]	Restauração DB	Sucesso/Falha	[X min]	[Notas]

8. Manutenção do Plano

8.1 Gatilhos de Revisão

O plano deve ser revisado quando:

• Ocorrer mudança significativa na infraestrutura
• Após qualquer incidente de severidade alta ou crítica
• Mudança na equipe de resposta
• Novos requisitos regulatórios
• Pelo menos uma vez por ano

8.2 Controle de Versões

Versão	Data	Alteração	Autor
1.0.0	Jan/2026	Versão inicial	[Nome]

9. Anexos

9.1 Diagrama de Recuperação

9.2 Contatos de Emergência Externos

Serviço	Contato	Finalidade
Provedor de Nuvem	[Número/Chat]	Suporte de infraestrutura
Registrador de Domínio	[Contato]	Problemas de DNS
Certificadora SSL	[Contato]	Problemas de certificado
ISP	[Contato]	Problemas de conectividade

---

Este documento é confidencial e deve ser tratado de acordo com a política de segurança da informação.