Dans ce billet de blog, je souhaiterais parler de la sécurité des comptes de services qui sont utilisés pour effectuer des actions automatisées dans la plateforme infonuagique Microsoft Azure.
Un Service Principal est une entité de sécurité dans Azure utilisée par une application, un service ou un objet de sécurité pour s’authentifier auprès de Microsoft Entra ID et accéder à des ressources. Bien qu’ils soient essentiels pour faciliter les déploiements et la gestion des ressources, il est crucial de comprendre les risques potentiels qu’ils présentent et de mettre en place des mesures appropriées pour renforcer la sécurité. Dans ce billet, nous allons explorer l’utilité des Service Principals pour l’automatisation, les risques d’usurpation de leurs privilèges, ainsi que des conseils sur la manière de réduire ces risques.
Comprendre l’utilité des Service Principals Azure
Les Service Principals Azure jouent un rôle central dans l’automatisation des tâches dans Azure. Ils permettent aux applications, aux outils et aux pipelines d’accéder aux ressources Azure de manière sécurisée sans avoir à stocker de manière permanente les informations d’identification. Cela simplifie les processus de déploiement, améliore l’efficacité opérationnelle et renforce la sécurité en réduisant l’exposition des informations d’identification sensibles.
Risques d’usurpation des privilèges dans les pipelines
Cependant, l’utilisation de Service Principals dans les pipelines peut également présenter des risques de sécurité. L’usurpation des privilèges est l’un des principaux risques auxquels les organisations sont confrontées. Si un service principal est compromis ou utilisé de manière inappropriée, cela pourrait permettre à des acteurs malveillants d’exécuter des actions non autorisées, telles que la modification ou la suppression de ressources critiques, entraînant ainsi des perturbations importantes dans l’environnement Azure.
Les Service Principals sont couramment créés avec le rôle contributeur dans Azure, qui est un privilège élevé permettant de créer, modifier et supprimer n’importe quelle ressource dans Azure.
D’ailleurs, dans Azure DevOps, lorsque vous créez un service connection avec l’approche « automatic » qui est celle recommandée par l’outil, un Service Principal est automatiquement créé dans Microsoft Entra ID et le rôle RBAC Contributeur est automatiquement donné sur l’abonnement Azure.
Ces Service Principals, permettant de presque tout faire dans Azure, ne sont pas suffisamment protégés pour éviter qu’une personne ayant accès à Azure DevOps ne puisse usurper son identité à d’autres fins.
Conseils pour réduire les risques d’utilisation non autorisée
Pour réduire les risques d’utilisation non autorisée des Service Principals dans les pipelines, il est essentiel de mettre en place des mesures de sécurité robustes. Voici quelques conseils pratiques à cet effet :
- Gestion des accès privilégiés : Mettez en œuvre des contrôles stricts sur l’accès aux Service Principals, en limitant les autorisations aux seules actions nécessaires pour chaque tâche ou processus automatisés.
- Surveillance continue : Mettez en place des mécanismes de surveillance en temps réel pour détecter toute activité suspecte ou anormale liée à l’utilisation des Services Principals.
- Principe du moindre privilège : Appliquez le principe du moindre privilège en accordant uniquement les autorisations minimales requises pour accomplir une tâche spécifique. Évitez de donner des privilèges excessifs aux Service Principals.
L’une de mes recommandations est de séparer les Service Principals applicatifs des Service Principals d’IaC.
Les Service Principals de déploiement applicatifs devraient avoir uniquement les privilèges permettant d’écrire les fichiers des artefacts générés dans le service d’exécution applicatif : App Service, Azure Functions, etc. Ce service principal est accessible à un large panel d’utilisateur qui ont besoin simplement de déployer du code et rien d’autre.
Le Service Principals d’IaC, quant à lui, aura besoin de plus de privilèges pour gérer les ressources. Des contrôles pourront être mis en place pour s’assurer qu’il est utilisé uniquement par les équipes d’infrastructure.
Dans un prochain billet de blog, je vais présenter les approches pouvant être mises en place pour protéger les Service Principals d’IaC dans Azure DevOps.
En conclusion, bien que les Services Principals Azure offrent de nombreux avantages pour l’automatisation des opérations dans Azure, ils présentent également des risques de sécurité. En mettant en place des mesures de sécurité appropriées, en suivant les bonnes pratiques et en dissociant les Service Principals selon les besoins, vous pouvez maximiser la sécurité de vos pipelines tout en bénéficiant des avantages de l’automatisation dans Azure.