Más allá del control de versiones: Verificación de la lista de materiales de IBM i para la integridad de DevSecOps

DevSecOps en IBM i: Garantizando la integridad a nivel de objeto en diferentes entornos

En el mundo de IBM i, los ecosistemas de aplicaciones son vastos, complejos y están profundamente integrados. A diferencia de los sistemas distribuidos, las aplicaciones de IBM i constan de miles de objetos independientes (programas, áreas de datos, archivos, programas de servicio, etc.) distribuidos en múltiples bibliotecas y entornos, incluidos desarrollo, pruebas y producción. Gestionar la integridad, la sincronización y la seguridad de estos objetos es fundamental para la continuidad operativa y el cumplimiento normativo.

Comprensión de los objetos y dependencias de IBM i

Las aplicaciones de IBM i se basan fundamentalmente en objetos. Cada objeto realiza una función específica, reside en una biblioteca y posee atributos como propiedad, autoridad y dependencias con otros objetos. Por ejemplo, un objeto de programa puede depender de un programa de servicio o un archivo de base de datos, que debe estar en la versión correcta para que la aplicación funcione correctamente.

Dado que estos objetos se implementan como binarios —y no se compilan dinámicamente a partir del código fuente en tiempo de ejecución, como ocurre en muchos sistemas distribuidos—, es especialmente importante realizar un seguimiento y verificar las versiones correctas de todos los objetos en todos los entornos.

El desafío DevSecOps

Los equipos de operaciones y desarrollo deben trabajar en conjunto para garantizar la coherencia de los objetos de IBM i en los entornos de desarrollo, pruebas y producción. Sin un proceso DevSecOps coordinado, es fácil que los objetos se desincronicen: binarios obsoletos, configuraciones de permisos incorrectas, dependencias compiladas de forma inadecuada y cambios no autorizados pueden generar riesgos operativos.

Estas discrepancias pueden provocar fallos en las aplicaciones, vulnerabilidades de seguridad, hallazgos en las auditorías e impactos financieros.

El riesgo aumenta cuando se aplican soluciones de emergencia directamente en producción. Si bien esta práctica suele ser necesaria para resolver problemas urgentes, elude los procesos formales de control de cambios, los repositorios de código fuente y los registros de auditoría. Cuando estos cambios no se adaptan a los sistemas de desarrollo y prueba, la desviación del entorno puede persistir sin ser detectada.

En el peor de los casos, los entornos de producción podrían verse comprometidos por modificaciones maliciosas. Dado que los objetos de IBM i no se reconstruyen desde el código fuente durante la implementación, un atacante con acceso a producción podría inyectar binarios maliciosos que pasarían desapercibidos para las revisiones de código fuente estándar.

Garantizar la seguridad del flujo de trabajo DevSecOps

Una estrategia DevSecOps eficaz para IBM i requiere más que control de versiones: exige una gobernanza integral a nivel de objeto. Las prácticas clave incluyen:

• Seguimiento y verificación a nivel de objeto: Implementar herramientas y procesos para realizar un seguimiento de los objetos en diferentes entornos, verificando que los binarios de producción coincidan exactamente con lo definido en los entornos de control de versiones y desarrollo.
• Implementación que facilite la auditoría: adopte flujos de trabajo de promoción que registren qué objetos se implementan, dónde, cuándo y quién los implementa.
• Sincronización del entorno: Asegúrese de que las correcciones de emergencia se registren, documenten y adapten a los entornos de desarrollo y prueba para mantener la coherencia.
• Gestión de autorizaciones: Audite periódicamente las autorizaciones a nivel de objeto para identificar privilegios excesivos, cambios de propiedad indebidos y posibles riesgos de seguridad.

Por qué es importante la integridad de los objetos

Incluso con una lista de materiales documentada para cada versión, no basta con tener una lista de los objetos esperados. Es necesario confirmar que los objetos que se ejecutan en producción coinciden con los previstos en el desarrollo y el control de versiones.

Las discrepancias pueden provocar fallos en las auditorías, inconsistencias operativas y, en los casos más graves, interrupciones en la actividad empresarial debido a la ejecución de código malicioso.

Las consecuencias de una auditoría fallida son significativas: sanciones regulatorias, daños a la reputación, retrasos operativos y pérdidas financieras. Las organizaciones pueden verse obligadas a detener implementaciones, revalidar sistemas o suspender operaciones hasta que se restablezca el cumplimiento normativo.

Superando la brecha en el control de origen

En entornos IBM i, DevSecOps no se limita a la automatización de la canalización, sino que se centra en preservar la integridad y la confianza en todos los entornos, objeto por objeto. Los sistemas de control de versiones populares, como Git, si bien son excelentes para gestionar el código fuente, no manejan de forma nativa la arquitectura basada en objetos de IBM i. Carecen de la capacidad de confirmar si el objeto implementado en producción se compiló a partir del código fuente del repositorio.

Esta deficiencia pone de manifiesto la necesidad de herramientas y procesos de verificación adicionales, específicos de IBM i, para mantener la confianza operativa y el cumplimiento normativo.

Conclusion

El éxito de DevSecOps en IBM i depende no solo de la automatización, sino también de una verificación rigurosa y continua de la integridad de los objetos en los sistemas de desarrollo, prueba y producción. Dado que las aplicaciones de IBM i se compilan y despliegan como objetos binarios —a menudo independientemente de los repositorios de código fuente—, las herramientas tradicionales de control de versiones por sí solas son insuficientes para garantizar la fidelidad en producción.

Para protegerse contra problemas de cumplimiento, amenazas de seguridad e interrupciones operativas, las organizaciones deben adoptar prácticas DevSecOps centradas en objetos. Esto incluye un seguimiento exhaustivo, procesos de implementación listos para auditoría, sincronización proactiva del entorno y revisiones rigurosas de las autorizaciones.

En definitiva, una implementación eficaz de DevSecOps en IBM i implica verificar lo que realmente se está ejecutando, no solo lo que está documentado.