Délégation de rôle et accès

(Section : Opérations et gestion)

1) Pourquoi la délégation de rôle

L'objectif est de donner à chaque participant (employé, partenaire, service) exactement autant de droits que nécessaire et exactement le temps nécessaire, avec une traçabilité complète des actions. Cela réduit les risques de fuites et d'abus, accélère l'onbording et le passage des audits.

2) Modèle d'accès : Niveaux et domaines

Domaines d'accès : personnes (console/panneaux), services (tokens machine), données (tables/objets), infrastructures (cloud/K8s), contreparties (intégrations externes), régions/tenants.
Niveaux de confiance : public → interne → protégé (PII/finances) → particulièrement critique (clés/décaissements).
Zones d'opérations : prod/staging/sandbox ; la règle "de" ci-dessous dans "ci-dessus" est uniquement par l'intermédiaire de pipeline approuvée ".

3) Modèles d'autorisation

RBAC : les rôles sont liés aux tâches (« Éditeur de contenu », « Opérateur de paiement »). Départ simple, facile à vérifier.
ABAC : politiques par attribut sujet/ressource/contexte (région, tenant, changement, appareil, risque-scoring).
ReBAC (relationship-based) : les droits proviennent des liens (propriétaire du projet, membre de l'équipe).
Hybride : RBAC pour la matrice de base, ABAC pour les contraintes contextuelles, ReBAC pour la propriété.

4) Accès minimum requis (Least Privilège)

Le début est un rôle minimum par défaut (read-only, sans PII).
Promotion - uniquement par le biais d'une demande avec justification, durée et propriétaire.
Limite de temps (TTL) : les droits « fondent » automatiquement ; extension - consciemment.
Raids de garde contextuels : région/tenant, heures d'ouverture, appareil, géo.

5) Partage des responsabilités (SoD)

• « Commence les limites » ≠ « approuve les limites ».
• « Prépare le paiement » ≠ « signe le paiement ».
• « Écrit le code » ≠ « va sortir dans prod ».
• Admin DB ≠ « lit PII en analyse ».
• Implémentez la SoD dans les stratégies et dans les processus eux-mêmes (à deux volets, M-of-N).

6) Processus JML (Joiner/Mover/Leaver)

Joiner : auto-attribution des rôles de base par poste/équipe/région, chèque d'accès en 24h.
Mover : redéfinir les rôles lors du changement d'équipe/projet ; retrait automatique des « anciens » droits.
Leaver : rappel de sessions, clés, jetons ; transfert de secrets, transfert de possessions par des artefacts.

7) Privilèges temporaires : JIT/PAM

Just-In-Time (JIT) : Soulever les droits sur une demande de 15 à 240 minutes avec l'AMF et la justification du tiquet.
PAM (Privilège Access Management) : proxy/connexion « sous le compte shell », enregistrement des sessions, journal de commande.
Break-glass : accès d'urgence avec alert instantané, TTL court et post mortem obligatoire.

8) Identités des services et clés

Comptes de service : distincts pour chaque service et environnement, pas de secrets partagés.
Workload Identity : lier les tokens au sous-sol/wire/fonction ; des creds à courte vie.
Secrets : KMS/Vault, rotation, cryptage à deux chiffres, interdiction d'entrer dans les logs.
Clés de signature/paiement : threshold/MPC, hardware HSM, diversité par domaine de confiance.

9) SSO/MFA/SCIM et cycle de vie des comptes

SSO : IdP (SAML/OIDC), connexion unique, stratégies centralisées de mots de passe/périphériques.
MFA : obligatoire pour les admins/finances/PII ; de préférence FIDO2.
SCIM : création/suppression/modification automatique des comptes et des groupes.
Device Posture : accès conditionnel à l'état de l'appareil (cryptage de disque, EDR, correctifs à jour).

10) Politiques-comme-code et vérification

OPA/Service d'autorisation : politiques sous forme de code (Rego/JSON), ronflements via PR, tests.
Contrôle de la dérive : comparaisons régulières « déclaré par vs en fait ».
« La politique autorisera-t-elle une telle opération ? » - testez les mallettes avant la sortie.

11) Accès aux données

Classification : public/intra/limité/PII/finance.
Pression « minimale » : agrégats/masques au lieu de données « brutes » ; demandes PII - uniquement par l'intermédiaire de jobs approuvés.
Tokenization/DE-ID : remplacement des identifiants, audit des requêtes.
Couches : prod → répliques → vitrines → agrégats ; l'accès direct à la prod-OBD est uniquement JIT/PAM.

12) Cloud, K8s, réseaux

Cloud IAM : rôles per-account/projet ; L'interdiction « Admin » par défaut ; Limiter les actions par tags/dossiers.
Kubernetes : RBAC sur les neimspaces, PSP/politiques similaires sans « privilège », image-allowlist, secrets via CSI, comptes de service per-pod.
Réseau : Zero-Trust (mTLS, identity-aware), accès à jump-host - JIT uniquement, enregistrement des sessions SSH.

13) Partenaires externes et intégrations

Tenants/clés isolés, un minimum de boucles de OAuth2, des tokens TTL courts.
Webhooks : signature (HMAC/EdDSA), 'nonce + timestamp', fenêtre de réception étroite.
Rotation des clés selon les horaires, révocation en cas de compromission, état-endpoint pour « santé ».

14) Audit, recertification, rapports

Immutabilité : journaux WORM, signatures de versions de stratégies, sections Merkle.
Recertification : vérification trimestrielle des rôles critiques, mensuelle - admin-right.
Quarantaine des droits : « 60 jours inutilisés » → auto-retrait.
Evidence pack : déchargement de la matrice des rôles, des déclenchements SoD, des applications JIT, enregistrement des sessions PAM.

15) Métriques et SLO

TTG (Time-to-Grant) : la médiane de la distribution de l'accès selon la demande standard (le but ≤ 4ч).
Part des accès JIT parmi les « privilégiés » (objectif ≥ 80 %).
SoD-violences : 0 en prod, temps d'élimination ≤ 24h.
Droits orphelins :% des utilisateurs ayant des droits redondants (objectif → 0. 0x%).
Rotation des secrets : âge moyen du secret (objectif ≤ 30 jours pour les personnes sensibles).
Audit-couverture : 100 % des actions privilégiées avec des artefacts (dossiers, reçus).

16) Dashboards

Access Health : rôles actifs, droits orphelins, JIT vs permanents.
PAM & Sessions : nombre de sessions privilégiées, durée, succès du MFA.
SoD & Incidents : statistiques de blocage, causes, MTTR.
Secrets & Keys : âge, rotation à venir, clés « rouges ».
JML : SLA onbording/offbording, demandes en retard.
Audit Evidence : statut de recentification trimestrielle, completeness 100 %.

17) Pleybooks d'incidents

Compromission token/clé : rappel immédiat, recherche globale d'utilisation, rotation des dépendances, audit rétro en N jours.
Violation SoD : bloc d'opération, désactivation temporaire du rôle, post-mortem et changement de stratégie.
Accès non autorisé aux IPI : isolement, notification au DPO, inventaire des fuites, procédures légales.
Escalade abuse : gel du JIT pour le sujet/l'équipe, analyse des demandes/justifications, ajustement des limites de TTL.

18) Pratiques opérationnelles

Quatre yeux sur la délivrance/modification des droits critiques.
Répertoire des rôles décrivant les tâches, les risques et les opérations admissibles.
Environnements de test avec données anonymes et autres rôles.
Politique dry-run : simulation des conséquences des changements avant application.
JeuxDays par accès : « perte d'IdP », « panne PAM », « fuite de secret ».

19) Chèque de mise en œuvre

• Former une taxonomie des rôles et une matrice SoD par processus clés.
• Inclure SSO + MFA pour tous, les flux SCIM pour JML.
• Déployer PAM/JIT, configurer le break-glass avec alerts et TTL court.
• Entrez des politiques-code (OPA), des révisions par l'intermédiaire des RP et des auto-tests.
• Comptes-services et identités de travail distincts ; l'interdiction des secrets partagés.
• Vault/KMS, rotation régulière des secrets et des clés, interdiction des secrets dans le code/les logs.
• Séparer les environnements et les régions, consolider les règles d'accès transversal régional.
• Lancez Dashboards et SLO, rapports mensuels de recertification.
• Effectuer un scan SoD du graphe a raison et éliminer les voies d'escalade.
• Exercices réguliers et post-mortems avec des items d'action.

20) FAQ

RBAC ou ABAC ?
RBAC est la couche de base de la lisibilité, ABAC est le contexte et la dynamique. Utilisez un hybride.

Est-ce que PAM est nécessaire s'il y a un JIT ?
Oui : PAM permet d'enregistrer les sessions et les canaux d'accès privilégié gérés.

Comment réduire le « gonflement » des droits ?
TTL sur le rôle, auto-retrait inutilisé, recertification mensuelle et SoD-alerte.

Que faire des sous-traitants ?
Tenants/groupes isolés, scoops limités, TTL courts, rapports obligatoires et recertification.

Résumé : La délégation de rôle et l'accès ne sont pas un « jeu de cases », mais un cycle de vie de droits : rôles minimaux requis, SoD, JIT/PAM, politique-code, observabilité et recertification régulière. Ce circuit permet aux équipes de travailler rapidement et de garantir une sécurité prévisible pour les entreprises et l'audit.