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

Last reviewed 2023-02-08 UTC

Questo documento fornisce le best practice di 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 periferici ad altre risorse. Questo documento è incentrato 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:

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

Architettura IoT

Un'architettura IoT include servizi che consentono di eseguire il provisioning e la gestione delle credenziali dei dispositivi, di autenticare e controllo dell'accesso l'accesso ai dispositivi periferici e di consentire a questi ultimi di accedere alle risorse di Google Cloud. Questo documento illustra 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 sono l'identità dei dispositivi e la gestione dei dispositivi. Le piattaforme IoT forniscono queste funzionalità come parte del loro sistema, mentre i broker MQTT richiedono che tu fornisca queste funzionalità.

Il seguente diagramma descrive l'architettura IoT.

dell'architettura di backend IoT.

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

  1. Provisioning del certificato, che è il processo che devi completare per preparare un dispositivo periferico per la configurazione.

  2. Autenticazione e autorizzazione, che includono lo schema di autenticazione utilizzato dal dispositivo periferico e dal broker MQTT o dalla piattaforma IoT per l'autenticazione reciproca.

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

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

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

  • Un dispositivo periferico (ad esempio un dispositivo medico) di cui esegui il deployment sui perimetri dell'ambiente e che si trova geograficamente vicino ai dati che vuoi elaborare. I dispositivi perimetrali si connettono in modo bidirezionale con il 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 consentire ai dispositivi periferici di connettersi tramite il protocollo MQTT. I broker MQTT non dispongono di funzionalità per la gestione delle identità e dei dispositivi e si affidano a sistemi esterni per fornirle.
    • Una piattaforma IoT è un'applicazione cloud con cui i dispositivi periferici si connettono e con cui comunicano. Le piattaforme IoT offrono un'interfaccia sicura con cui i dispositivi perimetrali possono connettersi tramite il protocollo MQTT. Ogni piattaforma IoT dispone di una propria implementazione di sicurezza che determina il modo in cui autentica e autorizza i dispositivi periferici e come gestisce le identità dei dispositivi.
  • Un archivio centrale dei certificati che ospita i certificati per tutti i dispositivi periferici.
  • Risorse cloud a cui devono accedere i dispositivi periferici.

Provisioning di un dispositivo periferico

Prima che un dispositivo periferico possa connettersi ai carichi di lavoro di backend, devi eseguire il provisioning di un certificato per il dispositivo periferico. Esistono due scenari principali in cui viene deciso il provisioning del certificato:

  • Se la tua soluzione è basata su dispositivi commerciali generici, hai il pieno controllo del processo di provisioning dopo l'acquisto del dispositivo.

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

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

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

  1. Genera la coppia di chiavi pubblica-privata utilizzando una soluzione di sicurezza basata su hardware supportata dal tuo dispositivo, come un Secure Element (SE) o un modulo hardware di sicurezza (HSM). Per progettazione, SE o HSM archivia le chiavi private localmente e le chiavi private non vengono mai esposte all'esterno. 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. Per ulteriori informazioni, consulta Utilizzare una chiave generata automaticamente.

  2. Firma e genera un certificato del dispositivo. Dopo aver generato la coppia di chiavi pubblica-privata, scarica la chiave pubblica, crea una richiesta di firma del certificato (CSR) e inviala alla CA per la firma. La CA genera un certificato dispositivo collegato alla CA radice. Per ulteriori informazioni, consulta la pagina relativa all'utilizzo di una richiesta di firma del certificato. Quando utilizzi chiavi generate automaticamente, puoi richiedere un certificato del dispositivo direttamente alla CA.

  3. Installa il certificato del dispositivo firmato sul dispositivo periferico e invialo a un repository di certificati centrale, come Secret Manager.

Per ulteriori informazioni, consulta Come eseguire il deployment di un'infrastruttura a chiave pubblica sicura e affidabile con Google Cloud CA Service (PDF).

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

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

  • Il certificato CA radice fornisce la radice per la 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, mentre i dispositivi periferici utilizzano il certificato radice per convalidare il certificato del server. Devi distribuire il certificato radice sia nel backend IoT che sui dispositivi perimetrali.

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

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

Procedura per generare un certificato dispositivo utilizzando un HSM o SE

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

Procedura per la generazione di un certificato per il dispositivo.

In questo diagramma si verificano i seguenti passaggi:

  1. Il dispositivo periferico genera la coppia di chiavi pubblica nell'hardware.
  2. Scarica la chiave pubblica e crea la relativa richiesta di firma del certificato.
  3. Devi inviare la richiesta di firma del certificato all'autorità di certificazione per richiedere un certificato.
  4. La CA completa le seguenti azioni:
    1. Firma il certificato.
    2. Restituisce il certificato del dispositivo al provisioner.
  5. Il provisioner completa le seguenti azioni:
    1. Invia il certificato al dispositivo periferico.
    2. Archivia il certificato nell'archivio certificati centrale.
  6. Il dispositivo periferico archivia il certificato in una posizione sicura.

Procedura per generare un certificato dispositivo utilizzando la CA

Il seguente diagramma mostra come viene eseguito il provisioning di un certificato del dispositivo quando si utilizza una CA.

Procedura per la generazione di un certificato per il dispositivo.

In questo diagramma si verificano i seguenti passaggi:

  1. Devi generare una richiesta di firma del certificato e inviarla all'autorità di certificazione per richiedere un certificato.
  2. La CA completa le seguenti azioni:
    1. Genera una coppia di chiavi pubblica e firma la chiave pubblica.
    2. Restituisce il certificato del dispositivo e la chiave privata al provisioner.
  3. Completa le seguenti azioni:
    1. Invia il certificato e la chiave privata al dispositivo periferico.
    2. Archivia il certificato e la chiave privata nell'archivio certificati centrale.
  4. Il dispositivo periferico archivia il certificato in una posizione sicura.

Best practice per l'identità del dispositivo

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

Utilizza un provider di identità con broker MQTT

I broker MQTT eseguono l'autenticazione dei dispositivi periferici 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). L'IdP gestisce le identità e le credenziali per tutti i dispositivi e funge da fonte attendibile per le identità dei dispositivi.

Per mantenere aggiornata l'identità del dispositivo nel broker MQTT, implementa un livello di integrazione specifico del sistema. Per ulteriori informazioni sulla gestione delle credenziali del dispositivo, consulta Provisioning di un dispositivo periferico.

Utilizzare le identità digitali della piattaforma IoT come fonte attendibile

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 attendibile principale di tutti i dispositivi gestiti dalla piattaforma IoT. Altri componenti di una soluzione IoT che richiedono informazioni sull'identità del dispositivo dovrebbero basarsi sul sistema di sicurezza della piattaforma IoT. La piattaforma IoT concede i diritti di accesso ai dispositivi e propaga eventuali modifiche alla sicurezza nell'intera 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 giusto. Ad esempio, una rete sicura può prevenire lo spoofing DNS, ovvero un attacco che tenta di deviare i dispositivi per connettersi a un backend non autorizzato controllato da utenti malintenzionati.
  • Le reti sicure fanno sì che terze parti non possano leggere il tuo traffico di dati. Ad esempio, una rete sicura può impedire un attacco con attacco hacker in the middle, in cui gli utenti malintenzionati leggono il traffico tra il tuo dispositivo e il backend.

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

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

Per istruzioni sull'utilizzo di TLS, consulta Architettura di broker MQTT autonoma su Google Cloud e Architettura dei prodotti 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 si utilizzano broker MQTT.

Archivia i certificati a livello centrale

Archivia e gestisci i certificati server e i certificati dei dispositivi in una posizione centrale. In particolare, assicurati di disporre dei seguenti controlli:

  • Un inventario di tutti i tuoi dispositivi e dei relativi certificati, degli endpoint del server e dei relativi certificati.
  • Informazioni aggiuntive sui certificati, come la loro validità.
  • La possibilità di aggiungere e rimuovere certificati per i dispositivi in modo che possano connettersi utilizzando nuovi certificati.
  • Diritti di accesso all'archivio certificati centrale, per limitare ciò che i diversi ruoli nel backend possono fare con i certificati.

Usa una soluzione di archiviazione e gestione dei secret, come Secret Manager o HashiCorp Vault. Secret Manager consente di modificare, aggiornare e invalidare le credenziali del dispositivo e di gestire i criteri 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 periferici

Per archiviare certificati e chiavi sui dispositivi periferici, utilizza un ambiente di esecuzione attendibile o un archivio certificati locale per proteggere le credenziali e bloccare gli accessi non autorizzati. Se devi archiviare un materiale segreto sui tuoi dispositivi, cripta il materiale utilizzando tecniche come la crittografia flash e archivialo su elementi a prova di manomissione per impedire l'estrazione non autorizzata dei dati.

Sincronizza 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, perciò devi sincronizzare gli archivi certificati dei broker MQTT con l'archivio certificati centrale. Verifica che le modifiche all'archivio certificati centrale, come l'aggiunta, l'aggiornamento e l'eliminazione di certificati, siano sincronizzate con l'archivio certificati del broker MQTT. I broker MQTT utilizzano archivi di certificati come MySQL, PostgresDB e Java Key Store. A seconda dell'archivio certificati utilizzato dal broker MQTT, assicurati che esistano i seguenti processi:

  • Un processo che monitora le modifiche nell'archivio certificati centrale e notifica il processo di sincronizzazione.
  • Un processo che apporta modifiche nell'archivio certificati centrale e sincronizza le modifiche nell'archivio certificati centrale con l'archivio certificati utilizzato dal broker MQTT.

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

Distribuisci i certificati ai dispositivi periferici in modo sicuro

Quando utilizzi broker MQTT, distribuisci il certificato radice e i certificati client ai dispositivi periferici. 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 periferici attraverso canali di comunicazione esistenti.
  • Un percorso indiretto in cui i dispositivi periferici richiedono e scaricano i certificati.

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

  • Un archivio certificati in cui i certificati sono gestiti centralmente.
  • Un coordinatore della distribuzione che invia i certificati e tiene traccia del processo di distribuzione per ciascun dispositivo periferico.
  • Un gestore degli aggiornamenti sul dispositivo periferico che riceve o scarica i certificati e li archivia sul dispositivo.

Distribuisci i certificati durante i processi di provisioning per i dispositivi periferici e quando è necessario ruotare i certificati.

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

Durante la rotazione dei certificati, utilizza il broker MQTT come canale di comunicazione tra il coordinatore della distribuzione e i dispositivi periferici. Utilizza altri canali per scaricare i certificati sul dispositivo. Per ridurre al minimo l'interruzione del funzionamento dei dispositivi periferici, utilizza un percorso di distribuzione indiretto dei certificati. La procedura 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 periferici 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 credenziali.
  5. Una volta scaricati i certificati, il gestore degli aggiornamenti continua il processo di rotazione dei certificati descritto nella sezione relativa alla rotazione dei certificati.

Quando utilizzi Secret Manager come archivio certificati centrale, puoi generare token di accesso di breve durata per concedere e limitare l'accesso ai certificati. Per maggiori informazioni, consulta Distribuire i token di accesso ai dispositivi in modo sicuro.

Per evitare che i certificati vengano esposti durante il transito, cripta la connessione tra i dispositivi periferici e il broker MQTT. Per ulteriori informazioni, consulta le best practice per la connettività di rete.

Ruota automaticamente i certificati

Per limitare i danni che un certificato esposto può causare, genera certificati con un periodo di validità limitato e ruotali prima che scadano. Per deployment IoT su larga scala, implementa una procedura di rotazione automatica dei certificati per aggiornare in modo coerente i dispositivi con nuovi certificati prima della scadenza di quelli precedenti. I dispositivi di cui è stato eseguito il deployment senza certificati validi ne impediscono il funzionamento, il che può essere costoso da risolvere e influire negativamente sulla funzionalità complessiva della tua soluzione IoT.

I dispositivi periferici devono connettersi in modo bidirezionale con il broker MQTT per assicurarsi 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 analizza periodicamente l'inventario dei certificati e cerca i certificati 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 periferico che comunica con il broker MQTT ed esegue passaggi di rotazione del certificato 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 periferico per avviare la rotazione del certificato.
  2. Il gestore della rotazione dei certificati del dispositivo conferma il messaggio di inizializzazione inviando una risposta al job di rotazione.
  3. Il processo di rotazione richiede un nuovo certificato all'autorità di certificazione. Questa richiesta è simile alla richiesta di provisioning dei certificati, con la differenza che le chiavi e la richiesta di firma del certificato vengono inviati come messaggi broker MQTT.
  4. Dopo aver ricevuto il nuovo certificato dalla CA, il job di rotazione distribuisce il certificato nell'archivio certificati centrale e sul dispositivo perimetrale. Inoltre, sincronizza il certificato con l'archivio certificati del broker MQTT.
  5. Il gestore della rotazione del certificato del dispositivo archivia il nuovo certificato e inizializza una nuova connessione con il broker MQTT utilizzando il nuovo certificato.
  6. Dopo aver stabilito la nuova connessione, il gestore della rotazione del certificato del dispositivo invia un messaggio completato al broker MQTT.
  7. Dopo aver ricevuto il messaggio completato, il processo di rotazione invalida il vecchio certificato nell'archivio certificati centrale.

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

Per proteggere il processo di rotazione dei certificati da errori di runtime, abilita la persistenza per le modifiche e l'avanzamento.

Per maggiori informazioni sulla rotazione dei secret mediante Secret Manager, consulta Rotazione dei secret.

Best practice per la gestione dei certificati per le piattaforme IoT

Se usi una piattaforma IoT, usa i meccanismi di aggiornamento e distribuzione dei certificati forniti dalla piattaforma. A scopo di backup, puoi esportare regolarmente le credenziali dalla tua piattaforma IoT in uno spazio di archiviazione dei secret secondario, ad esempio Secret Manager.

Best practice per l'autenticazione con un broker MQTT

Durante il processo di autenticazione reciproca, i carichi di lavoro di backend verificano l'identità dei dispositivi periferici, mentre i dispositivi periferici verificano l'identità dei carichi di lavoro di backend. Dopo che i carichi di lavoro di backend confermano l'identità del dispositivo periferico, i carichi di lavoro di backend autorizzano il dispositivo ad accedere alle risorse.

Le seguenti sezioni forniscono le best practice per i metodi di autenticazione quando si utilizzano broker MQTT.

Scegli il metodo di autenticazione per i broker MQTT

I vari backend IoT supportano metodi di autenticazione differenti. Di seguito sono riportati i metodi più comunemente utilizzati:

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

Nell'ambito dello standard MQTT, i broker MQTT supportano l'autenticazione di 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 per il broker MQTT. I dispositivi periferici 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 periferico e il broker MQTT.

Utilizza archivi di password con autenticazione di nome utente e password

Per l'autenticazione di nome utente e password, configura il broker MQTT in modo che utilizzi un archivio delle password. L'archivio delle password fornisce una posizione centralizzata per la gestione delle password per tutti i dispositivi periferici che si connettono al broker MQTT. Per impostazione predefinita, i campi nome utente, password e identificatore client sono facoltativi nella specifica MQTT. Progetta quindi il tuo meccanismo di autenticazione per 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:

Considera l'autenticazione basata su token

Con l'autenticazione basata su token, i dispositivi periferici inviano un token al broker MQTT per eseguire l'autenticazione. I dispositivi possono generare il token autonomamente o riceverlo da altri servizi di autenticazione. Rispetto alle password, i token sono di breve durata: i token sono validi solo per un periodo con una data di scadenza esplicita. Verifica sempre la scadenza al momento della convalida dei token.

I token web JSON (JWT) consentono di implementare l'autenticazione basata su token. I dispositivi periferici possono generare JWT e autenticarsi con il broker MQTT. Il JWT è incorporato nel pacchetto MQTT CONNECT come campo della password.

I vantaggi del JWT sono i seguenti:

  • JWT consente di scegliere l'algoritmo di crittografia utilizzato per la firma del token. JWT funziona bene con dispositivi periferici vincolati, in cui è possibile utilizzare un algoritmo di crittografia meno elevato, come ECC, per la firma del token.
  • Utilizzando la crittografia a chiave pubblica, la chiave privata viene utilizzata solo sul dispositivo periferico e non viene mai condivisa con altre parti. La chiave privata contribuisce a rendere questo metodo più sicuro rispetto all'autenticazione basata su nome utente e password, che prevede l'invio delle credenziali tramite la connessione e richiede la crittografia dei dati.

Considerare schemi di autenticazione personalizzati

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

  • Protocolli di autenticazione standard del settore come OpenID Connect, Security Assertion Markup Language (SAML), LDAP, Kerberos e Simple Authentication and Security Layer (SASL). Questi protocolli delegano l'autenticazione dei dispositivi ai provider di identità esistenti. Alcuni broker MQTT supportano l'autenticazione avanzata ed i meccanismi di autenticazione estensibili che possono essere utilizzati per estendere il broker MQTT al fine di supportare nuovi protocolli e provider di identità.
  • Autenticazione reciproca basata su certificati. Alcuni broker MQTT supportano uno schema di autenticazione reciproca, ad esempio l'autenticazione basata su mTLS.

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

A causa del modello di comunicazione di publisher e sottoscrittore del protocollo MQTT, il controllo dell'accesso dei dispositivi viene definito utilizzando gli argomenti MQTT. Gli argomenti MQTT controllano in che modo un dispositivo può comunicare con il tuo backend IoT. Ogni backend IoT ha implementazioni diverse per controllo dell'accesso dell'accesso e l'autorizzazione, quindi consulta la documentazione relativa al backend IoT per informazioni sulle opzioni di configurazione degli argomenti MQTT.

Usa account di servizio a uso specifico per accedere alle risorse Google Cloud

L'accesso alle risorse Google Cloud è gestito dai criteri di autorizzazione IAM che associano il margine di accesso alle risorse a un insieme di entità. Le entità tipiche sono account utente, account di servizio e gruppi. Gli account di servizio sono generalmente utilizzati da un'applicazione o da un carico di lavoro di computing per effettuare chiamate API autorizzate per le risorse cloud. Gli account di servizio consentono ai dispositivi periferici 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 periferico possa accedere alle risorse Google Cloud.

Se gestisci un numero elevato di dispositivi, il limite del numero di account di servizio per ogni progetto Google Cloud rende impossibile la mappatura diretta one-to-one tra il dispositivo e l'account di servizio.

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

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

Per implementare il privilegio minimo, assicurati che ogni account di servizio disponga solo dei diritti di accesso sufficienti per supportare il relativo 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.

Distribuisci i token di accesso ai dispositivi in modo sicuro

In genere, i dispositivi periferici comunicano con la tua piattaforma IoT utilizzando MQTT. Tuttavia, per casi d'uso specifici, i dispositivi potrebbero richiedere l'accesso diretto alle risorse Google Cloud. Prendi in considerazione quanto segue:

  • Per scaricare contenuti, un dispositivo periferico 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 periferico 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 carichi di lavoro elimina la necessità di eseguire il provisioning di credenziali specifiche per il cloud sui dispositivi periferici e la distribuzione degli accessi viene eseguita dinamicamente in base alla domanda.

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

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

  • Il dispositivo chiama il Security Token Service e fornisce le proprie credenziali.
  • Il servizio token di sicurezza verifica l'identità del dispositivo periferico convalidando le credenziali che il dispositivo periferico ha fornito al provider di identità.
  • Se la verifica dell'identità ha esito positivo, il Security Token Service restituisce un token federato al dispositivo periferico.
  • Il dispositivo periferico utilizza il token federato per rappresentare l'account di servizio a uso specifico e ottiene un token di accesso OAuth 2.0 di breve durata.
  • Il dispositivo utilizza il token di accesso OAuth 2.0 a breve durata per eseguire l'autenticazione con le API Google Cloud e ottenere l'accesso 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 limiti di accesso alle credenziali. I confini di accesso alle credenziali consentono di limitare l'accesso delle 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 carichi di lavoro è un modo scalabile per distribuire in modo sicuro l'accesso cloud ai dispositivi periferici. Per ulteriori informazioni sull'autenticazione, consulta la pagina Autenticazione su Google.

Monitora e controlla l'accesso alle risorse cloud

Abilita Cloud Audit Logs per creare voci di log quando i tuoi dispositivi periferici accedono alle risorse cloud tramite richieste API autenticate. Cloud Audit Logs consente di monitorare le azioni critiche eseguite dai tuoi dispositivi periferici su Google Cloud. Inoltre, Cloud Audit Logs crea le tracce di controllo e i log necessari per analizzare eventuali problemi. Per maggiori informazioni, consulta Impersonare un account di servizio per accedere a Google Cloud.

Passaggi successivi