Best practice di Secret Manager

Questa guida illustra alcune best practice per l'utilizzo di Secret Manager. La guida non è un elenco completo di consigli. Ti consigliamo di consultare la panoramica della piattaforma per comprendere il panorama complessivo di Google Cloud e la panoramica di Secret Manager prima di leggere questa guida.

Controllo degli accessi

L'accesso all'API Secret Manager è protetto da IAM. Segui il principio del privilegio minimo quando concedi le autorizzazioni ai secret.

• Limita la proprietà dell'organizzazione a un account super amministratore protetto.

• Suddividi le applicazioni e gli ambienti (di staging o di produzione) in progetti distinti come descritto in Decidere una gerarchia delle risorse per la tua zona di destinazione Google Cloud. In questo modo, puoi isolare gli ambienti con l'associazione IAM a livello di progetto e assicurarti che le quote vengano applicate in modo indipendente.

• Scegli un ruolo selezionato con le autorizzazioni minime necessarie o, se necessario, crea un ruolo personalizzato.

• Quando i secret per molti servizi si trovano in un unico progetto, utilizza le associazioni IAM a livello di secret o le condizioni IAM per limitare l'accesso al sottoinsieme necessario di secret.

• Il motore per suggerimenti IAM può aiutarti ulteriormente a identificare associazioni IAM con privilegi eccessivi.

Le credenziali sono necessarie per autenticarsi nell'API Secret Manager. Le librerie client utilizzano tutte una strategia simile per cercare le credenziali denominate Credenziali predefinite dell'applicazione.

• Quando sviluppi in locale, utilizza gcloud auth application-default login. Viene creato un file con le credenziali che vengono rilevate automaticamente dalle librerie client.

• Su Compute Engine e su altre piattaforme di calcolo Google Cloud come le funzioni Cloud Run, le librerie client ottengono le credenziali tramite il server di metadati dell'istanza.

• Su GKE, Workload Identity fornisce anche le credenziali tramite un servizio di metadati.

• Su altre piattaforme come Amazon Web Services o Microsoft Azure, valuta la possibilità di configurare la federazione delle identità per i carichi di lavoro, che utilizza i meccanismi di identità esistenti per autenticarsi nelle API Google Cloud.

Tutti questi metodi sono preferiti all'esportazione di una credenziale dell'account di servizio perché non richiedono l'archiviazione e l'accesso in sicurezza a un secret aggiuntivo al di fuori dell'API Secret Manager.

Pratiche di programmazione

Evita di passare i secret all'applicazione tramite il file system o le variabili di ambiente. Di seguito sono riportati alcuni motivi per cui è consigliabile utilizzare altri metodi per la gestione dei secret:

• Quando un segreto è accessibile nel file system, le vulnerabilità delle applicazioni come gli attacchi di attraversamento della directory possono diventare più gravi poiché l'aggressore potrebbe acquisire la capacità di leggere il materiale segreto.

• Quando un segreto viene utilizzato tramite variabili di ambiente, le configurazioni errate, come l'attivazione di endpoint di debug o l'inclusione di dipendenze che registrano i dettagli dell'ambiente di processo, possono causare la fuga di secret.

• Quando sincronizzi il materiale segreto con un altro data store (ad esempio i secret di Kubernetes), valuta i controlli di accesso forniti da quel datastore. Considera quanto segue:

  • Il data store espande l'accesso al secret?

  • È possibile controllare l'accesso al secret?

  • Il datastore è conforme ai requisiti di regionalizzazione e crittografia dei dati a riposo?

Ti consigliamo di utilizzare direttamente l'API Secret Manager utilizzando una delle librerie client fornite o seguendo la documentazione REST o GRPC.

Amministrazione

Fai riferimento ai secret tramite il loro numero di versione anziché utilizzare l'alias più recente. Esegui il deployment degli aggiornamenti ai numeri di versione utilizzando i processi di rilascio esistenti. In genere, questo significa configurare l'applicazione con una versione specifica del secret che viene letta all'avvio. Anche se l'utilizzo dell'alias più recente potrebbe essere pratico, se si verifica un problema con la nuova versione del secret, il tuo workload potrebbe non essere in grado di utilizzarla. Se la blocchi a un numero di versione, la configurazione può essere convalidata e ripristinata utilizzando le procedure di rilascio esistenti.

Disattiva le versioni dei secret prima di eliminarle o distruggerle. In questo modo è possibile evitare interruzioni mettendo il segreto in uno stato che sembra uguale a quello di distruzione, ma è reversibile. In altre parole, puoi disattivare la funzionalità e attendere una settimana per assicurarti che non ci siano dipendenze inutilizzate prima di eliminare definitivamente i dati.

Non impostare scadenza sui secret di produzione, a meno che tu non sia certo che debbano essere eliminati in modo irreversibile. La funzionalità di scadenza è più adatta per la pulizia automatica di ambienti temporanei. Valuta la possibilità di utilizzare le condizioni IAM basate sul tempo come alternativa ai secret con scadenza.

Ruota periodicamente i secret per:

• Limita l'impatto in caso di fuga di un secret.

• Assicurati che le persone che non richiedono più l'accesso a un secret non possano continuare a utilizzare un secret a cui hanno eseguito l'accesso in precedenza.

• Riduci la probabilità di un'interruzione del servizio.

Monitora i secret nella tua organizzazione utilizzando Cloud Asset Inventory per i seguenti motivi:

• Aiutano a identificare i secret in tutta l'organizzazione.

• Identifica la mancata conformità ai requisiti dell'organizzazione, ad esempio rotazione, configurazione della crittografia e posizione.

Attiva i log di accesso ai dati per ottenere e analizzare le informazioni sulle richieste AccessSecretVersion. Attiva questa opzione a livello di cartella o organizzazione per applicare il logging senza doverli configurare su ogni segreto o progetto.

Oltre ai controlli IAM, puoi limitare l'accesso all'API Secret Manager con controlli basati sulla rete configurando un perimetro Controlli di servizio VPC per la tua organizzazione.

Il criterio dell'organizzazione constraints/iam.allowedPolicyMemberDomains può essere utilizzato per limitare le identità che possono essere aggiunte ai criteri IAM per i secret.

Stima il picco di utilizzo delle chiavi (tenendo conto di un gran numero di richieste a causa di implementazioni di applicazioni simultanee o della scalabilità automatica del servizio) e assicurati che il tuo progetto disponga di una quota sufficiente per gestire un evento di questo tipo. Se hai bisogno di una quota più alta, richiedi un aumento.

Conformità alla residenza dei dati

Scegli i secret regionali se hai requisiti rigorosi di sovranità e residenza dei dati. I secret regionali ti consentono di archiviare dati sensibili in una posizione geografica specifica, offrendo garanzie complete per i dati at-rest, in uso e in transito e aiutandoti a rispettare i requisiti legali, normativi o organizzativi relativi alla residenza dei dati.