Seguridad de los datos en SAP – una introducción

La seguridad de los datos en SAP es un campo bastante amplio, pero te lo iremos desglosando de forma sencilla para que tengas toda la información necesaria. 

Sistema de gestión de la seguridad de los datos en SAP

Este sistema consta de tres macroáreas:

• La seguridad de la aplicación (es decir, el propio sistema de gestión). Es la forma en que se gestionan los usuarios y sus funciones de autorización para evitar el acceso no autorizado a los datos.
• La seguridad de las infraestructuras. Se refiere a la forma en que se almacenan los datos (por ejemplo, si están encriptados o no) y se transmiten (utilizando métodos criptográficos).
• La seguridad de los programas desarrollados. Se trata de la forma en que se escriben los programas “ad hoc” (es decir, específicos de la empresa) en ABAP. De hecho, estos programas pueden introducir vulnerabilidades en el sistema.

Veámoslos con más detalle.

¿Para que se realiza la seguridad de los datos en SAP?

La gestión de la seguridad de los datos en el sistema de gestión es necesaria para proteger los datos sensibles, como los datos del personal (salarios y otra información personal), las listas de materiales de nuestros productos o las listas de proveedores y clientes.

Son necesarias varias acciones: desde la formación del personal (que debe saber qué comportamientos ponen en riesgo los datos, como por ejemplo compartir sus contraseñas) hasta la gestión inteligente de los usuarios.

En otras palabras, el sistema debe desarrollarse teniendo en cuenta el “ciclo de vida” del personal, desde el momento en que es contratado hasta el momento en que deja la empresa, incluyendo cualquier cambio en las tareas que debe realizar.

Es una buena práctica establecer varios roles de trabajo (“job roles” o “business roles”) que cubran las distintas actividades de los empleados.

La idea es que un empleado tenga o no acceso a determinados tipos de datos en función de su función en la empresa: por ejemplo, es natural que alguien que trabaje en el departamento de personal (Recursos Humanos) pueda ver las condiciones contractuales de los distintos empleados. Sin embargo, la misma persona no debería poder acceder a la información sobre clientes, contratos pendientes, documentación de ingeniería, etc.

Estos roles no deben ser diseñados para ajustarse al perfil de una persona específica, sino que deben ser lo más genéricos posible y, si es necesario, evolucionar con la empresa.

El número de roles debe limitarse al máximo, tratando de evitar el solapamiento entre roles similares. Por ejemplo, para una empresa de 1.000 personas puede tener sentido trabajar con unos 100 roles diferentes.

Es importante definir estos roles teniendo en cuenta la segregación de funciones (concepto llamado en inglés Separation of duties o Segregation of Duties – “SoD”).

Se trata de la idea de que las tareas críticas para la vida de la empresa (como la gestión de las compras o la contratación de nuevo personal) deben ser gestionadas por varias personas para limitar el riesgo de robo, sabotaje, fraude o incluso de simples errores.

Por ejemplo, en SAP un pedido de compra (Purchase Order) es solicitado por un manager que gestiona un centro de costes. A menudo esta orden de compra tiene que ser aprobada por el superior directo de la persona que hace la solicitud, y posteriormente por el departamento de Compras. Esta es una buena práctica que reduce el riesgo de que se realicen compras no autorizadas en nombre de la empresa.

En este artículo encontrará más información sobre Autorizaciones y Roles en SAP.

En cuanto a la seguridad de la infraestructura, algunos elementos clave son el uso de protocolos seguros para el transporte de datos (SSL) con el uso de claves públicas y privadas para la gestión de certificados. La base de datos HANA también permite encriptar los datos del disco – y si es necesario también los registros (log) y las copias de seguridad (backups).

También es importante mencionar la posibilidad de proteger los datos con técnicas de enmascaramiento (“Masking”) o codificación (“Scrambling“).

En el caso del enmascaramiento, la información no se modifica en la base de datos, pero se anonimiza (“enmascara”) cuando se presenta al usuario final. En este caso, los datos de la base de datos no se tocan (y siguen siendo visibles para los usuarios con los permisos necesarios). Los usuarios sin los permisos necesarios verían entonces datos ficticios, preservando la confidencialidad de la información. SAP ofrece un producto específico para conseguirlo: Field Masking for SAP GUI.

En cambio, el Scrambling modifica los datos directamente en la base de datos. Obviamente, no podremos utilizar esta solución en sistemas de producción, pero podría interesarnos trabajar en copias del sistema para el desarrollo o el control de calidad. Una posible aplicación de esta técnica sería, por ejemplo, el caso en el que externalizamos el desarrollo de aplicaciones específicas para nuestra empresa y tenemos que compartir la base de datos con desarrolladores externos. Si no queremos compartir los datos reales, podríamos compartir con ellos datos ” mezclados ” e irreconocibles.

En cuanto a la seguridad de los programas desarrollados en ABAP, SAP ofrece varios métodos para comprobar la seguridad del software desarrollado interna o externamente; por ejemplo, el ABAP Test Cockpit, una herramienta diseñada para comprobar la calidad del código que verifica, por ejemplo, la sintaxis, la seguridad y el cumplimiento de las convenciones de denominación.

Otra solución es el “Code Vulnerability Analyzer” (SAP CVA), un complemento de SAP NetWeaver que busca riesgos potenciales, como nombres de usuario hardcoded (datos codificados directamente en el código fuente del programa) o situaciones que puedan provocar una “inyección SQL”, una técnica que permite insertar código SQL, por ejemplo, para alterar elementos de la base de datos o descargar información.