Segmentation des privilèges

1) Pourquoi la segmentation est nécessaire

La segmentation des privilèges est la clé pour réduire les erreurs « blast radius » et les abus d'initiés. Il permet de limiter exactement qui et où peut effectuer les actions avec les données, tout en conservant la vitesse des opérations et la conformité des régulateurs.

• moins d'incidents dus à des « abus de droits » ;
• accélérer les enquêtes : les accès sont transparents et compréhensibles ;
• Conformité SoD/conformité, vérification prouvable ;
• des expériences sûres et des sorties rapides sans risque pour le noyau prod.

2) Principes

Zero Trust : chaque action est validée contextuellement ; Il n'y a pas de "zones confiées".
Least Privilège : droits minimums accordés pour une durée minimale (idéalement JIT).
Contexte over Role : les droits dépendent non seulement du rôle, mais aussi des attributs (tenant, région, environnement, risque).
Segregation of Duties (SoD) : nous partageons l'initiation, l'approbation, l'exécution et l'audit.
Policy-as-Code : politiques en code avec versioning, tests et rhubarbe.

3) Modèle de maturité d'accès

1. RBAC (roles) : début - rôles fixes (Support, Risque, Paiements, Trading, Ops, SRE, Conformité).
2. ABAC (attributes) : nous ajoutons les attributs : tenant, région, juridiction, produit, canal, environnement (prod/stage/dev), temps, classe de risque de l'opération, signaux KRI.
3. PBAC (policy-based) : politiques centralisées « qui/quoi/où/quand/pourquoi » + conditions (par exemple, « dans la vente - uniquement par JIT et avec tiquet »).

4) Domaines de segmentation (axe après axe)

4. 1 Tenant/client

L'accès et les opérations sont limités à une marque/opérateur/affilié spécifique.
Les actions transtentes sont interdites à l'exception des agrégations strictement définies sans PII.

4. 2 Région/juridiction

Les politiques tiennent compte des règles de licence locales et KYC/AML.
Les opérations de données du joueur sont limitées par la géographie du stockage et du traitement.

4. 3 Environnement (dev/stage/prod)

Prod est isolé : creds individuels, réseaux, Bastion/PAM, « read-only ».
Accès à prod uniquement JIT, avec tiquet et fenêtres de changement.

4. 4 Classe de données

PII/finance/jeux télémétrie/techniques - différents niveaux d'accès et de masquage.
L'exportation de PII se fait uniquement par le biais de workflow approuvé avec cryptage et TTL.

4. 5 Criticité des opérations

Classes de P1/P2/P3 : publication de coefficients, points manuels, conclusions, changement de routage PSP - nécessite un contrôle double.
Les opérations à bas risque peuvent être auto-activées par la politique.

5) Niveaux de privilège (tiers)

Viewer : lecture uniquement des agrégats et des données masquées.
Operator : Exécutez des procédures par Ranbook sans modifier les configurations.
Contributor : Modifie les configurations des domaines non critiques.
Approver : approbation des demandes et des opérations à risque élevé (non combinée à l'exécution - SoD).
Admin (JIT) : promotion à court terme pour les tâches rares sous double contrôle et enregistrement de session.

6) SoD et rôles incompatibles

• Lancer des conclusions ≠ approuver ≠ mener à bien.
• Créez une campagne bonus ≠ activez la vente ≠ modifiez les limites.
• Développer fich ≠ apprivoiser la sortie ≠ être jeté dans la prod.
• Demander le déchargement PII ≠ approuver ≠ déchiffrer.

Pour chaque paire, une politique officielle d'interdiction et d'exclusion avec une date de révision.

7) Accès JIT et PAM

Elevation sur demande : objectif/ticket/délai indiqué ; après l'expiration - auto-avis.
Contrôle double : Les actions P1/P2 sont deux appellations de fonctions différentes.
Contrôle de session : enregistrement des sessions critiques, alertes des anomalies, interdiction du copipast lorsque vous travaillez avec PII.
Break-glass : accès d'urgence avec des limites strictes et un post-audit obligatoire.

8) Comptes de service et OPI

Écorces minimales ; la division par tâches/microservices ; jetons/certificats à courte durée de vie.
Rotation des secrets, interdiction des secrets partagés ; interdiction du « god-scope ».
Limites de rate/quotas, clés d'identité, signature Web HMAC.

9) Segmentation au niveau de l'infrastructure

Réseaux : isolation des segments (per-domain/per-tenant), interdiction d'egress par défaut, mTLS.
Kubernetes/Cloud : neimspace/projets par environnement et domaine, Gatekeeper/OPA pour interdire les modèles dangereux.
OBD/Cache : courtier d'accès (DB proxy/IAM), lecture uniquement par défaut, interdiction de DDL dans la vente hors fenêtre.
Stockages : différentes clés/baquets de données par classe avec des stratégies TTL et WORM pour l'audit.

10) Politiques en tant que code (PaC)

Politiques dans les référentiels (Rego/YAML), PR, auto-tests (unit/e2e), audit diff.
Contexte dynamique : heure de la journée, emplacement, niveau KRI, risque-scoring de l'opération.
L'explication de la décision allow/deny et la référence à la politique dans l'audit.

11) Revues et audits

Exhaustivité : qui/quoi/où/quand/pourquoi, avant/après-valeur, ID ticket.
Inamovibilité : collecte centralisée, WORM/immutable, signature des enregistrements.
Connectivité : chaîne de la console admin → API → OBD → fournisseurs externes.
SLA Audit : rapidité de réponse aux demandes de contrôle/régulateur.

12) Dashboards et métriques (KPI/KRI)

Accès KPI : part des droits permanents JIT vs, durée moyenne des privilèges, % des droits couverts par SoD, temps de traitement des demandes, couverture des reversements.
KRI abus : surtensions d'opérations sensibles, décharges massives, emplacements/heures atypiques, séquences « zayavka→deystviye→otkat ».
Exec-dashboard : piste d'état des rôles à haut risque, événements break-glass, tendances.

13) Exemples de politiques (croquis)

Prod-операции: `allow if role in {Operator, Admin} AND env=prod AND jit=true AND ticket!=null AND sod_ok AND time in ChangeWindow`.
Экспорт PII: `allow if data_class=PII AND purpose in ApprovedPurposes AND ttl<=7d AND encryption=ON AND approvers>=2`.
PSP-роутинг: `allow if action=UpdateRouting AND dual_control AND risk_assessment_passed AND rollback_plan_attached`.

14) Feuille de route pour la mise en œuvre (8-12 semaines)

Ned. 1-2 : inventaire des opérations/rôles/données, matrice SoD, classification des données et domaines de segmentation.
Ned. 3-4 : Base RBAC, annuaire des rôles, JIT pour consoles pro, début du PaC (OPA/Gatekeeper).
Ned. 5-6 : ABAC : attributs tenant/région/environnement/classe de données ; séparation des projets et des projets.
Ned. 7-8 : PAM (JIT-elevation, enregistrement des séances, break-glass), interdiction de DDL et courtier OBD, politiques d'exportation PII.
Ned. 9-10 : PBAC pour les opérations à haut risque (conclusions, bonus, PSP), contrôle double, alertes KRI.
Ned. 11-12 : reversement trimestriel, couverture de 100 % des opérations à risque élevé de PaC, rapports et formation.

15) Artefacts

Role Catalogue : rôles, privilèges minimums, propriétaires.
SoD Matrix : rôles/opérations incompatibles, exceptions, processus override.
Policy Pack : ensemble de politiques PaC avec des tests et des exemples de deny/allow.
Formulaire de demande d'accès : objectif, durée, objet (tenant/région/environnement), évaluation des risques, appellations.
Registre des ops sensibles : liste des actions P1/P2, fenêtres, critères de contrôle double.
Audit Playbook : collecte et fourniture de journaux, SLA de réponse, rôles.

16) Anti-modèles

Droits permanents et comptes communs.
Accès croisés « pour plus de commodité ».
Pas d'isolation prod/stage/dev.
Politiques sur papier sans enforce dans le code/consoles.
Exportation de PII par arrangement manuel sans cryptage et TTL.
Absence de resertifications et droits « dépendants ».

17) Résultat

La segmentation des privilèges n'est pas seulement un « rôle correct ». Il s'agit d'une isolation multidimensionnelle (tenant, région, environnement, données, criticité) + contexte dynamique (ABAC/PBAC) + processus (SoD, JIT, resertification) + contrainte technique (PaC, PAM, réseaux/OBD). Une telle boucle réduit considérablement le risque d'erreurs et d'abus, accélère les changements sécurisés et rend la plate-forme résistante aux exigences de l'échelle et des régulateurs.