Prácticas recomendadas de seguridad de AWS IoT Core
Esta sección contiene información sobre las prácticas de seguridad recomendadas 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
Protección de conexiones MQTT en AWS IoT
AWS IoT Core
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:
-
Su caso de uso (por ejemplo, los datos que los dispositivos envían a 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 del ID de cliente y sus posibles efectos negativos, asegúrese de que cada dispositivo o aplicación móvil tiene una política de AWS IoT o de IAM que restrinja qué identificadores de cliente pueden usarse en conexiones de MQTT con el agente de mensajes de AWS IoT. 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 la flota deben tener credenciales con privilegios que autoricen únicamente las acciones previstas; por ejemplo, acciones MQTT de AWS IoT, como la publicación de mensajes o la suscripción a temas con un ámbito 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 CoreVariables de las políticas de 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 la política relevantes para su caso de uso en función de su configuración de la cuenta de AWS IoT, el mecanismo de autenticación y el protocolo de red utilizado en la conexión al agente de mensajes de AWS IoT. 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 los dispositivos en el registro de AWS IoT, puede utilizar variables de la política de objetos en las políticas de AWS IoT para conceder o denegar permisos en función de las propiedades de un objeto, como el nombre o el tipo de objeto, o los valores de atributo de la cosa. El nombre de la cosa se obtiene a partir del ID de cliente del mensaje de MQTT Connect que se envía cuando un objeto se conecta a AWS IoT. Las variables de la política de objeto se sustituyen cuando un objeto se conecta con AWS IoT sobre MQTT empleando la autenticación mutua de TLS o MQTT sobre WebSocket mediante identidades de Amazon Cognito autenticadas. Puede usar la API AttachThingPrincipal para asociar certificados e identidades de Amazon Cognito autenticadas a un objeto. iot:Connection.Thing.ThingName es una variable de política de objetos útil para forzar la aplicación de las restricciones del ID de cliente. La siguiente política de AWS IoT de ejemplo requiere un nombre de la cosa registrado que se va a utilizar como el ID de cliente para las conexiones MQTT al agente de mensajes de AWS IoT:
Si desea identificar conflictos de ID de cliente en curso, puede habilitar y utilizar Registros de CloudWatch para AWS IoT. Por cada conexión MQTT que el agente de mensajes de AWS IoT desconecta debido a conflictos de ID de cliente, se genera un registro parecido a lo 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 Registros de CloudWatch como {$.reason= "DUPLICATE_CLIENT_ID" } para buscar instancias de conflictos de ID de cliente o para configurar filtros de métricas de CloudWatch y sus correspondientes alarmas de CloudWatch para la continua monitorización y generación de informes.
Puede utilizar AWS IoT Device Defender
Puede utilizar AWS IoT Device Advisor para comprobar que sus dispositivos se pueden conectar de forma fiable a 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 un dispositivo hace para interactuar con AWS IoT es abrir una conexión segura. Cuando conecte el dispositivo a AWS IoT, asegúrese de que está hablando con otro servidor AWS IoT y no a otro servidor que esté suplantando la identidad de AWS IoT. Cada uno de los servidores de AWS IoT se aprovisiona con un certificado emitido para el dominio iot.amazonaws.com. Este certificado fue emitido para AWS IoT por una autoridad de certificación de confianza que verificó nuestra identidad y propiedad del dominio.
Una de las primeras cosas que AWS IoT Core hace cuando se conecta un dispositivo es enviar al dispositivo 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. Algunos servicios como AWS IoT Core utilizan períodos de validez limitados (por ejemplo, un año) para los certificados de servidor y comienzan a proporcionar otros 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 por separado y trata cada conexión individualmente. 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 política de AWS IoT en AWS IoT que solo les permita conectarse con un ID de cliente conocido, así como publicar y suscribirse a un conjunto de temas identificado y fijo.
Utilice una segunda Región de AWS como copia de seguridad
Considere la posibilidad de almacenar una copia de sus datos en una segunda Región de AWS como copia de seguridad. Tenga en cuenta que la solución de AWS denominada Disaster Recovery for AWS IoT
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 dispositivos cuando se conectan por primera vez a AWS IoT. Para obtener más información, consulte Aprovisionamiento justo a tiempo.
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á reemplazar your-device-role-arn por el nombre de recurso de Amazon (ARN) del rol de dispositivo que creó según los requisitos previos.
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 entre servicios puede dar lugar al problema de la sustitución confusa. La suplantación entre servicios puedes 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 puedes 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 sus datos para todos los servicios con entidades principales de servicio a las que se les ha dado 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.
