Best practice per autenticare in modo sicuro le applicazioni in Google Cloud

I documenti di Google Cloud possono aiutarti con diverse parti del tuo lavoro. A volte potresti voler imparare a usare un nuovo servizio o vedere una funzionalità in azione. Durante un'altra visita alla documentazione, potresti dover sviluppare un'applicazione per l'uso in produzione.

I nostri documenti sono spesso scritti per aiutare l'utente a iniziare a usare un servizio o una funzionalità. In un ambiente di produzione o di sviluppo, la tua organizzazione potrebbe adottare alcune best practice per la sicurezza. Potrebbe essere necessario autenticare le applicazioni in modo diverso da quanto indicato nei documenti.

Per scegliere il metodo di autenticazione più adatto alle tue applicazioni, utilizza la seguente struttura decisionale. Nella parte restante di questo articolo viene spiegato ognuno dei modi sicuri per autenticare le applicazioni.

Diagramma ad albero decisionale per aiutarti a scegliere un modo per autenticare le applicazioni. Ogni opzione è descritta in dettaglio nelle sezioni di questo articolo.

Panoramica delle credenziali predefinite dell'applicazione

Nella maggior parte dei casi, vuoi che il codice effettui richieste API. Puoi utilizzare una strategia denominata Application Default Credentials (ADC) per trovare automaticamente le credenziali richieste e autenticare la tua applicazione. Tutte le librerie client di Google Cloud supportano ADC.

Con il controller ADC, puoi sviluppare localmente utilizzando un metodo di autenticazione e quindi eseguire l'autenticazione con un altro metodo durante il deployment di test o produzione. Non devi apportare alcuna modifica al codice quando ti sposti tra i diversi ambienti di deployment e tra i metodi di autenticazione supportati.

Le librerie client determinano quali metodi di autenticazione sono disponibili. ADC seleziona quindi il metodo di autenticazione corretto per consentire all'applicazione di effettuare richieste API, indipendentemente dal fatto che tu stia sviluppando localmente o in produzione. Ove possibile, prova a utilizzare ADC per le tue applicazioni.

Per ulteriori informazioni, consulta la Panoramica delle credenziali predefinite dell'applicazione (ADC, Application Default Credentials) e come ADC trova automaticamente le credenziali.

Sviluppo locale e test con l'interfaccia a riga di comando di Google Cloud

In questo scenario, utilizzi l'interfaccia a riga di comando di Google Cloud per apportare modifiche alla configurazione del tuo progetto utilizzando le API Cloud o scrivi il codice per testare le nuove integrazioni con tali API. Questo tipo di utilizzo interattivo è principalmente destinato allo sviluppo e ai test sulla macchina locale. Fornisci le tue credenziali per accedere all'interfaccia a riga di comando di Google Cloud. Questo approccio consente di monitorare l'identità che ha effettuato la richiesta API e gestire le quote o di fornire un audit trail per motivi di sicurezza.

Per eseguire l'autenticazione in modo interattivo con l'interfaccia a riga di comando di Google Cloud ed eseguire i tuoi comandi e apportare modifiche di configurazione, utilizza il comando gcloud auth login e specifica un progetto di fatturazione di proprietà dell'utente con il flag --billing-project. Le chiamate ad alcune API Cloud, come l'API Cloud Translation o l'API Cloud Vision, hanno esito negativo senza il set di progetto di fatturazione di proprietà dell'utente.

Per fare in modo che il codice effettui chiamate API Cloud dal tuo ambiente di sviluppo locale, utilizza le librerie client di Google e ADC. Per farlo, utilizza il comando gcloud auth application-default login e specifica un progetto di fatturazione di proprietà dell'utente con il flag --billing-project. Anche in questo caso, le chiamate ad alcune API Cloud, come per l'API Cloud Translation o l'API Cloud Vision, non riescono, senza il progetto di fatturazione impostato dall'utente stesso.

Non assegnare al tuo account un ruolo che conceda più autorizzazioni di quelle richieste per effettuare le richieste API Cloud per la tua applicazione. Il motore per suggerimenti di Identity and Access Management (IAM) può verificare quali autorizzazioni non sono state necessarie negli ultimi 90 giorni, in modo da poterle rimuovere.

Negli ambienti Google Cloud

In questo scenario, il tuo codice dell'applicazione viene eseguito in Google Cloud e utilizza il serverless e la famiglia di prodotti Compute, ad esempio VM di Compute Engine, Cloud Run, App Engine, Google Kubernetes Engine (GKE) o Cloud Functions. Poiché le applicazioni vengono eseguite nell'ambiente Google Cloud, utilizza le credenziali predefinite.

Con le credenziali predefinite, la tua applicazione recupera il token di identità associato all'istanza virtuale che esegue il tuo codice. Il token di identità viene recuperato da un server di metadati eseguito sull'istanza virtuale. Questo token può quindi essere utilizzato per eseguire l'autenticazione e effettuare richieste API Cloud utilizzando l'ADC.

Non devi fare nulla in modo diverso per utilizzare le credenziali predefinite perché fanno parte dell'ADC. Non è necessario modificare il codice o creare e gestire gli account di servizio e la rotazione delle chiavi.

Data center on-premise o altro provider cloud

In questo scenario, il codice dell'applicazione viene eseguito nell'infrastruttura del tuo data center o in un altro provider cloud come AWS o Azure. Se è disponibile il supporto per OpenID Connect (OIDC), utilizza la federazione delle identità per i carichi di lavoro esterni e crea un pool Workload Identity per ogni ambiente per fornire l'autenticazione per le tue applicazioni.

Con la federazione delle identità, puoi utilizzare Identity and Access Management (IAM) per concedere i ruoli IAM delle identità esterne, compresa la possibilità di impersonare account di servizio. Questo approccio consente di accedere alle risorse direttamente mediante un token di accesso di breve durata.

Esempi di provider di identità includono:

  • AWS
  • Active Directory di Azure
  • Active Directory on-premise
  • Okta
  • Cluster Kubernetes

Per ulteriori informazioni, scopri come utilizzare la federazione delle identità per i carichi di lavoro esterni e creare un pool Workload Identity.

Se non hai supporto per OIDC o non vuoi utilizzare la federazione delle identità, puoi creare account di servizio gestiti dall'utente. Questi account di servizio sono illustrati nella sezione successiva. Archivia queste credenziali in un archivio digitale che il tuo provider potrebbe offrirti, ad esempio AWS Secret Manager o Azure Key Vault. Non scrivere queste credenziali su disco, tranne in formato criptato.

Account di servizio gestiti dall'utente

In questo scenario, il tuo codice non è in esecuzione in Google Cloud o in un ambiente che supporta OpenID Connect e la federazione delle identità. Se l'ambiente è considerato attendibile e non esistono vincoli del Servizio Criteri dell'organizzazione, puoi utilizzare account di servizio per autenticare le tue applicazioni. ADC funziona con gli account di servizio, quindi le tue applicazioni possono utilizzare automaticamente diversi metodi di autenticazione in diversi ambienti di deployment.

Un account di servizio è un tipo speciale di account utilizzato da un'applicazione, non da una persona. Ogni account di servizio è associato a coppie di chiavi RSA pubbliche/private utilizzate per l'autenticazione. Assicurati che vi sia pochissimo rischio che l'ambiente sia compromesso e che le chiavi degli account di servizio siano esposte. Per proteggere le chiavi che esporti e ridurre al minimo i potenziali rischi per la sicurezza, consulta le best practice per le chiavi degli account di servizio.

Puoi anche utilizzare un token JWT (JSON Web Token) autofirmato con il tuo account di servizio per evitare un roundtrip non necessario per acquistare i token. Per ulteriori informazioni, consulta l'articolo su come effettuare una richiesta autenticata con JWT a un'API Cloud Endpoints.

Gli account di servizio eseguono azioni per tuo conto, ma potrebbero disporre di autorizzazioni eccessive e spesso non vengono eliminate quando non sono più necessarie. Il consigliatore di Identity and Access Management può esaminare le autorizzazioni non richieste negli ultimi 90 giorni e puoi identificare gli account di servizio inutilizzati che devono essere rimossi.

Ambienti semi-attendibili o con restrizioni

In questo scenario, il codice dell'applicazione viene eseguito in un ambiente semi-attendibile o sono applicate limitazioni ai criteri che limitano le azioni che possono essere eseguite. Non utilizzare questi account di servizio in questi ambienti per eseguire l'autenticazione ed effettuare richieste Cloud API.

Il servizio Criteri dell'organizzazione potrebbe essere utilizzato per applicare vincoli al progetto che ti impediscono di comunicare con le risorse eseguite all'interno di altri progetti, in particolare nei deployment di produzione.

Poiché ogni ambiente è unico e potrebbero essere applicabili requisiti di sicurezza diversi, esamina le indicazioni specifiche dei servizi che potrebbero riguardarti. Collabora con i tuoi team operativi e per la sicurezza per progettare la soluzione migliore per le tue esigenze.

A livello generale, devi progettare un sistema che ti permetta di ottenere in modo sicuro un token di accesso di breve durata. Si applicano le seguenti considerazioni di progettazione:

  • Il token deve durare a sufficienza affinché l'app possa essere eseguita o sia aggiornabile.
  • Restringi l'ambito del token ai ruoli richiesti.
  • Non scrivere il token su disco.

Alcune soluzioni di esempio potrebbero includere l'accesso a una gestione di chiavi digitali on-premise come Hashicorp Vault o la limitazione dell'accesso a Cloud Run e poi il recupero automatico delle credenziali da Secret Manager o le credenziali criptate da Cloud Key Management Service.

Puoi anche contattare Google Cloud Consulting per ricevere assistenza nella progettazione e nella creazione di una soluzione sicura.

Considerazioni sulla sicurezza

I token JWT o OIDC utilizzati durante il processo di autenticazione dell'applicazione sono validi per tutta la loro durata. Per ridurre il rischio di esposizione, configura la durata del token in modo che sia leggermente più lunga del previsto per l'esecuzione del job. Ad esempio, se è necessario un token per 15 minuti durante l'esecuzione del job, configura la durata del token a 20 minuti.

Non puoi revocare questi token, a meno che non elimini l'account di servizio principale. Ribadisci l'assegnazione dei criteri relativi alla durata del token per ridurre la durata dell'utilizzo di un token potenzialmente compromesso.

Le chiavi dell'account di servizio potrebbero essere rubate e utilizzate per generare credenziali in modo quasi non tracciabile per sempre o fino alla successiva rotazione della chiave. Per proteggere le chiavi che esporti e ridurre al minimo i potenziali rischi per la sicurezza, consulta le best practice per le chiavi degli account di servizio, come la rotazione e il controllo delle chiavi.

Se necessario, puoi eliminare le chiavi dell'account di servizio in modo da non poter più essere utilizzate.

Passaggi successivi

Per ulteriori informazioni sull'utilizzo delle credenziali nelle applicazioni, consulta le best practice per la gestione delle credenziali.