ITSec France

Azure : ces propriétaires d’abonnement que personne n’a validés

Azure : ces propriétaires d’abonnement que personne n’a validés

En décembre 2025, Azure a attribué automatiquement le rôle Propriétaire, à l’échelle de l’abonnement, à tous les comptes encore porteurs de Co-Administrator ou Service Administrator. Sans notification, sans validation, sans journal de décision.

La bascule était nécessaire : les rôles classiques ont été définitivement retirés en mai 2026, et il fallait bien que ces comptes conservent un accès. Mais elle a produit un effet de bord que peu d’organisations ont audité — et Propriétaire n’est pas un rôle anodin.

Ce que Propriétaire autorise réellement

Contrairement à Contributeur, le rôle Propriétaire permet d’attribuer des rôles. Un compte qui l’a obtenu par conversion automatique peut donc s’accorder des droits supplémentaires, en donner à d’autres, et le faire sur l’ensemble de l’abonnement. Si vous n’avez pas revu vos attributions depuis décembre 2025, vous ignorez probablement qui détient ce pouvoir chez vous.

Comment on en est arrivé là

Le calendrier s’est étalé sur près de deux ans, ce qui explique que beaucoup l’aient perdu de vue :

  • 31 août 2024 — retrait d’Azure Service Manager et de l’ensemble des ressources classiques. Les rôles classiques cessent d’être pris en charge.
  • Décembre 2025 — Azure attribue automatiquement le rôle RBAC Propriétaire, à l’échelle de l’abonnement, aux comptes encore porteurs de Co-Administrator ou Service Administrator dans le cloud public.
  • Mai 2026 — retrait complet. La gestion des accès passe exclusivement par Azure RBAC.

Le point sensible est la deuxième ligne. À l’époque du modèle classique, le rôle Co-Administrator était distribué avec une générosité que personne n’assumerait aujourd’hui : prestataires, comptes de service, administrateurs d’un projet ponctuel. Tous ces comptes se sont retrouvés Propriétaire.

Auditer les attributions Propriétaire

Ce script parcourt vos abonnements et liste les attributions du rôle Propriétaire à l’échelle de l’abonnement — précisément le périmètre concerné par la conversion.

Connect-AzAccount

$attributions = foreach ($abo in Get-AzSubscription) {
    $null = Set-AzContext -SubscriptionId $abo.Id
    $portee = "/subscriptions/$($abo.Id)"

    Get-AzRoleAssignment -Scope $portee |
        Where-Object {
            $_.RoleDefinitionName -eq 'Owner' -and $_.Scope -eq $portee
        } |
        Select-Object @{ Name = 'Abonnement'; Expression = { $abo.Name } },
                      DisplayName,
                      SignInName,
                      ObjectType,
                      @{ Name = 'Type'; Expression = { $_.ObjectType } }
}

$attributions |
    Sort-Object Abonnement, DisplayName |
    Format-Table -AutoSize

# Export pour revue avec les responsables d'application
$attributions |
    Export-Csv -Path .\proprietaires-azure.csv -NoTypeInformation -Encoding UTF8

Le module Az.Resources est requis, ainsi qu’un droit de lecture sur les abonnements concernés. Le filtre sur la portée est important : sans lui, vous remontez aussi les attributions héritées au niveau des groupes de ressources, ce qui noie le signal.

Ce qu’il faut chercher dans les résultats

Quatre catégories méritent une attention immédiate :

  • Les personnes parties. Un prestataire ou un collaborateur dont le compte n’a pas été désactivé conserve un rôle Propriétaire acquis silencieusement.
  • Les comptes de service basés sur des identités utilisateur. Ils cumulent deux problèmes, on y revient plus bas.
  • Les invités. Un compte externe avec le rôle Propriétaire sur un abonnement est une situation à corriger le jour même.
  • Les comptes que personne ne reconnaît. Sur un tenant ancien, il y en a presque toujours. Leur existence est le meilleur argument pour lancer une revue complète.

Par quoi remplacer Propriétaire

La correction naturelle consiste à redescendre vers Contributeur, qui permet de gérer les ressources sans pouvoir distribuer de rôles. Lorsque la personne doit réellement gérer des accès, la combinaison propre est Contributeur plus Administrateur de l’accès utilisateur : deux rôles distincts, deux justifications distinctes, deux traces d’attribution.

Pour les administrateurs qui ont un besoin ponctuel de privilèges élevés, l’activation à la demande via Privileged Identity Management supprime le rôle permanent. C’est la seule approche qui résiste à ce genre de dérive : un droit qui expire ne s’accumule pas.

Ne coupez pas à l’aveugle

Avant de retirer une attribution Propriétaire, vérifiez ce qui s’exécute sous cette identité. Un compte hérité de l’ère classique peut porter des tâches planifiées, des pipelines ou des scripts que personne n’a documentés. Retirez le rôle après avoir identifié les usages, pas avant.

Le second effet : ces comptes sont aussi rattrapés par le MFA

La conversion des rôles n’est pas le seul changement à les concerner. Depuis le 1er octobre 2025, toute opération de création, modification ou suppression de ressource Azure exige une authentification multifacteur, quel que soit le client — Azure CLI, Azure PowerShell, Terraform, API REST du plan de contrôle.

Trois précisions qui changent la façon d’aborder le sujet :

  • Les exclusions d’accès conditionnel ne s’appliquent plus. L’application se fait côté serveur, au niveau d’Azure Resource Manager. Exempter un compte dans une stratégie ne le protège pas de l’exigence.
  • Les comptes de secours ne sont pas exemptés non plus. Microsoft recommande de les basculer sur une clé FIDO2 ou une authentification par certificat, deux méthodes qui satisfont l’exigence sans dépendre d’un téléphone.
  • Les identités de charge de travail le sont. Principaux de service et identités managées ne sont pas concernés. C’est la cible de migration pour tout compte utilisateur qui sert d’automatisation.

Autrement dit, un compte de service basé sur une identité utilisateur et devenu Propriétaire en décembre 2025 cumule un privilège excessif et une automatisation qui va cesser de fonctionner. Ces comptes sont votre priorité.

La fenêtre de report qu’accordait Microsoft s’est refermée le 1er juillet 2026. Pour vérifier l’état de votre tenant, connectez-vous au portail Azure en administrateur général et consultez aka.ms/postponePhase2MFA : un bandeau confirme si l’application a démarré.

Les autres échéances de la période

Date Changement
2 avril 2026 Retrait d’Azure ACS : les applications qui l’utilisaient pour accéder à SharePoint Online ont perdu cet accès, de même que le modèle de compléments SharePoint
Fin décembre 2026 Désactivation par défaut de l’authentification de base sur SMTP AUTH. À préparer maintenant : copieurs, sondes de supervision, applications métier qui envoient des notifications

La séquence que je recommande

  • Exécuter l’audit des attributions Propriétaire et l’exporter
  • Faire valider chaque ligne par un responsable identifié — sans validation nominative, la revue ne sert à rien
  • Identifier ce qui s’exécute sous les comptes concernés avant toute suppression
  • Redescendre vers Contributeur, ou vers Contributeur et Administrateur de l’accès utilisateur si la gestion d’accès est justifiée
  • Migrer les comptes de service utilisateur vers des identités managées
  • Basculer les comptes de secours sur FIDO2 ou certificat

Cet audit prend une demi-journée. C’est peu au regard de ce qu’il révèle en général sur un tenant qui a plusieurs années d’existence.

Sources