Partager via

Comprendre le verrouillage de ressources dans les blueprints Azure

  • Article

Important

Le 11 juillet 2026, Blueprints (préversion) sera devenu obsolète. Migrez vos définitions et affectations Blueprint existantes vers les Spécifications de modèleet lesPiles de déploiement. Les artefacts de Blueprint doivent être convertis en modèles ARM JSON ou en fichiers Bicep utilisés pour définir des piles de déploiement. Pour savoir comment créer un artefact en tant que ressource ARM, consultez :

La création d’environnements cohérents à l’échelle n’est vraiment utile que s’il existe un mécanisme pour gérer cette cohérence. Cet article explique le fonctionnement du verrouillage de ressources dans les blueprints Azure. Pour voir un exemple de verrouillage des ressources et d’application d’affectations de refus, consultez le didacticiel relatif à la protection des nouvelles ressources.

Notes

Les verrous de ressources déployés par Azure Blueprints sont appliqués uniquement aux ressources qui ne sont pas des extensions et qui sont déployées par l’affectation du blueprint. Aucun verrou n’est ajouté aux ressources existantes (telles que celles des groupes de ressources qui existent déjà).

Modes et états de verrouillage

Le mode de verrouillage s’applique à l’attribution de blueprint et offre trois options : Ne pas verrouiller, Lecture seule ou Ne pas supprimer. Le mode de verrouillage est configuré durant le déploiement d’artefact au cours d’une attribution de blueprint. Un autre mode de verrouillage peut être défini en mettant à jour l’attribution de blueprint. Les modes de verrouillage ne peuvent cependant pas être modifiés en dehors d’Azure Blueprints.

Les ressources créées par des artefacts dans une attribution de blueprint ont quatre états possibles : Non verrouillé, Lecture seule, Modification/suppression impossible ou Suppression impossible. Chaque type d’artefact peut être en état Non verrouillé. Le tableau suivant permet de déterminer l’état d’une ressource :

Mode Type de ressource d’artefact State Description
Ne pas verrouiller * Non verrouillé Les ressources ne sont pas protégées par Azure Blueprints. Cet état est également utilisé pour des ressources ajoutées à un artéfact de groupe de ressources En lecture seule ou Ne pas supprimer à partir de l’extérieur d’une attribution de blueprint.
Lecture seule Resource group Modification/suppression impossible Le groupe de ressources est en lecture seule et toutes ses propriétés, à l’exception des balises, ne peuvent pas être modifiées. Des ressources Non verrouillées peuvent être ajoutées, déplacées, modifiées ou supprimées dans ce groupe de ressources.
Lecture seule Groupe de non-ressources Lecture seule À l’exception des balises, la ressource reste inaltérable et ne peut pas être supprimée ou modifiée.
Ne pas supprimer * Suppression impossible Les ressources peuvent être modifiées mais pas supprimées. Des ressources Non verrouillées peuvent être ajoutées, déplacées, modifiées ou supprimées dans ce groupe de ressources.

Neutralisation des états de verrouillage

Il est généralement possible pour une personne disposant d’un contrôle d’accès en fonction du rôle Azure (Azure RBAC) approprié sur l’abonnement, tel que le rôle « Propriétaire », d’être autorisée à modifier ou supprimer n’importe quelle ressource. Cet accès n’est pas possible quand Azure Blueprints applique un verrouillage dans le cadre d’une affectation déployée. Si l’attribution a été définie avec l’option Lecture seule ou Ne pas supprimer, même le propriétaire de l’abonnement ne peut pas effectuer l’action bloquée sur la ressource protégée.

Cette mesure de sécurité assure la cohérence du blueprint défini et protège l’environnement pour la création duquel il a été conçu contre toute modification ou suppression accidentelle ou programmatique.

Attribuer au niveau du groupe d’administration

La seule option pour empêcher les propriétaires d’abonnements de supprimer une attribution de blueprint consiste à attribuer le blueprint à un groupe d’administration. Dans ce scénario, seuls les propriétaires du groupe d’administration disposent des autorisations nécessaires pour supprimer l’attribution de blueprint.

Pour attribuer le blueprint à un groupe d’administration plutôt qu’à un abonnement, l’appel d’API REST change pour se présenter comme suit :

PUT https://management.azure.com/providers/Microsoft.Management/managementGroups/{assignmentMG}/providers/Microsoft.Blueprint/blueprintAssignments/{assignmentName}?api-version=2018-11-01-preview

Le groupe d’administration défini par {assignmentMG} doit soit se trouver dans la hiérarchie des groupes d’administration, soit être le même groupe d’administration où la définition du blueprint est enregistrée.

Le corps de la demande de l’attribution de blueprint ressemble à ceci :

{
    "identity": {
        "type": "SystemAssigned"
    },
    "location": "eastus",
    "properties": {
        "description": "enforce pre-defined simpleBlueprint to this XXXXXXXX subscription.",
        "blueprintId": "/providers/Microsoft.Management/managementGroups/{blueprintMG}/providers/Microsoft.Blueprint/blueprints/simpleBlueprint",
        "scope": "/subscriptions/{targetSubscriptionId}",
        "parameters": {
            "storageAccountType": {
                "value": "Standard_LRS"
            },
            "costCenter": {
                "value": "Contoso/Online/Shopping/Production"
            },
            "owners": {
                "value": [
                    "johnDoe@contoso.com",
                    "johnsteam@contoso.com"
                ]
            }
        },
        "resourceGroups": {
            "storageRG": {
                "name": "defaultRG",
                "location": "eastus"
            }
        }
    }
}

La principale différence entre ce corps de demande et celui pour l’assignation à un abonnement est la propriété properties.scope. Cette propriété obligatoire doit être définie sur l’abonnement auquel s’applique l’attribution de blueprint. L’abonnement doit être un enfant direct de la hiérarchie de groupes d’administration dans laquelle l’attribution de blueprint est stockée.

Notes

Un blueprint attribué à l’étendue du groupe d’administration fonctionne toujours comme une attribution de blueprint de niveau abonnement. La seule différence réside dans l’emplacement où l’attribution de blueprint est stockée pour empêcher les propriétaires d’abonnements de supprimer l’attribution et les verrous associés.

Suppression des états de verrouillage

S’il devient nécessaire de modifier ou supprimer une ressource protégée par une attribution, il existe deux manières de procéder.

  • En mettant à jour de l’attribution de blueprint en la définissant sur un mode de verrouillage Ne pas verrouiller
  • Supprimer l’attribution de blueprint

Une fois l’affectation supprimée, les verrous créés par Azure Blueprints sont supprimés. Cependant, la ressource est conservée et doit être supprimée selon des procédés normaux.

Fonctionnement des verrous de blueprint

Une action de refus de type Refuser les attributions de contrôle d’accès en fonction du rôle Azure est appliquée aux ressources d’artefact lors de l’attribution d’un blueprint si cette attribution a sélectionné l’option Lecture seule ou Ne pas supprimer. L’action de refus est ajoutée par l’identité managée de l’attribution de blueprint, et ne peut être supprimée des ressources d’artefacts que par cette même identité managée. Cette mesure de sécurité a pour effet d’appliquer le mécanisme de verrouillage et d’empêcher la suppression du verrou du blueprint en dehors d’Azure Blueprints.

Screenshot of the Access control (I A M) page and the Deny assignments tab for a resource group.

Propriétés d’affectation de refus de chaque mode :

Mode Permissions.Actions Permissions.NotActions Principals[i].Type ExcludePrincipals[i].Id DoNotApplyToChildScopes
Lecture seule * */read
Microsoft.Authorization/locks/delete
Microsoft.Network/virtualNetwork/subnets/join/action		 SystemDefined (Everyone) affectation blueprint et paramètres définis par l’utilisateur dans excludedPrincipals Groupe de ressources - true ; ressource - false
Ne pas supprimer */delete Microsoft.Authorization/locks/delete
Microsoft.Network/virtualNetwork/subnets/join/action		 SystemDefined (Everyone) affectation blueprint et paramètres définis par l’utilisateur dans excludedPrincipals Groupe de ressources - true ; ressource - false

Important

Azure Resource Manager met en cache les détails des affectations de rôles pendant 30 minutes au maximum. Par conséquent, une action de refus de type Refuser les attributions sur des ressources de blueprint risque de ne pas être immédiatement effective. Pendant cette période de temps, il peut être possible de supprimer une ressource destinée à être protégée par des verrous de blueprint.

Exclure un principal d’une affectation de refus

Dans certains scénarios de conception ou de sécurité, il peut être nécessaire d’exclure un principal de l’affectation de refus créée par l’affectation blueprint. Cette étape est effectuée dans l’API REST en ajoutant jusqu’à cinq valeurs au tableau excludedPrincipals de la propriété locks lors de la création de l’attribution. La définition d’attribution suivante est un exemple de corps de demande qui inclut excludedPrincipals :

{
  "identity": {
    "type": "SystemAssigned"
  },
  "location": "eastus",
  "properties": {
    "description": "enforce pre-defined simpleBlueprint to this XXXXXXXX subscription.",
    "blueprintId": "/providers/Microsoft.Management/managementGroups/{mgId}/providers/Microsoft.Blueprint/blueprints/simpleBlueprint",
    "locks": {
        "mode": "AllResourcesDoNotDelete",
        "excludedPrincipals": [
            "7be2f100-3af5-4c15-bcb7-27ee43784a1f",
            "38833b56-194d-420b-90ce-cff578296714"
        ]
    },
    "parameters": {
      "storageAccountType": {
        "value": "Standard_LRS"
      },
      "costCenter": {
        "value": "Contoso/Online/Shopping/Production"
      },
      "owners": {
        "value": [
          "johnDoe@contoso.com",
          "johnsteam@contoso.com"
        ]
      }
    },
    "resourceGroups": {
      "storageRG": {
        "name": "defaultRG",
        "location": "eastus"
      }
    }
  }
}

Exclure une action d’une affectation de refus

À l’instar de l’exclusion d’un principal sur une affectation de refus dans une affectation de blueprint, vous pouvez exclure des Opérations de fournisseur de ressources Azure spécifiques. Dans le bloc properties.locks, au même emplacement que excludedPrincipals, vous pouvez ajouter un excludedActions :

"locks": {
    "mode": "AllResourcesDoNotDelete",
    "excludedPrincipals": [
        "7be2f100-3af5-4c15-bcb7-27ee43784a1f",
        "38833b56-194d-420b-90ce-cff578296714"
    ],
    "excludedActions": [
        "Microsoft.ContainerRegistry/registries/push/write",
        "Microsoft.Authorization/*/read"
    ]
},

Bien que excludedPrincipals doive être explicite, les entrées excludedActions peuvent tirer parti de * pour la correspondance de caractères génériques des opérations de fournisseur de ressources.

Étapes suivantes