// // Escribe un comentario

Trace de Autorizaciones SAP

Trace de autorizaciones por medio de la transacción ST01: una muy buena herramienta para auditores y administradores de seguridad SAP.


Esta herramienta posee características que la hace ser una de las más importantes para auditar y obtener evidencia de accesos de los usuarios del sistema SAP:
  • Herramienta de fácil uso y es recomendable dominar el concepto de autorización para su utilización e interpretación adecuada (capa 1, 2 y 3 de seguridad de autorizaciones)
  • Herramienta que no merma el performance de la operación del ambiente en donde se tenga activada (no es invasiva). Este es el típico motivo por el cual se le bloquea el acceso a los auditores, perdiendo la oportunidad de obtener evidencia de muy buena calidad para la auditoría. Si el trace está activo solamente para la verificación de autorizaciones, no habría merma de performance. Eventualmente podríamos tener impacto, en la medida que activemos todas las opciones del trace (RFC, tablas, etc.)
  • Ocupa espacio en disco que se puede ir reciclando por medio de uso de dispositivos externos (discos de respaldo externos) y así no merma el espacio en disco. Esto se puede ir haciendo día a día, dado a la cantidad de información que almacena el trace y se recomienda dejarlo en 99MB de almacenamiento (máximo), a fin de que cada archivo genere la mayor cantidad de información posible.
  • Para un eficiente procesamiento y análisis de la evidencia, se recomienda trabajar el resultado del trace apoyado de un CAATs (técnicas de auditoría asistidas por computador) -ACL, ACCESS, EXCEL
  • Si estamos auditando el ambiente productivo, se debe activar en cada uno de los servidores que soportan productivo. Cabe mencionar, que esto aplica para cualquier ambiente y se activa en cada servidor de desarrollo, prueba, sandbox en la medida que nuestra necesidad sea auditar estos ambientes. Las instancias de servidores se pueden ver con la transacción SM51 y de esta forma administro los traces en un esquema multi-server.
  • La evidencia obtenida llega a nivel de capa 3 de seguridad de accesos (capa 1 S_TCODE, capa 2 TSTCA y capa 3 USOBT), por lo que la enriquece para evitar falsos positivos.
  • Para un modelo de prevención de delitos (Ley 20.393) y/o fraudes (procedimientos de detección de fraudes en el marco de las auditorías internas o externas) es muy recomendado, debido a la calidad de la evidencia.
  • Para el monitoreo del modelo de control interno de segregación funcional SoD-SOX Compliance, es muy recomendado, ya que nos permite obtener evidencia del monitoreo que hacen los dueños de procesos (process owners) o dueños de roles (role owners) en relación a los accesos bajo su responsabilidad.
  • Se puede complementar con los resultados de otras herramientas tales como: Ejecución histórica de transacciones ST03, STAD, SM04, SM20 log de auditoría con obtención de usuario, transacción y terminal (estas herramientas solamente llegan a nivel de capa 1 de seguridad, es decir, a nivel de transacción ejecutada por usuarios y no cubren los objetos de autorización. (Son susceptibles de levantar falsos positivos), pero complementado con el trace de autorizaciones se enriquece la evidencia.
  • Para complementar (y utilizar en auditorías o revisiones) no se olviden de las tablas (accedidas a través de la SE16): CDHDR (Change Documents - Header) y CDPOS (Change Documents - Positions)
    Ambas tablas almacenan información (logs) de las modificaciones realizadas por los usuarios (a nivel objeto o instancia de clases en documentos SAP)


Información enviada a través de LinkedIn, autores: Pedro Hernandez y Marco Antonio Cabrera Ovando. Me ha parecido invalorable el aporte de estos dos usuarios en LinkedIn, por eso lo re-transmito hacia el cyber-espacio. Si re-bloguean, recuerden tener en cuenta esta información.

Si desean complementar esta información sobre la ST01, les recomiendo los siguientes enlaces:
  • System Trace (Help.SAP; en ingles)
  • Authorization Trace in transaction ST01:
    Sometimes you may face a strange behavior in DMS functions which are caused by wrong authorization customizing or you do not know how and where authorization objects are checked by the system. So this page explains how an authorization trace is started in transaction ST01. This trace shows all checked authorization objects, the values which are handed over to the check and which object leads to the missing authorization behavior.
  • Code Gallery > Show ST01 authorization trace
Esto es todo por ahora.
Si tienen alguna duda, la comentan aquí. De ser necesario un nuevo artículo sobre sus dudas, se harán mas artículos, si no, se responde a través de comentarios.
Saludos!

0 comments:

Publicar un comentario

Nota Importante: los comentarios son para agradecer, comentar o sugerir cambios (o hacer preguntas) sobre el artículo de arriba.


Para otras preguntas, por favor envíe su consulta aquí, es gratis!. Su consulta no molesta, le responderemos a la brevedad