Gouvernance de bout en bout dans Azure lors de l’utilisation de CI/CD

Lors du développement d’un modèle de gouvernance pour votre organisation, il est important de se rappeler que Azure Resource Manager n’est qu’un moyen de gérer les ressources. L'automatisation avec Azure DevOps, ainsi que l'intégration continue et la livraison continue (CI/CD), peuvent constituer une porte dérobée involontaire en matière de sécurité si elles ne sont pas correctement sécurisées. Ces ressources doivent être protégées en mettant en miroir le modèle de contrôle d’accès en fonction du rôle (RBAC) utilisé pour Resource Manager.

Le concept de gouvernance de bout en bout est indépendant du fournisseur. L’implémentation décrite ici utilise Azure DevOps, mais les alternatives sont également brièvement mentionnées.

Cas d’usage potentiels

Cette implémentation de référence et cette démonstration sont open source et destinées à être utilisées comme outil d’enseignement pour les organisations qui sont nouvelles de DevOps et doivent créer un modèle de gouvernance pour le déploiement sur Azure. Lisez attentivement ce scénario pour comprendre les décisions relatives au modèle utilisé dans cet exemple de référentiel.

Tout modèle de gouvernance doit être lié aux règles métier de l’organisation, qui sont reflétées dans toute implémentation technique des contrôles d’accès. Cet exemple de modèle utilise une entreprise fictive avec le scénario courant suivant (avec les exigences métier) :

• Groupes Microsoft Entra qui s'alignent sur les domaines métier et les modèles d'autorisations
  L’organisation possède de nombreux domaines métier verticaux, tels que les « fruits » et les « légumes », qui fonctionnent en grande partie indépendamment. Dans chaque domaine métier, il existe deux niveaux ou privilèges mappés à des groupes Microsoft Entra distincts *-admins ou *-devs. Cela permet aux développeurs d’être ciblés lors de la configuration des autorisations dans le cloud.

• environnements de déploiement
  Chaque équipe a deux environnements :

  • Production. Seuls les administrateurs disposent de privilèges élevés.
  • Hors production. Tous les développeurs ont des privilèges élevés (pour encourager l’expérimentation et l’innovation).

• objectifs de l'automatisation
  Chaque application doit implémenter Azure DevOps non seulement pour l’intégration continue (CI), mais également pour le déploiement continu (CD). Par exemple, les déploiements peuvent être déclenchés automatiquement par des modifications apportées au référentiel Git.

• Parcours cloud jusqu’à présent
  L’organisation a commencé avec un modèle de projet isolé pour accélérer le parcours vers le cloud. Mais maintenant, ils explorent des options pour briser les silos et encourager la collaboration en créant les projets de « collaboration » et de « supermarché ».

Ce diagramme simplifié montre comment les branches d’un référentiel Git correspondent aux environnements de développement, de mise en scène et de production.

Télécharger un SVG de ce diagramme.

Architecture

Ce diagramme montre comment la liaison entre Resource Manager et CI/CD et Microsoft Entra ID est la clé de l’utilisation d’un modèle de gouvernance de bout en bout.

Télécharger un SVG de cette architecture.

Flux de travail

La numérotation reflète l’ordre dans lequel les administrateurs informatiques et les architectes d’entreprise pensent et configurent leurs ressources cloud.

1. Microsoft Entra ID

   Nous intégrons Azure DevOps à Microsoft Entra ID afin d’avoir un plan unique pour l’identité. Cela signifie qu’un développeur utilise le même compte Microsoft Entra pour Azure DevOps et Resource Manager. Les utilisateurs ne sont pas ajoutés individuellement. Au lieu de cela, l’appartenance est attribuée par les groupes Microsoft Entra afin que nous puissions supprimer l’accès d’un développeur aux ressources en une seule étape, en supprimant ses appartenances aux groupes Microsoft Entra. Pour chaque domaine, nous créons :

   • Groupes Microsoft Entra. Deux groupes par domaine (décrits plus loin à l’étape 4 et 5 plus loin dans cet article).
   • Des principaux de service. Un principal de service explicite par environnement.

2. environnement de production

   Pour simplifier le déploiement, cette implémentation de référence utilise un groupe de ressources pour représenter l’environnement de production. Dans la pratique, vous devez utiliser un autre abonnement.

   L’accès privilégié à cet environnement est limité aux administrateurs uniquement.

3. environnement de développement

   Pour simplifier le déploiement, cette implémentation de référence utilise un groupe de ressources pour représenter l’environnement de développement. Dans la pratique, vous devez utiliser un autre abonnement.

4. Attributions de rôles dans Resource Manager

   Bien que nos noms de groupe Microsoft Entra impliquent un rôle, les contrôles d’accès ne sont pas appliqués tant qu’une attribution de rôle n’est pas configurée. Cela attribue un rôle à un principal Microsoft Entra pour un périmètre spécifique. Par exemple, les développeurs ont le rôle Contributeur sur l’environnement de production.

   Microsoft Entra principal	Environnement de développement (Resource Manager)	Environnement de production (Resource Manager)
   veggies-devs-group	Propriétaire	Lecteur
   veggies-admins-group	Propriétaire	Propriétaire
   veggies-ci-dev-sp	rôle personnalisé *	–
   veggies-ci-prod-sp	–	rôle personnalisé *

   * Pour simplifier le déploiement, cette implémentation de référence affecte le rôle Owner aux principaux de service. Toutefois, en production, vous devez créer un rôle personnalisé qui empêche un principal de service de supprimer les verrous de gestion que vous avez placés sur vos ressources. Cela permet de protéger les ressources contre les dommages accidentels, tels que la suppression de la base de données.

   Pour comprendre le raisonnement derrière les attributions de rôles individuelles, consultez la section considérations plus loin dans cet article.

5. Assignations de groupes de sécurité dans Azure DevOps

   Les groupes de sécurité fonctionnent comme les rôles dans Resource Manager. Tirez parti des rôles intégrés et définissez par défaut le rôle de Contributeur pour les développeurs. Les administrateurs sont affectés au groupe de sécurité Administrateur de projet pour obtenir des autorisations élevées, ce qui leur permet de configurer des autorisations de sécurité.

   Notez qu’Azure DevOps et Resource Manager ont des modèles d’autorisations différents :

   • Azure Resource Manager utilise un modèle d’autorisations additives.
   • Azure DevOps utilise un modèle de permissions minimales.

   Pour cette raison, l’appartenance aux groupes -admins et -devs doit être mutuellement exclusive. Dans le cas contraire, les personnes concernées auraient moins d’accès que prévu dans Azure DevOps.

   Nom du groupe	Rôle Resource Manager	Rôle Azure DevOps
   fruits-all	–	–
   fruits-devs	Contributeur	Contributeur
   fruits-admins	Propriétaire	Administrateurs de projet
   veggies-all	–	–
   veggies-devs	Contributeur	Contributeur
   veggies-admins	Propriétaire	Administrateurs de projet
   infra-all	–	–
   infra-devs	Contributeur	Contributeur
   infra-admins	Propriétaire	Administrateurs de projet

   Dans un scénario de collaboration limitée, comme l’équipe fruits invitant l’équipe veggies à collaborer sur un référentiel unique, le groupe veggies-all serait utilisé.

   Pour comprendre le raisonnement derrière les attributions de rôles individuelles, reportez-vous à la section considérations plus loin dans cet article.

6. Connexions de service

   Dans Azure DevOps, une connexion de service est un wrapper générique autour d’une information d’identification. Nous créons une connexion de service qui contient l’ID client du principal du service et la clé secrète client. Les administrateurs de projet peuvent configurer l’accès à cette ressource protégée si nécessaire, par exemple lorsque vous avez besoin d’une approbation humaine avant le déploiement. Cette architecture de référence a deux protections minimales sur la connexion de service :

   • Les administrateurs doivent configurer les autorisations de pipeline pour contrôler les pipelines qui peuvent accéder aux identifiants.
   • Les administrateurs doivent également configurer une vérification de contrôle de branche afin que seuls les pipelines s’exécutant dans le contexte de la branche production puissent utiliser le prod-connection.

7. Dépôts Git

   Étant donné que nos connexions de service sont liées à des branches via des contrôles de branche , il est essentiel de configurer les autorisations sur les référentiels Git et d’appliquer des stratégies de branche . En plus d’exiger que les builds CI réussissent, nous exigeons également que les pull requests aient au moins deux approbateurs.

Composants

• Azure DevOps
• Microsoft Entra ID
• Gestionnaire de Ressources Azure
• Azure Repos
• Azure Pipelines

Alternatives

Le concept de gouvernance de bout en bout est indépendant du fournisseur. Bien que cet article se concentre sur Azure DevOps, Azure DevOps Server peut être utilisé comme substitut local. Vous pouvez également utiliser un ensemble de technologies pour un pipeline de développement CI/CD open source à l’aide d’options telles que Jenkins et GitLab.

Azure Repos et GitHub sont des plateformes conçues pour utiliser le système de contrôle de version Git open source. Bien que leurs ensembles de fonctionnalités soient légèrement différents, les deux peuvent être intégrés dans des modèles de gouvernance globale pour CI/CD. GitLab est une autre plateforme basée sur Git qui fournit des fonctionnalités CI/CD robustes.

Ce scénario utilise Terraform comme outil IaC (Infrastructure as Code). Les alternatives incluent Jenkins, Ansibleet Chef.

Considérations

Pour obtenir une gouvernance de bout en bout dans Azure, il est important de comprendre le profil de sécurité et d’autorisations du chemin d’accès de l’ordinateur du développeur en production. Le diagramme suivant illustre un flux de travail CI/CD de référence avec Azure DevOps. L’icône de verrouillage rouge indique les autorisations de sécurité qui doivent être configurées par l’utilisateur. La configuration ou la configuration incorrecte des autorisations laisse vos charges de travail vulnérables.

diagramme
Télécharger un SVG de ce flux de travail.

Pour sécuriser correctement vos charges de travail, vous devez utiliser une combinaison de configurations d’autorisations de sécurité et de vérifications humaines dans votre workflow. Il est important que n’importe quel modèle RBAC doit également s’étendre aux pipelines et au code. Celles-ci s’exécutent souvent avec des identités privilégiées et détruisent vos charges de travail si on leur demande de le faire. Pour éviter que cela ne se produise, vous devez configurer des stratégies de branche sur votre dépôt afin d’exiger une approbation humaine avant d’accepter des modifications qui déclenchent des pipelines d’automatisation.

Les concepts et questions suivants sont importants à prendre en compte lors de la conception d’un modèle de gouvernance. Gardez à l’esprit les cas d’usage potentiels de cet exemple d’organisation.

1. Protéger vos environnements avec des stratégies de branche

Étant donné que votre code source définit et déclenche des déploiements, votre première ligne de défense consiste à sécuriser votre référentiel de gestion du code source (SCM). Dans la pratique, cela est réalisé en utilisant le flux de travail pull request avec les politiques de branche , qui définissent les vérifications et les exigences avant que le code ne puisse être accepté.

Lors de la planification de votre modèle de gouvernance de bout en bout, les utilisateurs privilégiés (veggies-admins) sont responsables de la configuration de la protection des branches. Les vérifications courantes de protection des branches utilisées pour sécuriser vos déploiements sont les suivantes :

• Exiger la réussite de la build CI. Utile pour établir la qualité du code de base, comme le linting du code, les tests unitaires et même les vérifications de sécurité telles que les analyses d’informations d’identification et antivirus.

• Exiger une révision par les pairs Faire vérifier par une autre personne que le code fonctionne comme prévu. Soyez prudent lorsque des modifications sont apportées au code de pipeline. Combinez avec des builds d’intégration continue pour rendre les révisions par des pairs moins fastidieuses.

Que se passe-t-il si un développeur tente d’envoyer directement en production ?

N’oubliez pas que Git est un système SCM distribué. Un développeur peut effectuer un commit directement dans sa branche production locale. Toutefois, lorsque Git est correctement configuré, une telle transmission push est automatiquement rejetée par le serveur Git. Par exemple:

remote: Resolving deltas: 100% (3/3), completed with 3 local objects.
remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: Required status check "continuous-integration" is expected.
To https://github.com/Azure/devops-governance
 ! [remote rejected] main -> main (protected branch hook declined)
error: failed to push some refs to 'https://github.com/Azure/devops-governance'

Notez que le flux de travail dans l’exemple est indépendant du fournisseur. Les fonctionnalités de protection des pull requests et des branches sont disponibles auprès de plusieurs fournisseurs SCM, notamment Azure Repos, GitHubet GitLab.

Une fois le code accepté dans une branche protégée, la couche suivante des contrôles d’accès sera appliquée par le serveur de build (par exemple, Azure Pipelines).

2. Quel est l’accès dont ont besoin les entités de sécurité ?

Dans Azure, un principal de sécurité peut être soit un principal d’utilisateur, soit un principal headless, tel qu’un principal de service ou une identité managée. Dans tous les environnements, les acteurs de sécurité doivent suivre le principe de privilège le plus restreint possible. Bien que les entités de sécurité puissent avoir un accès élargi dans les environnements de préproduction, les environnements Azure de production doivent réduire les autorisations permanentes, en privilégiant l'accès juste-à-temps (JIT) et l'accès conditionnel via Microsoft Entra. Élaborez vos attributions de rôles RBAC Azure pour que les principaux d’utilisateur s’alignent sur ces principaux à privilèges minimum.

Il est également important de modéliser azure RBAC séparément d’Azure DevOps RBAC. L’objectif du pipeline est de réduire l’accès direct à Azure. À l’exception de cas spéciaux tels que l’innovation, l’apprentissage et la résolution des problèmes, la plupart des interactions avec Azure doivent être effectuées par le biais de pipelines intégrés et avec contrôle.

Pour les principaux de service de pipeline Azure, utilisez un rôle personnalisé qui l’empêche de supprimer des verrous de ressources et d’exécuter d’autres actions destructrices n’entrant pas dans le cadre de sa fonction.

3. Créer un rôle personnalisé pour le principal de service utilisé pour accéder à la production

L’affectation d’autorisations et de rôles de Propriétaire aux agents de build CI/CD est une erreur courante. Les autorisations de contributeur ne suffisent pas si votre pipeline doit également effectuer des attributions de rôles d’identité ou d’autres opérations privilégiées telles que la gestion des stratégies Key Vault.

Un agent de build CI/CD supprimera l’ensemble de votre environnement de production si on le lui ordonne. Afin d'éviter des changements destructeurs et irréversibles, nous créons un rôle personnalisé qui :

• Supprime les stratégies d’accès Key Vault
• Supprime les verrous de gestion qui sont conçus pour empêcher la suppression des ressources (une exigence courante dans les secteurs réglementés).

Pour ce faire, nous créons un rôle personnalisé et supprimons les actions Microsoft.Authorization/*/Delete.

{
  "Name": "Headless Owner",
  "Description": "Can manage infrastructure.",
  "actions": [
    "*"
  ],
  "notActions": [
    "Microsoft.Authorization/*/Delete"
  ],
  "AssignableScopes": [
    "/subscriptions/{subscriptionId1}",
    "/subscriptions/{subscriptionId2}",
    "/providers/Microsoft.Management/managementGroups/{groupId1}"
  ]
}

Si cela supprime trop d’autorisations à vos fins, reportez-vous à la liste complète dans la documentation officielle pour les opérations du fournisseur de ressources Azure et ajustez votre définition de rôle en fonction des besoins.

Déployer ce scénario

Ce scénario s’étend au-delà de Resource Manager. C’est pourquoi nous utilisons Terraform, ce qui nous permet également de créer des principaux dans Microsoft Entra ID et de démarrer Azure DevOps à l’aide d’une seule infrastructure en tant qu’outil de code.

Pour obtenir du code source et des instructions détaillées, consultez le dépôt GitHub Governance sur Azure Demo - de DevOps à ARM.

Tarification

Les coûts d’Azure DevOps dépendent du nombre d’utilisateurs de votre organisation qui nécessitent un accès, ainsi que d’autres facteurs tels que le nombre de builds/versions simultanées requises et le nombre d’utilisateurs. Azure Repos et Azure Pipelines sont des fonctionnalités du service Azure DevOps. Pour plus d’informations, consultez la tarification Azure DevOps .

Dans Microsoft Entra ID, le type de gestion des accès de groupe nécessaire pour ce scénario est fourni dans les éditions Premium P1 et Premium P2. La tarification de ces niveaux est calculée par utilisateur. Pour plus d’informations, consultez la tarification de Microsoft Entra.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteur principal :

• Julie Ng | Ingénieur de service senior

Étapes suivantes

• Consultez le dépôt de code pour ce scénario dans Démonstration de Gouvernance sur Azure, de DevOps à ARM.
• Passez en revue les guides de gouvernance du Framework d’adoption du cloud.
• Qu’est-ce que le contrôle d’accès en fonction du rôle Azure (Azure RBAC) ?
• Cloud Adoption Framework : gestion des accès aux ressources dans Azure
• Rôles Azure Resource Manager
  • Propriétaire (intégré)
  • Contributeur (intégré)
  • Lecteur (intégré)
  • Rôle personnalisé
• Groupes de sécurité Azure DevOps
  • administrateurs de projet
  • Contributeur
  • Lecteur