El entorno SAP es un componente crítico del entorno de TI de una organización. Sin embargo, la seguridad de la infraestructura no puede tratarse de forma aislada.

Se extiende más allá de la propia aplicación SAP para abarcar todo el ecosistema: instalaciones físicas, sistemas operativos, capas de virtualización, redes y marcos de monitoreo. A medida que el panorama se expande para incluir modelos híbridos y de nube, la seguridad de la infraestructura se convierte en una responsabilidad compartida entre el proveedor de servicios de nube, SAP, y la empresa que ejecuta SAP en nubes públicas y privadas.

En una empresa con un entorno SAP híbrido, la responsabilidad del propietario por la seguridad de la infraestructura cambia. Para un sistema local, la empresa que ejecuta SAP posee y opera todo, y para el componente de nube, en su mayoría asumen la responsabilidad. El proveedor de servicios en la nube y el proveedor de software (SAP en este caso) tienen la mayor parte de la responsabilidad de seguridad de infraestructura. Para la parte local, todavía desarrollan políticas, pautas y procesos de seguridad; adquirir sistemas de seguridad según sea necesario, implementar el diseño; operar los sistemas; monitorearlos; e implementar esquemas de mejora continua.

Para contrarrestar los exploits avanzados utilizados por los malos actores, las organizaciones han comenzado a adoptar medidas como arquitecturas de confianza cero, parches automatizados y monitoreo continuo con SIEM para reducir la exposición al riesgo y proteger su infraestructura de TI.

El proceso de protección de un entorno SAP local comienza mucho antes de que se creen los ID de usuario, se creen y asignen roles a los usuarios o se configuren las aplicaciones. El primer paso de ese proceso de desarrollo de seguridad es la planificación: planificar una infraestructura segura significa definir y proteger los componentes centrales del panorama de SAP: servidores, dispositivos de red, protocolos de red, sistemas operativos y los controles que gobiernan sus interacciones.

Una arquitectura segura debe diseñarse para estar libre de vulnerabilidades arquitectónicas. Los entornos SAP actualmente están altamente integrados. Cada sistema debe ser seguro y los mecanismos para integrarlos, las interfaces y la red deben serlo. Se deben adoptar medidas de seguridad como el cifrado para proteger los datos en movimiento. Los procesos de negocio deben diseñarse no sólo desde una perspectiva de eficiencia, sino también teniendo en cuenta la seguridad, reduciendo el riesgo para el negocio.

¿Cuál es su responsabilidad respecto del componente basado en la nube de su entorno SAP? La seguridad en la nube es una responsabilidad conjunta entre la empresa, el proveedor de servicios en la nube y el proveedor de software (SAP en este caso). La siguiente tabla presenta un cuadro RASCI de esta responsabilidad compartida para diversas tareas; las letras en RASCI tienen los siguientes significados:

• R: Responsable. La parte que asume la responsabilidad.
• R: Responsable. La parte que responde de la responsabilidad.
• S: soporte. La parte que respalda la actividad realizada como parte de la responsabilidad.
• C: Consultado. La parte que proporciona la experiencia para completar la actividad.
• Yo: informado. La parte que es informada sobre la actividad realizada como parte de la responsabilidad.

cuando usas SAP S/4HANA en la nube pública, es un modelo de software como servicio (SaaS), por lo que SAP es propietario de la infraestructura y la plataforma. SAP es responsable de gestionar la infraestructura y su seguridad. Por tanto, la seguridad de la infraestructura es propiedad mayoritaria de SAP. Sin embargo, la empresa cliente sigue siendo responsable. Si los auditores encuentran alguna excepción durante su auditoría, constituirá un hallazgo válido contra su organización. Para evitar este escenario, puede confiar en los informes de controles de organización y sistema (SOC).

Los informes SOC se utilizan ampliamente cuando una organización subcontrata sus servicios de TI y, por lo tanto, también se utilizan comúnmente para los servicios en la nube. Una empresa proveedora de servicios proporciona informes SOC a la empresa que consume sus servicios. Los informes SOC son informes de auditoría que certifican qué tan bien una empresa proveedora de servicios gestiona la protección de sus datos, la seguridad y los controles internos.

Existen diferentes tipos de informes SOC.

• SOC1: Este informe se centra en los controles de los informes financieros. Se utiliza cuando un servicio afecta los estados financieros de un cliente. Los ejemplos incluyen empresas que brindan soporte diario a SAP o soporte de software de nómina.
• SOC2: Este informe se centra principalmente en la seguridad, la disponibilidad, la integridad del procesamiento y la privacidad. Es el informe más común para servicios en la nube.
• SOC3: Este informe es similar al informe SOC2, pero a un nivel alto; no entra en detalles como lo hace SOC2 y es público.

Estos informes están disponibles en dos formatos:

• Tipo I: Este formato evalúa si los controles están correctamente diseñados en un momento dado para que sean efectivos.
• Tipo II: Esta es una versión más completa del informe, que evalúa si los controles funcionan eficazmente durante un período de tiempo.

Cuando una empresa contrata a un proveedor de servicios, el proveedor puede estar obligado en virtud del contrato a proporcionar informes SOC. Empresas de renombre como SAP entregan ellos mismos los informes. SAP no envía dichos informes por correo electrónico; los sube a su sitio confiable para que las empresas los descarguen.

Los informes SOC son importantes tanto para los proveedores de servicios como para el cliente por múltiples razones:

• Garantizan que un proveedor siga sólidas prácticas de seguridad y cumplimiento.
• Ayudan a los clientes a cumplir con los requisitos reglamentarios y de auditoría.
• Reducen la necesidad de realizar auditorías individuales de los clientes.
• Son esenciales para servicios en la nube como SAP S/4HANA, AWS, Azure y plataformas SaaS.

¿Aceptan los auditores los informes SOC como prueba de cumplimiento? La respuesta es no; Estos informes no eximen a los auditados de sus responsabilidades de cumplimiento. Los auditores los toman como parte de la evidencia disponible, pero también buscan pruebas adicionales de cumplimiento.

Por ejemplo, cuando los auditores auditan una empresa utilizando un servicio SaaS como SAP S/4HANA Cloud Public Edition, donde el proveedor del servicio gestiona completamente la infraestructura, los auditores pueden buscar lo siguiente como evidencia de cumplimiento:

• Informes SOC 1/SOC 2 Tipo II
• Certificados ISO 27001
• Resúmenes de pruebas de penetración
• Informes de cumplimiento del centro de datos (p. ej., ISO 22301, ISO 27017, ISO 27018)
• Documentos técnicos sobre seguridad de proveedores de nube

Además, la normativa vigente influirá aquí. Para cumplir con regulaciones estrictas como la Ley Sarbanes-Oxley (SOX), el Reglamento General de Protección de Datos (GDPR) y el Estándar de Seguridad de Datos de la Industria de Tarjetas de Pago (PCI DSS), los auditores pueden buscar evidencia adicional para proporcionar una hoja en blanco al auditado.

Conclusión

Proteger un entorno SAP no es un esfuerzo único ni la responsabilidad de un solo equipo: es un compromiso continuo de toda la organización que abarca la infraestructura física, las plataformas en la nube, los procesos comerciales y la responsabilidad compartida con los proveedores de servicios. Ya sea que su entorno sea totalmente local, basado en la nube o híbrido, comprender quién posee qué es fundamental para construir una postura defendible.

Los informes SOC, las certificaciones ISO y la documentación de los proveedores de la nube son puntos de partida sólidos, pero los auditores y el panorama de amenazas más amplio exigen más. Las arquitecturas de confianza cero, el monitoreo continuo y el diseño de procesos orientados a la seguridad deben trabajar en conjunto para reducir la exposición. Incluso cuando SAP administra la infraestructura, su organización sigue siendo responsable: trate la seguridad de la infraestructura no como una casilla de verificación de cumplimiento, sino como una disciplina continua integrada en todo, desde la planificación inicial de la arquitectura hasta las operaciones diarias.

Nota del editor: Esta publicación ha sido adaptada de una sección del libro. Seguridad del sistema SAP por Pradeep Kumar Mishra. El Dr. Mishra comenzó su trayectoria profesional como profesor de matemáticas en una universidad antes de hacer la transición a la informática. Tiene un doctorado en criptografía de clave pública, con un enfoque de investigación en criptografía de curva elíptica e hiperelíptica, y luego pasó a la industria para aplicar su experiencia en seguridad a los desafíos del mundo real. El Dr. Mishra ha pasado más de 13 años trabajando en seguridad y gobernanza, riesgo y cumplimiento (GRC) de SAP, principalmente como consultor que brinda apoyo a la industria del petróleo y el gas de Canadá. Es un profesional certificado por CISSP, CISA y CRISC, a través de lo cual ha adquirido una sólida experiencia en seguridad y GRC en complejos entornos empresariales de SAP. Durante su carrera académica, publicó más de 20 artículos de investigación en revistas y actas de congresos de renombre revisadas por pares. Sus contribuciones de investigación están disponibles en Google Scholar aquí.. Más allá de su trabajo técnico, al Dr. Mishra le apasiona explicar la tecnología en un lenguaje sencillo y no técnico para una audiencia más amplia. Además de escribir y hablar sobre tecnología, le gusta la poesía y pasar tiempo al aire libre.