Gli hacker che ottengono l’accesso al codice della tua applicazione possono essere devastanti per il software proprietario, ma l’archiviazione delle credenziali in Git può fornire loro un accesso elevato al database. Anche se non prevedi che il tuo repository Git venga violato, è una buona gestione del rischio ridurre al minimo i potenziali danni.
Accesso al controllo del codice sorgente come vettore di attacco Il software open source non è insicuro; dopotutto, gran parte del software utilizzato per eseguire Internet è sviluppato pubblicamente su GitHub. Sebbene il codice sia pubblico significa che gli hacker possono trovare gli exploit più facilmente, l’open source ha dimostrato che può essere ottimo per la trasparenza e la correzione dei bug della comunità.
Tuttavia, ciò non significa che il software closed source sia intrinsecamente più sicuro. Quando gli sviluppatori presumono che il controllo del codice sorgente sia privato, spesso adottano la soluzione più semplice quando gestiscono segreti come chiavi API o credenziali del database: codificandoli nell’applicazione anziché utilizzare una corretta gestione dei segreti.
Uno dei principali vettori di attacco per gli hacker è l’accesso al controllo del codice sorgente e la scansione dei progetti alla ricerca di chiavi API o altri segreti che non dovrebbero essere presenti. Ciò consente loro di elevare le proprie autorizzazioni e attaccare il resto della rete, ottenendo spesso l’accesso a dati o database sensibili dei clienti.
Di recente, l’elenco “No-Fly” della TSA è trapelato tramite questo metodo esatto. Un server di build Jenkins non sicuro è stato lasciato aperto al pubblico, un errore comune commesso durante l’impostazione di software che dovrebbe trovarsi in sottoreti private dietro il controllo degli accessi. Sul server Jenkins, l’hacker è stato in grado di accedere alla cronologia della build, che conteneva il codice, e ha trovato le credenziali AWS S3 per la compagnia aerea codificate nell’applicazione.
Non archiviare segreti nel controllo del codice sorgente Ogni applicazione avrà metodi diversi per archiviare in modo sicuro le chiavi API e le credenziali del database, ma esistono alcuni metodi comuni.
Il primo utilizza i file di configurazione, che possono essere distribuiti in produzione sul server e letti dall’applicazione in fase di esecuzione. Ad esempio, i progetti ASP.NET utilizzano per impostazione predefinita un file appsettings.json file vuoto mentre è archiviato nel controllo del codice sorgente. Spetta all’amministratore che distribuisce l’applicazione distribuire il file di configurazione di produzione.
È inoltre possibile utilizzare le variabili di ambiente, che vengono impostate dal sistema prima di eseguire un’applicazione. Questo è comunemente usato per i contenitori Docker, poiché è un modo semplice per inserire le credenziali in un contenitore già compilato. Ad esempio, Portainer offre la gestione delle variabili di ambiente come parte della sua interfaccia web Docker.
In genere, è una buona idea alternare regolarmente i segreti, poiché le credenziali obsolete rappresentano un rischio per la sicurezza. Uno degli strumenti in grado di gestire i segreti rotanti è Gestore dei segreti di AWSche funge da sistema di archiviazione in grado di fornire facilmente segreti alle tue applicazioni AWS.
Per le applicazioni al di fuori di AWS o qualsiasi applicazione che utilizza un servizio simile, c’è un piccolo problema in quanto avrai comunque bisogno di una chiave IAM per accedere a Secrets Manager, il che significa che dovrai gestire una chiave IAM, che è l’esatta problema con cui hai iniziato.
Tuttavia, il sistema IAM di AWS consente la gestione discreta di ruoli e autorizzazioni. Potresti, ad esempio, creare un utente per ogni server che hai e controllare a quali chiavi in Secrets Manager sono in grado di accedere. Puoi anche applicare le policy di sicurezza agli utenti IAM, richiedendo anche che vengano ruotate regolarmente.
IMPARENTATO: Non lasciare password nel tuo codice; Usa invece Secrets Manager di AWS
Non archiviare segreti negli script di compilazione Uno dei peggiori errori di sicurezza che gli sviluppatori possono commettere è l’archiviazione delle chiavi per le distribuzioni di produzione negli script di compilazione utilizzati in una pipeline CI/CD.
Ad esempio, potresti avere uno script di shell o un file YAML che viene utilizzato per controllare la creazione, il test e, soprattutto, la distribuzione della tua applicazione sui tuoi server o un servizio di archiviazione come Amazon S3. Tuttavia, se un utente malintenzionato dovesse ottenere l’accesso a questo script, sarebbe in grado di distribuire qualsiasi cosa sui tuoi server o bucket di archiviazione.
Uno dei modi più comuni per aggirare questo problema è utilizzare uno strumento di gestione dei segreti come GitHub Secrets, che memorizza le credenziali nel tuo repository a cui è possibile accedere per nome negli script di build di GitHub Actions.
Se la tua applicazione viene distribuita automaticamente utilizzando le azioni GitHub e necessita di credenziali per funzionare, puoi anche utilizzare i segreti per inserirli nel processo di compilazione in fase di esecuzione, creando i file di configurazione necessari o impostando le variabili di ambiente necessarie. In questo modo, il tuo repository potrebbe anche essere pubblico e creare comunque un’applicazione che viene inserita con le credenziali di produzione prima della distribuzione.
I segreti GitHub creati all’interno di un’organizzazione possono anche essere condivisi tra più repository, fornendo un modo semplice per gestire centralmente le chiavi sicure. Anche altri strumenti di build server come Jenkins o TeamCity avranno una gestione dei segreti integrata.
