Pla de contingència
El present Pla de Contingència (PdC) té com a objectiu garantir la continuïtat operativa de la infraestructura de xarxa i serveis davant qualsevol incident greu, ja sigui una fallida de maquinari, un tall de subministrament elèctric, un atac de programari maliciós o qualsevol desastre físic (incendi, inundació).
La nostra organització depèn de manera crítica dels serveis de directori, autenticació, resolució de noms i transferència de fitxers per al funcionament diari. Una aturada no planificada d’aquests serveis genera pèrdues econòmiques directes, interrupció de la productivitat dels usuaris i possibles incompliments de normativa de protecció de dades (RGPD).
La infraestructura es divideix en quatre zones clarament diferenciades:
Anàlisi d'impacte
D’acord amb els actius identificats, hem definit els escenaris d’impacte que justifiquen la implementació d’aquest pla:
- Fallida del servidor DebianDHCP: en menys de 5 minuts, cap equip nou de la xarxa pot obtenir configuració de xarxa, i les renovacions de lloguer d’IP faran que els equips existents perdin connectivitat progressivament.
- Fallida del servidor DebianLDAP: cap usuari podrà autenticar-se al sistema. Tot el personal queda bloquejat fora dels seus equips i serveis. Impacte immediat al 100% de la plantilla.
- Fallida de subministrament elèctric: sense SAI (Sistema d’Alimentació Ininterrompuda), tots els servidors s’apaguen de manera brusca, amb risc de corrupció de dades i danys al sistema de fitxers.
- Atac de ransomware: xifrat de fitxers dels servidors NFS i FTP, amb pèrdua total de dades compartides si no hi ha còpies de seguretat recents i aïllades.
- Incendi o desastre físic: destrucció física del maquinari i les còpies locals. Sense una còpia fora de les instal·lacions, la recuperació seria impossible.
Objectius de recuperació
Per a cada servei crític hem definit dos indicadors fonamentals:
- RTO (Recovery Time Objective): temps màxim tolerable per recuperar el servei.
- RPO (Recovery Point Objective): antiguitat màxima admissible de les dades recuperades.
Sistema d'Alimentació Ininterrompuda (SAI / UPS)
El SAI és la primera línia de defensa davant talls elèctrics. Protegeix els servidors de:
- Talls de subministrament elèctric (el SAI proporciona autonomia per a un apagat segur o fins al restabliment de la llum).
- Microtalls i fluctuacions de tensió que podrien corrompre sistemes de fitxers o danyar el maquinari.
- Sobretensions que poden destruir plaques base i discos durs.
Es recomana la instal·lació del programari NUT (Network UPS Tools) en tots els servidors per monitorar l’estat del SAI i automatitzar l’apagada segura quan la bateria arribi al 20% de càrrega.
Configuració bàsica de NUT en cada servidor:
# /etc/nut/ups.conf | driver = usbhid-ups | port = auto | desc = 'SAI principal'Política de còpies de seguretat
També tenim un a política de backup la qual es contempla tenir i ha fet el meu company@ a la tasca de còpies de seguretat, la recollim al Pla de contingència com a mesura.
Procediment de restauració
En cas de fallida d’un servidor, els passos de restauració són els següents:
- Identificar el servidor afectat i el tipus de fallida (maquinari, sistema operatiu, dades).
- Si és fallida de maquinari: substituir el component i reinstal·lar el SO base. Disposem d’ISOs de Debian i Rocky Linux en el NAS local.
- Restaurar l’última còpia total disponible: rsync -av /backup/YYYYMMDD/ /srv/data/
- Aplicar les còpies incrementals o la diferencial posterior per actualitzar les dades.
- En cas de restauració LDAP: slapadd -l /backup/ldap/últim_fitxer.ldif i reiniciar el servei.
- Verificar funcionament dels serveis: systemctl status slapd / named / dhcpd / vsftpd / nfs-server
- Provar la connectivitat des dels clients Ubuntu/Linux: ping, nslookup, mount NFS, autenticació LDAP.
- Documentar l’incident al registre d’incidències (data, causa, durada, solució aplicada).
Alta disponibilitat i redundància de xarxa
- DNS secundari (slave): el servidor DebianDNS ha de tenir configurada una zona secundària en un altre equip per evitar que la caiguda del primari deixi la xarxa sense resolució de noms.
- Doble connexió WAN: si és possible, es recomana tenir dues línies d’accés a Internet de proveïdors diferents (failover), amb el router configurat per canviar automàticament.
- VLANs i segmentació: la DMZ, la xarxa de laboratori i la xarxa de producció estan separades, de manera que un incident en una zona no es propaga a les altres.
- Clients portàtils: en ser equips portàtils, els usuaris poden treballar de manera offline en cas de caiguda de la xarxa interna, sempre que tinguin còpies locals dels fitxers necessaris (recomanem sincronització amb el servidor NFS via rsync o uniso
Protocol d'actuació: fallida de xarxa
- Verificar l’estat del router.
- Comprovar si el SAI ha activat el bypass per un tall elèctric.
- Verificar la taula d’encaminament: ip route show, ping al gateway.
- Si el DHCP falla: assignar IPs estàtiques temporals als servidors crítics per mantenir la connectivitat.
- Si el DNS falla: configurar temporalment el DNS de Google (8.8.8.8) als clients per mantenir la resolució externa fins a restaurar el servidor.
- Objectiu: temps d’aturada no superior a 2 hores per a serveis crítics de xarxa.
Protocol d'actuació: atac de ransomware o virus
- IMMEDIATAMENT: desconnectar de la xarxa el/s equip/s afectat/s (cable i Wi-Fi) per evitar la propagació.
- Identificar l’abast de l’atac: quants equips i servidors han estat afectats, quins fitxers han estat xifrats.
- NO pagar mai el rescat. No hi ha garanties de recuperació i financia activitats criminals.
- Restaurar els servidors afectats des de la còpia de seguretat del núvol (que no ha estat accessible des de la xarxa local durant l’atac).
- Analitzar el vector d’entrada (phishing, vulnerabilitat no pegada, credencial robada) i aplicar les correccions pertinents.
- Reportar l’incident a l’INCIBE (Institut Nacional de Ciberseguretat) si hi ha dades personals afectades (obligació RGPD).