Respuesta directa
Una cuenta huérfana carece de un responsable actual. Un permiso en la sombra es un permiso efectivo que no aparece en el registro formal. El acceso residual permanece después de terminar la tarea o necesidad correspondiente. Un autenticador sin responsable es una clave, un token, un dispositivo o un mecanismo similar que sigue funcionando sin un responsable o patrocinador válido.
En lenguaje claro
Una cuenta que sigue activa para un antiguo empleado puede estar huérfana. Un permiso oculto heredado mediante un grupo es un permiso en la sombra. El acceso a una carpeta que continúa tras terminar el proyecto es acceso residual. Una clave API operativa de la que nadie responde es un autenticador sin responsable.
Por qué importa
Estas cuatro situaciones pueden no aparecer en las listas ordinarias. Crean oportunidades de ataque, actuaciones equivocadas e incertidumbre sobre quién responde de ellas.
No confundir
- Una cuenta, un permiso, una vía de acceso y un autenticador son objetos distintos.
- Una cuenta puede tener responsable y, aun así, contener un permiso en la sombra.
- Una persona puede seguir empleada y conservar accesos que ya no necesita para su función actual.
Qué hacer
- Inventaríe cada identidad humana, de servicio, de aplicación y de agente.
- Asigne a cada identidad un responsable, un patrocinador, una finalidad y una fecha de revisión.
- Calcule la autoridad efectiva tanto de los permisos directos como de la pertenencia a grupos.
- Revise tokens, claves y cuentas sin uso prolongado.
- Concilie los registros de recursos humanos, registros oficiales y sistemas.
- Antes de desactivar un elemento, identifique sus dependencias y prepare un plan de recuperación controlado.
Cómo auditarlo
- ¿Existe una cuenta sin responsable o patrocinador?
- ¿Surge autoridad por una vía ausente del registro formal de funciones?
- ¿Continúa el acceso después de terminar la tarea o el contrato?
- ¿Existe un autenticador compartido o cuyo controlador se desconoce?
- ¿Están registrados el último uso, la finalidad y la fecha de revisión?
Límite
No toda cuenta sin uso es maliciosa. Sin embargo, si no pueden demostrarse su responsable, finalidad y necesidad continuada, debe tratarse como un riesgo.
Recuérdalo en una frase
No deje abierto un acceso cuando no puedan demostrarse su responsable, finalidad y necesidad actual.
Fuentes de este registro
- S24NIST SP 800-63-4, *Digital Identity Guidelines*Estándar
- S25NIST SP 800-63B-4, *Authentication and Authenticator Management*Estándar
- S26NIST SP 800-53 Rev. 5, *Security and Privacy Controls*Estándar
- S27IETF, RFC 7644, *System for Cross-domain Identity Management: Protocol*Estándar
- S28IETF, RFC 9967, *SCIM Roles and Entitlements Extension*Estándar
- S29Microsoft Learn, *Application and Service Principal Objects in Microsoft Entra ID*Documentación del proveedor
- S30Microsoft Learn, *Managed Identities for Azure Resources*Documentación del proveedor