A diferencia de los entornos ERP tradicionales, donde el acceso directo y en caliente a la base de datos era una práctica poco frecuente y altamente restringida, la evolución hacia una arquitectura S/4HANA ha incrementado este tipo de acceso para, entre otras tareas, explotar su capacidad analítica en tiempo real. Si bien esto abre un mundo de posibilidades para la explotación de datos, también amplia el alcance y el nivel de detalle al que deben de bajar los equipos de supervisión.
Durante este artículo se tratarán los puntos clave y las buenas prácticas que buscan controlar y mitigar los principales riesgos de seguridad en las bases de datos SAP HANA, principalmente la integridad, disponibilidad y confidencialidad de los datos.
A continuación, se detallan las validaciones de seguridad más relevantes en esta capa, qué podemos esperar de ellas y qué recomendaciones se pueden seguir para bastionar el entorno de control.
El Esquema Principal: El Núcleo del Sistema
En el centro de la base de datos se encuentra el llamado “esquema principal”, cuyo nombre técnico por defecto es SAPHANADB para sistemas RISE o SAPABAP1 para los “on premise”. Su importancia reside en su contenido: toda la información transaccional y de negocio del sistema, además de las tablas principales de parametrización técnica y funcional.
Esto implica que, la modificación directa sobre este esquema sea una de las amenazas más críticas para la integridad tanto de los datos como del sistema. Además, en caso de ser detectadas estas prácticas por parte del proveedor SAP, pueden llevar a la pérdida del soporte técnico por contrato.
Para este control, se facilita un ejemplo con los puntos claves:
| Riesgo | Alto (Impacto alto, Probabilidad media) |
| Detalle | Modificación directa de tablas estándar del esquema principal de la base de datos HANA. |
| Amenaza | La modificación directa de tablas estándar puede provocar corrupción de datos, inconsistencias lógicas y la pérdida del soporte oficial de SAP. Este tipo de acciones eluden todas las capas de control de la aplicación, como validaciones, lógica de negocio, trazas de auditoría y verificaciones de autorización. |
| Entornos | PRD, QAS, DEV |
| Consejos | Tratar el esquema principal como un sistema de solo lectura para cualquier acceso que no provenga de la propia aplicación SAP. Utilizar exclusivamente las BAPIs, módulos de función(capa de aplicación) o APIs (capa de BBDDs) proporcionadas por SAP para cualquier interacción con los datos. |
Como punto relevante destacar que la escritura en el esquema principal debe ser exclusiva del usuario de aplicación, es decir, la cuenta que utiliza el sistema SAP desde la capa de aplicación para guardar cambios en la capa de BBDDs. Ningún otro usuario debería realizar este tipo de cambios, ni se deberían de realizar accesos de tipo diálogo a dicho usuario. (En el caso de RISE ya no es posible por restricción de la propia infraestructura).
Permisos del sistema: Usuarios genéricos y Privilegios Críticos
En cuanto a los accesos y permisos a la base de datos deben ser gestionados bajo el principio del mínimo privilegio, diferenciando claramente los siguientes tipos de usuarios:
- Usuarios de consulta: Son cuentas con permisos de visualización destinados al consumo de datos en tiempo real. Esta información es procesada posteriormente en otros sistemas satélites para cuadros de mando o reporting.
- Usuarios Administradores: Son las cuentas con mayores privilegios y, por tanto, con mayor riesgo potencial asociado.
- Usuario estándar (SYSTEM & _SYS_REPO): Son los usuarios más poderosos de la base de datos. La buena práctica, recomendada por SAP, es utilizarlos únicamente para la configuración inicial (crear los primeros usuarios administradores con los privilegios mínimos necesarios) y posteriormente desactivarlos. Solo deben reactivarse de forma temporal para tareas de emergencia, y esto implica que deben contar con controles que velen por que estas cuentas no sean activadas ni utilizadas sin autorización.
- Usuarios locales: Tras la configuración inicial, se generan estos usuarios locales de BBDDs, necesarios para el mantenimiento. Estos no deben tener acceso de escritura sobre el esquema principal, y además debe estar controlado que empleados tienen acceso a ellos junto con una validación periódica de esta lista de superusuarios.
Por otro lado, al igual que en la capa de aplicación, existe una serie de permisos críticos que, en entornos productivos, no deben ser asignados salvo en casos excepcionales donde deberá ser la mínima. Los más críticos son:
- DATA ADMIN: Autoriza la ejecución de todos los comandos de definición de datos (DDL), permitiendo modificar la estructura de la base de datos.
- AUDIT ADMIN: Permite a los usuarios administrar y gestionar las configuraciones de auditoría dentro de la base de datos.
- USER ADMIN & ROLE ADMIN: Permite a los usuarios gestionar los usuarios y roles de la base de datos, habilitando a una potencial escalada de privilegios.
La Traza de Auditoría
La traza de auditoría es clave para la detección de incidentes y el cumplimiento de los controles. Esta debe ser configurada de forma proactiva, ya que no viene activada por defecto con la política completa disponible, y por ello se recomienda al menos que registre lo siguiente:
- Comandos de gestión de usuarios y roles (CREATE/DROP USER/ROLE).
- Comandos de cambios en privilegios y/o autorizaciones (GRANT/REVOKE).
- Cambios en la propia configuración de la auditoría que puedan haber manipulado su integridad.
- Accesos fallidos a los usuarios, con el objetivo de detección de ataques por fuerza bruta.
- Cambios en la configuración del sistema.
Respecto al almacenamiento de estos logs, se recomienda hacerlo en una ubicación externa, convirtiéndolos en inaccesibles e inalterables incluso para un administrador de la base de datos. También el integrar estos logs con el SIEM (Security Information and Event Management) corporativo de la compañía es una práctica muy extendida.
Supervisión
Es indispensable contar con procesos de supervisión y de revisión periódica tanto de usuarios, de su actividad y de los permisos con los que cuentan:
- Revisión Periódica de Privilegios: Revisiones trimestrales o semestrales de todos los usuarios de la base de datos HANA, prestando especial atención a aquellos con privilegios del sistema.
- Monitorización de la Traza de Auditoría: Establecer un proceso, preferiblemente automático, para analizar los logs en busca de actividades anómalas. La integración de los logs de HANA con la herramienta SIEM es habitual y facilita esta labor.
- Gobernanza del Acceso: Definir un proceso formal de solicitud, aprobación y revocación de acceso a la base de datos, documentando la justificación de negocio para cada petición.
Puntos Clave
- La modificación directa de tablas estándar del esquema principal de HANA conlleva un riesgo grave de integridad y la posible pérdida del soporte de SAP.
- La tarea de escritura en el esquema principal debe ser exclusiva del usuario de aplicación.
- La gestión de usuarios privilegiados debe ser extremadamente restrictiva, comenzando por la desactivación de los usuarios estándar y la limitación de privilegios críticos en los administradores locales.
- La habilitación y correcta configuración de la traza de auditoría, junto con su integración con el SIEM corporativo, otorga un sistema de control robusto.
- Es clave la definición de un proceso de revisión periódica de accesos y usuarios, junto con una monitorización activa de los logs de auditoría.