Proteggi le chiavi private nei server non presidiati

Iniziamo con i vincoli:

1. Hai bisogno di una sorta di segreto condiviso da inviare a un servizio per l'autenticazione, quindi devi essere in grado di accedere al testo in chiaro.
2. Questo deve essere fatto in modo automatico (non presidiato).
3. Vuoi proteggere le credenziali il più possibile.

Per prima cosa, dobbiamo riconoscere che è impossibile proteggerli completamente e potrebbe valere la pena o meno. Se qualcuno può eseguire codice sul tuo server, può fare quasi tutto ciò che può fare il servizio legittimo, inclusa la lettura delle chiavi e l'utilizzo dei tasti per effettuare richieste ai servizi remoti. Tuttavia, a seconda di quanto disagio sei disposto a soffrire, puoi renderli più difficili da usare.

In primo luogo, iniziamo con le "best practice" che hanno poco o nessun impatto sulla possibilità di utilizzarle.

1. Esegui ogni servizio sul tuo server come utente separato. Idealmente, aggiungi un sistema MAC come SELinux o AppArmor per contenere ulteriormente un compromesso.
2. Archivia chiavi / segreti in file che sono leggibili solo dal servizio appropriato e bloccano il più possibile le autorizzazioni. (0400 su Linux.)
3. Assicurarsi che le chiavi forniscano il minimo accesso necessario sul terminale remoto. Caricamento di file in un bucket S3? Crea un token di accesso con solo tale autorizzazione. (In questo modo, se compromesso, limita il danno che un attaccante può fare.)

Se devi andare oltre questo punto, puoi fare alcune cose:

1. Archivia i segreti in un modulo hardware. (In particolare se la crittografia asimmetrica è un'opzione.) Ciò non impedirà a un utente malintenzionato di utilizzare le tue credenziali, ma impedisce loro di esfiltrarle.
2. Utilizza un modulo hardware che richiede l'interazione umana. All'avvio del servizio, è necessario immettere un PIN, quindi il servizio mantiene la chiave decrittografata solo in memoria. (Naturalmente, un buon attaccante può probabilmente estrarre la chiave dalla memoria, ma alza la barra.)

Oltre questo punto, entriamo nella "sciocca per la maggior parte delle applicazioni": air gaping, token interattivi che richiedono PIN per ogni firma, ecc. La natura incustodita andrà rapidamente via.

Se il server è compromesso, non c'è modo di farlo in modo sicuro perché l'attaccante può fare quello che vuole, ad esempio intercettare la password. Osserva l'approccio delle chiavi pubbliche in gnupg: memorizzano il segreto cifrato su disco e decodificano utilizzando una chiave fornita dall'utente in memoria. Questo approccio funziona se è possibile avere l'interazione dell'utente. A mia conoscenza, se non c'è interazione umana è difficile proteggere questa chiave.