DevSecOps – Architecture de référence – Blogs performants

Architecture de référence DevSecOps

Lors de l'approche d'une implémentation DevSecOps complexe, il est souvent utile de considérer une architecture de référence comme point de départ. Comme l'illustre la figure 1, les activités d'automatisation peuvent être divisées en trois domaines principaux: l'intégration continue (CI), le déploiement continu (CD) et la conformité continue (CC). Chacun de ces domaines comprend un objectif distinct pour la mise en œuvre de DevSecOps. Par exemple, une équipe peut automatiser les aspects de génération, de test et d'analyse de sécurité de CI sans implémenter complètement le déploiement automatisé. Cependant, pour tirer pleinement parti de l'architecture, il est nécessaire que tous les espaces soient construits et fonctionnent comme un tout. Cela inclut une intégration appropriée dans le pipeline d'outils sélectionné.

Il existe de nombreux outils disponibles sur le marché pour permettre une livraison automatisée DevSecOps. Par exemple, de nombreux pipelines automatisés sont gérés par CloudBees ^(TM) Jenkins automatisation du flux de travail. Le contrôle des sources est souvent assuré par une variante de «git», comme BitBucket, GitLab ou GitHub. L'analyse de code automatisée peut être effectuée avec une variété de produits open source et commerciaux, tels que SonarQube, Veracode, Sonatype-Nexus IQ ou Blackduck. Xebialabs (fournisseur d'outils de déploiement) propose une très belle page de résumé pour la plupart des outils actuellement disponibles.

Figure 1. Architecture de référence du pipeline DevSecOps automatisée

Au-delà des outils , il est important de considérer comment les processus de développement, d'exploitation et de sécurité s'intégreront au pipeline de livraison automatisé. Par exemple, la coordination des versions est extrêmement importante pour la livraison des produits dans les environnements de production. Un processus inefficace d'examen et d'approbation des versions peut faire dérailler le pipeline DevSecOps le plus efficace. Dans l'architecture de référence, cela est représenté sous l'aspect Gouvernance ainsi que les pratiques de surveillance et de déploiement opérationnels.

Intégration continue (CI)

L'intégration continue automatise les aspects répétitifs de la construction du système, de l'empaquetage, des tests unitaires et de l'analyse de sécurité. Cela permet aux équipes de développement de concentrer leur énergie sur la satisfaction des demandes de fonctionnalités plutôt que sur la mécanique de la construction de systèmes. De plus, cette approche résout le problème redouté «ça marche sur mon ordinateur portable» où les changements de code se cassent lorsqu'ils sont combinés avec les contributions des autres membres de l'équipe. La création d'un système complet sur chaque soumission approuvée (par exemple, fusion avec la ligne de code de développement ou principale) permet de vérifier la couverture des tests unitaires, la détection précoce des violations de politique de sécurité, les échecs d'intégration et les collisions avec le code d'un autre développeur.

Contrôle de source [19659010] Le contrôle de source est un aspect clé de l'automatisation CI. La sélection de l'outil SCM approprié facilite l'intégration avec le flux de travail du pipeline de sorte que les événements clés peuvent déclencher des activités de pipeline. Par exemple, un produit tel que BitBucket peut s'intégrer directement à Jenkins pour lancer le processus de génération de pipeline CI sur des événements spécifiques (comme une fusion de code ou une approbation de demande de tirage). En choisissant sélectivement ces événements au niveau du code, le pipeline CI peut être utilisé pour accélérer considérablement le développement.

Gestion de la construction

Beaucoup, sinon la plupart, des systèmes logiciels doivent être compilés, liés ou autrement convertis du code brut en un produit exécutable. Ces étapes incluent généralement la résolution des dépendances, telles que les composants tiers ou les bibliothèques. Le résultat final de la phase de construction est une «unité déployable» versionnée comme base du déploiement automatisé.

Test unitaire automatisé et développement piloté par les tests

Après la construction du système, il est courant dans les pipelines DevSecOps d'effectuer un certain niveau de test unitaire automatisé. Les équipes qui tirent parti du TTD (développement piloté par les tests) sont mieux à même de tirer parti des tests unitaires automatisés, étant donné que les tests unitaires sont les premiers artefacts de code créés pour une fonctionnalité donnée.

Sécurité et assurance de conformité

L'automatisation de la vérification de code sécurisée est une bonne pratique de base pour l'automatisation DevSecOps. Trois analyses automatisées sont effectuées pour chaque génération de CI: pratiques de code sécurisé, utilisation de composants tiers et tests de pénétration des applications. Les deux premiers scans sont souvent considérés comme des scans de code «statiques» car ils se réfèrent à la base de code avant la compilation. Le troisième test examine le produit final (comme une application Web) et vérifie la résistance contre les attaques courantes (par exemple, OWASP Top Ten vulnérabilités).

Continuous Deployment (CD)

Contrairement à CI, Continuous Deployment gère la livraison cohérente d'unités déployables dans les environnements cibles. Cet élément de l’automatisation DevSecOps gère les paramètres système, les détails de connexion, le chiffrement, les secrets et d’autres exigences de «temps d’exécution». L'outil de déploiement simplifie la gestion de ces valeurs.

Implémentation du référentiel

Tous les déploiements doivent être effectués à partir d'une unité déployable vérifiée. Cela permet de garantir que chaque promotion vers des environnements ultérieurs (par exemple, Dev to Test to Production) tire toujours parti des mêmes produits de construction. L'utilisation d'un référentiel est donc essentielle pour garantir le contrôle de version de ces unités déployables. De plus, les référentiels peuvent gérer des bibliothèques, des composants et d'autres dépendances au moment de la construction.

Infrastructure en tant que code

L'un des objectifs de l'automatisation DevSecOps est de réduire ou d'éliminer les tâches répétitives du pipeline de livraison. L'environnement cible pour une génération de système particulière doit toujours être dans un état prévisible. Cela évite les problèmes de déploiement chronophages lorsqu'une configuration d'environnement dérive d'une autre. En codant le système attendu, les composants installés secondaires et la configuration du réseau, cette uniformité peut être appliquée au moment du déploiement.

Gestion de la configuration

Parallèlement à l'établissement et au maintien d'une configuration d'environnement cible, les paramètres système associés et les informations de connexion doivent être entretenu. Comme indiqué ci-dessus, c'est le but des outils de configuration et de gestion des secrets. Le découplage des informations de configuration de l'environnement de l'unité déployable réduit considérablement la probabilité d'une erreur de déploiement interrompant l'automatisation.

Conformité continue (CC) et gouvernance

La section finale de l'architecture de référence DevSecOps couvre la conformité et la gouvernance. Pour beaucoup, la conformité aux exigences réglementaires, de l'industrie ou des clients exige que l'organisation consacre un temps précieux à vérifier et approuver le respect de la politique de sécurité. Dans la mesure du possible, cette fonction d'audit de conformité doit être automatisée.

Audit de conformité automatisé

Il est important de vérifier l'état de configuration de tout environnement cible pour garantir la cohérence des serveurs, des réseaux et des points d'accès aux données. De même, le renforcement de la sécurité des systèmes d'exploitation, la politique / restrictions réseau, la configuration du pare-feu / équilibreur de charge et d'autres aspects de la sécurité du système doivent être vérifiés avant le déploiement du système. Ceci est particulièrement nécessaire pour le déploiement de la production, mais ne doit pas être négligé pour les environnements inférieurs.

Coordination des versions

Comme discuté dans mon article sur Coordination des versions un mauvais processus de libération du système peut dégrader considérablement les avantages gagné en automatisant les opérations CI et CD. Les performances de livraison attendues sont assurées grâce à un processus agile associé à l'automatisation DevSecOps.

Surveillance et contrôle de l'environnement

La prise en charge des opérations et de la surveillance continue du système est le dernier aspect de l'architecture de référence DevSecOps. Cela permettra à l'équipe d'exploitation de mieux répondre aux problèmes avant qu'ils ne surviennent.

Conclusion

L'implémentation de DevSecOps est un événement non trivial. Plusieurs outils, processus et politiques intégrés doivent être alignés. Tirer parti d'une architecture de référence cohérente garantira que tous les aspects de l'automatisation fonctionnent en étroite collaboration. Dans cet article, j'ai détaillé une telle architecture.