Configuración y evaluación de los parámetros de kernel del SAP Security Audit Log (SAL)

Para la auditoría de un sistema SAP, el Security Audit Log (SAL) es una de las fuentes más importantes. Con EHP 7 cambió la forma de configurarlo: además de los parámetros de perfil hay parámetros de kernel, que se aplican a todo el sistema y tienen prioridad. Quien no lo sabe audita en el lugar equivocado.

Por qué el Security Audit Log cuenta para la auditoría

Un sistema ERP está sujeto a requisitos legales sobre la exactitud de los datos y la trazabilidad de los cambios. De ahí se derivan en la práctica un entorno de sistemas con al menos desarrollo y producción y la segregación de funciones entre TI y áreas de negocio. Son especialmente críticos los accesos que anulan deliberadamente esa segregación, como las intervenciones de usuarios de emergencia.

Justo ahí entra el Security Audit Log: registra eventos relevantes para la seguridad por usuario en un área protegida, con independencia de los documentos de modificación de la aplicación. En la auditoría interna y en la auditoría de cuentas anuales es, por tanto, una fuente central de evidencia. Para que la evidencia se sostenga, el registro debe ser completo, permanente y estar configurado igual en todas las instancias.

Configuración hasta EHP 6: parámetros de perfil y SM19

Hasta EHP 6, el Security Audit Log se configura en la transacción SM19, en dos variantes:

• Configuración estática: los ajustes se guardan como parámetros de perfil o de instancia en la base de datos y están activos tras cada arranque del sistema. Para la operación permanente hace falta una configuración estática activa. Los filtros determinan qué usuarios o grupos de usuarios se registran; cuántos filtros son posibles depende de la release.
• Configuración dinámica: el registro puede activarse y ajustarse en funcionamiento, sin reinicio. Solo el número de filtros paralelos está fijado.

Se configuran, entre otras cosas, los mandantes a registrar, las clases de auditoría (por ejemplo inicio de sesión de diálogo o inicio de sesión RFC), la categoría de eventos (todos, críticos, graves) y el tamaño y la ubicación de los archivos de auditoría. Los parámetros de perfil más importantes son rsau/enable (registro activado o no), rsau/selection_slots (número de filtros), rsau/user_selection (filtro de usuarios) y rsau/max_diskspace/local (espacio en disco).

En la auditoría suele comprobarse en la transacción RZ10 si estos parámetros cumplen los requisitos regulatorios, las directrices de la empresa o las recomendaciones habituales. Como complemento, la tabla PAHI muestra si se han modificado parámetros a corto plazo, por ejemplo justo antes de la auditoría.

A partir de EHP 7: parámetros de kernel en SM19

Con EHP 7 se añadió en SM19 la pestaña «Parámetros de kernel». A través de ella, el Security Audit Log se activa y configura para todo el sistema, de forma parecida a como las políticas de seguridad para contraseñas (SECPOL) se aplican a todo el sistema. Tres cosas son decisivas:

1. Los parámetros de kernel anulan los parámetros de perfil. En cuanto están definidos, los conocidos parámetros de perfil rsau/* no tienen efecto. Quien quiera seguir trabajando con parámetros de perfil debe desactivar los parámetros de kernel.
2. El mantenimiento ya no se hace en RZ10, sino directamente en el Security Audit Log. En RZ10 puede figurar, por tanto, un valor que no se aplica.
3. Los valores se guardan en la tabla RSAUPROF. Para ello, el sistema crea perfiles con el nombre $KERNEL$; cada slot representa un parámetro. El slot 0006, por ejemplo, decide si se escriben varios archivos de auditoría al día.

Al activar aparece una pregunta de seguridad. Si se responde negativamente, los servidores de aplicación no quedan configurados de forma homogénea.

Qué significa esto para la auditoría

Una auditoría que solo lee los parámetros de perfil puede inducir a error a partir de EHP 7: un registro aparentemente desactivado mediante rsau/enable = 0 puede estar perfectamente activo por los parámetros de kernel, y a la inversa, un parámetro de perfil definido no dice nada sobre lo que realmente se registra. También el historial de cambios está en otro lugar: los cambios en los parámetros de kernel no figuran en PAHI, sino que se escriben mediante el registro de tablas (rec/client) para RSAUPROF.

Para la auditoría esto significa:

• Leer los dos sitios: los parámetros de perfil en RZ10 y la pestaña «Parámetros de kernel» en SM19.
• Determinar qué se aplica: si hay parámetros de kernel activos, cuentan ellos, no los parámetros de perfil.
• Evaluar el historial: con el informe RSTBHIST (por ejemplo a través de SA38) para la tabla RSAUPROF, buscando los perfiles $KERNEL$. PAHI por sí sola no basta.
• Comprobar la coherencia: con parámetros de kernel, el ajuste se aplica a todo el sistema; con parámetros de perfil sigue siendo necesaria la comparación entre todas las instancias.

Valoración

Desde el punto de vista de compliance, la novedad es un avance. Los parámetros de kernel se aplican a todo el sistema tras el reinicio; desaparece el riesgo de que la distribución a servidores de aplicación individuales falle y el registro falte allí. El auditor ya no tiene que comprobar la coherencia de cada instancia por separado.

Dos cosas siguen siendo insatisfactorias. Según la release, hay que comprobar dos sitios, parámetros de perfil y SM19. Y la tabla RSAUPROF estaba pensada para los filtros; con los perfiles $KERNEL$ se desvía de su finalidad, y la estructura heterogénea hace la evaluación más engorrosa de lo que debería ser.

Nota: en releases más recientes (a partir de SAP NetWeaver 7.50 con Support Package 03, es decir, también en S/4HANA), las transacciones RSAU_CONFIG, RSAU_READ_LOG y RSAU_ADMIN sustituyen a SM19, SM20 y SM18. La distinción entre parámetros de perfil y de kernel y el almacenamiento en RSAUPROF se mantienen.

Una versión más detallada de este artículo, en alemán y con capturas de pantalla, se publicó en el blog de expertos rz10.de: Kernel-Parameter für das SAP Security Audit Log (SAL): Vorsicht vor Inkonsistenzen.