Isolamento de Tenants MQTT: Dados dos Clientes Separados

O isolamento de tenants MQTT é o que garante que um cliente nunca consiga ler, escrever ou desacelerar as mensagens de outro cliente. Neste artigo, você vai entender a diferença entre isolamento lógico e físico, como funciona a proteção contra vizinhos barulhentos, quais modos de falha testar e como escolher o nível certo de separação para cada cliente.

Por Que o Isolamento de Tenants Importa

Se o seu produto conecta dispositivos que pertencem a clientes diferentes, o broker guarda os dados deles lado a lado. Um único erro, como uma assinatura com wildcard que corresponde a mais do que devia, uma credencial compartilhada ou uma colisão de client ID, pode expor a telemetria de um cliente a outro ou permitir que uma frota com mau comportamento degrade o serviço de todos. Esses incidentes são difíceis de explicar aos clientes e caros de remediar e, quando a telemetria contém dados pessoais, também envolvem obrigações da LGPD.

O isolamento tem três dimensões, e um bom design trata de todas elas:

Confidencialidade. Um tenant não pode ler as mensagens, os valores retidos ou os dados de sessão de outro tenant.
Integridade. Um tenant não pode publicar nos topics de outro tenant nem assumir as sessões dele.
Disponibilidade. Um tenant não pode consumir tanta capacidade a ponto de prejudicar os demais.

Isolamento Lógico vs Físico

Isolamento Lógico

Com o isolamento lógico, os tenants compartilham os mesmos processos e máquinas do broker, e o software os mantém separados. Cada tenant tem as suas próprias identidades e o seu próprio espaço de topics, e cotas por tenant limitam o uso de recursos. É assim que funciona a maioria dos serviços de nuvem compartilhados e, quando implementado com cuidado, é uma fronteira forte para confidencialidade e integridade.

O seu limite é que os recursos físicos continuam compartilhados. As cotas limitam o impacto de um vizinho barulhento, mas um tenant em um cluster compartilhado não consegue garantias de capacidade independentes de todos os outros.

Isolamento Físico

Com o isolamento físico, um tenant recebe o seu próprio cluster: processos separados, máquinas separadas e, muitas vezes, endpoints de rede separados. Nada do que outro cliente faça pode afetar a sua CPU, memória ou conexões. Custa mais, porque a capacidade é reservada em vez de compartilhada, e leva mais tempo para provisionar.

Um passo adicional é colocar esse cluster dedicado dentro da própria conta de nuvem do cliente, o que acrescenta a propriedade da própria infraestrutura. Esse é o modelo bring your own cloud descrito em broker MQTT BYOC.

Nível de isolamento	Compartilhado com outros	Protege contra	Escolha típica para
Apenas prefixo de topic (sem imposição)	Tudo	Apenas confusão acidental	Apps internos de um único dono
Lógico, identidade de broker por tenant	Hardware, processos	Vazamento de dados, falsificação de identidade, vizinhos barulhentos limitados	A maioria dos clientes SaaS, protótipos
Físico, cluster dedicado	Nada no nível do broker	Vizinhos barulhentos por completo	Frotas grandes, SLAs rigorosos, clientes regulados
Físico, na conta do cliente	Nada; o cliente é dono da infraestrutura	Requisitos de propriedade da infraestrutura	Políticas de controle de dados e conformidade

Proteção Contra Vizinhos Barulhentos na Prática

Vizinhos barulhentos raramente são maliciosos. As causas usuais são banais:

Firmware que reconecta imediatamente após uma falha, criando uma tempestade de conexões.
Um script de teste publicando em loop, sem nenhum atraso.
Payloads grandes demais, como imagens, enviados onde se esperava um JSON pequeno.
Milhares de assinaturas criadas por um cliente que nunca cancela nenhuma.

Uma proteção eficaz atua no nível do cliente e do tenant: limites de conexões, taxa de mensagens, tamanho de payload e assinaturas; bloqueio de endereços após repetidas falhas de login; e um retorno claro para o cliente. No MQTT 5, o reason code 0x97 (Quota exceeded) informa ao cliente exatamente por que uma publicação ou conexão foi recusada. Leia mais sobre como as cotas de conexão do broker MQTT afetam o design dos clientes.

A Identidade É a Base

O isolamento falha mais rápido na camada de identidade. Siga estas regras:

Nunca compartilhe credenciais entre tenants. Cada cliente recebe as suas próprias credenciais e, idealmente, cada dispositivo também.
Vincule os client IDs às credenciais. No MQTT, uma segunda conexão com o mesmo client ID derruba a primeira. Se os client IDs não estiverem vinculados a identidades, um tenant poderia atrapalhar outro reutilizando os IDs dele.
Use TLS em tudo. Credenciais enviadas por TCP puro em uma rede pública podem ser capturadas. As portas 8883 ou 8084 devem ser o padrão em produção.
Rotacione segredos. Planeje a rotação desde o primeiro dia, incluindo como os dispositivos recebem novas credenciais.

O guia de boas práticas de segurança MQTT aborda esses controles com mais profundidade.

Testando o Seu Isolamento

Não presuma que o isolamento funciona; verifique. Um plano de testes mínimo:

Conecte um cliente com as credenciais do tenant A e assine #. Publique a partir do tenant B. O tenant A não deve receber nada.
Tente se conectar com o client ID do tenant B usando as credenciais do tenant A. O broker deve rejeitar.
Publique retained messages como tenant B e depois assine o mesmo nome de topic como tenant A. Nenhuma mensagem retida pode chegar.
A partir do tenant A, ultrapasse o limite de conexões ou de taxa. Confirme que a latência e as conexões do tenant B não foram afetadas.
Erre o login do tenant A repetidamente a partir de um endereço. Confirme que o bloqueio se aplica a esse endereço, e não ao tenant B.

Veja um pequeno script em Python, usando paho-mqtt 2.x, para o teste 1. Rode-o com os dados do tenant A enquanto outro cliente publica com os do tenant B.

import ssl
import time
import paho.mqtt.client as mqtt

received = []

def on_connect(client, userdata, flags, reason_code, properties):
    print("Tenant A connected:", reason_code)
    client.subscribe("#", qos=0)

def on_message(client, userdata, msg):
    received.append(msg.topic)
    print("Unexpected message:", msg.topic)

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.on_connect = on_connect
client.on_message = on_message
client.connect("YOUR_BROKER_HOST", 8883, keepalive=30)
client.loop_start()
time.sleep(60)   # publique a partir do tenant B durante esta janela
client.loop_stop()
print("Isolation OK" if not received else f"Leak: {len(received)} messages")

No seu próprio broker, é claro, você verá o tráfego do seu próprio tenant, então rode este teste com um tenant que não tenha publicadores próprios.

Como o ConnectMQ Isola os Tenants

O ConnectMQ aplica o isolamento com intensidades diferentes conforme o plano:

Serverless (Free e Paid). Os brokers compartilham um cluster com isolamento multi-tenant. Cada broker tem credenciais geradas, client IDs vinculados a essas credenciais e cotas por plano, por exemplo até 25 conexões no plano gratuito e até 1.000 no plano pago. Proteção contra flood e bloqueio de IP após repetidas falhas de login protegem o cluster compartilhado.
Dedicated. O seu broker roda em um cluster isolado, então nenhum outro cliente compartilha a capacidade dele.
BYOC. O broker roda na sua própria conta de nuvem e o ConnectMQ o gerencia.
Self Managed Enterprise. Para organizações que operam a plataforma por conta própria.

O servidor MQTT público em broker.connectmq.com é, de propósito, o oposto de isolado: a sua área de demonstração pode ser lida por qualquer pessoa e serve apenas para experimentos. Use-o para aprender, nunca para dados de clientes. A página do servidor MQTT público (gratuito) lista os seus limites.

Escolhendo o Nível Certo

Parta do que os seus clientes e contratos exigem, não do que é tecnicamente possível:

Nenhum dado de cliente, apenas aprendizado: o servidor MQTT público.
Seu próprio produto, um único dono de todos os dados: um broker Serverless privado.
Muitos clientes com requisitos comuns: um broker isolado por cliente, ou um broker compartilhado com separação rigorosamente imposta no seu próprio back-end.
Clientes com garantias de capacidade ou necessidades regulatórias: Dedicated ou BYOC.

Para ver como produtos SaaS combinam essas opções, leia MQTT para SaaS IoT.

Comece com o ConnectMQ

Crie um broker isolado em minutos no plano Serverless gratuito em app.connectmq.com, sem cartão de crédito. Quando um cliente precisar de garantias mais fortes, migre-o para um cluster Dedicated ou para BYOC com o mesmo código cliente. A visão geral de broker MQTT gerenciado e o guia de broker MQTT na nuvem explicam os planos em mais detalhes.

Perguntas frequentes

Qual é a diferença entre isolamento MQTT lógico e físico?

O isolamento lógico mantém os tenants separados por software em máquinas compartilhadas; o isolamento físico dá a um tenant o seu próprio cluster. O isolamento físico também elimina por completo os efeitos de vizinhos barulhentos.

Outro cliente em um broker compartilhado pode ler minhas mensagens?

Não, se o provedor isolar os tenants corretamente. Cada tenant deve ter credenciais e espaço de topics próprios, o que você pode verificar com um teste de assinatura com wildcard.

O que acontece quando um tenant ultrapassa a sua cota?

O broker recusa a conexão ou a mensagem excedente. Clientes MQTT 5 recebem um reason code como 0x97 para que possam recuar e registrar a causa.

O servidor MQTT público é isolado?

Não. A área pública de broker.connectmq.com pode ser lida por qualquer pessoa e se destina apenas a testes.

Isolamento de Tenants MQTT: Mantendo Separados os Dados dos Clientes