Gouvernance de bout en bout, du DevOps à Azure

Cet article explique comment gérer et implémenter soigneusement des pratiques de gouvernance saines pour votre équipe, telles que les autorisations de contrôle d’accès en fonction du rôle.

Il ne suffit pas de planifier et d’implémenter un modèle de contrôle d’accès en fonction du rôle (RBAC) Azure pour les modèles Azure Resource Manager (modèles ARM) afin de limiter l’accès via le portail Azure et Azure CLI.

Si ce modèle n’est pas mis en miroir pour l’automation du DevOps, votre organisation risque de laisser ouverte une porte dérobée de sécurité. Prenons l’exemple d’un développeur qui n’a pas d’accès via des modèles ARM, mais qui dispose toujours d’autorisations suffisantes pour modifier le code d’application ou l’infrastructure en tant que code et déclencher un flux de travail d’automation. Via le DevOps, le développeur peut accéder indirectement et apporter des modifications destructrices à vos modèles ARM.

Plan de gestion des identités unique avec les groupes Microsoft Entra

La première étape consiste à intégrer Microsoft Entra ID pour utiliser la meilleure pratique d’authentification unique par gestion des identités.

Si vous n’utilisez pas un produit d’intégration continue interne Azure tel qu’Azure DevOps, vérifiez si votre fournisseur offre l’intégration Microsoft Entra.

La deuxième étape consiste à utiliser des groupes Microsoft Entra, les mêmes que ceux que vous utilisez déjà pour votre modèle RBAC des modèles ARM. La meilleure pratique consiste à attribuer des rôles à des groupes de Microsoft Entra, non à des individus. Pour créer un modèle de gouvernance de bout en bout, vous devez suivre cette étape pour les modèles ARM et le DevOps.

Azure DevOps offre une intégration étroite avec Microsoft Entra ID, incluant l’appartenance à des groupes Microsoft Entra, ce qui facilite l’application d’attributions de rôles au même groupe Microsoft Entra.

Le diagramme suivant illustre la façon dont Microsoft Entra est utilisé comme plan de gestion des identités uniques. Dans les modèles ARM et dans nos outils de DevOps (Azure DevOps dans cet exemple), nous devons uniquement gérer les attributions de rôles, et non les appartenances qui doivent être gérées dans Microsoft Entra. Notez que les noms de ressources respectent les conventions d’affectation de nomset les abréviations recommandées pour les ressources Azure.

Exemple de scénario : supprimer l’accès d’un prestataire en une étape, appartenance à Microsoft Entra

Pour rendre la gouvernance de bout en bout concrète, examinons ses avantages avec un exemple de scénario.

Si vous utilisez Microsoft Entra ID comme plan de gestion des identités uniques, vous pouvez supprimer l’accès d’un développeur à vos ressources Azure en une action, en ajustant ses appartenances à des groupes Microsoft Entra. Par exemple, si l’accès d’un prestataire doit être révoqué après l’achèvement d’un projet, lorsque vous supprimez l’appartenance du prestataire aux groupes Microsoft Entra concernés, l’accès aux modèles ARM et à Azure DevOps est supprimé.

Modèle de RBAC en miroir avec attributions de rôles

S’il est bien planifié, le modèle de RBAC dans vos outils d’intégration reflétera fidèlement votre modèle de RBAC Azure. Bien que les exemples de noms de groupe Microsoft Entra dans le diagramme ci-dessus impliquent des règles de sécurité, l’appartenance seule n’applique pas de sécurité. N’oubliez pas que le RBAC est une combinaison de principaux, de définitions et d’étendues, qui ne prend effet qu’une fois l’attribution de rôle créée.

• Le diagramme illustre l’attribution de rôle pour un seul groupe Microsoft Entra, contoso-admins-group.
• Ce groupe Microsoft Entra se voit attribuer le rôle Propriétaire pour les modèles ARM Azure au niveau de plusieurs étendues d’abonnement :
  • Abonnement contoso-dev-sub
  • Abonnement contoso-prod-sub
• Le groupe contoso-admins-group est ajouté au groupe Administrateurs de projet pour Azure DevOps au niveau d’une étendue de projet unique .

Le groupe Microsoft Entra a des rôles privilégiés similaires pour les modèles ARM et DevOps. Suivant cette logique, si un groupe de développeurs est affecté au rôle Contributeur pour les modèles ARM, nous ne nous attendons pas à ce que ces développeurs appartiennent au groupe Administrateurs de projet pour le DevOps.

Maintenant que vous comprenez la nécessité de sécuriser les modèles ARM et les flux de travail de DevOps, vous devriez suivre les étapes suivantes :

• Passer en revue votre modèle RBAC et réfléchir à la façon dont les rôles et les responsabilités que vous avez définis pour les modèles ARM correspondent à votre flux de travail de CI/CD.
• Passez en revue les solutions de gestion des identités de votre plateforme d’intégration continue et intégrez Microsoft Entra ID. Dans l’idéal, vous souhaitez inclure l’appartenance au groupe Microsoft Entra.
• Passer en revue les rôles et les niveaux d’accès proposés par vos outils d’intégration continue et les comparer à votre modèle de RBAC Azure. Les rôles et les niveaux d’accès ne sont pas mappés un à un. Vérifiez votre configuration. Si un développeur n’a pas accès aux modèles ARM, il ne doit pas avoir accès au DevOps. Dans l’exemple le plus simple, un développeur qui n’a pas d’autorisations d’accès en écriture aux ressources de production ne doit pas avoir d’accès direct pour déclencher des exécutions de pipeline de production.

Pour en savoir plus sur la conception de la gouvernance et les autorisations, consultez les ressources suivantes :

• Méthode recommandée pour l’octroi et la restriction des autorisations
• Autorisations et accès par défaut pour Azure DevOps
• Gestion de l’accès des personnes à votre organisation avec des rôles

Étapes suivantes

Maintenant que vous comprenez la nécessité de sécuriser les modèles ARM et les flux de travail de DevOps, découvrez comment gérer les secrets de manière sécurisée.