Ficha 02 · Mudança, segurança e incidentes

a) Permite ver o que mudou e quando (diff entre versões), reverter rapidamente para uma versão boa, e restaurar a config num equipamento substituído em minutos. Essencial para diagnóstico e recuperação.

b) Oxidized ou RANCID (recolhem e versionam configs automaticamente), exportar para Git, ou automação com Ansible/Netmiko. Idealmente diário e após cada mudança.

1. Pedido + justificação
2. Avaliação de impacto e risco
3. Aprovação
4. Planear (passos + rollback)
5. Executar na janela de manutenção
6. Verificar (funciona, nada partiu)
7. Documentar

Porque a maioria das interrupções vem de mudanças mal sucedidas — é preciso poder voltar atrás rapidamente para repor o serviço sem depender de improviso a meio da noite.

Exemplo: ao alterar a configuração de OSPF no router core, guardar a config anterior (copy run flash:backup-pre.cfg). Se após a mudança a rede perder rotas, restaura-se a config anterior (configure replace flash:backup-pre.cfg ou recarregar) — serviço reposto em minutos, investiga-se depois com calma.

1. SSH em vez de Telnet; service password-encryption; enable secret.
2. AAA com RADIUS/TACACS+ e contas nominais (não conta partilhada).
3. ACL no acesso de gestão (VTY) — só a VLAN/rede de gestão; idealmente out-of-band.
4. Desativar serviços/portas não usados; port security nas portas de acesso.
5. Firmware atualizado (CVE corrigidos), com janela.
6. Logs centralizados (syslog) + NTP para timestamps corretos.
7. 802.1X/NAC nas portas de acesso.

(5 quaisquer.)

a) Gateway redundante — se o router/gateway falha, outro assume o mesmo IP virtual. b) Agregação de links — soma largura de banda e tolera a falha de um cabo do grupo. c) Prevenção de loops L2 e caminho alternativo se um link cai. d) Energia — mantém os equipamentos a funcionar em falha de corrente. e) Redundância de acesso à Internet (failover de operador).

• RPO (Recovery Point Objective) — quanto de dados/estado se aceita perder (até que ponto no tempo o backup é válido).
• RTO (Recovery Time Objective) — em quanto tempo o serviço tem de estar reposto.

Exemplo escola: configs de rede com RPO de 24 h (backup diário versionado) e RTO de 2 h (substituir um switch e restaurar a config em ≤ 2 h). Servidor de ficheiros: RPO 4 h (snapshots), RTO 4 h.

1. Deteção — alerta de monitorização (switches/links down) e/ou utilizadores.
2. Triagem — quantas salas/utilizadores; severidade (alta — meio edifício).
3. Comunicação — avisar a direção/professores ("incidente em curso, a investigar").
4. Diagnóstico camada a camada — ver topologia: um switch de distribuição/uplink caiu? Loop (STP)? Falha de energia num bastidor? show nos equipamentos vizinhos, painel de monitorização.
5. Conter/mitigar — se for um uplink, ativar caminho redundante; se equipamento, substituir/reiniciar; se loop, isolar a porta.
6. Resolver definitivamente e verificar com utilizadores.
7. Documentar o incidente.
8. Post-mortem (sem culpabilizar): cronologia, causa raiz (ex.: UPS de um bastidor falhou e não havia alerta), o que correu bem/mal, ações corretivas (monitorizar UPS, redundância de energia) com responsáveis e prazos.

Documentos: diagrama físico e lógico, inventário de ativos, plano de endereçamento (sub-redes/VLANs), runbooks, registo de mudanças e de incidentes, contactos/escalonamento.

Perigo de estar desatualizada: numa crise, agir com base num diagrama errado leva a decisões erradas (mexer no equipamento errado, assumir VLAN/IP que já mudou), prolongando a indisponibilidade. Documentação errada engana — é pior do que assumir que não existe e investigar. Por isso deve ser atualizada a cada mudança (parte do processo de gestão de mudança).