NIS2 Portugal

2.1. Três Cópias dos Dados

Mantém-se sempre três cópias completas de todos os dados críticos:

• Cópia primária: Dados de produção ativos
• Cópia secundária: Backup local em storage dedicado
• Cópia terciária: Backup remoto ou cloud

Localização das cópias:

• Primária: [Servidores de produção]
• Secundária: [NAS/Storage local]
• Terciária: [Cloud/Datacenter remoto]

2.2. Dois Tipos de Média Diferentes

Os backups são armazenados em pelo menos dois tipos diferentes de média para reduzir o risco de falha simultânea:

• Média 1: [Discos SSD/HDD]
• Média 2: [Cloud storage/Tape]

Isto protege contra falhas específicas de tecnologia (ex: falha de controlador RAID, corrupção de filesystem).

2.3. Uma Cópia Offsite (Externa)

Pelo menos uma cópia completa é mantida numa localização geográfica diferente, protegendo contra:

• Desastres naturais (incêndios, inundações, terramotos)
• Roubos ou vandalismo físico
• Falhas de infraestrutura local (energia, refrigeração)

Localização offsite: [Cloud AWS/Azure, Datacenter secundário, Cofre bancário]

Distância mínima: [50km do site principal]

2.4. Uma Cópia Offline/Air-Gapped

Pelo menos uma cópia é mantida completamente offline (desconectada da rede), protegendo contra:

• Ransomware: Impossível de encriptar se desconectado
• Ciberataques: Inacessível remotamente
• Eliminação acidental/maliciosa: Não pode ser apagado da rede

Solução offline: [Tapes em cofre, Discos externos desconectados, Object lock S3]

Frequência de atualização: [Semanal]

2.5. Zero Erros de Verificação

Todos os backups são verificados e testados para garantir que podem ser restaurados com sucesso. Objetivo: 0% de falhas de restauro.

Procedimentos de verificação:

• Verificação automática de integridade após cada backup (checksums, hash verification)
• Testes de restauro semanais de sistemas críticos
• Testes de restauro completos mensais
• Alertas automáticos de falhas de backup
• Dashboard de monitorização de backups

Meta SLA: 100% de backups verificados, [99.9%] de sucesso de restauros

3.1. Sistemas Classificados

Sistemas CRÍTICOS:

• [Base de dados de produção]
• [Sistema ERP]
• [Website e-commerce]

Sistemas IMPORTANTES:

• [Microsoft 365 / Exchange]
• [Servidor de ficheiros]
• [CRM]

Sistemas NORMAIS:

• [Ambientes de desenvolvimento]
• [Arquivos históricos]

4.1. Calendário Visual de Backups

Exemplo de calendário mensal de backups:

4.2. Janela de Backup

Horário principal de backups: [22:00 - 06:00] (horário de menor atividade)

Backups incrementais contínuos: Durante horário de trabalho para sistemas críticos

5.1. Esquema de Retenção GFS (Grandfather-Father-Son)

Implementação do modelo GFS para otimizar espaço e garantir histórico adequado:

• Son (Filho): Backups diários - retidos por 7 dias
• Father (Pai): Backups semanais - retidos por 4 semanas
• Grandfather (Avô): Backups mensais - retidos por 12 meses
• Archive: Backups anuais - retidos por 7 anos

5.2. Conformidade Legal

Requisitos específicos de retenção:

• RGPD: Dados pessoais retidos apenas pelo tempo necessário (princípio da limitação da conservação)
• Fiscais: [10 anos para documentos contabilísticos]
• Setoriais: [Requisitos específicos do setor]

5.3. Eliminação Segura

Após o período de retenção, os backups são eliminados de forma segura:

• Eliminação certificada de dados em cloud (certificado de destruição)
• Wipe seguro de discos (múltiplas passagens, conformidade DoD 5220.22-M)
• Destruição física de tapes e discos com dados sensíveis
• Registo de todas as eliminações

6.1. Backup de Servidores

Solução: [Veeam / Acronis / Outra]

Procedimento:

1. Backup completo (full) semanal de todos os servidores
2. Backups incrementais diários
3. Snapshots de VMs a cada 4 horas (sistemas críticos)
4. Replicação para storage secundário
5. Cópia para cloud diária
6. Verificação automática de integridade

Sistemas incluídos:

• VMs completas (estado, configuração, dados)
• Configurações de rede e firewall
• Certificados SSL/TLS
• Logs de sistema

6.2. Backup de Bases de Dados

Solução: [SQL Server Backup / pg_dump / Outra]

Procedimento:

1. Transaction log backups a cada hora (SQL Server/Oracle)
2. Backup completo diário
3. Teste de restauro semanal
4. Export de dados críticos em formato portável
5. Replicação para servidor standby (se aplicável)

Bases de dados cobertas:

• [Base de dados ERP]
• [Base de dados CRM]
• [Base de dados e-commerce]

6.3. Backup de Ficheiros e Partilhas

Solução: [Servidor de ficheiros nativo / Sync tool]

Procedimento:

1. Backup incremental diário de todas as partilhas de rede
2. Versionamento de ficheiros (mínimo 30 versões)
3. Sync para cloud storage
4. Cópia offline semanal

6.4. Backup de Microsoft 365 / Google Workspace

Solução: [Veeam for Microsoft 365 / Outra]

Procedimento:

• Backup diário de Exchange Online (emails, calendários, contactos)
• Backup de SharePoint e OneDrive
• Backup de Teams (conversas e ficheiros)
• Retenção independente do fornecedor cloud

Nota: A retenção nativa do M365 não substitui backups independentes (proteção contra eliminação acidental, ransomware, falhas do fornecedor).

6.5. Backup de Aplicações SaaS

Aplicações SaaS críticas com backup independente:

• [Salesforce / Outra CRM]
• [Outras aplicações críticas]

Método: Export API diário + armazenamento em storage próprio

6.6. Backup de Workstations

Solução: [Cloud backup agent / Endpoint backup]

Política:

• Backup automático de pastas críticas (Documentos, Desktop)
• Sync contínuo para cloud
• Image backup mensal para recuperação rápida

6.7. Encriptação de Backups

Todos os backups são encriptados:

• Em trânsito: TLS 1.2+ durante transferência
• Em repouso: AES-256 no storage
• Gestão de chaves: [Azure Key Vault / HSM / Outra]
• Rotação de chaves: [Anual]

7.1. Frequência de Testes

7.2. Procedimento de Teste

1. Planeamento: Definir sistema, dados e âmbito do teste
2. Preparação: Ambiente isolado para restauro (evitar impacto em produção)
3. Execução: Restauro dos dados seguindo procedimentos documentados
4. Validação: Verificar integridade, completude e funcionalidade
5. Medição: Tempo de restauro (verificar se cumpre RTO)
6. Documentação: Registar resultados, problemas encontrados, ações corretivas
7. Reporte: Comunicar resultados ao órgão de gestão

7.3. Checklist de Verificação de Restauro

7.4. Métricas de Sucesso

KPIs de Testes de Restauro:

• Taxa de sucesso: Meta [100%]
• Tempo médio de restauro: Comparar com RTO
• Problemas identificados: Rastreados e resolvidos
• Cobertura de testes: % de sistemas críticos testados anualmente

7.5. Registo de Testes

Todos os testes são documentados em registo próprio incluindo:

• Data e hora do teste
• Sistema/dados testados
• Responsável pelo teste
• Resultado (sucesso/falha)
• Tempo de restauro
• Problemas encontrados
• Ações corretivas

Localização do registo: [SharePoint / Sistema de documentação]

8.1. Órgão de Gestão

• Aprovar a política de backups
• Garantir recursos adequados (orçamento, equipa, ferramentas)
• Revisar relatórios trimestrais de backups
• Aprovar RTO/RPO para sistemas críticos

8.2. Administrador de Backups

Responsável: [Nome do Administrador de Backups]

Responsabilidades:

• Configurar e manter sistemas de backup
• Monitorizar backups diários e investigar falhas
• Executar testes de restauro
• Gerir storage e capacidade
• Manter documentação atualizada
• Reportar métricas mensalmente
• Coordenar recuperações em caso de incidente

8.3. Equipa de IT

Responsável: [Diretor de IT]

• Garantir que novos sistemas são incluídos em backups
• Apoiar testes de restauro
• Validar recuperações após incidentes
• Colaborar na classificação de sistemas (RTO/RPO)

8.4. Proprietários de Dados/Sistemas

Cada departamento é responsável por:

• Identificar dados e sistemas críticos
• Definir requisitos de RTO/RPO
• Validar backups e restauros dos seus sistemas
• Comunicar mudanças que afetem backups

8.5. Todos os Utilizadores

• Guardar ficheiros de trabalho em localizações com backup (partilhas de rede, OneDrive)
• Não desativar backups automáticos de workstations
• Reportar problemas de acesso a ficheiros imediatamente
• Solicitar restauros através dos canais apropriados

8.6. Revisão e Atualização

Esta política é revista:

• Anualmente
• Após incidentes significativos de perda de dados
• Quando há mudanças em sistemas críticos
• Após auditorias que identifiquem gaps

Próxima revisão: [DATA]