Guide de durcissement — sécurité du plan de contrôle KySpectra

#Sommaire

§	Section
1	Portée, hypothèses et modèle de menace
2	Liste de contrôle de mise en production
3	Configuration recommandée de chaque drapeau sensible
4	Gestion des rôles et principe du moindre privilège
5	Rotation des secrets
6	Revue périodique des accès
7	Journalisation et conservation
8	Réponse à incident en six phases
9	Matrice de risques et mesures d'atténuation
10	Registre des décisions de sécurité

#1. Portée, hypothèses et modèle de menace

#1.1 Ce que couvre ce guide

Ce document complète le 04-guide-administrateur.md. Il ne redécrit pas les écrans : il indique comment configurer, exploiter et surveiller le plan de contrôle pour qu'il résiste à un usage adverse.

Il s'adresse à trois lecteurs :

Lecteur	Ce qu'il vient chercher
Administrateur plateforme	Les réglages à appliquer et les revues à tenir
Responsable sécurité de l'information	Les contrôles disponibles et leurs limites réelles
Responsable de la protection des renseignements personnels	Les preuves mobilisables et la procédure d'incident

#1.2 Hypothèses explicites

Les portails sont des sites statiques rendus côté navigateur. Tout ce qu'ils contiennent est visible par l'utilisateur, y compris chaque variable préfixée NEXT_PUBLIC_. Aucun secret ne peut y être caché.
Le contrôle d'accès visible dans l'interface est une commodité. L'autorité est le serveur.
Les identifiants de locataire, les identifiants d'utilisateur et les URL de service ne sont pas des secrets.
Les secrets vivent exclusivement dans le coffre. Le plan de contrôle ne manipule que des chemins et des noms de sous-clés.
Les agents sont des acteurs à part entière : ils exécutent du code, atteignent le réseau et consomment du budget. Ils se gouvernent comme des employés, pas comme des bibliothèques.

#1.3 Modèle de menace résumé

Menace	Vecteur réaliste	Contrôle principal	Limite du contrôle
M1 — Élévation de privilège	Auto-déclaration de rôle en mode `dev-headers`	Passage en mode `jwt`	Aucun contrôle si le mode reste `dev-headers`
M2 — Fuite entre locataires	Manipulation de l'identifiant de locataire	Masquage d'existence par 404	Dépend de la vérification du jeton
M3 — Exfiltration par un agent	Sortie réseau non maîtrisée depuis un bac à sable	Politique réseau en refus par défaut + allowlist d'egress	Allowlist trop large = fenêtre ouverte
M4 — Exposition de secret	Secret collé dans un champ de chemin	Validation de forme + analyse de contenu	Un champ de chemin accepte techniquement toute chaîne commençant par `secret/`
M5 — Contournement du double contrôle	Un même administrateur soumet et approuve	Refus en base de données	Ne protège pas contre deux comptes détenus par la même personne
M6 — Altération de la preuve	Modification du journal d'audit	Chaînage par hachage + vérification	La détection est postérieure : le journal détecte, il n'empêche pas
M7 — Dérive de coût	Boucle d'agent, plafond d'autonomie trop élevé	Budgets, seuils, quotas, plafonds	La réaction reste humaine
M8 — Interruption de service	Règle réseau manquante, sonde mal configurée	Règles de sortie explicites, sondes découplées, répliques multiples	Incidents déjà survenus en production
M9 — Capacité malveillante	Compétence ou serveur d'outils importé	Pipeline gouverné + revue de séparation des devoirs	La qualité dépend de la revue humaine
M10 — Persistance après départ	Compte non désactivé	Revue périodique des accès	Aucune détection automatique d'inactivité

#2. Liste de contrôle de mise en production

À exécuter intégralement avant d'ouvrir un environnement à des utilisateurs réels. Aucune ligne bloquante ne peut être reportée.

#2.1 Authentification et identité — bloquant

#	Contrôle	Attendu	Bloquant
1	Mode d'authentification du portail	`jwt` défini explicitement	🔴
2	Mode d'authentification du backend	`jwt` défini explicitement	🔴
3	Cohérence entre les deux	Identique	🔴
4	Domaine d'identité	Tranché et identique de bout en bout	🔴
5	Client public du portail	PKCE `S256`, flux implicite désactivé, sans secret	🔴
6	URI de redirection	`<origine>/auth/callback` déclarée	🔴
7	Panneau d'identité de la page Configuration	En lecture seule après connexion	🔴
8	Semis d'identité de développement	Vides en production	🔴
9	Promotion implicite au rôle propriétaire	Non activée	🔴
10	Politique de mot de passe du serveur d'identité	Longueur ≥ 8, majuscule, minuscule, chiffre, différent du nom d'utilisateur	🟡
11	Protection contre la force brute	Activée	🟡
12	Durée de vie du jeton d'accès	Explicite et documentée	🟡
13	Second facteur pour les administrateurs plateforme	Activé	🟡

#2.2 Réseau et disponibilité — bloquant

#	Contrôle	Attendu	Bloquant
14	Règle de sortie vers le serveur d'identité	Présente sur l'espace en refus par défaut	🔴
15	Répliques de la passerelle	≥ 2	🔴
16	Sondes de vitalité	Découplées du magasin de données	🔴
17	Répliques des services critiques	≥ 2	🟡
18	Stratégie de mise à jour	Adaptée à la capacité du cluster	🟡
19	Agrégat de santé	Répond 200 ou 503 avec le détail par service	🟡

#2.3 Routage et exposition

#	Contrôle	Attendu	Bloquant
20	Origine de passerelle	Renseignée	🔴
21	Variables d'accès direct aux services	Toutes vides en production	🔴
22	Page Configuration	Chaque ligne porte la pastille `passerelle`	🟡
23	Accès direct aux services depuis Internet	Impossible	🔴
24	Certificats TLS	Valides sur tous les domaines	🔴

#2.4 Politiques d'exécution et garde-fous

#	Contrôle	Attendu	Bloquant
25	Politique réseau de chaque politique d'exécution	Préfixe `deny-`	🔴
26	Allowlist d'egress	Chaque hôte justifié par écrit	🔴
27	Durée maximale d'exécution	Ajustée au besoin réel, jamais laissée large « au cas où »	🟡
28	Système de fichiers	Espace de travail éphémère uniquement	🟡
29	Au moins une règle de garde-fou	Présente — table vide = tout refusé	🟡
30	Ordre des priorités	Refus ciblés avant autorisations larges	🔴
31	Approbation humaine sur actions irréversibles	Cochée	🔴
32	Test d'une action non couverte	Verdict Refusée	🔴

#2.5 Secrets

#	Contrôle	Attendu	Bloquant
33	Chemins de coffre	Tous commencent par `secret/`	🔴
34	Aucune valeur de secret dans un champ de chemin	Vérifié ligne à ligne	🔴
35	Panneau Vault de la page Gouvernance	Ne montre que des chemins	🔴
36	En-têtes statiques des serveurs d'outils	Aucun justificatif	🔴
37	Clé de chiffrement des justificatifs	Provisionnée	🔴
38	Aucun secret dans une variable `NEXT_PUBLIC_`	Vérifié	🔴

#2.6 Rôles et séparation des devoirs

#	Contrôle	Attendu	Bloquant
39	Nombre d'administrateurs plateforme	≥ 3 personnes distinctes	🔴
40	Comptes partagés	Aucun	🔴
41	Aucun compte ne cumule soumission et approbation opérationnelles	Vérifié	🔴
42	Rôles `OWNER` par locataire	Le minimum, nominatif	🟡
43	Dérogations de permission	Toutes motivées	🟡

#2.7 Audit et conformité

#	Contrôle	Attendu	Bloquant
44	Vérification de chaîne sur chaque locataire	Valide	🔴
45	Rapport de conformité de référence	Généré et archivé	🟡
46	Durée de conservation du journal	Définie et documentée	🔴
47	Sauvegarde du journal	Testée en restauration	🔴
48	Procédure d'incident	Écrite, avec noms et coordonnées	🔴

#2.8 Données de démonstration

#	Contrôle	Attendu	Bloquant
49	Drapeau du module de démonstration	Portée Locataire, jamais Globale	🔴
50	Locataire de démonstration	L'identifiant réservé, jamais un locataire réel	🔴
51	Aucune donnée réelle dans la démonstration	Vérifié	🔴

#2.9 Hygiène de l'interface

#	Contrôle	Attendu	Bloquant
52	Clés de traduction manquantes	Corrigées (`nav.workforce`, `workforce.noTeams`)	🔴
53	Textes « TODO » visibles	Retirés	🔴
54	Catalogue de plans	Nettoyé, sans vocabulaire hérité	🔴
55	Valeur par défaut du champ Plan	Corrigée	🟡

#3. Configuration recommandée de chaque drapeau sensible

#3.1 Drapeaux d'authentification et d'accès

Drapeau	Défaut livré	Développement	Qualification	Production	Justification
`AUTH_MODE` (backend)	`dev-headers`	`dev-headers`	`jwt`	`jwt`	Seul mode strict. Le défaut équivaut à aucune authentification.
`NEXT_PUBLIC_AUTH_MODE` (portail)	vide ⇒ `dev-headers`	`dev-headers`	`jwt`	`jwt`	Doit être identique au backend.
`KYSPECTRA_DEV_IMPLICIT_OWNER`	non défini	non défini	non défini	non défini	Promotion implicite au rôle propriétaire. Jamais hors poste local.
`KYSPECTRA_E2E_BYPASS_AUTH`	non défini	non défini	non défini	non défini	Contournement d'authentification pour tests. Ignoré en mode `jwt`, mais ne le laissez jamais traîner.
`NEXT_PUBLIC_DEV_ADMIN_ROLES`	vide	au besoin	vide	vide	Pré-cocher un rôle d'administrateur donne les pleins pouvoirs à quiconque ouvre la page.
`NEXT_PUBLIC_DEV_ADMIN_ID`	vide	au besoin	vide	vide	Idem.
`NEXT_PUBLIC_DEV_TENANT_ID`	vide	au besoin	vide	vide	Réduit le risque d'action sur le mauvais locataire.

#3.2 Drapeaux d'exécution et de déploiement

Drapeau	Défaut	Développement	Qualification	Production	Justification
`DEPLOY_LIVE`	`False`	`True`	`True`	`True` après validation des garde-fous	Interrupteur maître. À faux, refus honnête ; jamais de déploiement simulé.
`DEPLOY_REQUIRE_APPROVAL`	`False`	`False`	`True`	`True`	Impose un approbateur distinct du demandeur. Contrôle central de séparation des devoirs sur le déploiement.
`GOLIVE_ENABLED`	`False`	`True`	`True`	`True` si le besoin est établi	Ouvre la mise en ligne sur sous-domaine.
`RPA_BROWSER_ENABLED`	`False`	au besoin	`False`	`False` sauf besoin explicite	Automatisation de navigateur : surface d'attaque élevée.
`SESSION_GOVERNOR_ENABLED`	`False`	`False`	à évaluer	à évaluer	Fonction en cours.
`CHECKPOINT_STORE_ENABLED`	`False`	`False`	à évaluer	à évaluer	Fonction en cours.
`EVIDENCE_SCRUB_ENABLED`	`True`	`True`	`True`	`True`	Nettoyage des preuves. Ne jamais désactiver.
`SPEC_APPLY_ENABLED`	`False`	au besoin	`False`	`False`	Application automatique de spécification : effet large.
`VCS_MULTI_PROVIDER_ENABLED`	`False`	au besoin	`False`	`False`	Élargit la surface d'intégration.

#3.3 Drapeaux de registre et de gouvernance

Drapeau	Défaut	Recommandation	Justification
`REGISTRY_VIRTUAL_ROLES_ENABLED`	`False`	Décision produit explicite. Si activé, l'activer d'abord en qualification et vérifier le plafonnement par plan.	Page Rôles IA inopérante tant qu'il est faux. Le drapeau n'est activé dans aucun manifeste.
`REGISTRY_TIERED_SCOPES_ENABLED`	`False`	Idem.	Portées global/locataire/utilisateur.
`AGENT_REGISTRY_ENABLED`	`True`	`True`	Registre central = source de vérité des agents. Le désactiver aveugle la gouvernance.
`DEMO_MODULE_ENABLED`	`False`	`True` en portée Locataire uniquement, sur le locataire de démonstration réservé	Une portée Globale ouvrirait le module sur tous les locataires.

#3.4 Drapeaux de fonctionnalité créés dans le portail

Règles applicables à tout drapeau que vous créez vous-même :

Règle	Détail
Portée minimale	Locataire par défaut. Global uniquement quand l'effet plateforme est voulu et documenté.
Créer désactivé	Comportement natif du portail — ne le contournez pas.
Démarrer à 0 %	Activer puis monter par paliers 5 → 25 → 50 → 100.
Description obligatoire	Date de création, responsable, date de retrait prévue.
Durée de vie bornée	Un drapeau à 100 % depuis plus d'un mois doit être retiré du code puis supprimé.
Retour arrière testé	Vérifier que la désactivation produit l'effet attendu en moins d'une minute.
Jamais de secret dans la clé ni la description	Ces champs sont lisibles par tout opérateur.

⚠️ Un drapeau créé dans le portail ne pilote pas un service backend : les drapeaux de service sont des variables d'environnement. Seule exception documentée : le module de démonstration.

#4. Gestion des rôles et principe du moindre privilège

#4.1 Les deux échelles de rôles

Ne les confondez jamais.

Échelle	Valeurs	Portée	Attribuée où
Rôles plateforme	`viewer`, `platform_operator`, `platform_admin`	Le plan de contrôle entier	Serveur d'identité (mode `jwt`) ou auto-déclaration (mode `dev-headers`)
Rôles de locataire	`VIEWER`, `EDITOR`, `PUBLISHER`, `ADMIN`, `OWNER`	Un locataire	Page Utilisateurs du portail d'administration

#4.2 Règles d'attribution des rôles plateforme

Règle	Détail
R-1	Attribuer le rôle le plus faible qui permette le travail attendu.
R-2	`platform_admin` est un rôle d'exception, pas de confort.
R-3	Au moins trois administrateurs plateforme distincts. En dessous de deux, aucune publication de capacité globale ne peut être approuvée : la plateforme se bloque par construction.
R-4	Aucun compte partagé. Un compte partagé détruit l'attribution des décisions et invalide la séparation des devoirs.
R-5	Second facteur obligatoire pour tout administrateur plateforme.
R-6	L'exploitation courante (budgets, drapeaux, interruption, exports) se fait en `platform_operator`.
R-7	Un compte de lecture (`viewer`) suffit pour l'audit et la conformité.

#4.3 Choix du rôle plateforme selon la fonction

Fonction	Rôle recommandé	Pourquoi
Astreinte d'exploitation	`platform_operator`	Peut interrompre une exécution, ajuster un budget, désactiver un drapeau
Ingénierie plateforme	`platform_admin`	Modèles, politiques, registre, agents
Conformité, audit interne	`viewer`	Lecture complète, aucune écriture
Direction, comité	`viewer`	Aucun besoin d'écriture
Prestataire externe	`viewer`, ou aucun accès	Élargir ponctuellement, avec date de fin

Limite connue de la matrice. La mise en pause d'un membre du personnel virtuel est gardée par la capacité de gestion des agents, réservée à l'administrateur. Un opérateur d'astreinte ne peut donc pas mettre un agent en pause. Sa voie disponible est l'interruption d'exécution. Documentez ce point dans votre procédure d'astreinte, ou prévoyez un administrateur joignable en permanence.

#4.4 Règles d'attribution des rôles de locataire

Règle	Détail
L-1	Un seul rôle par utilisateur. Les rôles sont composites : le plus élevé implique les précédents.
L-2	`OWNER` est nominatif et limité au responsable réel du locataire.
L-3	Un compte créé sans rôle ne peut rien faire : c'est l'état sûr par défaut.
L-4	Le retrait d'un rôle est immédiat et sans confirmation — c'est l'outil de coupure d'urgence.
L-5	Renseignez toujours prénom et nom : le journal d'audit devient lisible.

#4.5 Règles sur les dérogations de permission

Règle	Détail
D-1	Une dérogation est une exception, pas un mode de gestion. Si vous en posez plus de trois pour un même profil, c'est le modèle de rôles qui est à revoir.
D-2	Motif obligatoire en pratique : le champ est facultatif dans le formulaire, imposez-le par procédure. Sans motif, la dérogation est ininterprétable six mois plus tard.
D-3	Toute dérogation `Autoriser` est un élargissement : elle doit être revue mensuellement.
D-4	Une dérogation `Refuser` est un durcissement : elle peut être conservée plus longtemps.
D-5	Les dérogations de portée Locataire ne sont pas révocables depuis le portail. Vérifiez la portée avant de créer.

#4.6 Interdits

#	Interdit
1	Exposer un environnement en mode `dev-headers` à des utilisateurs réels
2	Pré-cocher un rôle d'administrateur via un semis d'environnement
3	Partager un compte d'administrateur plateforme
4	Utiliser un compte d'administrateur pour l'exploitation courante
5	Attribuer `OWNER` par confort
6	Poser une dérogation sans motif écrit
7	Supprimer un utilisateur au lieu de le suspendre lors d'une enquête
8	Approuver une revue à haut risque sans avoir lu le sujet

#5. Rotation des secrets

#5.1 Principe

Le plan de contrôle ne détient aucun secret. Il détient des chemins et des noms de sous-clés. Conséquence directe : la rotation d'un secret se fait dans le coffre, pas dans le portail.

#5.2 Ce qui se trouve où

Élément	Où il vit	Manipulé par le portail
Clé d'API d'un fournisseur de modèle	Coffre	❌ — seul le chemin
Justificatif d'un serveur d'outils	Coffre	❌ — chemin + noms de sous-clés
Secret de client d'identité	Coffre / configuration du backend	❌
Clé de chiffrement des justificatifs	Provisionnée vers l'exécution	❌
Jeton de session utilisateur	Navigateur, durée de vie bornée	Indirectement
Identifiants de locataire et d'utilisateur	Base de données	✅ — ce ne sont pas des secrets

#5.3 Cadence recommandée

Type de secret	Cadence normale	Rotation immédiate si
Clé de fournisseur de modèle	90 jours	Suspicion d'exposition, départ d'un détenteur
Justificatif d'outil externe	90 jours	Idem, ou compromission du fournisseur
Secret de client d'identité	180 jours	Compromission
Clé de chiffrement des justificatifs	365 jours, avec plan de reprise	Compromission
Mot de passe provisoire d'un utilisateur	À la première connexion	Toujours

#5.4 Procédure de rotation sans interruption

Déposer la nouvelle valeur dans le coffre, sous un nouveau chemin (par exemple en incrémentant un suffixe de version).
Vérifier que la nouvelle valeur fonctionne, depuis un environnement de recette.
Basculer le chemin dans le portail :
- Modèle : page Modèles & adaptateurs → Modifier → nouveau chemin → valider.
- Serveur d'outils : page Registre, onglet Outils (MCP) → Modifier l'authentification → nouveau chemin → valider.
Vérifier que le nouveau chemin apparaît dans le panneau Politiques d'accès Vault de la page Gouvernance.
Tester par une exécution réelle : page Flotte d'agents, statut attendu Terminé.
Retirer l'ancienne valeur du coffre après une période d'observation.
Consigner la rotation : date, secret, opérateur, motif.

Cette procédure évite toute fenêtre d'indisponibilité : l'ancienne valeur reste utilisable jusqu'à l'étape 6.

#5.5 Rotation d'urgence après exposition

Révoquer immédiatement le secret chez le fournisseur.
Déposer la nouvelle valeur dans le coffre.
Basculer le chemin dans le portail.
Révoquer la capacité concernée dans le Registre, avec un motif explicite. Rappel : la révocation désactive toutes les liaisons associées.
Exporter le journal d'audit sur la période d'exposition (filtres Acteur / Ressource).
Lire l'audit des appels d'outils sur la page Gouvernance : verdicts de politique, issues, coûts, empreintes d'arguments.
Ouvrir la réponse à incident (§8).

#5.6 Contrôles anti-fuite

Contrôle	Où il s'applique	Limite
Validation de forme du chemin	Champs de chemin de coffre — refus si le préfixe `secret/` manque	N'empêche pas une chaîne malformée mais bien préfixée
Analyse de contenu	Instructions de compétence, avant publication	Ne couvre pas les autres champs
Chemin obligatoire dès qu'il y a authentification	Serveurs d'outils	—
Avertissement explicite	En-têtes statiques : « jamais de justificatif ici »	Purement textuel
Empreintes au lieu des arguments	Audit des appels d'outils	Volontaire — les arguments bruts ne sont jamais consultables

Si un secret a été saisi dans un champ de chemin, considérez-le comme exposé : il a transité et il est persisté. Appliquez §5.5 sans délai.

#6. Revue périodique des accès

#6.1 Calendrier

Fréquence	Objet	Rôle
Hebdomadaire	Chaîne d'audit, comptes ajoutés, dérogations créées	Opérateur
Mensuelle	Revue nominative complète, dérogations, drapeaux, budgets	Administrateur
Trimestrielle	Rôles plateforme, politiques d'exécution, garde-fous, plafonds d'autonomie	Administrateur + sécurité
Annuelle	Modèle de menace, durées de conservation, procédure d'incident	Sécurité + protection des renseignements

#6.2 Revue mensuelle — déroulé

Pour chaque locataire actif :

Ouvrez Utilisateurs, exportez visuellement la liste : Courriel, Nom, Statut, Rôles.
Pour chaque ligne, répondez à trois questions :
- La personne est-elle toujours en poste ?
- Le rôle est-il toujours le plus faible suffisant ?
- Le compte a-t-il été utilisé récemment ?
Traitez les écarts : suspendre, abaisser le rôle, retirer les rôles.
Ouvrez Permissions effectives & dérogations pour chaque utilisateur porteur de dérogations.
Toute dérogation Autoriser sans motif écrit est révoquée par défaut.
Faites valider la liste par le responsable du locataire, et conservez la validation.

Au niveau plateforme :

Listez les détenteurs de platform_admin. Justifiez chacun.
Vérifiez qu'aucun compte n'est partagé.
Vérifiez qu'il reste au moins trois administrateurs distincts.
Vérifiez que le second facteur est actif pour chacun.

#6.3 Revue trimestrielle — déroulé

Politiques d'exécution : pour chaque hôte de l'allowlist d'egress, exiger une justification écrite. Retirer les autres.
Garde-fous : vérifier l'ordre des priorités ; tester cinq actions sensibles avec Évaluer une action ; vérifier qu'une action non couverte est bien refusée.
Plafonds d'autonomie : tout rôle en N2 ou N3 doit être justifié. Recalculer l'autonomie effective (min(plafond, maximum du plan)).
Serveurs d'outils MCP : chaque serveur est-il encore utilisé ? Ses justificatifs ont-ils été renouvelés dans les 90 jours ?
Compétences et prompts globaux : retirer ceux qui ne sont plus utilisés, par révocation motivée.
Modèles : configurations orphelines, adaptateurs pointant vers une clé inexistante, modèle par défaut cohérent et activé.
Drapeaux : supprimer ceux à 100 % depuis plus d'un mois ; questionner ceux à 0 % depuis longtemps.
Agents : comparer la liste des agents actifs à l'attendu.

#6.4 Traces à conserver pour chaque revue

Élément	Format
Date et périmètre	Consigné
Personne ayant conduit la revue	Nominatif
Liste examinée	Capture ou export
Écarts constatés et décisions	Consigné
Validation par le responsable du locataire	Conservée
Rapport de conformité de la période	Fichier JSON archivé

#7. Journalisation et conservation

#7.1 Ce qui est journalisé

Source	Contenu	Consultable depuis
Journal d'audit	Acteur, action, ressource, horodatage, empreinte chaînée	Page Audit & conformité
Audit des appels d'outils	Agent, type, verdict de politique, issue, coût, empreinte des arguments	Page Gouvernance & SoD
Vérifications de politique	Décisions du moteur, y compris les refus par défaut	Service d'exécution
Rapports de conformité	Agrégation par période + état de la chaîne	Page Audit & conformité

#7.2 Ce qui n'est pas journalisé

Angle mort	Conséquence	Contournement
Export JSON d'un rapport	Produit par le navigateur : aucune trace serveur	Consignation manuelle des extractions
Consultations en lecture	Seules les actions sont tracées	Journaux d'infrastructure
Arguments bruts des appels d'outils	Seule l'empreinte est conservée	Volontaire — exigence de protection des renseignements
Changement de locataire actif	Réglage local au navigateur	—
Changement de thème ou de langue	Réglage local	—

#7.3 Propriétés du journal

Propriété	Détail	Limite
Ajout seul	Aucune route de modification ni de suppression	—
Chaînage par hachage	Chaque empreinte dépend de la précédente	La détection est postérieure à l'altération
Vérification à la demande	Bouton Vérifier la chaîne	Coût croissant avec le volume
Localisation de la rupture	Identifiant, motif, position	—
Attestation	Indicateur Chaîne vérifiée sur le rapport	Ne vaut que pour la période couverte

#7.4 Durées de conservation recommandées

Élément	Durée recommandée	Justification
Journal d'audit	7 ans	Aligné sur les obligations de conservation les plus longues du secteur réglementé
Rapports de conformité	7 ans	Pièces probantes
Audit des appels d'outils	3 ans	Enquête et analyse de coût
Traces de revue d'accès	3 ans	Preuve de contrôle périodique
Journaux d'infrastructure	1 an	Diagnostic
Données du locataire de démonstration	Aucune	Réinitialisées à volonté ; ne doivent contenir aucune donnée réelle

[Gabarit : durées à confirmer par le responsable de la protection des renseignements personnels au regard des obligations sectorielles applicables au client.]

#7.5 Sauvegarde et restauration

Contrôle	Attendu
Sauvegarde du journal d'audit	Quotidienne, hors du cluster de production
Test de restauration	Trimestriel, documenté
Vérification de chaîne après restauration	Obligatoire — une restauration partielle rompt la chaîne
Chiffrement des sauvegardes	Au repos et en transit
Accès aux sauvegardes	Restreint, journalisé, distinct des accès de production

#8. Réponse à incident en six phases

#8.1 Déclencheurs

Déclencheur	Gravité initiale
Chaîne d'audit signalée compromise	Critique
Rapport de conformité avec « Chaîne vérifiée : Non »	Critique
Secret exposé dans un champ de configuration	Critique
Accès d'un locataire à des données d'un autre	Critique
Compte d'administrateur plateforme compromis	Critique
Agent atteignant un hôte non autorisé	Élevée
Dépassement de budget inexpliqué	Élevée
Compte actif après un départ	Élevée
Approbation obtenue en contournant le double contrôle	Élevée

#8.2 Phase 1 — Détecter et qualifier

Objectif : savoir ce qui s'est passé, et à quel point c'est grave.

Notez l'heure de découverte, le canal, la personne qui a détecté.
Identifiez le locataire, la ressource, l'acteur apparent.
Ouvrez Audit & conformité, filtrez sur Acteur, Action, Ressource.
Exécutez Vérifier la chaîne. Notez le résultat exact.
Qualifiez :

Question	Réponse attendue
Y a-t-il eu accès à des renseignements personnels ?	Oui / Non / Indéterminé
Combien de personnes concernées ?	Nombre ou fourchette
Le risque est-il sérieux ?	Détermine l'obligation de déclaration
L'accès est-il encore ouvert ?	Détermine l'urgence de la phase 2

Attribuez une gravité et nommez un responsable d'incident.

#8.3 Phase 2 — Contenir

Objectif : arrêter l'hémorragie. Objectif de temps : moins de 15 minutes pour un incident critique.

Couper les accès humains — page Utilisateurs : retirer tous les rôles, passer le statut à Suspendu (runbook R3). Ne supprimez pas.
Arrêter les agents — page Flotte d'agents : interrompre les exécutions concernées (runbook R14). Répétez locataire par locataire : il n'existe pas de vue agrégée.
Fermer les capacités — page Registre : révoquer la compétence ou le serveur d'outils impliqué, avec motif. La révocation désactive toutes les liaisons.
Refermer le réseau — page Garde-fous & exécution : retirer les hôtes non justifiés de l'allowlist d'egress.
Refermer la fonctionnalité — page Feature-flags : désactiver le drapeau qui exposait le comportement. Effet immédiat.
Abaisser l'autonomie — page Rôles IA : ramener le plafond du rôle concerné à N0 ou N1.
Faire tourner les secrets exposés (§5.5).

#8.4 Phase 3 — Préserver la preuve

Objectif : figer un état opposable, avant toute correction.

Générez un rapport de conformité sur la période de l'incident (runbook R12). Vérifiez l'indicateur Chaîne vérifiée.
Exportez le rapport en JSON et déposez-le dans le coffre documentaire. Consignez l'export manuellement : il n'en existe aucune trace serveur.
Capturez les écrans utiles : résultat de vérification de chaîne, audit des appels d'outils, détail des exécutions concernées.
Extrayez les journaux d'infrastructure sur la même fenêtre.
N'effectuez aucune écriture supplémentaire sur le locataire concerné tant que la preuve n'est pas figée.

Une chaîne d'audit rompue ne se répare pas. Elle se constate, se date et se documente. Toute tentative de « correction » aggrave le problème et détruit la valeur probante.

#8.5 Phase 4 — Éradiquer

Objectif : supprimer la cause, pas seulement l'effet.

Identifiez la cause première. Distinguez trois familles :

Famille	Exemple	Correction
Configuration	Mode `dev-headers` exposé, allowlist trop large, drapeau global activé trop tôt	Corriger la configuration, tester en qualification
Modèle d'accès	Rôle trop élevé, dérogation oubliée, compte partagé	Corriger le modèle de rôles, supprimer la dérogation
Capacité	Compétence ou serveur d'outils malveillant ou mal cadré	Révoquer, revoir le pipeline de revue

Corrigez d'abord en qualification, vérifiez, puis en production.
Vérifiez qu'aucun autre environnement ne porte le même défaut.
Vérifiez que la correction ne crée pas de régression : parcourez les seize destinations.

#8.6 Phase 5 — Notifier

Objectif : informer qui doit l'être, dans les formes.

Le responsable de la protection des renseignements personnels décide de l'obligation de déclaration, sur la base de la qualification de la phase 1. Ce n'est pas la décision de l'administrateur plateforme.
Préparez le dossier :

Élément	Source
Nature des renseignements concernés	Qualification, phase 1
Nombre de personnes concernées	Qualification, phase 1
Circonstances et date de survenance	Journal d'audit
Mesures de confinement prises	Phase 2, horodatées
Preuve d'intégrité du journal	Rapport de conformité, phase 3
Mesures correctives	Phase 4

Informez l'autorité compétente et les personnes concernées selon la décision du responsable.
Informez les responsables des locataires affectés.
Consignez chaque notification : destinataire, date, contenu.

[Gabarit : délais et modalités de notification à préciser avec le conseil juridique selon la juridiction applicable au client.]

#8.7 Phase 6 — Apprendre et durcir

Objectif : rendre la répétition impossible.

Tenez une revue d'incident dans les cinq jours ouvrés, sans recherche de responsable individuel.
Répondez à cinq questions :
- Qu'est-ce qui a permis l'incident ?
- Pourquoi ne l'a-t-on pas détecté plus tôt ?
- Quel contrôle aurait dû l'empêcher ?
- Ce contrôle existait-il, et pourquoi n'a-t-il pas joué ?
- Que faut-il changer, dans la configuration ou dans la procédure ?
Produisez au plus trois actions, chacune avec un responsable et une échéance.
Mettez à jour ce guide : liste de contrôle (§2), configuration des drapeaux (§3), matrice de risques (§9).
Ajoutez la ligne correspondante au registre des décisions de sécurité (§10).
Vérifiez l'application des actions à la revue mensuelle suivante.

#8.8 Vue d'ensemble

Aucun diagramme à afficher

Diagramme 1 — flowchart

#9. Matrice de risques et mesures d'atténuation

#9.1 Échelle

Niveau	Probabilité	Impact
Élevé	Attendu sans mesure spécifique	Compromission de données, arrêt de service, perte de valeur probante
Moyen	Possible dans des conditions courantes	Dégradation, coût non maîtrisé, écart de conformité
Faible	Nécessite un enchaînement improbable	Gêne, correction simple

#9.2 Matrice

#	Risque	Prob.	Impact	Niveau	Mesures d'atténuation	Risque résiduel
1	Environnement exposé en mode `dev-headers` — n'importe qui se déclare administrateur	Élevée	Élevé	🔴 Critique	Définir explicitement `jwt` côté portail et backend ; vider les semis d'identité ; contrôle n° 1 à 9 de la liste de mise en production ; vérification à chaque déploiement	Faible si le contrôle est automatisé dans la chaîne de livraison
2	Modes d'authentification incohérents — portail et backend désalignés	Moyenne	Élevé	🔴 Critique	Les deux valeurs changent ensemble, dans les deux sens ; test de connexion obligatoire après chaque bascule ; procédure R16 du guide administrateur	Faible
3	Divergence de domaine d'identité — configuration décrivant `sso` là où le portail vise `kyspectra`	Élevée	Élevé	🔴 Critique	Arbitrage explicite du propriétaire produit avant toute bascule ; vérification de bout en bout	Nul une fois tranché
4	Règle de sortie réseau vers le serveur d'identité manquante — passerelle en redémarrage continu, portail inutilisable	Moyenne	Élevé	🔴 Critique	Règle de sortie explicite sur l'espace en refus par défaut ; au moins deux répliques de passerelle ; contrôle n° 14-15 ; supervision de la santé	Faible
5	Sonde de vitalité couplée à la base de données — service à réplique unique en oscillation, 503 intermittents	Élevée	Moyen	🟠 Élevé	Sonde de vie découplée du magasin ; au moins deux répliques ; audit de tous les services, le défaut est systémique	Faible
6	Exfiltration par un agent — sortie réseau non maîtrisée	Moyenne	Élevé	🔴 Critique	Politique réseau en `deny-` imposée par l'interface ; allowlist d'egress justifiée hôte par hôte ; durée maximale d'exécution serrée ; système de fichiers éphémère ; revue trimestrielle	Moyen — dépend de la discipline de l'allowlist
7	Secret saisi dans un champ de chemin	Moyenne	Élevé	🔴 Critique	Validation de forme `secret/` ; analyse de contenu sur les compétences ; formation ; contrôle n° 33-38 ; rotation d'urgence documentée	Moyen — le champ accepte techniquement toute chaîne préfixée
8	Fuite entre locataires	Faible	Élevé	🟠 Élevé	Masquage d'existence par 404 ; résolution du locataire à précédence stricte ; isolation au niveau des lignes	Faible
9	Action sur le mauvais locataire — création d'utilisateur, interruption d'exécution	Élevée	Moyen	🟠 Élevé	Vérification systématique du sélecteur avant toute écriture ; ne pas câbler un identifiant de production dans les semis ; procédure de double vérification pour les actions destructrices	Moyen — aucun garde-fou technique
10	Contournement du double contrôle — même personne, deux comptes	Faible	Élevé	🟠 Élevé	Refus en base de données sur l'auto-approbation ; interdiction des comptes partagés ; au moins trois administrateurs distincts ; revue mensuelle des détenteurs	Moyen — le contrôle porte sur l'identifiant, pas sur la personne
11	Altération du journal d'audit	Faible	Élevé	🟠 Élevé	Chaînage par hachage ; ajout seul ; vérification hebdomadaire ; sauvegarde hors cluster ; test de restauration trimestriel	Moyen — la détection est postérieure
12	Drapeau global activé sans confirmation — bascule plateforme par un clic	Moyenne	Élevé	🟠 Élevé	Portée Locataire par défaut ; création désactivée à 0 % ; montée par paliers ; description avec date de retrait ; test du retour arrière	Moyen — l'interface ne demande aucune confirmation
13	Ordre de priorité des garde-fous mal réglé — autorisation large neutralisant un refus ciblé	Moyenne	Élevé	🟠 Élevé	Règle : refus ciblés en priorité basse, autorisations larges ensuite ; test avec Évaluer une action ; revue trimestrielle	Moyen
14	Plafond d'autonomie trop élevé	Moyenne	Moyen	🟡 Moyen	Autonomie effective = `min(plafond, maximum du plan)` ; repli sur N1 en cas de dégradation ; revue trimestrielle de tous les rôles en N2/N3	Faible
15	Capacité importée malveillante ou mal cadrée	Moyenne	Élevé	🟠 Élevé	Pipeline gouverné : provenance → signature → classification → validation → analyse de secrets → revue de séparation des devoirs ; jamais d'auto-approbation ; import idempotent	Moyen — la qualité dépend de la revue humaine
16	Dérive de coût	Élevée	Moyen	🟠 Élevé	Budget obligatoire à la création d'un locataire ; seuils 80/95 ; fenêtres de quota ; interruption d'exécution ; audit des coûts par appel d'outil	Moyen — la réaction reste humaine
17	Compte actif après un départ	Moyenne	Élevé	🟠 Élevé	Revue mensuelle nominative ; procédure de retrait d'urgence en moins de trois minutes ; validation par le responsable du locataire	Moyen — aucune détection automatique d'inactivité
18	Impossibilité de suspendre un locataire entier	Certaine	Moyen	🟠 Élevé	Écart backend assumé et affiché ; contournement par retrait des rôles utilisateur par utilisateur ; procédure documentée	Moyen jusqu'à correction
19	Dérogation `Autoriser` oubliée	Moyenne	Moyen	🟡 Moyen	Motif imposé par procédure ; revue mensuelle ; révocation par défaut des dérogations non motivées	Faible
20	Suppression d'un utilisateur au lieu d'une suspension	Moyenne	Moyen	🟡 Moyen	Procédure imposant le statut Suspendu en cas d'enquête ; formation	Faible
21	Modèle par défaut désactivé — toutes les exécutions échouent	Moyenne	Moyen	🟡 Moyen	Vérification conjointe des cases « Par défaut » et « Activé » ; test d'exécution après chaque changement ; point de retour arrière noté	Faible
22	Adaptateur pointant vers une clé de modèle inexistante	Élevée	Faible	🟡 Moyen	Recopie de la clé depuis le tableau ; revue trimestrielle des configurations orphelines	Faible
23	Politique d'exécution créée sans egress ni système de fichiers	Élevée	Faible	🟡 Moyen	Édition immédiate après création ; le comportement par défaut est sûr (aucune sortie) mais surprenant	Faible
24	Absence de trace des exports de rapport	Certaine	Faible	🟡 Moyen	Consignation manuelle imposée par procédure	Moyen jusqu'à correction
25	Catalogue de plans public et non filtré	Certaine	Faible	🟡 Moyen	Nettoyage du catalogue avant lancement ; ne rien y stocker de sensible	Faible après nettoyage
26	Locataire créé avec un plan inexistant	Élevée	Faible	🟡 Moyen	Écraser systématiquement la valeur par défaut du champ Plan ; correction du défaut dans le code	Faible après correction
27	Textes de développement visibles par l'utilisateur — mentions « TODO », clés de traduction manquantes	Certaine	Faible	🟡 Moyen	Prérequis de lancement ; contrôle n° 52-53	Nul après correction
28	Confusion entre drapeaux du portail et variables de service	Élevée	Faible	🟡 Moyen	Distinction documentée ; formation des opérateurs	Faible
29	Supervision purement active — aucune alerte poussée	Certaine	Moyen	🟡 Moyen	Rituels quotidien, hebdomadaire et mensuel ; branchement sur l'observabilité d'infrastructure pour l'alerte	Moyen
30	Saturation du cluster de développement — mise à jour bloquée, ancienne version servie	Élevée	Faible	🟡 Moyen	Stratégie de mise à jour libérant avant de remplacer ; vérification de la version servie après chaque déploiement	Faible — développement uniquement

#9.3 Les cinq risques à traiter en priorité

Rang	Risque	Action immédiate
1	Environnement exposé en mode `dev-headers` (n° 1)	Définir `jwt` explicitement, portail et backend
2	Divergence de domaine d'identité (n° 3)	Faire trancher par le propriétaire produit
3	Règle de sortie réseau manquante (n° 4)	Vérifier la règle et porter la passerelle à deux répliques
4	Sonde de vitalité couplée à la base (n° 5)	Auditer tous les services, découpler les sondes
5	Exfiltration par un agent (n° 6)	Justifier chaque hôte de chaque allowlist d'egress

#10. Registre des décisions de sécurité

Tenez ce registre à jour. Il est la mémoire des arbitrages et le premier document qu'un auditeur demandera.

Champ	Contenu attendu
Identifiant	Numéro séquentiel
Date	Date de la décision
Objet	Ce qui a été décidé
Contexte	Pourquoi la question s'est posée
Options examinées	Au moins deux
Décision	Formulation sans ambiguïté
Risque accepté	Ce que l'on assume en connaissance de cause
Compensation	Ce qui atténue ce risque
Décideur	Nominatif
Date de réexamen	Échéance de revalidation

#10.1 Décisions à consigner dès l'ouverture du registre

#	Objet	Statut
1	Mode d'authentification retenu par environnement	À consigner
2	Domaine d'identité retenu	En attente d'arbitrage
3	Liste nominative des administrateurs plateforme	À consigner
4	Durées de conservation retenues	`[Gabarit : à confirmer avec le responsable de la protection des renseignements personnels]`
5	Hôtes autorisés en sortie, avec justification	À consigner
6	Plafonds d'autonomie accordés au-delà de N1	À consigner
7	Drapeaux activés en production, avec date de retrait	À consigner
8	Écarts connus acceptés jusqu'au lancement	À consigner (voir §9 du guide administrateur)
9	Cadence de rotation des secrets retenue	À consigner
10	Périmètre et fréquence des revues d'accès	À consigner

KySpectra — Plateforme agentique SDD/SDLC · par Kyrieva
Documentation : kyspectradoc.kyrieva.com · Dossier de lancement : Strategielancement/
Document interne de pré-lancement — version 1.0 du 2026-08-17. Les données marquées « [Gabarit : … ] » doivent être renseignées ou revalidées avant diffusion externe.