tadata
← Retour à l'accueil

Gestion des Identités & des Accès : Principes, Modèles & Stratégie Multi-Cloud

#security#iam#cloud#governance#compliance

L'IAM est le périmètre de sécurité des organisations cloud-native. Chaque appel API, chaque accès aux données, chaque déploiement est une identité qui fait une requête. Bien faire l'IAM signifie le moindre privilège par défaut, l'auditabilité partout, et zéro accès permanent comme objectif.

Comparaison des Modèles de Contrôle d'Accès

ModèleFonctionnementGranularitéScalabilitéIdéal pour
RBAC (Basée sur les rôles)Utilisateurs assignés à des rôlesNiveau rôleBonne (<100 rôles)La plupart des organisations
ABAC (Basée sur les attributs)Politiques évaluent des attributsNiveau attributExcellenteAccès dynamique, décisions contextuelles
PBAC (Basée sur les politiques)Moteur de politiques centraliséNiveau politiqueExcellenteMulti-cloud, conformité complexe
ReBAC (Basée sur les relations)Accès selon les relations ressource-utilisateurNiveau relationExcellentePartage de documents, apps collaboratives
ACL (Liste de contrôle d'accès)Liste par ressource des identités autoriséesNiveau ressourceFaibleSystèmes de fichiers simples
tadata
  • New system
    • → Legal labels (classified, health)?
      • Yes: MAC + audit
      • No: Users share their own objects?
        • Yes: ReBAC (or DAC for files)
        • No: Context matters (time, device, tag)?
          • Yes: RBAC + ABAC conditions
          • No: RBAC
Choisir un modèle de départ

Extrait de la fiche « Access Control Models: DAC, MAC, RBAC, ABAC, ReBAC » · Demander la fiche complète

Checklist des Principes IAM

PrincipeDescriptionImplementation
Moindre privilègeAccorder le minimum de permissionsCommencer à zéro, ajouter selon besoin ; revue trimestrielle
Séparation des responsabilitésAucune identité ne peut compléter seule un workflow critiqueApprobation multi-parties pour les changements production
Zéro accès permanentPas d'accès privilégié permanentAccès just-in-time (JIT) avec élévation temporaire
Défense en profondeurPlusieurs couches de contrôle d'accèsRéseau + IAM + autorisation applicative
Présumer la compromissionConcevoir comme si le périmètre était déjà compromisMicro-segmentation, vérification continue
AuditabilitéChaque décision d'accès est loguéeCloudTrail, logs d'audit, intégration SIEM
Rotation des credentialsSecrets et clés ont une durée de vie définieAuto-rotation via Vault, AWS Secrets Manager
MFA partoutMulti-facteur pour tout accès humainClés physiques pour admins, TOTP minimum pour tous
tadata

Actors: Admin, PIM, Approver, Entra ID, SIEM

  1. Admin → PIM activate eligible role, justification + ticket, duration (e.g. 2 h)
  2. PIM ⇠ Admin step-up: phishing-resistant MFA via authentication context
  3. PIM → Approver approval request (roles marked require approval)
  4. Approver ⇠ PIM approve with reason
  5. PIM → Entra ID time-bound active assignment created
  6. Entra ID → SIEM audit: Add member to role completed (PIM activation)
  7. PIM → Entra ID assignment expires automatically; no one has to remember
Activation PIM d'un rôle éligible : le privilège n'existe qu'entre les étapes 5 et 7, et chaque étape figure dans le journal d'audit Entra

Extrait de la fiche « Cloud Entitlement Management and Least Privilege » · Demander la fiche complète

Mapping IAM Multi-Cloud

ConceptAWSGCPAzureKubernetes
Fournisseur d'identitéIAM Users / SSOCloud IdentityEntra IDServiceAccount / OIDC
Rôle / principalIAM RôleIAM RôleManaged IdentityClusterRole / Rôle
Identité de serviceIAM Rôle pour serviceService Account GCPManaged IdentityK8s ServiceAccount
Identité workloadIRSAWorkload Identity FederationWorkload Identity FederationTokens SA projetés
Credentials temporairesSTS AssumeRoleTokens court termeTokens Managed IdentityTokenRequest API
Périmètre de permissionsPermission BoundaryOrganization PolicyAzure PolicyOPA / Kyverno
Langage de politiqueJSON (IAM Policy)YAML (IAM bindings)JSON (ARM/Bicep)YAML (RBAC manifests)

Matrice de Gestion des Comptes de Service

AspectBonne pratiqueAnti-patternRisque si ignoré
NommageDescriptif : svc-billing-api-prodGénérique : admin, service-account-1Inauditable
Rotation des clésAuto-rotation tous les 90 jours maxClés statiques jamais changéesCredentials compromis persistants
PérimètreUn SA par workloadSA partagé entre servicesRayon d'explosion élargi
PermissionsLimitées aux actions API exactesPermissions admin/ownerMouvement lateral
Stockage des clésVault, secret manager cloudVariables d'env, dépôts gitFuite de credentials
Cycle de vieDécommissionner avec le workloadSAs orphelins accumulésSurface d'attaque inutilisée
tadata
GitHub job GitHub OIDC provider Microsoft Entra ID Azure ResourceManager 1. request ID token(permissions: id-token:write) 2. JWT: isstoken.actions.githubusercontent.com,subrepo:contoso/web:environment:prod 3. azure/login: client assertion = JWT, client-id, tenant-id 4. match issuer + subject +audienceapi://AzureADTokenExchange 5. access token (about 1 h) 6. az deployment group create (RBAC on the RG)
GitHub job GitHub OIDC provider Microsoft Entra ID Azure ResourceManager 1. request ID token(permissions: id-token:write) 2. JWT: isstoken.actions.githubusercontent.com,subrepo:contoso/web:environment:prod 3. azure/login: client assertion = JWT, client-id, tenant-id 4. match issuer + subject +audienceapi://AzureADTokenExchange 5. access token (about 1 h) 6. az deployment group create (RBAC on the RG)
Workload identity federation depuis GitHub Actions ; Azure Pipelines fait de même avec une service connection ARM de type workload identity federation (émetteur vstoken.dev.azure.com)

Extrait de la fiche « AZ-400 Domain 3c: IaC and Deployments in Pipelines » · Demander la fiche complète

Architecture IAM Multi-Cloud

tadata
Fournisseur d'identité(IdP) : Okta / Entra ID/ Google Workspace ; SSO+ MFA + SCIM AWS : IAM/SSO GCP : WorkloadIdentity Azure : Entra ID Workload (EKS) Workload (GKE) Workload (AKS) SAML / OIDC SAML / OIDC SAML / OIDC Cloud Workloads Architecture IAM multi-cloud
Fournisseur d'identité(IdP) : Okta / Entra ID/ Google Workspace ; SSO+ MFA + SCIM AWS : IAM/SSO GCP : WorkloadIdentity Azure : Entra ID Workload (EKS) Workload (GKE) Workload (AKS) SAML / OIDC SAML / OIDC SAML / OIDC Cloud Workloads Architecture IAM multi-cloud

Transverse : OPA/Cedar pour une évaluation unifiée des politiques. Audit : SIEM centralisé (Splunk, Elastic, Datadog).

Ressources

Nous utilisons des cookies analytiques pour améliorer votre expérience. Aucune donnée personnelle n'est collectée.