Configurer le moindre privilège sur un compte cloud existant

Configurer le moindre privilège sur un compte cloud existant

Réduire les permissions d’un environnement cloud existant ne consiste pas à remplacer AdministratorAccess par trois politiques vaguement plus petites. Il faut mesurer les accès réellement exercés, séparer les identités humaines des charges de travail, puis retirer les droits par vagues réversibles. Le compromis central est net : on gagne une réduction massive du rayon d’explosion, on paie en instrumentation, en exceptions documentées et en discipline d’exploitation.

Explication de la marmotte

Une politique de moindre privilège ressemble à un atelier où chaque personne reçoit uniquement les outils nécessaires à son poste. Cela évite qu’une clé oubliée puisse ouvrir tous les placards, couper l’électricité et commander une pelleteuse, juste parce qu’elle était dans le même trousseau.

→ Lire l’explication complète de la marmotte

Préparer l’audit des permissions cloud

Le moindre privilège ne se déduit pas d’un organigramme ni d’une feuille de calcul d’habilitations. Il se déduit d’actions observées, sur une période représentative des cycles d’exploitation : clôture comptable, déploiements, restauration, rotation de certificats et traitements mensuels. Un rôle jamais utilisé pendant quatorze jours peut être dormant ou n’avoir raté que le jour où il fallait restaurer une base. La différence coûte un incident.

Avant toute restriction, établir quatre inventaires versionnés :

1. Les identités humaines, fédérées et locales, avec leur propriétaire et leur date de dernière connexion.
2. Les identités machine : rôles de charge de travail, comptes de service, identités managées et clés d’interface de programmation applicative (API).
3. Les autorisations effectives, y compris groupes imbriqués, politiques héritées, délégations inter-comptes et permissions accordées par ressource.
4. Les journaux d’usage et les échecs d’autorisation, centralisés hors du compte ou projet administré.

Dans AWS, activer AWS CloudTrail sur toutes les régions, avec les événements de données pour les services sensibles, puis AWS Config pour figer l’état des politiques. Dans Azure, exporter les journaux d’activité et les journaux Microsoft Entra ID vers un espace de journalisation distinct. Dans Google Cloud Platform (GCP), conserver les journaux d’audit d’administration et d’accès aux données dans un projet dédié. Sans conservation centralisée, un administrateur compromis peut effacer les traces de son propre passage. Le chat ne doit pas garder la clé du garde-manger.

L’accès d’audit doit être en lecture seule et séparé du rôle d’administration. Les droits de lecture restent néanmoins dangereux : secretsmanager:GetSecretValue, ssm:GetParameter sur un paramètre chiffré, storage.objects.get ou Key Vault Secrets User exposent parfois plus que la permission de modifier une ressource. Lire un secret est déjà l’exfiltrer.

Consulter aussi les mécanismes de gouvernance existants : AWS Organizations et ses politiques de contrôle de service, Azure Management Groups avec Azure Policy, organisations GCP avec Organization Policy Service. Ces garde-fous limitent le plafond des permissions, pas les permissions réellement nécessaires. Les confondre produit des rôles trop larges sous une clôture trop haute, version cloud du placard rangé derrière une porte ouverte.

Les fondations d’identité conditionnent tout le reste. La gestion des identités et la détection de persistance IAM dans AWS doivent être traitées avant de réduire les droits, notamment pour identifier les clés longues durées, les relations de confiance inter-comptes et les rôles assumables par des fournisseurs externes.

Modéliser les accès IAM par capacité

IAM signifie Identity and Access Management, soit la gestion des identités et des accès. La bonne unité de travail n’est pas l’utilisateur, ni l’équipe, mais la capacité opérationnelle : déployer une application donnée, lire les métriques d’un périmètre donné, administrer un cluster précis, restaurer une sauvegarde contrôlée.

Découper les permissions selon quatre dimensions :

• Action : s3:GetObject n’implique pas s3:PutObject, et ec2:DescribeInstances n’implique pas ec2:TerminateInstances.
• Ressource : cibler un compartiment, un coffre, un abonnement, un projet, un registre ou une file identifiés.
• Contexte : imposer une région, un réseau privé, une étiquette de ressource, un type d’authentification ou une heure d’activation.
• Délégation : empêcher une identité de s’accorder elle-même un droit plus large, directement ou par création de rôle, attachement de politique, jeton d’accès ou modification de relation de confiance.

La quatrième dimension décide souvent du niveau réel de sécurité. Autoriser iam:CreateRole et iam:PassRole dans AWS, roleAssignments/write dans Azure, ou iam.serviceAccounts.getAccessToken sur un compte de service privilégié dans GCP peut rendre insignifiante une politique applicative pourtant étroite. Un droit de délégation est un droit de produire d’autres droits.

Séparer les rôles humains des rôles non humains. Une charge de travail doit utiliser une identité attachée à son environnement d’exécution, jamais une clé statique injectée dans une variable d’environnement ou un dépôt d’intégration et livraison continues (CI/CD). Les jetons fédérés à durée courte réduisent la valeur d’un vol, mais ne réduisent pas les permissions du jeton pendant sa validité.

Pour les humains, exiger l’authentification multifacteur (MFA, Multi-Factor Authentication), la fédération avec l’annuaire central et des rôles d’administration activables temporairement. Azure Privileged Identity Management permet cette élévation limitée dans le temps. AWS et GCP demandent généralement un mécanisme externe ou un rôle dédié avec durée de session bornée. L’administration permanente est une facilité opérationnelle qui finit par devenir une propriété du système, puis un angle mort.

Établir une base d’autorisation par fournisseur

AWS fournit IAM Access Analyzer pour générer des politiques à partir des événements CloudTrail. Le résultat sert de brouillon, jamais de vérité : les actions List, Describe et les appels indirects de console peuvent manquer, tandis que les accès historiques peuvent préserver des permissions obsolètes. Commencer par une politique gérée par le client, attachée à un seul rôle pilote. Éviter les politiques en ligne dispersées : elles échappent aux revues et se reproduisent avec l’enthousiasme des moisissures.

Azure s’appuie sur le contrôle d’accès basé sur les rôles (RBAC, Role-Based Access Control). Préférer des rôles personnalisés au périmètre d’un groupe de ressources ou d’une ressource, plutôt qu’un rôle intégré Contributor sur l’abonnement entier. Vérifier les actions de plan de contrôle et de plan de données séparément : administrer un coffre Azure Key Vault n’autorise pas forcément sa lecture, et inversement selon les modèles d’autorisation activés.

Dans GCP, analyser les journaux d’audit, puis composer des rôles personnalisés au niveau du projet, dossier ou de l’organisation selon la responsabilité réelle. Les rôles primitifs Owner, Editor et Viewer sont à éliminer des identités courantes. Editor peut modifier des ressources et créer des chemins d’élévation dans de nombreux services. Son nom semble inoffensif, comme un bouton rouge marqué « confort ».

Dans les trois fournisseurs, imposer des étiquettes obligatoires sur les ressources : propriétaire, environnement, criticité et application. Elles permettent de limiter une permission à une classe de ressources et de détecter les ressources orphelines. Une condition fondée sur une étiquette non obligatoire ne protège rien : il suffit de créer la ressource sans étiquette pour sortir du périmètre prévu.

Exemple AWS : restreindre un rôle de déploiement

L’exemple suivant crée une politique AWS IAM limitée à un compartiment Amazon Simple Storage Service (S3) et à un préfixe de déploiement. Tester d’abord sur un rôle pilote, avec journalisation CloudTrail active. La négation explicite bloque les suppressions, y compris si une politique plus large est ajoutée par erreur au même rôle.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "LireEtEcrireLePrefixeDeploiement",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::artefacts-production/releases/*"
    },
    {
      "Sid": "ListerUniquementLePrefixeAutorise",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::artefacts-production",
      "Condition": {
        "StringLike": {
          "s3:prefix": ["releases/*"]
        }
      }
    },
    {
      "Sid": "InterdireLaSuppressionMemeSiUnAutreDroitLAutorise",
      "Effect": "Deny",
      "Action": [
        "s3:DeleteObject",
        "s3:DeleteObjectVersion"
      ],
      "Resource": "arn:aws:s3:::artefacts-production/*"
    }
  ]
}

Cette politique ne permet ni de créer le compartiment, ni de modifier son chiffrement, ni de lire hors du préfixe releases/. Elle ne protège pas contre un artefact malveillant déposé par une identité déjà autorisée à écrire. L’intégrité du pipeline dépend alors de la signature des artefacts, du contrôle des sources et de la séparation des identités de construction et de déploiement.

Retirer les droits par vagues contrôlées

La stratégie recommandée est restrictive par étapes, pas le grand soir des autorisations. Créer une politique candidate, l’appliquer à un périmètre pilote, surveiller les refus, corriger les appels légitimes, puis étendre. Conserver un mécanisme de retour arrière limité dans le temps et détenu par une identité distincte. Un retour arrière administrateur permanent annule le modèle, avec une élégance toute théorique.

Traiter les refus selon leur cause :

• action absente de la politique ;
• ressource mal ciblée ;
• condition non satisfaite, souvent une étiquette ou une région ;
• dépendance implicite, par exemple lecture d’une clé de chiffrement avant accès à une donnée ;
• délégation bloquée par une politique d’organisation ou une frontière de permissions.

Une frontière de permissions AWS, une Azure Policy ou une règle d’organisation GCP ne remplace pas le contrôle d’accès applicatif. Ces mécanismes ne garantissent ni l’authenticité des données, ni la séparation des tâches métier, ni la sécurité d’une application compromise. Le reste doit venir du cloisonnement réseau, de secrets isolés, de journaux immuables et de contrôles applicatifs. La segmentation réseau et le Zero Trust complètent le moindre privilège, ils ne sont pas une décoration de slide.

Mesurer au minimum : nombre de rôles administrateurs permanents, permissions à caractère générique, identités inactives, échecs d’autorisation après chaque vague, et délai d’approbation des élévations temporaires. Une hausse durable des refus peut signaler une politique trop restrictive ou une tentative d’abus. Les deux hypothèses méritent une enquête, pas un Allow * lancé entre deux réunions.

Exploitation, rotation et reprise des identités

Les comptes d’urgence doivent exister, être fortement protégés et ne servir qu’à restaurer un chemin d’administration cassé. Stocker leurs facteurs d’authentification, procédures d’accès et propriétaires dans des systèmes séparés du fournisseur concerné. Tester périodiquement leur accès, sans les utiliser pour les opérations courantes. Un compte de secours jamais testé est un objet décoratif avec des permissions illimitées.

Faire tourner les clés d’accès statiques restantes et viser leur suppression. Toute clé qui ne peut pas être remplacée sans interruption révèle une dépendance architecturale, pas une fatalité. Révoquer une clé bloque les nouveaux appels, mais ne retire pas les jetons temporaires déjà émis : réduire aussi la durée de session et désactiver l’identité source.

Sauvegarder les définitions de rôles, politiques, affectations et relations de confiance dans un dépôt versionné, avec revue de changement. Sauvegarder seulement la configuration ne suffit pas : documenter l’ordre de restauration, les dépendances de fédération et les identités capables de réappliquer la configuration. Une reprise qui exige le même rôle supprimé pendant l’incident a la grâce mécanique d’un parachute rangé dans l’avion parti sans lui.

🐝 Ce qui arrive si on s’en passe

Sans moindre privilège, une identité compromise n’émet aucun refus d’autorisation pendant sa phase de reconnaissance : chaque appel d’énumération réussit et se confond avec l’activité normale, ce qui supprime l’un des signaux de détection les plus fiables, l’échec d’accès inattendu. Après l’incident, le périmètre d’enquête ne peut plus être borné par les droits de l’identité fautive ; toute ressource atteignable devient suspecte, et chaque secret, clé ou jeton lisible par cette identité doit être renouvelé, ce qui allonge la reprise et multiplie les interruptions. Une permission générique sur le calcul (création d’instances, de fonctions ou de clusters) permet aussi de lancer des ressources facturées au compte et d’épuiser les quotas de service, bloquant alors les déploiements légitimes qui partagent ces mêmes limites.

🦫 Explication de la marmotte 🍫

Un compte cloud contient des identités : des personnes, des applications et des programmes automatiques. Chaque identité reçoit des autorisations pour consulter, créer, modifier ou supprimer des ressources. Le moindre privilège consiste à donner seulement les autorisations nécessaires à une tâche précise, sur les bonnes ressources, pendant la durée nécessaire.

La première étape consiste à relever qui possède des accès et quelles actions sont réellement réalisées. Les journaux gardent la liste des demandes acceptées et refusées. Ces journaux doivent être conservés dans un endroit séparé, car une personne qui contrôle le compte ne doit pas pouvoir supprimer facilement les preuves de ses actions.

Ensuite, les autorisations sont découpées. Une application qui dépose des fichiers n’a pas besoin de supprimer tous les fichiers ni de créer de nouveaux comptes. Une personne qui administre une application n’a pas besoin de lire les secrets d’une autre application. Les permissions permettant de donner de nouveaux droits sont surveillées de très près, car elles permettent de contourner les limites prévues.

Les restrictions sont appliquées sur un petit groupe, puis étendues après vérification. Si une action légitime échoue, on identifie précisément le droit manquant au lieu de rétablir un accès total. Des accès de secours existent pour réparer une erreur grave, mais ils sont séparés, protégés et testés. Les clés et accès temporaires sont renouvelés ou supprimés pour limiter les conséquences d’un vol.

À lire aussi

• Quotas cloud contre le déni de service par coûtGérer les quotas et limites de ressources cloud pour réduire le risque de déni de service par abus de facturation.
• Détecter la persistance IAM dans AWSCatalogue de détection des techniques de persistance IAM dans AWS, incluant rôles de confiance, clés d'accès dormantes et fonctions déclenchées à intervalle.
• Configurer GitHub Actions OIDC vers AWS sans clé statiqueGuide pratique pour fédérer une identité GitHub Actions vers AWS avec OpenID Connect et des rôles temporaires strictement limités à un dépôt et une branche.
• Auditer et durcir un cluster Kubernetes avec kube-benchGuide pratique pour auditer un cluster Kubernetes existant avec kube-bench, prioriser les écarts CIS et conduire la remédiation sans casser l'exploitation.

Pages voisines

La citent

• Détecter la persistance IAM dans AWS
• Pourquoi le moindre privilège échoue en production

Configurer le moindre privilège sur un compte cloud existant

Elle cite

• ⇄Lien dans les deux sens :Mettre en place un accès JIT AWS pour comptes à privilèges
• Comment gouverner les coûts cloud contre un compte compromis
• OIDC pour sécuriser les identifiants CI/CD

⇄ : les deux pages se citent l’une l’autre.