fd2b0f70c5
Règles RGPD (docs/domains/_shared/rules/rgpd.md): - Ajouter sections 13.11-13.22 (droits utilisateurs, mineurs, sécurité) - Droit de rectification, opposition, limitation du traitement - Gestion des mineurs: 13 ans minimum + consentement parental 13-15 ans - Protection renforcée: RoadWave Kids pour < 13 ans - Sécurité: chiffrement multi-niveaux, procédure breach 72h CNIL - Politique de confidentialité avec versioning - Sous-traitants, DPIA, délais de réponse Entités (6 nouvelles): - PARENTAL_CONSENTS + PARENTAL_CONTROLS (workflow 13-15 ans) - PRIVACY_POLICY_VERSIONS + USER_POLICY_ACCEPTANCES - ACCOUNT_DELETIONS (grace period 30j) - BREACH_INCIDENTS + BREACH_AFFECTED_USERS - USER_PROFILE_HISTORY (audit trail rectification) - DATA_RETENTION_LOGS (purge 5 ans) Diagrammes séquences (5 nouveaux): - Consentement parental avec validation email - Anonymisation GPS automatique après 24h - Notification breach CNIL (procédure 72h) - Export données asynchrone - Suppression compte avec grace period Cycles de vie (3 nouveaux + 1 enrichi): - parental-consent-lifecycle.md - breach-incident-lifecycle.md - account-deletion-lifecycle.md - user-account-lifecycle.md (ajout états mineurs, frozen) Features BDD (4 nouvelles, 195 scénarios RGPD): - minors-protection.feature (9 scénarios) - data-security.feature (12 scénarios) - privacy-policy.feature (8 scénarios) - user-rights.feature (8 scénarios) Infrastructure: - Réorganiser docs générées: docs/bdd + output → generated/bdd + generated/pdf - Mettre à jour mkdocs.yml, Makefile, scripts Python - Ajouter /generated/ au .gitignore
111 lines
4.4 KiB
Gherkin
111 lines
4.4 KiB
Gherkin
# language: fr
|
|
|
|
@privacy @rgpd @security
|
|
Fonctionnalité: Sécurité des données (Article 32 RGPD)
|
|
En tant que responsable de traitement
|
|
Je veux garantir la sécurité des données personnelles
|
|
Afin de prévenir les violations et fuites
|
|
|
|
# Chiffrement transport
|
|
@encryption @tls
|
|
Scénario: TLS 1.3 obligatoire pour toutes les communications
|
|
Quand un client tente de se connecter à l'API
|
|
Alors la connexion utilise TLS 1.3 uniquement
|
|
Et les protocoles TLS 1.0, 1.1, 1.2 sont refusés
|
|
Et le certificat est valide et à jour
|
|
|
|
# Chiffrement stockage
|
|
@encryption @database
|
|
Scénario: Encryption at rest pour la base de données
|
|
Étant donné que PostgreSQL stocke des données utilisateurs
|
|
Alors le chiffrement AES-256 at rest est activé
|
|
Et les backups sont également chiffrés AES-256
|
|
Et les backups sont stockés offsite (règle 3-2-1)
|
|
|
|
# Tokens JWT sécurisés
|
|
@encryption @jwt
|
|
Scénario: Rotation des clés JWT tous les 90 jours
|
|
Étant donné que l'API utilise des tokens JWT RS256
|
|
Quand 90 jours se sont écoulés depuis la dernière rotation
|
|
Alors une nouvelle paire de clés RSA est générée
|
|
Et l'ancienne clé reste valide 7 jours (overlap)
|
|
Et tous les tokens sont progressivement re-signés
|
|
|
|
# CDN avec signed URLs
|
|
@cdn @signed-urls
|
|
Scénario: URLs signées expirables pour les fichiers audio
|
|
Quand un utilisateur demande à écouter un contenu
|
|
Alors l'API génère une signed URL valide 1 heure
|
|
Et l'URL contient un token HMAC
|
|
Et après expiration, l'URL retourne 403 Forbidden
|
|
|
|
# Détection breach
|
|
@breach @monitoring
|
|
Scénario: Alerte immédiate si erreurs critiques backend
|
|
Quand une erreur critique survient dans l'API (500, crash)
|
|
Alors Sentry déclenche une alerte Discord/Slack immédiate
|
|
Et l'équipe est notifiée en temps réel
|
|
Et les logs sont consultables dans Grafana
|
|
|
|
@breach @monitoring
|
|
Scénario: Alerte si pic de requêtes anormal (potentiel DDoS)
|
|
Étant donné que le trafic habituel est ~1000 req/min
|
|
Quand le trafic atteint 10000 req/min
|
|
Alors Grafana déclenche une alerte email
|
|
Et l'équipe vérifie s'il s'agit d'une attaque
|
|
|
|
@breach @monitoring
|
|
Scénario: Alerte si accès DB non autorisé
|
|
Quand une connexion PostgreSQL provient d'une IP non whitelistée
|
|
Alors PostgreSQL bloque la connexion
|
|
Et un SMS est envoyé au fondateur
|
|
Et l'IP est loggée pour investigation
|
|
|
|
# Procédure breach 72h CNIL
|
|
@breach @procedure
|
|
Scénario: Notification CNIL si violation de données sous 72h
|
|
Étant donné qu'une violation de données est détectée
|
|
Et que des données GPS utilisateurs ont fuité
|
|
Quand l'équipe évalue la gravité
|
|
Alors le runbook "docs/rgpd/procedure-breach.md" est suivi:
|
|
| Étape | Délai | Action |
|
|
| 1 | H+0 | Détection et confinement |
|
|
| 2 | H+24 | Évaluation gravité et impact |
|
|
| 3 | H+48 | Notification CNIL si risque |
|
|
| 4 | H+72 | Notification utilisateurs si élevé|
|
|
Et un email pré-rédigé est envoyé à la CNIL
|
|
Et le formulaire en ligne CNIL est rempli
|
|
|
|
# Mesures organisationnelles
|
|
@security @access-control
|
|
Scénario: Accès DB uniquement via VPN et whitelist IP
|
|
Étant donné que je suis un développeur
|
|
Quand je tente d'accéder à la DB de production
|
|
Alors je dois être connecté au VPN OVH
|
|
Et mon IP doit être dans la whitelist
|
|
Sinon la connexion est refusée
|
|
|
|
@security @2fa
|
|
Scénario: 2FA obligatoire pour les comptes administrateurs
|
|
Étant donné que je suis un administrateur
|
|
Quand je me connecte à Zitadel admin
|
|
Alors le 2FA (TOTP) est obligatoire
|
|
Et je ne peux pas désactiver le 2FA
|
|
Et chaque connexion est loggée avec IP et timestamp
|
|
|
|
@security @logs
|
|
Scénario: Anonymisation des IP dans les logs (rotation 90j)
|
|
Quand un utilisateur fait une requête API
|
|
Alors son IP est loggée pour debug
|
|
Mais les 2 derniers octets sont masqués (ex: 192.168.x.x)
|
|
Et les logs sont automatiquement supprimés après 90 jours
|
|
|
|
# Tests de sécurité
|
|
@security @pentest
|
|
Scénario: Pentest annuel obligatoire
|
|
Étant donné que l'application est en production
|
|
Quand une année s'est écoulée depuis le dernier pentest
|
|
Alors un pentest externe est planifié
|
|
Et les vulnérabilités découvertes sont corrigées sous 30 jours
|
|
Et un rapport est produit pour audit
|