Kill Switch

L'écran Kill Switch permet de comparer l'état souhaité de chaque kill switch de sécurité avec l'état observé sur la cible, de vérifier à nouveau un kill switch et de le lever par la reprise à quatre yeux : une demande, deux approbations distinctes, puis une réautorisation de la cible. Chemin dans le portail : /security/kill-switch, menu Sécurité et gouvernance > Kill Switch. Il sert aux responsables sécurité et aux administrateurs de tenant après un ordre de confinement, et aux analystes SOC qui suivent la convergence.

Ce que montre l'écran

L'écran (KillSwitch dans portal/src/screens/security-kit.tsx) commence par l'indication « Un kill switch converge quand l'état observé correspond à l'état souhaité. L'isolation réseau et l'arrêt de charge attendent un reçu signé. », puis deux tableaux.

Kill switches, lu dans GET /v1/soc/kill-switches :

Colonne	Contenu
Réaction	Réaction de l'ordre de confinement, par exemple `SUSPEND_AGENT`.
Type de cible, Cible	Ce que le kill switch retient.
État souhaité	`SUSPENDED` tant que le kill switch tient, `RELEASED` après la reprise.
État observé	État mesuré sur la cible, par exemple `SUSPENDED_VERIFIED` ou `VERIFICATION_FAILED`.
Convergé	Calculé par le portail : oui quand `SUSPENDED` rencontre `SUSPENDED_VERIFIED`, ou `RELEASED` rencontre `RELEASED`.
Dernier reçu	Identifiant du dernier reçu.
Dernière vérification	Date de la dernière vérification.

Filtre État : active (kill switches encore SUSPENDED, valeur par défaut de l'API) ou all. Les kill switches apparaissent quand un ordre de confinement est appliqué.

Reprises, lu dans GET /v1/soc/recoveries : colonnes Kill switch, Raison, Statut (pending, approved, recovered, rejected), Demandé par, Approuvé par (liste des approbateurs), Réautorisé par. Filtre Statut. « Demandez une reprise sur un kill switch actif : deux approbateurs distincts sont requis. »

Un clic sur une ligne de l'un ou l'autre tableau affiche la ligne dans un panneau latéral.

Actions

Bouton ou action	Effet	Appel API	Rôles
Vérifier la signature (menu de la ligne d'un kill switch)	Relance la vérification du kill switch et affiche la réponse dans un panneau latéral ; audité sous `soc.kill_switch.verify`.	`POST /v1/soc/kill-switches/{switch_id}/verify`	Menu : `security_officer`, `tenant_admin` ; le serveur ajoute `soc_analyst`
Demander une reprise (menu de la ligne, kill switch `SUSPENDED`)	Ouvre un formulaire avec Raison (obligatoire, au moins 3 caractères), puis Demander une reprise.	`POST /v1/soc/recoveries`	Menu : `security_officer`, `tenant_admin` ; le serveur ajoute `soc_analyst`
Approuver (menu de la ligne, reprise `pending`)	Ouvre un formulaire avec une Raison facultative, puis Approuver. La reprise passe à `approved` au second approbateur distinct.	`POST /v1/soc/recoveries/{recovery_id}/approve`	`security_officer`, `tenant_admin`
Réautoriser (menu de la ligne, reprise `approved`)	Après une confirmation, libère le kill switch, réévalue la cible par le point de décision des politiques et la rétablit (un agent suspendu reprend) ; la réponse s'affiche dans un panneau latéral.	`POST /v1/soc/recoveries/{recovery_id}/reauthorize`	`security_officer`, `tenant_admin`, et l'un des approbateurs
Filtrer	Applique le filtre État ou Statut.	`GET /v1/soc/kill-switches` (paramètre `state`) ou `GET /v1/soc/recoveries` (paramètre `status`)	`security_officer`, `tenant_admin`, `auditor`, `soc_analyst`
Icône d'actualisation d'un tableau	Relit la liste.	Les mêmes routes	Les mêmes

attention

REVOKE_CREDENTIAL reste en vigueur après la reprise : la clé d'API reste révoquée et une nouvelle clé doit être émise.

Rôles

Le portail affiche les actions de ligne à ROLES.socLead (security_officer, tenant_admin, portal/src/lib/kit.ts). Le Control Plane (services/control-plane/src/eai/domains/soc/__init__.py et services/control-plane/src/eai/domains/soc/recovery.py) exige :

lecture des deux tableaux : security_officer, tenant_admin, auditor ou soc_analyst ;
vérification et demande de reprise : security_officer, soc_analyst ou tenant_admin ;
approbation et réautorisation : security_officer ou tenant_admin.

La reprise est à quatre yeux : le demandeur ne peut pas approuver, les deux approbations viennent de deux personnes distinctes, et seule l'une d'elles peut réautoriser. platform_admin passe tous les contrôles de rôle.

Tâches courantes

Vérifier qu'un confinement tient

Lister les kill switches actifs. Filtre État active, Filtrer. Résultat attendu : les kill switches encore SUSPENDED. En cas d'échec : forbidden (HTTP 403) signifie que vos rôles ne lisent pas le SOC.
Lire la convergence. Convergé indique si la cible a réellement appliqué le kill switch. Cherchez Convergé Non. Résultat attendu : chaque kill switch a convergé. En cas d'échec : un kill switch ISOLATE_NETWORK ou TERMINATE_WORKLOAD attend un reçu signé du cluster ; vérifiez côté cluster.
Vérifier à nouveau. Menu de la ligne > Vérifier la signature. Résultat attendu : un panneau latéral avec le nouvel État observé et la Dernière vérification. En cas d'échec : not_found signifie que le kill switch a été retiré ; actualisez le tableau.

Lever un kill switch après l'incident

Demander la reprise. La reprise est le seul chemin de retour : RECOVER n'est pas un ordre. Menu de la ligne du kill switch > Demander une reprise, Raison, puis Demander une reprise. Résultat attendu : une nouvelle ligne pending dans Reprises. En cas d'échec : recovery_already_open (HTTP 409) signale une demande déjà en attente ou approuvée ; kill_switch_not_active (HTTP 409) signale que le kill switch n'est plus SUSPENDED.
Réunir deux approbations. Deux personnes, toutes deux différentes du demandeur, approuvent. Chacune ouvre le menu de la ligne > Approuver. Résultat attendu : après la seconde, le statut approved et deux noms dans Approuvé par. En cas d'échec : separation_of_duties (HTTP 409) pour le demandeur ; already_approved (HTTP 409) quand la même personne approuve deux fois.
Réautoriser. L'un des approbateurs libère le kill switch et laisse la politique réévaluer la cible. Menu de la ligne > Réautoriser, acceptez la confirmation. Résultat attendu : le statut recovered, Réautorisé par rempli et le kill switch RELEASED. En cas d'échec : reauthorization_by_approver (HTTP 403) si vous n'avez pas approuvé ; reauthorization_denied (HTTP 403) si le point de décision refuse la cible ; recovery_not_approved (HTTP 409) avant la seconde approbation.

Dépannage

Symptôme	Cause	Correction
`forbidden` (HTTP 403) avec `required_roles`	Vos rôles ne sont pas dans le groupe SOC de la route.	Demandez `security_officer` ou `tenant_admin` (ou `soc_analyst` pour les lectures, la vérification et la demande).
`invalid_request` (HTTP 400) avec `state`	Un État autre que `active` ou `all`.	Choisissez une valeur de la liste.
`kill_switch_not_active` (HTTP 409)	Ce kill switch n'est plus actif.	Actualisez le tableau.
`recovery_already_open` (HTTP 409)	Une demande de reprise est déjà ouverte pour ce kill switch.	Approuvez ou suivez la demande ouverte.
`recovery_not_pending` (HTTP 409)	La demande de reprise n'attend pas d'approbation.	Actualisez le tableau.
`separation_of_duties` (HTTP 409)	Le demandeur ne peut pas approuver sa propre demande.	Demandez à deux autres personnes.
`already_approved` (HTTP 409)	Vous avez déjà approuvé cette demande.	Demandez à un autre approbateur.
`recovery_not_approved` (HTTP 409)	La reprise exige deux approbateurs distincts avant la réautorisation.	Attendez la seconde approbation.
`reauthorization_by_approver` (HTTP 403)	Seul l'un des approbateurs peut réautoriser la cible.	Demandez à un approbateur de cliquer Réautoriser.
`reauthorization_denied` (HTTP 403)	Le point de décision des politiques a refusé la réautorisation de la cible.	Corrigez la politique ou la cible, puis réautorisez à nouveau.

Ce que montre l'écran​

Actions​

Rôles​

Tâches courantes​

Vérifier qu'un confinement tient​

Lever un kill switch après l'incident​

Dépannage​

Pages liées​