Condividi tramite

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 con la protezione avanzata dell'archiviazione e limitare l'accesso e la manipolazione e controllando tali azioni. Eseguire un processo di rotazione affidabile e regolare che può improvvisare rotazioni per le 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 non corretta 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 SECURE Shell (SSH) sono segreti. Alcune credenziali, ad esempio i token OAuth sul 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 l'uso di impostazioni di configurazione che in genere non vengono considerate segrete come segreti dell'applicazione.

Definizioni 

Termine Definizione
Certificati File digitali che contengono le chiavi pubbliche per la crittografia o la decrittografia.
Credenziali 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 Principio Zero Trust 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, i segreti possono causare una violazione.
X.509 Standard che definisce il formato dei certificati di 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. Prendere in considerazione l'uso di un sistema di gestione della configurazione dedicato, ad esempio app Azure Configurazione per gestire queste impostazioni. Per altre informazioni, vedere Che cos'è app Azure Configurazione?

Strategie di progettazione chiave

La strategia di gestione dei segreti deve ridurre al minimo i segreti il più possibile 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 in stringa di connessione ed è sicuro 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.

Gestire i segreti del carico di lavoro

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 è compromessa, è più facile 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 segreta

Usare un sistema di gestione dei segreti, ad esempio Azure Key Vault, per archiviare i segreti in un ambiente con protezione avanzata, 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 vengono 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à autorizzate e i servizi devono avere accesso agli archivi segreti. L'accesso al sistema può essere limitato tramite autorizzazioni. Applicare sempre l'approccio con privilegi minimi quando si assegnano 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 l'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 da un 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 attentamente i token di accesso OAuth, tenendo conto del tempo necessario. Valutare se la finestra di esposizione deve essere adattata a un periodo più breve. I token di aggiornamento devono essere archiviati in modo sicuro con esposizione limitata all'applicazione. Anche i certificati rinnovati devono usare una nuova chiave. Per informazioni sui token di aggiornamento, vedere Proteggere i token di aggiornamento on-behalf-of di OAuth 2.0.

Sostituire i segreti dopo aver raggiunto la fine del ciclo di vita, non vengono più usati dal carico di lavoro o se sono stati compromessi. Viceversa, non ritirare i segreti attivi a meno che non si tratti di 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 in segreti, consumer e metodi di accesso per una rotazione uniforme.

Per altre informazioni su come Archiviazione di Azure gestisce la rotazione, vedere Gestire le chiavi di accesso dell'account.

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

Usare i segreti del carico di lavoro in modo sicuro

In qualità di generatore o operatore segreto, dovrebbe essere possibile distribuire i 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, è necessario eseguire un processo per distribuire correttamente le credenziali ai destinatari autorizzati. I piani di ripristino di emergenza devono includere procedure di ripristino segrete. Avere un processo per situazioni in cui una chiave viene compromessa o persa e deve essere rigenerata su richiesta. Considerare le procedure consigliate seguenti per la sicurezza quando si usano segreti:

Impedisci la codifica

Non impostare segreti hardcoded come testo statico negli artefatti del codice, ad esempio il codice dell'applicazione, i file di configurazione e le pipeline di distribuzione di compilazione. Questa procedura 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 le 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 di segreti reali.

Usare strumenti che rilevano periodicamente segreti esposti nel codice dell'applicazione e creano artefatti. È possibile aggiungere questi strumenti come hook di precommit Git che eseguono l'analisi delle credenziali prima che vengano distribuiti i commit del codice sorgente. Esaminare e purificare regolarmente i log delle applicazioni per garantire che non vengano registrati inavvertitamente segreti. È anche possibile rafforzare il rilevamento tramite 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

In qualità di 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 segreto precedente non è valido, ma il nuovo segreto non è stato inserito. Durante tale finestra, il componente che l'applicazione sta tentando di raggiungere non riconosce le richieste. È possibile ridurre al minimo questi problemi compilando 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 l'uno sull'altro.

Collaborare con il team operativo e far parte del processo di gestione delle modifiche. È necessario informare i proprietari delle credenziali quando si rimuove una parte dell'applicazione che usa credenziali non 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 dei segreti per inserire segreti nel codice dell'applicazione o nella configurazione in fase di esecuzione, impedendo l'esposizione accidentale dei segreti 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, nell'insieme di credenziali delle chiavi, nel modulo di protezione hardware gestito di Azure e in altre posizioni. Per altre informazioni, vedere Come scegliere la soluzione di gestione delle chiavi appropriata.

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 le anomalie e altro ancora.

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

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

Implementare il rilevamento dell'esposizione dei segreti. Integrare i processi nel carico di lavoro che rilevano attività sospette e controllano periodicamente la presenza di 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 Servizi connessi di Visual Studio o file solo locali per accedere alle credenziali.

Elenco di controllo relativo alla sicurezza

Fare riferimento al set completo di raccomandazioni.

Elenco di controllo relativo alla sicurezza