Cómo organizar correctamente las cuentas de usuario de todas las aplicaciones

Introducción

Una empresa puede tener bien elegidas sus aplicaciones y, aun así, perder el control de las cuentas de usuario. El problema aparece de forma gradual: una persona recibe acceso al correo, otra al sistema comercial, alguien conserva una cuenta de administración que ya no necesita, un proveedor entra con un usuario creado para una incidencia puntual, una herramienta utiliza una identidad técnica para una integración y varias aplicaciones siguen mostrando usuarios que dejaron de colaborar hace meses.

Cuando la empresa utiliza pocas herramientas, estas situaciones pueden resolverse de memoria. A medida que crece el número de aplicaciones, esa estrategia deja de funcionar. La misma persona puede tener diez, veinte o más identidades repartidas entre servicios distintos, con nombres diferentes, métodos de autenticación incompatibles, permisos que se acumulan y procesos de baja que dependen de recordar dónde se creó una cuenta.

Organizar correctamente las cuentas de usuario de todas las aplicaciones significa tratar las identidades como un sistema transversal. No basta con revisar contraseñas ni con definir permisos dentro de una herramienta concreta. Hay que saber qué personas, cuentas funcionales, administradores, invitados y procesos automáticos existen en cada aplicación; quién necesita realmente cada acceso; cómo se crean, modifican y retiran; qué cuenta controla la recuperación; y qué evidencia permite comprobar que el mapa sigue siendo correcto.

Este enfoque es distinto de redactar una política general de seguridad. Una política define reglas sobre acceso, permisos, autenticación y revisión. Aquí el objetivo es convertir esas reglas en una estructura operativa que funcione a través de toda la cartera de aplicaciones. Para profundizar en las normas generales puede consultarse cómo crear políticas de acceso en una empresa pequeña sin complicarlo todo. En este artículo nos centraremos en cómo organizar las cuentas de forma coherente, mantenible y verificable.

La meta no es construir un sistema de identidad propio de una gran corporación. Una microempresa o una PYME pequeña puede conseguir mucho con una matriz bien diseñada, nombres coherentes, responsables claros, listas de comprobación para altas y bajas, separación de cuentas administrativas, control de invitados y revisiones periódicas. La clave está en que ninguna cuenta importante dependa de memoria informal.

Índice

• Qué significa organizar las cuentas de usuario a escala de empresa
• Diferenciar identidad, cuenta, permiso, licencia y administración
• Construir una matriz de personas y aplicaciones
• Definir una identidad corporativa coherente
• Usar cuentas nominativas como regla general
• Controlar las cuentas compartidas como excepción
• Organizar cuentas funcionales y buzones de servicio
• Separar cuentas administrativas de las cuentas de uso diario
• Gestionar cuentas técnicas, bots e integraciones
• Gestionar cuentas de proveedores, invitados y colaboradores externos
• Diseñar recuperación y acceso de emergencia
• Preferir roles y grupos frente a permisos individuales dispersos
• Organizar el alta de una persona
• Gestionar cambios de función sin acumular privilegios
• Cerrar correctamente todas las cuentas cuando alguien se va
• Controlar accesos temporales
• Detectar cuentas inactivas, huérfanas y olvidadas
• Coordinar cuentas y licencias sin confundirlas
• Mantener coherencia en MFA y recuperación
• Separar el inventario de cuentas de las contraseñas y secretos
• Cuándo ayuda el inicio de sesión centralizado
• Evitar que la identidad centralizada se convierta en otro punto único de fallo
• Cuentas de usuario y movilidad profesional
• Asegurar la titularidad empresarial de las cuentas críticas
• Mantener trazabilidad sin crear burocracia excesiva
• Revisar periódicamente el mapa de cuentas
• Indicadores útiles para saber si el sistema está ordenado
• Ejemplo práctico en una pequeña empresa de servicios
• Método completo paso a paso
• Errores frecuentes
• Lista de comprobación
• Preguntas frecuentes
• Conclusión

Qué significa organizar las cuentas de usuario a escala de empresa

Organizar cuentas no consiste en mantener una lista de correos electrónicos. Consiste en poder responder, en cualquier momento, a cuatro preguntas: quién tiene acceso, a qué aplicaciones, con qué nivel de privilegio y por qué sigue necesitándolo.

La dificultad aparece porque las aplicaciones no comparten necesariamente el mismo modelo. Una puede tener usuarios, grupos y administradores globales; otra distingue propietarios, miembros e invitados; otra utiliza una cuenta principal y varias subcuentas; otra crea accesos mediante una identidad externa; y otra puede ni siquiera permitir cuentas individuales en determinado plan.

Por eso el sistema empresarial debe abstraerse de los nombres comerciales de cada proveedor. La empresa necesita su propia lógica de gobierno y después traducirla a cada aplicación.

La cuenta pertenece a un ciclo de vida

Toda cuenta debería tener un origen, una finalidad, un responsable, un nivel de acceso, una fecha de revisión y un momento de cierre. Si alguno de esos elementos es desconocido, la cuenta está peor gobernada de lo que parece.

La organización debe funcionar aunque cambien las herramientas

Si mañana se sustituye una aplicación, el modelo de identidades no debería empezar desde cero. La empresa debe conservar una idea estable de quiénes son sus usuarios, qué funciones existen, quién aprueba accesos y qué categorías de cuenta utiliza.

Esta visión complementa cómo documentar todas las aplicaciones utilizadas por una empresa. La documentación explica cómo funciona cada herramienta; la organización de cuentas controla quién puede entrar en ellas y cómo cambia ese acceso durante el tiempo.

Diferenciar identidad, cuenta, permiso, licencia y administración

Muchos problemas empiezan porque se utilizan como sinónimos conceptos diferentes. Separarlos permite diseñar controles más precisos.

Una persona puede tener una identidad corporativa y varias cuentas en aplicaciones distintas. Puede disponer de licencia en una aplicación sin ser administrador. También puede existir una cuenta técnica sin una persona detrás y una cuenta compartida utilizada por varias personas.

Separar estos niveles evita decisiones erróneas

Retirar una licencia no siempre elimina una cuenta. Eliminar una cuenta puede no revocar una sesión externa. Quitar un permiso puede dejar intacta una clave API. Cambiar el correo principal puede no modificar la identidad de recuperación. Por eso el procedimiento debe saber qué está intentando cambiar exactamente.

Construir una matriz de personas y aplicaciones

La herramienta más útil para una pequeña empresa suele ser una matriz que cruce identidades con aplicaciones. No necesita empezar como una plataforma especializada. Una hoja estructurada puede ser suficiente si se mantiene con disciplina.

Filas por identidad

Cada fila puede representar una persona, una cuenta funcional, un proveedor o una cuenta técnica.

Columnas por aplicación

Para cada aplicación conviene registrar si la identidad:

• no tiene cuenta;
• tiene cuenta activa;
• es invitada o externa;
• dispone de permisos elevados;
• es administradora;
• consume licencia;
• está pendiente de revisión;
• debe darse de baja.

La matriz no sustituye el detalle de cada aplicación. Sirve para detectar incoherencias transversales: una persona que ya no trabaja pero conserva cuatro accesos, un proveedor con privilegios en tres sistemas, o un administrador que aparece como único punto de recuperación de varias herramientas.

Dos vistas complementarias

Resulta útil mantener una vista por persona y otra por aplicación. La primera responde «¿qué accesos tiene esta persona?». La segunda responde «¿quién entra en esta aplicación?». Ambas son necesarias durante una baja o una auditoría.

El inventario técnico general puede servir como fuente de aplicaciones y responsables. Para esa base puede consultarse cómo inventariar servidores, aplicaciones y servicios.

Definir una identidad corporativa coherente

Antes de crear cuentas en decenas de servicios, conviene decidir cómo se representará a las personas dentro del ecosistema digital.

Nombre principal estable

La empresa puede utilizar el correo corporativo como identificador principal cuando resulte adecuado. Lo importante es que exista un criterio uniforme y que no dependa de correos personales para herramientas importantes.

Evitar alias improvisados

Si una persona aparece como nombre.apellido en una aplicación, iniciales en otra y un correo personal en una tercera, resulta más difícil reconciliar cuentas y detectar duplicados.

Registrar cambios de nombre o dirección

Cuando cambia el correo de una persona, algunas aplicaciones permiten modificar el identificador y otras crean una cuenta nueva. La organización debe conservar la relación histórica para evitar que la identidad anterior quede abandonada.

Separar identidad humana y función

Una persona no debería convertirse en la identidad permanente de una función empresarial. Por ejemplo, una dirección de administración o soporte puede existir como función, mientras que las personas responsables cambian con el tiempo.

Usar cuentas nominativas como regla general

Cuando una aplicación permite usuarios individuales, lo normal es que cada persona disponga de su propia cuenta. Esto mejora trazabilidad, bajas, permisos y seguridad.

Ventajas operativas

• puede retirarse el acceso de una persona sin afectar a otras;
• los registros de actividad tienen sentido;
• los permisos pueden adaptarse a la función real;
• el doble factor pertenece a la persona correcta;
• la recuperación y soporte resultan más claros;
• es más fácil comprobar quién consume una licencia.

No confundir cuenta nominativa con correo personal

Una cuenta individual puede seguir estando bajo control empresarial. Lo importante es que identifique a una persona concreta y utilice una identidad cuya titularidad y recuperación estén adecuadamente organizadas.

No mantener cuentas «por si acaso»

Crear cuentas preventivas para personas que quizá necesiten una aplicación en el futuro aumenta el número de identidades que revisar. Conviene aprovisionar cuando existe una necesidad real.

Controlar las cuentas compartidas como excepción

Algunas aplicaciones pequeñas, dispositivos o servicios antiguos no permiten cuentas individuales. En otros casos existe una cuenta funcional que varias personas deben utilizar. Estas situaciones pueden ser inevitables, pero deben tratarse como excepción conocida.

Registrar quién conoce o puede usar la cuenta

La empresa debe poder enumerar las personas autorizadas. «La usa el departamento» es demasiado impreciso si nadie sabe exactamente quién tiene la credencial.

Custodiar la credencial de forma controlada

Cuando deba compartirse un secreto, conviene utilizar un mecanismo adecuado de compartición dentro de un gestor de contraseñas o sistema equivalente, evitando enviarlo repetidamente por correo o mensajería.

Cambiar el secreto tras una baja cuando sea necesario

Si una persona conocía una contraseña compartida y deja de necesitarla, la baja no está terminada hasta que esa credencial deja de ser válida o se modifica el mecanismo de acceso.

Evitar que una cuenta compartida sea la única administradora

Una identidad compartida puede resultar útil para una función, pero la administración y recuperación deben tener responsables claros.

Organizar cuentas funcionales y buzones de servicio

Una cuenta funcional representa una responsabilidad o servicio, no una persona. Puede utilizarse para administración, compras, facturación, soporte, alertas o recepción de notificaciones de proveedores.

Ventaja principal: continuidad

Si las notificaciones de renovación llegan al correo personal de quien contrató una herramienta hace tres años, la empresa depende de esa persona. Una identidad funcional permite conservar el canal aunque cambie el responsable.

No utilizarla como sustituto universal de las cuentas individuales

Que exista un buzón funcional no significa que todos deban iniciar sesión con la misma cuenta en las aplicaciones. Puede utilizarse como dirección de contacto o recuperación mientras cada persona mantiene su usuario individual.

Definir responsables y suplentes

La ficha debe indicar quién atiende la cuenta, quién puede sustituirle y para qué servicios se utiliza.

Evitar cuentas funcionales sin propietario

Una dirección genérica que recibe alertas pero nadie revisa es peor que no tener alerta, porque crea una falsa sensación de control.

Separar cuentas administrativas de las cuentas de uso diario

Una persona que administra una aplicación no necesita utilizar privilegios máximos para su trabajo cotidiano. Separar ambas funciones reduce el impacto de errores, sesiones comprometidas y acciones accidentales.

Cuenta ordinaria

Se utiliza para las tareas normales: consultar, editar, operar y colaborar.

Cuenta administrativa

Se utiliza solo cuando es necesario crear usuarios, modificar seguridad, cambiar integraciones, gestionar configuración crítica o realizar otras acciones privilegiadas.

Administradores suficientes, pero no excesivos

Una única persona administradora crea dependencia. Diez administradores para una aplicación usada por ocho personas crea exposición innecesaria. La cantidad adecuada debe permitir continuidad sin repartir privilegios indiscriminadamente.

Registrar administradores secundarios

Las aplicaciones críticas deberían tener un mecanismo de recuperación que no dependa exclusivamente de un único administrador. Este criterio se relaciona con cómo evitar depender de una única aplicación crítica, porque la identidad administrativa forma parte de la continuidad del sistema.

Gestionar cuentas técnicas, bots e integraciones

Las cuentas técnicas son uno de los puntos que más fácilmente quedan fuera del control. No aparecen en las listas de empleados, pueden no iniciar sesión de forma visible y a menudo conservan permisos durante años.

Qué puede ser una identidad técnica

• una cuenta utilizada por una integración;
• un usuario de servicio;
• un bot;
• una clave API asociada a una identidad;
• un usuario empleado por un script;
• una cuenta para copias o monitorización;
• una identidad utilizada por una herramienta de automatización.

Cada cuenta técnica necesita propietario humano

No basta con saber que «la usa el sistema». Debe existir una persona o función responsable de explicar qué hace, qué permisos necesita y qué ocurriría si se desactiva.

No reutilizar identidades técnicas para varios fines sin necesidad

Una sola cuenta con permisos amplios utilizada por cinco integraciones distintas dificulta revocación, auditoría y diagnóstico. Cuando sea razonable, conviene separar identidades por integración o propósito.

Revisar caducidad y rotación

Tokens, claves y secretos técnicos también tienen ciclo de vida. Deben registrarse sin exponer su valor y revisarse cuando cambian responsables o se retira una integración.

Gestionar cuentas de proveedores, invitados y colaboradores externos

Las identidades externas merecen una categoría propia. Un proveedor puede necesitar acceso durante semanas; un colaborador puede intervenir solo en un proyecto; un auditor puede necesitar lectura temporal; un soporte externo puede requerir administración durante una incidencia.

Dar el menor alcance razonable

Un proveedor que mantiene una aplicación no necesariamente necesita acceso a otras herramientas, datos comerciales o sistemas que quedan fuera de su trabajo.

Definir fecha de revisión o caducidad desde el principio

Los accesos externos se olvidan cuando no existe una fecha de cierre. Si el sistema permite caducidad automática, puede aprovecharse. Si no, debe existir una tarea de revisión.

Evitar cuentas de proveedor como único mecanismo de administración

La empresa debe conservar una identidad administrativa propia o un procedimiento real para recuperar el control.

Registrar accesos excepcionales

Si un proveedor recibe permisos elevados para resolver una incidencia, conviene documentar cuándo se concedieron, por qué y cuándo deben retirarse.

Diseñar recuperación y acceso de emergencia

Una cuenta bien protegida puede seguir siendo un riesgo si nadie sabe recuperarla. La recuperación debe formar parte del diseño de identidades y no añadirse después de un bloqueo.

Correo o identidad de recuperación controlada

Las cuentas críticas deberían utilizar mecanismos de recuperación que sigan bajo control de la organización aunque cambien las personas responsables.

Códigos de recuperación

Cuando un servicio ofrece códigos o claves de emergencia, deben custodiarse de forma separada y accesible únicamente a quienes realmente deban utilizarlos.

Cuenta de emergencia

En algunos entornos puede resultar razonable mantener una cuenta administrativa de emergencia con controles especiales y uso excepcional. No debe convertirse en una cuenta compartida de uso cotidiano.

Probar el procedimiento

La recuperación que nunca se ha revisado puede fallar cuando más se necesita. Conviene verificar periódicamente que los datos de recuperación siguen vigentes y que el procedimiento es comprensible.

Preferir roles y grupos frente a permisos individuales dispersos

Conceder permisos uno a uno puede funcionar con tres personas y cuatro aplicaciones. A medida que el entorno crece, aparecen excepciones difíciles de revisar.

Roles empresariales

La empresa puede definir funciones como administración, ventas, operaciones, dirección, soporte o tecnología. No es necesario que todas las aplicaciones utilicen exactamente esos nombres; lo importante es que exista una referencia común.

Grupos dentro de cada aplicación

Cuando la herramienta lo permite, los permisos pueden asignarse a grupos y después incorporar usuarios a esos grupos. Un cambio de función resulta más fácil de aplicar y auditar.

Permisos directos solo cuando aportan valor

Las excepciones pueden existir, pero deben ser visibles. Si una persona tiene un acceso especial fuera de su rol, conviene registrar el motivo y revisar si sigue siendo necesario.

Evitar copiar la misma estructura en todas las herramientas

Una aplicación pequeña puede necesitar solo usuario y administrador. Otra puede requerir varios roles. El modelo debe ser proporcional a cada sistema.

Organizar el alta de una persona

El alta es el momento más fácil para imponer orden. Cuando el procedimiento empieza bien, las cuentas nacen con nombre, función y permisos conocidos.

Partir de la función y no de una lista histórica

No conviene copiar automáticamente los accesos de otra persona sin comprobar si ambas necesitan realmente lo mismo. La función debe determinar las aplicaciones y el nivel de acceso.

Lista de comprobación de alta

• identidad corporativa creada;
• aplicaciones necesarias identificadas;
• cuentas creadas con nomenclatura coherente;
• roles y grupos asignados;
• MFA configurado cuando corresponda;
• recuperación revisada;
• licencias asignadas;
• cuentas compartidas autorizadas, si existen;
• acceso remoto definido;
• fecha de revisión inicial registrada.

Completar el registro al mismo tiempo que se crea la cuenta

Si la matriz se actualiza «después», es fácil que nunca refleje exactamente la realidad. El alta no debería considerarse terminada hasta que el registro de accesos esté actualizado.

Gestionar cambios de función sin acumular privilegios

Los cambios internos generan un riesgo menos visible que las altas y bajas. Una persona pasa a otra función y recibe nuevos permisos, pero conserva los anteriores por comodidad.

Recalcular, no solo añadir

Ante un cambio de rol, la pregunta no debe ser «¿qué acceso nuevo necesita?», sino «¿qué conjunto completo de accesos necesita ahora?». Eso obliga a retirar los que han dejado de tener sentido.

Revisar aplicaciones y grupos

La modificación debe recorrer la matriz completa: herramientas, grupos, permisos especiales, cuentas compartidas, recursos documentales y accesos externos relacionados.

Revisar privilegios administrativos

Una persona que deja de administrar una función puede seguir apareciendo como administradora de varias aplicaciones si nadie actualiza el sistema.

Conservar trazabilidad de la decisión

No hace falta mantener un expediente complejo, pero sí registrar que el cambio se revisó y cuándo.

Cerrar correctamente todas las cuentas cuando alguien se va

La baja es una operación transversal. El error habitual es cerrar el correo y asumir que todo lo demás queda resuelto.

Recorrer la matriz por persona

La vista por identidad permite localizar todas las aplicaciones asociadas y ejecutar la retirada de forma ordenada.

Desactivar antes de eliminar cuando sea prudente

Algunas aplicaciones vinculan información, documentos o responsabilidades a una cuenta. Puede ser necesario transferir propiedad o conservar trazabilidad antes de eliminarla definitivamente.

Transferir recursos

Proyectos, automatizaciones, documentos, paneles, integraciones o configuraciones pueden tener propietario. La baja debe reasignarlos antes de desactivar la identidad.

Revocar sesiones y credenciales

Cuando la herramienta lo permita, conviene cerrar sesiones activas, retirar tokens, revocar claves o desconectar dispositivos asociados.

Cambiar credenciales compartidas

Si la persona tenía acceso a cuentas compartidas, la baja incluye renovar esos secretos o retirarla del mecanismo de compartición.

Actualizar licencias y facturación

La cuenta puede cerrarse y la licencia seguir cobrándose. Conviene coordinar ambos procesos para que el gasto refleje el uso real.

Controlar accesos temporales

Los accesos temporales son peligrosos cuando no contienen un mecanismo de finalización. Una cuenta creada para «solo esta semana» puede permanecer activa durante años.

Registrar fecha de expiración

Todo acceso temporal debería nacer con una fecha de revisión o cierre.

Limitar privilegios y alcance

La temporalidad no justifica conceder administración completa. El acceso debe cubrir solo la tarea prevista.

Utilizar cuentas de invitado cuando existan

Muchas plataformas permiten invitados o colaboradores con capacidades reducidas. Pueden ser preferibles a crear usuarios internos completos.

Revisar al terminar el trabajo

El cierre de un proyecto, una auditoría o una intervención técnica debe incluir explícitamente la retirada de accesos temporales.

Detectar cuentas inactivas, huérfanas y olvidadas

Una cuenta puede existir sin que nadie la utilice ni sepa por qué sigue activa. Estas identidades aumentan superficie de ataque, confusión y costes.

Cuenta inactiva

Pertenece a una identidad conocida, pero no muestra uso durante un periodo significativo para esa aplicación.

Cuenta huérfana

No tiene propietario o responsable identificable. Puede haber pertenecido a una persona, proveedor o integración que ya no existe.

Cuenta duplicada

La misma persona aparece dos veces por cambios de correo, invitaciones repetidas o migraciones.

Cuenta técnica desconocida

Parece inactiva desde el punto de vista humano, pero podría sostener una integración. Antes de retirarla hay que comprobar dependencias.

El artículo sobre cómo detectar aplicaciones infrautilizadas recuerda que el uso visible no siempre explica el valor de una herramienta. La misma cautela se aplica a las cuentas: una identidad sin sesiones humanas puede seguir ejecutando procesos automáticos.

Coordinar cuentas y licencias sin confundirlas

La gestión de usuarios tiene relación directa con las licencias, pero son dos capas distintas.

Cuenta sin licencia

Puede existir en modo invitado, archivado, suspendido o con funciones limitadas.

Licencia asignada a una cuenta inactiva

Es una señal de posible gasto innecesario.

Licencias compartidas o concurrentes

Algunos modelos no se asignan uno a uno. La organización debe documentar cómo se relacionan con los usuarios reales.

Baja coordinada

Cuando se elimina una cuenta, conviene confirmar si la licencia queda disponible, debe reasignarse o requiere una acción contractual.

El control económico completo se desarrolla en cómo gestionar correctamente las licencias de software. Aquí basta con mantener una regla: ninguna cuenta debería consumir una licencia sin una necesidad identificada y ninguna licencia debería depender de una cuenta que ya no forma parte de la operativa.

Mantener coherencia en MFA y recuperación

Las aplicaciones pueden ofrecer métodos de doble factor muy distintos. El objetivo empresarial no es imponer una tecnología idéntica, sino evitar que las cuentas críticas queden protegidas de forma incoherente.

Clasificar aplicaciones por criticidad

Correo, identidad, administración, facturación, almacenamiento importante y otras aplicaciones críticas deberían recibir requisitos de autenticación más exigentes que una herramienta auxiliar de bajo impacto.

Evitar dependencia de un único dispositivo

Si todos los códigos de recuperación y segundos factores dependen del mismo teléfono, la empresa ha creado un punto único de bloqueo.

Controlar cambios de teléfono y número

Cuando una persona cambia de dispositivo, debe verificarse que las cuentas importantes han trasladado correctamente sus factores de autenticación.

No convertir la matriz en almacén de secretos

Puede registrarse que MFA está activo, qué tipo de mecanismo se utiliza y quién es responsable de recuperación, pero no es necesario almacenar en la matriz los códigos o claves de emergencia.

Separar el inventario de cuentas de las contraseñas y secretos

El registro de cuentas debe poder ser consultado por quienes necesitan gobernar accesos. Las contraseñas, tokens y claves privadas requieren un nivel de protección distinto.

Qué puede registrar la matriz

• nombre de la cuenta;
• aplicación;
• propietario;
• tipo de cuenta;
• nivel de acceso;
• MFA activo o no;
• método de recuperación;
• ubicación segura del secreto;
• fecha de revisión.

Qué no debería registrar en texto abierto

• contraseñas;
• claves API;
• códigos de recuperación;
• tokens;
• claves privadas;
• preguntas o respuestas de recuperación.

Esta separación permite compartir la información de gobierno sin exponer los secretos que habilitan el acceso.

Cuándo ayuda el inicio de sesión centralizado

Cuando muchas aplicaciones permiten utilizar una misma fuente de identidad, el inicio de sesión centralizado puede simplificar altas, bajas y autenticación. Sin embargo, no debe implantarse únicamente por moda.

Ventajas

• menos identidades independientes;
• bajas más rápidas;
• políticas de autenticación más coherentes;
• menor número de contraseñas;
• mejor visibilidad de accesos;
• posibilidad de asignar aplicaciones mediante grupos.

Limitaciones

No todas las aplicaciones soportan el mismo sistema. Algunas reservan SSO para planes superiores. Otras siguen necesitando cuentas locales de emergencia o administración.

No centralizar por encima de la capacidad operativa

Una microempresa no necesita una arquitectura de identidad compleja si el coste y mantenimiento superan el problema que pretende resolver. La solución debe ser proporcional al número de usuarios, aplicaciones y criticidad.

Evitar que la identidad centralizada se convierta en otro punto único de fallo

Centralizar reduce desorden, pero también concentra importancia. Si muchas aplicaciones dependen de un mismo proveedor de identidad, una incidencia o bloqueo en esa capa puede afectar a todo el entorno.

Conservar acceso de emergencia cuando sea necesario

Determinadas aplicaciones críticas pueden necesitar una cuenta local o mecanismo alternativo que permita recuperar administración si falla la identidad central.

Documentar la cadena de recuperación

Debe saberse cómo recuperar el proveedor de identidad, quién puede hacerlo y qué ocurre si la persona administradora principal no está disponible.

Evitar dependencias circulares

Un ejemplo frágil sería necesitar acceder al correo para recuperar la identidad central y necesitar la identidad central para acceder al correo. Las cadenas de recuperación deben revisarse como arquitectura, no como formularios aislados.

Probar escenarios de bloqueo

No es necesario provocar una caída real, pero sí comprobar que existe una ruta comprensible para recuperar cuentas críticas.

Cuentas de usuario y movilidad profesional

La organización de identidades debe funcionar cuando las personas trabajan desde un portátil, un móvil, una oficina temporal o fuera de la red habitual. La movilidad añade dispositivos y sesiones, pero no debería romper el modelo de cuentas.

Dispositivos autorizados y sesiones

En aplicaciones sensibles conviene saber qué dispositivos o sesiones permanecen activos y poder revocarlos cuando se pierde un equipo.

Teléfono como segundo factor

Si el móvil participa en la autenticación, su sustitución, pérdida o reparación debe estar contemplada dentro del ciclo de vida de la cuenta.

Acceso desde dispositivos personales

Cuando se permite, deben definirse límites claros sobre qué aplicaciones pueden utilizarse, qué datos pueden descargarse y qué ocurre al finalizar la colaboración.

No crear cuentas alternativas para resolver problemas de movilidad

Si una persona no puede acceder desde fuera, crear un segundo usuario «para viajes» suele empeorar trazabilidad. Es preferible corregir el método de acceso de la cuenta principal.

Asegurar la titularidad empresarial de las cuentas críticas

Una aplicación importante puede estar perfectamente configurada y seguir siendo frágil si la suscripción, administración o recuperación dependen de una identidad personal que la empresa no controla.

Cuenta titular

Debe conocerse qué identidad es propietaria del servicio, quién recibe facturas y quién puede cambiar la administración.

Administradores internos

Los proveedores externos pueden tener acceso, pero la empresa debería conservar capacidad real para recuperar el control.

Correos de recuperación

Las direcciones de recuperación deben formar parte del mapa de identidades. Una cadena de recuperación puede ser más importante que el usuario que trabaja diariamente en la aplicación.

Datos de contacto actualizados

Teléfonos antiguos, correos desactivados o datos de una persona que ya no participa pueden impedir recuperar una cuenta crítica.

Mantener trazabilidad sin crear burocracia excesiva

Una pequeña empresa no necesita registrar cada inicio de sesión en una hoja manual. La trazabilidad útil consiste en conservar suficiente evidencia para explicar decisiones relevantes.

Qué merece quedar registrado

• alta de una cuenta;
• concesión de privilegios administrativos;
• cambio de función;
• acceso temporal importante;
• baja;
• cambio de propietario de una cuenta crítica;
• creación de una identidad técnica;
• excepción a una regla de acceso;
• resultado de revisiones periódicas.

Utilizar los registros nativos

Cuando la aplicación ofrece historial de usuarios, auditoría o actividad administrativa, conviene aprovecharlo en lugar de duplicar manualmente toda la información.

Registrar la decisión, no cada detalle técnico

Una nota breve como «acceso administrativo temporal concedido para migración; retirar el 15/10» puede ser más útil que una documentación extensa que nadie actualiza.

Revisar periódicamente el mapa de cuentas

El entorno cambia continuamente: se incorporan aplicaciones, usuarios cambian de función, aparecen integraciones, proveedores terminan proyectos y herramientas modifican sus modelos de permisos.

Revisión por aplicación

Comprobar que todos los usuarios activos siguen necesitando acceso y que administradores, invitados y cuentas técnicas están identificados.

Revisión por persona

Comprobar que cada identidad conserva únicamente las aplicaciones y permisos necesarios para su función actual.

Revisión por excepción

Las cuentas compartidas, temporales, administrativas y externas deberían revisarse con mayor atención que los usuarios ordinarios estables.

Revisión vinculada a eventos

Además de la periodicidad, debe existir revisión tras altas, cambios de rol, bajas, sustitución de aplicaciones, incidentes relevantes y cambios de proveedor.

Priorizar por riesgo

No todas las aplicaciones requieren la misma frecuencia. Las críticas o que contienen información sensible merecen una revisión más cercana que herramientas auxiliares.

Indicadores útiles para saber si el sistema está ordenado

Unos pocos indicadores permiten detectar degradación sin construir un cuadro de mando complejo.

Evitar objetivos artificiales

No se trata de conseguir cero cuentas externas ni un único administrador. Los indicadores ayudan a descubrir anomalías; la decisión depende del contexto y del riesgo de cada aplicación.

Ejemplo práctico en una pequeña empresa de servicios

Imaginemos una empresa con ocho personas que utiliza correo y documentos, CRM, facturación, gestión de proyectos, almacenamiento, una herramienta de automatización y varias aplicaciones auxiliares. Hasta ahora cada servicio se ha administrado por separado.

Situación inicial

• dos personas utilizan correos personales en herramientas antiguas;
• cuatro usuarios son administradores del gestor de proyectos;
• un proveedor conserva acceso al hosting;
• una cuenta compartida gestiona una automatización;
• hay doce licencias de CRM para ocho personas;
• nadie sabe qué correo recupera la cuenta principal de facturación;
• una persona que dejó la empresa conserva acceso a dos servicios.

1. Crear la matriz

Se listan ocho personas, dos proveedores, tres identidades funcionales y dos cuentas técnicas. Después se cruzan con todas las aplicaciones.

2. Normalizar identidades

Las cuentas importantes pasan a utilizar identidades corporativas. Se documentan los dos casos donde un proveedor exige una cuenta externa.

3. Reducir administradores

El gestor de proyectos queda con dos administradores. El resto utiliza cuentas ordinarias.

4. Corregir la automatización

La cuenta compartida se sustituye por una identidad técnica cuyo propietario es la función de tecnología y cuyo secreto se guarda en el sistema correspondiente.

5. Revisar el proveedor

Se mantiene acceso al hosting porque el contrato sigue activo, pero se limita el permiso, se fija una fecha de revisión y la empresa confirma que conserva su propia cuenta administrativa.

6. Coordinar licencias

Se identifican cuatro cuentas de CRM que ya no necesitan asiento completo. La decisión económica se gestiona en paralelo al control de usuarios.

7. Resolver recuperación

La cuenta principal de facturación pasa a tener una dirección funcional de recuperación y un segundo administrador autorizado.

8. Cerrar cuentas antiguas

Se retiran los dos accesos de la persona que ya no trabaja y se cambian los secretos compartidos que conocía.

9. Definir altas y bajas

A partir de ese momento, cualquier incorporación o salida se gestiona mediante una lista de comprobación basada en la matriz. El sistema deja de depender de recordar aplicaciones una por una.

El resultado no es una arquitectura compleja. Es una visión común que permite saber quién accede a qué y actuar con rapidez cuando cambia una persona, una función o una aplicación.

Método completo paso a paso

1. Obtener la lista de aplicaciones

Partir del inventario o documentación existente y excluir herramientas que no requieran cuentas.

2. Enumerar identidades

Personas, proveedores, invitados, cuentas funcionales y cuentas técnicas.

3. Crear la matriz persona-aplicación

Registrar existencia de cuenta, tipo, rol, licencia y estado.

4. Normalizar nombres e identidades

Reducir alias, correos personales y duplicados sin romper cuentas activas.

5. Clasificar tipos de cuenta

Nominativa, compartida, funcional, administrativa, técnica, externa o emergencia.

6. Identificar propietarios

Cada cuenta no nominativa debe tener una persona o función responsable.

7. Revisar administradores

Eliminar privilegios innecesarios y asegurar continuidad administrativa.

8. Revisar cuentas compartidas

Justificar su existencia, limitar usuarios y custodiar secretos adecuadamente.

9. Revisar cuentas técnicas

Documentar finalidad, dependencias, permisos y responsable.

10. Revisar externos e invitados

Definir alcance y fecha de expiración o revisión.

11. Comprobar recuperación

Verificar correos, teléfonos, códigos y administradores de respaldo en aplicaciones críticas.

12. Coordinar MFA

Aplicar requisitos proporcionados a la criticidad y evitar dependencia de un único dispositivo.

13. Separar cuentas administrativas

Cuando la aplicación y el riesgo lo justifiquen, diferenciar uso cotidiano y administración.

14. Coordinar cuentas y licencias

Detectar licencias asignadas a identidades que ya no las necesitan.

15. Definir alta

Crear cuentas según función y actualizar la matriz en el mismo proceso.

16. Definir cambio de rol

Recalcular accesos y retirar privilegios antiguos.

17. Definir baja

Recorrer aplicaciones, sesiones, recursos, cuentas compartidas, licencias y dispositivos.

18. Programar revisiones

Aplicaciones críticas y excepciones primero; el resto según un calendario razonable.

19. Medir indicadores simples

Cuentas huérfanas, administradores, externos, inactivos y bajas incompletas.

20. Integrar el procedimiento con la documentación

La matriz debe enlazar con la ficha de cada aplicación y formar parte de su ciclo de vida.

Errores frecuentes

Gestionar cada aplicación de forma aislada

Impide saber todo lo que debe retirarse cuando cambia una persona.

Usar el correo personal como identidad empresarial

Introduce dependencia y dificulta recuperación o baja.

Compartir cuentas cuando existen usuarios individuales

Reduce trazabilidad y complica la retirada de accesos.

Dar permisos administrativos por comodidad

Aumenta el impacto de errores y compromisos.

Tener un único administrador

Puede bloquear la recuperación de aplicaciones críticas.

No distinguir cuenta y licencia

La empresa puede seguir pagando después de cerrar el acceso.

Eliminar cuentas antes de transferir recursos

Puede dejar documentos, automatizaciones o proyectos sin propietario.

Olvidar cuentas técnicas

Las integraciones quedan fuera de altas, bajas y revisiones.

No poner fecha de cierre a invitados

Los accesos temporales se vuelven permanentes.

Guardar contraseñas en la matriz

Mezcla gobierno de accesos con custodia de secretos.

Centralizar identidad sin preparar recuperación

Un sistema ordenado puede convertirse en un gran punto único de bloqueo.

Revisar solo cuando alguien se va

Los permisos excesivos también aparecen durante cambios internos y proyectos temporales.

Copiar los accesos de otro usuario sin analizar

Propaga privilegios históricos y excepciones innecesarias.

Confiar solo en el nombre de usuario

Alias, cambios de correo y duplicados pueden ocultar que dos cuentas pertenecen a la misma identidad.

Crear una solución demasiado compleja

El sistema debe ser mantenible por la empresa. Una matriz sencilla y actualizada vale más que una plataforma avanzada abandonada.

Lista de comprobación

Preguntas frecuentes

Conclusión

Organizar correctamente las cuentas de usuario de todas las aplicaciones exige dejar de tratar cada herramienta como un mundo independiente. La empresa necesita una visión transversal de identidades, cuentas, permisos, licencias, administradores, invitados y procesos automáticos.

La base práctica es una matriz que permita responder quién accede a qué y con qué nivel. Sobre ella se construyen reglas sencillas: cuentas nominativas por defecto, cuentas compartidas solo como excepción, identidades funcionales para responsabilidades estables, administración separada cuando el riesgo lo justifica y cuentas técnicas con propietario humano conocido.

El verdadero control aparece cuando ese mapa se integra con el ciclo de vida de las personas. Un alta crea únicamente los accesos necesarios; un cambio de función recalcula permisos en lugar de acumularlos; una baja recorre todas las aplicaciones, transfiere recursos, revoca sesiones, actualiza cuentas compartidas y libera licencias.

También deben gobernarse identidades que suelen quedar fuera de los procedimientos habituales: proveedores, invitados, bots, integraciones, cuentas de emergencia y usuarios locales que permanecen aunque exista inicio de sesión centralizado. Cada excepción necesita finalidad, propietario y fecha de revisión.

La seguridad técnica importa, pero el orden organizativo es igual de importante. Una empresa con doble factor en todas sus cuentas puede seguir teniendo un problema serio si no sabe qué cuentas existen, quién las controla o cómo retirarlas. Del mismo modo, un sistema de identidad centralizado puede simplificar mucho la administración y convertirse en un nuevo punto crítico si no existe recuperación.

El objetivo final es sencillo: que ninguna cuenta importante sobreviva por inercia y que ningún cambio de persona obligue a reconstruir de memoria todos los accesos. Cuando las identidades están organizadas, las aplicaciones dejan de acumular usuarios históricos y se convierten en un entorno más fácil de asegurar, delegar, auditar y mantener.