Un web hackejat té una habilitat força irritant: obligar a decidir-ho tot quan menys temps hi ha per pensar. Qui pot aturar el checkout, on és la còpia, qui parla amb l’allotjament i qui autoritza tornar a vendre. Si les respostes viuen al cap d’una sola persona, el problema ja arriba amb suplement.
Aquest pla de recuperació de WordPress per al 2027 ajuda a preparar aquestes decisions abans de l’incident i a assajar-les sense modificar producció. Inclou una fitxa copiable, responsabilitats, condicions de reobertura i un exercici fictici per descobrir mancances. No substitueix la investigació tècnica ni certifica que un web estigui net.
L’incident està passant ara? Comença per l’avaluació de recuperació de WordPress hackejat. Tenir un pla ajuda; omplir una plantilla mentre els visitants continuen exposats no ha de retardar la contenció adequada.
Què ha de resoldre el pla, abans de parlar d’eines
Separa tres resultats: recuperar el control, recuperar el servei i recuperar la continuïtat del negoci. Entrar a l’administrador resol una part del primer. Veure la portada resol una part del segon. Cap d’aquestes dues coses demostra que comandes, formularis o permisos siguin correctes.
Escriu què necessita el negoci per funcionar amb seguretat: rebre sol·licituds, donar accés a clients, publicar informació o vendre. Prioritza aquests recorreguts i les persones que en depenen. Un web corporatiu sense botiga també pot perdre contactes, documents privats o el control del correu de recuperació.
Després estableix qui pot acceptar una interrupció i què necessita saber per decidir. Evita prometre una recuperació en un nombre d’hores que ningú no ha provat. El pla ha de permetre escollir el pas següent amb informació incompleta i deixar visible aquesta incertesa.
La fitxa de recuperació que pots copiar
Desa una còpia accessible encara que WordPress i el correu habitual no funcionin. Substitueix cada marcador per una referència interna. Aquí hi van ubicacions i responsables; les contrasenyes pertanyen al gestor de secrets aprovat.
PLA WP-2027 | versió i data de revisió:
Domini i entorn de producció:
Responsable de l'incident / substitut:
Canal independent i contacte de l'allotjament:
Persona autoritzada a contenir / aprovar despesa:
Recorreguts de negoci que cal protegir:
Ubicació protegida de còpies i registres:
Última restauració assajada / resultat / límits:
Pèrdua de dades tolerable proposada / aprovada per:
Temps objectiu proposat / prova que el sustenta:
Responsable de conciliació de dades recents:
Criteris de reobertura / qui els revisa:
Alternativa segura si falla la reobertura:
Pròxima revisió / tasques pendents / responsables:Una casella buida és una tasca, no una invitació a inventar la dada. Si ningú no sap quan es va assajar la restauració, escriu «sense prova disponible». Si el proveïdor conserva registres durant un termini concret, anota la resposta i la data sense atribuir-li una garantia diferent.
Afegeix la ubicació de l’inventari de proveïdors: DNS, CDN, allotjament, correu, còpies, repositori i passarel·la quan n’hi hagi. La fitxa enllaça aquests documents; no necessita convertir-se en una enciclopèdia amb dades que caducaran sense que ningú les revisi. Els documents enllaçats també necessiten responsable.
Quatre responsabilitats que han de tenir nom
En una empresa petita, una persona pot assumir diversos papers. El que no convé és que tothom pensi que la decisió correspon a algú altre. Per a cada funció escriu titular, substitut i manera de localitzar-lo fora del correu del web.
| Funció | Decisió | Registre mínim |
|---|---|---|
| Coordinació | Abast, prioritats i escalat | Incident, responsables i pròxima revisió |
| Tècnica i allotjament | Contenció, conservació i recuperació | Canvi, motiu, abast i alternativa segura |
| Negoci | Conciliació i acceptació de recorreguts | Dades pendents, proves i aprovació |
| Comunicació | Missatges aprovats i destinataris | Fets confirmats, hora i pròxima actualització |
Una aprovació comercial no transforma un dubte tècnic en una comprovació superada. Si dues funcions discrepen, registra el punt concret i escala’l. Per a possibles problemes amb dades de clients o pagaments, activa els responsables i procediments corresponents; aquest document no determina obligacions de comunicació.
Preparar l’accés sense fabricar una altra porta del darrere
Comprova que el propietari pot acreditar la titularitat davant l’allotjament i recuperar els canals de control. El pla ha d’indicar quin procediment seguir si el correu d’administrador també està compromès. Enviar un altre enllaç de recuperació a la mateixa bústia no resol aquesta dependència.
Defineix accés individual i limitat per a qui intervingui, com s’autoritza i quan es revoca. No deixis un compte administratiu compartit «per si de cas», ni contrasenyes a la plantilla. La guia de recuperació segura de l’administrador bloquejat desenvolupa aquest recorregut tècnic.
Assaja la localització del contacte i la documentació amb el propietari. Veure un nom a l’inventari no demostra que respongui, que conservi accés o que la seva autorització continuï vigent. El simulacre ha de descobrir aquestes dependències amb temps per resoldre-les.
Còpies: defineix què recuperaries i què perdries
Una còpia té data, contingut, ubicació i estat de prova. «Tenim backup» deixa massa preguntes obertes. Identifica si inclou fitxers i base de dades, qui pot obtenir-la i on es podria restaurar sense sobreescriure l’única evidència de l’incident.
L’objectiu de pèrdua de dades tolerable s’acostuma a expressar com a RPO; el temps objectiu per recuperar el servei, com a RTO. Són objectius del negoci, no resultats per haver escrit les sigles. Si la prova no assoleix el que s’havia previst, registra la diferència i decideix quina inversió o canvi cal.
Per a una botiga, compara la data de la còpia amb comandes, pagaments i moviments posteriors. Per a un web de captació, fes-ho amb formularis i CRM. Conserva les fonts abans d’escollir una restauració: la recuperació des d’una còpia sense reintroduir la intrusió necessita avaluar codi, accés i dades, a més de disponibilitat.
Una referència visual per ordenar decisions
La idea útil és associar cada incidència amb responsable i estat. Pots fer-ho en un document senzill: «contingut», «pendent de verificar» i «aprovat per reobrir» han de significar coses diferents. Una barra de progrés bonica no substitueix la prova que falta.
Simulacre original: l’allotjament proposa restaurar ahir
El cas següent és fictici. És un exercici de taula dissenyat per a aquesta plantilla, sense executar un hackeig, restauració, compra ni cobrament. No descriu un client ni mesura temps de recuperació. Fes servir sis targetes, per ordre, i demana a l’equip que escrigui la decisió abans de llegir la següent.
Escenari: una botiga WordPress rep un avís de redirecció. L’allotjament ofereix una còpia del dia anterior; l’administrador no pot entrar i hi ha pagaments posteriors a aquesta còpia. La pregunta no és qui troba abans el botó de restaurar, sinó què s’ha de resoldre per autoritzar una intervenció.
- Avís sense abast confirmat. Coordinació registra símptoma, hora i font; tècnica proposa contenció adequada al risc. Falta determinar l’abast. No es marca «net» perquè desaparegui una redirecció.
- Còpia disponible. Tècnica identifica data, components i ubicació protegida. Demana conservar l’estat actual i els registres abans de sobreescriure. La disponibilitat de la còpia no demostra que sigui un punt de recuperació fiable.
- Correu de recuperació dubtós. El propietari activa el canal alternatiu amb el proveïdor. Es documenta qui valida la titularitat. Recuperar una sessió de WordPress encara no tanca la cadena d’accés.
- Pagaments posteriors. Negoci identifica la finestra de conciliació i el seu responsable. No repeteix cobraments ni força estats. Recuperar dades recents queda com a condició explícita, enllaçada al seu expedient protegit.
- El web torna a carregar. Tècnica lliura les comprovacions i els seus límits; negoci verifica els recorreguts acordats. Qualsevol prova incompleta conserva el seu estat. Ningú no transforma una portada visible en permís automàtic per vendre.
- Reapareix el símptoma. S’aplica l’alternativa de contenció aprovada i es conserva l’observació. El pla no retorna trànsit a una arrel infectada com a suposat rollback. Coordinació reobre l’incident i assigna la investigació següent.
En acabar, revisa quines decisions depenien d’algú absent o d’una dada inexistent. Aquests són els resultats de l’exercici: tasques concretes amb responsable. Si voleu mesurar durada, feu-ho al vostre simulacre real i anoteu les condicions; aquest exemple no aporta una durada observada.
Del simulacre a tres tasques que es poden tancar
En l’escenari anterior, «millorar les còpies» seria una conclusió massa còmoda. Converteix cada mancança en una tasca amb una sortida comprovable. Aquestes tres continuen sent propostes de l’exercici fictici, no feines realitzades en una botiga.
- REC-01: contacte alternatiu. El propietari ha de localitzar el procediment d’acreditació amb l’allotjament i comprovar qui pot utilitzar-lo. Tancament proposat: referència del procediment, titular i substitut confirmats, sense copiar documents d’identitat al pla.
- REC-02: restauració aïllada. Tècnica ha de proposar un entorn sense exposició pública ni enviaments, cobraments o sincronitzacions accidentals. Tancament proposat: restauració assajada, components identificats, resultat registrat i límits documentats. Tenir una data reservada per provar-ho encara no tanca la tasca.
- REC-03: dades posteriors. Negoci ha d’identificar les fonts de pagaments i comandes de la finestra pendent. Tancament proposat: responsable, fonts autoritzades, criteris de conciliació i prova acordada. Una xifra total de vendes no substitueix la relació entre cada pagament i la seva operació.
Prioritza segons el bloqueig que elimina cada tasca i qui en depèn. Si REC-01 impedeix obtenir la còpia, no té sentit declarar el pla llest perquè REC-03 tingui un document preciós. El resultat útil és saber què es pot executar i què continua condicionat.
Condicions de reobertura que es puguin revisar
Prepara una llista amb quatre estats: superat, fallit, incomplet i no aplicable amb motiu. Cada requisit necessita responsable, evidència i data. L’aprovació s’ha de referir a una versió recuperada concreta i als recorreguts provats, no a «el web» de manera indefinida.
Inclou control de comptes, tractament del punt d’entrada, procedència del codi, revisió de dades i comprovació del símptoma original. Afegeix les funcions de negoci afectades i què passarà si torna el problema. La guia per demostrar el tancament d’una recuperació permet desenvolupar la matriu tècnica; valida’n l’abast amb qui intervingui.
El retorn a producció i el tancament de l’incident són decisions diferents. Pot quedar feina de seguiment autoritzada, amb termini i responsable. Els bloquejos de seguretat o la incertesa sobre comandes cobrades necessiten resolució explícita abans de donar aquell recorregut per recuperat.
Què cal demanar al proveïdor de recuperació
Sol·licita un abast inicial per escrit: sistemes inclosos, conservació, accés necessari, lliurables i condicions per ampliar la feina. Diferencia resposta inicial, diagnòstic i recuperació verificada. Són fites diferents i haurien d’aparèixer separades al pressupost i a la conversa.
Demana també qui coordina amb l’allotjament, com tractarà les dades recents i quina evidència lliurarà en acabar. Confirma exclusions: correu, servidor, integracions i dominis associats poden requerir un altre especialista o autorització. Una promesa genèrica de neteja no respon a aquestes dependències.
Per preparar una avaluació de rescat d’un web hackejat, envia domini, símptomes, cronologia resumida, proveïdor i funcions afectades. Indica si hi ha una còpia i la data; no adjuntis bases de clients, arxius infectats ni credencials en un formulari públic. L’accés s’acorda per un canal gestionat.
Com mantenir útil l’edició del 2027
Revisa la fitxa quan canviïn allotjament, persones, passarel·la, sistema de còpies o desplegament. L’any identifica aquesta edició de planificació; no converteix una instrucció en vàlida per a qualsevol instal·lació. Els procediments concrets s’han de contrastar amb les versions i els proveïdors realment utilitzats.
Conserva el resultat del simulacre amb el pla: mancança descoberta, acció, responsable, data prevista i evidència de resolució. Repeteix el recorregut afectat després de corregir-lo. Un document amb data recent però mai assajat continua sent un document sense assajar.
Com a referències de base, consulta la documentació de WordPress sobre llocs compromesos i la seva guia de còpies. La fitxa i el simulacre d’aquest article són eines editorials pròpies per organitzar decisions; no són una certificació de WordPress ni un informe forense.