Best practice per l'esecuzione di un backend IoT su Google Cloud

Last reviewed 2024-12-06 UTC

Questo documento fornisce le best practice per la sicurezza per la gestione e l'esecuzione di un backend Internet of Things (IoT) su Google Cloud. In una soluzione IoT, un backend IoT connette i dispositivi edge ad altre risorse. Questo documento si concentra sui seguenti backend IoT: broker Message Queuing Telemetry Transport (MQTT) e la piattaforma IoT.

Questo documento fa parte di una serie di documenti che forniscono informazioni sulle architetture IoT su Google Cloud e sulla migrazione da IoT Core. Gli altri documenti di questa serie includono quanto segue:

Questo documento fornisce best practice per il provisioning e la gestione delle credenziali dei dispositivi, l'autenticazione e l'accesso ai dispositivi edge di controllo e per consentire ai dispositivi edge IoT di accedere alle risorse Google Cloud .

Architettura IoT

Un'architettura IoT include servizi che consentono di eseguire il provisioning e gestire le credenziali dei dispositivi, autenticare e controllo dell'accesso l'accesso ai dispositivi edge e consentire ai dispositivi edge di accedere alle risorse Google Cloud . Questo documento descrive due architetture di backend IoT: una che utilizza il broker MQTT e l'altra che utilizza una piattaforma IoT. Le principali differenze di sicurezza tra questi due backend riguardano l'identità del dispositivo e la gestione dei dispositivi. Le piattaforme IoT forniscono queste funzionalità come parte del loro sistema, mentre i broker MQTT richiedono di fornirle.

Il seguente diagramma descrive l'architettura IoT.

Architettura del backend IoT.

L'architettura mostra i servizi necessari per i seguenti tre processi:

  1. Provisioning dei certificati, ovvero la procedura che devi completare per preparare un dispositivo edge per la configurazione.

  2. Autenticazione e autorizzazione, che includono lo schema di autenticazione utilizzato dal dispositivo edge e dal broker MQTT o dalla piattaforma IoT per autenticarsi a vicenda.

  3. Connessioni tra i dispositivi edge e i servizi, ovvero le attività che il dispositivo edge completa per connettersi alle risorse cloud e caricare o scaricare dati. Google Cloud

Questo documento si concentra principalmente sulle best practice di sicurezza per il provisioning e l'autenticazione.

L'architettura utilizza una combinazione dei seguenti servizi e funzionalità:

  • Un dispositivo edge (ad esempio un dispositivo medico) che implementi ai margini del tuo ambiente e che si trova geograficamente vicino ai dati che vuoi elaborare. I dispositivi edge si connettono in modo bidirezionale al backend IoT, il che significa che possono inviare e ricevere messaggi dal backend IoT.
  • Un backend IoT che può essere un broker MQTT o una piattaforma IoT.
    • Un broker MQTT fornisce un'interfaccia sicura per la connessione dei dispositivi edge utilizzando il protocollo MQTT. I broker MQTT non dispongono di funzionalità per l'identità e la gestione dei dispositivi e si basano su sistemi esterni per fornirle.
    • Una piattaforma IoT è un'applicazione cloud a cui si connettono e con cui comunicano i dispositivi periferici. Le piattaforme IoT forniscono un'interfaccia sicura per la connessione dei dispositivi edge tramite il protocollo MQTT. Ogni piattaforma IoT ha una propria implementazione della sicurezza che determina come autentica e autorizza i dispositivi edge e come gestisce le identità dei dispositivi.
  • Un archivio certificati centrale che ospita i certificati per tutti i dispositivi edge.
  • Risorse cloud a cui devono accedere i dispositivi edge.

Provisioning di un dispositivo edge

Prima che un dispositivo edge possa connettersi ai tuoi workload di backend, devi provisionare un certificato per il dispositivo edge. Esistono due scenari principali che determinano la modalità di provisioning del certificato:

  • Se la tua soluzione si basa su dispositivi commerciali generici, hai il pieno controllo sulla procedura di provisioning dopo l'acquisto del dispositivo.

  • Se utilizzi dispositivi personalizzati, il processo di provisioning iniziale avviene durante la produzione dei dispositivi e devi integrare il processo di provisioning con i tuoi fornitori e produttori.

In entrambi gli scenari, devi creare certificati del dispositivo con una catena di attendibilità che rimanda a un'autorità di certificazione (CA) radice. Questi certificati autenticano l'identità del dispositivo e contribuiscono a garantire che gli aggiornamenti e le modifiche apportate al dispositivo siano eseguiti da attori attendibili. Utilizza un'autorità di certificazione come Certificate Authority Service per completare le seguenti attività:

Per eseguire il provisioning di un certificato del dispositivo, devi completare le seguenti attività:

  • Se il tuo dispositivo dispone di una soluzione di sicurezza hardware antimanomissione, ad esempio un elemento sicuro (SE) o un modulo di sicurezza hardware (HSM) che memorizza le chiavi private localmente e le chiavi private non vengono mai esposte esternamente, procedi nel seguente modo:

    1. Genera la coppia di chiavi pubblica/privata utilizzando la soluzione di sicurezza basata su hardware supportata dal tuo dispositivo.
    2. Richiedi un certificato utilizzando una richiesta di firma del certificato (CSR).

  • Se non utilizzi una soluzione di sicurezza basata su hardware per generare una coppia di chiavi pubblica/privata, utilizza la CA per generare le chiavi e il certificato. Per saperne di più, consulta Utilizzo di una chiave generata automaticamente. Il certificato che scarichi utilizzando questo metodo è già firmato.

Dopo aver generato e firmato un certificato del dispositivo, installalo sul dispositivo edge e archivialo in un repository centrale, ad esempio Secret Manager.

Per ulteriori informazioni, consulta la sezione Come implementare un'infrastruttura a chiave pubblica sicura e affidabile con Google Cloud CA Service (PDF).

Per informazioni su altre best practice di provisioning, consulta Best practice per il provisioning e la configurazione automatici di sistemi e server edge e bare metal.

Per proteggere una soluzione IoT vengono utilizzati tre tipi di certificati:

  • Il certificato CA radice fornisce la radice della catena di attendibilità di tutti gli altri certificati nel sistema. I carichi di lavoro di backend utilizzano il certificato radice per convalidare i certificati client e i dispositivi edge utilizzano il certificato radice per convalidare il certificato server. Devi distribuire il certificato radice sia al backend IoT sia ai dispositivi edge.

  • I certificati delle CA intermedie forniscono una catena di attendibilità radicata nella CA radice. Puoi utilizzare le CA intermedie per il provisioning o per le esigenze operative, ad esempio per concedere l'accesso alle CA intermedie ai produttori o per implementare processi di gestione delle CA flessibili.

  • I certificati del server vengono utilizzati per proteggere gli endpoint esposti dal backend IoT. Disponi di certificati server per i diversi algoritmi di crittografia che i tuoi endpoint devono supportare. I certificati server sono collegati alla CA radice. Un secret manager gestisce e archivia sia la parte privata che quella pubblica dei certificati server. Devi configurare il backend IoT con i certificati del server e le relative chiavi private.

  • I certificati client vengono utilizzati per identificare i dispositivi edge. Ogni dispositivo edge ha almeno un certificato client, il che significa che il numero di certificati che hai aumenta con il numero di dispositivi edge nel tuo ambiente. I certificati client sono collegati alla CA radice. Devi distribuire i certificati client ai tuoi dispositivi edge e al backend IoT.

Procedura per generare un certificato del dispositivo utilizzando un HSM o un SE

Il seguente diagramma mostra come viene eseguito il provisioning di un certificato del dispositivo quando si utilizza un HSM o un SE.

Procedura per generare un certificato del dispositivo.

In questo diagramma si verificano i seguenti passaggi:

  1. Il dispositivo edge genera la coppia di chiavi pubbliche nell'hardware.
  2. Scarichi la chiave pubblica e crei la richiesta di firma del certificato (CSR).
  3. Invia la CSR all'autorità di certificazione per richiedere un certificato.
  4. L'autorità di certificazione completa le seguenti azioni:
    1. Firma il certificato.
    2. Restituisce il certificato firmato al provisioner.
  5. Il provisioner completa le seguenti azioni:
    1. Invia il certificato firmato al dispositivo edge.
    2. Archivia il certificato firmato nell'archivio certificati centrale.
  6. Il dispositivo perimetrale memorizza il certificato in una posizione sicura.

Procedura per generare un certificato del dispositivo utilizzando la CA

Il seguente diagramma mostra come viene eseguito il provisioning di un certificato del dispositivo quando viene utilizzata un'autorità di certificazione.

Procedura per generare un certificato del dispositivo.

In questo diagramma si verificano i seguenti passaggi:

  1. Il provisioner richiede alla CA di inviare un certificato firmato per il dispositivo.
  2. L'autorità di certificazione completa le seguenti azioni:
    1. Genera una coppia di chiavi pubblica-privata e firma la chiave pubblica.
    2. Restituisce il certificato del dispositivo e la chiave privata al provisioner.
  3. Il provisioner completa le seguenti azioni:
    1. Invia il certificato e la chiave privata al dispositivo edge.
    2. Archivia il certificato e la chiave privata nell'archivio dei certificati centrale.
  4. Il dispositivo edge archivia il certificato e la chiave privata in una posizione sicura.

Se vuoi archiviare la chiave privata in un unico posto (il dispositivo), devi evitare di archiviarla nell'archivio dei secret centrale. Tuttavia, se memorizzi la chiave privata al di fuori dell'archivio segreti centrale e perdi l'accesso alla chiave privata, il dispositivo deve ripetere la procedura di provisioning.

Autenticare i dispositivi prima di firmare i certificati

La procedura per generare un certificato del dispositivo (sul dispositivo o utilizzando un'autorità di certificazione) richiede che il dispositivo e l'autorità di certificazione comunichino e si autentichino a vicenda.

Senza un'autenticazione corretta, la tua CA potrebbe considerare attendibile per errore un dispositivo dannoso. Ad esempio, un malintenzionato che sa come raggiungere l'infrastruttura di firma dei certificati della tua CA potrebbe implementare un dispositivo dannoso che chiede alla tua CA di firmare un certificato. Se non hai implementato l'autenticazione del dispositivo, la tua CA potrebbe firmare il certificato presentato dal dispositivo dannoso. Se la tua CA firma il certificato, il dispositivo dannoso può comunicare con il tuo backend come dispositivo attendibile.

Per impedire ai dispositivi dannosi di comunicare con la tua CA, ti consigliamo di eseguire le seguenti operazioni:

  • Implementa un meccanismo di autenticazione per i dispositivi non ancora attendibili.
  • Stabilire l'autenticità di qualsiasi dispositivo che richiede l'autenticazione.
  • Stabilisci l'autenticità del dispositivo prima che questo chieda alla CA di generare un nuovo certificato o firmarne uno esistente.

L'implementazione di un meccanismo di autenticazione in questa fase del processo di provisioning è difficile. Non puoi fare affidamento sui certificati del dispositivo per autenticare i dispositivi perché il dispositivo non ha ancora un certificato firmato dalla CA. Questa mancanza di un certificato firmato può verificarsi per i seguenti motivi:

  • Il dispositivo non ha ancora generato un certificato.
  • Il dispositivo non ha ancora inviato una CSR alla CA.
  • La CA non ha ancora restituito il certificato firmato al dispositivo.

Un modo per risolvere questo problema è estendere la procedura di provisioning del dispositivo per eseguire le seguenti operazioni per ogni dispositivo che vuoi autenticare o che devi autenticare:

  1. Genera un certificato di provisioning che utilizzi solo per autenticare il dispositivo rispetto all'infrastruttura di firma dei certificati.
  2. Firma il certificato di provisioning con la tua CA.
  3. Memorizza il certificato di provisioning firmato nell'elemento sicuro o nell'HSM sul dispositivo.
  4. Archivia il certificato di provisioning firmato nel backend Google Cloud.

Prima che al dispositivo venga concesso l'accesso all'infrastruttura di firma dei certificati della tua CA, il dispositivo deve presentare il certificato di provisioning. Deve presentare il certificato in modo che tu possa verificarne l'integrità e l'autenticità e determinare se il certificato corrisponde a uno dei certificati di provisioning memorizzati nel tuo backend Google Cloud . Se la verifica va a buon fine, il dispositivo può accedere all'infrastruttura di firma dei certificati della CA e la procedura di provisioning dei certificati può continuare.

Esistono differenze tra un certificato di provisioning e un certificato completamente attendibile. Un certificato di provisioning concede l'accesso solo a una quantità minima di servizi e infrastrutture. La creazione di un certificato di provisioning consente alla CA di verificare che il dispositivo sia autentico prima di considerarlo completamente attendibile e di rilasciare un certificato completamente attendibile.

Un'estensione di questa procedura è che puoi utilizzare le CA subordinate a cui i produttori di dispositivi hanno accesso, insieme alla tua CA, per firmare i certificati di provisioning. Ad esempio, un produttore potrebbe firmare i certificati di provisioning di un dispositivo dopo aver completato la procedura di produzione. Puoi quindi verificare queste firme per convalidare l'autenticità del dispositivo.

Se un dispositivo viene compromesso prima del provisioning, ti consigliamo di rimuovere il certificato di provisioning corrispondente dal tuo backend Google Cloud, in modo che il dispositivo non possa avviare la procedura per ottenere un certificato completamente attendibile perché non sarà in grado di autenticarsi con la tua CA.

Best practice per l'identità del dispositivo

Questa sezione descrive le best practice per le identità dei dispositivi.

Utilizzare un provider di identità con i broker MQTT

I broker MQTT autenticano i dispositivi edge utilizzando le credenziali del dispositivo fornite da plug-in, database e file. Per gestire le identità dei dispositivi in modo sistematico e scalabile, utilizza un provider di identità (IdP). Il provider di identità gestisce le identità e le credenziali per tutti i dispositivi e funge da fonte di riferimento principale per le identità dei dispositivi.

Per mantenere aggiornata l'identità del dispositivo nel broker MQTT, implementa un livello di integrazione specifico del sistema. Per saperne di più sulla gestione delle credenziali del dispositivo, vedi Provisioning di un dispositivo edge.

Utilizzare le identità digitali della piattaforma IoT come fonte di riferimento

La piattaforma IoT dispone di funzionalità di sicurezza che gestiscono le identità e le credenziali dei dispositivi e autenticano e autorizzano i dispositivi che tentano di accedere alla piattaforma. Queste funzionalità di sicurezza contribuiscono a garantire che solo i dispositivi autorizzati possano accedere alla piattaforma IoT e contribuiscono a garantire l'integrità dei dati.

Verifica che le identità dei dispositivi gestite dalla piattaforma IoT rappresentino la fonte di riferimento principale di tutti i dispositivi gestiti dalla piattaforma IoT. Gli altri componenti di una soluzione IoT che richiedono informazioni sull'identità del dispositivo devono fare affidamento sul sistema di sicurezza della piattaforma IoT. La piattaforma IoT concede diritti di accesso ai dispositivi e propaga eventuali modifiche alla sicurezza in tutta la soluzione IoT.

Best practice per la connettività di rete

Proteggere la connettività di rete è importante per i seguenti motivi:

  • Le reti sicure contribuiscono a garantire che un dispositivo si connetta al backend corretto. Ad esempio, una rete sicura può impedire lo spoofing DNS, un attacco che tenta di reindirizzare i dispositivi per connettersi a un backend compromesso controllato dai malintenzionati.
  • Le reti sicure contribuiscono a garantire che terze parti non possano leggere il traffico di dati. Ad esempio, una rete sicura può impedire un attacco man-in-the-middle, in cui gli autori dell'attacco leggono il traffico tra il tuo dispositivo e il backend.

Utilizza Transport Layer Security (TLS) per proteggere la comunicazione di rete tra i tuoi dispositivi edge e i carichi di lavoro di backend.

Estendi TLS con mTLS per implementare uno schema di autenticazione reciproca che consenta a entrambe le parti connesse di stabilire l'identità reciproca.

Per istruzioni sull'utilizzo di TLS, vedi Architettura del broker MQTT autonomo su Google Cloud e Architettura del prodotto della piattaforma IoT su Google Cloud.

Best practice per la gestione dei certificati per i broker MQTT

Questa sezione descrive le best practice per la gestione dei certificati quando utilizzi i broker MQTT.

Archivia i certificati in modo centralizzato

Archivia e gestisci i certificati server e i certificati dispositivo in una posizione centrale. Nello specifico, assicurati di aver implementato i seguenti controlli:

  • Un inventario di tutti i tuoi dispositivi e dei relativi certificati, nonché degli endpoint server e dei relativi certificati.
  • Informazioni aggiuntive sui certificati, ad esempio la loro validità.
  • Possibilità di aggiungere e rimuovere certificati per i dispositivi in modo che possano connettersi utilizzando nuovi certificati.
  • Diritti di accesso all'archivio centrale dei certificati per limitare le operazioni che i diversi ruoli nel backend possono eseguire con i certificati.

Utilizza una soluzione di archiviazione e gestione dei secret come Secret Manager o HashiCorp Vault. Secret Manager ti consente di gestire le versioni, aggiornare e invalidare le credenziali del dispositivo e di gestire le policy di accesso alle tue credenziali.

Per una piattaforma IoT, implementa l'accesso alle credenziali utilizzando l'accesso all'API Secret Manager.

Proteggere i certificati sui dispositivi perimetrali

Per archiviare certificati e chiavi sui dispositivi edge, utilizza un Trusted Execution Environment o un archivio certificati locale per proteggere le credenziali e bloccare gli accessi non autorizzati. Se devi archiviare materiale segreto sui tuoi dispositivi, criptalo utilizzando tecniche come la crittografia flash� e archivialo su elementi antimanomissione per impedire l'estrazione non autorizzata dei dati.

Sincronizzare l'archivio certificati centrale con l'archivio certificati del broker MQTT

I broker MQTT devono accedere ai certificati client per l'autenticazione basata su certificati, pertanto devi sincronizzare gli archivi certificati dei broker MQTT con l'archivio certificati centrale. Verifica che le modifiche all'archivio certificati centrale, ad esempio l'aggiunta, l'aggiornamento e l'eliminazione dei certificati, siano sincronizzate con l'archivio certificati del broker MQTT. I broker MQTT utilizzano store di certificati come MySQL, PostgresDB e Java Key Store. A seconda del negozio di certificati utilizzato dal broker MQTT, assicurati che esistano i seguenti processi:

  • Un processo che monitora le modifiche nell'archivio centrale dei certificati e invia una notifica al processo di sincronizzazione.
  • Un processo che acquisisce le modifiche nell'archivio certificati centrale e le sincronizza con l'archivio certificati utilizzato dal broker MQTT.

Quando utilizzi Secret Manager come archivio di certificati, puoi utilizzare le notifiche degli eventi come processo di monitoraggio. Puoi implementare il processo di sincronizzazione come listener delle notifiche degli eventi.

Distribuire i certificati ai dispositivi edge in modo sicuro

Quando utilizzi i broker MQTT, distribuisci il certificato radice e i certificati client ai tuoi dispositivi edge. Quando distribuisci i certificati, devi proteggere i tuoi canali di comunicazione in modo che il traffico non venga intercettato.

I principali canali di comunicazione per la distribuzione dei certificati sono i seguenti:

  • Un percorso diretto dal backend IoT ai dispositivi edge tramite i canali di comunicazione esistenti.
  • Un percorso indiretto in cui i dispositivi edge richiedono e scaricano i certificati.

Durante la distribuzione dei certificati, sono necessari i seguenti componenti:

  • Un archivio certificati in cui i certificati vengono gestiti centralmente.
  • Un coordinatore della distribuzione che invia i certificati e monitora il processo di distribuzione per ogni dispositivo edge.
  • Un gestore degli aggiornamenti sul dispositivo edge che riceve o scarica i certificati e li memorizza sul dispositivo.

Distribuisci i certificati durante le procedure di provisioning per i dispositivi edge e quando devi ruotare i certificati.

Durante il processo di provisioning, assicurati che il provisioner abbia accesso diretto ai dispositivi edge tramite canali criptati come SSH e utilizzi strumenti come SCP. Poiché i dispositivi non sono in funzione, puoi inviare i certificati direttamente ai dispositivi edge.

Quando ruoti i certificati, utilizza il broker MQTT come canale di comunicazione tra il coordinatore della distribuzione e i dispositivi edge. Utilizza altri canali per scaricare i certificati sul dispositivo. Per ridurre al minimo l'interruzione dei dispositivi edge in funzione, utilizza un percorso di distribuzione dei certificati indiretto. Il processo consisterebbe nei seguenti passaggi logici:

  1. Il coordinatore della distribuzione acquisisce le credenziali di accesso dall'archivio certificati.
  2. Il coordinatore della distribuzione invia le credenziali di accesso al certificato ai dispositivi perimetrali insieme a informazioni aggiuntive, come l'URL di download.
  3. Il gestore degli aggiornamenti sul dispositivo riceve le credenziali di accesso e memorizza temporaneamente le informazioni e conferma la ricezione.
  4. Il gestore degli aggiornamenti coordina il download del certificato quando il dispositivo non è attivo. Il gestore degli aggiornamenti utilizza le credenziali di accesso per scaricare i certificati dall'archivio delle credenziali.
  5. Una volta scaricati i certificati, il gestore degli aggiornamenti continua con il processo di rotazione dei certificati descritto nella sezione Rotazione dei certificati.

Quando utilizzi Secret Manager come archivio centrale dei certificati, puoi generare token di accesso di breve durata per concedere e limitare l'accesso ai certificati. Per saperne di più, vedi Distribuire in modo sicuro i token di accesso ai dispositivi.

Per impedire che i certificati vengano esposti durante il transito, cripta la connessione tra i dispositivi edge e il broker MQTT. Per saperne di più, consulta le best practice per la connettività di rete.

Ruotare automaticamente i certificati

Per limitare i danni che un certificato esposto può causare, genera certificati con un periodo di validità finito e ruotali prima che scadano. Per implementazioni IoT su larga scala, implementa una procedura di rotazione automatica dei certificati per aggiornare costantemente i tuoi dispositivi con nuovi certificati prima che quelli vecchi scadano. I dispositivi implementati senza certificati validi potrebbero smettere di funzionare, il che può essere costoso da risolvere e influire negativamente sulla funzionalità complessiva della tua soluzione IoT.

I tuoi dispositivi edge devono connettersi in modo bidirezionale al tuo broker MQTT per garantire che possano inviare messaggi al broker MQTT e che possano ricevere messaggi dal broker MQTT.

Durante la rotazione dei certificati, sono necessari i seguenti componenti:

  • Un processo di monitoraggio che esamina regolarmente l'inventario dei certificati e cerca quelli in scadenza. Il processo di monitoraggio attiva la rotazione dei certificati in scadenza.
  • Un processo di rotazione che inizializza e supervisiona la rotazione dei certificati.
  • Un gestore della rotazione dei certificati del dispositivo sul dispositivo edge che comunica con il broker MQTT ed esegue i passaggi di rotazione dei certificati sul dispositivo.

Per ruotare i certificati, la soluzione IoT completa i seguenti passaggi:

  1. Il processo di rotazione invia un messaggio di inizializzazione al dispositivo edge per avviare la rotazione del certificato.
  2. Il gestore della rotazione dei certificati del dispositivo riconosce il messaggio di inizializzazione inviando una risposta al job di rotazione.
  3. Il processo di rotazione richiede un nuovo certificato alla CA. Questa richiesta è simile alla richiesta di provisioning dei certificati, tranne per il fatto che le chiavi e la CSR vengono inviate come messaggi del broker MQTT.
  4. Dopo aver ricevuto il nuovo certificato dalla CA, il job di rotazione distribuisce il certificato all'archivio certificati centrale e al dispositivo edge. Sincronizza anche il certificato con l'archivio certificati del broker MQTT.
  5. Il gestore della rotazione dei certificati del dispositivo memorizza il nuovo certificato e inizializza una nuova connessione con il broker MQTT utilizzando il nuovo certificato.
  6. Una volta stabilita la nuova connessione, il gestore della rotazione dei certificati del dispositivo invia un messaggio di completamento al broker MQTT.
  7. Dopo aver ricevuto il messaggio completato, la procedura di rotazione invalida il vecchio certificato nell'archivio centrale dei certificati.

Per proteggere i certificati inviati durante il processo di rotazione, utilizza argomenti MQTT dedicati. Limita l'accesso a questi argomenti solo al job di rotazione e al dispositivo perimetrale.

Per proteggere il processo di rotazione dei certificati da errori di runtime, attiva la persistenza per le modifiche e lo stato di avanzamento.

Per saperne di più sulla rotazione dei secret utilizzando Secret Manager, consulta Rotazione dei secret.

Best practice per la gestione dei certificati per le piattaforme IoT

Se utilizzi una piattaforma IoT, utilizza i meccanismi di aggiornamento e distribuzione dei certificati forniti dalla piattaforma. Per scopi di backup, puoi esportare regolarmente le credenziali dalla tua piattaforma IoT in un archivio dei secret secondario, ad esempio Secret Manager.

Best practice per l'autenticazione con un broker MQTT

Durante la procedura di autenticazione reciproca, i workload di backend verificano l'identità dei dispositivi edge e i dispositivi edge verificano l'identità dei workload di backend. Dopo che i carichi di lavoro di backend confermano l'identità del dispositivo edge, i carichi di lavoro di backend autorizzano l'accesso del dispositivo alle risorse.

Le sezioni seguenti forniscono best practice per i metodi di autenticazione quando utilizzi i broker MQTT.

Scegliere il metodo di autenticazione per i broker MQTT

Diversi backend IoT supportano metodi di autenticazione diversi. I metodi più comunemente utilizzati sono i seguenti:

  • Autenticazione con nome utente e password, in cui il dispositivo edge presenta il proprio nome utente e la propria password per verificare la sua identità.
  • Autenticazione basata su token, in cui vengono utilizzati token di sicurezza criptati per verificare l'identità del dispositivo edge.
  • Schemi di autenticazione personalizzati, in cui implementi un meccanismo personalizzato per verificare l'identità del dispositivo edge.

Nell'ambito dello standard MQTT, i broker MQTT supportano l'autenticazione con nome utente e password come impostazione predefinita per i pacchetti MQTT CONNECT.

Il pacchetto MQTT CONNECT contiene anche un campo Client Identifier che puoi utilizzare per identificare in modo univoco il client nel broker MQTT. I dispositivi edge inviano il pacchetto MQTT CONNECT al broker MQTT quando stabiliscono una connessione.

Oltre ai campi nome utente, password e identificatore client nel pacchetto MQTT CONNECT, MQTT 5.0 supporta l'autenticazione avanzata che consente di creare flussi di autenticazione challenge-response. MQTT 5.0 consente più scambi di pacchetti AUTH tra il dispositivo edge e il broker MQTT.

Utilizzare gli archivi di password con l'autenticazione tramite nome utente e password

Per l'autenticazione con nome utente e password, configura il broker MQTT in modo che utilizzi un archivio password. Il password store fornisce una posizione centralizzata per la gestione delle password per tutti i dispositivi edge che si connettono al broker MQTT. Per impostazione predefinita, i campi nome utente, password e identificatore client sono facoltativi nella specifica MQTT. Pertanto, progetta il meccanismo di autenticazione in modo da verificare che i campi nome utente, password e identificatore client siano presenti nel pacchetto MQTT CONNECT.

Assicurati che le password siano criptate at-rest e in transito, come segue:

Valuta l'autenticazione basata su token

Con l'autenticazione basata su token, i dispositivi edge inviano un token al broker MQTT per l'autenticazione. I dispositivi possono generare il token autonomamente o ottenerlo da altri servizi di autenticazione. Rispetto alle password, i token hanno una durata breve: sono validi solo per un periodo con una data di scadenza esplicita. Controlla sempre la scadenza quando convalidi i token.

I token web JSON (JWT) sono un modo per implementare l'autenticazione basata su token. I dispositivi edge possono generare il JWT ed eseguire l'autenticazione con il broker MQTT. Il JWT è incorporato nel pacchetto MQTT CONNECT come campo della password.

I vantaggi di JWT sono i seguenti:

  • JWT ti offre la possibilità di scegliere l'algoritmo di crittografia utilizzato per la firma del token. JWT funziona bene con i dispositivi edge con risorse limitate, dove puoi utilizzare un algoritmo di crittografia meno intensivo in termini di risorse, come ECC, per la firma del token.
  • Utilizzando la crittografia con chiave pubblica, la chiave privata viene utilizzata solo sul dispositivo edge e non viene mai condivisa con terze parti. Una chiave privata contribuisce a rendere questo metodo più sicuro dell'autenticazione con nome utente e password, in cui le credenziali vengono inviate tramite la connessione e richiedono la crittografia dei dati.

Valuta schemi di autenticazione personalizzati

Alcuni broker MQTT supportano meccanismi e protocolli di autenticazione diversi. Ad esempio, se il tuo broker MQTT supporta schemi di autenticazione personalizzati, puoi configurarlo per supportare quanto segue:

  • Protocolli di autenticazione standard del settore, ad esempio OpenID Connect, SAML (Security Assertion Markup Language), LDAP, Kerberos, e SASL (Simple Authentication and Security Layer). Questi protocolli delegano l'autenticazione del dispositivo ai tuoi provider di identità esistenti. Alcuni broker MQTT supportano l'autenticazione avanzata e meccanismi di autenticazione estensibili che puoi utilizzare per estendere il broker MQTT in modo da supportare nuovi protocolli e provider di identità.
  • Autenticazione reciproca basata su certificati. Alcuni broker MQTT supportano uno schema di autenticazione reciproca, come l'autenticazione basata su mTLS.

Best practice per controllo dell'accesso e l'autorizzazione dei dispositivi

A causa del pattern di comunicazione publisher/subscriber del protocollo MQTT, il controllo dell'accesso ai dispositivi viene definito utilizzando gli argomenti MQTT. Gli argomenti MQTT controllano il modo in cui un dispositivo può comunicare con il backend IoT. Ogni backend IoT ha implementazioni diverse percontrollo dell'accessoo dell'accesso e l'autorizzazione, quindi consulta la documentazione del backend IoT per le opzioni su come configurare gli argomenti MQTT.

Utilizzare service account a scopo specifico per accedere alle risorse Google Cloud

L'accesso alle Google Cloud risorse è gestito da policy di autorizzazione IAM che associano la concessione dell'accesso alle risorse a un insieme di entità. Le entità tipiche sono account utente, service account e gruppi. I service account vengono in genere utilizzati da un'applicazione o da un workload di computing per effettuare chiamate API autorizzate per le risorse cloud. I service account consentono ai dispositivi perimetrali IoT di accedere alle risorse cloud.

Poiché l'identità del dispositivo è gestita dal backend IoT, devi mappare un'identità tra il backend IoT e IAM in modo che il dispositivo edge possa accedere alle risorseGoogle Cloud .

Se gestisci un ampio insieme di dispositivi, il limite al numero di service account per ogni progetto Google Cloud rende impossibile avere una mappatura diretta uno a uno tra dispositivoaccount di serviziount.

Crea invece service account collegati alle risorse cloud a cui la tua soluzione IoT deve accedere, come descritto in Creazione di service account monouso. Ad esempio, crea un account di servizio univoco per ciascuno dei seguenti casi d'uso:

  • Download dei pacchetti di aggiornamento software
  • Caricare file multimediali di grandi dimensioni
  • Importazione di dati da un flusso di latenza

Per implementare il principio del privilegio minimo, assicurati che ogni account di servizio disponga solo dei diritti di accesso sufficienti per supportare il suo caso d'uso. Ad esempio, per un account di servizio utilizzato per scaricare pacchetti software, concedi solo l'accesso in lettura al bucket Cloud Storage.

Distribuire in modo sicuro i token di accesso ai dispositivi

In genere, i dispositivi periferici comunicano con la piattaforma IoT utilizzando MQTT. Tuttavia, per casi d'uso specifici, i tuoi dispositivi potrebbero richiedere l'accesso diretto alle risorseGoogle Cloud . Ad esempio, prendi in considerazione quanto segue:

  • Per scaricare i contenuti, un dispositivo edge richiede l'accesso di sola lettura a un bucket Cloud Storage solo durante il processo di download.
  • Per caricare i dati in un bucket Cloud Storage, un dispositivo edge richiede l'accesso in scrittura al bucket.

Per questi casi d'uso, utilizza la federazione delle identità per i carichi di lavoro, in cui l'accesso alle risorse Google Cloud viene concesso tramite token di accesso. La federazione delle identità per i workload elimina la necessità di eseguire il provisioning di credenziali specifiche per il cloud sui dispositivi edge e la distribuzione dell'accesso viene eseguita in modo dinamico in base alla domanda.

Per distribuire token di accesso per le risorse cloud ai tuoi dispositivi, configura la federazione delle identità dei carichi di lavoro tra il provider di identità del dispositivo e Google Cloud. Per supportare la federazione delle identità per i workload, assicurati che il backend IoT soddisfi i requisiti della federazione delle identità per i workload e segua le best practice di sicurezza che corrispondono ai tuoi casi d'uso.

Per accedere alle risorse Google Cloud utilizzando la federazione delle identità per i carichi di lavoro, i tuoi dispositivi edge devono implementare il flusso di lavoro OAuth 2.0 Token Exchange, che prevede i seguenti passaggi:

  • Il dispositivo chiama il Security Token Service e fornisce le proprie credenziali del dispositivo.
  • Il servizio token di sicurezza verifica l'identità del dispositivo edge convalidando le credenziali fornite dal dispositivo con il provider di identità del dispositivo.
  • Se la verifica dell'identità ha esito positivo, il servizio token di sicurezza restituisce un token di accesso al dispositivo edge.
  • Il dispositivo edge utilizza questo token per rappresentare l'account di servizio monouso e ottiene un token di accesso OAuth 2.0 di breve durata.
  • Il dispositivo utilizza il token di accesso OAuth 2.0 di breve durata per l'autenticazione con le API Google Cloud e per accedere alle risorse cloud richieste.

Per limitare l'accesso del token di accesso di breve durata a bucket e oggetti specifici in Cloud Storage, utilizza i confini di accesso delle credenziali. I limiti di accesso alle credenziali ti consentono di limitare l'accesso alle credenziali di breve durata e ridurre al minimo il numero di risorse esposte nei bucket Cloud Storage quando un token di accesso viene compromesso.

La federazione delle identità per i workload è un modo scalabile per distribuire in modo sicuro l'accesso al cloud ai dispositivi edge. Per saperne di più sull'autenticazione, vedi Autenticazione su Google.

Monitorare e controllare l'accesso alle risorse cloud

Abilita Cloud Audit Logs per creare voci di log quando i tuoi dispositivi edge accedono alle risorse cloud tramite richieste API autenticate. Cloud Audit Logs ti consente di monitorare le azioni critiche eseguite dai tuoi dispositivi edge suGoogle Cloud. Inoltre, Cloud Audit Logs crea le tracce di controllo e i log necessari per esaminare eventuali problemi. Per ulteriori informazioni, vedi Eseguire l'impersonificazione di un account di servizio per accedere a Google Cloud.

Passaggi successivi

Collaboratori

Autori:

  • Charlie Wang | Cloud Solutions Architect
  • Marco Ferrari | Cloud Solutions Architect