DevSecOps, también en SAP

Preparados, listos...

DevOps no es una filosofía especialmente extendida en el ámbito del desarrollo en SAP. Aun teniendo en cuenta los innegables beneficios que ofrece, esta metodología todavía se encuentra en fase embrionaria, no exenta de incertidumbres. Dentro de este contexto puede parecer un tanto prematuro hablar de DevSecOps, aunque sí es cierto que se pueden empezar a dar ciertos pasos que faciliten su implantación.

Ya nadie duda de las evidentes ventajas que aporta DevOps en el ámbito del desarrollo, aunque también es muy cierto que todavía existen escenarios, como es el caso de SAP, en los que no se ha avanzado a la velocidad adecuada para poder adaptar esta metodología. En este ámbito, la evolución de las herramientas no ha seguido el mismo ritmo que en otros entornos y, seguramente, no se han hecho los esfuerzos necesarios para conseguir un cambio generalizado en la cultura y la filosofía de trabajo. Lo que también es cierto es que existen ciertos fundamentos que quizá impidan una integración total con este modelo. Por ejemplo, en la actualidad, la dificultad en la creación de runtimes ABAP con repositorios independientes parece un obstáculo insalvable para una implementación canónica de DevOps en SAP. Otro ejemplo: mientras que el sistema de transportes de SAP ha permanecido prácticamente inalterado desde las primeras versiones del ERP —con la notable excepción del SolMan ChARM /Change Request Management—, en una mayoría de lenguajes y frameworks de desarrollo los cambios han sido continuos, especialmente desde la aparición de la metodología Agile.

DEVOPS FOR SAP

Todos estos obstáculos no terminarán invalidando DevOps en SAP, sino que lo condicionarán de tal forma que, al final, ten-

dremos un DevOps for SAP. Es evidente que esta metodología ha promovido un cambio de paradigma en el ciclo de vida de las aplicaciones. SAP no puede quedar al margen de la evolución y de los beneficios que propone DevOps en ámbitos como la posibilidad de contar con repositorios centralizados, la gestión de aplicaciones híbridas o la homogeneización de los ciclos de despliegue. El camino está marcado, y tanto los integradores —o las áreas de desarrollo de las empresas— como el propio fabricante deben seguir avanzando en esa ineludible integración y acercamiento hacia el modelo DevOps. Por tanto, es necesario que los equipos de desarrollo SAP se adapten a este cambio de forma progresiva, evolucionando y adoptando aquellas características que aporten ventajas sobre el modelo actual. Eso sí, sin renunciar a mucho de lo que ya se hace bien en el ámbito de desarrollo SAP y que posiblemente no cambiará, como, por ejemplo, mantener la orden de transporte como unidad fundamental de despliegue.

ESPECIALIZAR LA SEGURIDAD

Otro de los retos importantes en este proceso es la necesaria adaptación cultural. Hay que tener en cuenta que DevOps requiere un cambio en la forma en la que la organización se compromete a trabajar. La práctica habitual dictaba que el desarrollo de aplicaciones se abordaba básicamente desde un punto de vista de TI, hablando con Negocio solo en determinados momentos, como la toma de requerimientos iniciales. Cuando se habla de DevOps, y sobre todo de DevSecOps, es necesario promover que diferentes roles y/o equipos —que antes trabajaban aislados— se coordinen desde el principio. Desde que nace la aplicación, en la toma de requerimientos iniciales, tienen que estar implicados los equipos de Infraestructura, de Negocio, de Desarrollo, y también los de Seguridad, y deben estar también involucrados en las siguientes fases de análisis, de testing, de entrada en producción e, incluso, en su posterior explotación. Lo curioso es que, cuando hablamos del desarrollo de aplicaciones SAP, la seguridad pocas veces ocupa un puesto de relevancia. Históricamente existe un déficit de en este tipo de aplicaciones y no se le prestaba demasiada atención a la seguridad en SAP, teniendo en cuenta que eran entornos muy “cerrados” y controlados. Normalmente, este aspecto suele aparecer de forma marginal en la fase de diseño y sus enunciados son bastante genéricos e implícitos, dejando casi toda la responsabilidad al programador, que normalmente se limita a proteger el acceso a ciertos recursos. De este modo, los equipos de desarrollo, así como los de pruebas, no suelen están formados en programación segura específica para SAP, más allá de poner ciertos artificios tales como los security checks. Nadie duda ya de la necesidad de incorporar la seguridad al ciclo de vida del desarrollo de software como una de las premisas indispensables, al mismo nivel que otras como el rendimiento, la mantenibilidad, la robustez o la escalabilidad. Eso sí, la integración de esta pieza de seguridad en todo el ciclo de vida del desarrollo requiere un grado adicional de especialización el ámbito específico de SAP.

INTEGRAR LA SEGURIDAD

Si simplemente fuésemos si capaces de involucrar la seguridad en todas las etapas del ciclo de vida de las aplicaciones, esto ya supondría una mejora sustancial al tratamiento actual de la seguridad en los desarrollos SAP. La cuestión es si es necesario adoptar de forma regulada DevSecOps para poder integrarla en el desarrollo de software. La respuesta es no, y seguramente aún queda algún tiempo para que podamos ver una implementación normalizada de DevSecOps en SAP. Lo que sí es posible es comenzar a implementar DevSecOps a través de una serie de iniciativas en diferentes niveles. Por ejemplo, como ya hemos comentado, incidiendo en la cultura de empresa, coordinando e integrando a los equipos responsables de la seguridad en el ciclo de despliegue de software. Pero también se puede actuar sobre la capacitación, formando a los equipos de programación, de testing y de seguridad en aquellos aspectos que son específicos del mundo SAP, para que puedan acompañar de forma adecuada durante todo el ciclo de vida de las aplicaciones.

Guillermo Vera

Partner

NOVIS EUFORIA

noviseuforia.com

*SAP no puede quedar al margen de la evolución y de los beneficios que ofrece la

metodología DevOps

Otro punto importante es el relativo a los procedimientos. En DevOps existen unos pipelines de entrega de software que siguen diferentes caminos que se pueden reproducir en el ciclo de vida de las aplicaciones SAP, por ejemplo, con la liberación de las ventanas de transporte a producción. De este modo, de forma previa a su entrada en producción, es posible introducir una serie de puntos de control específicos para todo lo relativo a la seguridad, integrándola en las fases de pruebas para detectar posibles vulnerabilidades. Por último, hay que incidir en todo lo relativo a las herramientas. Hasta ahora, en el ámbito de SAP, el sistema de transporte utilizado es TMS y, con la excepción del ChARM /Change Request Management, hasta la fecha no había soluciones que ayudasen a implementar DevOps en este ámbito. En cualquier caso, el fabricante alemán ya se está abriendo a la utilización de ciertas herramientas. Por ejemplo, en S/4 es posible publicar el repositorio ABAP en un repositorio compatible Git, o integrar el SolMan ChARM, con Jenkins, homogeneizando de esta forma la entrega del software. Si somos capaces de promover estas iniciativas, el beneficio para la organización, y para los clientes, será inmediato. Además, la posterior adaptación a DevSecOps, cuando finalmente explote en SAP, será poco más que automatizar lo que ya estamos haciendo.