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.

Conditions préalables

Une fois que vous avez choisi les modèles de zone d’atterrissage Azure à déployer, clonez-les dans votre propre référentiel. Configurez les 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ôle et la gestion du cycle de vie des identités. Pour plus d'informations, voir Connexion de votre organisation à Microsoft Entra ID. Si vous utilisez GitHub, envisagez d’intégrer GitHub Enterprise à l’ID Microsoft Entra.

Considérations générales relatives à la conception

Nous vous recommandons de maintenir un contrôle étroit des administrateurs et des groupes de comptes de service sur l’ID Microsoft Entra et votre outil DevOps. Envisagez d’implémenter le principe du privilège minimum pour toutes vos attributions de rôles.

Par exemple, votre organisation peut avoir une équipe Platform ou Cloud Excellence qui gère des modèles Azure Resource Manager pour vos zones d’atterrissage Azure. Affectez des utilisateurs sur cette équipe à un groupe de sécurité dans Microsoft Entra ID, en supposant que vous l’utilisez en tant que 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 l’ID Microsoft Entra et vice versa. Cette approche réduit la menace du mouvement latéral. Si un administrateur de Microsoft Entra ID est compromis, l’attaquant ne pourra pas accéder facilement 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. Pour plus d’informations, consultez les 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,du projet ou de l’objet. Pour intégrer un fournisseur d’identité tel que Microsoft Entra ID, envisagez de créer des stratégies d’accès conditionnel pour appliquer l’authentification multifacteur pour tous les utilisateurs. Les stratégies autorisent l’accès à votre organisation Azure DevOps et des restrictions plus granulaires 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 doivent 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 valident et déploient ces derniers.

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 privilège minimum. Ces affectations peuvent être effectuées via la page Paramètres du projet indiquée ci-dessous.

Une autre meilleure pratique pour vos projets et organisations Azure DevOps consiste à désactiver l’héritage, le cas échéant. 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 à votre équipe Plateforme l’appartenance au groupe de sécurité Contributeur, 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 attribué 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 d’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, tels que l’utilisation incorrecte des autorisations.

Pour plus d’informations, consultez les ressources suivantes :

• Meilleures pratiques relatives à la sécurité Azure 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. Une fois que vous avez déplié le dépôt Azure Landing Zones et que vous l’intégrez à un fournisseur d’identité, tel que 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 l'équipe de la plateforme qui modifient et déploient les Landing Zones, un accès en écriture devrait suffire. Pour les responsables de projet ou les responsables Scrum de l’équipe, vous devrez peut-être leur attribuer le rôle de maintenance à 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 Plateforme pour le dépôt Azure Landing Zone que vous avez créé sur GitHub avec le groupe de sécurité correspondant de l'équipe Plateforme 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.

Étapes suivantes

Pour plus d’informations sur la gestion des rôles et des équipes dans GitHub, consultez les ressources suivantes :

• Rôles et niveaux de portée GitHub
• Comment gérer les autorisations GitHub après l’intégration à Identity Provider
• Gestion des autorisations avec GitHub Teams