Prácticas recomendadas para ejecutar un backend de IoT en Google Cloud

Last reviewed 2024-12-06 UTC

En este documento se describen las prácticas recomendadas de seguridad para gestionar y ejecutar un backend del Internet de las cosas (IoT) en Google Cloud. En una solución de IoT, un backend de IoT conecta los dispositivos perimetrales con otros recursos. Este documento se centra en los siguientes backends de IoT: el broker de Message Queuing Telemetry Transport (MQTT) y la plataforma de IoT.

Este documento forma parte de una serie de documentos que proporcionan información sobre las arquitecturas de IoT en Google Cloud y sobre la migración desde IoT Core. Los otros documentos de esta serie incluyen lo siguiente:

En este documento se describen las prácticas recomendadas para aprovisionar y gestionar credenciales de dispositivos, autenticar y acceder a dispositivos de control perimetrales, y permitir que los dispositivos perimetrales de IoT accedan a los recursos. Google Cloud

Arquitectura de IoT

Una arquitectura de IoT incluye servicios que te permiten aprovisionar y gestionar credenciales de dispositivos, autenticar y controlar el acceso a dispositivos perimetrales, y permitir que los dispositivos perimetrales accedan a recursos de Google Cloud . En este documento se describen dos arquitecturas de backend de IoT: una que usa un broker MQTT y otra que usa una plataforma de IoT. Las principales diferencias de seguridad entre estos dos back-ends son la identidad del dispositivo y la gestión de dispositivos. Las plataformas de IoT ofrecen estas funciones como parte de su sistema, mientras que los brokers de MQTT requieren que las proporciones tú.

En el siguiente diagrama se describe la arquitectura de IoT.

Arquitectura de backend de IoT.

La arquitectura muestra los servicios necesarios para los tres procesos siguientes:

  1. El aprovisionamiento de certificados, que es el proceso que debes completar para preparar un dispositivo perimetral para la configuración.

  2. Autenticación y autorización, que incluyen el esquema de autenticación que usan el dispositivo perimetral y el broker de MQTT o la plataforma de IoT para autenticarse entre sí.

  3. Conexiones entre dispositivos perimetrales y Google Cloud servicios, que son tareas que el dispositivo perimetral completa para conectarse a recursos en la nube y subir o descargar datos.

Este documento se centra principalmente en las prácticas recomendadas de seguridad para el aprovisionamiento y la autenticación.

La arquitectura usa una combinación de los siguientes servicios y funciones:

  • Un dispositivo periférico (como un dispositivo médico) que se implementa en los extremos de tu entorno y que está geográficamente cerca de los datos que quieres procesar. Los dispositivos perimetrales se conectan de forma bidireccional con tu backend de IoT, lo que significa que pueden enviar y recibir mensajes del backend de IoT.
  • Un backend de IoT que puede ser un broker de MQTT o una plataforma de IoT.
    • Un broker de MQTT proporciona una interfaz segura para que los dispositivos perimetrales se conecten mediante el protocolo MQTT. Los brokers de MQTT no tienen funciones para la identidad y la gestión de dispositivos, y dependen de sistemas externos para proporcionarlas.
    • Una plataforma de IoT es una aplicación en la nube a la que se conectan los dispositivos perimetrales y con la que se comunican. Las plataformas de IoT proporcionan una interfaz segura para que los dispositivos perimetrales se conecten mediante el protocolo MQTT. Cada plataforma de IoT tiene su propia implementación de seguridad, que determina cómo autentica y autoriza los dispositivos perimetrales, así como la forma en que gestiona las identidades de los dispositivos.
  • Un almacén de certificados central que aloja los certificados de todos los dispositivos perimetrales.
  • Recursos de la nube a los que deben acceder los dispositivos perimetrales.

Aprovisionar un dispositivo perimetral

Para que un dispositivo perimetral pueda conectarse con tus cargas de trabajo de backend, debes aprovisionar un certificado para el dispositivo perimetral. Hay dos situaciones principales que determinan cómo se aprovisiona el certificado:

  • Si tu solución se basa en dispositivos genéricos comerciales, tendrás control total sobre el proceso de aprovisionamiento después de comprar el dispositivo.

  • Si utilizas dispositivos personalizados, el proceso de aprovisionamiento inicial se lleva a cabo durante la fabricación de los dispositivos y debes integrar el proceso de aprovisionamiento con tus proveedores y fabricantes.

En ambos casos, debes crear certificados de dispositivo con una cadena de confianza que enlace a una autoridad de certificación (CA) raíz. Estos certificados autentican la identidad del dispositivo y ayudan a asegurar que las actualizaciones y modificaciones que se realicen en el dispositivo sean de agentes de confianza. Usa una AC como Certificate Authority Service para completar las siguientes tareas:

Para aprovisionar un certificado de dispositivo, debes completar las siguientes tareas:

Después de generar y firmar un certificado de dispositivo, instálalo en el dispositivo perimetral y guárdalo en un repositorio de certificados central, como Secret Manager.

Para obtener más información, consulta el artículo Cómo implementar una infraestructura de clave pública segura y fiable con el servicio de CA (PDF) Google Cloud .

Para obtener información sobre otras prácticas recomendadas de aprovisionamiento, consulta el artículo Prácticas recomendadas para aprovisionar y configurar automáticamente sistemas y servidores bare metal y de periferia.

Se usan tres tipos de certificados para proteger una solución de IoT:

  • El certificado de la AC raíz proporciona la raíz de la cadena de confianza de todos los demás certificados de tu sistema. Las cargas de trabajo del backend usan el certificado raíz para validar los certificados de cliente, y los dispositivos perimetrales usan el certificado raíz para validar el certificado de servidor. Debes distribuir el certificado raíz tanto al backend de IoT como a los dispositivos perimetrales.

  • Los certificados de las CAs intermedias proporcionan una cadena de confianza que se basa en la CA raíz. Puede usar CAs intermedias para el aprovisionamiento o para necesidades operativas, como conceder acceso a CAs intermedias a fabricantes o implementar procesos de gestión de CAs flexibles.

  • Los certificados de servidor se usan para proteger los endpoints que expone el backend de IoT. Tienes certificados de servidor para los diferentes algoritmos de cifrado que deben admitir tus endpoints. Los certificados del servidor están vinculados a la CA raíz. Un gestor de secretos gestiona y almacena tanto la parte privada como la pública de los certificados de servidor. Debes configurar tu backend de IoT con los certificados de servidor y sus claves privadas correspondientes.

  • Los certificados de cliente se usan para identificar los dispositivos perimetrales. Cada dispositivo perimetral tiene al menos un certificado de cliente, lo que significa que el número de certificados que tienes aumenta con el número de dispositivos perimetrales de tu entorno. Los certificados de cliente están vinculados a la AC raíz. Debes distribuir certificados de cliente a tus dispositivos perimetrales y al backend de IoT.

Proceso para generar un certificado de dispositivo mediante un HSM o un SE

En el siguiente diagrama se muestra cómo se aprovisiona un certificado de dispositivo cuando se usa un HSM o un SE.

Proceso para generar un certificado de dispositivo.

En este diagrama, se siguen estos pasos:

  1. El dispositivo perimetral genera el par de claves públicas en el hardware.
  2. Descarga la clave pública y crea la solicitud de firma de certificado (CSR) correspondiente.
  3. Envías la CSR a la AC para solicitar un certificado.
  4. La autoridad certificadora lleva a cabo las siguientes acciones:
    1. Firma el certificado.
    2. Devuelve el certificado firmado al proveedor.
  5. El proveedor completa las siguientes acciones:
    1. Envía el certificado firmado al dispositivo perimetral.
    2. Almacena el certificado firmado en el almacén de certificados central.
  6. El dispositivo perimetral almacena el certificado en una ubicación segura.

Proceso para generar un certificado de dispositivo mediante la AC

En el siguiente diagrama se muestra cómo se aprovisiona un certificado de dispositivo cuando se usa una AC.

Proceso para generar un certificado de dispositivo.

En este diagrama, se siguen estos pasos:

  1. El aprovisionador solicita que la AC envíe un certificado firmado para el dispositivo.
  2. La autoridad certificadora lleva a cabo las siguientes acciones:
    1. Genera un par de claves pública y privada, y firma la clave pública.
    2. Devuelve el certificado del dispositivo y la clave privada al aprovisionador.
  3. El proveedor completa las siguientes acciones:
    1. Envía el certificado y la clave privada al dispositivo perimetral.
    2. Almacena el certificado y la clave privada en el almacén de certificados central.
  4. El dispositivo perimetral almacena el certificado y la clave privada en una ubicación segura.

Si quieres almacenar la clave privada en un solo lugar (el dispositivo), no debes almacenarla en el almacén de secretos central. Sin embargo, si almacenas la clave privada fuera del almacén de secretos central y pierdes el acceso a ella, el dispositivo tendrá que volver a pasar por el proceso de aprovisionamiento.

Autenticar dispositivos antes de firmar certificados

El proceso para generar un certificado de dispositivo (ya sea en el dispositivo o mediante una AC) requiere que el dispositivo y la AC se comuniquen y se autentiquen entre sí.

Si no se autentica correctamente, es posible que su CA confíe por error en un dispositivo malicioso. Por ejemplo, un atacante que sepa cómo acceder a la infraestructura de firma de certificados de tu CA podría implementar un dispositivo malicioso que le pida a tu CA que firme un certificado. Si no tienes configurada la autenticación de dispositivos, es posible que tu autoridad de certificación firme el certificado que presente el dispositivo malicioso. Si tu CA firma el certificado, el dispositivo malicioso podrá comunicarse con tu backend como un dispositivo de confianza.

Para evitar que los dispositivos maliciosos se comuniquen con tu CA, te recomendamos que hagas lo siguiente:

  • Implementa un mecanismo de autenticación para los dispositivos que aún no sean de confianza.
  • Determinar la autenticidad de cualquier dispositivo que solicite autenticación.
  • Establece la autenticidad del dispositivo antes de que este solicite a la AC que genere un nuevo certificado o firme uno que ya tenga.

Implementar un mecanismo de autenticación en este punto del proceso de aprovisionamiento es complicado. No puedes usar certificados de dispositivo para autenticar dispositivos porque el dispositivo aún no tiene un certificado firmado de la CA. La falta de un certificado firmado puede deberse a los siguientes motivos:

  • El dispositivo aún no ha generado un certificado.
  • El dispositivo aún no ha enviado una CSR a la CA.
  • La AC aún no ha enviado el certificado firmado al dispositivo.

Una forma de solucionar este problema es ampliar el proceso de aprovisionamiento de dispositivos para hacer lo siguiente en cada dispositivo que quieras autenticar o que necesite autenticación:

  1. Genera un certificado de aprovisionamiento que solo utilices para autenticar el dispositivo en la infraestructura de firma de certificados.
  2. Firma el certificado de aprovisionamiento con tu AC.
  3. Almacena el certificado de aprovisionamiento firmado en el SE o el HSM del dispositivo.
  4. Almacena el certificado de aprovisionamiento firmado en tu backend de Google Cloud.

Antes de que se conceda acceso al dispositivo a la infraestructura de firma de certificados de tu CA, el dispositivo debe presentar el certificado de aprovisionamiento. Tiene que presentar el certificado para que puedas verificar su integridad y autenticidad, y determinar si coincide con uno de los certificados de aprovisionamiento almacenados en tu backend de Google Cloud . Si la verificación se realiza correctamente, el dispositivo podrá acceder a la infraestructura de firma de certificados de tu CA y el proceso de aprovisionamiento de certificados podrá continuar.

Hay diferencias entre un certificado de aprovisionamiento y un certificado de confianza total. Un certificado de aprovisionamiento solo concede acceso a una cantidad mínima de servicios e infraestructura. Al crear un certificado de aprovisionamiento, la CA puede verificar que el dispositivo es auténtico antes de considerarlo totalmente de confianza y emitir un certificado de plena confianza.

Una ampliación de este proceso es que puedes usar autoridades de certificación subordinadas a las que tengan acceso los fabricantes de dispositivos, junto con tu autoridad de certificación, para firmar certificados de aprovisionamiento. Por ejemplo, un fabricante puede firmar los certificados de aprovisionamiento de un dispositivo después de completar el proceso de fabricación de ese dispositivo. Después, puedes verificar estas firmas para validar que el dispositivo es auténtico.

Si un dispositivo se ve comprometido antes de aprovisionarse, te recomendamos que elimines el certificado de aprovisionamiento correspondiente de tu backend para que el dispositivo no pueda iniciar el proceso para obtener un certificado totalmente de confianza, ya que no podrá autenticarse en tu CA. Google Cloud

Prácticas recomendadas para la identidad de los dispositivos

En esta sección se describen las prácticas recomendadas para las identidades de los dispositivos.

Usar un proveedor de identidades con brokers MQTT

Los brokers de MQTT autentican los dispositivos perimetrales mediante las credenciales de dispositivo proporcionadas por plugins, bases de datos y archivos. Para gestionar las identidades de tus dispositivos de forma sistemática y escalable, usa un proveedor de identidades (IdP). El proveedor de identidades gestiona las identidades y las credenciales de todos los dispositivos y actúa como fuente de información veraz principal para las identidades de los dispositivos.

Para mantener actualizada la identidad del dispositivo en el broker MQTT, implementa una capa de integración específica del sistema. Para obtener más información sobre cómo gestionar las credenciales de los dispositivos, consulta Aprovisionar un dispositivo perimetral.

Usar las identidades digitales de la plataforma de IoT como fuente de información principal

La plataforma de IoT tiene funciones de seguridad que gestionan las identidades y las credenciales de los dispositivos, así como autentican y autorizan a los dispositivos que intentan acceder a la plataforma. Estas funciones de seguridad ayudan a garantizar que solo los dispositivos autorizados puedan acceder a la plataforma de IoT y que los datos estén íntegros.

Verifica que las identidades de los dispositivos gestionadas por la plataforma de IoT representan la fuente de información veraz principal de todos los dispositivos que gestiona la plataforma de IoT. Otros componentes de una solución de IoT que necesiten información de identidad de dispositivo deben basarse en el sistema de seguridad de la plataforma de IoT. La plataforma del Internet de las cosas concede derechos de acceso a los dispositivos y propaga cualquier cambio de seguridad en toda la solución del Internet de las cosas.

Prácticas recomendadas para la conectividad de red

Proteger la conectividad de red es importante por los siguientes motivos:

  • Las redes seguras ayudan a garantizar que un dispositivo se conecte al backend correcto. Por ejemplo, una red segura puede evitar la suplantación de DNS, que es un ataque que intenta desviar los dispositivos para que se conecten a un backend no autorizado controlado por atacantes.
  • Las redes seguras ayudan a garantizar que terceros no puedan leer el tráfico de tus datos. Por ejemplo, una red segura puede evitar un ataque de intermediario, en el que los atacantes leen el tráfico entre tu dispositivo y el backend.

Usa Seguridad en la capa de transporte (TLS) para proteger la comunicación de red entre tus dispositivos perimetrales y las cargas de trabajo del backend.

Amplía TLS con mTLS para implementar un esquema de autenticación mutua que permita a ambas partes conectadas establecer la identidad de la otra.

Para obtener instrucciones sobre cómo usar TLS, consulta Arquitectura de broker MQTT independiente en Google Cloud y Arquitectura de producto de plataforma de IoT en Google Cloud.

Prácticas recomendadas para gestionar certificados de brokers MQTT

En esta sección se describen las prácticas recomendadas para gestionar certificados al usar brokers de MQTT.

Almacenar certificados de forma centralizada

Almacena y gestiona los certificados de servidor y de dispositivo en una ubicación central. En concreto, asegúrese de que ha implementado los siguientes controles:

  • Un inventario de todos tus dispositivos y sus certificados, así como de los endpoints del servidor y sus certificados.
  • Información adicional sobre los certificados, como su validez.
  • Posibilidad de añadir y quitar certificados de dispositivos para que estos puedan conectarse con certificados nuevos.
  • Derechos de acceso a tu almacén de certificados central para limitar lo que pueden hacer las diferentes funciones de tu backend con los certificados.

Usa una solución de almacenamiento y gestión de secretos, como Secret Manager o HashiCorp Vault. Secret Manager te permite crear versiones, actualizar e invalidar credenciales de dispositivos, así como gestionar las políticas de acceso a tus credenciales.

En una plataforma de IoT, implementa el acceso a las credenciales mediante el acceso a la API Secret Manager.

Proteger los certificados en dispositivos perimetrales

Para almacenar certificados y claves en los dispositivos perimetrales, utiliza un entorno de ejecución de confianza local o un almacén de certificados para proteger las credenciales y bloquear los accesos no autorizados. Si necesitas almacenar material secreto en tus dispositivos, cifra ese material con técnicas como el cifrado flash y guárdalo en elementos a prueba de manipulaciones para evitar que se extraigan datos sin autorización.

Sincronizar el almacén de certificados central con el almacén de certificados del broker MQTT

Los brokers de MQTT deben acceder a los certificados de cliente para la autenticación basada en certificados, por lo que debes sincronizar los almacenes de certificados de los brokers de MQTT con el almacén de certificados central. Verifica que los cambios en el almacén de certificados central, como añadir, actualizar y eliminar certificados, se sincronicen con el almacén de certificados del broker MQTT. Los brokers de MQTT usan almacenes de certificados, como MySQL, PostgresDB y Java Key Store. En función del almacén de certificados que use tu broker MQTT, asegúrate de que se hayan llevado a cabo los siguientes procesos:

  • Un proceso que monitoriza los cambios en el almacén de certificados central y notifica al proceso de sincronización.
  • Proceso que toma los cambios del almacén de certificados central y los sincroniza con el almacén de certificados que usa el broker de MQTT.

Si utiliza Secret Manager como almacén de certificados, puede usar las notificaciones de eventos como proceso de monitorización. Puedes implementar el proceso de sincronización como un listener de las notificaciones de eventos.

Distribuir certificados a dispositivos perimetrales de forma segura

Cuando utilices brokers de MQTT, distribuye el certificado raíz y los certificados de cliente a tus dispositivos perimetrales. Cuando distribuyas certificados, debes proteger tus canales de comunicación para que no se intercepte el tráfico.

Los principales canales de comunicación para la distribución de certificados son los siguientes:

  • Una ruta directa desde el backend de IoT a los dispositivos perimetrales a través de los canales de comunicación existentes.
  • Una ruta indirecta en la que los dispositivos perimetrales solicitan y descargan los certificados.

Durante la distribución de certificados, necesitas los siguientes componentes:

  • Un almacén de certificados en el que se gestionan los certificados de forma centralizada.
  • Un coordinador de distribución que envía los certificados y monitoriza el proceso de distribución de cada dispositivo perimetral.
  • Un gestor de actualizaciones en el dispositivo perimetral que recibe o descarga los certificados y los almacena en el dispositivo.

Distribuye certificados durante los procesos de aprovisionamiento de dispositivos perimetrales y cuando necesites rotar certificados.

Durante el proceso de aprovisionamiento, asegúrate de que el aprovisionador tenga acceso directo a los dispositivos perimetrales a través de canales cifrados, como SSH, y de que utilice herramientas como SCP. Como los dispositivos no están en funcionamiento, puedes enviar certificados directamente a los dispositivos perimetrales.

Cuando rotes los certificados, usa el broker MQTT como canal de comunicación entre el coordinador de distribución y los dispositivos perimetrales. Usa otros canales para descargar certificados en el dispositivo. Para minimizar las interrupciones de los dispositivos perimetrales en funcionamiento, utiliza una ruta de distribución de certificados indirecta. El proceso constaría de los siguientes pasos lógicos:

  1. El coordinador de distribución obtiene las credenciales de acceso del almacén de certificados.
  2. El coordinador de distribución envía las credenciales de acceso al certificado a los dispositivos perimetrales junto con información adicional, como la URL de descarga.
  3. El controlador de actualizaciones en el dispositivo recibe las credenciales de acceso y almacena temporalmente la información y confirma la recepción.
  4. El controlador de actualizaciones coordina la descarga del certificado cuando el dispositivo no está activo. El controlador de actualizaciones usa las credenciales de acceso para descargar certificados del almacén de credenciales.
  5. Una vez descargados los certificados, el controlador de actualizaciones continúa con el proceso de rotación de certificados, que se describe en la sección Rotación de certificados.

Si usas Secret Manager como almacén de certificados central, puedes generar tokens de acceso de corta duración para conceder y restringir el acceso a los certificados. Para obtener más información, consulta Distribuir tokens de acceso a dispositivos de forma segura.

Para evitar que los certificados se expongan durante el tránsito, cifra la conexión entre tus dispositivos perimetrales y el broker MQTT. Para obtener más información, consulta las prácticas recomendadas para la conectividad de red.

Rotar certificados automáticamente

Para limitar los daños que puede causar un certificado expuesto, genera certificados con un periodo de validez finito y rota los certificados antes de que caduquen. En las implementaciones de IoT a gran escala, implementa un procedimiento de rotación automática de certificados para actualizar constantemente tus dispositivos con nuevos certificados antes de que caduquen los antiguos. Si los dispositivos implementados no tienen certificados válidos, pueden dejar de funcionar, lo que puede resultar caro de solucionar y afectar negativamente a la funcionalidad general de tu solución de IoT.

Tus dispositivos perimetrales deben conectarse bidireccionalmente con tu broker de MQTT para asegurarse de que pueden enviar mensajes al broker de MQTT y de que pueden recibir mensajes del broker de MQTT.

Durante la rotación de certificados, necesitas los siguientes componentes:

  • Un proceso de monitorización que analiza de forma recurrente tu inventario de certificados y busca los que están a punto de caducar. El proceso de monitorización activa la rotación de los certificados que van a caducar.
  • Un proceso de rotación que inicializa y supervisa la rotación de certificados.
  • Un controlador de rotación de certificados de dispositivo en el dispositivo perimetral que se comunica con el broker MQTT y ejecuta los pasos de rotación de certificados en el dispositivo.

Para rotar los certificados, la solución de IoT sigue estos pasos:

  1. El proceso de rotación envía un mensaje de inicialización al dispositivo perimetral para iniciar la rotación del certificado.
  2. El controlador de rotación de certificados de dispositivo confirma el mensaje de inicialización enviando una respuesta al trabajo de rotación.
  3. El proceso de rotación solicita un nuevo certificado a la AC. Esta solicitud es similar a la solicitud de aprovisionamiento de certificados, salvo que las claves y la CSR se envían como mensajes del broker MQTT.
  4. Después de recibir el nuevo certificado de la AC, el trabajo de rotación distribuye el certificado al almacén de certificados central y al dispositivo perimetral. También sincroniza el certificado con el almacén de certificados del broker MQTT.
  5. El controlador de rotación de certificados de dispositivo almacena el nuevo certificado e inicializa una nueva conexión con el broker MQTT mediante el nuevo certificado.
  6. Una vez establecida la nueva conexión, el controlador de rotación de certificados del dispositivo envía un mensaje de finalización al broker de MQTT.
  7. Una vez que se recibe el mensaje completado, el proceso de rotación invalida el certificado antiguo en el almacén de certificados central.

Para proteger los certificados que se envían durante el proceso de rotación, usa temas MQTT específicos para la rotación de certificados. Limita el acceso a estos temas solo al trabajo de rotación y al dispositivo perimetral.

Para proteger el proceso de rotación de certificados frente a errores de tiempo de ejecución, habilita la persistencia de los cambios y el progreso.

Para obtener más información sobre cómo rotar secretos con Secret Manager, consulta Rotación de secretos.

Prácticas recomendadas para gestionar certificados en plataformas de IoT

Si utilizas una plataforma de IoT, usa los mecanismos de actualización y distribución de certificados que proporcione la plataforma. Para crear copias de seguridad, puedes exportar periódicamente las credenciales de tu plataforma de IoT a un almacenamiento de secretos secundario, como Secret Manager.

Prácticas recomendadas para la autenticación con un broker MQTT

Durante el proceso de autenticación mutua, las cargas de trabajo del backend verifican la identidad de los dispositivos perimetrales y los dispositivos perimetrales verifican la identidad de las cargas de trabajo del backend. Una vez que las cargas de trabajo del backend confirman la identidad del dispositivo perimetral, las cargas de trabajo del backend autorizan el acceso del dispositivo a los recursos.

En las siguientes secciones se describen las prácticas recomendadas para los métodos de autenticación al usar brokers MQTT.

Elegir el método de autenticación para los brokers de MQTT

Los diferentes back-ends de IoT admiten distintos métodos de autenticación. Los métodos que se suelen usar son los siguientes:

  • Autenticación con nombre de usuario y contraseña: el dispositivo perimetral presenta su nombre de usuario y su contraseña para verificar su identidad.
  • Autenticación basada en tokens: se usan tokens de seguridad cifrados para verificar la identidad del dispositivo perimetral.
  • Esquemas de autenticación personalizados: implementa un mecanismo personalizado para verificar la identidad del dispositivo perimetral.

Como parte del estándar MQTT, los brokers de MQTT admiten la autenticación con nombre de usuario y contraseña como valor predeterminado para los paquetes MQTT CONNECT.

El paquete MQTT CONNECT también contiene un campo Client Identifier que puedes usar para identificar de forma única al cliente en el broker de MQTT. Los dispositivos perimetrales envían el paquete MQTT CONNECT al broker de MQTT cuando establecen una conexión.

Además de los campos de nombre de usuario, contraseña e identificador de cliente del paquete MQTT CONNECT, MQTT 5.0 admite la autenticación mejorada, que te permite crear flujos de autenticación challenge-response. MQTT 5.0 permite varios AUTH intercambios de paquetes entre el dispositivo perimetral y el broker de MQTT.

Usar almacenes de contraseñas con autenticación mediante nombre de usuario y contraseña

Para la autenticación con nombre de usuario y contraseña, configura el broker de MQTT para que use un almacén de contraseñas. El almacén de contraseñas proporciona una ubicación centralizada para gestionar las contraseñas de todos los dispositivos perimetrales que se conectan al broker MQTT. De forma predeterminada, los campos de nombre de usuario, contraseña e identificador de cliente son opcionales en la especificación de MQTT. Por lo tanto, diseña tu mecanismo de autenticación para verificar que los campos de nombre de usuario, contraseña e identificador de cliente estén presentes en el paquete MQTT CONNECT.

Asegúrate de que las contraseñas estén cifradas en reposo y en tránsito, de la siguiente manera:

Considerar la autenticación basada en tokens

Con la autenticación basada en tokens, los dispositivos perimetrales envían un token al broker de MQTT para autenticarse. Los dispositivos pueden generar el token por sí mismos u obtenerlo de otros servicios de autenticación. En comparación con las contraseñas, los tokens tienen una duración breve: solo son válidos durante un periodo con una fecha de vencimiento explícita. Comprueba siempre si han caducado al validar tokens.

Los tokens web JSON (JWT) son una forma de implementar la autenticación basada en tokens. Los dispositivos perimetrales pueden generar el JWT y autenticarse con el broker MQTT. El JWT se inserta en el paquete CONNECT de MQTT como campo de contraseña.

Estas son las ventajas de JWT:

  • JWT te permite elegir el algoritmo de cifrado que se usa para firmar el token. JWT funciona bien con dispositivos periféricos con limitaciones, en los que puedes usar un algoritmo de cifrado que consuma menos recursos, como ECC, para firmar el token.
  • Mediante la criptografía de clave pública, la clave privada solo se usa en el dispositivo perimetral y nunca se comparte con terceros. Una clave privada ayuda a que este método sea más seguro que la autenticación con nombre de usuario y contraseña, en la que las credenciales se envían a través de la conexión y requieren el cifrado de los datos.

Considerar esquemas de autenticación personalizados

Algunos brokers de MQTT admiten diferentes mecanismos y protocolos de autenticación. Por ejemplo, si tu broker de MQTT admite esquemas de autenticación personalizados, puedes configurarlo para que admita lo siguiente:

Prácticas recomendadas para el control de acceso y la autorización de dispositivos

Debido al patrón de comunicación entre editores y suscriptores del protocolo MQTT, el control de acceso a los dispositivos se define mediante temas de MQTT. Los temas de MQTT controlan cómo puede comunicarse un dispositivo con tu backend de IoT. Cada backend de IoT tiene implementaciones diferentes para el control de acceso y la autorización, por lo que debes consultar la documentación del backend de IoT para ver las opciones sobre cómo configurar los temas MQTT.

Usar cuentas de servicio específicas para acceder a los Google Cloud recursos

El acceso a los Google Cloud recursos se gestiona mediante políticas de permiso de gestión de identidades y accesos que vinculan el permiso de acceso a los recursos con un conjunto de principales. Las entidades principales típicas son las cuentas de usuario, las cuentas de servicio y los grupos. Las cuentas de servicio suelen usarse en aplicaciones o cargas de trabajo de computación para hacer llamadas a APIs autorizadas de recursos en la nube. Las cuentas de servicio permiten que los dispositivos perimetrales de IoT accedan a recursos en la nube.

Como la identidad del dispositivo la gestiona el backend de IoT, debes asignar una identidad entre el backend de IoT y IAM para que el dispositivo perimetral pueda acceder a losGoogle Cloud recursos.

Si gestionas un gran número de dispositivos, el límite del número de cuentas de servicio por proyecto hace que sea inviable tener una asignación directa individual entre el dispositivo y la cuenta de servicio. Google Cloud

En su lugar, crea cuentas de servicio vinculadas a los recursos en la nube a los que necesite acceder tu solución de IoT, tal como se describe en el artículo sobre cómo crear cuentas de servicio para un solo propósito. Por ejemplo, crea una cuenta de servicio única para cada uno de los siguientes casos de uso:

  • Descargando paquetes de actualización de software
  • Subir archivos multimedia de gran tamaño
  • Ingerir datos de un flujo de latencia

Para implementar el principio de mínimos privilegios, asegúrate de que cada cuenta de servicio solo tenga los derechos de acceso suficientes para admitir su caso práctico. Por ejemplo, en el caso de una cuenta de servicio que se utilice para descargar paquetes de software, solo se debe conceder acceso de lectura al segmento de Cloud Storage.

Distribuir tokens de acceso a dispositivos de forma segura

Normalmente, los dispositivos perimetrales se comunican con tu plataforma de IoT mediante MQTT. Sin embargo, en casos prácticos específicos, es posible que tus dispositivos necesiten acceso directo a losGoogle Cloud recursos. Por ejemplo, plantéate lo siguiente:

  • Para descargar contenido, un dispositivo perimetral requiere acceso de solo lectura a un segmento de Cloud Storage únicamente durante el proceso de descarga.
  • Para subir datos a un segmento de Cloud Storage, un dispositivo perimetral necesita acceso de escritura al segmento.

En estos casos, usa la federación de identidades de cargas de trabajo, donde se concede acceso a los recursos de Google Cloud mediante tokens de acceso. La federación de identidades de cargas de trabajo elimina la necesidad de aprovisionar credenciales específicas de la nube en los dispositivos perimetrales, y la distribución del acceso se realiza de forma dinámica en función de la demanda.

Para distribuir tokens de acceso a recursos en la nube a tus dispositivos, configura la federación de identidades de carga de trabajo entre tu proveedor de identidades de dispositivo yGoogle Cloud. Para admitir la federación de identidades de cargas de trabajo, asegúrate de que tu backend de IoT cumpla los requisitos de la federación de identidades de cargas de trabajo y siga las prácticas recomendadas de seguridad que se ajusten a tus casos de uso.

Para acceder a los recursos de Google Cloud mediante la federación de identidades de carga de trabajo, tus dispositivos perimetrales deben implementar el flujo de trabajo de intercambio de tokens de OAuth 2.0, que consta de los siguientes pasos:

  • El dispositivo llama al servicio de token de seguridad y proporciona sus propias credenciales de dispositivo.
  • El servicio de tokens de seguridad verifica la identidad del dispositivo perimetral validando las credenciales que el dispositivo perimetral ha proporcionado con el proveedor de identidad del dispositivo.
  • Si la verificación de identidad se realiza correctamente, el servicio de tokens de seguridad devuelve un token de acceso al dispositivo perimetral.
  • El dispositivo perimetral usa ese token para suplantar la identidad de la cuenta de servicio de un solo uso y obtiene un token de acceso de OAuth 2.0 de corta duración.
  • El dispositivo usa el token de acceso de OAuth 2.0 de corta duración para autenticarse con las APIs de Google Cloud y obtener acceso a los recursos de la nube necesarios.

Para restringir el acceso del token de acceso de corta duración a segmentos y objetos específicos de Cloud Storage, usa los límites de acceso de credenciales. Los límites de acceso a credenciales te permiten limitar el acceso a la credencial de corta duración y minimizar el número de recursos que se exponen en tus segmentos de Cloud Storage cuando se vulnera un token de acceso.

La federación de identidades de cargas de trabajo es una forma escalable de distribuir de forma segura el acceso a la nube a los dispositivos perimetrales. Para obtener más información sobre la autenticación, consulta el artículo Autenticación en Google.

Monitorizar y auditar el acceso a recursos en la nube

Habilita los registros de auditoría de Cloud para crear entradas de registro cuando tus dispositivos perimetrales accedan a recursos en la nube a través de solicitudes de API autenticadas. Los registros de auditoría de Cloud te permiten monitorizar las acciones críticas que realizan tus dispositivos perimetrales enGoogle Cloud. Además, Cloud Audit Logs crea los registros y las trazas de auditoría que necesitas para investigar cualquier problema. Para obtener más información, consulta Suplantar la identidad de una cuenta de servicio para acceder a Google Cloud.

Siguientes pasos

Colaboradores

Autores:

  • Charlie Wang | Arquitecto de soluciones en la nube
  • Marco Ferrari | Arquitecto de soluciones en la nube