Au-delà du contrôle de version: vérification de la nomenclature IBM i pour l’intégrité DevSecOps

DevSecOps sur IBM i: Sécuriser l’intégrité des objets dans tous les environnements

Dans l'univers IBM i, les écosystèmes applicatifs sont vastes, complexes et profondément intégrés. Contrairement aux systèmes distribués, les applications IBM i comprennent des milliers d'objets distincts (programmes, zones de données, fichiers, programmes de service, etc.) répartis dans de multiples bibliothèques et environnements, notamment de développement, de test et de production. La gestion de l'intégrité, de la synchronisation et de la sécurité de ces objets est essentielle à la continuité des opérations et à la conformité réglementaire.

Comprendre les objets et les dépendances d'IBM i

Les applications IBM i sont fondamentalement orientées objet. Chaque objet remplit une fonction spécifique, réside dans une bibliothèque et possède des attributs tels que la propriété, les autorisations et les dépendances vis-à-vis d'autres objets. Par exemple, un objet programme peut dépendre d'un programme de service ou d'un fichier de base de données, qui doit être à la version requise pour que l'application fonctionne correctement.

Étant donné que ces objets sont déployés sous forme de fichiers binaires (et non construits dynamiquement à partir du code source lors de l'exécution, comme dans de nombreux systèmes distribués), il est particulièrement important de suivre et de vérifier les versions correctes de tous les objets dans chaque environnement.

Le défi DevSecOps

Les équipes d'exploitation et de développement doivent collaborer étroitement pour garantir la cohérence des objets IBM i entre les environnements de développement, de test et de production. Sans processus DevSecOps coordonné, les objets risquent de se désynchroniser: des binaires obsolètes, des paramètres d'autorisation incorrects, des dépendances mal compilées et des modifications non autorisées peuvent engendrer des risques opérationnels.

Ces anomalies peuvent entraîner des défaillances d'applications, des failles de sécurité, des anomalies lors des audits et des conséquences financières.

Le risque s'accroît lorsque des correctifs d'urgence sont appliqués directement en production. Bien que souvent nécessaire pour résoudre des problèmes urgents, cette pratique contourne les processus formels de contrôle des changements, les référentiels de code source et les journaux d'audit. Lorsque ces modifications ne sont pas répercutées sur les systèmes de développement et de test, des dérives de l'environnement peuvent persister sans être détectées.

Dans le pire des cas, les environnements de production pourraient être compromis par des modifications malveillantes. Étant donné que les objets IBM i ne sont pas reconstruits à partir du code source lors du déploiement, un acteur malveillant ayant accès à la production pourrait y injecter des fichiers binaires malveillants qui resteraient invisibles lors des analyses de code source standard.

Sécuriser le pipeline DevSecOps

Une stratégie DevSecOps efficace pour IBM i nécessite plus qu'un simple contrôle de version: elle exige une gouvernance complète au niveau objet. Les pratiques clés incluent:

• Suivi et vérification au niveau objet: Mettre en œuvre des outils et des processus pour suivre les objets dans différents environnements, en vérifiant que les binaires de production correspondent précisément à ce qui est défini dans le contrôle de version et les environnements de développement.
• Déploiement facilité par l'audit: Adoptez des flux de travail de promotion qui enregistrent quels objets sont déployés, où, quand et par qui.
• Synchronisation des environnements: veiller à ce que les correctifs d'urgence soient recensés, documentés et intégrés aux environnements de développement et de test afin de maintenir la cohérence.
• Gestion des autorisations: auditez régulièrement les autorisations au niveau des objets afin d’identifier les privilèges excessifs, les changements de propriété inappropriés et les risques de sécurité potentiels.

Pourquoi l'intégrité des objets est importante

Même avec une nomenclature (BOM) documentée pour chaque version, une liste des objets attendus ne suffit pas. Il est impératif de vérifier que les objets réellement utilisés en production correspondent bien à ceux prévus lors du développement et dans le système de gestion de versions.

Les divergences peuvent entraîner des échecs d'audit, des incohérences opérationnelles et, dans les cas les plus graves, une perturbation des activités en raison de l'exécution de code malveillant.

Les conséquences d'un audit non concluant sont importantes: sanctions réglementaires, atteinte à la réputation, retards opérationnels et pertes financières. Les organisations peuvent être contraintes d'interrompre leurs déploiements, de revalider leurs systèmes ou de suspendre leurs activités jusqu'à ce que la conformité soit rétablie.

Combler le fossé en matière de contrôle des sources

Dans les environnements IBM i, le DevSecOps ne se limite pas à l'automatisation des pipelines ; il s'agit de préserver l'intégrité et la confiance dans chaque environnement, objet par objet. Les systèmes de contrôle de version populaires comme Git, bien qu'excellents pour la gestion du code source, ne prennent pas en charge nativement l'architecture orientée objet d'IBM i. Ils ne permettent pas de vérifier si l'objet déployé en production a bien été compilé à partir du code source du dépôt.

Cet écart souligne la nécessité de disposer d'outils et de processus de vérification supplémentaires, spécifiques à IBM i, afin de maintenir la confiance et la conformité opérationnelles.

Conclusion

Le succès du DevSecOps sur IBM i repose non seulement sur l'automatisation, mais aussi sur une vérification rigoureuse et continue de l'intégrité des objets dans les environnements de développement, de test et de production. Les applications IBM i étant conçues et déployées sous forme d'objets binaires (souvent indépendamment des dépôts de code source), les outils de gestion de versions traditionnels ne suffisent pas à garantir leur conformité en production.

Pour se prémunir contre les problèmes de conformité, les menaces de sécurité et les interruptions opérationnelles, les organisations doivent adopter des pratiques DevSecOps orientées objet. Cela inclut un suivi rigoureux, des processus de déploiement prêts pour l'audit, une synchronisation proactive de l'environnement et des examens d'autorisation approfondis.

En définitive, une approche DevSecOps efficace sur IBM i implique de vérifier ce qui est réellement exécuté, et pas seulement ce qui est documenté.