Según la propia SAP, el 77% de los ingresos por transacciones del mundo pasa por un sistema SAP (comunicado oficial de la compañía). Piénsalo un segundo: finanzas, compras, inventarios, nómina y ventas de miles de empresas corriendo sobre la misma plataforma. Por eso el Pentesting en SAP no es un pentest más: es una prueba sobre el activo digital más concentrado de la organización, el que un atacante elegiría primero si pudiera elegir.
En este artículo te explicamos qué hace vulnerable a un paisaje SAP, qué piezas se evalúan en una prueba de penetración seria, qué normativa te toca según tu caso y qué escenarios encontramos en la práctica. Sin humo: con el criterio de quien ha evaluado estos entornos.
Tabla de Contenido
Por qué un SAP mal asegurado es el objetivo perfecto
Un ERP no es una aplicación cualquiera. En SAP conviven la contabilidad, las órdenes de compra, los datos de proveedores, la nómina completa y los precios con los que compites. Un atacante que consigue acceso privilegiado no necesita cifrar nada para hacer daño: le basta con alterar un pago, leer salarios o extraer la base de clientes.
Y hay un agravante estructural: SAP concentra usuarios con privilegios amplios, integraciones con decenas de sistemas y años de configuraciones acumuladas por equipos que ya no están en la empresa. Cada módulo que se añadió sin revisar autorizaciones, cada usuario «temporal» con permisos de más, cada servicio que quedó expuesto «mientras se hacían pruebas» es una puerta. El pentesting en SAP existe para recorrer esas puertas antes que otro.
La superficie de ataque de un paisaje SAP, pieza por pieza
Un paisaje SAP típico no es un solo sistema: es un conjunto de componentes que hay que evaluar por separado y en conjunto. Esto es lo que un pentest serio recorre:
Módulos de negocio: FI/CO, MM, SD y HCM
Finanzas y controlling (FI/CO), gestión de materiales y compras (MM), ventas y distribución (SD) y capital humano (HCM) concentran los datos más sensibles: asientos contables, condiciones con proveedores, precios y la nómina completa. Aquí la pregunta no es solo técnica —»¿se puede entrar?»— sino de autorizaciones: ¿quién puede ver y modificar qué?
Roles, autorizaciones y segregación de funciones
El punto débil más rentable de auditar. La segregación de funciones exige que los pasos críticos de un proceso los ejecuten personas distintas; cuando un mismo rol permite crear un proveedor, aprobar su pago y contabilizarlo, tienes un circuito de fraude servido. En nuestra experiencia, los roles con SAP_ALL o SAP_NEW «temporales» en productivo son de lo más común que encontramos, y de lo más peligroso.
Basis: el suelo sobre el que todo corre
El kernel, los perfiles de instancia, los parámetros del sistema y la gestión de usuarios a nivel de plataforma. Un Basis mal endurecido convierte cualquier vulnerabilidad de aplicación en compromiso total del sistema operativo.
SAP Gateway, RFC y servicios expuestos
Las llamadas a función remota (RFC) conectan tu SAP con otros sistemas: filiales, proveedores, aplicaciones satélite. Una RFC con confianza excesiva o credenciales débiles es un puente directo hacia el corazón del ERP. Lo mismo aplica a los servicios HTTP/ICM y a las aplicaciones Fiori accesibles desde internet: cada puerta web es una superficie que hay que probar como la probaría un atacante externo.
El parcheo: el Security Patch Day no es opcional
SAP publica notas de seguridad el segundo martes de cada mes —el Security Patch Day— y las clasifica por severidad, con las HotNews reservadas para lo crítico. El problema es que aplicarlas en productivo requiere ventanas de mantenimiento que muchas empresas posponen. El caso que lo demuestra todo: la vulnerabilidad CVE-2020-6287, conocida como RECON, permitía a un atacante sin autenticación crear un usuario administrador en SAP NetWeaver AS Java; recibió la puntuación máxima CVSS 10.0 y terminó en el catálogo de vulnerabilidades explotadas de CISA. Un pentest te dice cuántas de esas notas lleva tu paisaje sin aplicar y qué tan expuesto estás por ello.
SAP en las organizaciones de la región: infraestructura crítica del negocio
SAP es uno de los sistemas de gestión empresarial más extendidos en las grandes organizaciones de Colombia y Latinoamérica. En muchas empresas de la región, los procesos críticos del negocio operan sobre SAP: la gestión financiera y contable, la logística y la cadena de suministro, las compras y proveedores, y la administración de recursos humanos. Es decir, el corazón operativo de la organización pasa por una sola plataforma.
Esto convierte a SAP en infraestructura crítica para esas compañías: una interrupción, una alteración de datos o un acceso indebido a este sistema puede detener operaciones, distorsionar la información financiera o comprometer datos sensibles de empleados, clientes y socios. A diferencia de un sistema periférico, las fallas de seguridad en SAP tienen consecuencias transversales, porque el ERP concentra en un mismo lugar la información que sostiene la toma de decisiones.
En organizaciones con estructuras complejas —múltiples sedes, filiales, plantas o centros de distribución— la superficie de exposición crece: más usuarios, más roles, más integraciones con otros sistemas y más datos en movimiento. Por eso el pentesting en SAP no es un ejercicio aislado sobre una aplicación, sino una evaluación sobre el activo digital más concentrado de la empresa.
Qué cubre un pentesting en SAP bien hecho
Un pentest en SAP serio no es pasarle un escáner al servidor. Esto es lo mínimo que debería incluir:
Revisión de autorizaciones y segregación de funciones: análisis de roles, usuarios con privilegios excesivos y combinaciones tóxicas de autorizaciones que permiten fraude.
Exposición de servicios: qué RFC, servicios web, Fiori y puertos están accesibles, desde dónde y con qué autenticación.
Nivel de parcheo: comparativa del nivel de tus sistemas contra las notas de seguridad publicadas, priorizando HotNews y notas altas sin aplicar.
Endurecimiento de Basis: parámetros inseguros, usuarios estándar con contraseñas por defecto, configuración de la capa de plataforma.
Evidencia para auditoría: cada hallazgo con severidad, pasos de reproducción y recomendación de remediación concreta, más un retest para verificar el cierre. En DragonJAR los retests son ilimitados: probamos hasta que cada brecha quede cerrada de verdad.
Riesgos de ciberseguridad frecuentes en entornos SAP
Los entornos SAP enfrentan un conjunto de riesgos que conviene tener en cuenta. Los accesos no autorizados a datos sensibles del negocio son una preocupación central: dado que el sistema concentra información financiera, de personal y de operaciones, una credencial comprometida o un permiso mal configurado puede exponer mucho más que un solo módulo.
Las fallas en la segregación de funciones son otro riesgo recurrente: cuando los roles y autorizaciones permiten que un mismo usuario ejecute pasos críticos que deberían estar divididos entre varias personas, se abren espacios para el fraude interno y para errores con impacto operativo. Este riesgo crece en organizaciones que han ido ampliando sus equipos y sus módulos sin revisar periódicamente el esquema de autorizaciones.
Además, la exposición de módulos críticos —ya sea por integraciones con otros sistemas, por servicios conectados a internet o por configuraciones que quedaron habilitadas sin necesidad— amplía la superficie de ataque del ERP. Ninguna de estas amenazas es exclusiva de un país o sector, pero su impacto es proporcional al rol que SAP juega en la organización: cuanto más central es el sistema, más grave es una brecha.
La normativa que toca a un SAP
Dependiendo de tu empresa, sobre tu SAP pueden pesar varias obligaciones. Ninguna dice «haz un pentest en SAP» con esas palabras, pero todas exigen controles que un pentest demuestra en la práctica:
SOX (Sarbanes-Oxley): si tu casa matriz cotiza en bolsa en Estados Unidos, la ley exige controles internos sobre la información financiera. Tu SAP produce esa información: un pentest sobre FI/CO es evidencia directa de que esos controles existen y funcionan.
PCI DSS: si tu SAP toca datos de tarjetas de pago —directamente o a través de integraciones—, el estándar exige pruebas de penetración periódicas y tras cambios significativos. Es uno de los pocos marcos que sí pide pentests por su nombre.
Ley 1581 de 2012 (Colombia): tu HCM guarda datos personales de todos los empleados y tu MM/SD, de proveedores y clientes. La ley exige medidas de seguridad apropiadas, vigiladas por la Superintendencia de Industria y Comercio.
Ley 1273 de 2009 (Colombia): tipificó como delitos el acceso abusivo a sistemas informáticos y la interceptación de datos. Proteger el ERP también es reducir tu exposición legal.
Escenarios que encontramos en la práctica
Sin nombres, porque la confidencialidad no se negocia, pero con la sustancia intacta. Estos son patrones que vemos repetirse en paisajes SAP de la región:
El usuario con SAP_ALL «temporal» en productivo desde hace tres años, creado para una migración que ya terminó. Las RFC con confianza total entre el sistema productivo y el de desarrollo, donde un consultor externo tiene acceso amplio. Una aplicación Fiori accesible desde internet con autenticación básica y usuarios genéricos compartidos. Notas de seguridad críticas sin aplicar durante más de un año porque «el próximo trimestre hay ventana». Ninguno de estos escenarios requiere un atacante sofisticado: requieren que nadie haya mirado.
Si alguno te suena familiar, no es casualidad: son los hallazgos más comunes precisamente porque son los controles que menos se revisan.
Evalúa tu paisaje SAP con DragonJAR
Si tu empresa opera sus procesos críticos sobre SAP —finanzas, logística, recursos humanos o toda la operación—, el momento de evaluar ese entorno es ahora. Al llenar el formulario nos describes tu paisaje (versión, módulos, número de sistemas) y te respondemos con una propuesta de alcance ajustada a tu realidad, sin compromiso.
DragonJAR: comunidad de seguridad desde 2001, empresa operando desde 2012. Informes accionables sin falsos positivos, enfocados en el valor para tu negocio, con retests ilimitados hasta cerrar cada brecha. Conoce el portafolio completo de servicios de seguridad informática.
Preguntas frecuentes sobre el pentesting en SAP
¿La prueba se hace sobre el sistema productivo o sobre un ambiente de pruebas?
Depende del objetivo. Las revisiones de configuración, autorizaciones y parcheo pueden hacerse sobre copias o ambientes de QA sin riesgo. Las pruebas de exposición externa (Fiori, servicios web) suelen probarse tal cual están, porque es así como las ve un atacante. El alcance se acuerda por escrito antes de empezar, sistema por sistema.
¿El pentest obliga a detener la operación?
No. Un pentest en SAP trabaja con reglas de compromiso: ventanas acordadas, técnicas no disruptivas en productivo y reporte en caliente de cualquier hallazgo crítico. Si una prueba requiere condiciones especiales, se planifica aparte.
¿Cuánto dura una evaluación en SAP?
Depende del tamaño del paisaje: número de sistemas, módulos en alcance y si incluye revisión de autorizaciones. Un entorno mediano típico toma de dos a cuatro semanas entre ejecución, informe y retest. Desconfía de quien te prometa un «pentest SAP completo» en dos días.
¿Qué accesos necesitan de nuestro lado?
Para la revisión de autorizaciones y configuración se trabaja con un usuario de lectura y los accesos que tu equipo Basis defina; para las pruebas externas no se necesita nada más que las URLs públicas. Todo queda documentado en las reglas de compromiso.
¿Cubre tanto ECC como S/4HANA?
Sí. La metodología se adapta a la versión: los componentes cambian (por ejemplo, la superficie Fiori pesa más en S/4HANA), pero los focos —autorizaciones, exposición, parcheo, Basis— son los mismos. Lo importante es declarar la versión en el alcance.
¿El informe sirve para una auditoría o para cumplir PCI DSS?
Sí: el informe documenta metodología, alcance, hallazgos con evidencia y remediación verificada en el retest, que es lo que un auditor necesita ver. Para PCI DSS, asegúrate de que el alcance cubra el entorno de datos de tarjetas completo, no solo el SAP.
¿Cada cuánto conviene repetirlo?
Tras cambios relevantes —migraciones, nuevos módulos, integraciones nuevas— y de forma periódica. Además, el Security Patch Day es mensual: si tu proceso de aplicación de notas se retrasa, una revisión periódica te dice exactamente dónde estás parado.
Conclusión
El pentesting en SAP no es un gasto en seguridad más: es la revisión del sistema donde tu empresa guarda lo más valioso que tiene —su dinero, sus datos y su operación—. Un ERP que concentra el 77% de las transacciones del mundo en manos de sus clientes merece el mismo rigor que le exiges a tu contabilidad.
Empieza por lo básico: revisa quién tiene SAP_ALL en productivo, cuántas notas HotNews llevan sin aplicar y qué servicios están expuestos. Si no tienes esas respuestas, ya tienes el alcance de tu primera prueba.