Uno de los temas más conflictivos que podemos encontrarnos al tratar de implementar, ajustar, o auditar la seguridad de un sistema SAP es precisamente el acceso a las tablas de datos.
Cómo ya bien contamos en algún artículo previo, SAP a diferencia de otros sistemas, posee a través de su misma interfaz la posibilidad de interactuar con el sistema operativo, las bases de datos, e incluso el acceso directo a los datos en ella almacenada. Por este motivo es que se habla de acceso a tablas en SAP, la información allí almacenada puede ser visualizada y editada dependiendo de algunas condiciones.
Desde determinadas transacciones puede accederse a la visualización y manutención de los datos. Especificamente, en principio hablamos de las transacciones SE16, SE16N, SM16* (todas las variantes), SE17, SM30, SM30* (todas las variantes), SM31, SM31_OLD.
A través de las mismas es posible la modificación o visualización (depende del código de la transacción y los permisos que tengamos) de las tablas, sin pasar por validaciones de integridad referencial o de otro tipo.
Justamente este es el principal problema. Las organizaciones entre muchas de las cualidades que ven en un ERP como SAP es el trabajar con datos con múltiples validaciones, un fuerte control interno, y númerosas verificaciones de integridad intrínsecas del aplicativo. Modificando los datos directamente se pierde la confianza en todas estas características porque los controles no aplican en las mismas.
Este concepto, es el mismo criterio que tiene una auditoría sobre los Controles Generales y los Controles de Aplicación. Primero se debe confiar en los controles generales (evitar fallas en el acceso físico a equipos, al sistema operativo, al servidor de bases de datos, y un largo etc, y luego si se puede empezar a descansar sobre los controles de aplicación, que son los de más alto nivel dentro de las aplicaciones (lógica de negocio o control interno). Si el control interno de la aplicación es una maravilla, pero el acceso a modificar la base de datos es libre la aplicación pierde el sentido para el que fue creada.
Volviendo a temas más técnicos de SAP, estas transacciones además del control por el objeto de autorización S_TCODE correspondiente (a esta altura ya debiéramos saber que todas lo tienen), poseen básicamente 3 objetos de autorización que controlan su comportamiento.
Estos son:
S_TABU_CLI: A través de este objeto se permite la modificación de las tablas independientes de mandante (Ver este link si se desconoce este concepto). Posee un solo campo pudiendo tomar el valor vacio o “X”, siendo este último el que permite la modificación de este tipo especial de tablas. Es requerido para determinadas tareas de customizing y para permitir las modificaciones o nuevos programas en un ambiente de desarrollo.
S_TABU_DIS: Es el objeto que determina si se posee permiso para modificar una tabla determinada. Tiene dos campos uno es el ya conocido Actividad (ACTVT) con las posibilidades 02 (modificar), 03 (visualizar datos) y BD (distribución de customizing), y el otro es DICBERCLS o Grupo de Autorización. Este último campo permite determinar un grupo para ser asignado a tablas (1 o más) el cual puede crearse editando las tablas TBRG y la tabla TDDAT o mediante la transacción SE54 (preferentemente). Las tablas que no poseen un grupo asignado automáticamente adoptan el grupo &NC&, a su vez otro grupo predefinido por ejemplo son las tablas de sistema SS.
S_TABU_LIN: Es propio de las últimas versiones de SAP, su utilización se activa en el customizing (SPRO – SAP NetWeaver – Servidor de Aplicación – Gestión del Sistemas – Usuarios y Autorizaciones – Autorizaciones Referentes a Línea) y permite que los datos sean filtrados por campos determinados. Permitiendo, por ejemplo, que solo pueda visualizarse la información perteneciente al país Argentina (un campos definido en la tbla) cuando se consulta una tabla específica. El bojeto tiene 10 campos (8 criterios posibles), otro de actividad (02 modificar y 03 visualizar) y otro que define el criterio organizacional. Es importante detallar que la definición de númerosas autorizaciones por línea tienen un impacto para nada despreciable en la performance general de las consultas. Un documento detallando la configuración puede verse aquí en idioma inglés.
Resumiendo, resulta de suma importancia restringir el acceso a tablas, en principio la modificación de las mismas directamente solo debiera permitirse como una excepción y como tal no debería ser un permiso estándar incluido en un rol.
En el caso de ser necesario para modificar tablas Z o algunas muy específicas necesidades funcionales siempre debiera otorgarse la modificación de grupos de autorización lo suficientemente acotados para que sepamos cuales son todas las tablas incluidas en los mismos.
A su vez hay que tener sumo cuidado en otorgar el permiso amplio de visualización de tablas (S_TABU_DIS, Actividad 03, Grupo *) ya que se estaría poniendo a disposición del usuario toda la información transaccional de la empresa, la cual muchas veces estaríamos cuidando con restricciones físicas en “el mundo real” pero dejando a libre disposición en los sistemas.
En algún próximo post estaremos tratando la creación de variantes de transacción para la SM30 y SM16, con le fin de restringir la visualización o modificación a una sola tabla.
