Por qué un inventario de accesos del sitio es distinto de la “higiene de contraseñas”
Su sitio puede verse bien el lunes y, aun así, alguien más puede romperlo el martes—si usted no conoce cada cuenta que puede cambiarlo. Accesos del registrador, paneles de DNS, paneles de hosting, administradores del CMS, claves de CDN, manejadores de formularios, analítica, Search Console, widgets de pago, chat y píxeles de marketing viven en plataformas distintas con dueños distintos. Cuando esos asientos quedan en correos personales, cuentas de proveedores antiguos o contraseñas compartidas en un chat, dar de baja a una persona no da de baja su sitio web.
Este es un inventario práctico que TwoQM recomienda a operadores de pequeños negocios: liste cada superficie de control que pueda alterar su sitio público o los sistemas detrás de él, anote quién posee cada asiento, confirme el correo de recuperación y el 2FA, y documente qué ocurre cuando alguien se va. No es una guía de MFA, ni una lista de offboarding de proveedores, ni una auditoría del Perfil de Empresa de Google—esas cubren otras superficies. Esta es el mapa de los accesos que afectan al sitio web.
Los administradores de contraseñas ayudan a guardar secretos. Un inventario le dice cuáles secretos importan para el sitio y quién puede usarlos. Una contraseña fuerte en una cuenta de registrador que nunca documentó igual lo deja varado cuando la única persona que conocía el teléfono de recuperación se muda.
Trate el acceso al sitio como equipo de producción: asientos con nombre, propiedad controlada por la empresa cuando sea posible, rutas de recuperación que pueda demostrar y una nota escrita de offboarding para cada acceso de alto impacto.
Paso 1: Liste cada sistema que pueda cambiar el sitio
Empiece una hoja sencilla con una fila por sistema:
Registrador del dominio — Quién puede transferir el dominio, cambiar contactos o renovar.
Host de DNS — A menudo el registrador, a veces un proveedor DNS aparte; quién puede editar registros A/CNAME/MX/TXT.
Hosting web / panel del servidor — cPanel, Plesk, consola en la nube o panel de WordPress administrado.
Administradores del CMS / constructor — Usuarios de WordPress, workspace de Webflow, propietario de Squarespace, personal de Shopify.
CDN / WAF / edge — Herramientas que pueden cachear, bloquear o reescribir tráfico.
Manejadores de formularios y correo — Formularios de contacto, plugins SMTP, correo transaccional (SendGrid, Mailgun, Postmark).
Analítica y Search Console — Acceso a propiedades GA4, propietarios/usuarios de Google Search Console.
Widgets de pago y reservas — Stripe, Square, Calendly o cuentas de checkout embebidas en el sitio.
Chat, embeds de CRM y píxeles de marketing — Admin de chat en vivo, tracking del CRM, píxeles de Meta/Google Ads con derechos de publicación.
Si una herramienta puede cambiar lo que ven los visitantes, el correo de formularios o la verificación del dominio en herramientas de búsqueda, pertenece a la lista.
Paso 2: Para cada asiento, capture dueño, recuperación y 2FA
Columnas que de verdad ayudan después:
Sistema + URL — Página de inicio de sesión exacta, no “el host.”
Correo / usuario de la cuenta — Prefiera direcciones de empresa sobre Gmail personal cuando el proveedor lo permita.
Rol — Owner, Admin, Editor, solo facturación (anote lo que muestra el producto).
Dueño humano — Persona nombrada de su equipo, no “la agencia.”
Correo y teléfono de recuperación — Confirmados vigentes este trimestre.
Estado de 2FA — Activado / apagado / app vs SMS / dónde viven los códigos de respaldo.
¿Proveedor / contratista? — Sí/no, y fecha de fin de contrato si se conoce.
Nota de offboarding — Quién quita el acceso y qué lo reemplaza (transfiera Owner primero).
Última verificación — Fecha en que inició sesión o confirmó la lista.
Necesita una lista que pueda recorrer en menos de una hora la próxima vez que alguien se vaya—no un historial perfecto el día uno.
Paso 3: Señale asientos de “punto único de falla”
Resalte cualquier fila donde:
Solo una persona puede iniciar sesión y usa un correo personal.
El 2FA está apagado, o el teléfono de recuperación es el celular de un exempleado.
Un proveedor anterior aún tiene Owner mientras su equipo solo tiene Editor.
DNS y hosting viven bajo accesos distintos que nadie documentó.
Esos son los asientos a corregir antes de necesitar una transferencia de emergencia. Orden de arreglo para la mayoría de negocios: propiedad del registrador + DNS, luego Owner de hosting/CMS, luego edge/CDN, y al final la cola de píxeles y widgets.
Paso 4: Separe “puede publicar contenido” de “puede romper el DNS”
No todo asiento merece el mismo nivel de alarma. Niveles aproximados:
Nivel A (el sitio se apaga o se mueve): registrador, DNS, raíz de hosting, admin de zona CDN, Owner principal del CMS.
Nivel B (el sitio miente o pierde leads): manejadores de formularios/SMTP, widgets de pago, chat que puede desviar clientes.
Nivel C (medición y anuncios): analítica, Search Console, píxeles—importantes, pero por lo general no un apagón de un día para otro.
Documente quién puede otorgar nuevos asientos de Nivel A. Por lo general es el dueño-operador o el líder de operaciones—no cada marketer con acceso Editor del CMS.
Paso 5: Vincule el inventario a contrataciones y cambios de proveedor
Cuando contrate un proveedor web o un marketer de temporada: otorgue el rol mínimo que permita el trabajo; ponga una fecha de fin en la fila del inventario el mismo día; prefiera invitaciones con nombre sobre contraseñas compartidas; al terminar el contrato (o el último día del personal), quite los asientos el mismo día que revoque el correo—y confirme primero que los Owners de Nivel A de su lado aún puedan iniciar sesión.
Cuando cambie de host o reconstruya el sitio, actualice el inventario en la misma ventana. Un CMS nuevo con el DNS aún bajo un login de registrador abandonado no es una migración terminada.
Una revisión trimestral de 20 minutos
Una vez al trimestre basta para muchos equipos pequeños; cada mes si hay mucha rotación:
Abra la hoja—¿falta algún sistema (nuevo chat, nuevo plugin de formularios)?
Revise el Nivel A: ¿pueden sus cuentas Owner seguir iniciando sesión?
Confirme contactos de recuperación en registrador y hosting.
Quite a quien ya no necesite acceso.
Anote la fecha de la revisión.
Esto complementa—no reemplaza—el MFA en hosting/dominio/correo, el offboarding de proveedores y los drills de respaldo. Esos asumen que usted ya sabe qué puertas existen.
Cuándo pedir ayuda
Pida ayuda cuando los asientos Owner estén bajo una cuenta personal inalcanzable, un bloqueo del registrador pelee con un movimiento de dominio, o tres proveedores crean que “son dueños” del DNS. La preferencia de TwoQM: un inventario vivo, Owners de Nivel A controlados por la empresa, permisos cortos a contratistas y rutas de recuperación que usted haya probado—para que el sitio siga siendo suyo cuando cambien personas y herramientas.
Elabore el inventario esta semana. El próximo acceso sorpresa debería ser uno que usted ya esperaba.