Tomando decisiones con las cuentas de usuarios no activas

Cuando una cuenta de usuario SAP deja de ser utilizada, se pueden tomar dos decisiones: eliminarla del sistema o mantenerla en estado no vigente.

En los casos que un usuario deja la empresa, muchas veces su cuenta de usuario se mantiene en el sistema por necesidad de trazabilidad de sus acciones. Para dejarlo en estado no vigente, algunos administradores bloquean la cuenta y otros, dejan la fecha de término de su vigencia con la fecha de su retiro, ambas.  Es posible que incluso mantengan las autorizaciones asignadas para el evento en que sea necesario habilitar la cuenta, para lo cual sólo bastará con desbloquear y/o modificar la fecha de expiración de ésta.

Mi sugerencia es eliminar las cuentas de usuario no activos por retiro de la empresa. La historia de sus pasos en el sistema, quedará registrada en los documentos que hubiere creado(1) como también en el log de transacciones usadas.  Y… no olvidar verificar que la cuenta no esté asignada a algún job o proceso batch…

Con el apoyo de un software como CentinelBox podrá mantener la historia de sus roles asignados como también de su uso.

Si la decisión es mantener las cuentas de usuarios, se recomienda bloquearlos, fijar la fecha de expiración y retirar los roles asignados.  Manejar sólo la variable de bloqueo, tiene un riesgo por las acciones de bloqueo / desbloqueo masivo podrían activar erróneamente cuentas que deberían mantenerse bloqueados

Si la cuenta debe ser reactivada, los privilegios a ser asignados deberán ser evaluados previamente de acuerdo a las funciones que desempeñará, su posición y otras variables relevantes.

(1) Próximamente publicaré un método simple para identificar el usuario que ha creado un documento.

Identificar transacciones Z sin authority check

Siempre ha sido un problema identificar las transacciones cliente (custom transactions) que no tienen definición de authority check.

La soluciones más usadas son dos: revisar en forma manual cada una de las transacciones Z / Y y así detectar en qué condiciones se encuentra cada una de éstas. La segunda forma es contar con una aplicación que accese los programas y busque las palabras claves de definición de authority check y en caso de encontrarlas, genere un reporte con éstas.

Una forma alternativa, más simple pero no 100% segura, que permite un acercamiento a la solución del problema, es la siguiente: para cada transacción Z / Y  que ha sido usada - lo que permite descartar el análisis de transacciones que no se usan -  buscar en las tablas USOBT_C y USOBX_C si existen objetos de autorización declarados con la transacción SU24. Si efectivamente existen, es altamente probable que tales transacciones tengan efectivamente authority checks definidos.

Por qué no es 100% seguro este procedimiento?
Sólo por consecuencia de malas prácticas en el desarrollo y en su control de calidad:

1. Es posible que se hayan definido authority checks en una transacción Z / Y, sin embargo nunca se registraron con la transacción SU24. Recordemos que la SU24 registra los objetos de autorización que serán propuestos al crear un rol con la PFCG. Si es el caso, cada vez que se asigna una de estas transacciones a un rol, los objetos deben ser creados en forma manual. 

2. Una transacción Z / Y no tiene authority checks definidos pero, maliciosamente, se han creado los objetos en la SU24. Al asignar la transacción en un rol, se solicitan los valores de cada objeto. Sin embargo, la aplicación nunca los verificará.

Independiente de lo anterior, el método es mejor que navegar por cientos de transacciones, algunas obsoletas, otras que no se usan, etc.

Y, si la información la puedo obtener a un click... nada mejor !

Se han incorporado a la última versión de CentinelBox, dos reportes que aplican en método señalado:

• Análisis de las transacciones cliente asignadas a algún rol 
• Análisis de las transacciones cliente que han sido usadas

Qué pasa con esta información y los dos puntos antes mencionados?

• Para el primer caso, una transacción que esté en esta condición, se detectará de inmediato en la revisión y sólo faltará actualizar con la SU24.
• Para el segundo caso, se sugiere realizar una revisión al azar de un porcentaje - por ejemplo el 10% - del total de las transacciones con información en la SU24 y en caso de detectar esta condición se puede ampliar la muestra de revisión.

De esta forma nuestros reportes estarán con un nivel de certeza muy cercano al 100%.