O MQTT é seguro? O protocolo em si oferece apenas os ganchos para a segurança, um campo de usuário e senha e suporte para rodar sobre TLS, e é exatamente tão seguro quanto a implantação em volta dele. Este artigo explica o que o MQTT protege e o que não protege, quais ameaças de fato atingem sistemas reais, os mitos que causam problemas e as camadas que transformam uma configuração MQTT em uma configuração segura.
O que o próprio MQTT oferece
O MQTT foi projetado como um protocolo de mensagens leve, e sua especificação deixa deliberadamente a maior parte da segurança para outras camadas. De fábrica, você tem:
- Um campo de usuário e senha no pacote CONNECT, enviado como bytes simples.
- Ganchos de autenticação estendida do MQTT 5 (um método de autenticação e pacotes AUTH) para esquemas de desafio-resposta implementados pelo broker.
- Reason codes que permitem ao broker dizer "credenciais inválidas" ou "não autorizado".
- Independência de transporte, para que o MQTT possa rodar sobre TLS ou WebSockets seguros.
O que o protocolo não oferece sozinho:
- Nenhuma criptografia. Sem TLS, todo topic, payload e senha pode ser lido na rede.
- Nenhum modelo de autorização. Qual cliente pode usar qual topic fica a cargo do broker.
- Nenhuma integridade ou assinatura de payload. Uma mensagem não traz prova de quem a criou além da conexão pela qual chegou.
- Nenhuma limitação de taxa ou proteção contra abuso. Isso é um recurso do broker.
A especificação OASIS MQTT tem até um capítulo de segurança que trata esses pontos como responsabilidades da implementação. Então a resposta honesta para "o MQTT é seguro" é: o MQTT pode ser protegido, e a segurança é uma propriedade do broker, dos clientes e do desenho da rede.
As ameaças que realmente importam
| Ameaça | Como acontece | Proteção principal |
|---|---|---|
| Escuta | Tráfego na porta 1883 capturado em Wi-Fi, no provedor ou na rede da nuvem | TLS nas portas 8883 / 8084 |
| Roubo de credenciais em trânsito | Senha lida de um CONNECT não criptografado | TLS com verificação de certificado |
| Brokers abertos | Broker exposto à internet com acesso anônimo | Autenticação, sem acesso anônimo em produção |
| Extração de credenciais dos dispositivos | Senha fixa no firmware ou armazenada em flash sem proteção | Credenciais por dispositivo, armazenamento criptografado |
| Personificação | Atacante se conecta com um client ID roubado ou compartilhado | Client IDs vinculados às credenciais |
| Acesso entre tenants | Isolamento fraco em um broker compartilhado | Isolamento de tenants |
| Comandos maliciosos | Qualquer um consegue publicar em um topic de comandos | Autorização, validação de comandos no dispositivo |
| Negação de serviço | Inundação de conexões e de mensagens, logins por força bruta | Cotas, proteção contra flood, bloqueio de IP |
Varreduras em busca de brokers expostos encontram com frequência sistemas na porta 1883 com acesso anônimo, vazando dados de sensores e às vezes aceitando comandos. São falhas de configuração, não vulnerabilidades do protocolo, e é por isso que a maior parte do trabalho real é operacional. Veja brokers MQTT expostos para saber como eles são encontrados e fechados.
Mitos comuns sobre a segurança do MQTT
"O MQTT é inseguro porque envia senhas em texto claro."
Ele as envia em texto claro dentro da camada MQTT, da mesma forma que a autenticação HTTP Basic. Sobre TLS, a conexão inteira é criptografada, incluindo o pacote CONNECT. O problema é rodar MQTT sem TLS, não o MQTT em si.
"A porta 1883 é aceitável dentro da nossa rede."
Redes internas são comprometidas, o Wi-Fi é interceptado e redirecionamentos de porta "temporários" viram permanentes. Trate toda rede como não confiável e use TLS em todo lugar que puder. Reserve a porta 1883 sem criptografia para dados públicos de teste que você não se importaria de ver em qualquer lugar, como o tráfego de demonstração no servidor MQTT público (gratuito), que serve apenas para testes e protótipos.
"Um client ID longo e aleatório é um segredo."
Client IDs aparecem em logs, dashboards e caminhos de topics. Eles identificam um cliente; não o autenticam. A segurança vem da credencial à qual o client ID está vinculado.
"O TLS torna os payloads seguros de ponta a ponta."
O TLS protege cada trecho entre um cliente e o broker. O broker vê o payload em claro. Se você precisa de confidencialidade de ponta a ponta, do dispositivo à aplicação (por exemplo, para dados pessoais sujeitos à LGPD), adicione criptografia de payload MQTT por cima.
"Ninguém vai se dar ao trabalho de atacar meus sensores."
Scanners automatizados não se importam com o que os seus sensores medem, seja numa fazenda no Mato Grosso ou numa estação de saneamento. Eles procuram portas abertas e credenciais padrão, e um broker exposto pode ser usado como ponto de apoio ou como relay gratuito.
As camadas que tornam o MQTT seguro
- Criptografia de transporte. TLS 1.2 ou mais recente na porta 8883, ou WebSockets seguros na porta 8084 para navegadores, com verificação de certificado ativada em todos os clientes.
- Autenticação. Nenhum acesso anônimo a dados de produção. Credenciais únicas por dispositivo e por serviço.
- Vínculo de identidade. Client IDs vinculados às credenciais, para que um cliente não possa se passar por outro.
- Isolamento e autorização. Tenants e ambientes separados; restrinja topics onde o seu broker suportar e projete árvores de topics com identidade e direção visíveis. O guia de ACL MQTT cobre as duas abordagens.
- Proteção contra abuso. Cotas de conexões e de mensagens, proteção contra flood e bloqueio de tentativas de login por força bruta.
- Endurecimento dos dispositivos. Armazenamento criptografado de credenciais, Secure Boot, portas de depuração desativadas, atualizações de firmware assinadas.
- Operações. Rotação de credenciais, monitoramento do estado de conexão e de anomalias e um plano para revogar um dispositivo comprometido.
Como um broker MQTT gerenciado fecha as brechas
Várias dessas camadas ficam do lado do broker, e são exatamente as partes que implantações auto-hospedadas mais erram: certificados expiram, o acesso anônimo continua ligado depois de um teste, um arquivo de senhas é compartilhado por todos os dispositivos. Um broker MQTT gerenciado assume essas responsabilidades.
Veja como o ConnectMQ se relaciona com as camadas acima:
| Camada | ConnectMQ |
|---|---|
| Criptografia de transporte | TLS na porta 8883 e WebSocket seguro na 8084 (caminho /mqtt) com certificado Let's Encrypt |
| Autenticação | Usuário e senha gerados por conjunto de credenciais do broker |
| Vínculo de identidade | Client IDs vinculados às credenciais emitidas |
| Isolamento | Isolamento multi-tenant entre clientes; plano Dedicated para um cluster isolado; BYOC na sua própria conta de nuvem |
| Proteção contra abuso | Cotas por plano, proteção contra flood, bloqueio de IP após repetidas falhas de login |
| Visibilidade | Dashboard, explorador de topics ao vivo e $SYS/broker/connection/{clientId}/state para o estado de conexão de cada cliente |
O ConnectMQ não aplica ACLs por topic, então a sua fronteira de segurança é o tenant e o broker: se dois grupos de clientes não podem ver os dados um do outro, dê a eles brokers separados e mantenha usuários não confiáveis atrás do seu próprio backend, em vez de entregar a eles credenciais do broker. O endurecimento dos dispositivos e a rotação de credenciais continuam sendo responsabilidade sua, como seriam com qualquer broker; os guias proteger credenciais MQTT em dispositivos e boas práticas de segurança MQTT tratam desses temas.
Autoavaliação rápida
Responda sobre a sua implantação atual:
- Algum cliente de produção se conecta pela porta 1883?
- Algum cliente desativa a verificação de certificado?
- Dois ou mais dispositivos compartilham uma credencial?
- Alguma credencial está fixa em uma imagem de firmware ou em um repositório público?
- Você consegue revogar um único dispositivo em minutos sem afetar os outros?
- Você perceberia se um dispositivo começasse a se conectar de um lugar inesperado ou a publicar dez vezes mais do que o normal?
Um "sim" em qualquer uma das quatro primeiras ou um "não" em qualquer uma das duas últimas indica por onde começar.
Comece a usar o ConnectMQ
Tenha TLS, autenticação, vínculo de identidade, isolamento de tenants e proteção contra abuso desde o primeiro dia com um broker MQTT na nuvem gerenciado para você. Crie um broker no plano Serverless (Free) em app.connectmq.com, sem cartão de crédito, e conecte seu primeiro dispositivo pela porta 8883 em minutos.
Perguntas frequentes
O MQTT é seguro sem TLS?
Não. Sem TLS, usuários, senhas, topics e payloads podem ser lidos por qualquer pessoa que consiga capturar o tráfego. Use a porta 8883 ou WebSockets seguros para tudo que não seja dado público de teste.
O MQTT é mais ou menos seguro que o HTTP?
Eles são comparáveis. Ambos dependem do TLS para criptografia e do servidor para autenticação e autorização; nenhum dos dois é seguro em texto claro.
O MQTT 5 melhora a segurança?
O MQTT 5 adiciona autenticação estendida, reautenticação e reason codes mais ricos, o que facilita construir e depurar designs seguros. Ele não adiciona criptografia por si só.
É seguro usar um broker MQTT público?
Para aprendizado e demonstrações com dados não sensíveis, sim. Brokers públicos, como o servidor MQTT público da ConnectMQ, podem ser lidos por todos, então dados de produção devem ficar em um broker privado com credenciais e TLS.
