Accélérez votre cycle de développement logiciel grâce au DevSecOps

L'approche DevOps a été une réponse à la complexité croissante du développement logiciel, mais la multiplication des acteurs, des technologies et des environnements entraîne des exigences supplémentaires en matière de sécurité. Le passage au DevSecOps permettra non seulement de répondre à ces exigences, mais aussi d'accélérer le cycle de développement logiciel.

Au fur et à mesure que les projets de développement mûrissent, davantage de développeurs s'y ajoutent, la base de code devient plus importante et l'architecture plus complexe ; par conséquent, le cycle de développement logiciel (SDLC) ralentit. C'est pourquoi les approches agiles, microservices et DevOps sont apparues. Elles ne sont pas apparues sans raison mais parce qu'il y avait un problème spécifique à résoudre. Leur solution : séparer les grandes équipes en petites équipes et les monolithes en composants à granularité plus fine. 

Mais cette granularité et cette multiplicité d'équipes, d'environnements de travail, de technologies, de services et de référentiels rendent la sécurité encore plus complexe. En fait, vous êtes désormais confronté à de multiples SDLC, et vous ne voulez pas que le gain obtenu en termes de vélocité soit annulé par des problèmes de sécurité. Vous voulez un processus qui fonctionne, et de préférence, un processus qui fonctionne rapidement.  

C'est ce que DevSecOps défend. L'intégration de la sécurité au DevOps accélère réellement le SDLC. Voici pourquoi et comment.

Pendant la phase de planification

La phase de planification est essentielle car elle répond à des questions importantes au moment où la plupart des décisions architecturales sont prises. Certaines de ces décisions concernent le contrôle d'accès, l'infrastructure réseau et la sécurité des données. Pour chacune d'entre elles, l'ajout d'une automatisation, et donc d'une sécurité, permet une réplication rapide.

Pour le contrôle d'accès, vous pouvez exploiter les outils Infrastructure as Code (IaC) (Terraform par exemple) dans lesquels vous pouvez facilement définir différents groupes, rôles et permissions avec du code. En ajoutant divers plugins, vous pouvez même utiliser votre outil IaC pour gérer vos utilisateurs sur d'autres plateformes, comme dans GitHub. Lorsque vous avez défini tous les groupes, rôles et autorisations dans le code, vous n'êtes plus qu'à un commit des mises à jour de contrôle d'accès.

Si vous devez intégrer un nouveau membre à l'équipe non seulement dans un groupe AWS spécifique mais aussi dans un groupe GitHub, au lieu de le faire manuellement à deux endroits, vous pouvez le faire "as code" avec un minimum de modifications.

La complexité des organisations et la nécessité d'une meilleure sécurité impliquent davantage de contrôles d'accès basés sur les rôles, mais des outils d'automatisation existent et ils sont également moins sujets aux erreurs.

En ce qui concerne l'infrastructure réseau, vous pourrez utiliser l'IaC mais vous devrez également ajouter une couche de sécurité par-dessus, car comme tout ce qui est codé, il peut contenir des erreurs.

Vous pouvez utiliser tfsec et terrascan sur Terraform. Cela analysera votre code de manière statique et, sur la base de règles prédéfinies, générera des alertes et vous donnera des conseils pour améliorer votre sécurité. Si vous préférez CloudFormation, utilisez cfnlint, qui vous permet même de définir vos propres règles de sécurité.

Lorsque votre infrastructure est prête, le prochain élément important auquel il faut penser concerne vos données. Vous devez mettre en place le cryptage des données pour vous assurer qu'elles sont stockées en toute sécurité au repos. Vous devez également ajouter une couche de sécurité de transport afin de sécuriser le trafic en transit vers les bases de données. Outre les outils d'analyse de code statique et les services prêts à l'emploi mentionnés précédemment, vous pouvez même automatiser votre propre pipeline. Ceci est très utile lorsque vous avez plusieurs équipes agiles. 

Prenons l'exemple des buckets. Vous pourriez construire une solution générique où l'événement S3 déclenche une fonction serverless qui vérifie la permission du bucket. Si une politique est violée, corrigez-la immédiatement avec du code, puis informez le propriétaire automatiquement - c'est la méthode DevSecOps.

Passons au développement

Pendant la phase de développement, vous devez aborder trois sujets majeurs liés à la sécurité : La sécurité du code, la sécurité de l'intégration continue (IC) et la sécurité des images de conteneurs.

La sécurité du  code source doit aborder les questions relatives au contrôle d'accès au dépôt, en tenant compte du principe du moindre privilège, mais aussi en vérifiant qu'aucun dépôt n'est rendu public par accident ou qu'il ne contient pas d'éléments sensibles tels que des secrets.

Avec une configuration multi-équipes, agile et microservices, vous avez besoin d'automatisation pour éviter les tâches fastidieuses et sujettes aux erreurs, mais aussi pour éviter que votre SDLC ne soit vraiment ralenti. Nous avons déjà mentionné l'automatisation de la gestion des utilisateurs git, il existe également un certain nombre d'outils pour l'analyse statique du code et la détection des secrets. Vous pouvez même inclure cette détection dans votre pipeline de CI et l'intégrer à votre workflow d'alerte pour éliminer le risque dès l'origine.

La sécurité de la CI peut parfois être négligée, c’est pourtant un élément très important, car si votre CI n'est pas configurée correctement, elle peut générer des fuites de données. L'accès à votre CI doit être contrôlé pour donner les permissions et les droits d'accès appropriés. Faire cela manuellement aura un impact certain sur la vélocité de votre SDLC, d'où la nécessité d'automatiser. Vous pouvez intégrer votre CI à votre Git ou au SSO de votre entreprise pour l'authentification. Pour l'autorisation, vous pouvez vous appuyer sur les informations relatives aux groupes fournies par ces services SSO.

Les secrets sont également un sujet de sécurité pour les CI. Les CI modernes vous permettent de stocker des secrets au niveau d'un projet. Une fois configurée, vous pouvez l'utiliser directement dans le build sans mettre les données sensibles en clair. Même si vous essayez d'imprimer la variable contenant les données sensibles, elle ne s'affichera pas. Par exemple, pour utiliser les secrets directement à partir d'un pipeline Jenkins, vous pouvez stocker vos secrets dans un cluster Kubernetes et utiliser Kubernetes Credentials Provider ou HashiCorp Vault Plugin.

Passons maintenant aux conteneurs. Bien que les conteneurs aient simplifié le déploiement, la mise à l'échelle et le basculement, ils ont leurs propres points d’attention. Si l'image présente des vulnérabilités connues, vos conteneurs peuvent être exploités et l'intégrité de la machine, voire du système entier, peut être compromise. L'automatisation est encore une fois la solution à privilégier pour s'assurer que les images que vous avez créées ne contiennent pas de vulnérabilités. Certains outils en ligne de commande, comme Trivy, peuvent être facilement intégrés à vos pipelines de CI.

L'automatisation réduira considérablement vos frais d'exploitation. Plus de gestion des machines (qu'elles soient physiques ou virtuelles), plus de gestion des configurations, plus de correctifs, tout est automatisé, vous avez moins de travail - tout cela signifie que votre SDLC est non seulement plus sûr mais aussi plus rapide.

Ensuite, l'intégration et le déploiement

Kubernetes (orchestration de conteneurs) est la solution actuelle pour rationaliser l'intégration et le déploiement dans notre monde agile. Mais Kubernetes est un système complexe qui s'accompagne de ses propres défis en matière de sécurité, le plus important étant le secret. 

La pire chose à faire est de définir des secrets dans des fichiers YAML et de les stocker dans des dépôts git. Vous pourriez utiliser les secrets de Kubernetes comme source unique de vérité, mais qu'en est-il des secrets créés par des personnes qui n'ont pas besoin d'accéder à Kubernetes ? C'est là qu'un gestionnaire de secrets est un bon choix : il agit comme une source unique de vérité pour stocker vos données sensibles. Vous obtiendrez un processus automatisé qui élimine le travail manuel mais garantit également la sécurité et la rapidité.

Et enfin, la maintenance

Les playbooks de réponse aux incidents sont un élément crucial du DevSecOps. Les playbooks sont un ensemble de processus généralisés et résumés qui fournissent une manière cohérente de traiter les problèmes pour une réponse et une résolution plus rapides. Les leçons tirées de chaque incident font également partie du playbook, qu'il s'agisse d'un problème de sécurité ou d'une nouvelle vulnérabilité. 

Le contenu peut être très varié, allant des manuels d'exécution aux listes de contrôle, en passant par les modèles, les exercices de formation, les scénarios d'attaque de sécurité et les exercices de simulation. L'objectif est simple : disposer d'un ensemble de politiques, de processus et de pratiques permettant de réagir rapidement aux pannes non planifiées et de les résoudre, ce qui aidera les équipes à résoudre les problèmes plus rapidement et à réduire la taille de l'impact.

En conclusion

Nous n'avons couvert qu'une partie des capacités d'automatisation de la sécurité, mais vous voyez déjà que l'ajout de la sécurité (automatisée) dans le DevOps a effectivement un impact positif sur la vélocité globale du SDLC et, bien sûr, sur son niveau de sécurité. Alors allez-y, passez au DevSecOps !