Mejores prácticas de seguridad en AWS IoT Core - AWS IoT Core

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 (en inglés).

Protección de las conexiones MQTT en AWS IoT

AWS IoT Corees un servicio en la nube gestionado que permite que los dispositivos conectados interactúen con las aplicaciones en la nube y otros dispositivos de forma fácil y segura. AWS IoT Core es compatible con HTTP y MQTT, un protocolo de comunicación ligero diseñado específicamente para tolerar conexiones intermitentes. WebSocket Si se conecta AWS IoT mediante MQTT, cada una de sus conexiones debe estar asociada a un identificador conocido como ID de cliente. Los ID de cliente MQTT identifican de forma exclusiva conexiones MQTT. Si se establece una nueva conexión con un ID de cliente que ya se ha utilizado para otra conexión, el gestor de AWS IoT mensajes descarta la conexión anterior para permitir la nueva conexión. Los ID de cliente deben ser únicos en cada uno Cuenta de AWS de ellos Región de AWS. Esto significa que no necesitas imponer la exclusividad global de los ID de cliente fuera de tu región Cuenta de AWS o en todas las regiones de tu Cuenta de AWS región.

El impacto y la gravedad de la interrupción de las conexiones MQTT en su flota de dispositivos depende 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).

  • Su configuración de cliente MQTT (por ejemplo, configuración de reconexión automática, temporizaciones de interrupción asociadas y uso de sesiones persistentes de MQTT).

  • 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 impactos negativos, asegúrese de que cada dispositivo o aplicación móvil tenga una AWS IoT política de IAM que restrinja los ID de cliente que pueden usarse para las conexiones MQTT con el AWS IoT intermediario de mensajes. Por ejemplo, puede usar una política de IAM para evitar que un dispositivo cierre por error 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) las acciones de AWS IoT MQTT, 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 administración de políticas de permisos, puede utilizar AWS IoT Core variables de política y variables de la política de IAM. 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 su 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 conexión MQTT que se envía cuando una cosa se conecta a AWS IoT ella. Lo que las variables de política se sustituyen cuando una cosa se conecta a AWS IoT través de MQTT mediante la autenticación mutua TLS o MQTT a través del WebSocket protocolo mediante identidades autenticadas de Amazon Cognito. Puede usar la AttachThingPrincipalAPI para 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 de AWS IoT política exige que se utilice el nombre de un elemento registrado como ID de cliente para las conexiones MQTT con el intermediario 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 desea identificar los conflictos de ID de cliente en curso, puede habilitar y usar CloudWatch Logs for AWS IoT. Por cada conexión MQTT 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 utilizar 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 para identificar políticas excesivamente permisivas AWS IoT y de IAM. AWS IoT Device Defender también proporciona una verificación de auditoría que le notifica si varios dispositivos de su flota se están conectando al agente de AWS IoT mensajes con el mismo ID de cliente.

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 NTP (Protocolo de tiempo de red). El dispositivo debe esperar hasta que se sincronice con un servidor NTP antes de intentar conectarse a AWS IoT Core. 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 servidor NTP, podrá abrir una conexión con 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.

Los certificados TLS tienen formato X.509 e incluyen información diversa, como el nombre de la organización, la ubicación, el nombre de dominio y un 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 ya no AWS IoT está disponible. Si bien la GitHubbiblioteca asociada sigue siendo accesible, AWS quedó obsoleta en julio de 2023 y ya no proporciona mantenimiento ni soporte. Para implementar sus propias soluciones o explorar opciones de soporte adicionales, visite Contacto AWS. Si hay un administrador AWS técnico de cuentas asociado a tu cuenta, ponte en contacto con él para obtener ayuda.

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 mínimos y la entidad de IAM necesarios para ejecutar los casos de prueba de AWS IoT Device Advisor. Deberá sustituirlo por your-device-role-arnel 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", "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": "*" } ] }

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 el confuso problema de un 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 ARN de su recurso de definición de conjuntos. 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 problema de la sustitución confusa es utilizar la clave de contexto de condición global de aws:SourceArn con el ARN completo del recurso. Si no conoce el ARN completo del recurso o si especifica varios recursos, utilice la clave de condición de contexto global aws:SourceArn con comodines (*) para las partes desconocidas del ARN. 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" } } } }