Asignaciones Directas e Indirectas en SAP© HCM

Durante este artículo elaborado por Tamara Rivera, miembro de nuestro equipo de consultores especializados en seguridad SAP© y SAP© GRC, trataremos las restricciones a nivel de autorizaciones, para tener en cuenta en un sistema SAP© de Recursos Humanos (HCM: Human Capital Management).

Un sistema HCM contiene información muy sensible desde el punto de vista de protección de datos personales (existen normativas centradas solamente en asegurar el tratamiento de los datos personales como podría ser RGPD/GDPR). Por lo tanto, es importante entender que debemos centrarnos no solo en los permisos de edición sino también de visualización.

En relación con las Transacciones Custom, es importante analizarlas y confirmar si tienen todos los chequeos necesarios en base a la funcionalidad de la transacción, de cara a poder realizar las restricciones necesarias a nivel de autorizaciones, así como incluirlas en la matriz de riesgos en caso de que permitan ver o modificar información sensible y así tenerlas monitorizadas.

Centrándonos en las transacciones y chequeos estándar, tendríamos dos tipos de asignaciones de autorizaciones:

  • Asignación Directa: A través de roles, relacionando roles y usuarios.
  • Asignación Indirecta: A través de perfiles estructurales, relacionando los usuarios con la estructura organizacional de la compañía.

Asignación Directa

Este tipo de asignaciones es igual que en los entornos ECC, creamos los roles a través de la transacción PFCG y los asignamos a los usuarios desde la SU01.

A continuación, listaremos las principales restricciones comunes entre los entornos de HCM y ECC:

  • A nivel de Transacción: Clasificar las transacciones en roles, en base a funcionalidad y teniendo en cuenta la matriz de riesgos.
  • A nivel de Puestos de Trabajo: Definir los distintos puestos de trabajo de la compañía y clasificar a los usuarios en ellos de cara a definir roles compuestos que faciliten la gestión del modelo de roles.
  • A nivel de Tablas: Definir y limitar los accesos a modificar y visualizar tablas. Dado que un sistema de HCM hay cierta información muy sensible, es recomendable, en algunos casos, realizar restricción de las tablas no solo a través del objeto S_TABU_NAM sino también del S_TABU_LIN restringiendo columnas específicas, de cara a ocultar ciertos campos críticos de una tabla. (Mas detalle en el artículo técnico: “Objetos Restricción Tablas SAP©”).

Las principales restricciones a tener en cuenta de forma particular en un sistema HCM, bajando a nivel de objeto de autorización, serían las siguientes:

Datos Maestros HR (P_ORGIN)

Es el objeto de autorización más conocido en un sistema SAP© HCM. Este objeto chequea todos los accesos de infotipos de administración y gestión de tiempos, técnicamente hablando, todos los accesos a las tablas que comienzan con el prefijo PA.

Datos Maestros HR – Chequeo Ampliado (P_ORGXX)

El objeto P_ORGXX permite una gestión más amplia que el objeto P_ORIGIN. Se introduce un nuevo campo “SACHA” que permite hacer una restricción mas avanzada que no podríamos hacer a través de “P_ORIGIN”.

Datos Maestros HR – Chequeo Número de Personal (P_PERNR)

Es un objeto que se puede dar para gestionar los permisos de los infotipos de administración y tiempo de otros números de personal menos el del propio usuario. Por ejemplo, que pueda modificar todos los salarios menos el suyo. Campo PSIGN con letra “E” (Autorizaciones excluidas para el número de personal asignado).

Cluster HR (P_PCLX)

Los Clústeres son una forma de almacenamiento de datos complejos que estaba muy extendido en el SAP© HCM “clásico”. Los componentes más recientes del sistema HCM omiten cada vez más el almacenamiento de Clústeres y utilizan tablas en su lugar.

Registro de Gestión de personal (P_PCR)

El registro de control de personal (transacción PA03) es la herramienta de control central de las nóminas. Este objeto verifica los permisos de área de nómina y limita las actividades a visualización o cambio

Planificación de Personal (PLOG)

El nombre de este objeto es confuso, ya que no solamente aplica a esta área (planificación de Personal) sino, técnicamente hablando, a todas las tablas de bases de datos que comienzan con HRP.

Reporting HR (P_ABAP)

Este objeto nace para mejorar el rendimiento del sistema, en relación con los permisos de lectura de los objetos de autorización de datos maestros. Este objeto permite restringir o desactivar los chequeos de ciertos informes.

Candidatos HR (P_APPL)

El reclutamiento “clásico” ha sido reemplazado por los nuevos componentes “E-Recruiting”. Sin embargo, todavía está en uso y está sujeto a mantenimiento.

De los objetos comentados anteriormente el campo de autorizacion más importante sería el de Infotipo (INFTY). Para este campo es importante definir para cada usuario/puesto de trabajo tanto a los Infotipos que debería tener acceso de visualización como de modificación y crear los roles asociados. Se recomienda que estos sean “Enabler Roles” es decir roles que tienen objetos, pero no transacciones, y que funcionan en combinación con los roles que contienen las transacciones para generar el menor número de roles posibles, y que el modelo sea más manejable.

Otros campos importantes a los que prestar atención y que más comúnmente se restringen sería el Área de Personal (PERSA) y Administración de Nómina (SACHA).

Asignación Indirecta

Este tipo de asignaciones van totalmente relacionadas con la estructura organizacional de la empresa, dada de alta en la transacción PPOME. Mediante este tipo de asignación, podremos limitar que puedan ver o modificar los accesos asignados a través de roles (asignación directa comentada en el apartado anterior) solamente para ciertas áreas de la empresa, por ejemplo, para los usuarios de área de legal.

En este caso definiremos los perfiles estructurales a través de la transacción OOSP y los asignaremos a los usuarios a través de la OOSB. Es importante activar los perfiles estructurales a través de la transacción OOAC para que estos funcionen, de lo contrario por mucho que los diseñemos y los asignemos a los usuarios no funcionarán.

A través de esta transacción (OOAC) también podremos activar los objetos de contexto. Estos son objetos que finalizan con las letras CON, por ejemplo: P_ORGINCON y P_ORGXXCON, y que añaden un nuevo campo a los objetos originales (P_ORGIN y P_ORGXX). Este campo es el de Perfil de Autorización (PROFL):

Al activar estos objetos el sistema permite que no solo podamos asignarle a un usuario unas transacciones concretas, con una restricción a unos infotipos o áreas de personal específicos (a través de roles) para el departamento de la estructura organizacional al que pertenece (a través de perfiles estructurales), sino que combina estas dos restricciones para usuarios que puedan desempeñar una doble función, permitiendo indicar el perfil estructural definido en el nuevo campo PROFL y limitar unos accesos (infotipos, áreas de personal…) para un departamento/puesto de trabajo concreto y otros accesos concretos para otros departamentos/puestos de trabajo.

Por ejemplo, un usuario que pertenece al área de nóminas y tiene que poder realizar modificaciones en infotipos asociados a “Estado de Nómina”, pero es responsable de ciertas personas para las que necesita visualizar toda la información relacionada con “Ausencias”:

Puntos Clave

  • Realizar una buena definición inicial de las restricciones necesarias, tanto a nivel de Asignaciones Directas (Visualizar o Modificar: Transacciones, Tablas, Infotipos, Campos de Autorización…) como Indirectas (Perfiles estructurales).
  • Estructura Organizacional bien mantenida en la transacción PPOME. De cara a realizar una restricción correcta por perfiles estructurales.
  • Las tablas para revisar las autorizaciones relacionadas con perfiles estructurales son:
    • T77PR – Relación perfil estructural vs Accesos
    • T77UA – Relación perfil estructural vs Usuarios
  • En caso de querer utilizar perfiles estructurales o autorizaciones de contexto es importante acordarse de activarlas mediante la transacción OOAC.
  • Utilizar autorizaciones de contexto (objetos finalizados en CON) para poder realizar combinación de restricciones a nivel de roles (infotipos, áreas de personal, administración de nóminas…) y departamentos/puestos de trabajo definidos en la estructura organizacional.

Si este artículo te ha resultado útil o estás interesado en servicios de SAP HCM, no dudes en ponerte en contacto con nosotros haciendo clic aquí. Nuestro equipo de especialistas en seguridad SAP© y SAP© GRC está listo para ayudarte con soluciones personalizadas adaptadas a las necesidades de tu organización. 

¿Te ha gustado?

¡Compártelo en redes sociales!

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Rellena este campo
Rellena este campo
Por favor, introduce una dirección de correo electrónico válida.
Tienes que aprobar los términos para continuar

Categorías

Calendario de entradas

Nuestros servicios

keyboard_arrow_up