Hiérarchie des comptes et des sous-utilisateurs

(Section : Opérations et gestion)

1) Tâche et principes

La hiérarchie des comptes définit comment les organisations et les personnes accèdent aux ressources de la plate-forme et comment les droits, les quotas, les budgets et les responsabilités sont répartis.

• Séparation des concerts : la structure de l'entreprise est reflétée dans l'arbre des entités et les droits dans les politiques.
• Least Privilège : par défaut, les rôles minimaux, la promotion temporaire via JIT.
• Composability : les rôles/quotas/limites sont hérités et redéfinis.
• Policy-as-Code : politiques d'accès, quotas, facturation - artefacts versionnables.
• Auditabilité : chaque action est corrélée au sujet, au contexte et à la signature.

2) Modèle de référence de la hiérarchie

Tenant
├─ Account - legally/operationally significant unit
│ ├─ Sub-account - Product/Region/Team/Project
│ │ ├─ Spaces/Projects/Environments: prod/stage/dev
│ │ └─ Roles and Groups (RBAC/ABAC) for People and Services
│ └─ Shares (limits, budgets, keys, integrations)
└─ Marketplace/Integrations/Affiliates (Outer Loops)

• Tenant : propriétaire de contrats, facturation de haut niveau, politiques mondiales et SSO.
• Compte : zone de responsabilité isolée (marque/pays/BE) ; budgets/limites propres.
• Sous-compte : unité de travail (produit/flux/équipe) ; ses clés, ses quotas, ses rôles et ses audits.

3) Modèles d'autorisation

RBAC: роли Owner/Admin/Operator/Viewer/Billing/Compliance.
ABAC: атрибуты `region`, `tenant`, `account`, `environment`, `risk_score`, `device_posture`.
ReBAC : relation « propriétaire/participant/revuit » pour projets et secrets.

Pratique : hybride - RBAC en tant que base lisible, ABAC pour les contraintes contextuelles (région/temps/appareil), ReBAC pour la propriété des ressources.

4) Délégation et héritage

Délégation vers le bas : Tenant-admin donne le rôle Account Admin, celui-ci est Sous-account Maintainer.
Redéfinitions : les quotas/limites/politiques peuvent se resserrer dans l'arbre.
Trust Boundaries : PII/Finance - seulement dans les « zones de confiance » de niveau Compte ; Sous-compte voit les tokens/agrégats.
Break-glass : accès d'urgence avec TTL court, auto-alert et post-mortem.

5) Quotas, budgets, facturation

Quotas : requêtes/secondes, événements/jour, egress, stockage, clés/webhooks.
Budgets : caps mensuels et alertes (80/90/100 %), auto-trotting/suspension.
Facturation : factures au niveau Tenant/Account ; coupes par sous-compte et tags (cost centers).
Transfer Pricing : décharges internes entre les UB/régions.
Fair-use : limites publiques, taux-limites, protection contre les « burst ».

6) Identités et SSO/SCIM

SSO (SAML/OIDC) : entrée centralisée au niveau du Tenant.
SCIM : création/désactivation automatique des utilisateurs/groupes et ancrage aux rôles.
JML (Joiner/Mover/Leaver) : auto-émission des rôles de départ, révision lors de la traduction, révocation instantanée lors du licenciement.
MFA/FIDO2 : obligatoire pour les admins, la finance et l'accès aux IPI.
Device Posture : tolérance à l'état de l'appareil (cryptage, EDR).

7) Comptes de service et clés

Service Account per Sub-account + Environment, sans secrets partagés.
Workload Identity : tokens à courte durée de vie, ancrage au sous-sol/fonction.
KMS/Vault : rotation des secrets, accès par rôle, signature DSE.
Webhooks : signatures HMAC/EdDSA, 'nonce + timestamp', fenêtre TTL.

8) Modèle de données (simplifié)

`tenant` `{id, name, sso, billing_profile, policies[]}`

`account` `{id, tenant_id, region, legal_entity, quotas{}, budgets{}, risk_tier}`

`sub_account` `{id, account_id, product, environment, keys[], webhooks[], limits{}}`

`role` `{id, scope: tenant|account|sub_account, permissions[]}`

`membership` `{subject_id, role_id, scope_ref, ttl, justification}`

`policy` `{type: rbac|abac|sod|quota, version, rules, signature}`

`audit_event` `{who, what, where, when, trace_id, signature}`

`quota_usage` `{scope_ref, metric, window, used, cap}`

9) Contrats API

• 'POST/tenants/{ id }/accounts '- créer un compte (stratégies/quotas/facturation).
• 'POST/accounts/{ id }/sub-accounts '- créer un sous-compte (clés, webhooks).
• 'PUT/roles/{ id} 'est la stratégie du rôle ;' POST/membres 'est d'attribuer un rôle.
• 'POST/access/elevate '- Promotion JIT avec TTL et justification.
• « GET/quotas/usage » - utilisation/cap ; « POST/quotas/override ».

• `GET /audit/events? scope =... '- logs signés.
• « GET/status/access » - rôles/TTL/clés actifs.
• Вебхуки: `QuotaCapReached`, `RoleExpiring`, `KeyRotationDue`, `PolicyChanged`.

10) RACI (domaines clés)

11) Métriques et SLO

TTG (Time-to-Grant) : médiane d'émission de l'accès standard ≤ 4 h.
JIT Coverage : ≥ 80 % des opérations privilégiées via des rôles temporaires.
SoD Violations: 0 в prod; TTR de réparation ≤ 24 h.
Accès orphelin : part des droits « oubliés » ≤ 0. 1%.
Quota Accuracy : coïncidence charges/utilisation ≥ 99. 99%.
Vérification complète : 100 % des actions critiques avec signature/reçu.

12) Dashboards

Access Health : rôles actifs par niveau, TTL expirant, violations de SoD.
FinOps : utilisation des quotas, prévisions budgétaires, anomalies egress/compute.
Sécurité : rotation des clés, échecs de MFA/SSO, risque-score des cohortes.
Conformité : statut de recentification, audit-logs, violations de politiques.
Opérations : Demandes d'accès MTTR, TTFI pour les nouvelles commandes.

13) Séparation des données et vie privée

Domaines de données : PII/Finances - uniquement au niveau du compte ; Sous-compte - agrégats/tokens.
Régionalité : localisation des données et des clés par région (zones de confiance).
Demandes de PII : uniquement par l'intermédiaire de jobs approuvés ; Tokenisation et masquage.

14) Risques et anti-modèles

Modèle Flat : tous les « admins » → incidents et fuites.
Secrets partagés : Inviolabilité et impossibilité de revenir.
Pas de SoD : une personne crée et approuve des paiements/limites.
Environnements non résolus : clés dev dans prod ; mélange de données de test et de données réelles.
Les rôles « infinis » : sans TTL/recréation → accumulation de risques.
Quotas faibles : un sous-compte « mange » la capacité de tous.

15) Pleybooks d'incidents

Compromission de la clé du sous-compte : révocation immédiate, rotation des dépendances, recalculation des quotas, audit des 7 à 30 derniers jours.
Dépassement des quotas : TNT/pause automatique, notification au propriétaire, budget temporaire.
Violation de la SoD : blocage de l'opération, retrait temporaire du rôle, enquête et fixation de la politique.
Substitution de webhooks : interdiction de réception sans signature/en dehors de la TTL, re-key, status endpoint swerok.

16) Onbording et cycle de vie

1. Initialisation Tenant : SSO/SCIM, profil de facturation, politiques globales.
2. Création d'un compte : régions, quotas, budgets, zones de données, rôles de base.
3. Sous-compte : clés/webhooks, rôles de commande, intégration.
4. JML/Recertification : révision trimestrielle des droits, auto-retrait des « dormeurs ».
5. EOL : archive, révocation de clés, transfert de propriété, fermeture de la facturation.

17) Chèque de mise en œuvre

• Concilier l'arbre Tenant → Account → Sub-account et les règles d'héritage.
• Décrire les rôles (RBAC) et les politiques contextuelles (ABAC), matrice SoD.
• Démarrer SSO/SCIM, processus JML et élévation JIT.
• Introduire les quotas/budgets/règles de cap et l'alerte.
• Déployer KMS/Vault, rotation et interdire les secrets partagés.
• Inclure les stratégies-en-code, les versions signées et les journaux WORM.
• Configurer les API/webhooks de gestion, les endpoints de statut et les audits.
• Construire des dashboards Access/FinOps/Security/Compliance.
• Passer GameDay : fuite de clé, quota-tempête, panne d'IdP, violation de SoD.
• Recréer régulièrement les rôles et revoir les limites.

18) FAQ

Où garder la frontière entre le compte et le sous-compte ?
Lorsque les finances/conformité/réglementation (compte) changent et que le sous-compte est dédié à l'équipe/produit/environnement.

Les quotas de plusieurs sous-comptes peuvent-ils être « collés » ?
Oui, à travers les bassins et les priorités, mais avec des fusibles de « brûler » la capacité.

Quel est le délai pour délivrer un accès temporaire ?
Application JIT avec MFA et TTL, autologie et post mortem pour les séances privilégiées.

Avez-vous besoin de clés différentes le mercredi ?
Obligatoire : Comptes/clés de service séparés pour dev/stage/prod avec isolation des réseaux et des droits.

Résumé : La hiérarchie des comptes et des sous-utilisateurs est un cadre de gestion : structure lisible des entités, politiques héritées, quotas et facturation stricts, identités sécurisées et audit prouvable. Grâce à la mise en place de l'hybride RBAC/ABAC/ReBAC, JIT/SoD et policy-as-code, vous bénéficierez d'un engagement rapide, de coûts prévisibles et d'une sécurité durable lors de votre mise à l'échelle par produit, équipe et région.