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

Last reviewed 2023-02-08 UTC

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

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

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

Arquitectura de IoT

Una arquitectura de IoT incluye servicios que te permiten aprovisionar y administrar credenciales de dispositivos, autenticar y acceder a dispositivos perimetrales de control, y permitir que los dispositivos perimetrales accedan a los recursos de Google Cloud. En este documento, se analizan dos arquitecturas de backend de IoT: una que usa el agente de MQTT y la otra mediante una plataforma de IoT. Las diferencias de seguridad principales entre estos dos backends son la administración y la identidad del dispositivo. Las plataformas de IoT proporcionan estas capacidades como parte de su sistema, mientras que los agentes de MQTT requieren que proporciones estas capacidades.

En el siguiente diagrama, se describe la arquitectura de IoT.

Arquitectura de backend de IoT.

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

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

  2. La autenticación y la autorización, que incluyen el esquema de autenticación que el dispositivo perimetral y el agente de MQTT o la plataforma de IoT usan para autenticarse.

  3. Conexiones entre dispositivos perimetrales y servicios de Google Cloud, 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 perimetral (como un dispositivo médico) que implementas en los perímetros de tu entorno y que está geográficamente cerca de los datos que deseas procesar. Los dispositivos perimetrales se conectan de forma bidireccional con el backend de IoT, lo que significa que pueden enviar y recibir mensajes desde el backend de IoT.
  • Un backend de IoT que puede ser un agente de MQTT o una plataforma de IoT
    • Un agente de MQTT proporciona una interfaz segura para que los dispositivos perimetrales se conecten mediante el protocolo MQTT. Los agentes de MQTT no tienen capacidades para la identidad y la administración de dispositivos, y dependen de los sistemas externos para proporcionarlos.
    • Una plataforma de IoT es una aplicación en la nube con la que los dispositivos perimetrales se conectan y 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 dispositivos perimetrales y cómo administra las identidades de los dispositivos.
  • Un almacén de certificados central que aloja los certificados para todos los dispositivos perimetrales.
  • Recursos en la nube a los que deben acceder los dispositivos perimetrales.

Aprovisiona un dispositivo perimetral

Antes de que un dispositivo perimetral pueda conectarse con tus cargas de trabajo de backend, debes aprovisionar un certificado para el dispositivo perimetral. Existen dos situaciones principales en las que se decide cómo aprovisionar el certificado:

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

  • Si usas dispositivos personalizados, el proceso de aprovisionamiento inicial ocurre durante la fabricación de los dispositivos y debes integrar el proceso de aprovisionamiento con tus proveedores y fabricantes.

En cualquier caso, debes crear certificados de dispositivo con una cadena de confianza que se vincule a una autoridad certificadora (CA) raíz. Estos certificados autentican la identidad del dispositivo y ayudan a garantizar que las actualizaciones y modificaciones que se realizan en el dispositivo sean de actores confiables. Usa una CA como Certificate Authority Service para completar las siguientes tareas:

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

  1. Generar el par de claves públicas/privadas mediante una solución de seguridad basada en hardware que sea compatible con tu dispositivo, como un elemento seguro (SE) o un módulo seguro de hardware (HSM). Por diseño, el SE o HSM almacena las claves privadas de manera local, y las claves privadas nunca se exponen de forma externa. Si no usas una solución de seguridad basada en hardware para generar un par de claves públicas/privadas, usa la CA a fin de generar claves. Para obtener más información, consulta Usa una clave generada de forma automática.

  2. Firmar y generar un certificado de dispositivo. Después de generar el par de claves públicas/privadas, descarga la clave pública, crea una solicitud de firma de certificado (CSR) y envía la CSR a la CA para que la firme. La CA genera un certificado de dispositivo que está vinculado a la CA raíz. Para obtener más información, consulta Usa una CSR. Cuando usas claves generadas de forma automática, puedes solicitar un certificado de dispositivo directamente a la CA.

  3. Instalar el certificado del dispositivo firmado en el dispositivo perimetral y enviar el certificado a un repositorio de certificado central, como Secret Manager.

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

Si deseas obtener información sobre otras prácticas recomendadas de aprovisionamiento, consulta Prácticas recomendadas para aprovisionar y configurar de forma automática sistemas y servidores perimetrales y de equipos físicos.

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

  • El certificado de CA raíz proporciona la raíz para la cadena de confianza de todos los demás certificados de tu sistema. Las cargas de trabajo de 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 del servidor. Debes distribuir el certificado raíz al backend de IoT y a los dispositivos perimetrales.

  • Los certificados del servidor se usan para proteger los extremos que expone el backend de IoT. Tienes certificados de servidor para los diferentes algoritmos de encriptación que tus extremos necesitan admitir. Los certificados de servidor están vinculados a la CA raíz. Un administrador de secretos administra y almacena las partes privadas y públicas 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 dispositivos perimetrales. Cada dispositivo perimetral tiene al menos un certificado de cliente, lo que significa que la cantidad de certificados que tienes aumenta con la cantidad de dispositivos perimetrales en tu entorno. Los certificados de cliente están vinculados a la CA raíz. Debes distribuir certificados de cliente a tus dispositivos perimetrales y al backend de IoT.

Proceso para generar un certificado de dispositivo mediante HSM o SE

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

Proceso para generar un certificado de dispositivo.

En este diagrama, se producen los siguientes pasos:

  1. El dispositivo perimetral genera el par de claves públicas en el hardware.
  2. Debes descargar la clave pública y crear su solicitud de firma de certificado (CSR).
  3. Envías la CSR a la CA para solicitar un certificado.
  4. La CA completa las siguientes acciones:
    1. Firma el certificado.
    2. Muestra el certificado de dispositivo al aprovisionador.
  5. El aprovisionador completa las siguientes acciones:
    1. Envía el certificado al dispositivo perimetral.
    2. Almacena el certificado 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 con la CA

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

Proceso para generar un certificado de dispositivo.

En este diagrama, se producen los siguientes pasos:

  1. Generas una CSR y la envías a la CA para solicitar un certificado.
  2. La CA completa las siguientes acciones:
    1. Genera un par de claves públicas y lo firma.
    2. Muestra el certificado de dispositivo y la clave privada al aprovisionador.
  3. 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 en una ubicación segura.

Prácticas recomendadas para la identidad de dispositivos

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

Usa un proveedor de identidad con agentes de MQTT

Los agentes de MQTT autentican los dispositivos perimetrales mediante las credenciales de dispositivo que proporcionan los complementos, las bases de datos y los archivos. Para administrar las identidades de tu dispositivo de manera sistemática y escalable, usa un proveedor de identidad (IdP). El IdP administra las identidades y las credenciales de todos los dispositivos y actúa como la principal fuente de información para las identidades de los dispositivos.

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

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

La plataforma de IoT tiene funciones de seguridad que administran las identidades y las credenciales de los dispositivos, y autentican y autorizan 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 ayudan a garantizar la integridad de los datos.

Verifica que las identidades del dispositivo administradas por la plataforma de IoT representen la fuente de información principal de todos los dispositivos que administra la plataforma de IoT. Otros componentes de una solución de IoT que necesitan información de identidad de los dispositivos deben depender del sistema de seguridad de la plataforma de IoT. La plataforma de IoT otorga derechos de acceso a los dispositivos y propaga cualquier cambio de seguridad en toda la solución de IoT.

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 falsificación de identidad de DNS, que es un ataque que intenta desviar los dispositivos para conectarse a un backend fraudulento controlado por atacantes.
  • Las redes seguras ayudan a garantizar que terceros no puedan leer tu tráfico de datos. Por ejemplo, una red segura puede evitar un ataque de atacantes en el medio, en el que los atacantes leen el tráfico entre tu dispositivo y el backend.

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

Extiende TLS con mTLS para implementar un esquema de autenticación mutua que permita que ambas partes conecten establecer las identidades entre sí.

Para obtener instrucciones sobre el uso de TLS, consulta Arquitectura del agente de MQTT independiente en Google Cloud y Arquitectura de productos de la plataforma de IoT en Google Cloud.

Prácticas recomendadas para la administración de certificados para agentes de MQTT

En esta sección, se describen las prácticas recomendadas para administrar certificados cuando se usan agentes de MQTT.

Almacena certificados de forma centralizada

Almacena y administra certificados de servidor y certificados de dispositivo en una ubicación central. Específicamente, asegúrate de tener los siguientes controles:

  • Un inventario de todos tus dispositivos y sus certificados, y los extremos del servidor y sus certificados.
  • Información adicional sobre los certificados, como su validez.
  • La capacidad de agregar y quitar certificados para dispositivos a fin de que los dispositivos puedan conectarse mediante certificados nuevos
  • Accede a los derechos de tu almacén de certificados central para limitar lo que pueden hacer los diferentes roles de tu backend con los certificados.

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

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

Protege certificados en dispositivos perimetrales

Para almacenar certificados y claves en los dispositivos perimetrales, usa un entorno de ejecución confiable o un almacén de certificados local para proteger la credencial y bloquear los accesos no autorizados. Si necesitas almacenar material secreto en tus dispositivos, encripta ese material mediante técnicas como la encriptación Flash y almacénalo en elementos a prueba de manipulación para evitar extracciones de datos no autorizados.

Sincroniza el almacén de certificados central con el almacén de certificados del agente de MQTT

Los agentes 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 agentes de MQTT con el almacén de certificados central. Verifica que los cambios en el almacén de certificados central, como agregar, actualizar y borrar certificados, estén sincronizados con el almacén de certificados del agente de MQTT. Los agentes de MQTT usan almacenes de certificados, como MySQL, PostgresDB y Java Key Store. Según el almacén de certificados que use tu agente de MQTT, asegúrate de que existan los siguientes procesos:

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

Cuando usas Secret Manager como tu almacén de certificados, puedes usar notificaciones de eventos como el proceso de supervisión. Puedes implementar el proceso de sincronización como un objeto de escucha de las notificaciones de eventos.

Distribuye certificados a dispositivos perimetrales de forma segura

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

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 del certificado, necesitas los siguientes componentes:

  • Un almacén de certificados en el que los certificados se administran de manera central.
  • Un coordinador de distribución que envía los certificados y realiza un seguimiento del proceso de distribución para cada dispositivo perimetral.
  • Un controlador de actualización en el dispositivo perimetral que recibe o descarga los certificados y los almacena en el dispositivo.

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

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

Cuando rotes certificados, usa el agente de MQTT como el 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 la interrupción de los dispositivos perimetrales en funcionamiento, usa una ruta de distribución de certificados indirecta. El proceso constaría de los siguientes pasos lógicos:

  1. El coordinador de distribución adquiere credenciales de acceso desde el 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 actualización integrado en el dispositivo recibe las credenciales de acceso y almacena la información de forma temporal y confirma la recepción.
  4. El controlador de actualización coordina la descarga del certificado cuando el dispositivo no está activo. El controlador de actualización usa las credenciales de acceso para descargar certificados del almacén de credenciales.
  5. Después de descargar los certificados, el controlador de actualización continúa con el proceso de rotación de certificados que se describe en la sección Rotación de certificados.

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

Para evitar que se expongan los certificados durante el envío, encripta la conexión entre tus dispositivos perimetrales y el agente de MQTT. Si quieres obtener más información, consulta Prácticas recomendadas para la conectividad de red.

Rota certificados automáticamente

Para limitar el daño que puede causar un certificado expuesto, genera certificados con un período válido finito y rota los certificados antes de que venzan. Para implementaciones de IoT a gran escala, implementa un procedimiento de rotación de certificados automático a fin de actualizar los dispositivos de forma coherente con certificados nuevos antes de que venzan los anteriores. Los dispositivos implementados sin certificados válidos significan que los dispositivos pueden dejar de funcionar, lo que puede ser costoso de corregir y afectar de forma negativa la funcionalidad general de la solución de IoT.

Tus dispositivos perimetrales deben conectarse bidireccionalmente con tu agente de MQTT para garantizar que pueda enviar mensajes al agente de MQTT y que pueda recibir mensajes del agente de MQTT.

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

  • Un proceso de supervisión que analiza de manera recurrente a través de tu inventario de certificados y busca certificados que están a punto de vencer. El proceso de supervisión activa la rotación de certificados para los certificados vencidos.
  • Un proceso de rotación que inicializa y supervisa la rotación de certificados.
  • Es un controlador de rotación de certificados de dispositivo en el dispositivo perimetral que se comunica con el agente de MQTT y ejecuta los pasos de rotación de certificados en el dispositivo.

Para rotar los certificados, la solución de IoT completa los siguientes 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 del dispositivo confirma la recepción del mensaje de inicialización mediante el envío de una respuesta al trabajo de rotación.
  3. El proceso de rotación solicita un certificado nuevo de la CA. Esta solicitud es similar a la solicitud de aprovisionamiento de certificados, excepto que las claves y la CSR se envían como mensajes del agente de MQTT.
  4. Después de recibir el certificado nuevo de la CA, 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 agente de MQTT.
  5. El controlador de rotación de certificados del dispositivo almacena el certificado nuevo y, luego, inicializa una conexión nueva con el agente de MQTT mediante el certificado nuevo.
  6. Una vez que se establece la conexión nueva, el controlador de rotación de certificados del dispositivo envía un mensaje completo al agente de MQTT.
  7. Después de recibir el mensaje completo, el proceso de rotación invalida el certificado anterior en el almacén de certificados central.

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

Para ayudar a proteger el proceso de rotación de certificados de fallas del entorno de ejecución, habilita la persistencia de los cambios y el progreso.

Para obtener más información sobre la rotación de secretos mediante Secret Manager, consulta Rotación de secretos.

Prácticas recomendadas para la administración de certificados en plataformas de IoT

Si usas una plataforma de IoT, usa los mecanismos de actualización y distribución de certificados que proporciona la plataforma. Para fines de copia de seguridad, puedes exportar con regularidad 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 agente de MQTT

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

En las siguientes secciones, se proporcionan prácticas recomendadas para los métodos de autenticación cuando se usan agentes de MQTT.

Elige el método de autenticación para los agentes de MQTT

Los diferentes backends de IoT admiten diferentes métodos de autenticación. Los métodos más usados son los siguientes:

  • Autenticación de nombre de usuario y contraseña, en la que el dispositivo perimetral presenta su nombre de usuario y contraseña para verificar su identidad.
  • Autenticación basada en tokens, en la que se usan tokens de seguridad encriptados para verificar la identidad del dispositivo perimetral.
  • Esquemas de autenticación personalizados, en los que implementas un mecanismo personalizado para verificar la identidad del dispositivo perimetral.

Como parte del estándar MQTT, los agentes de MQTT admiten la autenticación de nombre de usuario y contraseña como configuración predeterminada 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 agente de MQTT. Los dispositivos perimetrales envían el paquete MQTT CONNECT al agente de MQTT cuando establecen una conexión.

Además de los campos de nombre de usuario, contraseña e identificador de cliente en el paquete MQTT CONNECT, MQTT 5.0 admite la autenticación mejorada que te permite compilar flujos de autenticación de desafío de respuesta. MQTT 5.0 permite varios intercambios de paquetes AUTH entre el dispositivo perimetral y el agente de MQTT.

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

Para la autenticación con nombre de usuario y contraseña, configura el agente de MQTT para usar un almacén de contraseña. El almacén de contraseñas proporciona una ubicación centralizada para administrar las contraseñas de todos los dispositivos perimetrales que se conectan al agente de MQTT. De forma predeterminada, los campos de nombre de usuario, contraseña e identificador de cliente son opcionales en la especificación 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 encriptadas en reposo y en tránsito, de la siguiente manera:

Considera la autenticación basada en tokens

Con la autenticación basada en tokens, los dispositivos perimetrales envían un token al agente de MQTT para autenticarse. Los dispositivos pueden generar el token por sí mismos o conseguir el token de otros servicios de autenticación. En comparación con las contraseñas, los tokens son de corta duración: los tokens solo son válidos durante un período con una fecha de vencimiento explícita. Verifica siempre el vencimiento cuando valides 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 agente de MQTT. El JWT está incorporado en el paquete MQTT CONNECT como el campo de contraseña.

Las ventajas de JWT son las siguientes:

  • JWT te brinda opciones sobre el algoritmo de encriptación que se usa para firmar el token. JWT funciona bien con dispositivos perimetrales limitados, en los que puedes usar un algoritmo de encriptación que consume menos recursos, como ECC para firmar el token.
  • Con la criptografía de clave pública, la clave privada solo se usa en el dispositivo perimetral y nunca se comparte con otros. 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 el que las credenciales se envían a través de la conexión y requieren la encriptación de los datos.

Considera los esquemas de autenticación personalizados

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

  • Protocolos de autenticación estándar de la industria, como OpenID Connect, lenguaje de marcado para confirmaciones de seguridad (SAML), LDAP, Kerberos y Autenticación y capa de seguridad (SASL) simples. Estos protocolos delegan la autenticación de dispositivo a tus proveedores de identidad existentes. Algunos agentes de MQTT admiten la autenticación mejorada y los mecanismos de autenticación extensibles que puedes usar para extender el agente de MQTT a fin de admitir protocolos y proveedores de identidad nuevos.
  • Autenticación mutua basada en certificados. Algunos agentes de MQTT admiten un esquema de autenticación mutua, como la autenticación basada en mTLS.

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

Debido al patrón de comunicación de suscriptores y publicadores del protocolo MQTT, el control de acceso al dispositivo se define mediante temas MQTT. Los temas de MQTT controlan la manera en que un dispositivo puede comunicarse 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 de backend de IoT a fin de obtener opciones para configurar temas de MQTT.

Usa cuentas de servicio de un solo propósito para acceder a los recursos de Google Cloud

El acceso a los recursos de Google Cloud se administra mediante políticas de permisos de IAM que vinculan la asignación de acceso a los recursos con un conjunto de principales. Los principales típicos son las cuentas de usuario, las cuentas de servicio y los grupos. Por lo general, una aplicación o una carga de trabajo de procesamiento usan cuentas de servicio para realizar llamadas autorizadas a la API para los recursos de la nube. Las cuentas de servicio permiten que los dispositivos de IoT Edge accedan a los recursos de la nube.

Debido a que el backend de IoT administra la identidad del dispositivo, debes asignar una identidad entre el backend de IoT y la de IAM para que el dispositivo perimetral pueda acceder a los recursos de Google Cloud.

Si administras un gran conjunto de dispositivos, el límite de la cantidad de cuentas de servicio para cada proyecto de Google Cloud hace que no sea factible tener una asignación uno a uno directa entre la cuenta de servicio y la del dispositivo.

En su lugar, crea cuentas de servicio que estén vinculadas a los recursos de la nube a los que necesita acceder la solución de IoT, como se describe en Crea cuentas de servicio de un solo propósito. Por ejemplo, crea una cuenta de servicio única para cada uno de los siguientes casos de uso:

  • Descarga paquetes de actualización de software
  • Sube archivos multimedia grandes
  • Transfiere datos desde una transmisión de latencia

A fin de implementar el privilegio mínimo, asegúrate de que cada cuenta de servicio solo tenga suficientes derechos de acceso para brindar asistencia a su caso de uso. Por ejemplo, para una cuenta de servicio que se usa a fin de descargar paquetes de software, solo otorga acceso de lectura al bucket de Cloud Storage.

Distribuye tokens de acceso en los dispositivos de forma segura

Por lo general, tus dispositivos perimetrales se comunican con tu plataforma de IoT mediante MQTT. Sin embargo, para casos de uso específicos, es posible que tus dispositivos requieran acceso directo a los recursos de Google Cloud. Por ejemplo, considera lo siguiente:

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

Para estos casos de uso, usa la federación de Workload Identity, en la que el acceso a los recursos de Google Cloud se otorga a través de tokens de acceso. La federación de Workload Identity elimina la necesidad de aprovisionar credenciales específicas de la nube en los dispositivos perimetrales y la distribución de acceso se realiza de forma dinámica según la demanda.

Para distribuir los tokens de acceso para los recursos de la nube a tus dispositivos, configura la federación de identidades para cargas de trabajo entre tu proveedor de identidad del dispositivo y Google Cloud. Para admitir la federación de identidades para cargas de trabajo, asegúrate de que el backend de IoT cumpla con los requisitos de federación de identidades para cargas de trabajo y sigue las prácticas recomendadas de seguridad que coincidan con tus casos de uso.

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

  • El dispositivo llama al servicio de tokens de seguridad y proporciona sus propias credenciales del dispositivo.
  • El servicio de tokens de seguridad verifica la identidad del dispositivo perimetral mediante la validación de las credenciales que proporcionó el dispositivo perimetral con el proveedor de identidad del dispositivo.
  • Si la verificación de identidad se realiza correctamente, el servicio de tokens de seguridad muestra un token federado de vuelta al dispositivo perimetral.
  • El dispositivo perimetral usa el token federado para actuar en nombre de la cuenta de servicio de un solo propósito 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 necesarios en la nube.

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

La federación de Workload Identity 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 Autenticación en Google.

Supervisa y audita el acceso a los recursos de la nube

Habilita los Registros de auditoría de Cloud para crear entradas de registro cuando tus dispositivos perimetrales acceden a los recursos en la nube a través de solicitudes a la API autenticadas. Los Registros de auditoría de Cloud te permiten supervisar acciones críticas que realizan tus dispositivos perimetrales en Google Cloud. Además, los registros de auditoría de Cloud crean los registros de auditoría y los registros que necesitas para investigar cualquier problema. Si deseas obtener más información, consulta Actúa como una cuenta de servicio para acceder a Google Cloud.

¿Qué sigue?