Han xifrat les dades del centre: el pla de resposta que hauries de tenir escrit

Han xifrat les dades del centre: el pla de resposta que hauries de tenir escrit

El 26 de juliol es va conèixer que la Junta d'Andalusia investigava un accés no autoritzat al sistema Séneca després d'un atac amb programari maliciós, amb dades de docents i alumnes compromeses. No va ser un cas aïllat ni un objectiu casual. L'INCIBE va gestionar 122.223 incidents durant el 2025, un 26 % més que l'any anterior, i educació apareix sistemàticament entre els sectors més atacats d'Espanya, al costat de sanitat i administració local.

Per què un centre educatiu és un objectiu fàcil

La raó és incòmoda però senzilla. Un centre concentra dades de menors, dades de salut, dades econòmiques de famílies i dades laborals de personal, tot junt, amb pressupostos de seguretat modestos i amb una plantilla que no va ser contractada per detectar correus fraudulents. És un objectiu d'alt valor i baixa resistència.

Aquest article no va de com evitar l'atac, que és un tema llarg i ben cobert. Va del que gairebé cap centre no té escrit: què es fa exactament les primeres hores, quan l'atac ja ha ocorregut.

Les primeres dues hores: contenir, no investigar

L'error més freqüent és voler entendre què ha passat abans d'aturar el que està passant. En un xifratge actiu, cada minut de xarxa connectada és equip addicional afectat. Entendre ve després; aturar ve ara.

Què fer, en aquest ordre

• Aïllar sense apagar: desconnecteu de la xarxa els equips afectats, però no els apagueu. Apagar destrueix evidència en memòria que després farà falta.
• Desconnectar les còpies: si l'emmagatzematge de còpies és accessible des de la mateixa xarxa, desconnecteu-lo. Xifrar-les també és l'objectiu habitual de l'atacant.
• Tallar accessos remots: revoqueu sessions actives i desactiveu els accessos des de fora.
• No tocar res més: no esborreu, no reinstal·leu, no intenteu desxifrar pel vostre compte. Tot això destrueix evidència que el pèrit, l'asseguradora i, si toca, l'autoritat de protecció de dades necessitaran.

Els tres rellotges que comencen a córrer

Aquí hi ha el que gairebé ningú no té clar i el que surt més car. Un incident posa en marxa terminis simultanis amb destinataris diferents:

• 72 hores, RGPD: des que el centre té constància de la bretxa per notificar-la a l'autoritat de protecció de dades, si hi ha risc per als drets de les persones afectades. Si el risc és alt —i amb dades de menors ho és gairebé sempre— cal a més comunicar-ho als propis afectats sense dilació indeguda.
• 24 hores, NIS2: alerta primerenca a l'autoritat competent, aplicable a les entitats incloses en el seu àmbit. Molts centres privats queden fora, però els grups grans i les entitats vinculades a administració pública convé que verifiquin el seu encaix abans de necessitar-ho.
• Les primeres hores, les famílies: un rellotge informal però decisiu. Si el centre no comunica aviat, la informació circularà igualment per grups de missatgeria, sense control i amb versions pitjors que la real.

L'ordre de trucades

Val la pena tenir-lo escrit en una sola pàgina, amb noms i telèfons reals, i actualitzar-lo cada curs:

• Sistemes o proveïdor informàtic: executa la contenció. És la primera trucada, sempre.
• Direcció i titularitat: assumeixen la coordinació i les decisions de comunicació.
• Delegat de protecció de dades: avalua el risc i prepara la notificació.
• Proveïdor de programari de gestió: si les dades afectades són a la seva plataforma, com a encarregat del tractament té obligació d'informar i col·laborar.
• Assessoria jurídica i asseguradora: si hi ha pòlissa de ciberrisc, activar-la aviat condiciona la cobertura.
• INCIBE i forces de seguretat: quan escaigui, i no abans d'haver contingut.

Aquest ordre importa perquè la temptació natural és començar pel final, denunciant, i deixar la contenció per després.

Què es comunica a les famílies i què no

La comunicació inicial ha de sortir encara que no se sàpiga l'abast, i precisament per això ha de dir el que se sap i el que no. Quatre elements: què ha ocorregut en termes comprensibles, quines dades podrien estar afectades, què està fent el centre i què ha de fer la família —normalment, desconfiar de comunicacions que demanin dades o pagaments.

El que no s'ha de fer és minimitzar abans de saber, prometre que no ha passat res o donar detalls tècnics del vector d'atac, que només serveixen a qui vulgui repetir-lo. I convé obrir un canal únic per a preguntes, perquè si no la secretaria queda col·lapsada durant dies.

La pregunta que decideix l'abast

Quan arriba el moment d'avaluar la bretxa, tot es redueix a una pregunta: on viu cada dada. Un centre que té l'expedient acadèmic i les dades econòmiques en una plataforma externa, i només la documentació administrativa a la seva xarxa local, pateix un incident incòmode. Un centre que ho té tot al mateix servidor pateix una crisi amb menors afectats. L'arquitectura decideix el titular.

El que cal preparar abans, no durant

Un pla de resposta que s'escriu el dia de l'incident no és un pla. Hi ha cinc coses que només serveixen si estan fetes abans:

• Còpies provades, no només programades: una còpia que mai no s'ha restaurat és una hipòtesi. Feu una restauració completa de prova almenys un cop l'any, i mantingueu les còpies aïllades de la xarxa que es xifraria.
• Inventari d'on viu cada dada: què hi ha en servidors propis, què a la plataforma de gestió, què en correu i emmagatzematge, què a l'ordinador d'algú. Sense ell no es pot avaluar l'abast en 72 hores.
• Doble factor en tot el que l'admeti: començant pel correu i pels accessos d'administració. És la mesura amb millor relació entre cost i atacs evitats.
• Revisió de permisos: quanta gent pot veure l'expedient complet d'un alumne, i per què. La majoria de bretxes amplifica el seu dany perquè tothom tenia accés a tot.
• Un assaig anual: mitja hora llegint el pla en equip directiu val més que vint pàgines que ningú no ha obert.

Què exigir al proveïdor per contracte

Si les dades són en una plataforma de tercers, el contracte és part del pla de resposta. Convé que fixi un termini concret de notificació —no «sense dilació indeguda» a seques—, un canal d'avís identificat, el compromís de col·laborar en l'avaluació de l'abast i el detall d'on s'allotgen les dades i amb quines mesures.

Cas pràctic (Espanya)

Un grup educatiu amb dos centres va detectar un divendres a la tarda que diversos equips d'administració mostraven fitxers xifrats. El responsable de sistemes va aïllar la xarxa en vint minuts i va desconnectar l'emmagatzematge de còpies, que era en un equip diferent i no va arribar a veure's afectat.

L'avaluació del dissabte va determinar que el que s'havia xifrat era la unitat compartida d'administració: nòmines, contractes i documentació escanejada. L'expedient acadèmic i les dades econòmiques de famílies eren a la plataforma de gestió, allotjada fora i sense relació amb la xarxa atacada, cosa que va reduir dràsticament l'abast.

Es va notificar a l'autoritat el dilluns, dins de termini. Es va comunicar al personal afectat, no a les famílies, perquè les seves dades no estaven compromeses. I la restauració es va completar el dimarts des d'una còpia de la nit de dijous. La pèrdua real va ser d'un dia de feina administrativa.

Conclusió

Cap centre pot garantir que no li passarà. El que sí que pot decidir és en quin estat el troba: amb les còpies provades o sense provar, amb l'inventari fet o per fer, amb una pàgina de telèfons actualitzada o improvisant un divendres a la tarda. Els rellotges de 24 i 72 hores corren igualment, i no admeten l'excusa que era agost.

A Edena allotgem les dades acadèmiques i econòmiques amb còpies gestionades, control d'accessos per perfil i traçabilitat de qui consulta cada expedient, amb compromisos de notificació escrits al contracte. Demana una demo i repassem amb tu quina part de la teva informació quedaria fora de l'abast d'un incident a la teva xarxa local.