Gli hacker che ottengono l'accesso al codice della tua applicazione possono essere devastanti per 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.
Fonte Controllare l'accesso come vettore di attacco
Il software open source non è insicuro; dopotutto, gran parte del software utilizzato per eseguire Internet è sviluppato pubblicamente su GitHub. Mentre il codice pubblico significa che gli hacker possono trovare più facilmente gli exploit, l'open source ha dimostrato che può essere ottimo per la trasparenza e la correzione dei bug della community.
Tuttavia, questo 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 le chiavi API o le credenziali del database: codificandoli nell'applicazione anziché utilizzare un'adeguata gestione dei segreti.
Uno dei problemi i principali vettori di attacco per gli hacker sono l'accesso al controllo del codice sorgente e la scansione di progetti per 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.
Recentemente, la TSA “No-Fly” list è 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 i 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 che è vuoto mentre è archiviato nel controllo del codice sorgente. Spetta all'amministratore che distribuisce l'applicazione distribuire il file di configurazione di produzione.
Puoi anche utilizzare le variabili di ambiente, che vengono impostate dal sistema prima di eseguire un'applicazione. Questo è comunemente usato per i container Docker, poiché è un modo semplice per inserire le credenziali in un container già creato. Ad esempio, Portainer offre la gestione delle variabili di ambiente come parte della sua interfaccia web Docker.
In genere, è una buona idea ruotare regolarmente i segreti, poiché le credenziali obsolete rappresentano un rischio per la sicurezza. Uno degli strumenti in grado di gestire i segreti a rotazione è Secrets Manager di AWS, che 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 ancora bisogno di una chiave IAM per accedere a Secrets Manager, il che significa che dovrai gestire un Chiave IAM, che è esattamente il 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 possiedi e controllare a quali chiavi in Secrets Manager sono in grado di accedere. Puoi anche applicare policy di sicurezza agli utenti IAM, richiedendo anche che vengano ruotati regolarmente.
RELAZIONATO: Non lasciare password nel tuo codice; Usa invece Secrets Manager di AWS
Non archiviare segreti negli script di compilazione
Uno dei peggiori sistemi di sicurezza gli errori che gli sviluppatori possono commettere è archiviare le 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 continuare a creare un'applicazione che viene inserita con le credenziali di produzione prima della distribuzione.
I GitHub Secret creati all'interno di un'organizzazione possono anche essere condivisi tra più repository, fornendo un modo semplice per accedere centralmente gestire chiavi sicure. Anche altri strumenti di build server come Jenkins o TeamCity avranno la gestione dei segreti integrata.
LEGGI SUCCESSIVO
- › Intel rinuncia ai suoi Tiny PC NUC
- › I 4 migliori gestori di password gratuiti
- › Le migliori offerte Prime Day di Apple, Samsung e altri
- › Risparmia il 45% sulla gamma di aspirapolvere di Roborock con i saldi Prime Day
- › Mozilla Thunderbird 115 arriva oggi e sembra fantastico
- › Oggi sono in vendita oltre 100 fantastiche app indipendenti