Le moindre privilège en pratique : Access Analyzer et l'élagage des permissions inutilisées

Le moindre privilège ne s’atteint pas en écrivant des politiques parfaites au jour un — il s’atteint en accordant à peu près juste, puis en élaguant ce que les données d’usage prouvent inutile. AWS vous donne trois instruments pour la boucle : les constats d’accès externe d’IAM Access Analyzer (qui, hors du compte, peut atteindre vos ressources), les constats d’accès inutilisé (quels rôles, clés et permissions sont restés inactifs), et les données de dernier accès plus la génération de politiques basée sur CloudTrail pour réécrire les accès à la hauteur de la réalité observée. Roulez la boucle chaque trimestre et les jokers arrêtent de s’accumuler.

Ce qui se passe

Les permissions ne font que croître par défaut. Chaque correctif d’incident, migration et « débloque-moi donc » ajoute des accès, et rien ne les retire — le côté retrait n’a aucun moteur naturel, alors la surface de permissions d’un compte s’étend jusqu’à ce qu’un audit ou une brèche force la question. La boucle d’élagage remplace la peur par des données : au lieu de demander « est-ce que quelque chose pourrait utiliser ça? », vous demandez « est-ce que quelque chose l’a utilisé en 90 jours? », ce qui a une réponse.

L’outillage se divise par direction. Les analyseurs d’accès externe examinent les politiques de ressources — compartiments S3, clés KMS, politiques de confiance de rôles IAM, files SQS, permissions Lambda et plus — et utilisent le raisonnement automatisé pour signaler tout ce qui est atteignable de l’extérieur de votre zone de confiance (le compte ou l’organisation). Ils sont gratuits et devraient exister dans chaque compte, puisqu’un compartiment public ou un rôle trop confiant est exactement le constat que vous voulez l’heure même où il apparaît. Les analyseurs d’accès inutilisé surveillent plutôt les principaux : rôles et utilisateurs qui ne se sont pas authentifiés, clés d’accès et mots de passe inactifs au-delà de votre seuil, et services et actions accordés mais non utilisés. Avertissement honnête sur la mécanique de coût : l’analyse d’accès inutilisé est une fonction payante, facturée par rôle ou utilisateur IAM analysé par mois, alors le nombre de principaux du compte pilote la facture — raisonnable pour les comptes qui comptent, à délimiter délibérément. À côté des analyseurs, les données de dernier accès sur n’importe quel rôle montrent quand chaque service a servi pour la dernière fois (avec détail au niveau des actions pour certains services dont S3, EC2, IAM et Lambda), et Access Analyzer peut générer une politique depuis l’historique CloudTrail réel d’un rôle — la façon la plus rapide de réduire un rôle PowerUserAccess à ce qu’il fait de façon démontrable. La liste complète des capacités vit dans la documentation IAM.

Quoi vérifier en premier

Un analyseur d’accès externe existe-t-il dans chaque région utilisée? Pas d’analyseur veut dire que les constats d’exposition publique ne sont le travail de personne. Zéro constat sur un analyseur neuf est une information; zéro analyseur est de la négligence.
Les sur-accès évidents. Des rôles portant AdministratorAccess ou PowerUserAccess qui appartiennent à des applications, pas à des humains.
Les principaux inactifs. Rôles et utilisateurs sans authentification depuis 90 jours et plus sont les gains les moins chers — des principaux entiers, pas des actions individuelles.
Si l’historique CloudTrail est intact. La génération de politiques et les verdicts « inutilisé » honnêtes dépendent tous deux d’un trail qui couvre vraiment la fenêtre — voir notre base CloudTrail et GuardDuty.

Comment vérifier

# Les analyseurs dans cette région, et leur type
aws accessanalyzer list-analyzers \
  --query 'analyzers[].[name,type,status]' --output table

# Constats actifs (accès externe)
aws accessanalyzer list-findings \
  --analyzer-arn arn:aws:accessanalyzer:ca-central-1:111122223333:analyzer/org-analyzer \
  --filter '{"status": {"eq": ["ACTIVE"]}}'

# Dernier accès par service pour un rôle (deux étapes, asynchrone)
aws iam generate-service-last-accessed-details \
  --arn arn:aws:iam::111122223333:role/app-role
aws iam get-service-last-accessed-details --job-id <job-id-from-previous>

Chemins console : IAM > Access Analyzer pour les constats, et sur n’importe quel rôle, l’onglet Last Accessed — la liste triée « not accessed in tracking period » au bas est la liste courte d’élagage. Notez que la fenêtre de suivi des données de dernier accès va jusqu’à 400 jours.

Le runbook

Créez d’abord l’analyseur d’accès externe, à l’échelle de l’organisation si vous avez Organizations. Triez ses constats avant tout élagage : une confiance inter-comptes que personne ne reconnaît et des ressources publiques passent devant toute permission inutilisée.
Supprimez ou mettez en quarantaine les principaux inactifs. Pour les rôles inutilisés depuis 90 jours et plus : retirez les politiques ou attachez un deny-tout explicite, attendez un cycle, puis supprimez. Désactivez les clés inactives de la même façon — réversible d’abord, permanent ensuite.
Activez l’analyse d’accès inutilisé là où elle paie. Comptes de production et de services partagés d’abord; la tarification par principal fait de « toute l’organisation » un choix délibéré, pas un défaut.
Réduisez les pires rôles avec des politiques générées. IAM > Roles > (role) > Generate policy bâtit une politique depuis jusqu’à 90 jours d’activité CloudTrail. Relisez-la — la génération couvre les services que CloudTrail a vus, et les actions rares mais légitimes (runbooks de reprise annuels) doivent être rajoutées à la main avant d’échanger la politique.
Institutionnalisez la boucle. Une revue trimestrielle des nouveaux constats, une règle permanente que les PR d’élargissement citent une action refusée, et l’archivage-avec-raison des constats acceptés pour que le tableau de bord reste signifiant.

Quand ce n’est pas la bonne approche

N’élaguez pas pendant un incident ou une fenêtre de migration — « inutilisé depuis 90 jours », c’est exactement de quoi ont l’air les permissions de reprise après sinistre la semaine avant d’en avoir besoin; étiquetez les rôles de reprise et de bris de glace comme exempts et testez-les sur leur propre calendrier. Et si le compte n’a jamais eu les bases — aucune histoire de MFA, clés racine encore vivantes — réglez ça avant de financer un abonnement d’accès inutilisé; l’ordre compte.

Erreurs fréquentes

Se fier à une fenêtre de 30 jours : les traitements de facturation trimestriels, les audits annuels et les chemins de reprise ont tous l’air inutilisés jusqu’au moment où ils ne le sont plus.
Livrer une politique générée sans relecture et casser le chemin de code rare mais critique que CloudTrail n’a jamais vu dans la fenêtre.
Archiver des constats d’accès externe sans noter pourquoi, forçant le prochain réviseur à replaider chaque compartiment.
Élaguer les permissions en laissant vivants les principaux inactifs eux-mêmes — un rôle inutilisé avec une politique de confiance active reste une surface d’attaque.

Garder le contrôle

Alarmez sur les nouveaux constats d’accès externe; ce sont des événements de sécurité, pas du carnet de retard.
Insérez la revue de dernier accès dans la revue d’accès trimestrielle que les auditeurs exigent déjà — même réunion, meilleures données.
Exigez que les nouveaux rôles partent d’un gabarit délimité, pas de PowerUserAccess, pour que la dette d’élagage arrête de composer.
Suivez une métrique simple par compte — constats actifs plus rôles avec politique admin — et donnez à quelqu’un la responsabilité de sa direction.

Le moindre privilège est un verbe : les comptes qui roulent la boucle se resserrent chaque trimestre, et les comptes qui comptent sur les bonnes intentions s’élargissent. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.