La seguridad de SAP es algo compleja, eso creo que ya lo dijimos, pero todas las cosas pueden ser complejas hasta que las entendemos. En este post vamos a tratar de lograr eso.
Algunos temas los empezamos a tratar en posts anteriores, pero no el proceso completo que pasamos a relatar.
1- El usuario ingresa en SAP R/3 y se le permite su acceso
2- Se cargan desde el maestro de usuarios los roles que el usuario posee (tabla AGR_USERS), a partir de los mismos se obtienen los perfiles que tienen las autorizaciones para esos roles (AGR_1016). Aunque es altamente probable que el sistema SAP directamente miré la tabla UST04 (usuarios y perfiles). En caso de perfiles compuestos estos se encuentran definidos en la tabla UST10C. A su vez la relación entre autorización y perfiles está en la UST10S, y por último los valores que se le otorgan a los objetos de autorización se encuentran en la tabla UST12 (probablemente SAP internamente utilice algunas otras tablas o no haga un uso de todas estas, pero es interesante repasarlo porque puede ser de utilidad para ustedes).
3- Esta información recopilada es almacenada en el buffer del usuario, el cual tiene para cada usuario todas las autorizaciones que el mismo posee cuando está logueado en el sistema, esta información puede consultarse para el propio usuario o para otro distinto mediante la transacción SU56 o si se necesita un mayor análisis en la tabla USRBF2 (y vínculos a la tabla UST12).
4- A partir de este momento el usuario ya tiene acceso al sistema y todos sus permisos están cargados. El sistema se encuentra a la espera de una acción por parte del mismo.
5- El usuario decide ejecutar una transacción, por ejemplo la FB02 (modificar documento contable).
6- SAP verifica SIEMPRE que el usuario en su buffer posea el permiso para la transacción. Para esto chequea que el objeto de autorización S_TCODE posea el campo TCD y entre sus valores se encuentre el FB02. Este chequeo no depende de la transacción si no que se ejecuta SIEMPRE que una es llamada.
7- Si se posee el valor FB02 se permite la ejecución del código de la transacción y se procede con el mismo, en caso negativo se rechaza automáticamente la solicitud informándole al usuario.
8- Dependiendo de la transacción a ejecutar, la misma puede chequear como primera instancia (antes de la ejecución del código) que se posea un objeto de autorización con un valor determinado para más de un campo. Este objeto, campos y valores se especifican en la definición de la misma a través de la transacción SE93 o la tabla TSTCA donde también pueden consultarse. Este chequeo actúa igual que el del código de transacción y se realiza previo a la ejecución del programa correspondiente a la transacción. En el caso de la transacción FB02 se chequea el objeto F_BKPF_BUK y la actividad (campo ACTVT) con valor 02 (modificación), el campo Sociedad (BUKRS) en esta instancia, no se verifica ya que el valor de chequeo está en blanco). Cabe destacar que no todas las transacciones realizan este chequeo inicial.
9- A partir de este momento se inicia la ejecución del código.
10- El código ABAP de la transacción se ejecuta hasta que dentro del mismo aparezca la instrucción AUTHORITY_CHECK.
11- A través de esta instrucción el programa verifica que los valores especificados para cada campo en la misma se encuentren en el buffer del usuario que la ejecuta. En caso de tenerlos se permite que se continúe la transacción y en caso de ausencia no se permite continuar o se bloquea el acceso a determinada información. Es a decisión del programador de la transacción en que momento se realiza el chequeo, a veces se verifica cuando uno ingresa un valor (por ejemplo la sociedad en la FB02) en donde se verifica el mismo objeto que antes F_BKPF_BUK, pero pidiendo la actividad 02 (modificar) y la sociedad para la cual va a realizarse la modificación (BUKRS).
NOTA 1: Tengamos que cuenta que los campos de un objeto de autorización siempre se verifican en conjunto, quiero decir que la actividad 02 (modificar) solo autoriza a la Sociedad que se encuentra dentro de la misma autorización. Podría ocurrir que dentro de un mismo rol tengamos permiso para modificar una Sociedad pero solo para Visualizar otra. Por eso es importante tener en cuenta que estas son verificadas “en bloque”
NOTA 2: También es importante destacar que es posible y hasta habitual que un usuario tenga más de un ROL asignado, en este caso se produce lo que se conoce como “suma de autorizaciones” y esto quiere decir que los valores solicitados de objetos de autorización pueden encontrarse en cualquiera de los roles que el usuario tiene asignado. Ejemplo: Si en el rol 1 el usuario tiene el acceso a la transacción FB02 (objeto S_TCODE), y en el objeto F_BKPF_BUK la actividad con valor 03 y la sociedad en 0001, pero el programa solicite 02 y 0001 el usuario no podría ingresar a la transacción. Ahora si agregamos un segundo rol al usuario sin ningún objeto S_TCODE pero con el objeto F_BKPF_BUK con valor de actividad 02 y sociedad 0001 el usuario ahora si va a poder tener acceso a ejecutar esta transacción (el primer rol le da el S_TCODE con FB02 y el segundo el F_BKPF_BUK con actividad 02)
Por último cabe destacar que la transacción FB02 necesita de otros objetos de autorización para ser ejecutada pero el nombrado aquí fue solo a modo de ejemplo. En un próximo post veremos un ejemplo completo.
Tags: AUTHORITY_CHECK, autorización, FB02, objeto de autorización, SAP, SE93, Seguridad, SU56, S_TCODE, Transacción
Un saludo, desde Colombia.
Este tipo de Blog son los que necesita la Internet.
Yo tambien tengo que ver con la seguridad de unas instalacion de SAP y la verdad me alegra mucho encontrar esta página.
Agregado a mi Feeds.
Gracias por tu comment!! Esperemos mantener el nivel! Saludos!
Excelente post! Muchas gracias!
hola, yo trabajo en el nivel de seguridad sap, mi deseo es aprender mucho mas del campo, se cosas muy basicas, donde puedo realizar un curso basico al menos de sap seguridad?
mcuhas gracias
Jacky,
Mirá todo depende el país en el que estés ubicada, pero SAP por ejemplo brinda en casi todos los paises su “Academia” donde se puede acceder a certificación en seguridad SAP. Esperemos el día de mañana desde este blog poder armar al menos un documento en PDF que pueda resultar útil para iniciarse en SAP.
Saludos
Hola !
Muy buena la pagina!
Me gustaria si se podria dar otro ejemplo o un poco mas de detalle sobre la suma de permisos.
Saludos!
Muy buena pagina. En estos momentos se implementará el SAP en nuestra empresa y necesito sprender sobre este producto. Muchas gracias
Hola! necesitaria saber si es posible que un usuario modifique solo un campo de un pedido de ventas.
Muchas Gracias!
Y la realidad es que habría que hacer un análisis puntual del caso. Pero en principio lo desestimo, porque los permisos por campos suelen estar disponibles solo para datos maestros. Te recomiendo ver a través de la SU24 cuales son los objetos de autorización vinculados con la transacción que querés restringir, y después consultar el help de esos objetos en la transacción SU02 para ver si permiten o restringen autorizaciones con algo vinculado a ese objeto. Otra alternativa es analizarlo mediante un trace de seguridad con la tx ST01. Pero no puedo darte una respuesta certera a la distancia.
Saludos!
Cualquier duda, preguntanos!
Hola a todos muy buen post!!!
quisiera hacerles una consulta tengo que documentar los roles del sistema, y debido a la cantidad de estos quisiera saber si alguna forma de obtener esta info Rol- Transaccion(es) – objeto (os) – Valor (es). muchas gracias de ante mano
Me fue de muchas ayuda a entender este inmenso mundo que es sap la verdad muy agradecidos y sigan asi saludos
Estimados : primero que nada quisiera felicitarlos por el sitio que tienen, es una ayuda muy importante. Les comento lo siguiente, trabajo en la empresa Twobox Consultores, nos dedicamos a la capacitación de los diferentes módulos de SAP y dentro de nuestras áreas es la auditoria de sap, para lo cual desarrollamos un software que permite obtener las tablas desde sap procesarlas para emitir reportes de transacciones críticas, sensible e incompatibles por usuario, perfiles, roles. Además tiene la funcionalidad de realizar simulaciones.
Nos gustaria tener un asercamiento ºcomercial con ustedes para ver la venta de este software en Argentina u otro pais latinoamericano.
Para mayor información favor visitar e sitio http://www.twobox.cl
saludos,,
Fernando Cortés Letelier
Excelente BLOG, mi mas grandes felicitaciones. Un gran aporte el MUNDO SAP!
Muy útil la información.
Una consulta, que sucedería si usando la FB02 se solicita para acceder:
F_BKPF_BUK con Actividad 02 y Sociedad 005
Y el usuario tiene:
Rol 1: FB02 y F_BKPF_BUK con Actividad 02 y Sociedad 001
Rol 2: FB02 y F_BKPF_BUK con Actividad 03 y Sociedad 005
Podría entonces obtener el acceso si las autorizaciones necesarias las tiene pero “cruzadas” a través de los dos roles?
Saludos.
1) Alberto:
Según el ejemplo que das, Estos dos roles no le estarían dando la autorización ya que SAP va a verificar en conjunto la actividad y la sociedad. Es decir que el usuario va a poder visualizar sociedades 005 y va a poder modificar sociedades 001. De otra forma va a dar error.
2) Felix:
Para obtener los valores “Rol- Transaccion(es) – objeto (os) – Valor (es)” vas a tener que hacer las bajadas de las tablas AGR_1251 y AGR_1252 desde la transacción SE16. La primera tabla te va a dar todos los roles y sus respectivos objetos y valores. (Los que tienen el campo TCD son las transacciones)
En la segunda tabla vas a ver los valores de los niveles organizacionales que en la otra tabla te aparecen, pero sin el valor. Como por ejemplo el campo KOKRS en la tabla AGR_1251 va a aparecer con el valor: $KOKRS
saludos rosi me urge hablar contigo
Hola gente, muy buena pagina, la cual me supo dar una manito para entender en su momento a que llamaban roles, perfiles, objetos de seg, etc…los molesto para consultarlos…en la empresa donde trabajo, la parte seguridad de SAP solo la veo a nivel de roles/perfiles y análisis de logs de auditoria para ver si existen desvíos…dado que solo contaba con MM y SD …dos consultas en realidad 1)Están por instalar con una consultora el modulo de HR y me piden de que manera puedo asegurar que, por ejemplo, la gente que administra la BD e incluso yo mismo como basis, no acceda a visualizar datos sensibles como ser la nomina de sueldos…que se hace en ese caso, se encripta la BD (esta sobre un sqlserver2005), o se puede restringir el acceso desde SAP….ideas? y 2) el tema vulnerabilidades en SAP, mas allá, en mi caso, de las paginas que publica Microsoft sobre parches, etc…desde SAP no existe una pagina o site que informe a medida que surjan vulnerabilidades, las implicancias y posibles soluciones que puedan tener?…como escalar a nivel Seg y poder ‘garantizar’ que el entorno es seguro?…, por la ayuda con la que pueda contar, les doy las gracias de antemano. Saludos!