PII & Données sensibles

Objectif & portée¶

• Définir la gestion PII: classification, traitements, sécurité, droits des personnes, purge.
• Couvre: API v1, webhooks (Facebook/WhatsApp), KB, logs, métriques, backups, datasets ML.

Définitions¶

• PII: toute information permettant d'identifier directement ou indirectement une personne.
• Catégories: public, interne, confidentiel, sensible.
• DPO: responsable de la conformité CNDP/RGPD.

Classification des données¶

Principes de traitement¶

• Minimisation: collecter uniquement les données nécessaires au service.
• Finalité: usage limité aux objectifs déclarés (support, amélioration produit).
• Transparence: informer l'utilisateur des traitements via politique de confidentialité.
• Sécurité: chiffrement AES-256 au repos, TLS 1.2+ en transit.

Flux de traitement PII¶

Le diagramme suivant illustre le cycle de vie complet des données PII dans SalamBot :

flowchart TD
    subgraph "Collecte"
        U[Utilisateur]
        API[API Gateway]
        WH[Webhooks]
        UI[Interface Web]
    end

    subgraph "Classification"
        CL[Classificateur PII]
        PUB[Public]
        INT[Interne]
        CONF[Confidentiel]
        SENS[Sensible]
    end

    subgraph "Traitement"
        VAL[Validation]
        CHIFF[Chiffrement]
        PSEUDO[Pseudonymisation]
        MASK[Masquage]
    end

    subgraph "Stockage"
        DB[(Base de données)]
        KMS[Key Management]
        BACKUP[(Backups)]
        LOGS[(Logs)]
    end

    subgraph "Utilisation"
        RBAC[Contrôle RBAC/ABAC]
        AUDIT[Audit Trail]
        ML[Datasets ML]
        EXPORT[Export utilisateur]
    end

    subgraph "Purge"
        SCHED[Planificateur]
        SOFT[Soft Delete]
        HARD[Purge définitive]
        VERIF[Vérification]
    end

    subgraph "Droits"
        ACCESS[Droit d'accès]
        RECTIF[Rectification]
        ERASE[Effacement]
        PORT[Portabilité]
    end

    %% Flux principal
    U --> API
    U --> WH
    U --> UI

    API --> CL
    WH --> CL
    UI --> CL

    CL --> PUB
    CL --> INT
    CL --> CONF
    CL --> SENS

    PUB --> VAL
    INT --> CHIFF
    CONF --> CHIFF
    SENS --> |Rejet| CL

    VAL --> DB
    CHIFF --> PSEUDO
    PSEUDO --> MASK
    MASK --> DB

    DB --> KMS
    DB --> BACKUP
    DB --> LOGS

    DB --> RBAC
    RBAC --> AUDIT
    RBAC --> ML
    RBAC --> EXPORT

    %% Cycle de purge
    SCHED --> SOFT
    SOFT --> HARD
    HARD --> VERIF
    VERIF --> DB

    %% Droits des personnes
    U --> ACCESS
    U --> RECTIF
    U --> ERASE
    U --> PORT

    ACCESS --> EXPORT
    RECTIF --> DB
    ERASE --> SOFT
    PORT --> EXPORT

    %% Styles
    style U fill:#e3f2fd
    style SENS fill:#ffebee
    style CHIFF fill:#e8f5e8
    style KMS fill:#fff3e0
    style AUDIT fill:#f3e5f5
    style HARD fill:#ffcdd2
    style ERASE fill:#ffcdd2

Contexte multi-tenant¶

• Cloisonnement: données balisées par tenant (labels/partitions); interdiction de jointures inter-tenant.
• Clés de chiffrement: par tenant (KEK distincts KMS) quand possible; rotation indépendante.
• Exports: les exports/archives incluent tenant et sont isolés côté stockage (buckets/paths dédiés).
• Accès: RBAC/ABAC exigent correspondance stricte jwt.tenant == res.tenant.

Droits des personnes¶

Accès & portabilité¶

• Délai: réponse ≤30 jours (CNDP) / ≤1 mois (RGPD).
• Format: JSON structuré via API /v1/users/{id}/export.
• Authentification: vérification identité requise.

Rectification & effacement¶

• Rectification: API /v1/users/{id} (PATCH).
• Effacement: soft delete puis purge définitive après 90j.
• Exceptions: conservation légale (comptabilité, audit).

Opposition & limitation¶

• Opt-out: désactivation traitement marketing/analytics.
• Limitation: suspension temporaire sur demande justifiée.

Sécurité technique¶

Chiffrement¶

• Repos: AES-256-GCM, clés KMS rotées ≤90j.
• Transit: TLS 1.2+ avec PFS, certificats ≤1 an.
• Backups: chiffrés, clés séparées, test restauration mensuel.

Pseudonymisation¶

• Identifiants: hash SHA-256 + salt pour analytics.
• Logs: remplacer PII par tokens réversibles (DPO uniquement).
• Métriques: agrégation sans PII individuelle.

Contrôles d'accès¶

• RBAC: rôles DPO, Support, Dev avec scopes limités.
• Audit: traçabilité accès PII (qui/quand/pourquoi).
• Masquage: affichage partiel en UI (ex: user@*****.com).

Datasets ML & PII¶

• Ingestion: filtrer/masquer PII avant feature store; bannir champs sensibles (santé, religion, mineurs).
• Anonymisation: tokenisation irréversible (salt par tenant) pour analytics; agrégation k≥20.
• Jeux d'entraînement: fiches de données (Data Cards) indiquant source, base légale, rétention, PII résiduelles.
• Droit à l'effacement: traçabilité des contributions (data lineage); outil de data deletion pour retirer un utilisateur des jeux et ré-entraîner lors des cycles planifiés. Inclut suppression des features transformées, embeddings et annotations dérivées.
• Évaluation: utiliser jeux synthétiques/anonymisés; interdiction de logs bruts.
• Partage: aucun dataset ML contenant PII en dehors des régions autorisées (Maroc/UE).

Gestion des incidents¶

Détection¶

• Monitoring: alertes accès anormal, export massif.
• Logs: journalisation tentatives d'accès échouées.
• Scan: détection PII dans logs/code (CI/CD).

Notification¶

• Interne: DPO + Security Team ≤2h.
• Autorités: CNDP ≤72h si risque élevé.
• Personnes: notification directe si impact individuel.

Mesures correctives¶

• Isolation: blocage accès compromis.
• Investigation: analyse cause racine, impact.
• Remediation: correction vulnérabilité, renforcement.
• Conservation: logs d'incident et postmortem conservés 24 mois pour traçabilité et amélioration continue.

Rétention & purge¶

Calendrier de rétention¶

Justification des durées¶

• Conversations (12 mois): amélioration IA et support, intérêt légitime documenté; anonymisation après 90j pour analytics.
• Logs applicatifs (90j): sécurité/diagnostic; conservation minimale.
• Logs d'audit (12 mois): obligations de traçabilité et enquêtes sécurité.
• Métriques agrégées (24 mois): tendances produit (données non identifiantes).
• Backups (6 mois): continuité d'activité; chiffrage + accès restreint.

Toute durée différente par tenant doit être contractualisée et tracée.

Processus de purge¶

• Automatique: job quotidien, vérification intégrité.
• Manuelle: sur demande DPO, traçabilité complète.
• Vérification: audit trimestriel des suppressions.

Transferts internationaux¶

Localisation¶

• Primaire: Maroc (conformité CNDP).
• Secondaire: UE (adéquation RGPD).
• Interdits: pays sans protection adéquate (ex: États-Unis post-Schrems II, Chine, Russie, pays sans législation PII).

Garanties¶

• SCC: clauses contractuelles types pour sous-traitants UE.
• Certification: ISO 27001, SOC 2 Type II exigées.
• Audit: vérification annuelle des transferts.

Conformité & gouvernance¶

Responsabilités¶

• DPO: politique, formation, audits, relations autorités.
• Security Team: implémentation technique, incidents.
• Dev Teams: privacy by design, tests conformité.
• Ops: monitoring, backups, purge automatisée.

Documentation¶

• Registre: traitements, finalités, durées, transferts.
• DPIA: analyse d'impact pour nouveaux traitements.
• Procédures: gestion droits, incidents, audits.

Formation¶

• Onboarding: sensibilisation PII pour tous.
• Spécialisée: formation technique Dev/Ops.
• Recyclage: mise à jour annuelle réglementaire.

Gestion des consentements¶

• Base légale: consentement, contrat, intérêt légitime ou obligation légale (documenter par traitement).
• Collecte: opt-in explicite pour marketing/analytics facultatifs; preuve horodatée (tenant, canal, version de la politique).
• Retrait: opt-out traçable via UI/API (/v1/privacy/consent), propagation ≤72h.
• Journalisation: chaque changement de consentement est audité (qui/quand/quoi/tenant/canal).
• Bannière & granularité: séparer nécessaire vs optionnel; refuser par défaut l'optionnel.

Horodatage¶

• Les exports/erasures et journaux associés horodatent en UTC (Z). L'UI peut afficher en UTC+1 pour lisibilité.

Pour la signature Webhooks, se référer à API/reference.md#webhooks (centralisé).

Checklists opérationnelles¶

Nouveau traitement¶

• [ ] DPIA réalisée si risque élevé
• [ ] Base légale identifiée et documentée
• [ ] Durée de rétention définie
• [ ] Mesures de sécurité implémentées
• [ ] Information utilisateurs mise à jour

Incident PII¶

• [ ] Notification DPO ≤2h
• [ ] Évaluation risque et impact
• [ ] Notification CNDP si requis ≤72h
• [ ] Mesures correctives appliquées
• [ ] Documentation incident complète

Audit mensuel¶

• [ ] Vérification purges automatiques
• [ ] Contrôle accès aux données sensibles
• [ ] Test procédures droits des personnes
• [ ] Mise à jour registre des traitements
• [ ] Formation équipes si nécessaire

Tests & validations périodiques¶

• Purge: test mensuel sur échantillon; vérification d'effacement dans DB, blobs, index RAG, caches et backups (via marquage TTL/snapshots).
• Accès: revue mensuelle des accès PII (DPO/Security) + sampling d'événements d'audit.
• Scans: CI/CD avec détecteur PII sur code/diffs et scans journaux (regex + classifieurs ML) ; alertes en cas de fuite.
• Webhooks: test de signature HMAC et horodatage (±5min) par tenant; rejouabilité contrôlée validée. Se référer à API/reference.md (Webhooks & HMAC) pour les tests de signature et la fenêtre temporelle (source unique).
• Droits: tests automatisés des endpoints /export, /erase, délais de réponse et traçabilité.
• Drill: exercice incident PII trimestriel (table-top) avec postmortem.

Références croisées¶

• Runbooks : procédures d'incident PII
• SLO & SLA : métriques de conformité
• IAM : contrôles d'accès PII
• API Reference : endpoints de gestion PII
• Audit : cadre d'audit technique et journalisation détaillée
• Quality/datasets.md : gouvernance des jeux de données ML