Conceptos de usuarios de emergencia SAP: ¿hay que asignar SAP_ALL?
¿Roles de emergencia diferenciados o simplemente SAP_ALL? El escalonamiento sitúa el control en el lugar equivocado. Lo decisivo: emergencias raras y cada intervención revisada sin lagunas.
Este artículo trata del diseño de las autorizaciones dentro de los conceptos de usuarios de emergencia SAP. En concreto: ¿hay que asignar el perfil SAP_ALL, o son los roles de usuario de emergencia diferenciados el mejor camino?
Por qué los auditores de cuentas miran más de cerca
El tema de los usuarios de emergencia ha llegado a las empresas medianas. Los auditores de cuentas dan cada vez más importancia a un diseño técnico de las intervenciones que resista la auditoría, sobre todo con vistas a una información financiera íntegra y trazable. La razón es evidente: las intervenciones directas en el sistema productivo con autorizaciones amplias infringen la segregación de funciones entre TI y proceso de negocio y el principio de asignación mínima de derechos (need-to-know), aunque sea solo por poco tiempo.
Qué forma parte de un concepto de usuarios de emergencia
Para Maxim Chuprunov, un manejo conforme de los usuarios de emergencia empieza por un concepto documentado y aplicado. Según su exposición, incluye:
- un acceso restringido a las credenciales, sin acceso compartido (shared access),
- condiciones previamente definidas para una intervención,
- un proceso de aprobación y notificación,
- un registro sin lagunas de las intervenciones y
- una evaluación periódica de los registros. [1]
Hasta aquí hay acuerdo. Los caminos se separan en la cuestión de qué autorizaciones recibe el usuario de emergencia.
Roles diferenciados: el deseo evidente
Chuprunov considera deseable una restricción técnica de las autorizaciones de usuario de emergencia según distintos escenarios de intervención y grupos de usuarios. Este deseo lo oímos también una y otra vez de nuestros clientes: un rol para contabilidad financiera, uno para logística, uno para Basis, uno para desarrolladores con derechos de visualización.
La idea es comprensible. Pero tiene un precio: junto al concepto de autorizaciones propiamente dicho surge un segundo que hay que mantener, revisar y documentar, y que en la propia emergencia puede convertirse en un obstáculo cuando el rol a medida no es suficiente justo en ese momento.
Nuestra posición: pocas emergencias, autorización completa, revisión completa
Sostenemos que las intervenciones de usuarios de emergencia deben limitarse a emergencias reales. Un número elevado de intervenciones indica, según nuestra experiencia, deficiencias en los procesos e integraciones de sistemas subyacentes, y esas deberían corregirse con prontitud y prioridad, en lugar de hacer más cómodos los usuarios de emergencia.
Si el número de emergencias se mantiene bajo, no vemos necesidad de autorizaciones de emergencia escalonadas. Vemos más bien el peligro de que por esta vía se establezca un concepto de autorizaciones en la sombra. Nuestra solución ISPICIO_E asigna, por tanto, simplemente SAP_ALL.
La integridad de los datos y la trazabilidad de las intervenciones las garantiza en otro lugar: mediante una revisión obligatoria de todas las actividades en el Security Audit Log. Justo después de cada intervención, el registro individual se asigna a un revisor para que lo comente y decida: aprobar o rechazar. Todas las intervenciones quedan así, junto con la justificación (por ejemplo la referencia a un ticket), el archivo de registro y el resultado de la revisión, en una base de datos que puede evaluarse cómodamente en la auditoría.
Conclusión
La pregunta «¿SAP_ALL o no?» es, a nuestro juicio, la pregunta equivocada. Lo decisivo es con qué poca frecuencia se necesita el usuario de emergencia y con qué exhaustividad se revisa cada intervención. Quien tiene ambas cosas bajo control puede conceder la autorización completa en la emergencia, y el auditor obtiene lo que quiere ver: cada intervención, cada justificación, cada resultado.
[1] Cf. Chuprunov, Maxim: Handbuch SAP-Revision. Internes Kontrollsystem und GRC. Rheinwerk, Bonn 2012, págs. 242 y s. (en alemán).