Cuando se trabaja en seguridad SAP y se es responsable de gestionar el control de acceso para todos los empleados de una organización, se tiene un puesto con mucho poder. Comparado con los programadores, cuyo trabajo está muy controlado, la mayoría de las veces el responsable de autorizaciones no tiene que obedecer reglas ni acatar controles de cambio. Mientras que los programadores necesitan abrir solicitudes de cambio, liberar los cambios en el sistema de desarrollo y luego obtener la aprobación de sus responsables para el traslado a producción, los gerentes de autorización suelen hacer cambios en las autorizaciones directamente en el sistema de producción. Debido a esto, hay mucho peso sobre los hombros del responsable de autorizaciones para que no cometa errores.
Hay tres áreas comunes en las que opera el responsable de autorizaciones: la gestión del ciclo de vida de los usuarios (creación y eliminación de cuentas de usuario), los cambios en la asignación de funciones de autorización a los usuarios y los cambios en la propia estructura de las funciones de autorización. Esta última es la menos común, debido a que los cambios de funciones son la actividad más peligrosa y hay muchas posibilidades de causar serios problemas si no se hacen cuidadosamente. Es por esto por lo que los proyectos de reingeniería de funciones son tan raros. Además, cuando se llevan a cabo, la mayoría de las organizaciones utilizan herramientas como ProfileTailor Dynamics.
A fin de mantener las buenas prácticas como responsable de autorizaciones, deben definirse procedimientos que le ayuden a reducir el riesgo de cometer errores en el sistema de producción. He aquí algunos ejemplos:
En la gestión del ciclo de vida del usuario, NUNCA elimine una cuenta de usuario. Muchas organizaciones trasladan las cuentas de usuario que deberían eliminarse a un grupo de usuarios específico (por ejemplo, «DELETED_USERS»), eliminan o bloquean todas sus autorizaciones y luego las dejan estar. La mayoría de las veces, las organizaciones no eliminarán una cuenta de usuario. Al utilizar la función «delete» en el código T SU01, se elimina la cuenta de usuario de la tabla de usuarios incluyendo TODOS sus detalles, a diferencia de lo que ocurre en otras áreas de SAP. Una empresa siempre debe pensar en las posibles situaciones en las que esa información crítica puede ser útil. Por ejemplo, nunca se sabe cuándo se encontrará de repente un registro o una factura sospechosa creada por un usuario ya eliminado. En este caso, necesitaría acceder a los detalles específicos del usuario anterior.
Moraleja de la historia: ¡No elimine usuarios!
Otro consejo importante para la gestión del ciclo de vida de los usuarios atañe a la creación de cuentas de usuario: no las copie de otro usuario. Aunque es quizá la forma más fácil de crear cuentas de usuario, ya hemos discutido por qué es el peor método.
La clave para cambiar las funciones de autorización es «NUNCA cambies nada en el entorno de producción directamente». Primero se debe hacer el cambio en el sistema de desarrollo, probarlo en QA, y solo entonces, si funciona correctamente, llevarlo a producción. Esta es una buena práctica incluso si SAP no la aplica (pista: puede descargar una función del sistema de desarrollo y subirla directamente a producción). Recuerde esto siempre: usted está al mando; tiene poder para hacer cambios, pero también tiene la responsabilidad de prevenir cualquier posible error.
Por último, si utiliza una herramienta como «Role Splitter» para separar las funciones de autorización en función del uso real y evitar así la segregación de funciones, siempre debe encaminar el proceso para que las funciones se creen antes en un sistema de desarrollo. Aunque la herramienta es muy potente, sigue siendo muy arriesgado ejecutar una separación de funciones directamente en el entorno de producción. Como dijimos al principio, un gran poder conlleva una gran responsabilidad, y todo el peso está sobre sus hombros.
