Roles SAP en S/4HANA: ¿rediseñar antes o después de migrar?
8 de octubre de 2026
Clonar usuarios en SAP: ¿una solución rápida o un riesgo de seguridad?
Escrito por
Nathalia Cortés Riascos
Agente de soporte
Octubre 2025
Hay una petición que aparece con bastante frecuencia en el soporte de Seguridad SAP:
“Necesito que este usuario tenga los mismos accesos que aquel.”
Para quien realiza la solicitud es una forma sencilla de explicar lo que necesita. No tiene por qué conocer el modelo de roles ni saber qué autorizaciones concretas permiten realizar cada actividad. Si dos personas hacen aparentemente el mismo trabajo, utilizar una como referencia parece razonable.
El problema empieza cuando desde Seguridad SAP traducimos esa referencia como “copiar todos los roles del usuario A al usuario B”.
Porque una cosa es compartir una función y otra muy distinta compartir todo el histórico de autorizaciones.
Modelo de autorizaciones
Mismo puesto no significa mismos accesos acumulados
Pensemos en un modelo de autorizaciones construido sobre roles de puesto de trabajo.
Si dos usuarios ocupan el mismo puesto y ese rol representa correctamente las funciones que deben desempeñar, tiene todo el sentido que ambos tengan asignado ese mismo rol.
Precisamente esa es una de las ventajas de trabajar con un modelo de este tipo: la autorización se vincula a una necesidad de negocio identificable y no a una persona concreta.
El problema aparece cuando tomamos como referencia al usuario y no al puesto.
Además del rol correspondiente a su función, ese usuario puede tener otros accesos derivados de una sustitución, un proyecto, una responsabilidad adicional, una excepción aprobada en su momento o una necesidad temporal que nunca llegó a retirarse.
Nada de eso forma necesariamente parte de su puesto.
Si clonamos al usuario completo, dejamos de replicar una función y empezamos a replicar también todas las decisiones particulares que se han ido tomando sobre esa persona.
Riesgos heredados
Y con ellas, también sus riesgos
Entre esas asignaciones adicionales puede haber accesos críticos o combinaciones que generen conflictos de Segregación de Funciones (SoD).
Incluso pueden existir conflictos conocidos y aceptados porque responden a una circunstancia específica del usuario origen y están sujetos a determinadas medidas de control.
Trasladarlos automáticamente a otra persona cambia completamente el escenario.
Por eso, que dos usuarios ocupen el mismo puesto puede justificar que compartan el rol asociado a ese puesto.
No justifica que compartan automáticamente todos los roles que uno de ellos tenga asignados.
La diferencia es importante: estamos heredando el puesto, no al usuario.
Riesgo acumulativo
Cuando la clonación se convierte en procedimiento
Clonar un usuario puede ser una solución puntual. Lo preocupante es convertirla en el mecanismo habitual para gestionar nuevas altas o cambios de función.
“Ponle lo mismo que a María.”
Después:
“Ponle lo mismo que a Pedro, que hace lo mismo que María.”
Con el tiempo, resulta difícil distinguir qué accesos proceden realmente del puesto y cuáles se han ido propagando simplemente porque estaban presentes en el usuario utilizado como referencia.
Esto genera además un efecto acumulativo. Una excepción individual puede terminar convertida, después de varias clonaciones, en un acceso aparentemente normal para todo un colectivo.
Y llegado ese punto, la pregunta “¿por qué tiene este usuario este acceso?” empieza a ser bastante difícil de responder.
Seguridad SAP
El solicitante puede pedir una copia. Seguridad debería interpretar la necesidad.
Aquí es donde el papel de un servicio especializado de Seguridad SAP va más allá de ejecutar técnicamente una solicitud.
Si el negocio indica que una nueva incorporación realizará las mismas funciones que otro usuario, esa información es útil. Nos está dando una referencia funcional.
Pero Seguridad debería ser capaz de traducirla al modelo de autorizaciones:
¿Qué puesto ocupa?
¿Qué rol representa ese puesto?
¿Qué ámbito organizativo necesita?
¿Existen accesos adicionales que deban solicitarse y justificarse de manera independiente?
No se trata de trasladar a Seguridad la decisión sobre qué puede hacer el negocio. Esa responsabilidad sigue correspondiendo a quien solicita y aprueba los accesos.
Se trata de no convertir una indicación funcional —“va a hacer lo mismo que esta persona”— en una copia indiscriminada de autorizaciones.
Modelo de roles
Un modelo de roles debería permitirnos hacerlo mejor
Cuando existe un modelo de autorizaciones estructurado por puestos de trabajo, la clonación pierde buena parte de su razón de ser.
Si sabemos que un usuario ocupa el puesto X, deberíamos poder identificar qué rol corresponde a X sin necesidad de reconstruir su función mirando los accesos de otra persona.
Y cualquier autorización que quede fuera de ese puesto debería tratarse por lo que realmente es: una asignación adicional que necesita su propia justificación.
Esto también facilita algo que suele ser mucho más complicado cuando trabajamos por clonación: explicar por qué alguien tiene acceso.
Ante una auditoría, una revisión periódica o simplemente una recertificación, “lo tiene porque lo tenía el usuario que utilizamos como referencia cuando se incorporó” aporta poca información.
“Lo tiene porque corresponde a su puesto de trabajo” establece una relación mucho más clara entre autorización y necesidad.
Puede haber excepciones. Habrá usuarios que necesiten accesos adicionales, responsabilidades temporales o combinaciones específicas. Precisamente por eso interesa que esas excepciones sean visibles como excepciones y no queden escondidas dentro de una clonación.
El usuario de referencia puede ayudarnos a entender una necesidad. Incluso puede servir para contrastar si el modelo está representando correctamente una función.
Conclusión
Pero el objeto que deberíamos replicar no es la persona.
Es el puesto y las funciones que queremos autorizar.
