Residência de dados MQTT significa saber, e controlar, onde as suas mensagens IoT são processadas e armazenadas no caminho do dispositivo até a aplicação. Este artigo explica quais partes de um sistema MQTT tocam os dados, quais questões regulatórias e contratuais costumam se aplicar e como a escolha de região e as implantações bring your own cloud ajudam a atendê-las. É um guia prático de engenharia, não aconselhamento jurídico; envolva a sua equipe jurídica ou de compliance nas decisões.
O Que Residência de Dados Significa para o MQTT
Residência de dados é a exigência de que determinados dados sejam armazenados ou processados dentro de uma geografia específica, como um país ou o Espaço Econômico Europeu. Termos relacionados costumam ser usados de forma imprecisa:
- Residência de dados: onde os dados ficam fisicamente.
- Soberania de dados: as leis de qual jurisdição se aplicam aos dados.
- Localização de dados: uma exigência legal de que os dados permaneçam em um país.
Um broker MQTT está no caminho de cada mensagem. Mesmo que o seu banco de dados esteja no país certo, um broker em outra região continua recebendo, processando e possivelmente armazenando essas mensagens. Entender o que um broker MQTT faz com os seus dados é o ponto de partida.
Onde os Dados Ficam em um Sistema MQTT
Mapeie todos os lugares onde uma mensagem pode existir, não apenas o seu banco de dados:
| Local | O que guarda | Pergunta de residência |
|---|---|---|
| Dispositivo | Leituras antes do envio, mensagens em buffer | Onde os dispositivos estão implantados? |
| Caminho de rede | Mensagens em trânsito | O tráfego é criptografado com TLS de ponta a ponta até o broker? |
| Memória do broker | Mensagens sendo roteadas | Em qual região o broker roda? |
| Retained messages | Último valor por topic | Armazenadas onde e por quanto tempo? |
| Sessões persistentes | Mensagens enfileiradas para clientes offline | Armazenadas onde e quando expiram? |
| Logs do broker | Client IDs, endereços IP, às vezes topics | Os logs contêm dados pessoais e onde são mantidos? |
| Assinantes e back-ends | Tudo o que vem depois | Onde rodam os seus serviços e bancos de dados? |
Dois itens passam despercebidos com facilidade. Primeiro, retained messages e mensagens de sessão enfileiradas são dados em repouso no broker. Segundo, os logs do broker podem conter endereços IP e identificadores de clientes, que podem ser dados pessoais segundo algumas regulamentações.
Fatores Regulatórios e Contratuais
GDPR e Dados Pessoais
Pelo Regulamento Geral de Proteção de Dados da UE (GDPR), dados pessoais só podem ser transferidos para fora do EEE com salvaguardas adequadas. Nem todo dado de IoT é pessoal, mas boa parte pode ser: a localização de um rastreador veicular, a ocupação de uma casa, o consumo de energia vinculado a uma residência ou leituras de saúde de um wearable. Se um dispositivo pode ser associado a uma pessoa, a sua telemetria pode ser dado pessoal.
Requisitos do Setor e dos Clientes
Além das leis de privacidade, os requisitos de residência costumam vir de:
- Contratos com o setor público que exigem hospedagem no país.
- Infraestrutura crítica e utilities com regras de segurança nacional.
- Clientes da saúde e do setor financeiro com políticas próprias.
- Questionários de compras corporativas perguntando onde roda cada suboperador.
Muitas vezes, o requisito mais rígido nem é uma lei, e sim uma cláusula no contrato de um cliente. Reúna esses requisitos antes de escolher um modelo de hospedagem.
Reduzindo o Risco de Residência no Seu Design
Escolhas de engenharia podem diminuir o problema, independentemente de onde o broker roda:
- Minimize dados pessoais nos payloads. Envie IDs de dispositivo, não nomes ou endereços. Resolva identidades no seu back-end, na região certa.
- Mantenha dados pessoais fora dos nomes de topics. Topics aparecem em logs, exploradores e ferramentas de depuração.
- Use TLS em todas as conexões. As portas 8883 e 8084 criptografam os dados em trânsito.
- Limite os dados em repouso no broker. Use o message expiry do MQTT 5 e um session expiry razoável, e evite reter mensagens que contenham dados pessoais.
- Processe na borda. Agregue ou anonimize em um gateway antes de publicar para a nuvem.
- Documente o fluxo de dados. Um diagrama listando cada componente e a sua região responde à maioria das perguntas de compras.
Veja um exemplo em Python (paho-mqtt 2.x) que publica telemetria pseudônima com message expiry do MQTT 5, para que o broker a descarte se nenhum assinante a receber em dez minutos.
import json
import ssl
import time
import paho.mqtt.client as mqtt
from paho.mqtt.packettypes import PacketTypes
from paho.mqtt.properties import Properties
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="YOUR_CLIENT_ID",
protocol=mqtt.MQTTv5)
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set(cert_reqs=ssl.CERT_REQUIRED)
client.connect("YOUR_BROKER_HOST", 8883, keepalive=60)
client.loop_start()
props = Properties(PacketTypes.PUBLISH)
props.MessageExpiryInterval = 600 # segundos
payload = {"device": "dev-4f9a", "kwh": 1.84, "ts": int(time.time())} # sem nomes ou endereços
info = client.publish("site-07/meter/dev-4f9a/telemetry", json.dumps(payload),
qos=1, properties=props)
info.wait_for_publish()
client.loop_stop()
client.disconnect()
Trade-Offs na Escolha da Região
Escolher a região do broker é um equilíbrio entre residência, latência e conveniência:
- Residência: a região precisa atender aos seus requisitos legais e contratuais.
- Latência: dispositivos e consumidores distantes do broker têm round trips mais longos; veja latência de broker MQTT por região.
- Co-localização: colocar o broker perto do seu back-end reduz a transferência de dados entre regiões.
- Frotas multirregião: se você vende em várias jurisdições, pode precisar de um broker por região, com cada dispositivo configurado para o seu broker de origem.
O último ponto importa para a arquitetura. Uma frota de dispositivos dividida entre regiões geralmente significa brokers e back-ends separados por região, com apenas dados agregados e não pessoais fluindo para uma visão global.
Retenção e Exclusão
Perguntas sobre residência normalmente vêm acompanhadas de perguntas sobre retenção. Decida por quanto tempo cada tipo de dado pode existir em cada etapa: no buffer do dispositivo, no broker como mensagens retidas ou enfileiradas, nos logs e nos seus bancos de dados. Torne a exclusão possível por dispositivo e por cliente, porque desligar um cliente ou atender a um pedido de exclusão significa remover os dados de todos os lugares para onde foram copiados. Limpar uma retained message é simples no MQTT: publique um payload retido vazio no mesmo topic.
Como o BYOC Resolve a Residência
A resposta mais forte para "onde estão os nossos dados?" é "na nossa própria conta de nuvem, em uma região que escolhemos". Esse é o modelo bring your own cloud. Com o BYOC do ConnectMQ, o broker roda na sua conta de nuvem e o ConnectMQ o gerencia, então você decide a região, as fronteiras de rede e a política de logs, sem assumir a carga operacional da auto-hospedagem. Os detalhes estão no nosso artigo sobre broker MQTT BYOC.
Os outros planos do ConnectMQ atendem a necessidades diferentes. Brokers Serverless no cluster compartilhado são ideais para desenvolvimento, pilotos e dados sem restrições de residência. O plano Dedicated oferece um cluster isolado. Em ambos os casos, pergunte ao ConnectMQ onde a infraestrutura roda e inclua a resposta na documentação do seu fluxo de dados. Organizações que precisam operar tudo por conta própria podem considerar o Self Managed Enterprise.
Qualquer que seja o plano, o lado do cliente não muda: MQTT 3.1.1 ou 5.0 sobre TLS na porta 8883, ou Secure WebSocket na 8084 com caminho /mqtt. Mover uma frota de um modelo de hospedagem para outro é questão de atualizar host e credenciais.
Checklist de Residência Antes do Lançamento
- Liste as jurisdições onde estão os dispositivos, os usuários e os clientes.
- Classifique os campos do payload: pessoais, pseudônimos ou não pessoais.
- Registre a região do broker, de cada assinante e de cada banco de dados.
- Configure message expiry, session expiry e a política de retained messages.
- Confirme que o TLS é obrigatório para todos os clientes.
- Decida se BYOC ou brokers por região são necessários.
- Mantenha dados de teste fora de brokers públicos; o que é publicado no servidor MQTT público gratuito pode ser lido por qualquer pessoa, e ele serve apenas para experimentos não sensíveis.
Comece com o ConnectMQ
Comece a construir no plano Serverless gratuito em app.connectmq.com, sem cartão de crédito, usando dados de teste não pessoais. Quando os requisitos de residência estiverem definidos, converse com o ConnectMQ sobre implantações Dedicated ou BYOC. Para uma visão completa dos modelos de hospedagem, leia o guia de broker MQTT na nuvem e a comparação de broker MQTT gerenciado.
Perguntas frequentes
A residência de dados MQTT só importa para dados armazenados?
Não. Em muitas políticas, o processamento também conta, e um broker processa cada mensagem. Retained messages, sessões enfileiradas e logs também são dados em repouso no broker.
A telemetria IoT é dado pessoal segundo o GDPR?
Pode ser, se estiver relacionada a uma pessoa identificável, como localização ou consumo de energia de uma residência. Peça ao seu encarregado de proteção de dados para classificar os seus payloads.
Como o BYOC ajuda na residência de dados?
O broker roda na sua própria conta de nuvem, em uma região que você escolhe, sob as suas políticas, enquanto o provedor o opera.
Posso usar um único broker para dispositivos em vários países?
Tecnicamente sim, mas se cada país tiver regras de residência, você pode precisar de um broker por região, com os dispositivos atribuídos ao seu broker de origem.
