Contrôle d’accès en fonction du rôle pour les outils DevOps
Lorsque vous déployez des solutions cloud pour vos déploiements d’infrastructure, la sécurité doit toujours être votre préoccupation la plus importante. Microsoft sécurise l’infrastructure cloud sous-jacente. Vous configurez la sécurité dans Azure DevOps ou GitHub.
Prérequis
Une fois que vous avez choisi les modèles de zone d’atterrissage Azure à déployer, clonez-les dans votre propre référentiel. Configurer des pipelines CI/CD. Pour GitHub et Azure DevOps, il existe plusieurs méthodes d’authentification disponibles, telles que les jetons d’accès personnels (PAT) et l’intégration à un fournisseur d’identité, comme Microsoft Entra ID. Pour plus d’informations, consultez Utiliser les jetons d’accès personnels.
Nous vous recommandons d’intégrer à Microsoft Entra ID pour utiliser toutes ses fonctionnalités. L’intégration permet de simplifier votre processus d’attribution de rôles et la gestion du cycle de vie des identités. Si vous souhaitez obtenir plus d’informations, consultez Connecter votre organisation à Microsoft Entra ID. Si vous utilisez GitHub, envisagez d’intégrer GitHub Enterprise à Microsoft Entra ID.
Considérations de conception générales
Nous vous recommandons de maintenir un contrôle étroit des administrateurs et des groupes de comptes de service dans Microsoft Entra ID et votre outil DevOps. Envisagez d’implémenter le principe du moindre privilège pour toutes vos attributions de rôles.
Par exemple, votre organisation peut avoir une équipe de plateforme ou d’excellence cloud qui gère des modèles Azure Resource Manager pour vos zones d’atterrissage Azure. Affectez des utilisateurs de cette équipe à un groupe de sécurité dans Microsoft Entra ID, en supposant que vous l’utilisez comme fournisseur d’identité. Attribuez des rôles à ce groupe de sécurité dans votre outil DevOps afin que ces utilisateurs puissent effectuer leurs tâches.
Pour tous les comptes d’administrateur ou hautement privilégiés dans Active Directory, nous vous recommandons de ne pas synchroniser les informations d’identification avec Microsoft Entra ID, et vice versa. Cette approche réduit la menace de mouvement latéral. Si un administrateur dans Microsoft Entra ID est compromis, l’attaquant ne pourra pas facilement accéder aux ressources cloud telles qu’Azure DevOps. Ce compte ne peut pas injecter de tâches malveillantes dans les pipelines CI/CD. Cette étape est particulièrement importante pour tous les utilisateurs auxquels des autorisations élevées ont été attribuées dans votre environnement DevOps, comme les administrateurs de build ou de projet/collection. Si vous souhaitez obtenir plus d’informations, consultez Meilleures pratiques de sécurité dans Microsoft Entra ID.
Considérations relatives à l’accès en fonction du rôle Azure DevOps
Gérez la sécurité dans Azure DevOps avec des groupes de sécurité, des stratégies et des paramètres au niveau de l’organisation/la collection, du projet ou de l’objet. Pour l’intégration à un fournisseur d’identité tel que Microsoft Entra ID, envisagez de créer des stratégies d’accès conditionnel afin d’appliquer l’authentification multifacteur pour tous les utilisateurs. Les stratégies autorisent l’accès à votre organisation Azure DevOps, avec des restrictions plus précises concernant l’adresse IP, le type d’appareil utilisé pour l’accès et la conformité des appareils.
Pour la plupart des membres de votre équipe de plateforme qui gèrent vos zones d’atterrissage Azure, le niveau d’accès De base et le groupe de sécurité Contributeur par défaut devraient fournir un accès suffisant. Le groupe de sécurité Contributeur leur permet de modifier les modèles de zone d’atterrissage Azure dans votre référentiel et les pipelines CI/CD qui les valident et les déploient.
Nous vous recommandons d’affecter votre équipe de plateforme au groupe de sécurité Contributeur au niveau du projet d’Azure DevOps. Cette approche suit le principe du moindre privilège. Ces affectations peuvent être effectuées via la page Paramètres du projet illustrée ci-dessous.
Une autre bonne pratique pour vos projets et organisations Azure DevOps consiste à désactiver l’héritage si possible. Les utilisateurs héritent des autorisations autorisées par leurs affectations de groupe de sécurité. En raison de la nature autorisée par défaut de l’héritage, des utilisateurs inattendus peuvent obtenir l’accès ou des autorisations.
Par exemple, si vous affectez l’appartenance au groupe de sécurité Contributeur à votre équipe de plateforme, vérifiez leurs autorisations sur le référentiel Zones d’atterrissage Azure. Vous devez avoir des stratégies de branche en place pour vérifier que le groupe de sécurité n’est pas autorisé à contourner ces stratégies pendant les demandes de tirage. Vérifiez ce paramètre sous Paramètres du projet>Référentiels.
Une fois que vous avez affecté des autorisations aux utilisateurs, passez régulièrement en revue les événements d’audit pour surveiller et réagir aux modèles d’utilisation inattendus par les administrateurs et autres utilisateurs. Commencez par créer un flux d’audit dans un espace de travail Log Analytics. Si votre espace de travail utilise Microsoft Sentinel, créez des règles d’analytique pour vous avertir des événements notables, comme l’utilisation incorrecte des autorisations.
Pour plus d’informations, consultez les ressources suivantes :
- Meilleures pratiques relatives à la sécurité DevOps
- Groupes et autorisations Azure DevOps
- Niveaux d’accès à Azure DevOps
Considérations relatives à l’accès en fonction du rôle GitHub
Si votre outil DevOps principal est GitHub, vous pouvez affecter aux utilisateurs l’accès aux ressources en leur accordant des rôles au niveau du référentiel, de l’équipe ou de l’organisation. Après avoir dupliqué (fork) le référentiel Zones d’atterrissage Azure et l’avoir intégré à un fournisseur d’identité, comme Microsoft Entra ID, envisagez de créer une équipe dans GitHub. Affectez à cette équipe l’accès en écriture à votre nouveau référentiel de zone d’atterrissage Azure. Pour la plupart des membres de votre équipe de plateforme, qui modifient et déploient les zones d’atterrissage, l’accès en écriture devrait être suffisant. Pour les responsables de projet ou les responsables Scrum de l’équipe, vous devrez peut-être leur attribuer le rôle de maintenance pour ce référentiel.
Nous vous recommandons de gérer toutes ces attributions de rôles via le fournisseur d’identité intégré. Par exemple, vous pouvez synchroniser l’équipe de plateforme pour le référentiel Zone d’atterrissage Azure que vous avez créé dans GitHub avec le groupe de sécurité d’équipe de plateforme correspondant dans Microsoft Entra ID. Ensuite, lorsque vous ajoutez ou supprimez des membres au groupe de sécurité Microsoft Entra, ces modifications sont reflétées dans vos attributions de rôles GitHub Enterprise Cloud.
Remarque
Une fois que vous avez connecté une équipe GitHub spécifique à un fournisseur d’identité intégré, vous êtes limité à la gestion de l’appartenance à l’équipe via ce dernier.
Étapes suivantes
Pour plus d’informations sur la gestion des rôles et des équipes dans GitHub, consultez les ressources suivantes :