Politiques d'accès et segmentation

1) Objectif et principes

Objectif : minimiser les risques de fuites/fraudes et les conséquences réglementaires grâce à un contrôle strict de « qui, à quoi et pourquoi a accès », avec preuve pour l'audit.
Principes : Least Privilège (minimum de droits), Need-to-Know, Zero Trust, Segregation of Duties (SoD), Just-in-Time (JIT), traçabilité et révocation de l'accès en un clic.

2) Classification des données et niveaux de protection

3) Modèle d'accès : RBAC + ABAC

RBAC (rôles) : matrice de base « rôle → résolution ».
ABAC (attributs) : règles de contexte (compétence du joueur/opérateur, segment d'environnement, sensibilité du jeu, changement/temps, appareil, niveau de vérification KYC, tâche de service/purpose).

• L'analyste marketing ne peut lire les tableaux « événements _ » que pour les pays où il y a consentement à l'analyse, seulement dans la semaine de 08:00 à 21:00, seulement à partir du réseau d'entreprise/dispositif MDM, sans champs PII (masquage inclus).

4) SoD - Partage des responsabilités (antifraude et conformité)

5) JIT, break-glass и PAM

JIT (Just-in-Time) : les droits élevés sont délivrés pour un intervalle limité (15-120 min) pour une tâche spécifique et sont automatiquement retirés.
Break-glass : accès d'urgence via une procédure séparée (MFA + deuxième confirmation + indication obligatoire de purpose), enregistrement complet de la session et post-factum avec des revues.
PAM : pour les comptes admin - stockage par mot de passe, analyse comportementale, rotation des clés/secrets, proxy de session avec écriture.

6) Segmentation : Moyen, réseau et logique

6. 1 Médias : 'prod' ≠' stage '≠' dev '. Les données prod ne sont pas copiées dans stage/dev ; on utilise des ensembles synthétiques ou pseudonymes.

• Edge/WAF/CDN → App Zone → Data Zone (DWH/DB) → Secrets/KMS.
• Le périmètre de paiement (PSP/cartes) est isolé du prod commun ; Le CUS/sanctions est un segment distinct.
• 6. 3 Segmentation logique : espaces de noms (K8s), tenant-IDs, schémas OBD/répertoire de données, clés de chiffrement individuelles per tenant/région.
• 6. 4 Géo-segmentation : stockage/traitement selon la localisation (CE/UK/...) ; acheminement des guides et des clés par région.

7) Accès des fournisseurs et partenaires

Mécanique : B2B-tenants/comptes individuels, minimum API, mTLS, allow-list IP, fenêtre temporelle.
Contrats : DPA/SLA (journaux, durées de conservation, géographie, incidents, sous-processeurs).
Offboard : révocation des clés, confirmation de suppression, acte de fermeture.
Surveillance : alertes sur des volumes anormaux, interdiction des exportations massives.

8) Processus (SOP)

8. 1 Demande/modification d'accès

1. Demande à l'IDM/ITSM avec purpose et délai.
2. Contrôle automatique SoD/juridiction/classe de données.
3. Approbation par le propriétaire du domaine + Sécurité/Conformité (si Restreint +).
4. Délivrance d'un JIT/accès permanent (recrutement minimum).
5. Journal : qui/quand/ce qui est délivré ; date de révision.

8. 2 Révision périodique (recertification)

Trimestriel : les propriétaires confirment les droits des groupes ; droits non utilisés (> 30/60 jours).

8. 3 Exportation de données

Seulement via les piplines/vitrines approuvées, les listes de formats blancs (CSV/Parquet/JSON), le masquage par défaut, la signature/hachage, le journal de déchargement.

9) Politique sur les appareils et contexte

MDM/EMM : accès à Restreint/Restreint à partir d'appareils gérés uniquement.
Signaux contextuels : géo, risque de l'appareil, heure de la journée, état MFA, réputation IP - comme attributs ABAC.
Extensions de navigateur/capture d'écran : contrôle et journal, interdiction pour les consoles sensibles.

10) Exemples de politiques (fragments)

10. 1 YAML (pseudo) - ABAC pour l'analyste marketing

yaml policy: read_analytics_no_pii subject: role:marketing_analyst resource: dataset:events_
condition:
consent: analytics == true data_class: not in [Restricted, HighlyRestricted]
network: in [corp_vpn, office_mdm]
time: between 08:00-21:00 workdays effect: allow masking: default logging: audit_access + fields_scope

10. 2 masquage SQL (idée)

sql
SELECT user_id_hash,
CASE WHEN has_priv('pii_read') THEN email ELSE mask_email(email) END AS email_view
FROM dwh. users;

11) Surveillance, journaux et alertes

Audit trails: `READ_PII`, `EXPORT_DATA`, `ROLE_UPDATE`, `BREAK_GLASS`, `PAYMENT_APPROVE`.
KRIs : accès sans « purpose » = 0 ; tentatives à Highly Restricted à l'extérieur de la fenêtre ; la proportion de contrôles SoD échoués ; décharges anormales.
KPI :% des demandes avec JIT ≥ 80 %; le temps moyen d'accès est ≤ 4 h ; 100 % de couverture de re-certification.
SOAR-playbooks : auto-rappel dans les menaces, tickets pour l'enquête.

12) Conformité (carte courte)

GDPR/UK GDPR : minimisation, Need-to-Know, interopérabilité DSAR, audit PII.
AML/KYC : accès au CUS/sanctions - uniquement pour les rôles formés, journal des décisions.
DSS PCI (le cas échéant) : ségrégation de la zone de paiement, interdiction de stockage PAN/CSC, clés individuelles/hébergement.
ISO/ISMS : politiques d'accès formalisées, audits annuels et tests.

13) PACI

14) Métriques de maturité

Couverture ABAC des jeux de données critiques ≥ 95 %.
Sessions JIT/toutes les augmentations de droits ≥ 90 %.
Temps de révocation d'accès par offboarding ≤ 15 min.
0 incidents « rôle ≠ fonction » (SoD).
100 % des journaux d'accès sont disponibles et vérifiés (signature/hash).

15) Chèques-feuilles

15. 1 Avant d'accorder l'accès

• Définition de purpose, durée et propriétaire des données
• Vérification de la SoD/juridictions passée
• Minimum scoop/masquage inclus
• Conditions MFA/MDM/réseau respectées
• Journal et date de révision personnalisés

15. 2 Examen trimestriel

• Rapprochement des groupes et des rôles avec la structure organisationnelle
• Droits auto « suspendus »
• Contrôle des exportations anormales et break-glass
• Formation et tests alertes

16) Scénarios et mesures types

A) Nouveau rôle de « VIP Manager »

Accès aux profils VIP (masqué), interdiction des exportations, JIT pour une vue unique de KYC via ticket.

B) Vérification de la BI par le vendeur

read-only aux vitrines sans PII, VPN temporaire + allow-list, interdiction d'enregistrer localement, journal de déchargement.

C) Accès d'urgence DevOps à la prod-OBD

break-glass ≤ 30 min, enregistrement de session, post-revue avec DPO/Compliance, CAPA en cas d'irrégularités.

17) Feuille de route pour la mise en œuvre

Semaines 1 à 2 : inventaire des données/systèmes, classes de données, matrice RBAC de base, SoD.
Semaines 3 à 4 : implémenter ABAC (premiers attributs : environnement, géo, classe de données), flux IDM, JIT/break-glass, PAM.
Mois 2 : segmentation du périmètre de paiement et KYC, clés individuelles/KMS, journaux d'exportation, alertes SOAR.
Mois 3 + : re-certification trimestrielle, extension des attributs (dispositif/risque), automatisation du masquage, exercices réguliers.

TL; DR

Le modèle sûr de l'accès = la classification des données → RBAC+ABAC → SoD+JIT/PAM → la segmentation rigide → les revues et алерты. Cela réduit les risques de fuites et d'abus, accélère l'audit et maintient la plate-forme dans les limites du RGPD/AML/PCI et des normes internes.