Quan acaba la relació amb una agència web, un desenvolupador autònom o un proveïdor tecnològic, eliminar el seu usuari de WordPress acostuma a ser només una part de la feina. El proveïdor pot conservar accés al domini, a l'allotjament web, a les còpies de seguretat, al correu transaccional, als repositoris de codi o a integracions que permeten modificar el web o consultar dades operatives.
El problema concret és retirar aquests accessos sense deixar inoperativa una botiga, els formularis, els avisos de comandes o les renovacions del domini. La solució no consisteix a revocar-ho tot de cop: requereix identificar dependències, assegurar primer el control intern i aplicar un tancament documentat i verificable.
L'abast real dels accessos d'un proveïdor web
Un web corporatiu o un comerç electrònic depèn normalment de diversos serveis connectats. A més de l'administrador del CMS, hi poden haver comptes al registrador del domini, la gestió de DNS, l'allotjament web o el núvol, una CDN, un tallafoc d'aplicacions, plataformes de pagament, eines de correu electrònic, CRM, analítica, monitoratge i sistemes de còpia. Cada servei pot tenir usuaris, tokens, claus o mecanismes de recuperació propis.
El primer risc d'un tancament precipitat és la interrupció: desactivar un compte que renova una credencial d'API pot aturar l'enviament de comandes a l'ERP; retirar un correu de recuperació pot impedir recuperar un compte crític. El segon és mantenir accessos residuals sense saber-ho. OWASP recomana aplicar el principi de mínim privilegi, revisar els permisos periòdicament i denegar l'accés quan no hi hagi una autorització explícita. [2]
Prepareu un inventari abans de revocar cap accés
Abans de canviar contrasenyes o eliminar usuaris, reuniu un inventari d'actius i accessos. Per a cada actiu, anoteu el servei, l'URL o identificador, el propietari intern, els administradors, el proveïdor amb accés, l'ús operatiu, el mètode de recuperació i la data prevista de retirada. Aquest registre permet decidir l'ordre dels canvis i redueix la dependència d'informació dispersa en correus o converses.
Incloeu com a mínim el domini i el DNS; allotjament web, núvol, CDN i WAF; WordPress i la botiga; pagaments; correu sortint i formularis; CRM i automatitzacions; còpies, alertes i monitoratge; repositoris; claus SSH; tokens d'API; aplicacions OAuth i webhooks. També convé registrar sessions actives i comptes de servei, perquè no sempre s'eliminen en suprimir un usuari del CMS.
- Assigneu una persona responsable interna i una suplent per a cada actiu crític.
- Distingiu entre comptes de persones, comptes compartits, comptes de servei i credencials d'integració.
- Marqueu quins serveis afecten les vendes, l'atenció al client, les campanyes, les còpies o la renovació del domini.
Assegureu la propietat, la recuperació i l'MFA dins de l'empresa
L'empresa ha de ser propietària administrativa dels seus actius crítics, encara que en delegui l'operació. Abans de retirar el proveïdor, comproveu que almenys dues persones autoritzades de l'organització poden administrar o recuperar els comptes més sensibles mitjançant vies separades. NIST indica mantenir els comptes actius com a identitats úniques i registrar els autenticadors associats; disposar de més d'un mitjà d'autenticació redueix la dependència d'un únic procés de recuperació. [1]
Reviseu els correus i telèfons de recuperació, les claus de reserva i els factors d'autenticació multifactor. CISA recomana habilitar l'MFA sempre que sigui possible, començant pels comptes administratius i els accessos que gestionen informació sensible. Si cal substituir un factor MFA, feu-ho amb un procediment validat: OWASP adverteix que aquest canvi és una acció de risc i recomana demanar una nova autenticació amb un factor ja registrat i notificar-ho per un canal independent. [3] [4]
Executeu la retirada per fases i amb proves operatives
Una seqüència prudent és crear primer comptes nominals interns, validar que funcionen i després reduir els permisos del proveïdor fins a retirar-los. Substituïu els comptes compartits per comptes personals amb el rol mínim necessari. Per a les credencials tècniques, planifiqueu una rotació: genereu una clau o un token nou, actualitzeu la integració autoritzada, comproveu-ne el funcionament i només aleshores invalideu l'element anterior.
Exemple hipotètic: una botiga a WordPress envia comandes a un ERP mitjançant una API configurada per la seva agència. En lloc d'eliminar immediatament el proveïdor, l'equip identifica la credencial utilitzada, en crea una de nova sota control empresarial, actualitza la configuració en un entorn o una finestra de canvi acordada i verifica que una comanda de prova autoritzada arriba a la destinació correcta. Després d'això, revoca el token antic i l'accés administratiu de l'agència.
- Comproveu l'accés al domini abans de modificar el DNS o l'allotjament web.
- Verifiqueu formularis, pagaments, comandes, correus transaccionals i restauració de còpies després de cada canvi rellevant.
- Tanqueu les sessions actives quan el servei ho permeti i retireu claus SSH, tokens, OAuth, webhooks i permisos als repositoris.
Documenteu el tancament i reviseu els accessos restants
Registreu cada acció de tancament amb l'actiu afectat, el compte o la credencial retirada, la persona responsable, la data, la substitució aplicada i la prova realitzada. Aquest registre no substitueix una auditoria completa, però facilita respondre a incidències i saber què continua pendent. Deseu també instruccions operatives actualitzades, sense incloure secrets en documents accessibles de manera indiscriminada.
Després del canvi, programeu una revisió autoritzada de comptes, permisos i registres disponibles per confirmar que no queden accessos innecessaris. CISA recomana retirar els comptes que ja no calen, revisar periòdicament si els comptes continuen sent necessaris i aplicar el principi de mínim privilegi. Si l'inventari revela configuracions desconegudes o dependències crítiques, una auditoria de protecció web amb un abast acordat pot ajudar a prioritzar correccions defensives sense afectar l'operació. [5]
Preguntes freqüents
N'hi ha prou d'eliminar l'agència com a administradora de WordPress?
No necessàriament. Aquesta acció no revoca per si sola els accessos a l'allotjament web, el domini, el DNS, les còpies, els repositoris, el correu transaccional, els comptes de servei, els tokens d'API, les aplicacions OAuth o les sessions actives. Reviseu cada actiu inclòs en l'inventari abans de donar el tancament per acabat.
He de canviar totes les contrasenyes en acabar la relació?
Prioritzeu els comptes crítics i els que hagin estat compartits o gestionats pel proveïdor. A més de les contrasenyes, reviseu els mètodes de recuperació, l'MFA, les claus SSH, els tokens i els permisos de les integracions. El canvi s'ha de fer per fases per evitar trencar serveis que depenguin d'una credencial anterior.
Què faig si no sé qui controla el domini o una integració?
No retireu accessos a cegues. Identifiqueu el registrador, les dades de titularitat, els comptes de recuperació i les persones responsables actuals. Per a una integració, determineu quin sistema la utilitza, amb quina credencial opera i com se'n valida el funcionament. Si hi ha una incertesa tècnica rellevant, delimiteu una revisió autoritzada-abra