Dar a los empleados acceso a la 2FA sin darles el secreto

Da a la plantilla acceso a los códigos y conserva el secreto con la persona que administra la cuenta. En concreto: una persona introduce cada secreto una vez, concede el acceso por persona y por cuenta, y retira ese acceso cuando alguien cambia de puesto o se va. Nadie inscribe su propia aplicación de autenticación, así que nadie se lleva un acceso que no puedas recuperar.

Este artículo trata el lado del empleador de ese arreglo: quién obtiene qué, y cómo hacerlo funcionar. El razonamiento detrás de la separación está en cómo compartir códigos 2FA en equipo con seguridad, y la mecánica que permite distribuir un código mientras el secreto se queda donde está, en compartir códigos TOTP sin compartir el secreto.

Empieza por decidir cuál es la unidad de acceso

La mayoría de los equipos conceden los accesos 2FA como reparten las llaves de la oficina: alguien pide, otro dice que sí, y no se escribe nada. Aguanta hasta la cuarta contratación. Elige más bien una unidad y mantente en ella; tres se pueden defender.

Por cuenta. La opción por defecto. Cada identificador compartido es algo para lo que se está autorizado o no: los pagos, el cloud, el registrador de dominios, el perfil social principal, cada panel de cliente.

Por rol. En lugar de concedérselo a Amira, se lo concedes a quien haga el trabajo de Amira. «Finanzas» obtiene el proveedor de pago y la herramienta de contabilidad. «Social» obtiene los dos perfiles y la herramienta de programación. Cuando Amira cambia de equipo, la lista que hereda su sustituto ya está definida.

Por encargo. Las agencias necesitan un tercer eje: el cliente. El acceso a las cuentas de un cliente se detiene cuando se detiene el encargo, sean quienes sean las personas que sigan en plantilla.

Cruzar rol y cuenta no exige ninguna ceremonia. Una tabla pequeña, una fila por rol y una columna por cuenta compartida, es el documento que usarás cuando llegue una persona y en las revisiones.

El mínimo privilegio, aplicado a los códigos

Dos preguntas deciden cada concesión. ¿Se conecta esta persona a esta cuenta en el marco de su trabajo? Y si le robaran el portátil esta noche, ¿querrías ver esa cuenta en la lista de exposiciones?

La primera descarta los accesos especulativos. «Es más sencillo dárselo todo a todos» es cierto el día de la puesta en marcha y falso todos los días siguientes, porque el coste llega más tarde, en un incidente o una salida. La segunda es una prueba de sentido común sobre la antigüedad: fundadores y responsables técnicos acumulan todas las cuentas por defecto y se convierten en el objetivo más interesante de la empresa.

Mínimo privilegio no significa obligar a la gente a pedir cada vez. Si alguien necesita una cuenta cada semana, concédesela. Un acceso incómodo de usar se esquiva, normalmente por alguien que lee los códigos en una conversación.

Cómo son los diez primeros minutos de una persona nueva

El alta debe ser una tarea, no un proyecto. Si lleva una tarde, se hará mal.

Antes de su primer día

Busca su rol en la tabla y anota las cuentas que van con él. Si el rol es nuevo, decide la lista ahora, no durante su incorporación.

El día mismo

El administrador concede esas cuentas. La persona nueva se conecta, ve las cuentas para las que está autorizada, y puede generar un código para cada una. No hay ningún código QR que escanear ni ningún secreto que guardar: no tiene nada que perder ni que copiar.

Lo que merece decirse en voz alta

Dile dos cosas. Primero, que nunca verá el secreto detrás de un código, y que eso es deliberado. Segundo, que si necesita una cuenta que no está en su lista, la respuesta es una petición y no un rodeo. Los equipos que se saltan la segunda frase heredan accesos paralelos: alguien captura un código QR de configuración para un compañero, y el número de copias se vuelve imposible de conocer. Por qué esa copia no se puede reclamar nunca se trata en cómo funcionan los secretos TOTP y por qué no hay que compartirlos.

Altas, cambios de puesto, salidas

La palabra que la mayoría de los equipos olvida es cambios de puesto. Las altas y las salidas se vigilan; el cambio de rol rara vez, y así es como se acumulan los accesos.

Alta. Concede la lista del rol. Nada más, aunque la persona tenga experiencia.

Cambio de puesto. Concede las cuentas del nuevo rol y retira las del anterior. La retirada es el paso que se salta, y así es como un agente de soporte que pasó a marketing hace dos años sigue teniendo el proveedor de pago. Concede por rol y un cambio se convierte en la comparación de dos listas.

Salida. Retira a la persona de todas las cuentas, el día en que se va, en una acción que no cambie nada para los demás. Si la salida obliga en cambio a restablecer la 2FA en nueve cuentas y a pedir a ocho compañeros que se vuelvan a inscribir, esa es la señal: tu plantilla guarda secretos, no accesos.

Los proveedores entran en el mismo circuito, con una fecha de fin anotada en el momento en que se concede el acceso. Nadie se acuerda de revocar el acceso de un encargo de tres semanas que terminó sin ruido.

Lo que ve un empleado, y lo que ve un administrador

Ser explícito sobre esa asimetría evita muchas sospechas.

Un empleado ve las cuentas para las que está autorizado y, para cada una, el código vigente y el tiempo que le queda. No puede ver ni el secreto, ni las cuentas que no se le han concedido, ni la forma de conceder acceso a nadie.

Un administrador ve todas las cuentas, quién tiene acceso a cada una, y el listado de los códigos consultados con su marca de tiempo. Los administradores son también quienes introducen los secretos y conservan los códigos de recuperación del proveedor.

El material sensible queda así en manos de un número pequeño de personas con nombre, y «¿quién puede conectarse a la cuenta publicitaria?» tiene una respuesta real en lugar de una estimación.

Cómo presentarlo sin que suene a vigilancia

El registro de accesos es la parte que provoca reacciones, y la reacción es legítima: a nadie le gusta enterarse después de que sus consultas quedan grabadas.

Dilo de entrada, en el alta, y explica para qué sirve en términos operativos. Cuando un identificador compartido hace algo que nadie se explica, la primera pregunta es quién estaba conectado, y el registro de la plataforma solo dice que la cuenta se usó. El registro de códigos es el único sitio que distingue a cinco compañeros. También protege a quienes lo usan: un registro que muestra quién consultó un código muestra igualmente quién no lo hizo.

Lo que no ayuda es presentarlo como una medida de confianza. Descríbelo como fontanería, porque lo es.

«Confiamos en nuestra gente»

La objeción merece una respuesta franca, porque su premisa suele ser cierta: la mayoría de los equipos tienen empleados de fiar. Pero la confianza no es la propiedad que se gestiona aquí. Otras dos sí.

El recuento. Deberías poder decir cuántos dispositivos pueden generar actualmente un código para una cuenta. Si la gente ha inscrito sus propias aplicaciones, ese número es desconocido y lo sigue siendo; nada en la página de seguridad de la cuenta lo informa.

La revocabilidad. Deberías poder poner fin al acceso de alguien sin tocar la cuenta. Si terminarlo obliga a restablecer la 2FA y a reinscribir a todos los demás, evitarás hacerlo, y el acceso persistirá.

Ninguna de las dos supone que nadie se porte mal. Un equipo perfectamente honrado tiene igualmente teléfonos olvidados en taxis, gente que se va en buenos términos, y proveedores cuyo encargo terminó en marzo. Es para esos acontecimientos para lo que existe esta organización.

Una versión de la objeción sí merece concederse. Si dos personas comparten un identificador, ningún modelo de permisos hace de ello dos identidades. Allí donde la cuenta gestiona accesos individuales de verdad, eso vale más que cualquier arreglo de compartición, y es lo primero que hay que comprobar al clasificar tus cuentas. Ver la 2FA de una cuenta compartida: ¿cómo debería abordarla un equipo?.

Revisa los accesos en fecha fija

Una vez por trimestre, lee la lista de cada cuenta compartida y quita los nombres que no deberían estar. Añade una revisión en cada cambio de puesto y en cada fin de encargo.

Lleva unos minutos si el acceso se concedió cuenta por cuenta. Si tu única huella es una carpeta de caja fuerte compartida que una docena de personas pueden abrir, no hay nada que revisar: la respuesta es siempre «todo el mundo». Las cuentas que nadie ha consultado en meses no suelen necesitar compartirse en absoluto.

Los errores que se repiten

Todo para todos por defecto. Normalmente se justifica con el miedo a los cuellos de botella. Convierte cada portátil perdido en una exposición de toda la empresa.

Conceder a la persona en vez de al puesto. El acceso sigue a un nombre, el nombre cambia de trabajo, y nadie sabe qué concesiones estaban ligadas al rol anterior. Concede al rol y el cambio se vuelve mecánico.

Ningún administrador con nombre. Si nadie es responsable del secreto de una cuenta, nadie conserva sus códigos de recuperación y nadie ve derivar los accesos.

Tratar la salida como un proyecto de seguridad en vez de como una línea de una lista. Se coloca junto al portátil y la tarjeta, con el mismo plazo.

Elegir el mecanismo antes de haber clasificado las cuentas. Compara los mecanismos solo para los identificadores que de verdad tienen un único juego de datos de conexión, como en las mejores formas de gestionar la 2FA de una cuenta compartida.

Dónde se sitúa Share Auth

Share Auth está construido en torno a esa forma. Introduces el secreto de cada cuenta una vez, y se cifra en reposo. Las personas que invitas ven el código vigente y su cuenta atrás, no la cadena de la que viene: no hay nada que puedan inscribir en otro sitio.

Los permisos se conceden por miembro y por cuenta, lo que hace expresable la tabla por rol de arriba en vez de teórica. Cada consulta se escribe en un registro de accesos. Retirar a un miembro retira su acceso en todas las cuentas de golpe: una salida es una acción, no una migración. Hay una API si tu incorporación de nuevas personas ya está automatizada.

El plan gratuito cubre tres secretos y tres miembros sin tarjeta bancaria, lo justo para hacer funcionar las cuentas reales de un equipo y ver si el modelo de permisos aguanta.

Lo que esto no resuelve

Un identificador compartido sigue siendo una identidad compartida. Unos códigos concedidos por persona te dicen quién obtuvo uno; no hacen que la pista de auditoría de la plataforma distinga a tus compañeros, y no te dan ningún permiso por persona dentro de la cuenta. Allí donde un proveedor ofrece cuentas de usuario reales o SSO, eso sigue siendo la mejor respuesta, y esta organización vale para las cuentas que no ofrecen ni una cosa ni la otra.

Tampoco hace nada respecto a la contraseña. Si anda por algún sitio donde cualquiera puede leerla, guardar el secreto aparte te ha comprado la independencia del segundo factor y nada más. Es algo, pero no es todo el control de accesos.