Auditoría de seguridad SAP

SAP concentra los procesos financieros, de compras y de recursos humanos más críticos de tu empresa. Un rol mal diseñado, una interfaz RFC expuesta o una nota de seguridad sin aplicar pueden dar a un atacante —interno o externo— control sobre transacciones que mueven dinero real. Auditamos tu entorno SAP con la misma mentalidad de quien quiere comprometerlo, no solo revisando una checklist de cumplimiento.

¿Tu SAP es seguro o solo cumple la checklist de auditoría interna?

La mayoría de las revisiones de seguridad SAP se quedan en el terreno del cumplimiento: comprobar que existe una matriz de segregación de funciones (SoD) documentada, que hay una política de contraseñas o que el sistema está dentro de mantenimiento. Eso no confirma que el entorno resista un ataque real. Los compromisos de SAP suelen explotar combinaciones concretas: una cuenta de servicio con la contraseña por defecto, una interfaz RFC accesible sin control de acceso, código ABAP a medida con una inyección, o notas de seguridad (SAP Security Notes) publicadas hace meses y nunca aplicadas. Una auditoría ofensiva confirma qué de todo eso es explotable de verdad en tu instancia concreta.

Qué cubre la auditoría de seguridad SAP

  • Autorizaciones y perfiles: roles críticos, combinaciones de segregación de funciones (SoD) y principio de mínimo privilegio
  • Cuentas por defecto y de servicio (SAP*, DDIC, SAPCPIC, EARLYWATCH) y su política de contraseñas
  • Seguridad de la interfaz RFC y del Gateway: listas de control de acceso (secinfo/reginfo), gw/sim_mode y conexiones RFC de confianza
  • Gestión de parches: aplicación de SAP Security Notes frente al calendario mensual de SAP Security Patch Day
  • Código ABAP personalizado: inyección SQL/OS, cross-site scripting en Web Dynpro/BSP y malas prácticas de desarrollo a medida
  • Exposición de servicios Fiori, OData y Message Server a redes no confiables o a Internet
  • Seguridad de la base de datos HANA cuando forma parte del alcance
  • Security Audit Log: qué se registra, retención y capacidad real de detección de un incidente

Cómo ejecutamos la auditoría

  1. Alcance y acceso: Definimos el alcance (módulos, mandantes, entorno productivo o de pre-producción) y obtenemos acceso de auditoría o una cuenta de prueba. Acordamos qué pruebas activas se permiten y en qué ventana.
  2. Revisión de configuración y autorizaciones: Analizamos roles, perfiles y combinaciones de SoD, cuentas por defecto, parámetros del Gateway y el estado real de aplicación de SAP Security Notes.
  3. Análisis de superficie de ataque: Enumeramos interfaces RFC expuestas, servicios Fiori/OData accesibles, conexiones de confianza entre sistemas y código ABAP personalizado de mayor riesgo.
  4. Simulación ofensiva controlada: Reproducimos técnicas reales (abuso de RFC, escalada vía roles mal diseñados, explotación de vulnerabilidades conocidas sin parchear) en el entorno acordado para confirmar el impacto real.
  5. Informe y remediación: Documentamos cada hallazgo con evidencias, criticidad (CVSS) e impacto de negocio, y entregamos un plan de remediación priorizado para el equipo Basis/SAP.

Qué recibes al finalizar

  • Informe ejecutivo: nivel de riesgo del entorno SAP, para dirección y CISO
  • Informe técnico: hallazgos con evidencias, CVSS y pasos de remediación para el equipo Basis
  • Mapa de roles y combinaciones de SoD críticas con su nivel de riesgo
  • Checklist de hardening priorizado (autorizaciones, Gateway, parcheo)
  • Reunión de cierre con el equipo Basis o de administración SAP
  • Re-test opcional para verificar que los hallazgos críticos se han corregido

¿Cuándo conviene auditar tu entorno SAP?

  • Tu empresa tiene SAP en producción y nunca ha hecho una auditoría de seguridad ofensiva, solo revisiones de cumplimiento
  • Antes o después de una migración a S/4HANA o de una ampliación relevante de módulos
  • Tras un incidente o sospecha de fraude interno en procesos financieros o de compras
  • Cuando un cliente, auditor externo o inversor exige acreditar la seguridad del ERP
  • Para cumplir con NIS2, ENS o ISO 27001 en los sistemas que soportan procesos críticos de negocio
  • Si tenéis desarrollos ABAP a medida que nunca han pasado una revisión de seguridad de código

Preguntas frecuentes sobre la auditoría de seguridad SAP

¿Es lo mismo que una revisión de segregación de funciones (SoD) para auditoría interna?

No. Una revisión de SoD para auditoría interna o compliance confirma que existe una matriz documentada y que, sobre el papel, no hay combinaciones prohibidas asignadas. Nuestra auditoría va más allá: confirma qué de eso es explotable de verdad, añade el análisis de la interfaz RFC/Gateway, el código ABAP personalizado y el estado de parcheo, y simula el impacto real de un atacante, no solo el riesgo teórico documentado.

¿Necesitáis acceso al sistema productivo?

Para la revisión de configuración y autorizaciones basta con un usuario de solo consulta o acceso al sistema de pre-producción con la misma configuración. Para las pruebas ofensivas activas acordamos previamente el alcance, el entorno (habitualmente pre-producción) y, si procede, una cuenta de prueba. Todo se realiza con autorización explícita y bajo acuerdo de confidencialidad (NDA).

¿Cubrís tanto SAP on-premise como S/4HANA Cloud?

Sí, adaptando el alcance: en on-premise y S/4HANA Private Cloud el análisis incluye la capa de infraestructura, el Gateway y el sistema operativo subyacente; en S/4HANA Public Cloud el alcance se centra en autorizaciones, integraciones y configuración, ya que SAP gestiona directamente parte de la infraestructura.

¿La auditoría interrumpe la operativa del ERP?

No. La mayor parte del trabajo es análisis de configuración, roles y código, que no afecta a los usuarios. Las pruebas activas se acuerdan previamente, se ejecutan preferentemente en un entorno de pre-producción y, si deben tocar producción, en una ventana pactada con el equipo Basis.

¿El informe sirve para cumplimiento normativo (NIS2, ENS, ISO 27001)?

Sí. El informe documenta el estado de seguridad del entorno SAP con evidencias y es válido como parte de la documentación de adecuación a NIS2, certificación ISO 27001 o adecuación al Esquema Nacional de Seguridad (ENS) para los sistemas dentro de su alcance.