
Gestionar la 2FA de las cuentas de clientes siendo una agencia
Cuentas que pertenecen a los clientes y equipos que rotan. Pedir un acceso en regla, compartimentar a los clientes y devolverlo todo al final.
Pide a cada cliente que os añada en vuestro nombre, en lugar de enviaros su identificador. Casi todas las plataformas donde trabaja una agencia tienen una forma de conceder acceso a una organización externa: acceso de socio, invitación de miembro, rol entre cuentas, vuestro propio usuario en su CMS. Donde eso existe, no hay ni contraseña compartida ni segundo factor compartido que gestionar.
Lo que queda después es una lista corta por cliente: las cuentas sin delegación, las que la reservan a los planes de empresa, las que configuró alguien que ya no está. Esas piden una custodia que puedas auditar durante el encargo y deshacer limpiamente al final.
La restricción que hace distinta la 2FA de agencia
Un equipo interno posee sus cuentas. Si el segundo factor está en el sitio equivocado, puede moverlo: restablecer la 2FA, añadir un segundo administrador, vincular la cuenta a un buzón compartido. Es engorroso, pero es posible.
Una agencia no tiene ninguna de esas palancas. Las cuentas pertenecen al cliente, las configuró hace dos años alguien de su departamento financiero, y tu influencia sobre esa configuración se reduce a una petición educada al arrancar. No puedes corregir la cuenta. Solo puedes corregir tu lado.
La segunda diferencia es aritmética. Un equipo interno tendrá quince cuentas compartidas en total. Una agencia tiene un cierto número por cliente. Con tres clientes lo llevas todo en la cabeza. Con cuarenta, la práctica informal ya no es una elección de estilo, es lo que va a ceder, y cederá sobre la propiedad de otro.
El razonamiento general sobre la custodia de cuentas compartidas está en la 2FA de una cuenta compartida: ¿cómo debería abordarla un equipo?. El modelo de explotación de una agencia se coloca encima.
Qué pedir en lugar de una contraseña
Las formas de un acceso en regla
Los nombres cambian de una plataforma a otra, la forma no. Alguien de fuera de la organización del cliente recibe un nivel de acceso definido sobre un recurso definido, con su propio identificador y su propio segundo factor.
| Lo que suelen ofrecerte | Lo que hay que pedir en su lugar |
|---|---|
| El identificador de su cuenta publicitaria | Un acceso de socio, concedido desde vuestra propia cartera profesional |
| La contraseña de un panel de pagos o facturación | Una invitación de miembro de equipo con un rol ajustado al trabajo |
| Los identificadores raíz o de consola de su cuenta cloud | Un rol que asuma vuestra organización, revocable por su parte |
| La contraseña de administración del CMS o de la tienda | Vuestro propio usuario con nombre, con rol de editor o colaborador |
| El identificador de la herramienta de analítica | Vuestro propio usuario en su propiedad, con el nivel de acceso necesario |
El cliente gana más que tú, y eso hace fácil la conversación. Ve qué cambios son vuestros, puede retiraros sin restablecer nada para sus propios empleados, y ninguna de sus contraseñas acaba en un hilo de correo. Dilo al pedirlo.
Las versiones propias de cada herramienta se tratan en otro sitio: una cuenta de Stripe compartida, una cuenta de AWS compartida, y las cuentas de redes sociales compartidas, donde el modelo de acceso de socio está más desarrollado.
Cómo llevar la conversación
Pide al arrancar, por escrito, cuenta por cuenta. Un encargo que empieza con una contraseña enviada por correo no vuelve nunca sobre la cuestión.
Dos cosas hacen que la petición pase. Dirígete a la persona que administra de verdad la cuenta, no a la responsable de marketing que trasladará tu petición a alguien de vacaciones. Y envía los pasos en lugar de la petición: una lista numerada y corta de dónde hay que hacer clic, por plataforma, elimina el esfuerzo que es la verdadera objeción. «Por razones de seguridad» se lee como tu problema; «para que veáis lo que hemos cambiado y podáis cortarnos con un clic» se lee como el suyo.
Cuenta con unos quince días y dos recordatorios en algunas cuentas. No dejes que el trabajo se pare detrás.
Cuando el cliente envía la contraseña de todos modos
Algunos lo harán. Una empresa unipersonal donde el director es el único administrador, un cliente cuyo proveedor informático no responde, una plataforma realmente sin delegación. Rechazar el identificador no es una opción real: reduce más bien la exposición.
- Sácalo del buzón nada más recibirlo. La copia en tu bandeja de entrada y la de sus mensajes enviados siguen ahí, y solo controlas una.
- Pídele que cambie la contraseña una vez que la tengáis, o cámbiala tú si estás autorizado. Eso mata la copia enviada por correo, que es lo único que puedes hacer al respecto.
- No aceptes nunca el código de inscripción 2FA. Ni la captura del código QR, ni la cadena de debajo, por ningún canal. Si te lo ofrece, recházalo y explica por qué: es la credencial permanente y no una contraseña, sus copias no se pueden contar ni recuperar, y deshacer una obliga a restablecer la 2FA de la cuenta. La mecánica está en cómo funcionan los secretos TOTP.
- Si menciona habérselo enviado por correo a un proveedor anterior, dile que lo considere comprometido y lo restablezca. Mensaje incómodo, consejo correcto.
- Anota qué has recibido, de quién y cuándo. Es esa costumbre la que hace posible el final del encargo.
Nada de esto vuelve retroactivamente segura una contraseña enviada por correo. Acorta la ventana y te deja un rastro.
Un cliente, una frontera
Con cuarenta clientes, la compartimentación es la propiedad que mantiene pequeño un incidente pequeño.
Una entrada por cuenta de cliente. Nombrada por cliente y por cuenta, nunca un montón común de «identificadores de clientes». Es el montón lo que vuelve inaplicables todas las reglas siguientes.
Un acceso concedido por persona, para los clientes en los que trabaja. El responsable de proyecto de un paquete no tiene ninguna razón para llegar al registrador de dominios de otro cliente. No es desconfianza hacia vuestros empleados; significa que un portátil robado es el problema de un solo cliente y que una salida es una sola conversación.
Un registro que llevéis de verdad. No un documento escrito una vez al arrancar:
| Campo | Por qué está ahí |
|---|---|
| Cliente y cuenta | Para que la lista de traspaso se escriba sola |
| Tipo de acceso | Usuario delegado, enlace de socio, o identificador compartido |
| Quién, en la agencia, lo tiene | La lista de salida, persona a persona |
| Concedido el | Para poder cuestionar un acceso permanente |
| Quién lo administra del lado del cliente | Para saber a quién preguntar cuando algo se rompe |
Una revisión en una franja fija, enganchada a la revisión del paquete o a la facturación. Un acceso nunca revisado solo se acumula.
El coste honesto: la compartimentación bloqueará a alguien, normalmente a quien sustituye de urgencia a un compañero en un cliente. La respuesta es una concesión que tarde treinta segundos, no un acceso permanente para todo el mundo. Si conceder es lento, la gente lo esquiva, y lo esquiva con una contraseña en un mensaje.
La llegada de un cliente
Trata la recogida de accesos como un entregable, con un responsable y una fecha, igual que la reunión de lanzamiento.
- Lista las cuentas que el trabajo necesita de verdad, no todo lo que el cliente posee. La deriva del alcance de los accesos es como una agencia acaba guardando el identificador de un registrador que no usa nunca.
- Averigua quién administra cada una y qué delegación permite. La segunda pregunta suele responderse en su propia página de ajustes.
- Pide un acceso delegado, con los pasos adjuntos.
- Para lo que quede, acuerda explícitamente la custodia: quién, en la agencia, guarda el identificador, dónde vive, y quién puede leer sus códigos.
- Deja constancia de todo, incluidas las cuentas que pediste sin obtenerlas.
- Acuerda ya el estado final, mientras la buena voluntad es alta: qué devolveréis, qué retiraréis, qué le pediréis que renueve.
El paso 6 cuesta cinco minutos al arrancar y evita una negociación más tarde, cuando un paquete termina y nadie se siente generoso.
El final de un encargo
La salida de un empleado se discute. El final de un encargo de cliente es el que los clientes notan de verdad, y suele salir peor.
- Retira lo que controlas. Sal de la relación de socio, abandona el rol asumido, elimina vuestros propios usuarios donde tengáis derecho.
- Envía al cliente la lista de lo que solo él puede retirar. Usuarios con nombre, enlaces de socio, claves de API, contraseñas de aplicación, integraciones. Él no se acordará de lo que se os dio; vuestro registro sí.
- Elimina los identificadores que guardáis, y dilo.
- Nombra cada cuenta donde hayáis guardado un secreto TOTP, y pide que restablezcan la 2FA y desconecten todas las sesiones en cada una. Este es el paso que todo el mundo se salta.
- Pon todo eso en un traspaso escrito, fechado, con lo que teníais, lo que habéis retirado, y lo que pedís renovar.
Sobre la prueba de que ya no guardáis nada: no puedes probar la ausencia de una copia, y una agencia que pretenda hacerlo exagera. Lo que sí puedes hacer es poner al cliente en una posición donde todo lo que aún pudierais tener no valga nada. Una contraseña cambiada y un segundo factor restablecido son la única prueba real, y le toca a él producirla: construye el traspaso alrededor de esa petición y no de palabras tranquilizadoras.
Ahí es donde una práctica informal se hace visible. Si los identificadores han vivido en un solo sitio, con un rastro de quién podía leerlos, el paso 4 es un párrafo que puedes escribir honestamente. Si once personas han escaneado códigos de inscripción en tres años, no puedes escribirlo en absoluto, y es el hecho de escribir una versión más vaga lo que debería incomodarte.
Proveedores y autónomos
La rotación es la condición normal, no la excepción, y se lleva mal con todo lo permanente.
Concede por cliente, y anota la retirada el mismo día de la concesión. Un autónomo en un cliente durante seis semanas debería tener acceso a un cliente durante seis semanas. Esa fecha es fácil de poner cuando ya estás en la página de ajustes, e imposible de reconstruir cuatro meses después.
Dales códigos, nunca secretos. Un subcontratista trabaja en su propio dispositivo, con su gestor de contraseñas y sus copias de seguridad. Todo lo que pueda copiar se lo queda una vez pagada la factura, y ninguna cláusula cambia nada. La distinción es el tema de compartir códigos TOTP sin compartir el secreto.
Donde la plataforma del cliente lo permita, consigue al autónomo su propio usuario del lado del cliente. El cliente ve de quién viene el trabajo, y la retirada es una acción suya que no os implica.
No dejes nunca que un autónomo sea el punto de inscripción de la 2FA de un cliente. Pasa por accidente: configura la cuenta durante un lanzamiento, la aplicación de autenticación acaba en su teléfono, y dos años después nadie puede conectarse y él ha cambiado de oficio. En algunas plataformas eso no tiene salida fiable, solo una cola de soporte.
Cierra los accesos al terminar el contrato con la misma seguridad con que envías la factura. Una de las dos cosas siempre se hace. Engancha la otra encima.
Qué poner en la carta de encargo
Cosas operativas, no jurídicas: la redacción del contrato es una cuestión para un abogado, y nada de esto es asesoramiento legal. Pero un párrafo en el pliego o en el correo de arranque zanja las disputas del noveno mes, y debería cubrir:
- para qué cuentas la agencia guarda identificadores, y a cuáles llega por un acceso delegado;
- que el cliente conserva la propiedad y puede revocar cualquier acceso en cualquier momento, sin preaviso ni explicación;
- quién, en la agencia, está autorizado, y que el acceso es por persona y no a la agencia como entidad;
- que los códigos de inscripción 2FA y los secretos no circulan ni por correo ni por mensajería, en ningún sentido;
- qué pasa al final: la lista de traspaso, las retiradas que efectúa la agencia, y las renovaciones que pedirá al cliente;
- a quién contactar cuando un identificador deja de funcionar, para que nadie lo resuelva publicando una contraseña en un canal a las 19 h.
El interés no es que sea oponible. Es que la conversación tenga lugar una vez, al principio, durante una semana tranquila.
Lo que se rompe cuando todo esto queda informal
Los fallos son reconocibles, y todos vienen de la misma estructura ausente.
El relevo. Los códigos vienen del teléfono de un responsable de proyecto. Practicable con cuatro clientes, hasta que esa persona coge una semana de vacaciones.
El que se va y no se puede desvincular. Alguien se marcha después de haber inscrito su aplicación de autenticación en una docena de cuentas de clientes. Hacerlo bien supone contactar con doce clientes para pedirles que restablezcan su 2FA, y explicarles por qué. La mayoría de las agencias se abstienen sin decirlo, lo que significa que la siguiente nota de traspaso contiene una afirmación falsa.
La cuenta que nadie puede recuperar. Registrada con una dirección o un número personales, por alguien a quien ya no se puede localizar.
La pregunta sin respuesta. Un cliente pregunta quién abrió su cuenta publicitaria el día 14. «Una de cuatro o cinco personas, creemos» es una mala respuesta para dar a un cliente sobre su propia propiedad, y suele ser el momento en que una agencia cambia su forma de trabajar.
El radio de acción. Un montón común hace que un portátil comprometido sea un incidente para todos los clientes a la vez, y la conversación de notificación se convierte en cuarenta conversaciones.
Dónde se sitúa Share Auth
Para las cuentas de clientes que quedan después de la delegación: las que solo tienen un identificador, sin modelo de socio, y con un cliente que no va a reestructurar nada.
El secreto se introduce una vez y se cifra en reposo. Las personas que invitas ven el código de seis cifras vigente y su cuenta atrás en lugar de la cadena que hay detrás, lo que hace el acceso de un subcontratista realmente revocable. Los permisos se ajustan por miembro y por cuenta, así que la compartimentación de los clientes se vuelve expresable en vez de ser un deseo. Cada consulta se escribe en un registro de accesos, así que «quién leyó el código el día 14» tiene una respuesta con un nombre y una marca de tiempo. Retirar a un miembro retira su acceso en todas las cuentas de clientes de golpe. Una acción, sin restablecimiento en doce clientes. Hay una API para los casos en que es una máquina, y no una persona, la que necesita el código. El plan gratuito cubre tres secretos y tres miembros sin tarjeta bancaria, lo justo para pasar a un cliente por todo el ciclo antes de decidir nada.
Lo que no hace: no os conseguirá un acceso delegado, que sigue siendo la mejor respuesta allí donde existe, no lleva vuestro registro ni vuestras notas de traspaso, y no puede deshacer un código de inscripción ya enviado por correo. Tampoco es un gestor de contraseñas, y la contraseña debe quedarse en el que ya tenéis, por la razón expuesta en cómo compartir códigos 2FA en equipo con seguridad. Si aún estás sopesando las opciones, los mecanismos se comparan en las mejores formas de gestionar la 2FA de una cuenta compartida, y el protocolo subyacente se trata en la guía completa del TOTP en equipo.
Por dónde empezar
No por cuarenta clientes a la vez.
- Coge el cliente con los accesos más enredados y construye limpiamente su entrada de registro. Una tarde, y te dice cómo son los otros treinta y nueve.
- Escribe dos plantillas: los pasos numerados de la petición enviada al arrancar, y la nota de traspaso con su petición de renovación. El hecho de estar escritas es lo que hace que salgan.
- Pide un acceso delegado a todos tus clientes actuales donde exista, a razón de un cliente por semana.
- Para las cuentas que sigan compartidas, pon el secreto en un solo sitio con acceso a los códigos por persona, y restablece la 2FA de toda cuenta cuyo código de inscripción se haya enviado o publicado alguna vez.
El estado final no tiene nada de lucido: un cliente pregunta qué guardáis y quién lo ha usado, y respondéis el mismo día.
Preguntas frecuentes
Pide que os añadan en vuestro nombre en lugar de recibir un identificador. La mayoría de las plataformas donde trabaja una agencia lo permiten: acceso de socio desde vuestra propia cartera profesional, invitación de miembro con un rol, rol entre cuentas, vuestro propio usuario en su CMS. El cliente conserva la propiedad, vuestros empleados usan su propio segundo factor, y el registro de actividad del cliente anota nombres en vez de «la agencia».
Acepta el trabajo y después reduce la exposición. Saca el identificador del buzón para meterlo en vuestra caja fuerte, pide al cliente que cambie la contraseña una vez la tengáis, y no aceptes nunca el código de inscripción 2FA ni una captura del código QR, por ningún canal. Después sigue pidiendo un acceso delegado en la próxima ocasión natural: una migración de plataforma, o la llegada de una persona nueva a la cuenta.
Una entrada por cuenta de cliente, nunca un montón común, y un acceso concedido por persona para los clientes en los que realmente trabaja. La compartimentación cuesta algo de comodidad cuando alguien sustituye a un compañero, y es lo que impide que un portátil comprometido o una salida se conviertan en un evento de cuarenta clientes.
No puedes probar la ausencia de una copia, y no deberías pretenderlo. Lo que sí puedes hacer es listar exactamente lo que teníais, confirmar lo que habéis retirado por vuestro lado, y pedir al cliente que cambie la contraseña y restablezca la 2FA en todo lo que teníais. Esa rotación es la única prueba real, y le pertenece a él: construye tu traspaso alrededor de esa petición.
Concede el acceso por cliente y anota la fecha de retirada el mismo día en que lo concedes. Da a los subcontratistas los códigos y no el secreto, porque todo lo que puedan copiar se queda con ellos cuando acaba el contrato. Donde la plataforma del cliente lo permita, consigue al autónomo su propio usuario del lado del cliente, para que la retirada sea una única acción del cliente.