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

Last reviewed 2024-12-06 UTC

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

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

Questo documento fornisce best practice per il provisioning e la gestione delle credenziali dei dispositivi, l'autenticazione e l'accesso ai dispositivi edge di controllo e 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 controllare 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 seguenti tre 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 Google Cloud servizi, 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 di edge si connettono in modo bidirezionale al backend IoT, il che significa che possono inviare e ricevere messaggi dal backend IoT.
  • Un backend IoT che può essere un broker MQTT o una piattaforma IoT.
    • Un broker MQTT fornisce un'interfaccia sicura per la connessione dei dispositivi edge utilizzando il protocollo MQTT. I broker MQTT non dispongono 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à:

  • Se il tuo dispositivo dispone di una soluzione di sicurezza basata su hardware e a prova di manomissione, ad esempio un elemento di sicurezza (SE) o un modulo di sicurezza hardware (HSM) che memorizza le chiavi private localmente e queste non vengono mai esposte esternamente, svolgi i seguenti passaggi:

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

  • Se non utilizzi una soluzione di sicurezza basata su hardware per generare una coppia di chiavi pubblica/privata, utilizza l'autorità di certificazione per generare le chiavi e il certificato. Per ulteriori informazioni, consulta Utilizzare una chiave generata automaticamente. Il certificato scaricato utilizzando questo metodo è già firmato.

Dopo aver generato e firmato un certificato del dispositivo, installalo sul dispositivo edge e memorizzalo in un repository di certificati centralizzato, ad esempio Secret Manager.

Per ulteriori informazioni, consulta Come implementare un'infrastruttura a chiave pubblica sicura e affidabile con Google Cloud il servizio CA (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, mentre i dispositivi periferici usano il certificato radice per convalidare il certificato del server. Devi distribuire il certificato radice sia al backend IoT sia ai dispositivi edge.

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

  • 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 firmato al provisioning.
  5. Il provisioning esegue le seguenti azioni:
    1. Invia il certificato firmato al dispositivo edge.
    2. Memorizza il certificato firmato 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. Il provisioning richiede all'autorità di certificazione di inviare un certificato firmato per il dispositivo.
  2. La CA completa le seguenti azioni:
    1. Genera una coppia di chiavi pubblica-privata e firma la chiave pubblica.
    2. Restituisce il certificato del dispositivo e la chiave privata al provisioning.
  3. Il provisioning esegue 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 archivia il certificato e la chiave privata in una posizione sicura.

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

Autentica i dispositivi prima di firmare i certificati

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

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

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

  • Implementa un meccanismo di autenticazione per i dispositivi che non sono ancora attendibili.
  • Stabilire l'autenticità di qualsiasi dispositivo che richiede l'autenticazione.
  • Stabilisci l'autenticità del dispositivo prima che un dispositivo chieda all'autorità di certificazione di generare un nuovo certificato o di firmare un certificato esistente.

L'implementazione di un meccanismo di autenticazione in questo punto della procedura di provisioning è complessa. Non puoi fare affidamento sui certificati dei dispositivi per autenticarli perché il dispositivo non dispone ancora di un certificato firmato dalla CA. Questa mancanza di un certificato firmato può verificarsi per i seguenti motivi:

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

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

  1. Genera un certificato di provisioning da utilizzare solo per autenticare il dispositivo rispetto all'infrastruttura di firma del certificato.
  2. Firma il certificato di provisioning con la tua CA.
  3. Memorizza il certificato di provisioning firmato nell'SE o nell'HSM sul dispositivo.
  4. Memorizza il certificato di provisioning firmato nel tuo Google Cloud backend.

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

Esistono differenze tra un certificato di provisioning e un certificato completamente attendibile. Un certificato di provisioning concede l'accesso solo a un numero minimo di servizi e infrastrutture. La creazione di un certificato di provisioning consente alla CA di verificare che il dispositivo sia autentico prima di considerarlo attendibile al 100% e di emettere un certificato attendibile al 100%.

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

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

Best practice per l'identità del dispositivo

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

Utilizzare un provider di identità con i broker MQTT

I broker MQTT autenticano i dispositivi edge utilizzando le credenziali del dispositivo fornite da plugins, 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 verità 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 autorizzati.

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 keystore 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 certificati centrale 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 inizializza 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 perimetrale. 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 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 i meccanismi di aggiornamento e distribuzione dei certificati forniti dalla piattaforma. Per scopi di backup, puoi esportare regolarmente le credenziali dalla tua piattaforma IoT in 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 con 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 i dispositivi edge con limitazioni, 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 Google Cloud risorse

L'accesso alle Google Cloud risorse viene gestito dai criteri di autorizzazione IAM che associano l'autorizzazione di accesso alle risorse a un set 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 risorseGoogle 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 monouso. Ad esempio, crea un account di servizio univoco per ciascuno dei seguenti scenari di utilizzo:

  • Download dei pacchetti di aggiornamento del 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 risorseGoogle 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 viene concesso tramite token di accesso. Google Cloud 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 avviene 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 provider di identità del dispositivo eGoogle 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 Google Cloud risorse utilizzando la federazione delle identità dei 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 vita 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 suGoogle Cloud. Inoltre, Cloud Audit Logs crea le tracce di controllo e gli audit log necessari per esaminare eventuali problemi. Per ulteriori informazioni, consulta Impersonare un account di servizio per accedere Google Cloud.

Passaggi successivi

Collaboratori

Autori:

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