Les tres accions correctives amb què va tancar la lliçó anterior —còpies immutables en compte separat, prova de restauració trimestral i alerta d'esborrament— no són resposta a incidents: són una altra disciplina. El pla de resposta et diu com actuar quan l'agenda de 40 clíniques està aturada, però no quant de temps pot estar aturada abans que el negoci no ho resisteixi, ni quantes dades es pot permetre perdre, ni com continuen atenent el Rubén i les clíniques mentre el sistema no torna, ni quant triga de debò una restauració que ningú no ha cronometrat. Aquesta lliçó respon a aquestes quatre preguntes i tanca el mòdul amb l'artefacte que a 02-06 hauria canviat el desenllaç més que cap altre: una còpia verificada.

1. Continuïtat de negoci i recuperació davant desastres: dos plans diferents
2. L'anàlisi d'impacte en el negoci (BIA)
3. RTO i RPO: què són, com es fixen i quant costen
4. Estratègies de còpia de seguretat
5. La prova de restauració: el cor de la lliçó
6. L'escenari ransomware, que trenca els plans clàssics
7. Alta disponibilitat no és còpia de seguretat
8. El pla escrit: DRP i procediments d'emergència
9. Proves del pla i cadència
10. Mètriques i millora contínua

Són complementaris i no substituïbles. Un DRP excel·lent sense BCP significa que durant les 12 hores de recuperació les clíniques no poden fer absolutament res i perden els seus pacients; un BCP excel·lent sense DRP significa que es pot aguantar uns dies a mà, però ningú no sap quan tornarà el sistema ni si les dades existeixen.

I una precisió de vocabulari: en aquest context «desastre» no significa terratrèmol. Per a una pime com Nimbus els desastres realistes són, per ordre de probabilitat: un ransomware, un esborrament accidental massiu, una caiguda prolongada del proveïdor al núvol, un error de migració que corromp dades i, molt lluny, un incendi a l'oficina. El pla s'escriu contra els primers, no contra el darrer.

El BIA (Business Impact Analysis) és el punt de partida obligatori, i respon a una sola pregunta per procés: si això s'atura, quant fa mal i a partir de quan? Sense BIA, els objectius de recuperació es fixen per intuïció o pel que la tecnologia ja fa, que és exactament a l'inrevés.

S'identifiquen els processos de negoci, no els sistemes. El sistema és el mitjà; el procés és allò que el client paga.

El MTPD (Maximum Tolerable Period of Disruption) és el temps màxim que el negoci suporta la interrupció d'aquell procés abans de patir un dany que ja no es repara. Tres regles per fixar-lo bé:

• El fixa negoci, no tecnologia. La Marta i el Rubén saben a partir de quina hora una clínica comença a trucar els seus pacients per reprogramar; la Lucía no.
• No tot és crític. Si al teu BIA tots els processos tenen MTPD d'1 hora, no has fet un BIA: has fet una llista de desitjos, i el resultat serà que no es prioritza res.
• L'impacte no és lineal. Fixa't en la taula: dues hores de caiguda són una molèstia i vint-i-quatre són una crisi. Per això el BIA es mesura per trams, no amb un únic número.

Una observació sobre el cas de Nimbus que convé interioritzar: el procés més crític (reserves, MTPD de 4 h) no és el que gestiona més dades, i el que gestiona més dades sensibles (historial i adjunts) tolera bastant més interrupció. Confidencialitat i disponibilitat tenen prioritats diferents, i per això el registre de riscos de 04-01 donava més ALE a la caiguda que a la fuita tot i ser molt menys greu per esdeveniment.

• RPO (Recovery Point Objective): quantes dades es pot permetre perdre, mesurat en temps. Un RPO d'1 hora significa que, en el pitjor cas, es perd l'últim treball d'una hora. El determina la freqüència de còpia.
• RTO (Recovery Time Objective): quant es pot trigar a tornar. El determinen l'arquitectura i el procediment, i ha de ser sempre menor que el MTPD.

La diferència entre rèplica asíncrona i síncrona mereix una frase: en l'asíncrona l'escriptura es confirma al client abans d'arribar a la còpia, així que és ràpida i pot perdre els últims segons; en la síncrona no es confirma fins que totes dues còpies la tenen, cosa que garanteix RPO zero a canvi de latència en cada escriptura i que un problema a la zona secundària degradi la principal.

Objectius de Nimbus, derivats del BIA i no del desig:

I la regla que evita la conversa circular: RTO i RPO es deriven del MTPD del BIA, i després es comprova si el pressupost els permet. Si no els permet, no es canvia el número al full: es documenta la bretxa com a risc acceptat al registre de 04-01, amb signatura. Un RTO compromès amb un client i no assolible és, a més d'una mentida, un incompliment contractual.

Esquema típic i assenyat per a Nimbus: completa setmanal, incremental diària i còpia contínua del registre de transaccions de PostgreSQL —aquesta última és la que permet un RPO de 15 minuts, perquè habilita la recuperació a un punt en el temps—.

Ja va aparèixer a 02-04; aquí es desenvolupa, perquè cada dígit respon a una fallada diferent:

Els dos darrers dígits són els que separen aquesta regla de la clàssica 3-2-1, i són exactament els que li faltaven a Nimbus a 02-06. El quart dígit —immutabilitat— és el que impedeix l'esborrament del dia 20 a les 02:10; el cinquè —verificació— és el que hauria revelat, setmanes abans, que l'única còpia alternativa era un disc extern de cinc setmanes que ningú no havia provat.

Sobre la immutabilitat hi ha un matís que decideix la seva eficàcia: ha de ser en un compte les credencials del qual producció no conegui, i amb retenció bloquejada de manera que ni tan sols l'administrador pugui escurçar-la durant el període fixat. Si el mateix conjunt de credencials que gestiona producció pot desactivar la retenció, la immutabilitat és una etiqueta, no un control.

Retenció i versionat. Nimbus conserva: 7 còpies diàries, 4 setmanals, 12 mensuals i 1 anual. La retenció llarga no és caprici: una corrupció silenciosa o un esborrament lògic poden descobrir-se setmanes després, i amb només set dies de retenció ja s'ha replicat el problema a totes les còpies.

Xifratge de la còpia, amb la clau fora de l'entorn (03-07). Les còpies contenen les mateixes dades que producció i viatgen a llocs menys vigilats, així que van xifrades. I la clau no pot ser on és allò que es xifra: si la clau de les còpies viu al mateix gestor de secrets que l'atacant ja controla, el xifratge no aporta res davant la doble extorsió. Custòdia separada, amb procediment de recuperació de la clau provat —perdre la clau de la còpia és perdre la còpia—.

Què es copia a més de les dades, i que gairebé ningú no inclou: la configuració de la infraestructura (idealment com a codi, versionada al repositori), la definició dels recursos al núvol, els secrets —xifrats i amb custòdia separada—, els certificats, la configuració del proveïdor d'identitat i la mateixa documentació de recuperació. Restaurar una base de dades sense poder reconstruir la infraestructura que la serveix allarga el RTO en dies.

I què NO cobreix una còpia. És la part que produeix sorpreses: l'esborrament lògic replicat —si esborres una fila i la còpia se sincronitza, la còpia també l'esborra—; la corrupció propagada, quan un error d'aplicació fa setmanes que escriu dades incorrectes que totes les còpies contenen fidelment; les dades que només viuen en un SaaS que ningú no exporta; i els canvis d'esquema, perquè una còpia de fa sis mesos pot no ser restaurable a l'aplicació actual sense un procés de migració.

Una còpia no verificada no és una còpia: és una esperança. Aquesta frase resumeix el mòdul sencer, i en el cas de 02-06 va ser literal: existia una còpia i no servia. Les tres coses que només es descobreixen restaurant de debò són que el fitxer és íntegre i llegible, que el procediment funciona amb la documentació que hi ha escrita, i quant es triga en realitat —que és sempre més que l'estimació—.

Cinc decisions de l'script que són de mètode. Es cronometra, perquè la dada més valuosa de la prova no és «va funcionar», sinó «va trigar 55 minuts» comparat amb l'RTO compromès. Es verifica el hash abans de restaurar, per no descobrir la corrupció a mitges. Es compara el nombre de files amb producció, perquè pg_restore pot acabar amb èxit havent restaurat una còpia truncada. Es comprova la coherència referencial amb la consulta de files òrfenes, que detecta una restauració parcial que les xifres globals amagarien. I es destrueix l'entorn en acabar, perquè conté dades reals de pacients i un entorn de prova oblidat és exactament l'A-22 amb classificació «a revisar» de l'inventari d'01-04.

El camp troballes de l'informe és el que justifica tot l'exercici: la prova ha de produir troballes. Una prova de restauració que surt perfecta a la primera gairebé sempre significa que es va provar el que era fàcil.

Els plans de recuperació tradicionals es van dissenyar contra la fallada tècnica: un disc que es trenca, un centre de dades que s'inunda. El ransomware amb doble extorsió trenca quatre supòsits d'aquell model:

D'aquí les quatre exigències específiques davant ransomware. Immutabilitat real, amb retenció bloquejada que ningú no pugui escurçar. Aïllament de les credencials de còpia: el compte que escriu les còpies no ha de poder esborrar-les, i el que les llegeix per restaurar ha de ser diferent i estar fora de l'abast de producció. Còpia offline o lògicament aïllada com a últim recurs. I un RTO calculat per a l'escenari de reconstrucció completa, no per al de restaurar un fitxer: si Nimbus promet 4 hores i el seu escenari de ransomware exigeix 3 dies, té un compromís que no pot complir i ho ha de saber abans de signar-lo.

Nota de validació. La decisió sobre el pagament d'un rescat, les obligacions de notificació derivades de l'exfiltració i les condicions de cobertura de l'assegurança són qüestions jurídiques i contractuals, no tècniques. Es consulten amb assessoria jurídica, amb el responsable de compliment i amb l'asseguradora, la pòlissa de la qual sol imposar procediments concrets (04-01, 04-05).

La fila decisiva és la tercera. Una rèplica no és una còpia perquè replica els errors amb la mateixa diligència amb què replica els encerts. Confondre-les és un dels errors més cars i més freqüents: «tenim alta disponibilitat» no respon a «i si algú esborra la taula de cites?».

A més de la redundància, el BCP compta amb la degradació elegant: dissenyar el sistema perquè, davant una fallada parcial, continuï oferint l'essencial. A Nimbus significa que si el bucket d'adjunts no respon, l'agenda ha de continuar funcionant en mode només lectura de cites en lloc de retornar un error general. Cada grau de degradació que el sistema suporta redueix l'impacte per hora del BIA, i sol ser més barat que pujar un esglaó de la taula de RTO.

Restaurar en l'ordre equivocat allarga el RTO i produeix errors confusos. L'ordre es deriva del mapa de dependències de l'inventari d'01-04:

Dos avisos sobre el diagrama. El pas 7 es deixa per al final expressament: reactivar les integracions abans de validar pot disparar centenars de correus o de cobraments duplicats amb dades restaurades. I el pas 8 no és opcional: la conciliació —comprovar quines cites es van crear entre l'RPO i el desastre i no hi són— és la feina que converteix una restauració tècnica en una recuperació de negoci.

Mentre dura el RTO, el negoci ha de continuar. Aquesta és la part del pla que no és tècnica i la que més agraeixen els clients:

La primera fila conté la idea més rendible d'aquesta lliçó: una exportació diària automàtica que cada clínica ja té al seu correu converteix una catàstrofe operativa en una molèstia, costa gairebé res i funciona fins i tot si Nimbus sencer ha desaparegut.

El simulacre parcial trimestral és el que té millor relació cost-valor i el que Nimbus no es pot saltar. El complet anual convé fer-lo en finestra planificada i avisant els clients: un simulacre que surt malament en horari acordat és aprenentatge; la mateixa fallada en un desastre real és una crisi.

I una regla que tanca el cicle del mòdul: tota prova produeix troballes, i tota troballa es converteix en una acció amb propietari i data que entra al registre de riscos de 04-01 i, si escau, al catàleg de controls de 04-03. Sense això, provar és una cerimònia.

La mètrica que més sorprèn en mesurar-la per primera vegada és la de cobertura: gairebé sempre apareix algun sistema crític —la configuració del proveïdor d'identitat, el gestor d'incidències, les dades d'un SaaS— que ningú no estava copiant perquè tothom assumia que ho feia el proveïdor. És la responsabilitat compartida de 04-04 manifestant-se a la pràctica.

• Tenir còpies i no haver-les restaurat mai. És l'error del mòdul sencer, i va ser literal a 02-06. Consell: la prova trimestral al calendari, amb informe i troballes; sense informe, la prova no va passar.
• Fixar el RTO pel que la tecnologia ja fa. En surt un número còmode i fals. Consell: primer el BIA i el MTPD, després la tecnologia, i si no hi arriba, es documenta com a risc acceptat amb signatura.
• Còpies accessibles amb les mateixes credencials que producció. És el que va permetre l'esborrament del dia 20. Consell: compte separat, retenció bloquejada i credencials de còpia que producció no conegui.
• Confondre alta disponibilitat amb còpia de seguretat. La rèplica replica els errors. Consell: pregunta't sempre «i si algú esborra la taula?».
• Xifrar la còpia i guardar la clau dins de l'entorn xifrat. Consell: custòdia separada i procediment de recuperació de la clau provat.
• Copiar les dades i no la configuració. Restaurar una base de dades sense poder aixecar la infraestructura allarga el RTO en dies. Consell: infraestructura com a codi versionada, i també a la còpia.
• Retenció massa curta. Una corrupció descoberta al cap de tres setmanes ja és a totes les còpies. Consell: retenció esglaonada diària/setmanal/mensual/anual.
• Pla que només existeix al sistema que pot caure. Consell: còpia impresa i fora de banda, igual que el pla de resposta.
• Oblidar el BCP. Un DRP perfecte deixa el negoci aturat mentre dura el RTO. Consell: comença per l'exportació diària de l'agenda; és gairebé gratis.

Nimbus vol llançar un mòdul de teleconsulta per a les clíniques. Negoci estima que si el mòdul cau, les clíniques poden reprogramar per telèfon, però més de 2 hores de caiguda en horari de matí implica perdre les consultes del dia, i que perdre els registres d'una consulta ja realitzada és inacceptable perquè són dades clíniques.

1. Fixa el MTPD, el RTO i el RPO del mòdul, justificant-los.
2. Tria l'estratègia tècnica fent servir la taula de l'apartat 3 i indica el cost relatiu.
3. Proposa dues mesures de degradació elegant que redueixin l'impacte per hora sense pujar d'esglaó de cost.

Aquest és l'informe de la darrera prova de restauració d'una altra empresa:

Identifica tot el que fa que aquest informe no demostri que l'empresa es pot recuperar, i reescriu els camps que falten.

Nimbus té compromès un RTO de 4 hores per a l'API i la base de dades, mesurat a la prova trimestral (55 minuts). Estima el RTO real davant un ransomware com el de 02-06 descomponent-lo en fases, indica on hi ha la major part del temps i proposa tres mesures que el redueixin. Acaba indicant què hauria de fer la Marta amb el compromís de 4 hores.

Exercici 1

(1) MTPD = 2 hores, perquè és el límit que fixa negoci abans d'un dany no reparable (les consultes del dia es perden). El RTO ha de ser menor que el MTPD, així que es fixa en 1 hora, deixant marge per a la detecció i la decisió, que també consumeixen temps del MTPD —error molt comú: fixar RTO = MTPD i descobrir que l'hora de detectar i decidir ja l'ha esgotat—. El RPO ≈ 0-5 minuts, perquè perdre el registre d'una consulta ja realitzada és inacceptable: són dades clíniques que a més poden tenir valor probatori.

(2) Amb RTO d'1 h i RPO de minuts, la taula de l'apartat 3 situa la solució en rèplica asíncrona a una altra zona amb promoció manual (× 2), no en rèplica síncrona (× 3-4). L'asíncrona amb un desfasament de segons compleix un RPO de 5 minuts amb escreix, i la promoció manual cap en 1 hora si el procediment és escrit i provat. Pagar la síncrona aquí seria sobredimensionar: el RPO exigit no és zero, és «minuts», i aquesta distinció val el doble de cost.

(3) Dues mesures de degradació elegant: (a) que l'aplicació de teleconsulta desi localment al dispositiu del professional les notes de la consulta en curs i les sincronitzi en recuperar-se, de manera que una caiguda no destrueixi la feina feta —això redueix l'impacte del RPO sense canviar l'arquitectura de dades—; i (b) un mode degradat en què, si falla el servei de vídeo, la plataforma continuï permetent consultar la fitxa i registrar la consulta, oferint un enllaç telefònic alternatiu: es manté el procés de negoci encara que falli el seu component més car. Totes dues redueixen l'impacte per hora del BIA i cap no puja l'esglaó de cost.

Exercici 2

Problemes de l'informe:

Camps que falten: hash_verificat: true, copia_provada: {recent: ..., antiga: ...}, files: {cites, clients, orfes} amb desviacio_vs_produccio_pct, rpo_real, executada_per i procediment_suficient: true|false, entorn_destruit: true, troballes amb almenys una observació i accions amb propietari i data.

Exercici 3

Descomposició del RTO real davant ransomware:

La major part del temps no és a restaurar, sinó a reconstruir i a confiar. Restaurar és el 3 % del total; el 97 % restant és descobrir l'abast, aixecar un entorn net i verificar que es pot tornar.

Tres mesures que el redueixen de debò: (a) infraestructura com a codi completa i provada, que converteix les 8-24 hores de reconstrucció en 1-2 hores d'aplicar una plantilla —és, amb diferència, la mesura de més impacte—; (b) controls detectius (C-08, C-09 de 04-03), que retallen la fase de detecció de dies a hores i a més redueixen l'abast a investigar; i (c) un entorn de recuperació preparat en un compte separat, amb la xarxa i els rols ja definits, per no crear-lo sota pressió.

Què ha de fer la Marta amb el compromís de 4 hores. No mantenir-lo tal com està. Té tres opcions defensables i una d'inacceptable. Pot qualificar el compromís —4 hores per a fallada tècnica, un objectiu diferent i declarat per a escenaris de compromís de seguretat, que és el que fan els proveïdors seriosos—; pot invertir en infraestructura com a codi i en l'entorn de recuperació preparat per acostar l'escenari de ransomware a les 4 hores; o pot acceptar formalment el risc amb signatura de direcció i caducitat (04-01) mentre executa l'anterior. L'inacceptable és deixar el número tal qual al contracte: un RTO compromès i no assolible és un incompliment contractual esperant la seva data, i a més falseja el risc residual del registre.

Has tancat el mòdul amb la disciplina que decideix si l'empresa sobreviu. Distingeixes BCP i DRP com a plans complementaris i no substituïbles —que el negoci continuï davant que la tecnologia torni—, i saps que per a una pime «desastre» no significa terratrèmol: significa ransomware, esborrament massiu, caiguda del proveïdor o migració corrupta. Saps construir un BIA identificant processos de negoci i no sistemes, amb el seu MTPD fixat per negoci i no per tecnologia, mesurat per trams perquè l'impacte no és lineal, i amb l'observació que reordena prioritats: a Nimbus el procés més crític per disponibilitat no és el que manega les dades més sensibles.

Domines RTO i RPO —quant es triga a tornar i quantes dades es perden—, la seva relació amb el MTPD, la taula que tradueix cada objectiu en una estratègia tècnica i en un cost relatiu, la diferència entre rèplica asíncrona i síncrona, i la regla que evita la conversa circular: es deriven del BIA i, si el pressupost no hi arriba, es documenta la bretxa com a risc acceptat amb signatura, mai no es canvia el número al full. Coneixes les estratègies de còpia —completa, incremental i diferencial— i la regla 3-2-1-1-0 dígit a dígit, amb els dos darrers dígits com a protagonistes perquè són justament els que li faltaven a Nimbus a 02-06: l'1 d'immutable, que només compta si la retenció està bloquejada i les credencials de còpia són alienes a producció, i el 0 de verificat. Saps què més cal copiar a més de les dades —configuració, infraestructura com a codi, secrets, certificats i la mateixa documentació— i què no cobreix una còpia: l'esborrament lògic replicat, la corrupció propagada, les dades que només viuen en un SaaS i els canvis d'esquema.

T'endús el cor de la lliçó: una còpia no verificada no és una còpia, és una esperança, amb els quatre tipus de prova, un script de restauració a entorn aïllat que cronometra el RTO real, verifica el hash abans de restaurar, compara files amb producció, comprova la coherència referencial i destrueix l'entorn en acabar, i un informe en què el camp de troballes és el que justifica l'exercici. Saps per què el ransomware trenca els plans clàssics —còpies accessibles que es xifren, reconstrucció en lloc de restauració, RTO multiplicat i confidencialitat que no es recupera—, per què l'alta disponibilitat no és còpia de seguretat —replica el DELETE amb la mateixa diligència—, i què aporta la degradació elegant. I tens el pla escrit: l'ordre d'arrencada per dependències amb els seus dos avisos, els procediments manuals d'emergència encapçalats per la idea més rendible de la lliçó —l'exportació diària de l'agenda que cada clínica ja té al seu correu—, la plantilla completa de DRP, la cadència de proves amb el simulacre parcial trimestral com a peça irrenunciable, i les mètriques, entre les quals la de cobertura sempre revela algun sistema crític que ningú no estava copiant.

Amb això, el Mòdul 4 està complet i forma un sistema. Saps què protegir i amb quina prioritat, mitjançant una avaluació de riscos defensable amb el seu registre viu, el seu apetit signat i les seves quatre estratègies de tractament (04-01). Saps sota quines regles, amb una jerarquia documental que fa que les decisions sobrevisquin a qui les va prendre i un registre d'excepcions amb caducitat obligatòria (04-02). Saps amb quines mesures, amb un catàleg de controls classificats per naturalesa i per funció, mesurats per cobertura i no per existència, i traçats fins a la seva evidència (04-03). Saps fins on arriba el teu perímetre, amb un mapa de tercers, diligència deguda proporcionada, clàusules contractuals i la cadena de subministrament de programari (04-04). Saps com reaccionar, amb un pla escrit abans, evidències preservades, comunicació honesta i post mortem sense culpables (04-05). I saps com tornar, amb objectius derivats del negoci i còpies verificades (04-06).

Però fixa't en una paraula que ha aparegut en les sis lliçons sense desenvolupar-se mai: verificar. El catàleg de controls exigeix comprovar que l'MFA cobreix el 100 % dels comptes; l'escaneig extern mensual ha de descobrir si el port 5432 s'ha tornat a obrir; les alertes d'exfiltració han d'existir i disparar-se; les proves d'autorització per tenant s'han d'executar en cada fusió; i algú ha de buscar activament les vulnerabilitats abans que l'atacant. Tot això és feina tècnica amb eines concretes que aquest mòdul ha anomenat sense ensenyar.

Al Mòdul 5: Eines i Tècniques de Seguretat passem de la gestió a l'execució: eines d'anàlisi de vulnerabilitats (05-01) per trobar el que hi ha exposat, tècniques de monitoratge i detecció (05-02) per construir per fi els controls detectius que a Nimbus li falten, proves de penetració (05-03), seguretat en xarxes (05-04), seguretat en aplicacions (05-05), hardening de l'endpoint (05-06) i seguretat al núvol i en contenidors (05-07). Deixem de preguntar què val la pena protegir i comencem a comprovar, amb eines a la mà, si de debò està protegit.