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
L'impatto e la gravità della chiusura delle connessioni MQTT nel parco istanze di dispositivi dipende da molti fattori. Ciò include:
-
Il tuo caso d'uso (ad esempio, i dati a cui vengono inviati i dispositivi AWS IoT, la quantità di dati e la frequenza di invio dei dati).
-
La configurazione client MQTT, ad esempio le impostazioni di riconnessione automatica, le tempistiche di back-off associate e l'utilizzo di sessioni persistenti MQTT).
-
Vincoli delle risorse dispositivo.
-
La causa radice delle disconnessioni, la sua aggressività e la sua persistenza.
Per evitare conflitti tra ID client e i loro potenziali impatti negativi, assicurati che ogni dispositivo o applicazione mobile disponga di una politica AWS IoT o IAM che limiti gli ID client che possono essere utilizzati per le connessioni MQTT al broker di AWS IoT 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 (ma non solo) azioni AWS IoT MQTT come la pubblicazione di messaggi o l'iscrizione 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 alla configurazione AWS IoT dell'account, al meccanismo di autenticazione e al protocollo di rete utilizzato per la connessione al broker di messaggi. AWS IoT 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 i dispositivi sono stati registrati nel AWS IoT registro, è possibile utilizzare le variabili Thing Policy nelle AWS IoT policy per concedere o negare le autorizzazioni in base alle proprietà degli oggetti come i nomi degli oggetti, i tipi di oggetto e i valori degli attributi degli oggetti. Il nome dell'oggetto viene ottenuto dall'ID client nel messaggio di connessione MQTT inviato quando un oggetto si connette a. AWS IoT Le variabili Thing Policy vengono sostituite quando un oggetto si connette AWS IoT tramite MQTT utilizzando l'autenticazione reciproca TLS o MQTT tramite il WebSocket protocollo utilizzando identità Amazon Cognito autenticate. Puoi utilizzare l'API AttachThingPrincipal 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. La seguente AWS IoT politica di esempio richiede che il nome di un oggetto registrato venga utilizzato come ID client per le connessioni MQTT al broker di AWS IoT messaggi:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "iot:Connect", "Resource": [ "arn:aws:iot:us-east-1:123456789012:client/${iot:Connection.Thing.ThingName}" ] } ] }
Se si desidera identificare i conflitti di ID client in corso, è possibile abilitare e utilizzare CloudWatch Logs for. AWS IoT Per ogni connessione MQTT che il broker di AWS IoT messaggi 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 filtro CloudWatch Logs, ad esempio per {$.reason= "DUPLICATE_CLIENT_ID" } cercare istanze di conflitti tra ID client o per impostare filtri CloudWatch metrici e CloudWatch allarmi corrispondenti per il monitoraggio e la segnalazione continui.
Puoi utilizzare AWS IoT Device Defender
Puoi utilizzare AWS IoT Device Advisor per verificare che i tuoi dispositivi possano connettersi in modo affidabile AWS IoT Core e seguire le migliori pratiche di sicurezza.
Consulta anche
Tieni sincronizzato l'orologio del dispositivo
È importante avere un orario preciso sul dispositivo. I certificati X.509 hanno data e ora di scadenza. L'orologio sul dispositivo viene utilizzato per verificare che un certificato server sia ancora valido. Se costruisci dispositivi IoT commerciali, ricorda che i tuoi prodotti potrebbero essere conservati per periodi prolungati prima di essere venduti. Gli orologi in tempo reale possono fermarsi nel corso del tempo e le batterie possono scaricarsi, quindi impostare il tempo 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 con cui un dispositivo interagisce AWS IoT è aprire una connessione sicura. Quando colleghi il dispositivo a AWS IoT, assicurati di parlare con un altro server AWS IoT e di non AWS IoT impersonare un altro server. Ciascun AWS IoT server è dotato di un certificato rilasciato per il dominio. iot.amazonaws.com Questo certificato è stato rilasciato AWS IoT da un'autorità di certificazione affidabile che ha verificato la nostra identità e la proprietà del dominio.
Una delle prime cose che AWS IoT Core fa quando un dispositivo si connette è inviare 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 in formato X.509 e includono una serie di informazioni, ad esempio il nome, la posizione, il nome di dominio e un periodo di validità dell'organizzazione. Il periodo di validità è specificato come una coppia di valori di tempo chiamati notBefore e notAfter. Servizi come ad esempio AWS IoT Core utilizzano periodi di validità limitati (ad esempio, un anno) per i certificati server e iniziano a fornirne di nuovi prima della scadenza di quelli vecchi.
Utilizzare una singola identità per dispositivo
Utilizzare una singola identità per client. I dispositivi utilizzano generalmente certificati client X.509. 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 una AWS IoT politica AWS IoT che consenta loro di connettersi solo con un ID client noto e di pubblicare e sottoscrivere una serie di argomenti identificati e fissi.
Usa un secondo Regione AWS come backup
Prendi in considerazione l'idea di archiviare una copia dei tuoi dati in un secondo Regione AWS come backup. Tieni presente che la AWS soluzione denominata Disaster Recovery for
Utilizzare il provisioning Just In Time
La creazione e il provisioning manuali di ogni dispositivo possono richiedere molto tempo. AWS IoT fornisce un modo per definire un modello a cui effettuare il provisioning dei dispositivi quando si connettono per AWS IoT la prima volta. Per ulteriori informazioni, consulta J: approvvigionamento ust-in-time .
Autorizzazioni per eseguire i test di AWS IoT Device Advisor
Il seguente modello di policy mostra le autorizzazioni minime e l'entità IAM necessarie per eseguire i casi di test di AWS IoT Device Advisor. Dovrai sostituire your-device-role-arn con l'Amazon Resource Name (ARN) del ruolo del dispositivo creato sotto i prerequisiti.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": "iam:PassRole", "Resource": "your-device-role-arn", "Condition": { "StringEquals": { "iam:PassedToService": "iotdeviceadvisor.amazonaws.com" } } }, { "Sid": "VisualEditor1", "Effect": "Allow", "Action": [ "execute-api:Invoke*", "iam:ListRoles", // Required to list device roles in the Device Advisor console "iot:Connect", "iot:CreateJob", "iot:DeleteJob", "iot:DescribeCertificate", "iot:DescribeEndpoint", "iot:DescribeJobExecution", "iot:DescribeJob", "iot:DescribeThing", "iot:GetPendingJobExecutions", "iot:GetPolicy", "iot:ListAttachedPolicies", "iot:ListCertificates", "iot:ListPrincipalPolicies", "iot:ListThingPrincipals", "iot:ListThings", "iot:Publish", "iot:StartNextPendingJobExecution", "iot:UpdateJobExecution", "iot:UpdateThingShadow", "logs:CreateLogGroup", "logs:CreateLogStream", "logs:DescribeLogGroups", "logs:DescribeLogStreams", "logs:PutLogEvents", "logs:PutRetentionPolicy" ], "Resource": "*" }, { "Sid": "VisualEditor2", "Effect": "Allow", "Action": "iotdeviceadvisor:*", "Resource": "*" } ] }
Prevenzione del problema "confused deputy" tra servizi per Device Advisor
Con "confused deputy" si intende un problema di sicurezza in cui un'entità che non dispone dell'autorizzazione per eseguire una certa operazione può costringere un'entità con più privilegi a eseguire tale operazione. Nel frattempo AWS, l'impersonificazione tra servizi può portare alla confusione del vicesceriffo. La rappresentazione tra servizi può verificarsi quando un servizio (il servizio chiamante) effettua una chiamata a un altro servizio (il servizio chiamato). 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 che ciò accada, AWS mette a disposizione strumenti che consentono di proteggere i dati relativi a tutti i servizi con responsabili del servizio a cui è stato concesso l'accesso alle risorse del vostro 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 conosci l'ARN completo della risorsa o scegli più risorse, utilizza 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".
{ "Version": "2012-10-17", "Statement": { "Sid": "ConfusedDeputyPreventionExamplePolicy", "Effect": "Allow", "Principal": { "Service": "iotdeviceadvisor.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "ArnLike": { "aws:SourceArn":"arn:aws:iotdeviceadvisor:us-east-1:123456789012:suitedefinition/ygp6rxa3tzvn"}, "StringEquals": { "aws:SourceAccount":"123456789012"} } } }
