Share via

Raccomandazioni per la protezione dei segreti dell'applicazione

  • Articolo

Si applica a questa raccomandazione dell'elenco di controllo per la sicurezza di Azure Well-Architected Framework:

SE:09 Proteggere i segreti dell'applicazione tramite la protezione avanzata dell'archiviazione e limitando l'accesso e la manipolazione e controllando tali azioni. Eseguire un processo di rotazione affidabile e regolare che può improvvisare rotazioni per emergenze.

Questa guida descrive le raccomandazioni per proteggere le informazioni riservate nelle applicazioni. La corretta gestione dei segreti è fondamentale per mantenere la sicurezza e l'integrità dell'applicazione, del carico di lavoro e dei dati associati. La gestione impropria dei segreti può causare violazioni dei dati, interruzioni del servizio, violazioni normative e altri problemi.

Le credenziali, ad esempio le chiavi API, i token OAuth (Open Authorization) e le chiavi SSH (Secure Shell) sono segreti. Alcune credenziali, ad esempio i token OAuth lato client, possono essere create dinamicamente in fase di esecuzione. I segreti dinamici devono comunque essere protetti nonostante la loro natura temporanea. Anche le informazioni non credenziali, ad esempio certificati e chiavi di firma digitale, possono essere sensibili. I requisiti di conformità possono causare la gestione delle impostazioni di configurazione che in genere non sono considerate segrete come segreti dell'applicazione.

Definizioni 

Termine Definizione
Certificati File digitali che contengono le chiavi pubbliche per la crittografia o la decrittografia.
Titolo Informazioni utilizzate per verificare l'identità dell'editore o del consumer in un canale di comunicazione.
Analisi delle credenziali Processo di convalida del codice sorgente per assicurarsi che i segreti non siano inclusi.
Crittografia Processo in base al quale i dati vengono resi illeggibili e bloccati con un codice segreto.
Chiave Codice segreto usato per bloccare o sbloccare i dati crittografati.
Accesso con privilegi minimi Un Zero Trust principio che mira a ridurre al minimo un set di autorizzazioni per completare una funzione di processo.
Identità gestita Identità assegnata alle risorse e gestita da Azure.
Nonsecret Informazioni che non compromettono il comportamento di sicurezza del carico di lavoro in caso di perdita.
Rotazione Il processo di aggiornamento regolare dei segreti in modo che, se compromessi, siano disponibili solo per un periodo di tempo limitato.
Segreto Componente riservato del sistema che facilita la comunicazione tra i componenti del carico di lavoro. In caso di perdita di segreti, i segreti possono causare una violazione.
X.509 Standard che definisce il formato dei certificati a chiave pubblica.

Importante

Non trattare i nonsecret come segreti. I segreti richiedono rigore operativo che non è necessario per i nonsecret e che potrebbero comportare costi aggiuntivi.

Le impostazioni di configurazione dell'applicazione, ad esempio gli URL per le API usate dall'applicazione, sono un esempio di nonsecret. Queste informazioni non devono essere archiviate con il codice dell'applicazione o i segreti dell'applicazione. È consigliabile usare un sistema di gestione della configurazione dedicato, ad esempio Configurazione app di Azure per gestire queste impostazioni. Per altre informazioni, vedere Che cos'è Configurazione app di Azure?.

Strategie di progettazione chiave

La strategia di gestione dei segreti deve ridurre al minimo i segreti e integrarli nell'ambiente sfruttando le funzionalità della piattaforma. Ad esempio, se si usa un'identità gestita per l'applicazione, le informazioni di accesso non sono incorporate nelle stringhe di connessione ed è possibile archiviare le informazioni in un file di configurazione. Considerare le aree di interesse seguenti prima di archiviare e gestire i segreti:

  • I segreti creati devono essere mantenuti nell'archiviazione sicura con controlli di accesso rigorosi.

  • La rotazione dei segreti è un'operazione proattiva, mentre la revoca è reattiva.

  • Solo le identità attendibili devono avere accesso ai segreti.

  • È consigliabile mantenere un audit trail per controllare e convalidare l'accesso ai segreti.

Creare una strategia intorno a questi punti per prevenire il furto di identità, evitare ripudio e ridurre al minimo l'esposizione non necessaria alle informazioni.

Procedure sicure per la gestione dei segreti

Se possibile, evitare di creare segreti. Trovare modi per delegare la responsabilità alla piattaforma. Ad esempio, usare le identità gestite predefinite della piattaforma per gestire le credenziali. Un minor numero di segreti comporta una riduzione della superficie di attacco e meno tempo impiegato per la gestione dei segreti.

È consigliabile che le chiavi abbiano tre ruoli distinti: utente, amministratore e revisore. La distinzione dei ruoli consente di garantire che solo le identità attendibili abbiano accesso ai segreti con il livello di autorizzazione appropriato. Informare sviluppatori, amministratori e altri membri del personale pertinente sull'importanza della gestione dei segreti e delle procedure consigliate per la sicurezza.

Chiavi precondivise

È possibile controllare l'accesso creando chiavi distinte per ogni consumer. Ad esempio, un client comunica con un'API di terze parti usando una chiave precondivisa. Se un altro client deve accedere alla stessa API, deve usare un'altra chiave. Non condividere le chiavi anche se due consumer hanno gli stessi modelli di accesso o ruoli. Gli ambiti consumer possono cambiare nel tempo e non è possibile aggiornare in modo indipendente le autorizzazioni o distinguere i modelli di utilizzo dopo la condivisione di una chiave. L'accesso distinto semplifica anche la revoca. Se la chiave di un consumer viene compromessa, è più semplice revocare o ruotare tale chiave senza influire sugli altri consumer.

Queste linee guida si applicano a ambienti diversi. La stessa chiave non deve essere usata sia per la preproduzione che per gli ambienti di produzione. Se si è responsabili della creazione di chiavi precondivise, assicurarsi di creare più chiavi per supportare più client.

Per altre informazioni, vedere Raccomandazioni per la gestione delle identità e degli accessi.

Archiviazione privata

Usare un sistema di gestione dei segreti, ad esempio Azure Key Vault, per archiviare i segreti in un ambiente protetto, crittografare i dati inattivi e in transito e controllare l'accesso e le modifiche ai segreti. Se è necessario archiviare i segreti dell'applicazione, mantenerli all'esterno del codice sorgente per semplificare la rotazione.

I certificati devono essere archiviati solo in Key Vault o nell'archivio certificati del sistema operativo. Ad esempio, l'archiviazione di un certificato X.509 in un file PFX o in un disco non è consigliata. Se è necessario un livello di sicurezza superiore, scegliere i sistemi con funzionalità del modulo di protezione hardware anziché archivi segreti basati su software.

Compromesso: le soluzioni HSM sono offerte a un costo più elevato. È anche possibile che si verifichi un effetto sulle prestazioni dell'applicazione a causa di livelli di sicurezza aggiunti.

Un sistema di gestione dei segreti dedicato semplifica l'archiviazione, la distribuzione e il controllo dell'accesso ai segreti dell'applicazione. Solo le identità e i servizi autorizzati devono avere accesso agli archivi segreti. L'accesso al sistema può essere limitato tramite autorizzazioni. Applicare sempre l'approccio con privilegi minimi durante l'assegnazione delle autorizzazioni.

È anche necessario controllare l'accesso a livello di segreto. Ogni segreto deve avere accesso solo a un singolo ambito di risorsa. Creare limiti di isolamento in modo che un componente sia in grado di usare solo i segreti necessari. Se un componente isolato viene compromesso, non può ottenere il controllo di altri segreti e potenzialmente dell'intero carico di lavoro. Un modo per isolare i segreti consiste nell'usare più insiemi di credenziali delle chiavi. Non sono previsti costi aggiuntivi per la creazione di insiemi di credenziali delle chiavi aggiuntivi.

Implementare il controllo e il monitoraggio per l'accesso segreto. Registrare chi accede ai segreti e quando identificare attività non autorizzate o sospette. Per informazioni sulla registrazione dal punto di vista della sicurezza, vedere Raccomandazioni sul monitoraggio della sicurezza e il rilevamento delle minacce.

Rotazione dei segreti

Avere un processo sul posto che mantiene l'igiene segreta. La longevità di un segreto influenza la gestione di quel segreto. Per ridurre i vettori di attacco, i segreti devono essere ritirati e sostituiti con nuovi segreti il più frequentemente possibile.

Gestire con attenzione i token di accesso OAuth, prendendo in considerazione il tempo necessario. Si consideri se la finestra di esposizione deve essere modificata in un periodo più breve. I token di aggiornamento devono essere archiviati in modo sicuro con un'esposizione limitata all'applicazione. Anche i certificati rinnovati devono usare una nuova chiave. Per informazioni sui token di aggiornamento, vedere Secure OAuth 2.0 On-Behalf-Of token di aggiornamento.

Sostituire i segreti dopo aver raggiunto la fine della vita, non vengono più usati dal carico di lavoro o se sono stati compromessi. Al contrario, non ritirare segreti attivi a meno che non sia un'emergenza. È possibile determinare lo stato di un segreto visualizzando i log di accesso. I processi di rotazione dei segreti non devono influire sull'affidabilità o sulle prestazioni del carico di lavoro. Usare strategie che creano ridondanza nei segreti, nei consumer e nei metodi di accesso per una rotazione uniforme.

Per altre informazioni sul modo in cui Archiviazione di Azure gestisce la rotazione, vedere Gestire le chiavi di accesso all'account.

I processi di rotazione devono essere automatizzati e distribuiti senza alcuna interazione umana. L'archiviazione dei segreti in un archivio di gestione dei segreti che supporta in modo nativo i concetti di rotazione può semplificare questa attività operativa.

Procedure sicure per l'uso dei segreti

Come generatore segreto o operatore, è necessario essere in grado di distribuire segreti in modo sicuro. Molte organizzazioni usano strumenti per condividere in modo sicuro i segreti all'interno dell'organizzazione e esternamente ai partner. In assenza di uno strumento, è possibile distribuire correttamente le credenziali ai destinatari autorizzati. I piani di ripristino di emergenza devono includere procedure di ripristino segreto. Avere un processo per situazioni in cui una chiave è compromessa o perdita e deve essere rigenerata su richiesta. Prendere in considerazione le procedure consigliate seguenti per la sicurezza quando si usano i segreti:

Prevenire il hardcoding

Non creare segreti del codice rigido come testo statico negli artefatti del codice, ad esempio codice dell'applicazione, file di configurazione e pipeline di distribuzione di compilazione. Questa pratica ad alto rischio rende il codice vulnerabile perché i segreti vengono esposti a tutti gli utenti con accesso in lettura.

È possibile evitare questa situazione usando identità gestite per eliminare la necessità di archiviare le credenziali. L'applicazione usa l'identità assegnata per eseguire l'autenticazione su altre risorse tramite il provider di identità (IdP). Testare in ambienti non di produzione con segreti falsi durante lo sviluppo per evitare l'esposizione accidentale dei segreti reali.

Usare gli strumenti che rilevano periodicamente i segreti esposti nel codice dell'applicazione e gli artefatti di compilazione. È possibile aggiungere questi strumenti come hook precommit Git che eseguono l'analisi delle credenziali prima della distribuzione del commit del codice sorgente. Esaminare e sanificare regolarmente i log delle applicazioni per garantire che non vengano registrati inavvertitamente segreti. È anche possibile rafforzare il rilevamento tramite le verifiche peer.

Nota

Se gli strumenti di analisi individuano un segreto, tale segreto deve essere considerato compromesso. Deve essere revocato.

Rispondere alla rotazione dei segreti

Come proprietario del carico di lavoro, è necessario comprendere il piano di rotazione dei segreti e i criteri in modo da poter incorporare nuovi segreti con interruzioni minime agli utenti. Quando un segreto viene ruotato, potrebbe esserci una finestra quando il vecchio segreto non è valido, ma il nuovo segreto non è stato inserito. Durante questa finestra, il componente che l'applicazione sta tentando di raggiungere non riconosce le richieste. È possibile ridurre al minimo questi problemi creando la logica di ripetizione dei tentativi nel codice. È anche possibile usare modelli di accesso simultanei che consentono di avere più credenziali che possono essere modificate in modo sicuro senza influire tra loro.

Collaborare con il team operativo e far parte del processo di gestione delle modifiche. È consigliabile informare i proprietari delle credenziali quando si rimuove una parte dell'applicazione che usa le credenziali che non sono più necessarie.

Integrare il recupero e la configurazione dei segreti nella pipeline di distribuzione automatizzata. Il recupero dei segreti consente di assicurarsi che i segreti vengano recuperati automaticamente durante la distribuzione. È anche possibile usare modelli di inserimento segreto per inserire segreti nel codice dell'applicazione o nella configurazione in fase di esecuzione, che impedisce che i segreti vengano esposti accidentalmente ai log o al controllo della versione.

Facilitazione di Azure

Archiviare i segreti usando Key Vault. Archiviare i segreti nel sistema di gestione dei segreti di Azure, Key Vault, HSM gestito di Azure e altre posizioni. Per altre informazioni, vedere Come scegliere la soluzione di gestione delle chiavi corretta.

Integrare il controllo degli accessi in base all'identità. Microsoft Entra ID e identità gestite consentono di ridurre al minimo la necessità di segreti. Microsoft Entra ID offre un'esperienza estremamente sicura e utilizzabile per il controllo di accesso con meccanismi predefiniti per la gestione della rotazione delle chiavi, per anomalie e altro ancora.

Usare il controllo degli accessi in base al ruolo di Azure per assegnare autorizzazioni agli utenti, ai gruppi e alle applicazioni in un determinato ambito.

Usare un modello di accesso per controllare insiemi di credenziali delle chiavi, autorizzazioni e segreti. Per altre informazioni, vedere Panoramica del modello di accesso.

Implementare il rilevamento dell'esposizione privata. Integrare i processi nel carico di lavoro che rilevano attività sospette e controllano periodicamente le chiavi esposte nel codice dell'applicazione. Alcune opzioni includono:

Non archiviare chiavi e segreti per qualsiasi tipo di ambiente nei file di configurazione dell'applicazione o nelle pipeline di integrazione continua e recapito continuo (CI/CD). Gli sviluppatori devono usare Visual Studio Connected Services o file solo locali per accedere alle credenziali.

Elenco di controllo relativo alla sicurezza

Fare riferimento al set completo di raccomandazioni.

Elenco di controllo della sicurezza