Cookbook: esercitazione kill switch

Eseguire un'esercitazione kill switch sicura su un estate non di produzione — attivare l'arresto a livello di estate.

Il kill switch e il gate di negazione a livello di estate. Attivarlo è deliberatamente economico — livello admin, nessun quorum — perché un arresto che attende il consenso non è un arresto. Riabilitare è deliberatamente costoso: doppio controllo, nessun break-glass. Non vuoi scoprire una lacuna in nessuna delle due direzioni alle 03:00.

Un’esercitazione su un tenant non di produzione e l’unico modo sicuro per provare che il gate di stop nega ogni punto di attuazione, che le approvazioni in sospeso vengono cancellate atomicamente e che la riabilitazione richiede effettivamente due umani distinti. Eseguila prima di averne bisogno.

Prerequisiti

Un tenant non di produzione. L’esercitazione attiva un vero arresto a livello di estate. Eseguila contro staging o dev, mai produzione.
Minimo tre utenti umani. (1) Un attivatore di livello admin; (2) due approvatori per la riabilitazione distinti (editor o superiore) che soddisfino il minimo di doppio controllo critical; (3) un post-revisore non coinvolto (editor o superiore) che chiuda la post-revisione obbligatoria. Il post-revisore può coincidere con un approvatore se non è l’attivatore.
Un elenco dei punti di attuazione governati da testare — deploy apply, orchestration fire, voice open, esecuzione modello, spesa budget, più qualsiasi superficie personalizzata che hai cablato.

Passo 1: Attivare il kill switch

L’attivatore attiva il kill switch con una stringa di motivazione obbligatoria:

# The API call — substitute your host, port and auth header.
curl -X POST https://<host>/v1/kill-switch/engage \
  -H "Authorization: Bearer <admin-token>" \
  -H "Content-Type: application/json" \
  -d '{"reason": "scheduled quarterly drill"}'

L’attivazione è deliberatamente economica: livello admin, una motivazione, nessun quorum di approvazione, nessuno step-up, nessun break-glass. La riga di stop diventa la singola fonte di verità. Ogni gate di attuazione governata la consulta dal vivo su ogni azione e fallisce chiuso su un errore di lettura.

Nella stessa transazione dell’attivazione, ogni approvazione di attuazione in sospeso nell’ambito viene cancellata — un intento pre-stop non può maturare in una concessione nel momento in cui l’estate torna attivo. Annota il timestamp; lo verificherai nel registro successivamente.

Passo 2: Verificare la negazione

Con il kill switch attivato, tenta ogni attuazione governata che il tuo estate ha cablato. Ciascuna deve restituire negato.

Punti di attuazione da testare:

Testa ogni punto che il tuo estate ha configurato. Se hai superfici di attuazione personalizzate cablate attraverso il nucleo di governance, includile.

Verifica anche cosa deve continuare a funzionare:

Lo stop ferma l’estate agentico, mai i controlli che lo governano. Le azioni di governance restano disponibili:

Leggere la mappa degli accessi — GET /v1/access-map dovrebbe restituire normalmente.
Visualizzare il registro di audit — GET /v1/audit/export dovrebbe restituire il registro, incluso l’evento di attivazione appena creato.
Elencare le approvazioni — la coda di approvazione è leggibile; le approvazioni precedentemente in sospeso dovrebbero risultare cancellate.

Se un punto di attuazione restituisce qualcosa di diverso da negato, o se un’azione di governance è bloccata, interrompi l’esercitazione e investiga. Il kill switch ha una lacuna.

Passo 3: Riabilitare l’estate

La riabilitazione non è mai unilaterale. Richiede una nuova approvazione a doppio controllo al livello critical: due umani distinti, ri-verificati strutturalmente al momento del cambio. Non esiste deliberatamente nessun percorso break-glass per la riabilitazione — “l’estate resta fermato” e lo stato sicuro.

L’attivatore (o qualsiasi admin) richiede la riabilitazione:

curl -X POST https://<host>/v1/kill-switch/re-enable \
  -H "Authorization: Bearer <admin-token>" \
  -H "Content-Type: application/json" \
  -d '{"reason": "drill complete, restoring estate"}'

Questo crea una richiesta di approvazione al livello critical. Due approvatori — ciascuno un umano distinto, nessuno con un token di sistema — devono ciascuno approvarla tramite POST /v1/approvals/<request-id>/decide con {"decision": "approve"}. Il minimo di doppio controllo viene applicato lato server: la guardia contro decisori duplicati impedisce a una persona di contare due volte, e un token di sistema viene rifiutato (nessuna garanzia umana). Anche se il livello della policy viene declassato, il minimo strutturale tiene — un’azione critical non può passare con un solo approvatore. Una volta che entrambe le approvazioni arrivano, l’estate viene riabilitato.

Passo 4: Verificare il ripristino

Ripeti ogni tentativo di attuazione del Passo 2. Ciascuno dovrebbe ora avere successo (permesso, o instradato nel normale flusso di approvazione). Se un punto resta negato dopo la riabilitazione, la riabilitazione non si e propagata completamente — investiga prima di firmare l’esercitazione.

Passo 5: Chiudere la post-revisione

Una post-revisione obbligatoria da parte di un umano non coinvolto e strutturalmente richiesta prima che un’altra attivazione del kill switch possa avvenire. Il revisore deve essere qualcuno che non era l’attivatore:

curl -X POST https://<host>/v1/kill-switch/post-review \
  -H "Authorization: Bearer <reviewer-token>" \
  -H "Content-Type: application/json" \
  -d '{"notes": "drill verified: all seams denied, re-enable required dual-control, restoration confirmed"}'

Finche questa revisione non è chiusa, una successiva attivazione del kill switch è bloccata. Questo è per progetto — non puoi accumulare attivazioni per evitare lo scrutinio.

Cosa verificare nel registro

Dopo l’esercitazione, esporta il registro di audit e verifica il trail completo:

olivares audit export --format json --since <drill-start-timestamp>

Il registro dovrebbe contenere, in ordine:

Evento di attivazione — l’admin, la motivazione (“scheduled quarterly drill”), il timestamp e il livello di garanzia della sessione di attivazione.
Cancellazioni delle approvazioni — ogni approvazione in sospeso nell’ambito che è stata cancellata nella stessa transazione dell’attivazione.
Eventi di negazione — uno per ogni tentativo di attuazione che è stato rifiutato durante lo stop.
Richiesta di riabilitazione — la richiesta di approvazione al livello critical.
Due decisioni di approvazione — una per approvatore, ciascuna che nomina l’identità umana distinta.
Evento di riabilitazione — l’estate ripristinato.
Evento di post-revisione — il revisore non coinvolto, le sue note, il timestamp di chiusura.

Ogni record porta i campi di integrità della catena (seq, prev_hash, hash, sig). Un record mancante o fuori ordine significa che il registro ha una lacuna — investiga prima di fidartene in un incidente reale.

Frequenza

Esegui l’esercitazione trimestralmente. Il kill switch e l’ultima linea di difesa; se ha una lacuna vuoi trovarla in una finestra programmata, non durante un incidente. Aggiungi l’esercitazione al tuo calendario operativo insieme ad altri esercizi di continuità (ripristino backup, failover, attivazione break-glass).

Se il tuo estate cambia materialmente — nuovi punti di attuazione cablati, nuovi tenant configurati, motore di policy sostituito — esegui un’esercitazione non programmata per coprire la nuova superficie.

Correlati

Governance — il modello di autorizzazione, i livelli di rischio e il design del kill switch.
Kill switch — il gate di negazione a livello di estate in termini di prodotto.
Governare e approvare — il flusso di approvazione dal vivo e la meccanica del doppio controllo.