Un piano pratico di gestione dei segreti per applicazioni self-hosted

Perché la gestione dei segreti è un requisito operativo, non solo di sicurezza

Un'applicazione self-hosted raramente funziona con una sola credenziale. Può richiedere un account di database, una password SMTP, token API di terze parti, webhook, materiale di firma e una o più chiavi di crittografia. Se questi valori non sono gestiti, il lavoro ordinario diventa rischioso: un deployment è più difficile da riprodurre, la partenza di un membro del personale lascia accessi poco chiari e una sospetta esposizione può trasformarsi in un'interruzione urgente.

Un processo utile di gestione dei segreti rende prevedibile il lavoro autorizzato. Il team sa a cosa serve ciascun segreto, chi ne è responsabile, dove viene fornito, quale applicazione ne dipende e come può essere sostituito. Ciò è coerente con l'enfasi del NIST CSF 2.0 sulla definizione, comunicazione e applicazione di ruoli, responsabilità e autorità in materia di cybersicurezza.

L'infrastruttura gestita può ridurre il carico operativo attorno a un'applicazione, ma non risolve la governance delle credenziali. Ad esempio, Airbip distribuisce le applicazioni del catalogo come carichi di lavoro Docker sui propri server cloud e automatizza il routing e i certificati TLS tramite Traefik e Let's Encrypt. I clienti devono comunque decidere chi può creare, approvare, visualizzare e ruotare le credenziali dell'applicazione che connettono tali carichi di lavoro a database e servizi esterni.

• Tratta ogni segreto di produzione come una dipendenza operativa con un responsabile.
• Progetta le procedure di sostituzione prima che un segreto sia sospettato o noto come esposto con urgenza.
• Quando pratico, mantieni separate le responsabilità di amministrazione dell'infrastruttura e l'approvazione aziendale degli account sensibili di terze parti.

Cosa rientra nella definizione di segreto

Un segreto è un'informazione la cui divulgazione potrebbe consentire accesso non autorizzato, impersonificazione, decrittazione o azioni privilegiate. Una chiave segreta, ad esempio, è una chiave crittografica che non è pubblica; la sua riservatezza è fondamentale per il suo scopo.

Non limitare il registro ai valori chiamati letteralmente PASSWORD. Una stringa di connessione può contenere un nome utente e una password. Un'esportazione della configurazione può contenere un token di integrazione. Una chiave privata, un valore di firma dei cookie, un segreto client OAuth o un codice di recupero possono avere conseguenze maggiori di una password convenzionale.

Al contrario, la configurazione ordinaria di solito non concede accesso se viene divulgata. Gli esempi possono includere l'URL pubblico dell'applicazione, un'impostazione di funzionalità non sensibile, una lingua o una scelta relativa al livello di log. La classificazione deve basarsi su ciò che la divulgazione consente di fare, anziché sul nome di una variabile d'ambiente.

• Nomi utente e password di database, incluse le credenziali incorporate nelle stringhe di connessione.
• Token API, segreti webhook e segreti client OAuth usati dalle integrazioni.
• Nomi utente e password SMTP usati per inviare email dall'applicazione.
• Valori di firma delle sessioni, chiavi private e altre chiavi di firma.
• Chiavi di crittografia, materiale di cifratura delle chiavi e codici di recupero.
• Password di amministratore e token di accesso per account dell'applicazione, del server o di servizi di terze parti.

Separa i segreti dalla configurazione non sensibile prima del deployment

Prima del deployment, crea due elenchi: la configurazione che può essere conservata nella documentazione di deployment ordinaria e i valori che richiedono una gestione con accesso limitato. Questo piccolo passaggio evita una modalità di errore comune, in cui un comodo file .env diventa la fonte informale di verità per tutto, comprese le credenziali di produzione.

Per i deployment basati su Docker, usa un metodo di distribuzione dei segreti separato quando l'applicazione lo supporta. Docker consiglia di utilizzare i segreti anziché le variabili d'ambiente per valori sensibili nei deployment Compose. I segreti Compose sono dichiarati al livello superiore e poi concessi esplicitamente ai singoli servizi; un servizio non può accedere a un segreto dichiarato se la sua definizione non include tale concessione.

I segreti Docker vengono montati come file anziché impostati direttamente come variabili d'ambiente, normalmente in /run/secrets. Questo approccio può restringere quali servizi ricevono un valore. Non elimina la necessità di proteggere l'host, la configurazione di deployment o le persone con accesso amministrativo, e l'applicazione deve essere in grado di leggere il segreto nel formato fornito.

Evita di inserire credenziali di build negli argomenti di build Docker o nelle variabili d'ambiente. Docker afferma che questi elementi possono persistere nell'immagine finale. Usa mount di segreti di build o mount SSH per le credenziali necessarie solo durante la build. Escludi inoltre i file .env dal contesto di build con .dockerignore quando potrebbero contenere segreti; altrimenti possono essere inclusi in un layer dell'immagine.

• Classifica ciascun valore di deployment prima di aggiungerlo a un file Compose, a un job CI o a un pannello di amministrazione.
• Concedi un segreto Docker Compose solo al servizio che ne ha bisogno.
• Consulta la documentazione di configurazione dell'applicazione per stabilire se accetta un segreto da file, variabile d'ambiente o altro meccanismo.
• Esamina Dockerfile, contesti di build e cronologia delle immagini quando sono mai state usate credenziali in fase di build.

Mappa ogni luogo in cui un segreto può essere esposto

Un segreto è protetto solo quanto ciascuna delle sue copie. Il file di deployment è solo uno dei luoghi da ispezionare. Artefatti di build, il laptop di uno sviluppatore, una richiesta di assistenza archiviata o una configurazione esportata possono diventare silenziosamente copie aggiuntive che sopravvivono alla credenziale prevista.

Crea una mappa dell'esposizione per ogni segreto di alto valore. Registra sia le posizioni intenzionali, come un archivio di segreti con accesso limitato, sia le possibili posizioni accidentali, come cronologia della shell, screenshot o rapporti di errore. La mappa è particolarmente utile durante la risposta agli incidenti perché indica al team cosa deve essere esaminato dopo una rotazione.

I log meritano attenzione esplicita. OWASP ASVS osserva che credenziali e dettagli di pagamento possono essere vietati nei log, mentre i token di sessione potrebbero richiedere hashing o mascheramento. Richiede inoltre un inventario dei file e dei servizi in cui i log sono archiviati o trasmessi. Tratta le destinazioni dei log, i sistemi di tracciamento degli errori e i canali di assistenza come parte del perimetro dei segreti.

• Repository del codice sorgente, inclusi file .env sottoposti a commit, esempi e commit storici.
• File Compose, variabili CI/CD, cronologia della shell e output della riga di comando.
• Log dei container, log del reverse proxy, rapporti di errore dell'applicazione e servizi di log esterni.
• Ticket di assistenza, messaggi in chat, email, screenshot e output del terminale copiato.
• Backup, dump di database, esportazioni di configurazione e vecchie snapshot dei server.
• Computer degli amministratori, vault dei password manager, sessioni del browser e supporti rimovibili.

Scegli un modello di responsabilità prima di concedere l'accesso

I piccoli team spesso concentrano la responsabilità in un unico account amministratore. Può essere una soluzione rapida, ma rende difficili l'approvazione, il recupero e l'offboarding. Assegna invece ruoli nominativi per ogni segreto rilevante, anche quando una persona ricopre temporaneamente più di un ruolo.

Un modello pratico separa il responsabile dell'applicazione, l'amministratore dell'infrastruttura e il responsabile del servizio di terze parti. Il responsabile dell'applicazione decide se un'integrazione è necessaria e ne accetta il rischio aziendale. L'amministratore dell'infrastruttura fornisce la configurazione approvata al servizio in esecuzione e mantiene l'accesso al deployment. Il responsabile del servizio di terze parti amministra l'account esterno che ha emesso la credenziale, come un provider email o una piattaforma API.

Le linee guida NIST supportano la definizione di ruoli e la limitazione degli account privilegiati a personale o ruoli definiti. Dove possibile, gli amministratori dovrebbero usare account non privilegiati per il lavoro ordinario e riservare l'accesso privilegiato alle attività che lo richiedono.

• Responsabile dell'applicazione: approva finalità, uso dei dati e necessità aziendale.
• Amministratore dell'infrastruttura: distribuisce i valori approvati e controlla l'accesso a livello di piattaforma.
• Responsabile del servizio di terze parti: gestisce l'account del fornitore esterno, il rapporto di fatturazione e l'emissione delle credenziali.
• Revisore di sicurezza o operativo: conferma periodicamente accessi, scadenze, stato della rotazione e prontezza al recupero.

Archivia e fornisci i segreti in modo sicuro

Scegli il processo più leggero che limiti in modo affidabile la divulgazione e supporti il recupero. L'opzione migliore dipende dalle dimensioni del team, dal numero di applicazioni, dal turnover, dai requisiti di conformità e dalla frequenza con cui cambiano le credenziali. Un sistema di gestione dei segreti maturo non è automaticamente il primo passo corretto se il team non riesce a gestirlo con costanza.

Un archivio di segreti cifrato con accesso individuale degli utenti è in genere una scelta solida quando più persone necessitano di accesso controllato a un inventario in crescita. Una configurazione di deployment con accesso limitato è utile quando il meccanismo di deployment può limitare chi può leggere o modificare un valore. Un flusso di inserimento manuale può essere appropriato per un numero ridotto di modifiche poco frequenti, purché il processo registri chi ha inserito il segreto, dove è stato inserito e come il valore viene recuperato.

Evita di trattare un documento condiviso in chiaro, una chat di team senza restrizioni o un repository come archivio principale dei segreti di produzione. Evita inoltre di presumere che un segreto Compose sia un vault completo: Compose può ricavare il contenuto del segreto da un file sull'host o, in Docker Compose, da una variabile d'ambiente dell'host. Queste posizioni di origine richiedono controlli di accesso propri. I segreti Compose supportati da variabili d'ambiente non sono supportati da docker stack deploy.

• Usa un archivio di segreti cifrato con account individuali quando più persone necessitano di accesso o la verificabilità è importante.
• Usa impostazioni di deployment con accesso limitato quando solo un piccolo gruppo amministrativo deve fornire valori ai carichi di lavoro.
• Usa un flusso manuale documentato solo per modifiche a basso volume con approvazione chiara, trasferimento sicuro e procedure di recupero.
• Conserva nella documentazione di deployment un riferimento all'ID di registro del segreto, non al suo valore effettivo.

Applica il privilegio minimo a database, servizi email, API e integrazioni

Il privilegio minimo significa concedere a utenti e processi solo l'accesso necessario per le attività assegnate. NIST richiede inoltre che i privilegi siano riesaminati periodicamente e che gli accessi non necessari siano rimossi o riassegnati. Applica questo principio alle credenziali, non solo agli utenti umani.

Per un database, preferisci un account specifico dell'applicazione anziché un account amministratore condiviso. Per l'email, usa credenziali destinate alla funzione di invio dell'applicazione anziché la password della casella di posta di una persona. Per le API, scegli le autorizzazioni più ristrette disponibili e separa le credenziali di sviluppo, test e produzione. Per le integrazioni, identifica se il token può leggere dati, scrivere dati, eliminarli, amministrare utenti o creare ulteriori credenziali.

Un test utile è il raggio d'impatto: se questo valore viene esposto, cosa può effettivamente fare un aggressore? Un token con ambito ristretto associato a una sola applicazione è più facile da revocare e causa meno danni rispetto a un token con ampi privilegi riutilizzato tra sistemi.

• Crea credenziali di database separate per ogni applicazione e ambiente, dove il servizio lo consente.
• Evita di usare un superutente del database o credenziali amministrative estese per l'accesso ordinario dell'applicazione.
• Usa token API separati per applicazioni o integrazioni diverse anziché riutilizzare un unico token generico.
• Limita autorizzazioni, dati accessibili e capacità amministrative alle effettive necessità dell'applicazione.
• Rivedi le credenziali dopo cambiamenti di ruolo, fornitore, integrazione o architettura.

Crea una procedura di rotazione che eviti integrazioni non funzionanti

La rotazione è una sostituzione controllata, non un semplice ripristino della password. Una modifica non pianificata può interrompere la connettività al database, la consegna delle email, i webhook o l'automazione essenziale. La sequenza più sicura consiste nel preparare una sostituzione, aggiornare il servizio che la utilizza, convalidarla, revocare il vecchio valore e documentare il risultato.

Inizia con una voce dell'inventario che indichi se sono possibili credenziali parallele. Alcuni provider consentono a un nuovo token di coesistere brevemente con il vecchio token; ciò rende più semplice una transizione graduale. Quando la sovrapposizione non è disponibile, pianifica una finestra di manutenzione, definisci un percorso di rollback e assicurati che siano disponibili i responsabili corretti.

Dopo la modifica, verifica la funzione reale anziché limitarti a controllare che il servizio si avvii. Testa una lettura e una scrittura nel database appropriate per l'applicazione, invia un'email controllata, effettua una chiamata API autorizzata oppure esegui il flusso di lavoro critico. Poi rimuovi la vecchia credenziale e cerca nelle posizioni di esposizione note se la rotazione è avvenuta in seguito a una sospetta fuga di dati.

• 1. Inventario: identifica la credenziale, il responsabile, i consumatori, le dipendenze e le posizioni di esposizione.
• 2. Sostituzione: genera o ottieni un nuovo valore tramite il processo approvato dal responsabile del servizio di terze parti.
• 3. Aggiornamento: fornisci il valore sostitutivo solo all'applicazione autorizzata o al percorso di deployment autorizzato.
• 4. Convalida: testa la specifica integrazione o funzione che dipende dalla credenziale.
• 5. Revoca: disabilita, elimina o altrimenti invalida il valore precedente non appena sia sicuro farlo.
• 6. Documentazione: registra data, operatore, risultato della convalida, prossima data di revisione ed eventuali eccezioni.