Formation DevOps écrite

Comment protéger votre pipeline de déploiement DevOps ?

Après avoir construit avec votre équipe DevOps un pipeline de déploiement opérationnel pour la livraison continue en suivant les principes précédents, vous pouvez effectuer des déploiements à faible risque en production sans approbation externe. La plupart de vos déploiements en production n’ont plus besoin de suivre un processus d’approbation. Vous vous appuyez sur une méthode de livraison bien conçue, des tests et une supervision automatisés et des alertes intelligentes, au-delà des seules autorités externes. La sécurité et la conformité restent néanmoins une responsabilité importante de votre équipe DevOps. Il s’agit de répondre aux exigences de la loi et de bien servir vos clients. Votre équipe continue à travailler avec les spécialistes de la sécurité et de la conformité de l’organisation, mais la conception de systèmes sécurisés et conformes au cadre juridique où votre organisation évolue doit devenir une habitude de travail quotidienne.

Types de changements dans vos systèmes de production

• Changements standard : Changements à faible risque qui ne nécessitent pas d’approbation et se déploient rapidement, car ils sont entièrement automatisés et journalisés. Les mises à jour de tables de référence, de contenu ou de mise en forme et les correctifs standard de systèmes d’exploitation, de bases de données ou d’autres composants externes en sont des exemples.
• Changements normaux : Changements à haut risque nécessitant l’approbation du comité consultatif des changements (CAB). Ce comité demande un formulaire de demande de changement (RFC) pour les évaluer. Les délais sont longs, car les membres du comité connaissent le plus souvent mal les changements. Ils les mettent en attente et finissent par prendre une décision selon leur expérience, leur intuition et leurs préjugés sur l’auteur de la demande.
• Changements urgents : Changements à haut risque qui nécessitent l’approbation de la direction. Les erreurs critiques de production qui touchent les clients, les corrections de déploiements défectueux, les correctifs de sécurité et les rétablissements de service en sont des exemples.

Quel que soit le type de changement, votre équipe DevOps et vous-même devez le documenter dans vos systèmes de gestion des changements et de planification du travail, tels que Remedy et Jira. Le travail sera ainsi visible pour tous, dans l’équipe et en dehors.

Appuyez-vous sur vos déploiements automatisés réussis pour convertir des changements normaux en changements standard

En augmentant la proportion de changements standard par rapport aux changements normaux, vous évitez les approbations du comité consultatif des changements (CAB), accélérez le flux et améliorez la qualité du pipeline de déploiement.

Votre équipe DevOps et vous-même vous appuyez désormais sur les déploiements automatisés réussis pour convertir autant de changements normaux que possible en changements standard. Présentez au CAB l’historique des déploiements et la liste des incidents en production pour montrer que les déploiements automatisés ne provoquent aucun incident ou seulement des incidents négligeables.

Accélérez le déploiement des changements normaux

Pour les changements qui doivent rester normaux, automatisez la préparation du formulaire de demande de changement (RFC). Associez au formulaire les résultats de tous les tests, automatisés ou non, les incidents résolus et non résolus, ainsi que les données de supervision et les journaux des systèmes hors production. Facilitez le travail du CAB en lui donnant dès la première version toutes les informations qu’il recherche, afin d’accélérer autant que possible les approbations.

Une fois les changements normaux approuvés, permettez leur déploiement en un clic. Examinez régulièrement leurs différents types avec le CAB. Définissez les critères qui le convaincraient de les convertir en changements standard pour pouvoir déployer automatiquement la plupart des changements de votre organisation DevOps.

Réduisez la bureaucratie et la dépendance à l’égard de tiers dans votre organisation DevOps

Plus une organisation grandit, plus la bureaucratie trouve de quoi se nourrir. Elle a la capacité insidieuse de croître de façon exponentielle et de durer indéfiniment. Quand vous dépendez d’une autorité et de contrôles du niveau hiérarchique supérieur pour approuver votre propre travail, vous perdez votre autonomie et le sentiment d’être responsable des résultats. L’autorité au-dessus de vous échouera alors régulièrement.

Cette autorité finira par dépendre à son tour d’une autre autorité pour être contrôlée. Cette spirale ne fait que s’allonger jusqu’à la prochaine réorganisation de votre entreprise. Après celle-ci, une nouvelle spirale sous une forme légèrement différente a presque 100 % de chances de prendre la place de la précédente.

Votre entreprise doit garder à l’esprit que la séparation des tâches et les mécanismes de contrôle et de dépendance extérieurs à l’équipe ralentissent la livraison, en réduisent la qualité et rendent l’organisation moins sûre. Une grande institution financière américaine a été victime d’une fraude aux distributeurs automatiques à cause d’une porte dérobée intégrée par un développeur à leur logiciel. Aucun auditeur, expert en sécurité, responsable de la conformité ou membre du CAB extérieur à l’équipe n’a pu repérer le code frauduleux mis en production. Seule l’équipe qui l’a développé aurait pu le repérer en appliquant des pratiques DevOps de base, comme l’inspection des modifications intégrées et les revues de code.

Pour livrer vite et en toute sécurité, réduisez la dépendance à l’égard de tiers et la séparation des tâches, qui empêchent votre équipe DevOps de prendre ses responsabilités. Mettez en place d’autres contrôles dans l’équipe, comme l’inspection des modifications, la programmation en binôme, les revues par les pairs, les tests et la supervision automatisés. Si la séparation des tâches est légalement obligatoire, les contrôles intégrés à l’équipe permettront quand même aux auditeurs et aux responsables de la conformité de prendre des décisions plus éclairées et plus rapides.

CONCLUSION

Le DevOps introduit une dimension nouvelle et dynamique dans la conformité et la sécurité de l’information. Lorsque l’infrastructure est définie en code, que le code fait apparaître et disparaître des systèmes et qu’il est déployé automatiquement, il devient difficile pour les auditeurs de comprendre ce qui se passe. C’est un nouveau défi et une occasion de mettre en place des mécanismes et des fonctions d’audit et de conformité plus légers et plus efficaces.

Dans votre équipe DevOps, la sécurité de l’information, la conformité et l’accélération du pipeline relèvent de tous. L’un de vos objectifs majeurs consiste à permettre aux responsables de la conformité de consulter en libre-service les informations, journaux, rapports et indicateurs qui attestent la qualité de la livraison. Cela simplifiera les processus d’approbation bureaucratiques, voire permettra de les supprimer.