Identity & Access Management

Résumé succinct

L'IAM est un ensemble de processus, de politiques et d'outils qui garantissent qui accède à quoi, à quelles conditions et comment cela est contrôlé. Objectifs : minimisation des droits redondants, réduction de la surface d'attaque, accélération de l'onbording et de l'audit, conformité (PCI DSS, GDPR, etc.) et fiabilité d'accès mesurable.

Notions de base

Identité (Identity) : personne (employé, entrepreneur), service/application, appareil.
Authentification (AuthN) : Vérifie « qui » (mot de passe → MFA → circuits sans parole FIDO2/passkeys).
Autorisation (AuthZ) : solution « ce qui est autorisé » (RBAC/ABAC/ReBAC, politiques).
Identifiants (Credentials) : mots de passe, clés, jetons, certificats (mTLS).
Gestion des secrets : KMS/HSM/Vault, rotations, TTL courts, secrets dynamiques.
Cycle de vie : Joiner-Mover-Leaver (JML) : Création, modification de rôles, rappel.

Architecture IAM cible

• IdP (fournisseur d'identité) : SSO, MFA, catalogue, fédération (OIDC/SAML), politiques de risque.
• PDP/PEP : Decision/Enforcement est un moteur de stratégie (OPA/Cedar) + points d'application (passerelles API, proxy, mesh-service).
• Catalogues/système RH : source de vérité selon les employés et les rôles.
• Providence : SCIM/Automation pour la création/modification/révocation d'accès.
• Audit : logiques centralisées, UEBA, rapports sur les rôles et les accès.

• SSO (+ MFA) → la sortie du token (OIDC/JWT/SAML) → PEP vérifie le token/contexte → PDP décide par stratégie (rôle/attributs/risque) → l'application délivre/refuse l'accès.

Authentification : des mots de passe aux passkeys

Mots de passe : seulement avec les gestionnaires de mots de passe, minimum 12-14 caractères, pas de rotation « selon le calendrier », mais avec obligatoire en cas d'incident.
MFA par défaut : TOTP/WebAuthn/Push ; éviter le SMS comme facteur principal.
Entrée sans parol : FIDO2/passkeys pour les domaines critiques.
AuthN adaptatif : prendre en compte le signal de risque (géo, ASN, appareil, anomalies) → exiger un facteur/blocage supplémentaire.

Autorisation : RBAC, ABAC, ReBAC

RBAC : rôles correspondant aux fonctions (Support, Finance, DevOps). Simple et compréhensible, mais « grandit ».
ABAC : règles par attribut (ministère, niveau de risque, heure, zone, étiquettes de ressources). Évolutif.
ReBAC : relation « qui se rapporte à quoi » (porteurs de projets, membres d'équipes). Pratique pour les scénarios multitenants.

• Combiner RBAC (grille de base) + ABAC/ReBAC (contexte/frontières).
• JIT (Just-In-Time) : émission de privilèges temporaires par demande/appel, révocation automatique.
• JEA (Just-Enough Access) : droits de transaction minimalement suffisants.
• PAM : accès isolés « forts » (admins OBD/cloud) avec courtier de session, enregistrement d'écran/commandes et émission de creds à courte durée de vie.

Fédération et SSO

Protocoles : OIDC (jetons JWT), SAML 2. 0 (XML asserties) - pour les fournisseurs/partenaires externes.
SSO : point d'entrée unique avec MFA, réduction du phishing, rappel centralisé.
B2B/B2C : fédération avec des partenaires, limitation des zones, politiques de domaine.
mTLS/m2m : pour les services, utilisez x.509 (SPIFFE/S....) ou OAuth2 Client Credentials.

Cycle de vie (JML) et Provivining

Joiner : SCIM-provisionnement automatique des comptes et des rôles de base de HR/catalogue.
Mover : les rôles changent automatiquement en fonction des attributs (subdivision, projet, localisation).
Leaver : révocation immédiate des SSO, clés, tokens, accès aux référentiels/cloud/CI/CD.
Processus : demandes d'accès (ITSM), matrice SoD (partage des responsabilités), examen périodique de l'accès.

Secrets, clés et rotations

KMS/HSM : stockez les clés racines/critiques, activez l'audit des opérations.
Gestionnaires Vault/Secrets : Crédits dynamiques (OBD, nuages), Auto-rhubarbe à la fin de la TTL.
Rotations : jetons OAuth, clés de signature JWT, mots de passe des services - programmés et en cas d'incident.
mTLS : certificats à courte durée de vie (heures/jours), transfert automatique.

Politiques et moteur de décision

Déclaration : stockez les politiques dans Git ; vérifier auprès de l'IC (policy-tests).
Contexte : temps/localisation/ASN/niveau de risque/état de l'appareil (MDM/EDR).

rego package authz. payments default allow = false

allow {
input. user. role == "finance"
input. device. compliant == true input. action == "read"
input. resource. type == "report"
time. now_hh >= 8 time. now_hh <= 20
}

Surveillance, SLO et audit

• Succès AuthN/AuthZ (%), p95 temps login/solution, proportion MFA/entrées sans barol.
• Kol dans les escalades JIT/PAM, durée moyenne des privilèges.
• Couverture des dispositifs compliants, proportion de secrets à courte durée de vie.

• Disponibilité SSO/IdP ≥ 99. 95 % par mois.
• p95 AuthZ decision ≤ 50 мс.
• 100 % déconnexion du compte ≤ 15 minutes après offboarding.
• Audit et UEBA : logiques centralisées immuables (accès, changements de rôle, entrées ratées, solutions PDP), analyse comportementale et anxiété sur les anomalies.

Incident response dans IAM

Compromission des tokens/clés : révocation immédiate, logout forcé, rotation des clés de signature, re-issue des secrets à vie courte.
Abus de droits : suspendre le compte, bloquer JIT/JEA, effectuer un examen d'accès sur les entités voisines.
IdP n'est pas disponible : modes hors ligne (Temporel Cache Validation Tokens Short TTL), procédures de restauration prioritaires.
Phishing : MFA obligatoire, contrôles de risque des sessions, notifications aux utilisateurs, formation.

Nuages et Kubernetes (modèles)

IAM Cloud public : utilisez des rôles natifs avec le principe du least privilège ; au lieu des clés « éternelles », les charges de travail avec la fédération OIDC vers le cloud (IRSA/Workload Identity).
Kubernetes : RBAC par neuspace/rôles, limiter « cluster-admin » ; secrets - par l'intermédiaire de gestionnaires externes ; service-mesh + OPA pour les politiques L7 ; Admissions-contrôleurs (images signées, interdiction « : latest »).
passerelles API : vérification JWT/mTLS, limites de vitesse, signatures de requête (HMAC) pour les endpoints sensibles.

Pratique pour iGaming/fintech

Domaines d'accès : paiements, antifrod, PII, fournisseurs de contenu - isoler les rôles et les segments de réseau.
SoD : interdiction de combiner des rôles conflictuels (par exemple, création d'une promo + approbation de paiement).
PAM et JIT : pour accéder à PSP/banques et prod-OBD - uniquement par l'intermédiaire d'un courtier de session, avec enregistrement et auto-rappel.
Conformité : DSS PCI - MFA, privilèges minimums, segmentation de la zone CHD ; Le RGPD est le principe de la minimisation des données et des logs d'accès aux PII.
Partenaires et fournisseurs de contenu : fédération et per-tenant de la politique ; Tokens à courte vie et IP/ASN allow-list.

Erreurs typiques

Clés et jetons « éternels » : pas de rotation et TTL → risque élevé de fuites.
Offboarding manuel : retards dans la révocation des droits → accès « fantômes ».
Rôles monolithes : un « super rôle » au lieu de la composition et des attributs.
MFA uniquement en admin : Les MFA doivent être pour toutes les entrées et opérations critiques.
Logs « nulle part » : absence de centralisation et d'UEBA → détection tardive des incidents.

Feuille de route pour la mise en œuvre de l'IAM

1. Inventaire des utilisateurs/services/ressources ; carte de données et de sensibilité.
2. SSO + MFA pour tous, inclure les facteurs de résistance au phishing.
3. Modèle de rôle : RBAC + attributs de base (ABAC) pour le contexte ; matrice SoD.
4. SCIM Provivining : Auto-sortie/modification/retrait des droits de HR/catalogue ; demandes et aprouves à l'ITSM.
5. PAM et JIT/JEA : pour les accès privilégiés ; enregistrement des sessions, court TTL.
6. Gestion des secrets : refus des clés statiques ; secrets dynamiques, rotations, mTLS avec certificats courts.
7. Politiques dans Git + CI : tests de règles, contrôle des changements, déploiements de politiques canaries.
8. Observabilité et SLO : AuthN/AuthZ dashboards, alertes, examen d'accès régulier.

Exemples d'artefacts

AWS IAM Policy (minimum pour la lecture des rapports S3)

json
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "ReadOnlyReports",
"Effect": "Allow",
"Action": ["s3:GetObject","s3:ListBucket"],
"Resource": [
"arn:aws:s3:::reports-bucket",
"arn:aws:s3:::reports-bucket/"
],
"Condition": {
"IpAddress": { "aws:SourceIp": "203. 0. 113. 0/24" }
}
}]
}

Kubernetes RBAC (développeur namespace-scoped)

yaml apiVersion: rbac. authorization. k8s. io/v1 kind: Role metadata:
name: dev-read-write namespace: app-prod rules:
- apiGroups: ["","apps"]
resources: ["pods","deployments","services","configmaps"]
verbs: ["get","list","watch","create","update","patch","delete"]
apiVersion: rbac. authorization. k8s. io/v1 kind: RoleBinding metadata:
name: dev-bind namespace: app-prod subjects:
- kind: User name: alice@example. com roleRef:
kind: Role name: dev-read-write apiGroup: rbac. authorization. k8s. io

OIDC : approbations pour ABAC (exemple)

json
{
"sub": "d81f0b5c-...",
"email": "bob@example. com",
"dept": "finance",
"role": "analyst",
"device_compliant": true,
"tenant": "casino-eu"
}

Une stratégie peut exiger que 'device _ compliant = true' et 'tenant' correspondent à la ressource.

Check-list

• SSO inclus pour toutes les applications ; MFA par défaut, passkeys en priorité.
• RBAC défini ; L'ABAC/ReBAC ajoute un contexte ; Mise en œuvre de JIT/JEA.
• PAM protège les accès privilégiés ; les séances sont enregistrées.
• SCIM-providence de HR ; l'offboarding est entièrement automatisé.
• Les secrets sont dynamiques, avec un court TTL ; les rotations sont automatisées.
• Les politiques sont converties en Git, testées en IC ; Il y a des canaries.
• Dashboards et SLO par AuthN/AuthZ ; logiques centralisées et UEBA.
• Examen périodique de l'accès et contrôles SoD ; rapports pour la conformité.

FAQ

Est-ce que tout le monde a besoin de ReBAC ?
Non. Pour les environnements simples, RBAC + ABAC suffit. ReBAC est utile dans une hiérarchie complexe de la propriété des ressources et de la multitenance.

Puis-je garder mes comptes locaux ?
Uniquement pour les scénarios break-glass et hors ligne, avec des restrictions strictes et des contrôles périodiques.

Comment réduire l'explosion des rôles ?
Augmenter la granularité des ressources, utiliser AVAS/modèles, automatiser la rhubarbe et abandonner les rôles inutilisés.

Résultat

L'architecture IAM mature est un SSO + MFA, un minimum de droits nécessaires, un JML automatisé, des politiques centralisées et une observabilité. En combinant RBAC avec des modèles d'attributs et relationnels, en appliquant JIT/JEA et PAM, et en automatisant la provision et la rotation des secrets, vous obtenez un accès gérable, vérifiable et évolutif qui répond aux exigences de sécurité et d'entreprise.