Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Mejores prácticas de seguridad en AWS IoT Core
Esta sección contiene información sobre las mejores prácticas de seguridad para AWS IoT Core. Para obtener información sobre las reglas de seguridad de las soluciones de IoT industrial, consulte Ten security golden rules for Industrial IoT solutions
Proteger MQTT las conexiones en AWS IoT
AWS IoT Core
El impacto y la gravedad de la caída de MQTT las conexiones en tu flota de dispositivos dependen de muchos factores. Entre ellos se incluyen:
-
Tu caso de uso (por ejemplo, los datos a los que envían tus dispositivos AWS IoT, la cantidad de datos y la frecuencia con la que se envían).
-
Las restricciones de recursos de dispositivos.
-
La causa principal de las desconexiones, su agresividad y persistencia.
Para evitar conflictos de ID de cliente y sus posibles repercusiones negativas, asegúrate de que cada dispositivo o aplicación móvil tenga una AWS IoT IAM política que restrinja qué cliente se IDs puede utilizar para las MQTT conexiones con el intermediario de mensajes. AWS IoT Por ejemplo, puedes usar una IAM política para evitar que un dispositivo cierre involuntariamente la conexión de otro dispositivo utilizando un ID de cliente que ya esté en uso. Para obtener más información, consulte Autorización.
Todos los dispositivos de su flota deben tener credenciales con privilegios que autoricen únicamente las acciones previstas, que incluyen (pero no se limitan a) AWS IoT MQTT acciones como publicar mensajes o suscribirse a temas con un alcance y un contexto específicos. Las políticas de permisos específicas pueden variar en función de los casos de uso. Identifique las políticas de permisos que se ajusten mejor a sus requisitos empresariales y de seguridad.
Para simplificar la creación y la gestión de las políticas de permisos, puede utilizar AWS IoT Core variables de política las variables IAM de política. Las variables de la política se pueden colocar en una política y cuando se evalúa la política las variables se sustituyen por valores procedentes de la solicitud del dispositivo. Al usar variables de la política, puede crear una única política para la concesión de permisos a varios dispositivos. Puede identificar las variables de política relevantes para su caso de uso en función de la configuración de la AWS IoT cuenta, el mecanismo de autenticación y el protocolo de red utilizado para conectarse al agente de AWS IoT mensajes. Sin embargo, para escribir las mejores políticas de permisos, deben tenerse en cuenta los detalles concretos de su caso de uso y el modelo de amenazas
Por ejemplo, si ha registrado sus dispositivos en el AWS IoT registro, puede utilizar variables de política de cosas en las AWS IoT políticas para conceder o denegar permisos en función de las propiedades de las cosas, como los nombres, los tipos y los valores de los atributos de las cosas. El nombre de la cosa se obtiene del ID de cliente del mensaje de MQTT conexión que se envía cuando una cosa se conecta a ella AWS IoT. Las variables de política se sustituyen cuando una cosa se conecta MQTT mediante AWS IoT la autenticación TLS mutua o mediante el MQTT WebSocket protocolo mediante identidades autenticadas de Amazon Cognito. Puede utilizarla AttachThingPrincipalAPIpara adjuntar certificados e identidades autenticadas de Amazon Cognito a un objeto. iot:Connection.Thing.ThingNamees una variable de política útil para hacer cumplir las restricciones de identificación de los clientes. El siguiente ejemplo AWS IoT de política exige que se utilice el nombre de una cosa registrada como ID de cliente para MQTT las conexiones al agente de AWS IoT mensajes:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "iot:Connect", "Resource": [ "arn:aws:iot:us-east-1:123456789012:client/${iot:Connection.Thing.ThingName}" ] } ] }
Si quieres identificar los conflictos de ID de cliente en curso, puedes habilitar y usar CloudWatch Logs for AWS IoT. Para cada MQTT conexión que el agente de AWS IoT mensajes desconecte debido a conflictos de ID de cliente, se genera un registro similar al siguiente:
{ "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" }
Puede usar un filtro de CloudWatch registros, por ejemplo, {$.reason= "DUPLICATE_CLIENT_ID" } para buscar casos de conflictos de ID de cliente o para configurar los filtros de CloudWatch métricas y CloudWatch las alarmas correspondientes para una supervisión y generación de informes continuas.
Puede usar AWS IoT Device Defender
Puede utilizar AWS IoT Device Advisor para comprobar que sus dispositivos se pueden conectar de forma fiable AWS IoT Core y seguir las prácticas recomendadas de seguridad.
Véase también
Mantener sincronizado el reloj del dispositivo
Es importante que la hora del dispositivo sea precisa. Los certificados X.509 tienen una fecha y una hora de caducidad. El reloj del dispositivo se utiliza para comprobar que un certificado de servidor sigue siendo válido. Si está creando dispositivos IoT comerciales, recuerde que sus productos pueden permanecer en el almacén durante largos períodos de tiempo antes de venderse. Los relojes en tiempo real pueden retrasarse durante este tiempo y las baterías pueden descargarse, por lo que no es suficiente fijar el tiempo en fábrica.
En la mayoría de los sistemas, esto significa que el software del dispositivo debe incluir un cliente de protocolo de tiempo de red (NTP). El dispositivo debe esperar a que se sincronice con un NTP servidor antes de intentar conectarse a AWS IoT Coreél. Si esto no es posible, el sistema debería proporcionar un mecanismo para que el usuario establezca la hora del dispositivo, de forma que las conexiones posteriores se realicen correctamente.
Una vez que el dispositivo se haya sincronizado con un NTP servidor, podrá establecer una conexión con él. AWS IoT Core La cantidad de sesgo de reloj permitida dependerá de lo que esté tratando de hacer con la conexión.
Validar el certificado de servidor
Lo primero que hace un dispositivo para interactuar AWS IoT es abrir una conexión segura. Cuando conectes tu dispositivo a AWS IoT, asegúrate de que estás hablando con otro servidor AWS IoT y no haciéndote pasar por AWS IoT otro. Cada uno de los AWS IoT servidores está provisto de un certificado emitido para el dominio. iot.amazonaws.com Este certificado lo emitió una autoridad AWS IoT de certificación de confianza que verificó nuestra identidad y propiedad del dominio.
Una de las primeras cosas que se AWS IoT Core hace cuando un dispositivo se conecta es enviarle un certificado de servidor. Los dispositivos pueden comprobar que estaban esperando para conectarse a iot.amazonaws.com y que el servidor al final de dicha conexión posee un certificado de una autoridad de confianza para ese dominio.
TLSlos certificados están en formato X.509 e incluyen una variedad de información, como el nombre de la organización, la ubicación, el nombre de dominio y el período de validez. El período de validez se especifica como un par de valores de tiempo llamados notBefore y notAfter. Servicios como estos AWS IoT Core utilizan períodos de validez limitados (por ejemplo, un año) para sus certificados de servidor y comienzan a entregar los nuevos antes de que caduquen los antiguos.
Usar una identidad única por dispositivo
Utilice una identidad única por cliente. Los dispositivos generalmente usan certificados de cliente X.509. Las aplicaciones web y para móviles utilizan Amazon Cognito Identity. Esto le permite aplicar permisos detallados a sus dispositivos.
Por ejemplo, puede tener una aplicación que consiste en un dispositivo de teléfono móvil que recibe actualizaciones de estado de dos objetos de hogar inteligente diferentes: una bombilla y un termostato. La bombilla envía el estado de su nivel de batería y el termostato envía mensajes que informan de la temperatura.
AWS IoT autentica los dispositivos de forma individual y trata cada conexión de forma individual. Puede aplicar controles de acceso detallados a través de políticas de autorización. Puede definir una política para el termostato que le permita publicar en un espacio de tema. Puede definir una política independiente para la bombilla que le permita publicar en un espacio de tema diferente. Por último, puede definir una política para la aplicación móvil que solo le permita conectarse y suscribirse a los temas del termostato y la bombilla para recibir mensajes de estos dispositivos.
Aplique el principio de privilegios mínimos y amplíe los permisos por dispositivo tanto como sea posible. Todos los dispositivos o usuarios deben tener una AWS IoT política AWS IoT que solo les permita conectarse con un ID de cliente conocido y publicar y suscribirse a un conjunto de temas identificado y fijo.
Utilice un segundo Región de AWS como respaldo
Considere almacenar una copia de sus datos en un segundo Región de AWS como copia de seguridad. Tenga en cuenta que la AWS solución denominada Disaster Recovery for
Usar aprovisionamiento justo a tiempo
Crear y aprovisionar manualmente cada dispositivo puede llevar mucho tiempo. AWS IoT proporciona una forma de definir una plantilla para aprovisionar los dispositivos cuando se conectan por primera vez. AWS IoT Para obtener más información, consulte Just-in-time : aprovisionamiento.
Permisos para ejecutar pruebas de AWS IoT Device Advisor
La siguiente plantilla de políticas muestra los permisos y la IAM entidad mínimos necesarios para ejecutar los casos de prueba de AWS IoT Device Advisor. Tendrá que reemplazar your-device-role-arn con el rol de dispositivo Amazon Resource Name (ARN) que creó según los requisitos previos.
{ "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", "iotjobsdata:DescribeJobExecution", "iot:DescribeJob", "iot:DescribeThing", "iotjobsdata:GetPendingJobExecutions", "iot:GetPolicy", "iot:ListAttachedPolicies", "iot:ListCertificates", "iot:ListPrincipalPolicies", "iot:ListThingPrincipals", "iot:ListThings", "iot:Publish", "iotjobsdata:StartNextPendingJobExecution", "iotjobsdata:UpdateJobExecution", "iot:UpdateThingShadow", "logs:CreateLogGroup", "logs:CreateLogStream", "logs:DescribeLogGroups", "logs:DescribeLogStreams", "logs:PutLogEvents", "logs:PutRetentionPolicy" ], "Resource": "*" }, { "Sid": "VisualEditor2", "Effect": "Allow", "Action": "iotdeviceadvisor:*", "Resource": "*" } ] }
Prevención de la sustitución confusa entre servicios para Device Advisor
El problema de la sustitución confusa es un problema de seguridad en el que una entidad que no tiene permiso para realizar una acción puede obligar a una entidad con más privilegios a realizar la acción. En AWS, la suplantación de identidad entre servicios puede provocar un confuso problema de diputado. La suplantación entre servicios puede producirse cuando un servicio (el servicio que lleva a cabo las llamadas) llama a otro servicio (el servicio al que se llama). El servicio que lleva a cabo las llamadas se puede manipular para utilizar sus permisos a fin de actuar en función de los recursos de otro cliente de una manera en la que no debe tener permiso para acceder. Para evitarlo, AWS proporciona herramientas que le ayudan a proteger los datos de todos los servicios cuyos directores de servicio tengan acceso a los recursos de su cuenta.
Recomendamos utilizar las claves contextuales de condición global aws:SourceArn y aws:SourceAccount en las políticas de recursos para limitar los permisos que Device Advisor concede a otro servicio sobre el recurso. Si se utilizan ambas claves contextuales de condición global, el valor aws:SourceAccount y la cuenta del valor aws:SourceArn deben utilizar el mismo ID de cuenta cuando se utilicen en la misma declaración de política.
El valor de aws:SourceArn debe ser el recurso ARN de definición de su suite. El recurso de definición de conjuntos hace referencia al conjunto de pruebas que creó con Device Advisor.
La forma más eficaz de protegerse contra el confuso problema de los diputados es utilizar la clave del contexto ARN de la condición aws:SourceArn global con todo el recurso. Si no conoce la totalidad ARN del recurso o si está especificando varios recursos, utilice la clave de condición del contexto aws:SourceArn global con caracteres comodín (*) para las partes desconocidas delARN. Por ejemplo, arn:aws:iotdeviceadvisor:*: . account-id:suitedefinition/*
El siguiente ejemplo muestra cómo puede utilizar las claves contextuales de condición global aws:SourceArn y aws:SourceAccount en Device Advisor para evitar el problema de la sustitución confusa.
{ "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"} } } }
