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

Last reviewed 2024-05-31 UTC

Il presente documento fornisce le best practice sulla sicurezza per la gestione e l'esecuzione di Backend Internet of Things (IoT) su Google Cloud. In una soluzione IoT, Il backend IoT connette i dispositivi periferici ad altre risorse. Questo documento è incentrato su i seguenti backend IoT: broker MQTT (Message Queuing Telemetry Transport (MQTT)) e la piattaforma IoT.

Il presente documento fa parte di una serie di documenti che forniscono informazioni su le architetture IoT su Google Cloud e la migrazione IoT Core. Gli altri documenti di questa serie includono seguenti:

Questo documento fornisce le best practice per il provisioning e la gestione del dispositivo le credenziali, l'autenticazione e l'accesso ai dispositivi periferici di controllo e dispositivi periferici accedono alle risorse Google Cloud.

Architettura IoT

Un'architettura IoT include servizi che consentono di eseguire il provisioning e la gestione del dispositivo le credenziali, l'autenticazione e il controllo dell'accesso ai dispositivi periferici e per accedere alle risorse Google Cloud. Questo documento illustra due backend IoT architetture: una che utilizza il broker MQTT e l'altra che utilizza una piattaforma IoT. La le principali differenze di sicurezza tra questi due backend sono l'identità dei dispositivi e la gestione dei dispositivi. le piattaforme IoT offrono queste funzionalità nell'ambito delle mentre i broker MQTT richiedono di fornire queste funzionalità.

Il seguente diagramma descrive l'architettura IoT.

Architettura del backend IoT.

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

  1. il provisioning dei certificati, ossia la procedura da completare per preparare dispositivo periferico per la configurazione.

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

  3. Connessioni tra dispositivi periferici e servizi Google Cloud, che sono 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 del provisioning e dell'autenticazione.

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

  • Un dispositivo periferico (ad esempio un dispositivo medico) che distribuisci del tuo ambiente e geograficamente vicini ai dati che vuoi elaborare. La i dispositivi periferici si connettono in modo bidirezionale al tuo backend IoT, 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 i dispositivi periferici connettiti utilizzando Protocollo MQTT. I broker MQTT non dispongono di funzionalità per l'identità e il dispositivo dei dispositivi e si affidano a sistemi esterni per fornirli.
    • Una piattaforma IoT è un'applicazione cloud che consente la connessione dei dispositivi periferici e con cui comunicare. Le piattaforme IoT forniscono un'interfaccia sicura per i dispositivi periferici per la connessione dei dispositivi tramite il protocollo MQTT. Ogni piattaforma IoT dispone di una propria implementazione di sicurezza che determina il modo in cui autorizza i dispositivi periferici e come gestisce le identità dei dispositivi.
  • Un archivio certificati centrale che ospita i certificati per tutto il perimetro dispositivi mobili.
  • Risorse cloud a cui devono accedere i dispositivi periferici.

Provisioning di un dispositivo periferico

Prima che un dispositivo periferico possa connettersi con i carichi di lavoro di backend, devi eseguire il provisioning di un certificato per il dispositivo periferico. Esistono due scenari principali decide come eseguire il provisioning del certificato:

  • Se la tua soluzione si basa su dispositivi commerciali generici, hai a disposizione il controllo sul processo di provisioning dopo l'acquisto del dispositivo.

  • Se usi dispositivi personalizzati, il processo di provisioning iniziale avvengono durante la produzione dei dispositivi ed è necessario integrare di provisioning con i vostri fornitori e produttori.

In entrambi i casi, devi creare certificati dei dispositivi con una catena di attendibilità. che si collega a un'autorità di certificazione (CA) radice. Questi certificati vengono autenticati l'identità del dispositivo e garantire che gli aggiornamenti e le modifiche siano dispositivi da parte di attori attendibili. Utilizza una CA come Certificate Authority Service per completare le seguenti attività:

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

  1. Generare la coppia di chiavi pubbliche/private utilizzando una sicurezza basata su hardware supportata dal tuo dispositivo, come una secure Element (SE) o un modulo di sicurezza hardware (HSM). Per impostazione predefinita, SE o HSM archivia le chiavi private localmente e non vengono mai esposte all'esterno. Se non utilizzi un software di sicurezza per generare una coppia di chiavi pubbliche/private, utilizza la CA generare chiavi. Per ulteriori informazioni, vedi Utilizzo di una chiave generata automaticamente.

  2. Firma e genera un certificato per il dispositivo. Dopo aver generato coppia di chiavi pubblica-privata, scarica la chiave pubblica, crea un richiesta di firma del certificato (CSR), e inviare la richiesta di firma del certificato alla CA per la firma. La CA genera un dispositivo collegato alla CA radice. Per ulteriori informazioni, vedi Utilizzare una richiesta di firma del certificato (CSR). Quando utilizzi chiavi generate automaticamente, puoi richiedere un certificato del dispositivo da direttamente la CA.

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

Per ulteriori informazioni, vedi 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 di provisioning, consulta Best practice per il provisioning e la configurazione automatici 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 tutte gli altri certificati nel sistema. I carichi di lavoro di backend utilizzano per convalidare i certificati client e i dispositivi periferici usano il certificato radice per convalidare il certificato del server. Devi distribuirà il certificato radice sia al backend IoT sia al perimetro dispositivi mobili.

  • I certificati del server vengono utilizzati per proteggere gli endpoint esposto dal backend IoT. Disponi di certificati server per algoritmi di crittografia che i tuoi endpoint devono supportare. Server siano collegati alla CA radice. Un Secret Manager gestisce e archivia sia la parte pubblica che la parte privata dei certificati del server. Devi configurare il backend IoT con i certificati server e i relativi le chiavi private corrispondenti.

  • I certificati client vengono utilizzati per identificare i dispositivi periferici. Ogni bordo dispositivo ha almeno un certificato client, a indicare che il numero di cui si dispone aumenta con il numero di dispositivi periferici in del tuo ambiente. I certificati client sono collegati alla CA radice. Devi distribuire i certificati client ai dispositivi periferici e al backend IoT.

Processo per la generazione di un certificato di dispositivo utilizzando un HSM o SE

Il seguente diagramma mostra come viene eseguito il provisioning del certificato di un dispositivo quando utilizzi 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 periferico genera la coppia di chiavi pubbliche nell'hardware.
  2. Scarichi la chiave pubblica e crei la richiesta di firma del certificato. (CSR).
  3. Devi inviare il 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 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 la generazione di un certificato del dispositivo tramite l'autorità di certificazione

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

Procedura per la generazione di un certificato del dispositivo.

In questo diagramma vengono eseguiti 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 pubbliche 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 i broker MQTT

I broker MQTT autenticano i dispositivi periferici utilizzando le credenziali dispositivo fornite 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 e la principale fonte di dati 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 del dispositivo le credenziali, consulta Provisioning di un dispositivo periferico.

Utilizza le identità digitali della piattaforma IoT come fonte attendibile

La piattaforma IoT dispone di funzionalità di sicurezza che gestiscono le identità dei dispositivi e credenziali del dispositivo e autenticare e autorizzare i dispositivi che tentano di accedere completamente gestita. Queste funzioni di sicurezza contribuiscono a garantire che soltanto i dispositivi autorizzati vengano autorizzati ad accedere alla piattaforma IoT e contribuire a garantire l'integrità dei dati.

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

Best practice per la connettività di rete

La protezione della connettività di rete è importante per i seguenti motivi:

  • Le reti sicure contribuiscono a garantire che un dispositivo si connetta di un backend cloud. Ad esempio, una rete protetta può impedire spoofing DNS, ovvero un attacco che tenta di deviare i dispositivi per connettersi a un rogue controllato dai malintenzionati.
  • Le reti sicure contribuiscono a impedire che le terze parti possano leggere il tuo traffico di dati. Ad esempio, una rete protetta può impedire un attacco in the middle, in cui i malintenzionati leggono il traffico tra il tuo dispositivo e il backend.

Utilizza le funzionalità di TLS (Transport Layer Security) per proteggere le comunicazioni di rete tra i dispositivi periferici e i backend carichi di lavoro con scale out impegnativi.

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

Per istruzioni sull'utilizzo di TLS, vedi Architettura autonoma del broker MQTT 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 utilizza MQTT broker.

Archivia i certificati a livello centrale

Archivia e gestisci i certificati server e dei dispositivi in una posizione centrale in ogni località. In particolare, assicurati di aver implementato i seguenti controlli:

  • Un inventario di tutti i tuoi dispositivi, con i relativi certificati e il server endpoint e i relativi certificati.
  • Informazioni aggiuntive sui certificati, come la loro validità.
  • È possibile aggiungere e rimuovere certificati per i dispositivi in modo che possono connettersi usando nuovi certificati.
  • Diritti di accesso all'archivio certificati centrale, per limitare ciò ruoli diversi nel backend possono operare con i certificati.

Usa una soluzione di archiviazione e gestione dei secret come Secret Manager o HashiCorp Vault. Secret Manager consente di controllare la versione, aggiornare e invalidare le credenziali del dispositivo, gestire i criteri di accesso alle tue credenziali.

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

Proteggi i certificati sui dispositivi periferici

Per archiviare certificati e chiavi sui dispositivi periferici, utilizza un un ambiente di esecuzione affidabile 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 crittografia flash, e archiviarli su elementi a prova di manomissione per impedire l'accesso ai dati l'estrazione dei contenuti.

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

I broker MQTT devono accedere ai certificati client per i certificati dell'autenticazione, quindi devi sincronizzare gli archivi di certificati dei broker MQTT con l'archivio certificati centrale. Verifica che le modifiche nella piattaforma un archivio certificati, come l'aggiunta, l'aggiornamento e l'eliminazione dei certificati, sincronizzati con l'archivio certificati del broker MQTT. I broker MQTT utilizzano come MySQL, PostgresDB e Java Key Store. In base a quale archivio di certificati utilizza il tuo broker MQTT, assicurati che: di questi processi:

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

Quando utilizzi Secret Manager come archivio certificati, è possibile usare notifiche di eventi come processo di monitoraggio. Puoi implementare il processo di sincronizzazione come listener delle notifiche degli eventi.

Distribuisci i certificati sui dispositivi periferici in modo sicuro

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

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

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

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

  • Un archivio certificati in cui i certificati sono gestiti a livello centrale.
  • Un coordinatore della distribuzione che invia i certificati e i percorsi il processo di distribuzione per ogni dispositivo periferico.
  • Un gestore degli aggiornamenti sul dispositivo periferico che riceve o scarica i certificati e li archivia sul dispositivo.

Distribuire i certificati durante i processi di provisioning per i dispositivi periferici e quando devi ruotare i certificati.

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

Quando fai ruotare i 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 le interruzioni del perimetro sui dispositivi operativi, utilizza un percorso di distribuzione indiretto dei certificati. Il processo consistere di questi passaggi logici:

  1. Il coordinatore della distribuzione acquisisce le credenziali di accesso un archivio certificati.
  2. Il coordinatore della distribuzione esegue il push delle credenziali di accesso ai certificati ai dispositivi periferici insieme a informazioni aggiuntive, come URL di download.
  3. Il gestore degli aggiornamenti sul dispositivo riceve le credenziali di accesso e memorizza temporaneamente le informazioni e restituisce una ricevuta di ritorno.
  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 dall'archivio di credenziali.
  5. Dopo aver scaricato i certificati, il gestore degli aggiornamenti continua con il processo di rotazione dei certificati, descritto 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 ulteriori informazioni, vedi Distribuisci i token di accesso ai dispositivi in modo sicuro.

Per evitare che i certificati vengano esposti durante il transito, cripta il file connessione tra i dispositivi periferici e il broker MQTT. Per ulteriori informazioni, vedi 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à limitato e ruota i certificati prima che scadano. Per di deployment IoT su larga scala, implementare una rotazione automatica dei certificati per aggiornare costantemente i dispositivi con i nuovi certificati prima quelle vecchie scadono. I dispositivi di cui è stato eseguito il deployment senza certificati validi possono comportare l'interruzione del funzionamento, che possono essere costosi da risolvere e influire negativamente sulla funzionalità complessiva delle la tua soluzione IoT.

I tuoi dispositivi periferici devono connettersi in modo bidirezionale al tuo broker MQTT per garantire di poter inviare messaggi al broker MQTT e di poter ricevere e i messaggi del broker MQTT.

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

  • Un processo di monitoraggio che analizza ripetutamente il certificato inventario e cerca i certificati che stanno per scadere. La Il processo di monitoraggio attiva la rotazione dei certificati per i certificati in scadenza.
  • Un processo di rotazione che inizializza e supervisiona la rotazione dei certificati.
  • Un gestore della rotazione dei certificati sul dispositivo periferico 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 periferico per avviare la rotazione dei certificati.
  2. Il gestore della rotazione dei certificati del dispositivo conferma l'inizializzazione inviando un messaggio di risposta al job di rotazione.
  3. Il processo di rotazione richiede un nuovo certificato alla CA. Questo è simile alla provisioning dei certificati richiesta, tranne per il fatto che le chiavi e CSR vengono inviate come messaggi dell'intermediario MQTT.
  4. Dopo aver ricevuto il nuovo certificato dalla CA, il job di rotazione distribuisce il certificato all'archivio certificati centrale e dispositivo periferico. Sincronizza inoltre il certificato con l'archivio certificati del broker MQTT.
  5. Il gestore della rotazione dei certificati del dispositivo archivia il nuovo certificato e inizializza una nuova connessione con il broker MQTT utilizzando il nuovo certificato.
  6. Una volta stabilita la nuova connessione, la rotazione del certificato del dispositivo invia un messaggio completato al broker MQTT.
  7. Dopo aver ricevuto il messaggio completato, il processo di rotazione invalida con il vecchio certificato nell'archivio certificati centrale.

Per proteggere i certificati che vengono inviati durante la rotazione. usa 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 delle modifiche e dell'avanzamento.

Per ulteriori informazioni 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 l'aggiornamento e la distribuzione del certificato meccanismi forniti dalla piattaforma. A scopo di backup, puoi eseguire regolarmente esporta le credenziali dalla tua piattaforma IoT a uno spazio di archiviazione dei secret secondario, come 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 e quelli periferici verificano l'identità dei carichi di lavoro di backend. Dopo che i carichi di lavoro del backend hanno confermato l'identità del dispositivo periferico, il backend carichi di lavoro autorizzano l'accesso del dispositivo alle risorse.

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

Scegli il metodo di autenticazione per i broker MQTT

Backend IoT diversi supportano metodi di autenticazione diversi. L'approccio usati sono i seguenti:

  • Autenticazione con nome utente e password, quando il dispositivo periferico presenta il nome utente e la password per verificarne l'identità.
  • Autenticazione basata su token, che prevede l'uso di token di sicurezza criptati per verificare l'identità del dispositivo periferico.
  • Schemi di autenticazione personalizzati, in cui implementi uno schema di meccanismo di verifica dell'identità del dispositivo periferico.

Nell'ambito del standard MQTT, I broker MQTT supportano l'autenticazione con nome utente e password come impostazione predefinita MQTT CONNECT.

Il pacchetto MQTT CONNECT contiene anche Client Identifier che puoi utilizzare per identificare in modo univoco il client del broker MQTT. Dispositivi periferici di dispositivi 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 autenticazione avanzata che ti consente di creare risposta-sfida nei flussi di autenticazione. MQTT 5.0 consente di eseguire AUTH per gli scambi di pacchetti tra il dispositivo periferico e il broker MQTT.

Utilizza archivi delle password con autenticazione di nome utente e password

Per l'autenticazione di nome utente e password, configura il broker MQTT in modo che utilizzi una l'archivio delle password. L'archivio delle password offre una posizione centralizzata per la gestione 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 in MQTT e la specifica del prodotto. Progetta quindi il tuo meccanismo di autenticazione per verificare i campi nome utente, password e identificatore client sono presenti nel pacchetto MQTT CONNECT.

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

Valutare l'autenticazione basata su token

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

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

JWT offre i seguenti vantaggi:

  • JWT consente di scegliere l'algoritmo di crittografia usato per la firma dei il token. JWT funziona bene con i dispositivi periferici vincolati, dove puoi usare un algoritmo di crittografia che richiede meno risorse, come ECC per la firma il token.
  • Utilizzando la crittografia a chiave pubblica, la chiave privata viene utilizzata solo a livello perimetrale dispositivo e mai condivisi con altri. Una chiave privata consente più sicuro dell'autenticazione basata su nome utente e password, in cui vengono inviate tramite la connessione e richiedono la crittografia dei dati.

Valutare gli schemi di autenticazione personalizzati

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

  • Protocolli di autenticazione standard del settore come OpenID Connect SAML (Security Assertion Markup Language), LDAP, Kerberos, e Simple Authentication and Security Layer (SASL). Questi protocolli delegano l'autenticazione dei dispositivi alla tua identità esistente di Google Cloud. Alcuni broker MQTT supportano l’autenticazione avanzata ed estensibile meccanismi di autenticazione per estendere il broker MQTT supportare nuovi protocolli e provider di identità.
  • Autenticazione reciproca basata su certificati. Alcuni broker MQTT supportano 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 modello di comunicazione del publisher e del sottoscrittore di MQTT il controllo dell'accesso al dispositivo viene definito utilizzando argomenti MQTT. Argomenti MQTT controllare in che modo un dispositivo può comunicare con il tuo backend IoT. Ogni backend IoT diverse implementazioni per il controllo dell'accesso e l'autorizzazione, quindi fai riferimento alle Documentazione del backend IoT per le opzioni di configurazione degli argomenti MQTT.

Usa account di servizio monouso per accedere alle risorse Google Cloud

Accesso alle risorse Google Cloud sono gestiti dai criteri di autorizzazione IAM che associano il permesso di accesso alle risorse a un un insieme di entità. Le entità tipiche sono account utente, account di servizio gruppi. Account di servizio vengono in genere utilizzate da un'applicazione o da un carico di lavoro di computing per rendere le API autorizzate per le risorse cloud. Gli account di servizio consentono ai dispositivi periferici IoT di accedere al cloud Google Cloud.

Poiché l'identità del dispositivo è gestita dal backend IoT, è necessario e l'identità tra il backend IoT e IAM in modo che il dispositivo periferico possa accedere dell'accesso a specifiche risorse Google Cloud.

Se gestisci un numero elevato di dispositivi, limite del numero di account di servizio per ciascun progetto Google Cloud rende per avere una mappatura diretta one-to-one tra dispositivo e account di servizio.

Crea invece account di servizio collegati alle risorse cloud che l'accesso alla soluzione IoT, come descritto in la creazione di account di servizio monouso. Ad esempio, crea un account di servizio univoco per ciascuno dei seguenti utilizzi casi:

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

Per implementare privilegio minimo, assicurati che ogni account di servizio disponga solo di diritti di accesso sufficienti per l'assistenza al suo caso d'uso. Ad esempio, per un account di servizio utilizzato per scaricare di 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 piattaforma IoT tramite MQTT. Tuttavia, per casi d'uso specifici, i dispositivi potrebbero richiedere l'accesso diretto dell'accesso a specifiche risorse Google Cloud. Ad esempio, considera quanto segue:

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

Per questi casi d'uso, usa federazione delle identità per i carichi di lavoro, in cui l'accesso alle risorse Google Cloud viene concesso token di accesso. La federazione delle identità per i carichi di lavoro elimina la necessità di eseguire il provisioning credenziali specifiche del cloud sui dispositivi periferici e la distribuzione degli accessi 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à dei dispositivi in Google Cloud. Per supportare la federazione delle identità per i carichi di lavoro, assicurati che che il backend IoT soddisfi i requisiti requisiti di federazione delle identità per i carichi di lavoro e segue i best practice per la 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 dispositivi periferici devono implementare Scambio di token OAuth 2.0 che prevede i seguenti passaggi:

  • Il dispositivo chiama Servizio token di sicurezza e fornisce le proprie credenziali del dispositivo.
  • Il servizio token di sicurezza verifica l'identità del dispositivo periferico convalida delle credenziali che il dispositivo periferico ha fornito con il dispositivo o il provider di identità.
  • Se la verifica dell'identità ha esito positivo, il servizio token di sicurezza restituisce un token federato al dispositivo periferico.
  • Il dispositivo periferico utilizza il token federato per rappresentare un account di servizio monouso e ottiene 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 accedere alle risorse cloud necessarie.

Limitare l'accesso del token di accesso di breve durata a bucket specifici in Cloud Storage, utilizza Limiti dell'accesso alle credenziali. I limiti dell'accesso alle credenziali ti consentono di limitare l'accesso alle credenziali di breve durata, le credenziali e ridurre al minimo il numero di risorse 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 ai dispositivi periferici. Per ulteriori informazioni sull'autenticazione, vedi Autenticazione in Google.

Monitoraggio e controllo dell'accesso alle risorse cloud

Abilita Cloud Audit Logs per creare voci di log quando i tuoi dispositivi periferici accedono al cloud tramite richieste API autenticate. Cloud Audit Logs consente di monitora le azioni critiche compiute dai dispositivi periferici in Google Cloud. Inoltre, Cloud Audit Logs crea le tracce di audit e i log necessari per analizzare gli eventuali problemi. Per ulteriori informazioni, vedi Furto d'identità di un account di servizio per accedere a Google Cloud.

Passaggi successivi