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 le panoramica della piattaforma al fine di comprendere il panorama complessivo di Google Cloud 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 super amministratore protetto Google Cloud.

• Suddividi le applicazioni e gli ambienti (di staging o di produzione) in progetti distinti come descritto in Decidere una gerarchia delle risorse per la 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-curated con le autorizzazioni minime necessarie oppure crea un ruolo personalizzato se necessario.

• 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.

• Motore per suggerimenti IAM può essere utile per identificare le associazioni IAM con privilegi.

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

• Per lo sviluppo 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 altre piattaforme di computing Google Cloud, come Le funzioni Cloud Run, le librerie client ottengono le credenziali tramite server di metadati dell'istanza.

• Su GKE, puoi utilizzare l'identità dei carichi di lavoro fornisce le credenziali anche 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 preferibili per esportare le credenziali di un account di servizio perché non richiedono l'accesso e l'archiviazione sicura di un secret aggiuntivo all'esterno 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 secret viene utilizzato tramite le variabili di ambiente, le configurazioni errate ad esempio l'abilitazione degli endpoint di debug o l'inclusione delle dipendenze che elaborano i log i dettagli dell'ambiente potrebbero rivelare 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 data store. Considera quanto segue:

  • Il datastore espande l'accesso al secret?

  • È possibile controllare l'accesso al secret?

  • Il datastore è conforme alla crittografia dei dati at-rest e requisiti di regionalizzazione?

Ti consigliamo di utilizzare direttamente l'API Secret Manager utilizzando uno dei le librerie client fornite o seguendo le REST o documentazione di GRPC.

Amministrazione

Fai riferimento ai secret tramite il numero di versione anziché utilizzare l'alias più recente. Esegui il deployment degli aggiornamenti ai numeri di versione utilizzando i processi di rilascio esistenti. Generalmente, questo significa configurando 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 carico di lavoro potrebbe non essere in grado di utilizzare la versione del secret. Con il blocco su un numero di versione, può essere convalidato e sottoposto a rollback utilizzando i processi di release esistenti.

Disabilita le versioni del secret prima del giorno l'eliminazione o l'eliminazione di secret. In questo modo si evitano interruzioni mettendo il segreto in uno stato che sembra uguale a quello di distruzione, ma è reversibile. Vale a dire che puoi disattivare il servizio e attendere una settimana per assicurarti che non ci siano 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. Prendi in considerazione condizioni IAM basate sul tempo in alternativa ai secret in scadenza.

Ruota periodicamente i secret per:

• Limita l'impatto nel caso di un secret divulgato.

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

• Riduci la probabilità di un'interruzione.

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

• Contribuisci a identificare i secret nella tua 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 nella cartella o a livello di organizzazione per applicare il logging senza doverlo configurare su ogni secret o progetto.

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

La constraints/iam.allowedPolicyMemberDomains è possibile utilizzare i criteri dell'organizzazione 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 aumenta la quota è necessario, richiedi un aumento.

Conformità della 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.