AWS IAM — comment une requête API est réellement évaluée

Deny explicite, garde-fou d'organisation, limite de permissions, politique d'identité ou de ressource : l'intersection gagne

AWS IAM — comment une requête API est réellement évaluée Deny explicite, garde-fou d'organisation, limite de permissions, politique d'identité ou de ressource : l'intersection gagne 01 / Requête 02 / Évaluation 03 / Résultat 04 / Trace 1 · Appel API · requête signée (SigV4) · Requête · requête 1 · Appel API requête signée (SigV4) requête 2 · Contexte · principal, action, ressource · Requête · conditions 2 · Contexte principal, action, ressource conditions 3 · Deny explicite · une politique refuse · Évaluation · gagne toujours 3 · Deny explicite une politique refuse gagne toujours 4 · Garde-fou SCP · plafond du compte · Évaluation · compte AWS 4 · Garde-fou SCP plafond du compte compte AWS 5 · Politiques · identité, ressource, borne · Évaluation · autorisation 5 · Politiques identité, ressource, borne autorisation 6 · Décision · session, Allow ou deny implicite · Résultat · deny par défaut 6 · Décision session, Allow ou deny implicite deny par défaut 7 · Journal · CloudTrail, Access Analyzer · Trace · preuve 7 · Journal CloudTrail, Access Analyzer preuve journalise aucun refus explicite autorisation ∩ plafonds SCP autorise Legend Policy Context / trace Cloud service External system

Les 5 familles de politiques

  • • Politiques d'identité (utilisateur ou rôle) et politiques de ressource (seau, clé, file) : l'une décrit qui agit, l'autre protège l'objet
  • • Garde-fous d'organisation : les SCP plafonnent tout ce que le compte peut faire, y compris pour sa racine
  • • Limite de permissions : un plafond attaché à un principal — elle n'accorde jamais rien par elle-même
  • • Politique de session : un plafond supplémentaire, appliqué le temps de la session
  • • Certains services ajoutent des ACL ou des politiques de point de terminaison VPC : même logique d'intersection, à vérifier service par service

Moindre privilège concret

  • • Restreindre l'action ET la ressource : lire un préfixe nommé, jamais tout le service sur tout le compte
  • • Utiliser les conditions : réseau d'origine, tags de principal, présence du MFA, émetteur de la fédération
  • • Préférer les rôles et la fédération aux clés d'accès ; borner la durée des sessions
  • • Réviser les politiques à chaque changement de périmètre, pas seulement la veille de l'audit

Pièges

  • • Wildcard sur l'action ou la ressource : une politique large survit plus longtemps que son intention
  • • Clés d'accès longue durée dans un pipeline ou un poste : des secrets qui ne tournent jamais
  • • Politique de ressource qui autorise un principal inattendu : le plus court chemin vers la fuite
  • • Un deny explicite l'emporte toujours : le tester avant la production, pas pendant l'incident