✒️SAP El modelo de seguridad
SAP El modelo de seguridad
Lección 7. El modelo de seguridad en SAP
En cualquier sistema de gestión de informática integrado se guardan datos de diferentes áreas a los que solo pueden acceder algunas personas. Estas restricciones pueden darse por varios motivos:
SAP contempla toda esta problemática implementando un modelo de seguridad que permite proteger de una manera flexible los datos y las operaciones que se hacen sobre ellos.
El esquema está basado en los siguientes componentes:
Vemos la estructura modular que va desde el usuario que accede al sistema SAP hasta el campo particular que se quiere proteger.
Usuarios
Para que un empelado de la empresa tenga acceso a los datos de gestión, debe disponer de un código de usuario en SAP. Este usuario tendrá asignados los roles y perfiles necesarios para poder realizar las tareas que exige su función o puesto de trabajo.
En SAP existen 5 tipos de ususarios:
De diálogo: con los cuales acceden normalmente los usuarios finales que necesitan interactuar con el sistema a traves del SAP GUI. Todos los parametros de logueo definidos son verificados al iniciar la sesion como asi tambien las restricciones de login multiples. Normalmente la mayoria de los usuarios de nuestra empresa deberian estar encuadrados dentro de este tipo de usuarios.
De sistema: son usuarios no interactivos, lo que significa que no pueden loguearse a traves del SAP GUI al sistema. Comunmente son utilizados como usuarios de procesamiento por lote, workflow, procesos alle, etc. Su contraseña solo puede ser cambiada por el administrador del sistema y se permiten logueos multilpes.
De comunicacion: son usados para comunicacion RFC entre sistemas. Comunmente utilizados para las interfases con otros sistemas SAP. No es posible establecer logueos por parte de los usuarios finales a traves del SAP GUI.
De servicio: usado por parte de los usuarios que requieren acceso anonimo, no respetan las normas de expiracin de contraseñas y las mismas solo pueden ser cambiadas por el administrador del sistema. Las autorizaciones que se le otorgan a este tipo de usuarios deben ser minimas y restringidas especificamente a la necesidad por la cual se creo este tipo de usuario. Podemos decir que el uso de un usuario de servicio no es recomendable ya que puden loguearse mediante el SAP GUI.
De referencia: este usuario es muy poco usado en general, no admite Logon de dialogo y puedens er utilizados para traspasar sus autorizaciones al usuario que lo tiene como referente.
Roles
Un rol es el nombre que se le confiere al conjunto de perfiles que le son asignados al usuario para el ejercicio de sus funciones.
Un rol puede ser asignado a varios usuarios. Los usuarios pueden tener más de un rol, esto es útil para algunas actividades como la impresión que serán permitidas para la mayoría de los usuarios.
Los cambios a un rol, por lo tanto, tienen efecto sobre todos los usuarios.
La transacción para el mantenimiento de los roles es la PFCG. Esta transacción es usada únicamente por los encargados de mantener la seguridad del sistema SAP, que pueden ser los administradores del sistema SAP o un grupo separado de estos que se encarga exclusivamente de la seguridad del sistema.
Si accedemos a la transacción SU01 y vemos los datos de nuestro usuario de SAP, vamos a ver los roles asignados en la pestaña roles.
Tal como vemos en la imagen anterior, en el ambiente de desarrollo existe el rol Z_SAP_ALL_SIN_TRX_BASIS_DU3 el cual es asignado a todos los usuarios del sistema de desarrollo y brinda acceso a todas las funcionalidades del sistema, con excepción de las transacciones propias de la administración del sistema y de la seguridad.
Existen 3 tipos de roles:
Los roles simples;
Los roles compuestos: compuestos basiacmente por un conjunto de roles simples. S eunen varios roles simples para mejorar la organizacion de los mismos con un objetivo concreto. Por ejemlpo, crear un rol compuesto para el administrador de la nomina que va a tener el perfil simple de la administracion del personal y el rol simple de administracion de nomina.
Los roles derivados: suele hablarse de padres e hijos es decir, roles que heredan de otros roles.
Perfiles
Son la descripción detallada de las posibles acciones que puede realizar un usuario en el sistema.
Por cada rol puede existir uno o más perfiles creados automáticamente por el sistema SAP que van a ser los que efectivamente activas las autorizaciones.
Los perfiles también pueden crearse manualmente y asignarse a un usuario o se pueden usar los perfiles preexistentes.
Existen perfiles que vienen en la instalación del sistema SAP que pueden ser asignados a los usuarios finales y que muchas veces contienen autorizaciones sumamente amplias, como es el caso del perfil SAP_ALL que contiene todas las autorizaciones del sistema.
Asignar a un usuario el perfil SAP_ALL constituye un riesgo muy grande en la seguridad del sistema SAP. Si un usuario posee este perfil, tiene el control total del sistema, situación que el cliente en muchas ocasiones tiende a minimizar. Para mantener los perfiles, los encargados de seguridad de SAP usan la transacción estándar RZ10.
Si accedemos a la transacción SU01 y vemos los datos de nuestro usuario SAP, vamos a ver los perfiles asignados en la pestaña perfiles.
Tal como vemos en la imagen anterior, en el ambiente de desarrollo, para el usuario SAP i0604226, se encuentran asignados entre otros perfiles T-D39300731, T-D3900731, T-D393007311, los cuales forman parte del rol Z_SAP_ALL_SIN_TRX_BASIS_DU3.
Autorizaciones
Consisten en una asignación de valores a los campos de un objeto de autorización. Cada autorización incorpora permisos para un elemento del sistema.
Por ejemplo, crearemos una autorización para el objeto S_TCODE que tenga el valor FB01 (Transacción correspondiente a la contabilización de documentos) para el campo TCODE.
En la siguiente imagen vemos que para el rol Z_SAP_ALL_SIN_TRX_BASIS_DU3 existen definidas un conjunto amplio de autorizaciones:
Objetos de autorización
Son objetos que se usan para validar la autorización de un usuario del sistema a acceder a una determinada transacción, dato, tarea o funcionalidad.
Existen objetos de autorización estándar del sistema SAP y también se pueden crear objetos de autorización Z a través de la transacción SU21.
Los objetos de autorización representan lo que queremos proteger y se componen de campos
Cada uno de estos objetos de autorización es el elemento mínimo que nos permite proporcionar permiso para ejecutar una tarea determinada.
Esta tarea puede ser el acceso a una transacción, a un grupo de transacciones, aun área de ventas, a un grupo de compras, a una planta, a un almacén, entre muchas otras alternativas.
Cada tarea a la cual tiene acceso un usuario se encuentra definida de un campo de autorización. Este campo se encuentra en un objeto de autorización y este a su vez en un rol.
Todas las tareas (transacciones o elementos de la estructura organizativa), a las que tiene acceso un usuario es porque el permiso para tener acceso a esta parte del sistema está definido en los objetos de autorización que forman uno o más roles de los tiene asignado este usuario.
Los siguientes son algunos ejemplos de autorización:
S_TCODE: protege el código de transacción y contiene un solo campo que es la transacción. Es el más importante de todos los objetos porque todas las operaciones que se hacen en SAO empiezan por el acceso a una transacción.
S_TABU_DIS: protege el contenido de tablas de customizing. Contiene dos campos que son el grupo de autorizaciones de la tabla (DICBERCLS) a la que se quiere acceder y la actividad (ACTVT) que se quiere ejecutar (crear, modificar, borrar).
F_BKPF_BUK: protege la contabilización de documentos por sociedad financiera. Se compone de dos campos, la sociedad (BUKRS) a cuyos documentos contables queremos acceder y la actividad (ACTVT) que se quiere hacer.
Finalmente, los objetos de autorización son usados en los programas ABAP, entre otros objetos, para validar el acceso a las funcionalidades.
Basicamente la seguridad a nivel campos en SAP, se logra a traves de los objetos de autprizacion, los cuales permiten a los usuarios del sistema ejecutar funcionalidades con determinados valores en los campos de las pantallas. En caso de introducirse un valor no permitido para un campo, el cual se valida a traves de un objeto de autorizacion, el sistema va a emitir un mensaje de error por pantlla y no va a permitir continuar con el procesamietno.
 
 
 
Sobre el autor
Publicación académica de Ornella Mollani Norverto, en su ámbito de estudios para el Carrera Consultor Basis NetWeaver.
Ornella Mollani Norverto
Profesión: Ingeniera Química - Argentina - Legajo: MA29J
✒️Autor de: 38 Publicaciones Académicas
🎓Egresado del módulo:
Disponibilidad Laboral: FullTime
Presentación:
Soy ing. química (utn-frc, argentina). quisiera formar parte de una empresa dónde poder crecer en el ámbito it, integrando con mis conocimientos ingenieriles y mis aptitudes de liderazgo e innovación.
Certificación Académica de Ornella Mollani