AGOV nel Business Continuity Management: autenticazione in caso di crisi
Una soluzione di autenticazione ad alta disponibilità è importante. Per i compiti statali particolarmente critici, tuttavia, l’alta disponibilità da sola non basta. Vedere anche il video «Degradazione di AGOV per requisiti al di fuori della situazione normale».
Se un’applicazione specialistica deve continuare a funzionare anche durante una crisi grave, non basta chiarire quanto sia affidabile la sua autenticazione. Occorre anche definire che cosa succede quando:
- vengono meno singole infrastrutture di comunicazione;
- AGOV stesso non è più disponibile;
- anche il sistema di destinazione non può più essere gestito.
Con AGOV è quindi possibile costruire un modello di resilienza a più livelli.
Il principio di base è semplice:
AGOV deve poter fornire ai sistemi di destinazione critici un’autenticazione sicura il più a lungo possibile anche in condizioni avverse. Allo stesso tempo, i sistemi particolarmente critici non devono dipendere dal fatto che AGOV sia sempre disponibile.
In questo modo AGOV non diventa un single point of failure, bensì una componente di un’architettura più ampia di IT Service Continuity Management e Business Continuity Management.
Prima di tutto occorre stabilire che cosa è realmente critico
Non tutte le applicazioni necessitano di un’architettura di questo tipo.
Il punto di partenza è quindi l’analisi del fabbisogno di protezione e della criticità del sistema di destinazione. Per ogni servizio occorre chiarire:
- per quanto tempo sia possibile farne a meno;
- quali conseguenze avrebbe un’interruzione prolungata;
- quali dipendenze debbano continuare a funzionare anche in una situazione di crisi.
Ne derivano requisiti differenti.
Per molte applicazioni specialistiche è sufficiente che AGOV stesso sia gestito in alta disponibilità. Per alcuni sistemi particolarmente critici, invece, occorre partire dal presupposto che anche componenti centrali dell’infrastruttura possano venire meno.
Solo per questi sistemi è necessaria l’architettura a più livelli descritta di seguito.
Modello di resilienza a più livelli
Livello 1: mantenere AGOV disponibile il più a lungo possibile
La prima linea di difesa è la resilienza di AGOV stesso.
Un’infrastruttura centrale di autenticazione non deve dipendere da un solo centro di calcolo o da un solo dominio infrastrutturale.
L’architettura obiettivo prevede pertanto un funzionamento active-active separato sia geograficamente sia dal punto di vista infrastrutturale, nel quale una parte dell’infrastruttura AGOV può essere gestita al di fuori dell’infrastruttura ordinaria dell’Amministrazione federale.
Il guasto di un dominio infrastrutturale non deve quindi comportare automaticamente il guasto dell’autenticazione.
Questo approccio protegge dai classici guasti tecnici, ma ha anche una dimensione di politica di sicurezza: in una situazione straordinaria, le infrastrutture centrali della Confederazione possono esse stesse diventare obiettivo di cyberattacchi.
Resilienza significa quindi non solo ridondanza nello stesso ambiente, ma anche, per quanto possibile, evitare cause di guasto comuni.
Livello 2: l’autenticazione non deve dipendere dal telefono cellulare
Nel funzionamento normale AGOV viene spesso utilizzato con un dispositivo mobile personale. Per le funzioni particolarmente critiche, tuttavia, questo non dovrebbe essere l’unico percorso di autenticazione disponibile.
Le persone previste a tale scopo registrano quindi nel proprio account AGOV anche una chiave di sicurezza FIDO fisica.
L’accesso rimane così possibile, ad esempio, quando:
- a telefonia mobile è compromessa;
- il dispositivo mobile personale non può più essere utilizzato;
- il percorso di autenticazione mobile non è disponibile per altri motivi.
Non è però sufficiente la registrazione tecnica.
La chiave di sicurezza deve essere effettivamente:
- disponibile;
- reperibile;
- funzionante.
Un controllo organizzativo è quindi parte integrante di un simile concetto.
Durante esercitazioni periodiche, le persone interessate accedono con la propria chiave di sicurezza. Una chiave registrata anni prima ma oggi irreperibile o difettosa non ha alcun valore ai fini del BCM.
Livello 3: il sistema di destinazione deve poter autenticare anche senza AGOV
Qui si trova il passaggio architetturale decisivo.
Per i sistemi di destinazione particolarmente critici non basta che AGOV sia altamente disponibile. Il sistema di destinazione deve disporre anche di un proprio livello di autenticazione indipendente da AGOV.
Una possibilità consiste nel supportare FIDO direttamente nel sistema di destinazione.
Funzionamento normale
Nel funzionamento normale l’autenticazione continua ad avvenire tramite AGOV.
Parallelamente, la chiave di sicurezza FIDO registrata per la persona interessata viene memorizzata anche nel livello FIDO del sistema di destinazione.
In questo modo anche il sistema di destinazione conosce l’associazione tra persona e chiave di sicurezza.
Funzionamento in caso di indisponibilità di AGOV
Se AGOV non è disponibile, la stessa persona può utilizzare direttamente la stessa chiave fisica nei confronti del sistema di destinazione.
Il principio centrale è il seguente:
Nel funzionamento normale AGOV predispone già le condizioni per un funzionamento senza AGOV.
L’infrastruttura centrale d’identità non crea quindi soltanto una dipendenza, ma contribuisce attivamente a rendere gestibile la propria indisponibilità.
Livello 4: il fallback deve essere realmente utilizzato con regolarità
Un livello di ripiego tecnicamente disponibile non è ancora un livello di ripiego operativo.
L’accesso diretto al sistema di destinazione deve pertanto essere testato periodicamente nella pratica.
Allo stesso tempo devono essere ricertificati regolarmente:
- le persone autorizzate;
- le autorizzazioni;
- le chiavi di sicurezza registrate.
Un livello di ripiego che non è mai stato testato non è un livello di ripiego.
Un test BCM non dovrebbe quindi limitarsi a verificare se un server è raggiungibile. Dovrebbe coprire l’intero processo:
- persona;
- chiave di sicurezza fisica;
- dispositivo disponibile;
- connessione di rete;
- autenticazione diretta;
- accesso alla funzione specialistica effettivamente necessaria.
Solo quando l’intera catena funziona il fallback è affidabile.
Livello 5: anche Internet pubblico può venire meno
L’indipendenza da AGOV da sola non basta.
Se il sistema di destinazione può autenticare direttamente con FIDO, ma è raggiungibile esclusivamente tramite Internet pubblico, rimane una dipendenza centrale.
Per i sistemi corrispondentemente critici possono quindi essere necessarie connessioni di rete dedicate o particolarmente resilienti.
L’obiettivo è ridurre, in caso di crisi, la catena tecnica al minor numero possibile di componenti:
utente finale → chiave di sicurezza FIDO → dispositivo → rete specializzata → sistema di destinazione
Meno componenti sono necessari, meno componenti possono guastarsi.
Anche l’alimentazione elettrica fa parte del BCM
Anche l’alimentazione elettrica deve essere considerata.
Un centro di calcolo ridondante più volte serve a poco se nel luogo operativo previsto non possono essere alimentati né il dispositivo finale né l’infrastruttura di comunicazione.
Il BCM non termina quindi al confine del centro di calcolo.
Livello 6: per una crisi grave servono identità di emergenza preparate
Un ulteriore livello di ripiego va ancora oltre.
Nel livello FIDO diretto di un sistema di destinazione particolarmente critico può essere preregistrato un numero limitato di chiavi di sicurezza fisiche senza associarle in modo permanente a una persona specifica.
Queste chiavi vengono conservate in modo decentralizzato, controllato e sicuro.
Se in caso di crisi una persona autorizzata non può più operare con la propria identità elettronica regolare, una chiave preparata può esserle consegnata secondo un processo d’emergenza definito.
L’associazione tra la persona effettiva e l’identità tecnica di emergenza avviene allora al di fuori del sistema, ad esempio tramite documentazione cartacea.
Requisiti per le identità di emergenza
Un simile meccanismo non deve naturalmente trasformarsi in una chiave universale improvvisata.
Sono necessari in particolare:
- un ambito di applicazione definito con precisione;
- un gruppo di persone autorizzate chiaramente definito;
- una custodia sicura e, se possibile, distribuita geograficamente;
- un inventario delle chiavi di sicurezza;
- procedure regolamentate di consegna e restituzione;
- ove possibile, il principio dei quattro occhi;
- una documentazione tracciabile di ogni associazione;
- test regolari;
- un processo vincolante per la successiva normalizzazione.
Dopo il ripristino del funzionamento normale, le associazioni temporanee vengono ricostruite sulla base della documentazione e corrette nel sistema di destinazione.
La procedura è volutamente analogica.
Proprio questo è il suo scopo: deve funzionare anche quando le normali dipendenze digitali non sono più disponibili.
Livello 7: a un certo punto deve essere possibile rinunciare anche al sistema di destinazione
L’IT Service Continuity Management risponde alla domanda di come un servizio IT possa continuare a funzionare o essere ripristinato nonostante gravi perturbazioni.
Il Business Continuity Management deve andare oltre.
Deve esistere anche uno scenario nel quale non solo AGOV, ma anche il sistema di destinazione vero e proprio non è più disponibile.
A quel punto la soluzione non può essere un ulteriore metodo di autenticazione. I processi specialistici devono poter passare ad altri mezzi.
L’ultimo livello di ripiego può comprendere, ad esempio:
- mezzi di comunicazione autonomi;
- alimentazione elettrica indipendente;
- informazioni disponibili fisicamente;
- processi cartacei;
- competenze e poteri decisionali definiti in anticipo.
In ultima analisi, lo Stato deve poter rimanere operativo anche senza:
- AGOV;
- i sistemi di destinazione interessati;
- Internet;
- la telefonia mobile;
- la normale alimentazione elettrica.
Quattro stati operativi invece di un’unica soluzione d’emergenza
Per l’attuazione pratica, il modello può essere ricondotto a quattro stati operativi chiaramente distinti.
1. Funzionamento normale
La persona si autentica regolarmente tramite AGOV.
AGOV assume l’autenticazione centrale e fornisce al sistema di destinazione:
- l’identità necessaria;
- le informazioni richieste.
2. Funzionamento degradato
Parti dell’infrastruttura – ad esempio la telefonia mobile – non sono disponibili.
Le persone particolarmente importanti possono continuare a utilizzare AGOV mediante la propria chiave di sicurezza FIDO fisica.
3. Funzionamento senza AGOV
AGOV stesso non è disponibile.
Il sistema di destinazione particolarmente critico viene raggiunto tramite una connessione di rete alternativa e autentica direttamente le chiavi di sicurezza FIDO preregistrate.
Per casi straordinari possono essere impiegate identità di emergenza preparate secondo una procedura rigorosamente regolamentata.
4. Funzionamento senza sistema di destinazione
Anche il sistema specialistico non è più disponibile.
Subentra il processo BCM definito in precedenza.
L’organizzazione continua a operare con i mezzi:
- tecnici;
- organizzativi;
- analogici
preparati specificamente per questo caso.
Questa distinzione evita che per ogni perturbazione venga attivata immediatamente la modalità d’emergenza più radicale.
La vera forza risiede nel disaccoppiamento
L’idea decisiva di questo modello non è un singolo prodotto tecnico.
È il disaccoppiamento controllato delle dipendenze.
Nel funzionamento normale, una soluzione centrale come AGOV offre grandi vantaggi:
- verifica centralizzata dell’identità;
- autenticazione forte;
- processi uniformi;
- un’infrastruttura di fiducia comune.
Queste funzioni non devono quindi essere ricostruite da ogni applicazione specialistica.
Per pochi sistemi particolarmente critici, tuttavia, questa centralizzazione viene completata da livelli di ripiego mirati.
Non nasce così un secondo IAM parallelo per il funzionamento quotidiano.
Il livello FIDO aggiuntivo rimane una funzione d’emergenza volutamente limitata. Identità, chiavi di sicurezza e autorizzazioni vengono predisposte e verificate regolarmente nel funzionamento normale, ma utilizzate direttamente solo nel caso di perturbazione definito.
Questo evita due errori opposti:
- ogni sistema specialistico non torna a diventare un sistema IAM completo autonomo;
- non si presume nemmeno che una piattaforma centrale di autenticazione possa essere garantita disponibile in ogni circostanza immaginabile.
La resilienza deve essere ancorata nell’organizzazione
La tecnica da sola non basta.
Per ogni sistema di destinazione particolarmente critico devono quindi essere definiti almeno:
- le responsabilità;
- i criteri di attivazione;
- gli intervalli delle esercitazioni;
- la ricertificazione;
- la gestione delle chiavi;
- i canali di comunicazione;
- il ritorno al funzionamento normale.
Quest’ultimo punto viene spesso sottovalutato.
Dopo una crisi devono poter essere ricondotti in modo controllato allo stato regolare:
- e identità temporanee;
- le autorizzazioni particolari;
- le associazioni manuali.
Il BCM necessita quindi non solo di un percorso verso il funzionamento d’emergenza, ma anche di un percorso controllato per uscirne.
Conclusione
AGOV può svolgere un ruolo centrale nella resilienza dei servizi statali critici. L’approccio corretto non consiste tuttavia nel considerare AGOV indistruttibile.
Il modello più robusto accetta fin dall’inizio che ogni componente tecnico possa guastarsi.
Pertanto:
- AGOV viene costruito con alta disponibilità e ridondanza infrastrutturale;
- le persone particolarmente importanti dispongono di un fattore FIDO indipendente dal telefono cellulare;
- determinati sistemi di destinazione critici possono, se necessario, autenticare direttamente le stesse chiavi di sicurezza;
- le dipendenze di rete e di alimentazione vengono ridotte;
- per le crisi gravi sono previste identità di emergenza preparate e processi manuali documentati;
- un ultimo livello BCM funziona anche senza il sistema di destinazione digitale.
Intesa in questo modo, la resilienza non è un’unica soluzione sostitutiva.
È una catena di livelli di degradazione preparati consapevolmente, nella quale ogni livello richiede meno infrastruttura del precedente.
Ed è proprio per questo che AGOV può essere contemporaneamente un’infrastruttura centrale di autenticazione e parte di un’architettura preparata a continuare a funzionare, se necessario, anche senza AGOV.