Dove devono stare le credenziali del pannello

Ogni pannello di controllo ospitato per l’automazione dei server chiede la stessa cosa nella sua procedura guidata: l’indirizzo del suo hypervisor, un token API, le credenziali di root del suo pannello di web hosting. Poi le conserva, perché gli servono a ogni richiesta.

È una cosa ragionevole da parte del software e una cosa davvero scomoda da aver accettato. Ha appena consegnato al database di una terza parte la facoltà di eliminare ogni macchina che possiede. Non a causa di un bug e non per malizia: è il comportamento normale, documentato e funzionante del prodotto.

Vale la pena essere precisi su che cosa le alternative diano davvero, perché «le cifriamo a riposo» è la risposta che danno tutti ed è quasi priva di significato da sola.

Cifrate a riposo, decifrate da chi

Se un SaaS conserva cifrato il token del suo hypervisor, la chiave deve stare in un posto che quello stesso SaaS può raggiungere, perché deve usare il token per suo conto mentre lei dorme. La cifratura a riposo protegge da un disco rubato e da un backup trapelato. Non protegge dalla cosa di cui si preoccupa davvero, cioè la compromissione della piattaforma stessa.

Non è un argomento contro la cifratura a riposo. È un argomento per dire che la domanda «dove sta la chiave» è l’unica domanda, e che un piano di controllo in grado di decifrare è un piano di controllo che si può costringere a decifrare.

L’alternativa strutturale è la terza riga: non avere affatto il segreto. Il che suona sbrigativo, finché non si guarda quanto costa organizzarlo.

Tenere il segreto dove sta la macchina

La forma che funziona: un piccolo agente gira dentro la rete del cliente, conserva le credenziali in locale e si connette verso l’esterno alla piattaforma. La piattaforma invia istruzioni. L’agente detiene le chiavi.

Questo capovolge il raggio d’azione di una violazione. La compromissione del piano di controllo può ora impartire comandi, il che è grave e su cui torneremo, ma non può portarsi via un file pieno di token di hypervisor di ogni cliente, perché quel file non esiste.

Le parti che lo rendono reale non hanno nulla di appariscente.

Il vault, e da che cosa protegge onestamente

Il nostro agente conserva le credenziali in un file locale cifrato con XChaCha20-Poly1305. La chiave non è il file su disco: è derivata con HKDF da un file di chiave mescolato con l’identità della macchina stessa, e i dati autenticati aggiuntivi legano il testo cifrato alla versione del formato e all’ID dell’agente.

La conseguenza pratica è quella su cui vale la pena progettare. Copi il file di chiave e il vault su un’altra macchina e non si aprirà. Ripristini il backup del mese scorso della directory dei dati su un host diverso e non si aprirà. Ogni modo di fallire, chiave sbagliata, agente diverso, byte alterati, produce lo stesso errore indistinguibile, ed è proprio questo il punto.

Ecco la parte che dovrebbe stare nella documentazione di ogni prodotto che fa così, e di solito non c’è. Questo non protegge da root sull’host. Non può farlo e non ne ha bisogno: il cliente possiede l’host e possiede le credenziali. Il vault protegge da un file trapelato, non dal proprietario della macchina. Un fornitore che lascia intendere il contrario le sta vendendo una sensazione.

Le credenziali non toccano mai il database della piattaforma

Questa è la parte facile da sbagliare mentre si crede di averla azzeccata, perché il codice sembra a posto in entrambi i casi.

Quando qualcuno digita un token di hypervisor nel nostro pannello, la riga che finisce nella tabella dei comandi contiene soltanto i nomi dei campi. I valori viaggiano in un messaggio transitorio separato che non viene conservato e finiscono direttamente nella consegna all’agente. Il dispatcher non li registra mai nei log e non li rende mai persistenti.

Se sta valutando un prodotto su questo punto, la domanda da porre non è «conservate le credenziali». È «che cosa c’è nel vostro registro di audit e che cosa c’è nella vostra coda». Una coda che trasporta il segreto è un database che trasporta il segreto con qualche passaggio in più.

Eliminare un segreto è un problema diverso dal conservarlo

Rimuovere un’integrazione nel pannello deve avere come esito la sparizione delle credenziali da una macchina che lei non controlla, il che è un problema più difficile di quanto sembri.

L’implementazione ovvia è una riconciliazione: chiedere all’agente che cosa ha, confrontarlo con ciò che il database dice che dovrebbe avere, eliminare la differenza. È più breve ed è pericolosa, perché la sottrazione fallisce nella direzione di è sparito tutto. Una lettura fallita, un elenco troncato, e ha generato l’istruzione di cancellare ogni integrazione funzionante su quell’host; e quelle credenziali non sono recuperabili senza che il cliente le ridigiti.

Perciò l’istruzione nasce soltanto da conoscenza positiva: una riga esiste perché qualcuno ha davvero eliminato un’integrazione. Una lettura fallita produce zero righe e quindi zero istruzioni, e il segreto resta dov’era, che è esattamente lo stato in cui si trovava prima.

Viene consegnata due volte: subito attraverso il bus degli eventi, e di nuovo a ogni handshake di sessione, per l’agente che era offline, per il messaggio andato perduto, per il gateway che si è riavviato. Entrambi i percorsi leggono la stessa tabella, quindi non c’è una seconda verità né un secondo ordinamento.

Che cosa può e non può fare un certificato di agente rubato

Se l’agente si autentica con un certificato client, la domanda onesta è che cosa succede quando qualcuno se ne impossessa. Essere precisi su questo è più utile di una pagina sulla sicurezza.

Può impersonare quel singolo agente. La porta di sessione richiede il TLS mutuo e, oltre al controllo TLS, l’impronta del certificato del peer viene cercata nella tabella degli agenti, che ha un indice unico. Un’impronta punta quindi a esattamente un agente, e l’identità dichiarata nell’handshake viene confrontata con essa. Un attaccante con il certificato diventa quell’agente e può inviare tutto ciò che un agente può inviare: eventi di stato, risultati, telemetria.

Non può leggere i dati di altri clienti. Tutto è delimitato dall’organizzazione a cui l’agente appartiene, ricavata dal certificato e non da ciò che il client dice di sé.

Non consegna di per sé le credenziali. Il certificato è l’identità usata per parlare con la piattaforma. La chiave del vault è separata, vive sull’host ed è legata all’identità macchina di quell’host. Chi ha entrambe le cose ha root sulla macchina, e a quel punto il certificato è il problema minore.

Smette di funzionare quando lo decide lei, in circa un minuto. La revoca è uno stato del database, non una CRL e non OCSP. Una nuova connessione viene rifiutata subito. Una connessione esistente viene ricontrollata a intervalli di un minuto, quindi un attaccante già connesso ha al massimo quel tempo. Se il controllo di stato continua a fallire, la sessione viene chiusa dopo tre fallimenti consecutivi anziché restare aperta a tempo indeterminato, il che limita il caso peggiore a circa tre minuti.

E l’agente fa pulizia da solo. Alla revoca cancella il vault, la chiave del vault, la propria identità, lo stato di sessione e le code, in quest’ordine, le credenziali per prime. Ogni passo viene tentato senza garanzie e registrato singolarmente, perché mezza cancellazione è meglio di nessuna cancellazione.

I certificati hanno anche vita breve, novanta giorni, con rinnovo automatico a metà strada e un controllo ogni ora. Più che una difesa dal furto, è un limite a quanto a lungo resta utile un furto che nessuno ha notato.

Che cosa questo non risolve

Tre cose, dette con chiarezza, perché un modello di minaccia senza rischio residuo è una pagina di marketing.

Un piano di controllo compromesso può comunque impartire comandi. Non può rubarle i token, ma può dire al suo agente di eliminare una macchina, e l’agente lo farà. Spostare i segreti sposta il raggio d’azione del danno; non lo elimina. Ciò che ottiene in cambio è che il danno è limitato da ciò che l’API sa esprimere ed è visibile in una traccia di audit, invece di essere un attaccante con le sue credenziali che alle tre di notte fa quel che vuole direttamente sul suo hypervisor.

Root sull’host dell’agente legge tutto. Per costruzione. Se quell’host è compromesso ha una macchina compromessa dentro la sua stessa rete, e quella macchina ha le credenziali del suo hypervisor perché è lì che devono stare.

L’eliminazione dipende dal ritorno dell’agente. Se un host non si riconnette mai, l’istruzione di dimenticare le sue credenziali resta aperta. Questo è visibile nel pannello invece di essere contrassegnato come fatto in silenzio, il che è il compromesso corretto, ma è un limite reale ed è bene conoscerlo prima di farci affidamento.

Domande che vale la pena porre a un fornitore

Qualunque cosa finisca per acquistare, queste cinque separano i prodotti che ci hanno pensato da quelli che hanno scritto un paragrafo:

1. 01Dove sta fisicamente la chiave di decifratura? Se la risposta è «nella nostra piattaforma», la cifratura a riposo protegge dal furto di un disco e da nient’altro.
2. 02Che cosa c’è nel registro di audit e nella coda dei lavori? I segreti finiscono in entrambi assai più spesso che nella tabella su cui qualcuno è stato attento.
3. 03Che cosa succede alle credenziali quando elimino un’integrazione, e posso vedere se è successo davvero?
4. 04Quanto tempo richiede la revoca dell’accesso, e vale anche per le sessioni già aperte?
5. 05Serve una porta in entrata a qualcosa? Una regola di firewall che lascia entrare l’intervallo di indirizzi di un fornitore nell’interfaccia di gestione del suo hypervisor è una seconda versione, più silenziosa, dello stesso problema.

È così che l’abbiamo costruito in Provibr: l’agente gira sull’hardware del cliente, conserva le credenziali in locale e si connette solo verso l’esterno.