SCIM y aprovisionamiento automático de cuentas

El servicio de aprovisionamiento trabaja por ciclos. Un primer ciclo consulta todos los usuarios y grupos de origen, y después los ciclos incrementales tratan solo lo que ha cambiado desde la última marca registrada². Si un usuario no tiene cuenta correspondiente en la aplicación, se crea. Si la tiene, se actualiza².

La baja sigue varios casos previstos. Un usuario desactivado o eliminado a la «papelera» en el directorio se desactiva en la aplicación de destino. En una aplicación SCIM, desactivar equivale a pedir que la propiedad «active» valga falso². Treinta días después de la eliminación en el directorio, el usuario se elimina definitivamente y el servicio envía entonces una solicitud de eliminación a la aplicación². Un usuario cuyos grupos o derechos cambian también puede salir del ámbito, lo que cuenta como una baja de la aplicación². Con grupos dinámicos, la rapidez de la retirada depende de la velocidad con que el grupo reevalúa a sus miembros².

Todo queda registrado en los registros de aprovisionamiento, que anotan las lecturas y escrituras realizadas en los sistemas de origen y de destino².

• Avise con antelación. Comunique a su responsable y a recursos humanos su incorporación, cambio de puesto o baja con la fecha exacta, porque es la modificación del directorio la que desencadena todo lo demás.
• Responsables: declaren los cambios de puesto igual que las bajas. Un cambio de rol puede exigir retirar accesos, no solo añadirlos¹.
• No cree ninguna cuenta fuera del circuito oficial: ni registro personal en un servicio con la dirección profesional, ni cuenta abierta a mano en la interfaz de administración de una aplicación sin informar al equipo informático. Una cuenta así no está vinculada al directorio, de modo que nadie la cerrará automáticamente.
• Devuelva sus accesos antes de irse: tarjeta de acceso, llaves de seguridad, dispositivos y cualquier acceso recibido por un canal distinto de su cuenta habitual.
• Active la autenticación de varios factores en las cuentas que sigan abiertas. CISA sitúa las llaves de seguridad a la cabeza de los métodos y el código por SMS o correo electrónico en último lugar⁷.

Aplicación no conectada

Una aplicación del catálogo admite aprovisionamiento manual o automático. En modo manual no existe un conector automático: las cuentas se crean a mano, por ejemplo en el portal de administración de la aplicación o mediante una hoja de cálculo¹. En estas aplicaciones, la baja requiere una acción humana. Una aplicación creada a partir de un simple registro OIDC no está habilitada para el aprovisionamiento automático³.

Cambios hechos directamente en la aplicación

El servicio ignora las modificaciones hechas en aplicaciones externas y no las revierte: se basa en lo que cambia en el directorio³. Una cuenta creada o modificada localmente escapa, por tanto, al circuito. Microsoft indica que el aprovisionamiento también puede detectar cuentas existentes en una aplicación, incluidas las locales o huérfanas¹. MITRE recomienda eliminar las cuentas huérfanas, por ejemplo las que no tienen propietario, en auditorías periódicas, y desactivar automáticamente las cuentas tras un periodo de inactividad, por ejemplo 30 días⁴.

Cuentas locales, cuentas compartidas, contraseñas

El aprovisionamiento de contraseñas no es compatible³. Algunas aplicaciones locales no están federadas con el directorio y exigen contraseñas locales³. Una cuenta compartida o una contraseña local que conoce alguien que se va no se cierra con la baja de su titular: hay que cambiarla o eliminarla a mano.

Plazos y errores

El intervalo entre dos ciclos no es configurable³. Cuando un error impide modificar a un usuario, la operación se reintenta en el ciclo siguiente, y un administrador debe consultar los registros para hallar la causa². Si la mayoría de las llamadas fallan, por ejemplo por credenciales de administración no válidas, el trabajo pasa a cuarentena, con ciclos ralentizados a uno por día, y se desactiva después de más de cuatro semanas². Una baja puede, por tanto, no reflejarse a tiempo sin que nadie se dé cuenta.

Tokens y sesiones que sobreviven

Según MITRE, un atacante que controla una cuenta en la nube puede crear credenciales adicionales duraderas para mantenerse en ella, y esas credenciales pueden eludir controles como la autenticación de varios factores⁵. Las fuentes citadas aquí no dicen si una sesión abierta se detiene en cuanto se desactiva una cuenta SCIM. Por parte de la aplicación, OWASP indica que, cuando una sesión termina, la aplicación debe invalidarla en el cliente y en el servidor, y que el lado del servidor es el más importante y obligatorio desde el punto de vista de la seguridad⁶. También recomienda un tiempo de inactividad y un tiempo absoluto para todas las sesiones⁶. Cuando un empleado se va, el equipo informático debe por tanto comprobar los tokens de acceso, las contraseñas de aplicación y las sesiones, además de la propia cuenta.