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 souvenir qu’Azure Resource Manager n’est que l’une des façons de gérer les ressources. L’automatisation CI/CD (intégration continue et livraison continue) et Azure DevOps peuvent être une porte dérobée de sécurité non intentionnelle en cas de sécurisation incorrecte. Ces ressources doivent être protégées par la mise en miroir du 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 des 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 débutent avec DevOps et qui 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 dépôt.

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

• Groupes Microsoft Entra qui s'alignent sur les domaines métier et les modèles d'autorisations
  L’organisation dispose de nombreux domaines métier verticaux, tels que « fruits » et « légumes », qui opèrent en grande partie indépendamment. Dans chaque domaine métier, il existe deux niveaux *-admins ou *-devs privilèges, qui sont mappés à des groupes Microsoft Entra distincts. 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 ont des 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 d’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 dépôt Git.

• Parcours cloud jusqu’à présent
  L’organisation a commencé avec un modèle de projet isolé pour accélérer le parcours cloud, mais elle explore désormais les options permettant de rompre les silos et de favoriser la collaboration en créant les projets « collaboration » et « supermarché ».

Ce diagramme simplifié montre comment les branches d’un dépôt Git sont mappées à des environnements de développement, intermédiaire et de production :

Téléchargez un fichier SVG de ce diagramme.

Architecture

Ce diagramme montre comment la liaison de Resource Manager et CI/CD à Microsoft Entra ID est la clé pour disposer d'un modèle de gouvernance de bout en bout.

Téléchargez un fichier SVG de cette architecture.

Workflow

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 avec Microsoft Entra ID afin d'avoir un seul plan d'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'adhésion 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 son adhésion au groupe Microsoft Entra. Pour chaque domaine, nous créons :

   • Groupes Microsoft Entra. Deux groupes par domaine (décrits aux étapes 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 afin de 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 afin de 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 une étendue 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 attribue 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 tout verrou de gestion placé 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. Affectations de groupes de sécurité dans Azure DevOps

   Les groupes de sécurité fonctionnent comme des rôles dans Resource Manager. Tirez parti des rôles intégrés et attribuez par défaut le rôle de Contributeur aux développeurs. Les administrateurs sont affectés au groupe de sécurité Administrateurs de projet pour les 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 d’autorisations minimales.

   Pour cette raison, les appartenances aux groupes -admins et -devs doivent s’exclure mutuellement, sinon les personnes concernées auront 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	Project Administrators
   veggies-all	–	–
   veggies-devs	Contributeur	Contributeur
   veggies-admins	Propriétaire	Project Administrators
   infra-all	–	–
   infra-devs	Contributeur	Contributeur
   infra-admins	Propriétaire	Project Administrators

   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, consultez 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, si une approbation humaine est requise avant le déploiement. Cette architecture de référence a deux protections minimales sur la connexion de service :

   • Les administrateurs doivent configurer des autorisations de pipeline afin de contrôler les pipelines capables d’accéder aux informations d’identification
   • 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 prod-connection.

7. Dépôts Git

   Nos connexions de service étant liées à des branches par le biais de contrôles de branche, il est essentiel de configurer des autorisations sur les dépôts Git et d’appliquer des stratégies de branche. En plus d’exiger la réussite des builds d’intégration continue, nous avons également besoin que les demandes de tirage (pull requests) aient au moins deux approbateurs.

Composants

• Azure DevOps
• Microsoft Entra ID
• Azure Resource Manager
• Azure Repos
• Azure Pipelines

Autres solutions

Le concept de gouvernance de bout en bout est indépendant du fournisseur. Bien que cet article soit axé sur Azure DevOps, Azure DevOps Server peut faire office de 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. Même si leurs ensembles de fonctionnalités sont légèrement différents, ils peuvent tous deux être intégrés dans des modèles de gouvernance globaux pour CI/CD. GitLab est une autre plateforme Git qui fournit des fonctionnalités CI/CD fiables.

Ce scénario utilise Terraform comme outil d’infrastructure en tant que code (IaC). Les alternatives incluent Jenkins, Ansible et 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 de l’ordinateur du développeur vers la production. Le diagramme suivant illustre un flux de travail CI/CD de référence avec Azure DevOps. L’icône de verrou rouge indique les autorisations de sécurité qui doivent être configurées par l’utilisateur. Si vous configurez incorrectement ne configurez pas les autorisations, vos charges de travail seront vulnérables.

Téléchargez un fichier 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 flux de travail. Il est important que tout modèle RBAC s’étende également aux pipelines et au code. Ceux-ci s’exécutent souvent avec des identités privilégiées, et détruiront vos charges de travail s’ils reçoivent des instructions en ce sens. 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.

Il convient de prendre en compte les concepts et questions suivants 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égez vos environnements à l’aide de 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 dépôt de gestion du code source. Dans la pratique, cette opération est effectuée grâce au flux de travail de demande de tirage en association avec des stratégies de branche, qui définissent les vérifications et les exigences avant que le code puisse être accepté.

Lorsque vous planifiez 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. Voici quelques vérifications courantes de protection des branches utilisées pour sécuriser vos déploiements :

• 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 la révision par un paire. Faites en sorte qu’une autre personne vérifie que le code fonctionne comme prévu. Faites preuve d’une grande prudence 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’effectuer un push direct en production ?

N’oubliez pas que Git est un système de gestion du code source distribué. Un développeur peut effectuer un commit directement dans sa branche production locale. Mais lorsque Git est configuré correctement, un tel push sera rejeté automatiquement 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 demande de tirage et de protection de branche sont disponibles auprès de plusieurs fournisseurs de gestion du code source, notamment Azure Repos, GitHub et GitLab.

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

2. De quels accès les principaux de sécurité ont-ils besoin ?

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 principaux de sécurité doivent respecter le principe des privilèges minimum. Alors que les principes de sécurité peuvent avoir étendu l'accès dans les environnements de pré-production, les environnements de production Azure doivent minimiser les autorisations permanentes, en favorisant l'accès juste à temps (JIT) et l'accès conditionnel 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 le contrôle RBAC Azure de manière distincte du contrôle RBAC Azure DevOps. L’objectif du pipeline est de réduire l’accès direct à Azure. À l’exception des cas particuliers tels que l’innovation, l’apprentissage et la résolution des problèmes, la plupart des interactions avec Azure doivent être effectuées via des pipelines contrôlés et conçus spécifiquement à cet effet.

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éez 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 sont pas suffisantes si votre pipeline doit également effectuer des attributions de rôle d’identité ou d’autres opérations privilégiées telles que la gestion de stratégies Key Vault.

Toutefois, un agent de build CI/CD supprimera l’intégralité de votre environnement de production s’il en reçoit l’instruction. Pour éviter toute modification destructrice irréversible, nous créons un rôle personnalisé qui :

• Supprime les stratégies d’accès Key Vault.
• Supprime les verrous de gestion qui, de par leur conception, doivent empêcher la suppression des ressources (une exigence courante dans les industries réglementées).

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 un trop grand nombre d’autorisations, reportez-vous à la liste complète dans la documentation officielle sur les opérations du fournisseur de ressources Azure et ajustez votre définition de rôle en fonction de vos besoins.

Déployer ce scénario

Ce scénario va au-delà de Resource Manager. C'est pourquoi nous utilisons Terraform, qui nous permet également de créer des principaux dans Microsoft Entra ID et d'amorcer Azure DevOps en utilisant une seule infrastructure comme outil de code.

Pour obtenir le code source et des instructions détaillées, consultez le dépôt GitHub Démonstration de Gouvernance sur Azure, de DevOps à ARM.

Tarifs

Les coûts d’Azure DevOps varient en fonction du nombre d’utilisateurs de votre organisation qui nécessitent un accès, ainsi que d’autres facteurs tels que le nombre de builds/mises en production simultanées requis et le nombre d’utilisateurs. Azure Repos et Azure Pipelines sont des fonctionnalités du service Azure DevOps. Pour plus d’informations, consultez la page Tarification Azure DevOps.

Dans Microsoft Entra ID, le type de gestion des accès aux groupes nécessaire pour ce scénario est fourni dans les éditions Premium P1 et Premium P2. Le tarif de ces niveaux est calculé sur la base de chaque 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 cloud du Cloud Adoption Framework.
• Qu’est-ce que le contrôle d’accès en fonction du rôle Azure (RBAC Azure) ?
• Framework d’adoption du cloud : Gestion de l’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
  • Project Administrators
  • Contributeur
  • Lecteur

Ressources associées

• Concevoir un pipeline CI/CD à l’aide d’Azure DevOps
• Chaîne de preuves de forensique informatique dans Azure
• Gestion et déploiement d’Azure Arc hybride pour les clusters Kubernetes
• Parcourir l’architecture Azure - CI/CD