Boas práticas de segurança MQTT: um checklist prático

O MQTT foi projetado para redes limitadas, não para redes hostis. Na configuração padrão, muitos brokers aceitam clientes anônimos na porta 1883 e enviam tudo em texto puro. Nada disso é uma falha do protocolo — o MQTT tem todos os mecanismos de que você precisa —, mas a segurança é algo que você precisa ativar. Este guia percorre cada camada e termina com um checklist que você pode usar em revisões.

Contra o que você está se protegendo

• Interceptação — leitura de credenciais e payloads na rede.
• Falsificação de identidade — um cliente malicioso se conectando como um dos seus dispositivos ou serviços.
• Publicação não autorizada — alguém enviando unlock para home/door/cmd.
• Vazamento de dados — um cliente que assina # e lê tudo.
• Negação de serviço — enxurradas de conexões ou mensagens que esgotam o broker.

1. Criptografe tudo com TLS

O TLS protege credenciais e payloads em trânsito e permite que os clientes verifiquem se estão falando com o broker verdadeiro. Use a porta 8883 para MQTT sobre TLS e wss:// para navegadores; desative ou bloqueie no firewall o listener 1883 sem criptografia em qualquer lugar fora de uma rede local confiável. Detalhes em portas MQTT explicadas e MQTT sobre WebSockets.

• Exija TLS 1.2 ou mais recente.
• Sempre verifique o certificado do servidor nos clientes. Opções como --insecure, setInsecure() ou rejectUnauthorized: false servem apenas para depuração local.
• Planeje a renovação dos certificados — um certificado expirado derruba todos os dispositivos de uma vez.

mosquitto_sub -h broker.example.com -p 8883 --cafile ca.crt \
  -u sensor-01 -P 'secret' -t 'devices/sensor-01/#' -v

2. Autentique todos os clientes

Desative o acesso anônimo. Depois, escolha um método de autenticação adequado para cada tipo de cliente:

Nunca compartilhe um mesmo login entre toda a frota: se um único dispositivo for comprometido, você vai querer revogar uma credencial, não regravar o firmware de todos os dispositivos. Armazene as senhas com hash no broker — quem usa Mosquitto pode seguir o guia de autenticação do Mosquitto, e o gerador de mosquitto.conf cria uma configuração segura com TLS e arquivos de senha.

3. Autorize tópicos com ACLs

A autenticação responde quem é você; a autorização responde o que você pode fazer. Sem ACLs, qualquer cliente autenticado pode ler e escrever em todos os tópicos. Aplique o princípio do menor privilégio: cada cliente recebe acesso de leitura ou escrita apenas aos tópicos de que precisa.

# backend service: read all telemetry, send commands
user backend
topic read devices/+/telemetry
topic write devices/+/cmd

# every device: only its own topics (%u = username)
pattern write devices/%u/telemetry
pattern read devices/%u/cmd

Regras com padrões que substituem o nome de usuário ou o client ID escalam muito melhor do que uma regra por dispositivo. Verifique seus filtros com o testador de tópicos; os curingas do MQTT são explicados em tópicos e curingas.

4. Controle os client IDs

Um cliente que se conecta com um client ID já existente derruba a conexão original do broker. Um atacante que conheça seus IDs pode usar isso para desconectar dispositivos, e uma duplicata acidental causa loops infinitos de reconexão. Vincule os client IDs às credenciais quando o seu broker permitir (por exemplo, exigindo que o client ID seja igual ao nome de usuário ou ao common name do certificado) e evite IDs previsíveis em brokers compartilhados. O gerador de client ID ajuda a criar IDs únicos.

5. Projete os tópicos pensando em segurança

• Coloque o ID do dispositivo ou do tenant em uma posição fixa para que os padrões de ACL possam casar com ele.
• Separe telemetria (o dispositivo escreve) de comandos (o dispositivo lê) em subárvores diferentes.
• Mantenha segredos e dados pessoais fora dos nomes de tópicos — tópicos aparecem em logs e ferramentas de monitoramento.
• Cuidado com mensagens retidas (retained) em tópicos de comando: um unlock retido dispara de novo na reconexão.

6. Criptografe ou assine payloads sensíveis

O TLS protege cada salto, mas o broker vê os payloads em texto puro. Se o operador do broker ou outros serviços conectados a ele não devem ler os dados, criptografe os payloads de ponta a ponta (por exemplo, AES-GCM com chaves gerenciadas fora do MQTT) ou, no mínimo, assine os comandos para que os dispositivos possam rejeitar os forjados. Valide todo payload recebido no dispositivo: imponha limites de tamanho, verifique tipos e ignore comandos desconhecidos.

7. Defina limites e rate limits

Limite o tamanho máximo de pacote, as mensagens em trânsito (inflight) e enfileiradas por cliente, a taxa de conexões e o número de assinaturas. O MQTT 5 permite que o broker anuncie limites como maximum packet size e receive maximum aos clientes. Rate limits impedem que um dispositivo com bug preso em um loop de publicação derrube todos os outros — use a calculadora de tamanho de pacote para definir limites de tamanho realistas.

8. Proteja as credenciais em dispositivos e apps

As credenciais dos dispositivos acabam na memória flash, e as credenciais do navegador acabam em bundles JavaScript que qualquer um pode ler. Parta do princípio de que elas podem ser extraídas: dê a cada cliente a ACL mais restrita possível, provisione credenciais por dispositivo na fabricação ou no primeiro boot em vez de embutir um único segredo no firmware, e use criptografia de flash ou um secure element quando o hardware suportar. Para apps web e mobile, emita credenciais de curta duração a partir do seu backend em vez de distribuir uma senha de longa duração.

9. Monitore e registre logs

• Registre conexões, desconexões e falhas de autenticação, e crie alertas para picos.
• Fique de olho em clientes que assinam # ou $SYS/# inesperadamente.
• Acompanhe o número de conexões e a taxa de mensagens por cliente para identificar dispositivos comprometidos ou com mau comportamento.
• Mantenha o broker e as bibliotecas cliente atualizados.

Checklist de segurança MQTT

Quando um cliente com acesso restrito não consegue se conectar, o reason code do CONNACK diz se o problema foi de credenciais ou de autorização — consulte-o na referência de reason codes MQTT.

Perguntas frequentes