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

Last reviewed 2024-12-06 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 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 recursos de Google Cloud .

Arquitectura de la IoT

Una arquitectura de IoT incluye servicios que te permiten aprovisionar y administrar credenciales de dispositivos, autenticar y controlar el acceso a dispositivos de perímetro, y permitir que los dispositivos de perímetro accedan a 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 que usa una plataforma de IoT. Las principales diferencias de seguridad entre estos dos backends son la identidad y la administración de dispositivos. Las plataformas de IoT proporcionan estas capacidades como parte de su sistema, mientras que los agentes de MQTT requieren que las proporciones.

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

Arquitectura de backend de la IoT.

La arquitectura muestra los servicios que se requieren para los siguientes tres procesos:

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

  2. Autenticación y 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 entre sí

  3. Conexiones entre dispositivos de perímetro y Google Cloud servicios, que son tareas que el dispositivo de perímetro completa para conectarse a recursos de la nube y subir o descargar datos.

En este documento, se enfoca 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 se encuentra geográficamente cerca de los datos que deseas 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 agente de MQTT o una plataforma de IoT.
    • Un agente de MQTT proporciona una interfaz segura para que los dispositivos perimetrales se conecten con el protocolo MQTT. Los agentes de MQTT carecen de capacidades para la identidad y la administración de dispositivos, y dependen de sistemas externos para proporcionarlas.
    • Una plataforma de IoT es una aplicación en la nube con la que se conectan y comunican los dispositivos perimetrales. Las plataformas de IoT proporcionan una interfaz segura para que los dispositivos de perímetro se conecten con el protocolo MQTT. Cada plataforma de IoT tiene su propia implementación de seguridad que determina cómo autentica y autoriza los dispositivos de perímetro y cómo administra sus identidades.
  • Un almacén de certificados central que aloja los certificados de todos los dispositivos de perímetro.
  • Son los recursos de la nube a los que deben acceder los dispositivos de borde.

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 que deciden cómo aprovisionas 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 se realiza 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 dispositivos con una cadena de confianza que vincule a una autoridad certificadora (AC) raíz. Estos certificados autentican la identidad del dispositivo y ayudan a garantizar que las actualizaciones y modificaciones que se realicen en él sean de partes 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:

  • Si tu dispositivo tiene una solución de seguridad basada en hardware y a prueba de manipulaciones, como un elemento seguro (SE) o un módulo seguro de hardware (HSM) que almacena las claves privadas de forma local y que nunca se exponen de forma externa, haz lo siguiente:

    1. Generar el par de claves públicas/privadas con la solución de seguridad basada en hardware que sea compatible con tu dispositivo
    2. Solicita un certificado con una solicitud de firma de certificado (CSR).
  • Si no usas una solución de seguridad basada en hardware para generar un par de claves pública y privada, usa la AC para generar las claves y el certificado en su lugar. Para obtener más información, consulta Cómo usar una clave generada automáticamente. El certificado que descargues con este método ya está firmado.

Después de generar y firmar un certificado de dispositivo, debes instalar el certificado firmado en el dispositivo perimetral y almacenarlo en un repositorio de certificados 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 Google Cloud servicio de AC (PDF).

Si deseas obtener información sobre otras prácticas recomendadas de aprovisionamiento, consulta Prácticas recomendadas para aprovisionar y configurar automáticamente sistemas y servidores perimetrales y bare metal.

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

  • El certificado de la AC 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 de perímetro 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 de borde.

  • Los certificados de las AC intermedias proporcionan una cadena de confianza que se basa en la AC raíz. Puedes usar AC intermedias para el aprovisionamiento o para necesidades operativas, como otorgar acceso a AC intermedias a los fabricantes o implementar procesos de administración de AC flexibles.

  • 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 deben admitir. Los certificados del servidor están vinculados a la AC raíz. Un administrador de secretos administra y almacena las partes privadas y públicas de los certificados del servidor. Debes configurar tu backend de IoT con los certificados del servidor y sus claves privadas correspondientes.

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

Proceso para generar un certificado de dispositivo con 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 realizan los siguientes pasos:

  1. El dispositivo de borde genera el par de claves públicas en el hardware.
  2. Descargas la clave pública y creas la solicitud de firma de certificado (CSR) para ella.
  3. Envía la CSR a la AC para solicitar un certificado.
  4. La AC completa las siguientes acciones:
    1. Firma el certificado.
    2. Devuelve el certificado firmado al aprovisionador.
  5. El aprovisionador 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 con 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 realizan los siguientes pasos:

  1. El proveedor solicita que la AC envíe un certificado firmado para el dispositivo.
  2. La AC completa las siguientes acciones:
    1. Genera un par de claves pública/privada y firma la clave pública.
    2. Muestra el certificado del dispositivo y la clave privada al proveedor.
  3. El aprovisionador 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 de borde almacena el certificado y la clave privada en una ubicación segura.

Si quieres almacenar la clave privada en un solo lugar (el dispositivo), debes evitar 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 debe volver a realizar el proceso de aprovisionamiento.

Cómo autenticar dispositivos antes de firmar certificados

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

Sin una autenticación adecuada, es posible que tu AC confíe por error en un dispositivo malicioso. Por ejemplo, un atacante que sepa cómo llegar a la infraestructura de firma de certificados de tu AC podría implementar un dispositivo malicioso que le solicite a la AC que firme un certificado. Si no tienes la autenticación del dispositivo, la AC podría firmar el certificado que presenta el dispositivo malicioso. Si la AC firma el certificado, el dispositivo malicioso puede comunicarse con tu backend como un dispositivo de confianza.

Para ayudarte a evitar que dispositivos maliciosos se comuniquen con tu AC, te recomendamos que tomes las siguientes medidas:

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

Implementar un mecanismo de autenticación en este punto del proceso de aprovisionamiento es un desafío. No puedes confiar en los certificados del dispositivo para autenticarlo, ya que aún no tiene un certificado firmado de la AC. Esta falta de un certificado firmado puede ocurrir por los siguientes motivos:

  • El dispositivo aún no genera un certificado.
  • El dispositivo aún no envió una CSR a la AC.
  • La AC aún no envía el certificado firmado al dispositivo.

Una forma de resolver este problema es extender el proceso de aprovisionamiento de dispositivos para hacer lo siguiente en cada dispositivo que quieras autenticar o necesites autenticar:

  1. Genera un certificado de aprovisionamiento que solo uses 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 HSM del dispositivo.
  4. Almacena el certificado de aprovisionamiento firmado en tu backend de Google Cloud.

Antes de que se le otorgue acceso al dispositivo a la infraestructura de firma de certificados de la AC, el dispositivo debe presentar el certificado de aprovisionamiento. Debe 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 es correcta, el dispositivo puede acceder a la infraestructura de firma de certificados de tu AC y el proceso de aprovisionamiento de certificados puede continuar.

Existen diferencias entre un certificado de aprovisionamiento y un certificado de confianza completa. Un certificado de aprovisionamiento solo otorga acceso a una cantidad mínima de servicios e infraestructura. La creación de un certificado de aprovisionamiento permite que la AC verifique que el dispositivo sea original antes de considerarlo de confianza total y emitir un certificado de confianza total.

Una extensión de este proceso es que puedes usar AC subordinadas a las que los fabricantes de dispositivos tienen acceso, junto con tu AC, 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. Luego, puedes verificar estas firmas para validar que el dispositivo sea original.

Si un dispositivo se ve comprometido antes de aprovisionarse, te recomendamos que quites el certificado de aprovisionamiento correspondiente de tu backend de Google Cloudpara que el dispositivo no pueda iniciar el proceso para obtener un certificado de confianza total, ya que no podrá autenticarse con tu AC.

Prácticas recomendadas para la identidad del dispositivo

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 tus dispositivos de forma sistemática y escalable, usa un proveedor de identidad (IdP). El IdP administra las identidades y credenciales de todos los dispositivos y actúa como la fuente de información principal 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 del dispositivo, consulta Aprovisionamiento de un dispositivo de borde.

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

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

Verifica que las identidades de los dispositivos que administra 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 del dispositivo 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 la 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 identidad de DNS, que es un ataque que intenta desviar los dispositivos para que se conecten a un backend no autorizado que controlan los atacantes.
  • Las redes seguras ayudan a garantizar que los terceros no puedan leer tu tráfico de 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 la seguridad de la capa de transporte (TLS) para proteger la comunicación de red entre tus dispositivos perimetrales y las cargas de trabajo del backend.

Extiende TLS con mTLS para implementar un esquema de autenticación mutua que permita que ambas partes conectadas establezcan la identidad de cada una.

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

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

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

Almacena los certificados de forma centralizada

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

  • 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, de modo que estos puedan conectarse con certificados nuevos
  • Derechos de acceso a tu almacén de certificados central para limitar lo que los diferentes roles de tu backend pueden hacer con los certificados

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

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

Protege los 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, se sincronicen con el almacén de certificados del agente de MQTT. Los agentes de MQTT usan almacenes de certificados, como MySQL, PostgresDB y el almacén de claves de Java. Según el almacén de certificados que use tu agente de MQTT, asegúrate de que existan los siguientes procesos:

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

Cuando usas Secret Manager como 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 de borde 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 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 de borde solicitan y descargan los certificados.

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

  • Un almacén de certificados en el que los certificados se administran de forma centralizada.
  • Un coordinador de distribución que envía los certificados y hace un seguimiento del proceso de distribución de 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 de dispositivos de borde 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 encriptados como SSH y usa herramientas como SCP. Como los dispositivos no están en funcionamiento, puedes enviar certificados directamente a los dispositivos de perímetro.

Cuando rotes los certificados, usa el agente de 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, usa una ruta de distribución de certificados indirecta. El proceso consistiría en los siguientes pasos lógicos:

  1. El coordinador de distribución adquiere 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 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 que se descargan 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 Cómo distribuir tokens de acceso a los dispositivos de forma segura.

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

Rota los certificados automáticamente

Para limitar el daño que puede causar un certificado expuesto, genera certificados con un período de validez 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 para actualizar de forma coherente tus dispositivos 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:

  • Es un proceso de supervisión que analiza de forma recurrente 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.
  • Es un proceso de rotación que inicializa y supervisa la rotación de certificados.
  • Un controlador de rotación de certificados del 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 de certificados.
  2. El controlador de rotación de certificados del dispositivo confirma el mensaje de inicialización enviando una respuesta al trabajo de rotación.
  3. El proceso de rotación solicita un certificado nuevo a la AC. 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 AC, la tarea 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. Después de que se establece la nueva conexión, 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.

Para ayudar a proteger los certificados que se envían durante el proceso de rotación, usa temas MQTT dedicados para la rotación de certificados. Limita el acceso a estos temas solo a la tarea 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 para 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 de 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 crear copias de seguridad, puedes exportar las credenciales de tu plataforma de IoT de forma periódica 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, estas cargas de trabajo 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 comunes 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 la 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 para 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 de nombre de usuario y contraseña

Para la autenticación de nombre de usuario y contraseña, configura el agente de MQTT para que use un almacén de contraseñas. 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 y 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 obtenerlo de otros servicios de autenticación. En comparación con las contraseñas, los tokens son de corta duración: solo son válidos por un período con una fecha de vencimiento explícita. Siempre verifica 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 se incorpora 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 de borde con limitaciones, en los que puedes usar un algoritmo de encriptación menos intensivo en recursos, como ECC, para firmar el token.
  • Con la criptografía de clave pública, la clave privada solo se usa en el dispositivo de borde y nunca se comparte con otras partes. Una clave privada ayuda a que este método sea más seguro que la autenticación de nombre de usuario y contraseña, en la que las credenciales se envían a través de la conexión y requieren la encriptación de los datos.

Considera usar 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:

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

Debido al patrón de comunicación del publicador y el suscriptor del protocolo MQTT, el control de acceso de dispositivos se define con temas MQTT. Los temas de MQTT controlan cómo 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 tu backend de IoT para obtener opciones sobre cómo configurar temas de MQTT.

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

El acceso a los Google Cloud recursos se administra mediante políticas de permiso de IAM que vinculan el permiso 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 de recursos en la nube. Las cuentas de servicio permiten que los dispositivos perimetrales de la IoT 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 IAM para que el dispositivo perimetral pueda acceder a los recursos deGoogle 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 de paquetes de actualización de software
  • Sube archivos multimedia grandes
  • Cómo transferir datos de un flujo 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 para descargar paquetes de software, solo otorga acceso de lectura al bucket de Cloud Storage.

Distribuye tokens de acceso a los dispositivos de forma segura

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

  • Para descargar contenido, un dispositivo de borde requiere acceso de solo lectura a un bucket de Cloud Storage solo durante el proceso de descarga.
  • Para subir datos a un bucket de Cloud Storage, un dispositivo de borde 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 yGoogle 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 siga 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 de dispositivo.
  • El servicio de tokens de seguridad verifica la identidad del dispositivo perimetral a través de la validación de las credenciales que el dispositivo perimetral proporcionó 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 de acceso al dispositivo perimetral.
  • El dispositivo perimetral usa ese token para robar la identidad 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 la credencial 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 en la nube

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

¿Qué sigue?

Colaboradores

Autores:

  • Charlie Wang | Arquitecto de Soluciones de Cloud
  • Marco Ferrari | Arquitecto de soluciones de nube