Sommaire
Une usine logicielle doit être considérée comme un environnement de production sensible car tout le contenu qui y sera produit ira ensuite sur vos systèmes de production ou ceux de vos clients.
Il faut donc que toute l’activité soit effectuée en totale confiance.
Un mantra, simple, pour guider vos choix :
Je dois être capable, à tout moment, d’expliquer le pourquoi d’une configuration technique, la provenance d’une dépendance, le contenu d’un livrable, l’activité des acteurs.
Autrement dit, l’usine logicielle est un environnement technique qui doit être déterministe et où l’on sait qui fait quoi, comment et où l’on peut expliquer le pourquoi des contenus.
Des règles d’opération niveau production
L’usine logicielle est un environnement technique avec un certain nombre de services, opérés en interne et/ou en externe.
Gestionnaire de sources, moteurs de CI/CD et leur grappes d’agents de construction, gestionnaire d’artefacts, suivis de qualité et sécurité, une usine logicielle est clairement un environnement de production.
Il faut donc des règles strictes sur les opérations qui sont effectuées.
Maintien en conditions
Dès lors qu’on parle de production, on doit s’intéresser au MCO (maintien en condition opérationnelle) et MCS (maintien en condition de sécurité), cela fait partie des recommandations de l’ANSSI.
Le MCO correspond aux montées de versions, pour ajout de correctifs ou nouvelles fonctionnalités, quand le MCS lui porte sur des corrections de failles de sécurité.
La mise à jour des composants de l’usine logicielle doit se faire sur un scope complet qui va du hosting aux applications de l’usine
- Les conditions de MCO et MCS doivent être définies et connues de tous
- Quand
- Pourquoi
- A quelle fréquence
- Quel délai de réponse pour une MCO et pour une MCS
- Les fréquences de mise à jour pour MCO et MCS peuvent être différentes
- Pour les mises à jour de sécurité
- On fait une étude pour déterminer l’exploitabilité de la faille
- Si la faille est critique et exploitable, on applique les correctifs le plus rapidement possible, quitte à devoir interrompre le service aux utilisateurs
Les erreurs sont analysées et suivies
Si certains services ou applications ne fonctionnent pas comme de normal, on investigue sans tarder pour en déterminer les raisons.
Le but est d’avoir un niveau de service de niveau production, ne pas laisser des zones de flous ou de chaos, une usine logicielle doit être prédictible et stable, c’est un facteur de confiance important.
Comme tout environnement de production sensible, on s’assure aussi qu’il n’y a pas d’activité ou contenu malveillants et si on a une suspicion on se rapproche des équipes sécurité.
De même, tout incident de production doit être suivi et donner lieu à un post mortem. Si des actions de mitigation, correction ou monitoring préventifs seront nécessaires, il faudra pouvoir les rattacher au post mortem.
Suivi de toutes les vulnérabilités de l’usine
Une usine logicielle est une composante du système d’information global et de la même manière que l’on suit les vulnérabilités sur les vos environnements de production, on doit suivre les annonces sur les nouvelles failles qui peuvent s’appliquer sur les solutions déployées directement ou indirectement sur l’usine.
Il est donc recommandé de suivre les annonces des organismes spécialisés dans le suivi des failles comme NIST ou CVE qui offrent des notifications par courriel ou des publications sur X.
Pour ce faire, il faut une cartographie de l’usine logicielle recensant l’ensemble des composants logiciels utilisés, tant les outils que les services qu’ils utilisent.
Pour donner un exemple, GitLab, Artifactory et Sonarqube utilisent des bases de données relationnelles, il faudra aussi suivre les vulnérabilités de ces moteurs SQL.
Les alertes de sécurité sur la partie hébergement sont aussi à suivre, équipements réseaux, systèmes d’exploitation et orchestrateurs et services connexes.
Des actions tracées
Dès lors que les acteurs sur l’usine logicielle sont clairement identifiés, il devient possible de suivre les opérations et associer le pourquoi au comment.
Dis autrement, établir la relation bidirectionnelle entre la demande (le besoin) et l’implémentation technique.
Prenons un exemple, la montée de version d’un outil.
La gestion de projet se fait avec Jira, les opérations sur l’infrastructure utilisent une mécanique d’Infra As Code depuis un gestionnaire de source Git :
- Un ticket Jira pour la montée de version. C’est le pourquoi qui détaille les attendus et les motivations (fonctionnalités, correctifs ou sécurité).
- Dans le code d'implémentation, le comment, on trouve un lien vers le ticket Jira.
- La mécanique de validation des changements de code (Merge/Pull Requests) permet d’avoir à la fois le pourquoi et le comment. Les acteurs qui vont valider ont ainsi l’ensemble des informations de prise de décision.
- Dès la validation des changements, l’outillage CI/CD va effectuer des opérations qui vont produire le résultat.
La validation des changements peut se faire avec différents acteurs, qu’ils appartiennent à l’équipe CI/CD ou une équipe plus orientée sécurité SecOps.
Dès lors, on a l’ensemble des actions tracée via le suivi des Merge/PR du projet avec :
- Le pourquoi
- Le comment
- Les acteurs
- L’ensemble des discussions de la demande à la validation.
- Les résultats obtenus
Vous pourrez ainsi à tout moment expliquer le pourquoi et le comment de toute action sur le système d’information.
Une usine reproductible et prédictible
La confiance dans une usine logicielle vient d’un environnement où le hasard n’a pas sa place, tout est tel qu’attendu, prédictibilité et reproductibilité des opérations est donc capital.
Environnement reproductible
Avec l’avènement de l’Infra As Code, il est possible d’avoir un environnement parfaitement défini et cartographié. Vous pouvez ainsi non seulement construire et mettre à jour votre usine de manière reproductible, mais vous pouvez aussi montrer comment cela se fait.
Tout est visible et explicable, la taille des dispositifs, la configuration des services, les règles de sécurité, systèmes ou encore les réglages d’interconnexion et d’isolation.
Il n’y a pas d’éléments inconnus dans l’environnement, ou de shadow IT, l’ensemble des composants qui participent à l’usine sont parfaitement identifiés.
Un autre intérêt de l’Infra As Code, est que l’environnement pourra être reconstruit, ailleurs, à tout moment, c’est qui est indispensable pour avoir des solutions de repli, en cas de problèmes techniques ou d’attaques.
Environnement prédictible
Avec un mécanisme reproductible, on peut avoir simplement des environnements de backup et qualification de l’usine qui seront ISO production. Ces environnements permettent d'effectuer toutes sortes de tests sans perturber la production, comme valider la mécanique de Plan de Reprise d’Activité (PRA) en restaurant régulièrement les backups de production.
Il est ainsi possible de tester une montée de version, d’en mesurer le temps d’indisponibilité et de détecter des régressions ou comportements anormaux. L’opération de production sera donc anticipée, maîtrisée et les informations utiles communiquées aux utilisateurs.
On peut aussi effectuer des tests de montée en charge (Capacity Planning), pour déterminer les seuils et limites de fonctionnement (Baseline), définir les SLI (Service Level Indicator) qui seront à suivre pour garantir le niveau de service (SLO/SLA) en production.
Ceci permet de savoir quand déclencher les évolutions sur l'environnement de production. Cette anticipation participe en la confiance qu’on aura sur la capacité de son usine à produire et ainsi à détecter des baisses de performances, qui peuvent être liées à des bugs mais aussi des activités suspectes.
Isolation entre environnements
L’usine logicielle doit être isolée des autres environnements afin qu’elle ne puisse être contaminée ou ne puisse contaminer elle-même.
Implicitement, cela oblige à définir les points de contacts entre environnements, décrire les processus de communication avec les environnements et ainsi de mieux protéger la chaîne de production..
Le niveau d’isolation va dépendre de votre contexte et des normes que vous suivez ou ciblez.
Par exemple, pour la conformité SecNumCloud, il faut garantir l’étanchéité totale entre zones d’exploitation (production) et l’usine logicielle. Il sera donc impossible de faire du GitOps traditionnel, votre moteur GitOps n’aura pas le droit d’accéder aux zones d’exploitation.
Il faut donc concevoir très tôt les mécaniques d’orchestration CI/CD compatibles avec vos contraintes.
Conclusion
Une usine logicielle est un environnement isolé des autres, qui doit suivre des règles de niveau production.
Avec un suivi des actions mais aussi des incidents rencontrés, qu’ils soient techniques, fonctionnels ou de sécurité, on obtient la transparence et la traçabilité qui sont les conditions nécessaires à la confiance dans votre production logicielle.
Cette rigueur est un des éléments clés pour l’obtention ou le renouvellement de conformités ISO, HDS ou SecNumCloud.
