Una identidad técnica necesita propósito, responsable y ciclo de vida. Disponer de un inventario ayuda, pero su valor depende de poder relacionarlo con accesos y dependencias reales.
La identidad tiene que tener una finalidad
Cuando encuentro una cuenta técnica, mi primera pregunta es qué servicio depende de ella. El nombre puede sugerir una función, pero no demuestra que esa función siga existiendo. Necesito relacionar la identidad con un proceso, un responsable y los recursos que utiliza.
Una aplicación puede tener varias identidades y una misma integración puede utilizar mecanismos diferentes según el entorno. Registrar esa relación ayuda a localizar dependencias antes de modificar permisos o credenciales. También conviene distinguir quién decide el alcance del acceso y quién mantiene la implementación. Si todo queda asignado a “IT”, tendremos un inventario con un campo completo, pero quizá nadie capaz de explicar si ese permiso sigue siendo necesario o qué impacto tendría retirarlo.
Registrar el propósito
Relacionar cada identidad con una aplicación, workload o agente. Documentar propietario, entorno, recursos accesibles y mecanismo de autenticación sin guardar secretos en el inventario.
Descubrir también dónde se usa
Empezaría combinando la información de identidad, plataformas cloud, aplicaciones e inventarios de secretos. Cada fuente muestra una parte. Una cuenta registrada puede tener varias credenciales, y una clave encontrada en un repositorio puede corresponder a una identidad de otra plataforma.
El inventario debe registrar referencias y metadatos, nunca copiar los secretos. Necesitamos saber dónde se custodian y quién puede recuperarlos. También revisaría despliegues, tareas programadas y procesos de integración: ahí pueden aparecer dependencias que no están documentadas. Los registros de uso ayudan a contrastar la finalidad declarada, siempre que conozcamos su cobertura. La ausencia de eventos puede significar falta de visibilidad, una actividad periódica o un servicio retirado. Hay que comprobar cuál de esas situaciones tenemos.
El ciclo de una identidad no humana
- RegistrarFinalidad, propietario, servicio y entorno.
- AutorizarPermisos ajustados a las operaciones necesarias.
- UtilizarAutenticación y actividad trazables.
- RevisarUso, credenciales, permisos y dependencias.
- RetirarRevocar accesos y verificar el efecto.
Los cambios de función o entorno obligan a revisar el alcance; la retirada debe considerar los consumidores.
Limitar y revisar el acceso
Separar identidades por función y entorno cuando sea viable. Evaluar credenciales de corta duración y mecanismos de federación según el soporte real de la plataforma.
Separar identidad, credencial y permiso
Son elementos relacionados, pero no equivalentes. Una identidad representa al servicio; una credencial permite autenticarse; los permisos determinan qué puede hacer después. Cambiar una contraseña no corrige un rol excesivo. Eliminar una clave tampoco garantiza que no exista otro mecanismo de autenticación.
Preferiría credenciales temporales o identidades asociadas al workload cuando la plataforma y la aplicación lo soporten. Esa elección reduce ciertas tareas de custodia, pero sigue requiriendo permisos adecuados y control sobre quién puede ejecutar el workload o actuar como esa identidad. Si debemos mantener un secreto de larga duración, definiría su almacenamiento, distribución, rotación y recuperación ante fallo. Hay que probar el cambio con la aplicación, incluyendo las instancias que pueden conservar la credencial anterior.
Ejemplo: una integración entre servicios
Una integración consulta un repositorio y escribe resultados en otro sistema. En lugar de reutilizar una cuenta compartida para ambos entornos, puede evaluarse una identidad específica con acceso a las operaciones necesarias. El registro debe permitir responder quién aprueba esos permisos y qué servicio dejará de funcionar al revocarlos. Si existe una credencial de larga duración, su custodia y rotación deben quedar explícitas.
Revisar permisos sin perder la función
Para ajustar una identidad existente, elegiría primero una función concreta y registraría las operaciones necesarias. Consultar un recurso, escribir resultados y administrar el servicio son capacidades diferentes. Una integración puede haber recibido un rol amplio para resolver la implantación inicial y conservarlo aunque su actividad habitual sea mucho más limitada.
Los registros pueden ayudar a preparar una propuesta de permisos, pero no muestran necesariamente todas las actividades legítimas. Debemos contrastarlos con el responsable y considerar procesos de cierre, mantenimiento o recuperación. La revisión debe incluir quién puede cambiar la configuración de la identidad, emitir credenciales o utilizarla desde otro workload. Ese acceso indirecto puede ser más importante que el permiso visible en una aplicación.
Probaría el nuevo alcance con operaciones permitidas y otras que deberían quedar denegadas. También documentaría la respuesta ante un fallo, para evitar que la solución inmediata sea devolver un rol administrativo completo sin revisión.
Cuando la prueba termine, registraría el resultado, la versión de permisos y los consumidores afectados. Si la aplicación cambia, ese alcance debe volver a revisarse. No hace falta esperar a una auditoría para hacerlo: incorporar una nueva integración, cambiar de propietario o añadir otro entorno son momentos naturales para confirmar que la identidad sigue representando la misma función y que sus privilegios siguen siendo necesarios.
Planificar la retirada
Definir qué sucede al retirar una aplicación o cambiar al propietario. Probar la revocación y revisar dependencias antes de eliminar credenciales.
Retirar sin romper y revocar cuando importa
Para una retirada planificada, primero comprobaría consumidores, frecuencia de ejecución y dependencias. Una integración que solo funciona al cierre de mes puede parecer inactiva durante semanas. Revisaría la finalidad con el responsable y probaría la retirada en un alcance controlado cuando sea posible.
Ante un compromiso, el objetivo cambia: necesitamos detener el uso no autorizado y activar el procedimiento de respuesta. Debemos saber qué revoca realmente cada acción y qué credenciales o sesiones siguen válidas. Una nueva credencial no invalida necesariamente todas las anteriores. El plan tiene que identificar los mecanismos de autenticación afectados y las comprobaciones que confirman la contención. Después recuperaremos la función legítima con permisos revisados, evitando volver automáticamente a la configuración que permitió el problema.
Evitar el inventario sin contexto
Contar identidades no explica el riesgo por sí solo. Resulta más útil identificar las que carecen de propietario, mantienen privilegios elevados o no pueden relacionarse con un servicio activo. La ausencia de uso reciente es una señal para investigar, no una prueba automática de que una identidad pueda eliminarse.
Los agentes también entran en este modelo
Si un agente utiliza herramientas, necesito identificar con qué identidad actúa y qué permisos recibe. También quién inició la ejecución y si existe delegación de un usuario o una identidad propia del servicio. Sin esa distinción, podemos atribuir una acción a la integración sin saber qué solicitud la originó.
Para medir el avance, miraría identidades con responsable y finalidad validados, permisos amplios pendientes de revisión, credenciales de larga duración y retiradas probadas. No buscaría simplemente reducir el número total: separar funciones puede aumentar las identidades y mejorar el control. Lo importante es que cada una tenga una explicación, un alcance y un ciclo de vida. Esa revisión debe continuar cuando cambia la aplicación, el proveedor o el equipo responsable.
Referencias para profundizar
Fuentes oficiales para contrastar y ampliar estos conceptos. Este artículo presenta un enfoque práctico; no reproduce los requisitos completos de las referencias.
Los ejemplos son ilustrativos. Las decisiones de implementación deben adaptarse a los requisitos y dependencias de cada organización.