Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Le migliori pratiche di sicurezza in AWS IoT Core

Questa sezione contiene informazioni sulle migliori pratiche di sicurezza per AWS IoT Core. Per informazioni sulle regole di sicurezza per le soluzioni IoT industriale, consultare Ten security golden rules for Industrial IoT solutions.

Protezione delle connessioni MQTT in AWS IoT

AWS IoT Core è un servizio cloud gestito che consente ai dispositivi connessi di interagire con le applicazioni cloud e altri dispositivi in modo semplice e sicuro. AWS IoT Core supporta HTTP, WebSockete MQTT, un protocollo di comunicazione leggero progettato specificamente per tollerare connessioni intermittenti. Se ti stai connettendo a AWS IoT utilizzando MQTT, ciascuna delle connessioni deve essere associata a un identificatore noto come ID client. Gli ID client MQTT identificano le connessioni MQTT in modo univoco. Se viene stabilita una nuova connessione utilizzando un ID client già richiesto per un'altra connessione, AWS IoT message broker elimina la vecchia connessione per consentire la nuova connessione. Gli ID client devono essere univoci all'interno di ciascuno Account AWS e ciascuno Regione AWS. Ciò significa che non è necessario imporre l'unicità globale degli ID dei clienti al di fuori del Account AWS o in tutte le regioni all'interno del tuo Account AWS.

L'impatto e la gravità della chiusura delle connessioni MQTT nel parco istanze di dispositivi dipende da molti fattori. Ciò include:

Per evitare conflitti tra ID cliente e i loro potenziali impatti negativi, assicurati che ogni dispositivo o applicazione mobile sia dotato di un AWS IoT o una politica IAM che limita gli ID client che possono essere utilizzati per le connessioni MQTT a AWS IoT broker di messaggi. Ad esempio, puoi utilizzare una policy IAM per impedire a un dispositivo di chiudere involontariamente la connessione di un altro dispositivo utilizzando un ID client già in uso. Per ulteriori informazioni, consulta Autorizzazione.

Tutti i dispositivi del parco dispositivi devono disporre di credenziali con privilegi che autorizzano solo le azioni previste, che includono (a titolo esemplificativo e non esaustivo) AWS IoT Azioni MQTT come la pubblicazione di messaggi o la sottoscrizione ad argomenti con ambito e contesto specifici. Le policy di autorizzazione specifiche possono variare a seconda dei casi d'uso. Identifica le policy di autorizzazione che meglio soddisfano i requisiti aziendali e di sicurezza.

Per creare e gestire più facilmente le policy di autorizzazione, puoi utilizzare AWS IoT Core variabili politiche e le variabili delle policy IAM. Le variabili di policy possono essere inserite in una policy e, nel momento in cui questa viene valutata, vengono sostituite con i valori provenienti dalla richiesta del dispositivo. Con le variabili di policy è possibile creare una singola policy per concedere le autorizzazioni a più dispositivi. È possibile identificare le variabili di policy pertinenti per il proprio caso d'uso in base alle proprie AWS IoT configurazione dell'account, meccanismo di autenticazione e protocollo di rete utilizzati per la connessione a AWS IoT broker di messaggi. Per scrivere policy di autorizzazione ottimali, considera gli aspetti specifici del tuo caso d'uso e il tuo modello di gestione delle minacce.

Ad esempio, se hai registrato i tuoi dispositivi nel AWS IoT registro, puoi usare variabili di politica delle cose nel AWS IoT politiche per concedere o negare le autorizzazioni in base a proprietà degli oggetti come i nomi degli oggetti, i tipi di oggetti e i valori degli attributi degli oggetti. Il nome dell'oggetto è ottenuto dall'ID del client nel messaggio di connessione MQTT inviato quando un oggetto si connette a AWS IoT. Le variabili di policy dell'oggetto vengono sostituite quando un oggetto si connette a AWS IoT su MQTT utilizzando l'autenticazione reciproca TLS o MQTT tramite WebSocket protocollo che utilizza autenticato identità Amazon Cognito. Puoi usare il AttachThingPrincipal API per allegare certificati e identità Amazon Cognito autenticate a un oggetto. iot:Connection.Thing.ThingName è una variabile di policy utile per applicare le restrizioni relative agli ID dei clienti. L'esempio seguente AWS IoT la policy richiede che il nome di un oggetto registrato venga utilizzato come ID client per le connessioni MQTT a AWS IoT broker di messaggi:

Se desideri identificare i conflitti in corso tra gli ID del cliente, puoi abilitare e utilizzare CloudWatch Registri per AWS IoT. Per ogni connessione MQTT che il AWS IoT Il broker di messaggi si disconnette a causa di conflitti tra ID client, viene generato un record di registro simile al seguente:

{
    "timestamp": "2019-04-28 22:05:30.105",
    "logLevel": "ERROR",
    "traceId": "02a04a93-0b3a-b608-a27c-1ae8ebdb032a",
    "accountId": "123456789012",
    "status": "Failure",
    "eventType": "Disconnect",
    "protocol": "MQTT",
    "clientId": "clientId01",
    "principalId": "1670fcf6de55adc1930169142405c4a2493d9eb5487127cd0091ca0193a3d3f6",
    "sourceIp": "203.0.113.1",
    "sourcePort": 21335,
    "reason": "DUPLICATE_CLIENT_ID",
    "details": "A new connection was established with the same client ID"
}

È possibile utilizzare un CloudWatch Filtro dei log ad esempio {$.reason= "DUPLICATE_CLIENT_ID" } per cercare casi di conflitto tra ID client o per configurare CloudWatch filtri metrici e corrispondenti CloudWatch allarmi per il monitoraggio e la segnalazione continui.

Puoi usare AWS IoT Device Defender per identificare un atteggiamento eccessivamente permissivo AWS IoT e politiche IAM. AWS IoT Device Defender fornisce anche un controllo di controllo che ti avvisa se più dispositivi del tuo parco dispositivi si connettono al AWS IoT broker di messaggi che utilizza lo stesso ID client.

Puoi usare AWS IoT Device Advisor per verificare che i tuoi dispositivi possano connettersi in modo affidabile a AWS IoT Core e segui le migliori pratiche di sicurezza.

Consulta anche

Tieni sincronizzato l'orologio del dispositivo

È importante avere un'ora precisa sul dispositivo. X.509 i certificati hanno una data e un'ora di scadenza. L'orologio sul dispositivo viene utilizzato per verificare che un certificato server sia ancora valido. Se stai costruendo dispositivi IoT commerciali, ricorda che i tuoi prodotti potrebbero essere conservati per lunghi periodi prima di essere venduti. Real-time Gli orologi possono spostarsi durante questo periodo e le batterie possono scaricarsi, quindi impostare l'ora in fabbrica non è sufficiente.

Per la maggior parte dei sistemi, ciò significa che il software del dispositivo deve includere un client NTP (Network Time Protocol). Il dispositivo deve attendere fino a quando si sincronizza con un server NTP prima di tentare di connettersi a AWS IoT Core. Se ciò non è possibile, il sistema dovrebbe fornire agli utenti la possibilità di impostare l'ora del dispositivo in modo che le connessioni successive abbiano esito positivo.

Dopo che il dispositivo è sincronizzato con un server NTP, può aprire una connessione con AWS IoT Core. L'inclinazione del clock consentita dipende dalla finalità della connessione.

Convalidare il certificato server

La prima cosa che fa un dispositivo è interagire AWS IoT è aprire una connessione sicura. Quando colleghi il dispositivo a AWS IoT, assicurati di parlare con AWS IoT e non un altro server che finge AWS IoT. Ciascuna delle AWS IoT i server sono dotati di un certificato rilasciato per iot.amazonaws.com dominio. Questo certificato è stato rilasciato a AWS IoT da un'autorità di certificazione affidabile che ha verificato la nostra identità e la proprietà del dominio.

Una delle prime cose AWS IoT Core quando un dispositivo si connette invia al dispositivo un certificato server. I dispositivi possono verificare che aspettino di connettersi a iot.amazonaws.com e che il server alla fine di tale connessione disponga di un certificato di un'autorità attendibile per tale dominio.

I certificati TLS sono presenti X.509 formattare e includere una serie di informazioni come il nome dell'organizzazione, l'ubicazione, il nome di dominio e il periodo di validità. Il periodo di validità è specificato come una coppia di valori di tempo chiamati notBefore e notAfter. Servizi come AWS IoT Core utilizzano periodi di validità limitati (ad esempio, un anno) per i propri certificati server e iniziano a fornire quelli nuovi prima che scadano quelli vecchi.

Utilizzare una singola identità per dispositivo

Utilizzare una singola identità per client. I dispositivi generalmente utilizzano X.509 certificati dei clienti. Le applicazioni per il Web e i dispositivi mobili utilizzano Amazon Cognito Identity. In questo modo è possibile applicare le autorizzazioni a grana fine ai dispositivi.

Ad esempio, disponi di un'applicazione costituita da un dispositivo mobile che riceve aggiornamenti di stato da due diversi oggetti smart home, una lampadina e un termostato. La lampadina invia lo stato del suo livello della batteria e un termostato invia messaggi che segnalano la temperatura.

AWS IoT autentica i dispositivi singolarmente e tratta ogni connessione singolarmente. È possibile applicare controlli di accesso a grana fine utilizzando le policy di autorizzazione. È possibile definire una policy per il termostato che consenta la pubblicazione in uno spazio argomento. È possibile definire una policy separata per la lampadina che consenta la pubblicazione su uno spazio argomento diverso. Infine è possibile definire una policy per l'app mobile che consente solo di connettersi e sottoscrivere gli argomenti relativi al termostato e alla lampadina per ricevere messaggi da questi dispositivi.

Applicare il principio del minimo privilegio e definire l'ambito delle autorizzazioni per dispositivo il più possibile. Tutti i dispositivi o gli utenti devono disporre di un AWS IoT politica in AWS IoT che gli consente solo di connettersi con un ID cliente noto e di pubblicare e sottoscrivere una serie di argomenti identificati e fissi.

Usane un secondo Regione AWS come riserva

Valuta la possibilità di archiviare una copia dei tuoi dati in un secondo Regione AWS come backup. Nota che il AWS soluzione denominata Disaster Recovery per AWS IoT non è più disponibile. Mentre l'associato GitHub biblioteca rimane accessibile, AWS lo ha dichiarato obsoleto nel luglio 2023 e non fornisce più manutenzione o supporto. Per implementare le tue soluzioni o per esplorare opzioni di supporto aggiuntive, visita Contattaci AWS. Se c'è un AWS Contatta il Technical Account Manager associato al tuo account per ricevere assistenza.

Utilizzare il provisioning Just In Time

La creazione e il provisioning manuali di ciascun dispositivo possono richiedere molto tempo. AWS IoT fornisce un modo per definire un modello per il provisioning dei dispositivi quando si connettono per la prima volta AWS IoT. Per ulteriori informazioni, consulta Just-in-time approvvigionamento.

Autorizzazioni di esecuzione AWS IoT Test di Device Advisor

Il seguente modello di policy mostra le autorizzazioni minime e l'entità IAM necessarie per l'esecuzione AWS IoT Casi di test di Device Advisor. Dovrai sostituire your-device-role-arn con il ruolo del dispositivo Amazon Resource Name (ARN) che hai creato in prerequisiti.

Cross-service sostituto confuso per Device Advisor

Il problema confused deputy è un problema di sicurezza in cui un’entità che non dispone dell’autorizzazione per eseguire un’azione può costringere un’entità maggiormente privilegiata a eseguire l’azione. Nel AWS, l'imitazione tra servizi può causare il confuso problema dei vice. Cross-service l'imitazione può avvenire quando un servizio (il servizio di chiamata) chiama un altro servizio (il chiamato servizio). Il servizio chiamante può essere manipolato per utilizzare le proprie autorizzazioni e agire sulle risorse di un altro cliente, a cui normalmente non avrebbe accesso. Per evitare ciò, AWS fornisce strumenti che ti aiutano a proteggere i tuoi dati per tutti i servizi i cui clienti hanno avuto accesso alle risorse del tuo account.

Consigliamo di utilizzare le chiavi di contesto delle condizioni globali aws:SourceArn e aws:SourceAccount nelle policy delle risorse per limitare le autorizzazioni con cui Device Advisor fornisce un altro servizio alla risorsa. Se si utilizzano entrambe le chiavi di contesto delle condizioni globali, il valore aws:SourceAccount e l'account nel valore aws:SourceArn devono utilizzare lo stesso ID account nella stessa istruzione di policy.

Il valore di aws:SourceArn deve essere l'ARN della risorsa di definizione della suite. La risorsa di definizione della suite fa riferimento alla suite di test creata con Device Advisor.

Il modo più efficace per proteggersi dal problema "confused deputy" è quello di usare la chiave di contesto della condizione globale aws:SourceArn con l’ARN completo della risorsa. Se non si conosce l’ARN completo della risorsa o si scelgono più risorse, è necessario utilizzare la chiave di contesto della condizione globale aws:SourceArn con caratteri jolly (*) per le parti sconosciute dell’ARN. Ad esempio, arn:aws:iotdeviceadvisor:*:account-id:suitedefinition/*.

L'esempio seguente mostra il modo in cui puoi utilizzare le chiavi di contesto delle condizioni globali aws:SourceArn e aws:SourceAccount in Device Advisor per prevenire il problema "confused deputy".