Analyse de la sécurité et de la fiabilité : 7 points faibles du modèle de livraison à vérifier en priorité

Pourquoi ton modèle de déploiement est un enjeu de sécurité et de fiabilité

Point clé : les audits de sécurité qui se concentrent uniquement sur le code des applications négligent souvent complètement la couche de déploiement. C’est là que se trouvent les défaillances les plus courantes et les plus évitables.

La plupart des équipes considèrent la sécurité comme une couche ajoutée par-dessus un système déjà opérationnel. Le problème, c’est que le modèle de déploiement lui-même introduit des risques avant même qu’une seule ligne de code d’application ne soit exécutée.

Lorsque les déploiements sont manuels, que les environnements ne sont pas cohérents ou que la configuration dérive d’une étape à l’autre, le système se comporte de manière imprévisible. Cette imprévisibilité rend les incidents plus difficiles à détecter et plus faciles à aggraver.

Les 7 points faibles à vérifier en priorité

1. Environnements incohérents

Lorsque les environnements local, de préproduction et de production sont configurés différemment, tu ne testes pas ce que tu mets en production. Les bugs qui n’apparaissent qu’en production sont souvent des bugs d’environnement, pas des bugs de code.

À vérifier : peux-tu créer un nouvel environnement en utilisant les mêmes données et la même configuration que celles utilisées en production ?

2. Étapes de déploiement manuelles

Toute étape qui nécessite qu’une personne exécute une commande est une étape qui peut être sautée, effectuée dans le désordre ou oubliée sous la pression. L’écart entre les équipes qui automatisent et celles qui ne le font pas est mesurable : selon l’étude DORA de 2024, les équipes les plus performantes se remettent d’un déploiement raté 2 293 fois plus vite que les moins performantes et affichent un taux d’échec des changements 8 fois plus faible.

À vérifier : combien d’étapes de déploiement ne sont pas sous contrôle de version ? Si un nouveau venu devait effectuer un déploiement aujourd’hui, qu’est-ce qu’il ne trouverait pas dans la doc ?

3. Responsabilités floues

Quand personne n’est clairement responsable d’un environnement ou d’une décision de configuration, les problèmes s’accumulent. Les accès persistent même après le départ des personnes concernées. La dette technique est reportée jusqu’à ce qu’elle se transforme en incident.

À vérifier : pour chaque environnement de ton pipeline de livraison, peux-tu nommer la personne responsable de son état actuel ?

4. Des procédures de retour en arrière insuffisantes

Une restauration rapide est à la fois un mécanisme de fiabilité et de sécurité. Si la restauration d’un mauvais déploiement prend des heures ou nécessite de reconstituer l’état manuellement, l’ampleur des répercussions de n’importe quel incident augmente.

À vérifier : combien de temps prend réellement une restauration dans ta configuration actuelle ? A-t-elle été testée récemment, ou s’agit-il d’une hypothèse théorique ?

5. Dérive de configuration

La dérive de configuration se produit lorsque des environnements qui devraient correspondre divergent progressivement à cause de modifications ponctuelles, souvent dans un panneau de contrôle que personne ne vérifie. C’est l’un des modes de défaillance les plus difficiles à détecter.

À vérifier : la configuration de ton infrastructure est-elle gérée par versions, au même titre que le code de l’application ?

6. Mauvaises pratiques en matière de contrôle d’accès

Les autorisations larges accordées par commodité sont rarement revues à la baisse. Au fil du temps, de plus en plus de personnes ont accès à l’environnement de production alors qu’elles n’en ont pas besoin. Cela va au-delà du risque opérationnel : le rapport 2024 de Verizon sur les enquêtes relatives aux violations de données a révélé que des identifiants volés étaient impliqués dans 31 % de toutes les violations au cours des dix dernières années, faisant des accès excessifs l’un des points de vulnérabilité les plus systématiquement exploités

À vérifier : qui a actuellement accès à l’environnement de production ? Cette liste est-elle revue régulièrement ? Les autorisations sont-elles limitées à ce dont chaque rôle a besoin ?

7. Faible prévisibilité des déploiements

Si les développeurs ne sont pas sûrs qu’un déploiement se passera sans accroc, ils repoussent la mise en production. Les ensembles de modifications plus volumineux sont plus difficiles à valider et à annuler. Le risque s’aggrave.

À vérifier : qu’est-ce qui a provoqué le dernier gel imprévu d’un déploiement ? La cause sous-jacente a-t-elle été résolue ?

Découvre à quoi ressemble un modèle de livraison sans ces lacunes

À quoi ça ressemble quand tout va bien

Point clé : une bonne hygiène de livraison réduit le nombre de décisions qui nécessitent qu’un humain fasse le bon choix à chaque fois.

Un modèle de livraison qui gère bien ces aspects présente quelques caractéristiques communes :

• La configuration est gérée par un système de contrôle de version, ce qui rend les décisions relatives à l’infrastructure vérifiables et réversibles.
• Les environnements sont créés à partir de la même source, ce qui fait que l'environnement de test se comporte comme l'environnement de production.
• Les déploiements sont déclenchés par Git. L’historique des commits constitue le journal des déploiements.
• L’accès est limité et vérifiable, avec un responsable clairement désigné pour chaque environnement.

Upsun s’articule autour de ces principes : la configuration est stockée dans des fichiers YAML validés dans ton dépôt, chaque branche peut générer un environnement entièrement isolé, et l’accès est géré au niveau de l’environnement. 

Questions rapides d’auto-évaluation

Point clé à retenir : si tu mets plus de quelques minutes à répondre à l’une de ces questions, c’est en soi un constat.

Passe-les en revue avant ton prochain audit :

1. Si un membre de l’équipe partait aujourd’hui, est-ce que quelqu’un d’autre pourrait effectuer un déploiement en toute confiance en utilisant uniquement ce qui se trouve dans le dépôt ?
2. À quand remonte la dernière fois où tu as testé une restauration de bout en bout ?
3. Peux-tu fournir une liste à jour de toutes les personnes ayant accès à l'environnement de production et justifier chaque entrée ?
4. L'environnement de préproduction est-il actuellement synchronisé avec la configuration de production ?
5. Combien d’étapes de déploiement nécessitent l’intervention directe d’une personne en particulier ?

Comment repérer les lacunes à combler en priorité

Point clé : les lacunes qui passent inaperçues sont celles qui finissent par se transformer en incidents graves. La visibilité, c’est la première étape.

Établis tes priorités en fonction de deux facteurs :

• À quelle fréquence cette lacune t'affecte-t-elle ? Les chemins de retour en arrière peu fiables ont plus d'importance si tu effectues des déploiements fréquents. La dérive de configuration a plus d'importance dans les environnements à longue durée de vie.
• Est-ce difficile de détecter quand quelque chose ne va pas ? Les failles qui échouent en silence, comme la prolifération des accès ou l’incohérence des environnements, méritent une priorité plus élevée que celles qui génèrent des erreurs immédiates.

Commence par la faille qui est à la fois courante et difficile à détecter.

Prêt à passer en revue ton modèle de déploiement avec l’équipe Upsun ? Réserve un bilan de fiabilité

En savoir plus

• https://upsun.com/blog/dora-exit-strategy-for-financial-services/
• https://upsun.com/blog/git-driven-environments-infrastructure-as-code/
• https://upsun.com/blog/developer-guide-to-building-apps-without-infrastructure-burden/
• https://upsun.com/blog/unified-cloud-management-platform/

Foire aux questions (FAQ)

Est-ce que ça a un intérêt si on a déjà une équipe de sécurité qui fait des audits ? 

Oui, et c’est complémentaire plutôt que redondant. La plupart des audits de sécurité se concentrent sur le code des applications, la configuration réseau et les politiques d’accès. La couche de mise en production (cohérence de l’environnement, processus de déploiement, gestion de la configuration) est souvent hors du champ d’un audit standard, et c’est là que s’accumulent les failles structurelles entre deux cycles d’audit.

Comment établir des priorités pour corriger ces problèmes si on a des capacités d’ingénierie de plateforme limitées ? 

Commence par les failles qui sont à la fois courantes et silencieuses. La dérive de configuration et le manque de clarté quant à la responsabilité sont les deux éléments qui entraînent le plus de coûts en aval, car ils sont difficiles à détecter tant qu’ils ne s’accumulent pas. Ces deux problèmes peuvent être partiellement résolus en intégrant la définition de l’infrastructure dans un système de contrôle de version, ce qui ne nécessite pas d’équipe dédiée à la plateforme, mais simplement un changement dans la façon dont la configuration est gérée.

Quel est le lien entre ces points faibles et les référentiels de conformité comme SOC 2 ou ISO 27001 ? 

Plusieurs des sept points correspondent directement à des contrôles présents dans les deux référentiels : les modèles de contrôle d’accès, la gestion de la configuration et les enregistrements des changements de déploiement sont des exigences explicites dans la plupart des référentiels de conformité. Combler ces lacunes au niveau de la couche de livraison ne se contente pas de réduire le risque opérationnel ; ça génère les preuves d’audit requises par ces référentiels comme un résultat naturel des opérations normales, plutôt que comme un exercice de collecte manuelle.

À quelle fréquence faut-il effectuer cet examen ? 

Au minimum, avant une mise à jour majeure, avant un audit et après tout changement important au sein de l’équipe (nouvelles embauches, départs ou restructuration). En pratique, les équipes qui ont de bonnes pratiques de livraison intègrent certaines de ces vérifications dans leur cycle de sprint régulier pour éviter que les lacunes ne s’accumulent entre deux revues.