PD-30 - Cahier de tests¶

1. Matrice de couverture INV -> Tests¶

2. Matrice de couverture CA -> Tests¶

3. Scenarios de test¶

TC-30-001 - Creation de session active unique et complete¶

• Preconditions : Horloge de test synchronisee UTC ms ; store central disponible ; utilisateur U1 authentifie avec succes ; contexte WEB connu ; logs audit activables en lecture.
• Donnees d'entree : Evenement d'authentification reussie (userId=U1, deviceId=D1, ip=IP1, userAgent=UA1, context=WEB).
• Actions : Declencher la creation de session une seule fois ; lire la session creee ; lire les logs lies a l'operation.
• Resultat attendu : Exactement 1 session ACTIVE est creee avec sessionId non nul ; champs minimaux presents (sessionId, userId, deviceId, ipHash, userAgentHash, createdAt, lastActivityAt, context, expiresAt, status) ; ttlSeconds >= 1 ; expiresAt > createdAt ; aucun token brut/secret/materiau cryptographique en clair dans la session et dans les logs.
• Criteres couverts : INV-30-01, INV-30-03, INV-30-04, INV-30-17, CA-30-01, CA-30-02, CA-30-03
• Automatisable : Oui

TC-30-002 - Unicite globale du sessionId sur retention active + 24h¶

• Preconditions : Environnement de test permettant de conserver l'historique des sessionId ; retention configuree ; horloge controlee.
• Donnees d'entree : N creations de sessions (N >= 100000) sur plusieurs utilisateurs/devices/contexte, reparties sur la fenetre retention active + 24h.
• Actions : Executer les creations ; collecter tous les sessionId emis sur la fenetre ; verifier l'unicite globale.
• Resultat attendu : 0 collision de sessionId sur toute la fenetre observee ; toute collision rend le test en echec.
• Criteres couverts : INV-30-02
• Automatisable : Oui

TC-30-003 - Expiration automatique et rejet post-expiration¶

• Preconditions : Session S1 active avec TTL court deterministic (ex. 3 s) ; horloge controlee ; endpoint protege par session actif.
• Donnees d'entree : Requete authentifiee avec S1 apres depassement de expiresAt.
• Actions : Attendre strictement au-dela de expiresAt ; emettre une requete avec S1 ; consulter trace d'audit.
• Resultat attendu : Rejet SESSION_INVALID ; S1 inutilisable sans action humaine ; evenement EXPIRE et trace SESSION_REJECTED avec raison presentes.
• Criteres couverts : INV-30-05, CA-30-04, ECT-30-01
• Automatisable : Oui

TC-30-004 - Renouvellement autorise avant expiration, interdit apres¶

• Preconditions : Session S2 active non expiree ; mecanisme de refresh disponible.
• Donnees d'entree : (A) requete valide avant expiration ; (B) tentative de refresh apres expiration ; (C) tentative apres invalidation explicite.
• Actions : Executer A puis lire expiresAt/lastActivityAt ; laisser expirer S2 puis executer B ; recreer S3 puis invalider S3 et executer C.
• Resultat attendu : A augmente expiresAt et met a jour lastActivityAt ; B et C sont refuses (pas de prolongation possible) ; aucun refresh accepte sur session expiree/invalidee.
• Criteres couverts : INV-30-06, CA-30-05
• Automatisable : Oui

TC-30-005 - Matrice des TTL par contexte¶

• Preconditions : Valeurs TTL configurees pour WEB, MOBILE, API, SENSITIVE ; horloge UTC ms controlee.
• Donnees d'entree : 4 creations de session (une par contexte) avec meme userId/deviceId de test.
• Actions : Creer 4 sessions ; relever createdAt, expiresAt, context, ttlSeconds ; comparer les deltas.
• Resultat attendu : Les 4 TTL appliques sont strictement positifs ; expiresAt - createdAt coherent avec la valeur du contexte ; les 4 valeurs sont distinctes entre elles.
• Criteres couverts : INV-30-04, INV-30-07, CA-30-03, CA-30-06
• Automatisable : Oui

TC-30-006 - Listing appareils/sessions : complet, isole, frais, champs autorises¶

• Preconditions : Utilisateurs U1 et U2 avec sessions actives multiples ; derive geoloc ville/pays disponible ; store central disponible ; endpoint listing actif.
• Donnees d'entree : Requete de listing par U1 ; tentative de lecture des sessions U2 par U1.
• Actions : Prendre un snapshot etat store pour U1/U2 ; appeler listing U1 ; mesurer ecart temporel snapshot vs reponse ; executer tentative inter-utilisateur.
• Resultat attendu : Reponse U1 contient toutes et seulement les sessions de U1 ; aucune session U2 ; staleness <= 2 s ; chaque entree expose uniquement type appareil, date connexion, derniere activite, localisation approximative (ville/pays), statut ; tentative inter-utilisateur rejetee ACCESS_DENIED + trace.
• Criteres couverts : INV-30-08, INV-30-12, CA-30-07, ECT-30-04
• Automatisable : Oui

TC-30-007 - Revocation session ciblee cross-instance avec SLA latence¶

• Preconditions : Cluster multi-instance (>= 3 instances) ; jeu de sessions valides ; instrumentation latence p95/p99 ; echantillon >= 1000 operations.
• Donnees d'entree : 1000 requetes REVOKE_SESSION ciblees avec verification immediate d'usage token sur toutes instances.
• Actions : Pour chaque operation, declencher revocation puis sonder toutes instances jusqu'au rejet ; enregistrer latence de propagation.
• Resultat attendu : Chaque session ciblee devient inutilisable sur toutes instances ; distribution latence respecte p95 < 100 ms et p99 < 250 ms ; journal REVOKE_SESSION present.
• Criteres couverts : INV-30-09, CA-30-08
• Automatisable : Oui

TC-30-008 - Revocation globale utilisateur cross-instance avec SLA latence¶

• Preconditions : Cluster multi-instance ; utilisateur U3 avec plusieurs sessions actives sur plusieurs devices/instances ; instrumentation latence p95/p99 ; echantillon >= 1000 operations.
• Donnees d'entree : 1000 operations REVOKE_ALL sur des utilisateurs ayant au moins 3 sessions actives.
• Actions : Declencher chaque REVOKE_ALL ; sonder reutilisation de toutes sessions sur toutes instances ; mesurer latence de pleine invalidation.
• Resultat attendu : Toutes les sessions du user cible deviennent inutilisables ; p95 < 100 ms et p99 < 250 ms ; journal REVOKE_ALL avec motif.
• Criteres couverts : INV-30-10, CA-30-09
• Automatisable : Oui

TC-30-009 - Invalidation obligatoire sur evenements contractuels¶

• Preconditions : Utilisateur U4 avec sessions multi-devices ; canal d'emission d'evenements securite/conformite disponible.
• Donnees d'entree : 4 evenements : PASSWORD_CHANGED, DEVICE_REVOKED(deviceId=D4), INTRUSION_SUSPECTED, JUDICIAL_REQUEST(scope explicite).
• Actions : Injecter chaque evenement dans un run isole ; verifier la portee d'invalidation appliquee et les journaux sources/cibles.
• Resultat attendu : PASSWORD_CHANGED => REVOKE_ALL U4 ; DEVICE_REVOKED => invalidation de toutes sessions actives de D4 seulement ; INTRUSION_SUSPECTED => REVOKE_ALL U4 ; JUDICIAL_REQUEST => invalidation conforme a la portee explicite fournie ; toutes les traces d'evenement source + action d'invalidation sont presentes.
• Criteres couverts : INV-30-11, CA-30-10
• Automatisable : Oui

TC-30-010 - Revocation device : toutes les sessions du device cible, seulement celles-ci¶

• Preconditions : U5 avec 2 sessions actives sur D5-A et 2 sessions actives sur D5-B.
• Donnees d'entree : Requete REVOKE_DEVICE pour D5-A.
• Actions : Declencher la revocation ; verifier etat/utilisabilite des 4 sessions.
• Resultat attendu : Les 2 sessions de D5-A sont invalidees ; les 2 sessions de D5-B restent actives ; journal REVOKE_DEVICE present.
• Criteres couverts : INV-30-13, CA-30-11
• Automatisable : Oui

TC-30-011 - Verification timing-safe de token/session¶

• Preconditions : Composant de verification instrumentable ; environnement capable de preuve statique et test de non-regression runtime.
• Donnees d'entree : Corpus de tokens valides/invalides differant a positions variables (debut/milieu/fin) et longueurs controllees.
• Actions : (1) Verification statique : confirmer l'usage de primitive timing-safe dans le chemin de comparaison ; (2) Verification runtime : comparer distributions de temps sur jeux invalides a positions differentes, sous charge stable.
• Resultat attendu : Preuve explicite d'appel a comparaison timing-safe dans le composant de validation ; aucune comparaison directe type ==/=== sur secrets/token ; derive temporelle non exploitable selon seuil de test defini.
• Criteres couverts : INV-30-14, CA-30-13
• Automatisable : Oui

TC-30-012 - Rate limiting scope user (fenetre glissante 15 min)¶

• Preconditions : Endpoint sensible soumis au rate limiting ; fenetre glissante 15 min ; utilisateur U6 depuis IP stable.
• Donnees d'entree : 4 requetes sensibles valides emises par U6 en < 15 min.
• Actions : Emettre les 4 requetes selon un timing controle ; collecter reponses et traces.
• Resultat attendu : Requetes 1-3 non rejetees par la regle user ; 4e rejetee RATE_LIMIT_USER (HTTP 429 equivalent) avec retryAfterSeconds ; trace RATE_LIMIT_HIT scope user.
• Criteres couverts : INV-30-15, CA-30-12, ECT-30-02
• Automatisable : Oui

TC-30-013 - Rate limiting scope IP (fenetre glissante 15 min)¶

• Preconditions : Endpoint sensible soumis au rate limiting ; 2+ utilisateurs derriere la meme IP.
• Donnees d'entree : 6 requetes sensibles en < 15 min depuis meme IP (users differents autorises).
• Actions : Emettre les 6 requetes ; collecter reponses et traces.
• Resultat attendu : 1-5 non rejetees par la regle IP ; 6e rejetee RATE_LIMIT_IP (HTTP 429 equivalent) avec retryAfterSeconds ; trace RATE_LIMIT_HIT scope ip.
• Criteres couverts : INV-30-15, CA-30-12, ECT-30-03
• Automatisable : Oui

TC-30-014 - Journalisation append-only complete, ordonnee et conforme¶

• Preconditions : Audit log interrogeable en lecture ; pipeline d'horodatage UTC ms actif ; acteur et motif disponibles dans contexte.
• Donnees d'entree : Sequence d'actions couvrant CREATE, REFRESH, REVOKE_SESSION, REVOKE_DEVICE, REVOKE_ALL, EXPIRE.
• Actions : Executer la sequence ; extraire les logs ; verifier ordre temporel, immutabilite append-only, presence champs obligatoires.
• Resultat attendu : Tous les evenements contractuels testes sont presents en ordre de creation, sans mise a jour destructive d'entrees precedentes ; chaque entree contient timestamp UTC milliseconde, acteur, motif (si applicable) ; aucune donnee secrete en clair dans le journal.
• Criteres couverts : INV-30-16, INV-30-17, CA-30-14
• Automatisable : Oui

TC-30-015 - Absence de secrets en clair dans store et logs¶

• Preconditions : Jeux d'entree contenant canaris secrets (token brut, secret auth, materiau crypto simulé) injectes dans flux de test autorises ; acces lecture au store session et logs.
• Donnees d'entree : Operations create/refresh/revoke incluant identifiants canari en entree amont.
• Actions : Executer operations ; scanner store session et logs sur patterns canari/brut.
• Resultat attendu : Aucun canari secret present en clair ; seules representations autorisees (hash/redaction) observees.
• Criteres couverts : INV-30-03, INV-30-17, CA-30-02
• Automatisable : Oui

TC-30-016 - Bascule fallback in-memory en < 1 s avec TTL applique¶

• Preconditions : Store central operationnel puis fault injection possible ; fallback in-memory activable ; horloge monotone de mesure.
• Donnees d'entree : Defaillance simulee du store central pendant trafic nominal ; creation session en mode degrade avec TTL court.
• Actions : Provoquer indisponibilite store ; mesurer delai detection -> FALLBACK_ON ; creer session fallback ; verifier expiration par TTL ; restaurer store central et verifier FALLBACK_OFF.
• Resultat attendu : Activation fallback en < 1 s ; mode degrade explicitement signale ; session fallback expire selon TTL ; FALLBACK_ON et FALLBACK_OFF journalises ; operations locales continuent tant que fallback disponible.
• Criteres couverts : INV-30-18, INV-30-16, CA-30-15, ECT-30-05
• Automatisable : Oui

TC-30-017 - Rejet explicite des operations globales en mode degrade¶

• Preconditions : Mode degrade actif (fallback ON) ; utilisateur avec sessions actives ; endpoint global disponible en mode nominal.
• Donnees d'entree : Requetes LIST_ALL_USER_SESSIONS et REVOKE_ALL_USER_SESSIONS pendant degradation.
• Actions : Executer les deux requetes ; collecter reponses et traces.
• Resultat attendu : Rejets explicites DEGRADED_MODE_RESTRICTION pour les 2 operations ; traces de rejet presentes et correlees au mode degrade.
• Criteres couverts : INV-30-19, CA-30-16, ECT-30-05
• Automatisable : Oui

TC-30-018 - Store central indisponible et fallback indisponible¶

• Preconditions : Mecanisme de simulation panne double (store central OFF + fallback OFF/KO).
• Donnees d'entree : Requete de verification/operation session standard.
• Actions : Mettre store central hors service ; rendre fallback indisponible ; emettre requete.
• Resultat attendu : Rejet SESSION_SERVICE_UNAVAILABLE (HTTP 503 equivalent) ; trace SESSION_SERVICE_UNAVAILABLE presente.
• Criteres couverts : ECT-30-06
• Automatisable : Oui

TC-30-019 - Revocation sans acteur autorise¶

• Preconditions : Endpoint de revocation expose ; principal non autorise prepare.
• Donnees d'entree : Requete de REVOKE_SESSION ou REVOKE_ALL par acteur non autorise.
• Actions : Executer la requete non autorisee ; collecter reponse et trace.
• Resultat attendu : Rejet FORBIDDEN_ACTION ; trace FORBIDDEN_ACTION obligatoire.
• Criteres couverts : ECT-30-07
• Automatisable : Oui

4. Tests non testables¶

5. Verdict de couverture¶

• INV couverts : 19/19
• CA couverts : 16/16
• Regles non testables : 3