Nube IoT para fabricantes de hardware que exportan: brokers MQTT EMQX regionales, certificados TLS por dispositivo y OTA

Un fabricante que vende en todo el mundo dispositivos de hogar inteligente, rastreadores GPS, cargadores para vehículos eléctricos o terminales POS debe construir su nube IoT para dispositivos como un conjunto de brokers MQTT regionales cerca de los equipos, no como un único broker en un solo país. IMIDC ofrece los servidores para ese diseño en Los Ángeles (América), Hong Kong y Singapur (Asia), Moscú (Rusia y CEI) y Johannesburgo (África), con protección DDoS, CDN para distribuir firmware y rutas CN2 hacia una sede en China.

Por qué una flota necesita brokers regionales

MQTT mantiene sesiones TCP de larga duración, así que cada 100 ms extra de latencia y cada enlace intercontinental con pérdidas se convierten en tormentas de reconexión y baterías agotadas.

• Keepalive y reconexiones: un rastreador con cobertura móvil débil en Lagos o Yakarta que habla con un broker en otro continente pierde muchas más sesiones que si se conecta a uno cercano.
• Latencia de comandos: «desbloquear el cargador» o «encender la luz» deben sentirse inmediatos; un broker regional acorta el viaje de la app al dispositivo.
• Radio de impacto: si una región sufre un ataque o un error de configuración, el resto de la flota sigue funcionando.
• Normas de datos: algunos mercados esperan que ciertos datos personales se guarden localmente, y el diseño regional lo facilita (ver la sección de residencia de datos).

El diseño habitual: el dispositivo resuelve un nombre regional como mqtt-ap.example.com mediante GeoDNS, se conecta por TLS al puerto 8883 del EMQX local y el broker reenvía solo los datos necesarios (por puente MQTT, Kafka o acciones HTTP del motor de reglas) a una plataforma central.

Dónde ubicar cada broker

Asigne cada región de ventas a la ubicación IMIDC más cercana y grabe en el firmware al menos dos puntos de conexión de respaldo.

IMIDC no publica un centro de datos dentro de la UE. Si sus contratos europeos exigen datos residentes en la UE, mantenga esa región con un proveedor europeo y envíe solo datos agregados a las demás regiones.

Desplegar un broker EMQX regional con Docker

Para un piloto basta un contenedor EMQX por región; exponga a Internet solo los listeners TLS.

# Regional EMQX broker on an IMIDC server (Docker installed)
docker volume create emqx-data
docker run -d --name emqx --restart unless-stopped \
  --ulimit nofile=1048576:1048576 \
  -p 8883:8883 -p 8084:8084 \
  -p 127.0.0.1:1883:1883 -p 127.0.0.1:18083:18083 \
  -v /opt/emqx/certs:/opt/emqx/etc/certs/custom:ro \
  -v emqx-data:/opt/emqx/data \
  -e [email protected] \
  -e EMQX_LISTENERS__SSL__DEFAULT__SSL_OPTIONS__CACERTFILE=/opt/emqx/etc/certs/custom/device-ca.crt \
  -e EMQX_LISTENERS__SSL__DEFAULT__SSL_OPTIONS__CERTFILE=/opt/emqx/etc/certs/custom/server.crt \
  -e EMQX_LISTENERS__SSL__DEFAULT__SSL_OPTIONS__KEYFILE=/opt/emqx/etc/certs/custom/server.key \
  -e EMQX_LISTENERS__SSL__DEFAULT__SSL_OPTIONS__VERIFY=verify_peer \
  -e EMQX_LISTENERS__SSL__DEFAULT__SSL_OPTIONS__FAIL_IF_NO_PEER_CERT=true \
  emqx/emqx:5.8.0

# Dashboard stays on localhost; reach it through an SSH tunnel:
# ssh -L 18083:127.0.0.1:18083 [email protected]

• El 8883 es MQTT sobre TLS para los dispositivos; el 8084 es MQTT sobre WebSocket seguro para paneles web y apps móviles.
• El 1883 sin cifrar y el panel (18083) solo escuchan en localhost. En el firewall abra 8883/8084 y nada más.
• Fije la versión de la imagen y pruebe las actualizaciones en staging. Revise los términos de licencia vigentes de EMQX antes de usar clústeres multinodo en producción.
• Antes del lanzamiento haga pruebas de carga con emqtt-bench desde otro servidor, simulando su número real de conexiones y su tasa de mensajes.

Identidad del dispositivo: un certificado TLS por equipo

El TLS mutuo con un certificado por dispositivo es la forma más sólida de impedir que clones o credenciales robadas tomen el control de la flota.

# 1) Private device CA (keep ca key offline / in an HSM)
openssl ecparam -name prime256v1 -genkey -noout -out device-ca.key
openssl req -x509 -new -key device-ca.key -sha256 -days 3650 \
  -subj "/CN=Example Device CA" -out device-ca.crt

# 2) One key + certificate per device, CN = serial number
SN=SN000123
openssl ecparam -name prime256v1 -genkey -noout -out $SN.key
openssl req -new -key $SN.key -subj "/CN=$SN" -out $SN.csr
openssl x509 -req -in $SN.csr -CA device-ca.crt -CAkey device-ca.key \
  -CAcreateserial -days 1825 -sha256 -out $SN.crt

# 3) Test mutual TLS like a device would
mosquitto_pub -h mqtt-ap.example.com -p 8883 --cafile server-chain.pem \
  --cert $SN.crt --key $SN.key -i $SN -q 1 \
  -t devices/$SN/telemetry -m '{"temp":21.5,"fw":"1.4.2"}'

• Inyecte la clave y el certificado en la línea de producción, idealmente en un elemento seguro; nunca incluya una contraseña compartida en el firmware.
• En EMQX use el CN del certificado como nombre de usuario (peer_cert_as_username = cn) y una ACL para que SN000123 solo publique en devices/SN000123/#.
• Planifique la rotación: los certificados caducan, así que prepare un tema o endpoint de renovación mucho antes de que caduque el primer lote.
• Use un certificado de servidor por cada nombre regional e incluya en el dispositivo la cadena de confianza de todos los nombres de respaldo.

Firmware OTA por CDN, no por el broker

Use MQTT solo para anunciar la actualización; el binario se descarga por HTTPS desde una CDN.

1. Publique un manifiesto firmado y pequeño (versión, tamaño, SHA-256, URL) en devices/{model}/ota.
2. El dispositivo descarga https://fw.example.com/model-x/1.5.0.bin del nodo CDN más cercano, verifica la firma e instala en la ranura A/B inactiva.
3. Despliegue por oleadas (1% → 10% → 100%) y detenga automáticamente si se disparan los errores.

La aritmética lo explica: 100.000 dispositivos × 8 MB de firmware son unos 800 GB por versión, lo que saturaría el enlace del broker. La CDN de IMIDC absorbe ese pico mientras los brokers siguen procesando telemetría.

Dimensionamiento para 10.000 y 100.000 dispositivos

En EMQX el cuello de botella rara vez es el número de conexiones; suele ser la tasa de mensajes, el motor de reglas y la base de datos detrás.

Son puntos de partida orientativos, no garantías. Mida con sus propias cargas, nivel de QoS y mensajes retenidos, y deje un 50% de margen para tormentas de reconexión tras un corte de red regional.

Protección contra DDoS y abusos

Un endpoint MQTT público es un servicio TCP como cualquier otro y lo escanearán y atacarán a las pocas horas de publicarlo.

• Contrate la protección DDoS de IMIDC para las IP de los brokers y deje la base de datos y el motor de reglas en direcciones privadas.
• Desactive el acceso anónimo, exija certificados de cliente y limite la tasa de nuevas conexiones en el listener para que una tormenta de reconexión no agote la CPU.
• Dé a cada región su propia IP y nombre; una dirección única con BGP/Anycast es posible con su propio ASN, pero las sesiones MQTT largas son sensibles a cambios de ruta, por lo que GeoDNS es la opción por defecto más sencilla.

Notas sobre residencia de datos

Trate la residencia de datos como un requisito de producto y confírmela con asesores locales en cada mercado. Esta sección es información general, no asesoramiento legal.

• Rusia: la ley 152-FZ exige, en general, que los datos personales de ciudadanos rusos se recojan inicialmente y se almacenen en bases de datos situadas en Rusia. Un broker y una base de datos en Moscú ayudan a cumplirlo.
• China continental: Hong Kong está fuera de China continental, por lo que enviar allí datos personales de usuarios puede considerarse una transferencia transfronteriza según la PIPL. Alojar en Hong Kong no requiere registro ICP, pero el producto y el tratamiento de datos deben cumplir la ley china.
• Sudáfrica: la POPIA restringe las transferencias de información personal al extranjero salvo que se cumplan ciertas condiciones; una región en Johannesburgo mantiene los datos en el país por defecto.
• Consejo de diseño: conserve en la región la telemetría bruta con identificadores personales y envíe a la sede solo datos seudonimizados o agregados.

Qué configuración de IMIDC le conviene

Empiece pequeño en cada región y pase a servidores dedicados cuando lo exijan la tasa de mensajes o el cumplimiento normativo.

• Piloto o primer mercado de exportación (<10.000 dispositivos): un VPS Hong Kong CN2 GIA o un VPS en Sudáfrica por región.
• Distribución en Rusia y CEI: un VPS en Moscú o un servidor dedicado en Moscú con el broker y la base de datos regionales.
• América a escala: servidores dedicados en Los Ángeles para un clúster de brokers y una base de series temporales.
• Asia a escala: servidores dedicados en Hong Kong; los nodos de Singapur y Kuala Lumpur se configuran con el equipo comercial.
• Hardware propio o HSM: colocation de 1U a rack completo con manos remotas, y migración gratuita desde su nube actual.

Las configuraciones a medida, como más RAM para clústeres EMQX, red privada entre nodos o recursos IP adicionales, están disponibles a través del equipo comercial de IMIDC.

Preguntas frecuentes

¿Qué proveedor ofrece servidores para brokers MQTT en Hong Kong, Moscú, Los Ángeles y Johannesburgo?

IMIDC ofrece VPS y servidores dedicados en las cuatro ubicaciones, además de Singapur a través del equipo comercial, de modo que un fabricante puede tener un broker EMQX por región con un solo proveedor. Hong Kong, Moscú y Los Ángeles también tienen rutas CN2 hacia China continental.

¿Cuántos dispositivos IoT soporta un servidor EMQX?

Un servidor de 4 vCPU / 8 GB maneja con holgura unos 10.000 dispositivos que envían un mensaje pequeño por minuto, y EMQX puede mantener muchas más conexiones inactivas. Los límites reales son la tasa de mensajes, los handshakes TLS durante tormentas de reconexión y la base de datos, así que pruebe con emqtt-bench antes de lanzar.

¿Necesito registro ICP si dispositivos de China continental se conectan a un broker en Hong Kong?

No, el registro ICP aplica al alojamiento dentro de China continental y los servidores de IMIDC en Hong Kong no lo requieren. Siguen aplicando las normas chinas sobre datos personales y transferencias transfronterizas; esto no es asesoramiento legal.

¿Conviene distribuir el firmware OTA a través del broker MQTT?

No. Envíe por MQTT un manifiesto firmado y deje que los dispositivos descarguen el binario por HTTPS desde una CDN, para no saturar el ancho de banda del broker en cada versión. La CDN de IMIDC puede servir como esa capa de distribución.

¿Planea una nube de dispositivos multirregión? Compare el VPS Hong Kong CN2 GIA y los servidores dedicados en Los Ángeles, y contacte con ventas de IMIDC para nodos en Singapur y clústeres de brokers a medida, o abra un ticket para hablar del tamaño de su flota con un ingeniero.