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

Last reviewed 2024-05-31 UTC

Questo documento fornisce best practice per la sicurezza per la gestione e l'esecuzione di un backend di 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 le best practice per il provisioning e la gestione delle credenziali dei dispositivi, l'autenticazione e l'accesso ai dispositivi edge di controllo e la possibilità per i dispositivi edge IoT di accedere alle risorse Google Cloud.

Architettura IoT

Un'architettura IoT include servizi che ti 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 illustra due architetture di backend IoT: una che utilizza il broker MQTT e l'altra una piattaforma IoT. Le principali differenze di sicurezza tra questi due backend sono l'identità e la gestione dei dispositivi. Le piattaforme IoT forniscono queste funzionalità come parte del loro sistema, mentre i broker MQTT richiedono che tu le fornisca.

Il seguente diagramma descrive l'architettura IoT.

Architettura di backend IoT.

L'architettura mostra i servizi necessari per le tre seguenti procedure:

  1. Il provisioning dei certificati, ovvero la procedura che devi completare per preparare un dispositivo edge alla 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 tra loro.

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

Questo documento è incentrato 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) di cui esegui il deployment ai confini 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 messaggi al backend IoT e ricevere messaggi da questo.
  • 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 delle funzionalità per l'identità e la gestione dei dispositivi e si affidano a 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 la propria implementazione di sicurezza che determina in che modo autentica e autorizza i dispositivi edge e come gestisce le loro identità.
  • Un archivio certificati centrale che ospita i certificati per tutti i dispositivi edge.
  • Risorse cloud a cui devono accedere i dispositivi edge.

Eseguire il provisioning di un dispositivo Edge

Prima che un dispositivo edge possa connettersi ai tuoi workload di backend, devi eseguire il provisioning di un certificato per il dispositivo edge. Esistono due scenari principali che determinano il modo in cui esegui il provisioning del certificato:

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

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

In entrambi gli scenari, devi creare certificati del dispositivo con una catena di attendibilità che rimandi 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 sul dispositivo siano eseguiti da utenti 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à:

  1. Genera la coppia di chiavi pubblica/privata utilizzando una soluzione di sicurezza basata su hardware supportata dal tuo dispositivo, ad esempio un elemento di sicurezza (SE) o un modulo di sicurezza hardware (HSM). Per impostazione predefinita, l'SE o l'HSM memorizza le chiavi private localmente e queste 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 l'autorità di certificazione 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 all'autorità di certificazione per la firma. La CA genera un certificato del dispositivo collegato alla CA radice. Per ulteriori informazioni, consulta la sezione Utilizzare un CSR. Quando utilizzi chiavi generate automaticamente, puoi richiedere un certificato dispositivo direttamente all'autorità di certificazione.

  3. Installa il certificato del dispositivo firmato sul dispositivo edge e invialo a un repository di certificati centralizzato come Secret Manager.

Per saperne di più, consulta Come implementare un'infrastruttura a chiave pubblica sicura e affidabile con il servizio CA di Google Cloud (PDF).

Per informazioni su altre best practice per il 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 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 e i dispositivi edge utilizzano il certificato radice per convalidare il certificato del server. Devi distribuire il certificato radice sia al backend IoT sia ai dispositivi edge.

  • I certificati del server vengono utilizzati per proteggere gli endpoint esposti dal backend IoT. Disponi di certificati del server per i diversi algoritmi di crittografia che i tuoi endpoint devono supportare. I certificati del server sono collegati alla CA radice. Un gestore delle chiavi gestisce e archivia sia le parti private che quelle pubbliche dei certificati del 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 di cui disponi 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 la generazione di 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 la generazione di un certificato del dispositivo.

In questo diagramma vengono eseguiti i seguenti passaggi:

  1. Il dispositivo perimetrale genera la coppia di chiavi pubbliche nell'hardware.
  2. Scarichi la chiave pubblica e crei la richiesta di firma del certificato (CSR).
  3. Invii la CSR 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 provisioning.
  5. Il provisioning esegue le seguenti azioni:
    1. Invia il certificato al dispositivo edge.
    2. Memorizza il certificato nell'archivio certificati centrale.
  6. Il dispositivo edge 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 si utilizza un'autorità di certificazione.

Procedura per la generazione di un certificato del dispositivo.

In questo diagramma vengono eseguiti i seguenti passaggi:

  1. Generi una CSR e la invii alla CA 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 provisioning.
  3. Completa le seguenti azioni:
    1. Invia il certificato e la chiave privata al dispositivo edge.
    2. Memorizza il certificato e la chiave privata nell'archivio dei certificati centrale.
  4. Il dispositivo edge memorizza il certificato in una posizione sicura.

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). L'IdP gestisce le identità e le credenziali di tutti i dispositivi e funge da fonte di verità principale per le identità dei dispositivi.

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

Utilizza 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, nonché 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 basarsi sul sistema di sicurezza della piattaforma IoT. La piattaforma IoT concede i diritti di accesso ai dispositivi e propaga eventuali modifiche alla sicurezza in tutta la soluzione IoT.

Best practice per la connettività di rete

La sicurezza della 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 il DNS spoofing, che è un attacco che tenta di reindirizzare i dispositivi a connettersi a un backend malintenzionato controllato da malintenzionati.
  • Le reti sicure contribuiscono a garantire che terze parti non possano leggere il tuo traffico di dati. Ad esempio, una rete sicura può impedire un attacco man-in-the-middle, in cui gli utenti malintenzionati leggono il traffico tra il dispositivo e il backend.

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

Estendere TLS con mTLS per implementare uno schema di autenticazione reciproca che consenta a entrambe le parti in connessione di stabilire l'identità l'una dell'altra.

Per istruzioni sull'utilizzo di TLS, consulta 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 si utilizzano broker MQTT.

Memorizza i certificati in modo centralizzato

Memorizza e gestisci i certificati del server e i certificati dei dispositivi in un'unica posizione. In particolare, assicurati di aver implementato i seguenti controlli:

  • Un inventario di tutti i tuoi dispositivi e dei relativi certificati, nonché degli endpoint del server e dei relativi certificati.
  • Informazioni aggiuntive sui certificati, ad esempio 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 dei certificati centrali 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 consente di eseguire il versionamento, l'aggiornamento e l'invalidazione delle credenziali del dispositivo, nonché di gestire i criteri di accesso alle 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 locale o un archivio certificati per proteggere la credenziale 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 a prova di manomissione per contribuire a impedire l'estrazione di dati non autorizzata.

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 store dei certificati dei broker MQTT con lo store dei certificati centrale. Verifica che le modifiche all'archivio certificati centrale, come l'aggiunta, l'aggiornamento ed l'eliminazione dei certificati, siano sincronizzate con l'archivio certificati del broker MQTT. I broker MQTT utilizzano magazzini di certificati come MySQL, PostgresDB e Java Key Store. A seconda del magazzino dei certificati utilizzato dal tuo broker MQTT, assicurati che esistano le seguenti procedure:

  • Un processo che monitora le modifiche nell'archivio dei certificati centrali e notifica il processo di sincronizzazione.
  • Un processo che prende le modifiche nello store dei certificati centrali e le sincronizza con lo store dei certificati utilizzato dal broker MQTT.

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

Distribuire i certificati ai dispositivi edge in modo sicuro

Quando utilizzi 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:

  • 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 la procedura di distribuzione per ogni dispositivo edge.
  • Un handler di aggiornamento 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 ruotarli.

Durante la procedura di provisioning, assicurati che il provisioning 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 esegui la rotazione dei 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. La procedura prevede i 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 edge insieme a informazioni aggiuntive, come l'URL di download.
  3. Il gestore dell'aggiornamento sul dispositivo riceve le credenziali di accesso, memorizza temporaneamente le informazioni e conferma la ricezione.
  4. Il gestore dell'aggiornamento coordina il download del certificato quando il dispositivo non è attivo. Il gestore dell'aggiornamento utilizza le credenziali di accesso per scaricare i certificati dall'archivio delle credenziali.
  5. Dopo aver scaricato i certificati, il gestore dell'aggiornamento continua con la procedura di rotazione dei certificati descritta nella sezione Rotazione dei certificati.

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

Per contribuire a impedire l'esposizione dei certificati durante il transito, cripta la connessione tra i tuoi dispositivi edge e il broker MQTT. Per saperne di più, consulta le best practice per la connettività di rete.

Ruotare i certificati automaticamente

Per limitare i danni che un certificato esposto può causare, genera certificati con un periodo di validità limitato e ruotali prima che scadano. Per gli implementazioni IoT su larga scala, implementa una procedura di rotazione automatica dei certificati per aggiornare in modo coerente i dispositivi con i nuovi certificati prima della scadenza di quelli vecchi. I dispositivi di cui è stato eseguito il deployment senza certificati validi possono smettere di funzionare, il che può comportare costi elevati per la correzione e influire negativamente sulla funzionalità complessiva della tua soluzione IoT.

I dispositivi edge devono connettersi in modo bidirezionale al broker MQTT per assicurarsi di poter inviare messaggi al broker MQTT e di poter 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 inizia e supervisiona la rotazione dei certificati.
  • Un gestore della rotazione dei certificati del dispositivo sul dispositivo edge che comunicata 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 dei certificati.
  2. Il gestore della rotazione dei certificati del dispositivo conferma il messaggio di inizializzazione inviando una risposta al job di rotazione.
  3. La procedura di rotazione richiede un nuovo certificato dall'autorità di certificazione. Questa richiesta è simile alla richiesta di provisioning del certificato, tranne per il fatto che le chiavi e la CSR vengono inviate come messaggi del broker MQTT.
  4. Dopo aver ricevuto il nuovo certificato dall'autorità di certificazione, il job di rotazione lo distribuisce all'archivio certificati centrale e al dispositivo edge. Sincronizza inoltre 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. Dopo aver stabilito la nuova connessione, l'handler di rotazione dei certificati del dispositivo invia un messaggio completato al broker MQTT.
  7. Dopo aver ricevuto il messaggio di completamento, la procedura di rotazione invalida il vecchio certificato nell'archivio dei certificati centrali.

Per contribuire a 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 edge.

Per contribuire a proteggere il processo di rotazione dei certificati da errori di runtime, attiva la persistenza per le modifiche e l'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 il backup, puoi esportare regolarmente le credenziali dalla tua piattaforma IoT in uno spazio di archiviazione di secret secondario, come Secret Manager.

Best practice per l'autenticazione con un broker MQTT

Durante la procedura di autenticazione reciproca, i carichi di lavoro di backend verificano l'identità dei dispositivi edge e questi ultimi verificano l'identità dei carichi di lavoro di backend. Dopo che i carichi di lavoro di backend hanno confermato l'identità del dispositivo edge, questi autorizzino 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 diversi backend IoT supportano metodi di autenticazione diversi. I metodi più comunemente utilizzati sono i seguenti:

  • Autenticazione tramite nome utente e password, in cui il dispositivo edge presenta il proprio nome utente e la propria password per verificare la propria 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 tramite 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 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 la autenticazione avanzata che consente di creare flussi di autenticazione a sfida e risposta. MQTT 5.0 consente più scambi di pacchetti tra il dispositivo edge e il broker MQTT.AUTH

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

Per l'autenticazione tramite nome utente e password, configura il broker MQTT in modo che utilizzi un deposito delle password. L'archivio delle password fornisce una posizione centralizzata per gestire le password di 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 sia quando sono inattive che in transito, come segue:

Valuta la possibilità di utilizzare l'autenticazione basata su token

Con l'autenticazione basata su token, i dispositivi edge inviano un token al broker MQTT per autenticarsi. I dispositivi possono generare il token autonomamente o riceverlo da altri servizi di autenticazione. Rispetto alle password, i token hanno una durata limitata: 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 e autenticarsi 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 dispositivi edge con risorse limitate, in cui puoi utilizzare un algoritmo di crittografia meno dispendioso in termini di risorse come ECC per la firma del token.
  • Con la crittografia con chiave pubblica, la chiave privata viene utilizzata solo sul dispositivo edge e non viene mai condivisa con altre parti. Una chiave privata contribuisce a rendere questo metodo più sicuro dell'autenticazione tramite nome utente e password, in cui le credenziali vengono inviate tramite la connessione e richiedono la crittografia dei dati.

Valutare gli 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 da supportare quanto segue:

  • Protocolli di autenticazione standard di settore come OpenID Connect, Security Assertion Markup Language (SAML), LDAP, Kerberos, e Simple Authentication and Security Layer (SASL). Questi protocolli delegan l'autenticazione del dispositivo ai tuoi provider di identità esistenti. Alcuni broker MQTT supportano l'autenticazione avanzata e meccanismi di autenticazione estendibili 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 un schema di autenticazione reciproca, ad esempio l'autenticazione basata su mTLS.

Best practice per il controllo e l'autorizzazione dell'accesso ai dispositivi

A causa del pattern di comunicazione di publisher e subscriber del protocollo MQTT, il controllo dell'accesso al dispositivo 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 del backend IoT per le opzioni su come configurare gli argomenti MQTT.

Utilizzare account di servizio a scopo singolo per accedere alle risorse Google Cloud

L'accesso alle risorse Google Cloud viene gestito dai criteri di autorizzazione IAM che associano l'autorizzazione di accesso alle risorse a un insieme di entità. Le entità più comuni sono account utente, account di servizio e gruppi. Gli account di servizio vengono in genere utilizzati da un'applicazione o da un carico di lavoro di calcolo per effettuare chiamate API autorizzate per le risorse cloud. Gli account di servizio consentono ai dispositivi IoT edge 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 risorse Google Cloud.

Se gestisci un insieme di dispositivi di grandi dimensioni, il limite al numero di account di servizio per ogni progetto Google Cloud rende impraticabile avere una mappatura uno a uno diretta tra dispositivo e account di servizio.

Crea invece account di servizio collegati alle risorse cloud a cui deve accedere la tua soluzione IoT, come descritto nella sezione sulla creazione di account di servizio a scopo singolo. Ad esempio, crea un account di servizio univoco per ciascuno dei seguenti scenari di utilizzo:

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

Per implementare il modello di privilegi minimi, 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.

Distribuire i token di accesso ai dispositivi in modo sicuro

In genere, i dispositivi edge comunicano con la piattaforma IoT utilizzando MQTT. Tuttavia, per casi d'uso specifici, i tuoi dispositivi potrebbero richiedere l'accesso diretto alle risorse Google Cloud. Ad esempio, prendi in considerazione quanto indicato di seguito:

  • 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 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 qualsiasi credenziale specifica per il cloud sui dispositivi edge e la distribuzione dell'accesso 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à dei carichi di lavoro tra il tuo 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 di 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 edge devono implementare il flusso di lavoro di scambio di token OAuth 2.0, 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 al fornitore di servizi di identità del dispositivo.
  • Se la verifica dell'identità va a buon fine, il servizio Security Token restituisce un token di accesso al dispositivo edge.
  • Il dispositivo edge utilizza questo token per rubare l'identità dell'account di servizio a scopo unico e ottiene un token di accesso OAuth 2.0 a durata breve.
  • Il dispositivo utilizza il token di accesso OAuth 2.0 di breve durata per autenticarsi con le API Google Cloud e ottenere l'accesso alle risorse cloud richieste.

Per limitare l'accesso del token di accesso a breve termine a bucket e oggetti specifici in Cloud Storage, utilizza i confini di accesso alle credenziali. I limiti di accesso alle credenziali ti consentono di limitare l'accesso della credenziale 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 al cloud ai dispositivi edge. Per ulteriori informazioni sull'autenticazione, consulta Autenticazione su Google.

Monitorare e controllare l'accesso alle risorse cloud

Abilita gli audit log di Cloud 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 su Google Cloud. Inoltre, Cloud Audit Logs crea le tracce di controllo e gli audit log necessari per esaminare eventuali problemi. Per ulteriori informazioni, consulta Rubare l'identità di un account di servizio per accedere a Google Cloud.

Passaggi successivi