O estado da IoT
A Gartner prevê que haverá 20,8 bilhões de dispositivos conectados em todo o mundo até 2020. O número crescente de dispositivos conectados na Internet das Coisas (IoT) oferece aos provedores de serviços a oportunidade de desenvolver novas fontes de receita. Para os usuários finais, a IoT tem o potencial de oferecer soluções capazes de melhorar significativamente a produtividade e a qualidade nas áreas de segurança, saúde, educação e muitas outras. Para aproveitar essa oportunidade, os provedores de serviços devem oferecer uma experiência ideal ao cliente, garantindo ao mesmo tempo proteção absoluta dos dados, privacidade e segurança dos usuários.
No entanto, essa grande quantidade de dispositivos diversos também aumentará a vulnerabilidade da rede, pois muitos deles poderão se tornar alvos de hackers e ataques de negação de serviço. Os dispositivos de IoT geralmente têm recursos limitados de memória, armazenamento e processamento. Essas limitações dificultam o suporte a algoritmos de segurança complexos e em constante evolução, pois eles exigem maior capacidade de processamento com poucos ciclos de CPU. Além disso, os dispositivos conectados podem permanecer em uso por mais tempo do que a criptografia se mantém eficaz.
Em uma pesquisa e um relatório de fevereiro de 2016 sobre O Futuro da Prestação de Serviços Móveis, Jim Hodges, analista sênior da Heavy Reading, destacou que a principal preocupação das operadoras com a segurança são as interrupções causadas por ataques distribuídos de negação de serviço (DDoS) e por botnets. Em seguida, vêm as ameaças relacionadas à integridade dos sistemas, nas quais invasores externos manipulam o tráfego enquanto se passam por um usuário.
Três conceitos são fundamentais para a segurança da IoT: identidade, autenticação e autorização. A identidade diz respeito a nomear o cliente e conceder-lhe autorização. A autenticação consiste em comprovar a identidade do cliente, enquanto a autorização se refere ao gerenciamento dos direitos concedidos a ele. Para viabilizar também a coleta de dados dos dispositivos para análise de inteligência em tempo real, é necessário definir os protocolos de comunicação da IoT.
Os protocolos de mensagens de IoT devem incluir as seguintes funções de alto nível:
- Validação do protocolo de mensagens e mitigação de DDoS
- Mediação de protocolos com tradução de diversos protocolos de IoT
- Interoperabilidade de protocolos de mensagens de IoT
- Detecção e prevenção de tempestades de sinalização de IoT
Atualmente, o protocolo de mensagens de IoT mais utilizado é o MQTT (Message Queue Telemetry Transport). O MQTT é usado como protocolo de transporte principal em diversos setores, incluindo manufatura, transporte e rastreamento de ativos, energia e casas conectadas. Empresas como IBM, Microsoft, Amazon Web Services e Facebook Messenger usam o MQTT para entregar mensagens rapidamente e economizar a bateria dos dispositivos.
Segurança do protocolo
Noções básicas de MQTT
Protocolos de IoT, como o MQTT, são usados para garantir uma comunicação segura e confiável entre dispositivos. O MQTT é baseado no Protocolo de Controle de Transmissão (TCP) e pode ser protegido com o protocolo de Segurança da Camada de Transporte (TLS). O protocolo MQTT foi projetado para exigir pouca capacidade de processamento e memória, com pacotes muito mais simples e menores do que os do HTTP, sendo otimizado para determinadas aplicações de IoT.
O MQTT foi criado originalmente em 1999 para sensores remotos, mas ganhou uma nova aplicação em diversas soluções de IoT baseadas em um modelo de publicação e assinatura. Os dispositivos/sensores “publicam” dados em uma plataforma de IoT (broker), e a aplicação de IoT então “assina” os dados relevantes para seu caso de uso. Os dados publicados e assinados são chamados de “tópicos” e podem ser organizados em uma estrutura hierárquica com base nos casos de uso e na categoria do tipo de dado. A conectividade e a comunicação entre os dispositivos e a plataforma influenciam a carga, o controle e a segurança exigidos por cada caso de uso.
Para manter o protocolo o mais leve possível para dispositivos de IoT com recursos limitados, o MQTT oferece segurança mínima além do TCP. O MQTT apenas recomenda o uso do protocolo TLS para aplicações que exigem níveis adicionais de autenticação. Como resultado, as comunicações MQTT que dependem exclusivamente do TCP não são criptografadas e estão sujeitas a ataques man-in-the-middle.
Vulnerabilidades do MQTT
O protocolo MQTT apresenta diversas vulnerabilidades em potencial. Por exemplo, portas abertas podem ser usadas para realizar ataques de negação de serviço (DoS), bem como ataques de estouro de buffer em redes e dispositivos. Dependendo do número de dispositivos de IoT conectados e dos casos de uso compatíveis, a complexidade da estrutura de “tópicos” pode aumentar significativamente e causar problemas de escalabilidade. As cargas úteis das mensagens MQTT são codificadas em formato binário, e os tipos de aplicações/dispositivos correspondentes devem ser capazes de interoperar. Outra área problemática envolve os nomes de usuário e as senhas das mensagens MQTT, que são enviados em texto não criptografado.
Embora não faça parte especificamente da especificação MQTT, tornou-se prática comum que os brokers de plataformas de IoT ofereçam suporte à autenticação de clientes por meio de certificados SSL/TLS do lado do cliente. A criptografia de transporte com SSL e TLS pode proteger os dados quando implementada corretamente. Para evitar ameaças, dados confidenciais, incluindo IDs de usuário, senhas e quaisquer outros tipos de credenciais, devem ser sempre criptografados.
A desvantagem de usar TLS, SSL e outros métodos de criptografia é que eles podem gerar uma sobrecarga significativa. No entanto, técnicas como a retomada de sessão TLS podem compensar parte dos custos de conexão do TLS. A aceleração por hardware é outro método para reduzir o impacto da criptografia no tamanho. Para aplicações complexas executadas em dispositivos com recursos limitados, uma biblioteca de criptografia otimizada pode ser muito útil. Quando o código da aplicação é extenso, uma biblioteca de criptografia pode reduzir o uso de memória de processamento e melhorar o desempenho.
A arquitetura do MQTT depende da alta disponibilidade dos brokers. O uso de certificados X.509 para autenticação de clientes pode poupar recursos no lado do broker quando muitos clientes tentam usar seus serviços, como consultas a bancos de dados ou chamadas a serviços web. Combinar o MQTT com padrões de segurança de última geração, como o TLS, e usar certificados X.509 também pode ajudar a melhorar a segurança e o desempenho.
Segurança de ponta a ponta para aplicações de IoT
A IoT representa uma nova e importante oportunidade de negócios para os provedores de serviços. Embora proteger o protocolo de mensagens MQTT com TLS seja uma consideração de segurança importante, muitos outros vetores de ataque também podem ser explorados. Os provedores de serviços devem garantir a segurança de ponta a ponta, com autenticação rigorosa de dispositivos, autorização e políticas impostas pela rede para o acesso aos canais de comunicação. A criptografia de dados para garantir a segurança e a privacidade também é fundamental para as fontes de receita dos provedores de serviços e para oferecer uma experiência ideal ao cliente.
Sobre o autor
Publicações relacionadas no blog
Entrega e proteção de agentes de IA em fábricas de IA: F5 para a arquitetura de referência NVIDIA OpenShell para agentes de IA seguros
As soluções da F5 ampliam a Arquitetura de Referência NVIDIA OpenShell para agentes de IA seguros.
Como medir – e minimizar – o custo total de propriedade do seu Kubernetes
O Kubernetes pode ser baixado e executado gratuitamente, mas sua manutenção está longe de não ter custos. Assim como outras grandes plataformas de código aberto que são “gratuitas” apenas em um sentido simplista, o Kubernetes quase certamente exigirá investimentos para ser implantado e operado.
As-Code: a pilha de TI contínua
Infraestrutura, configuração, pipeline, operações. De repente, tudo é “como código”. Lori MacVittie busca esclarecer a terminologia e identificar os diferentes componentes de uma stack contínua de TI.
O estado da entrega de aplicações em 2017: automação, APIs e DevOps
Explore o relatório State of Application Delivery de 2017. Leia o blog retrospectivo da F5 sobre o início da ascensão das redes declarativas e dos pipelines de DevOps.
DevOps Summit: onde a rede foi convidada para a festa
No DevOps Summit NY, falou-se muito não apenas sobre DevOps, mas também sobre contêineres, IoT e microsserviços. As sessões se concentraram não só na mudança cultural necessária para crescer em escala com uma abordagem DevOps, mas também fizeram questão de incluir...
F5 e Nutanix convergem em infraestrutura no .NEXT
Aplicações empresariais como Microsoft SharePoint e Exchange, juntamente com a VDI, continuam sendo a espinha dorsal da sua empresa. A produtividade, embora não seja tão atraente quanto o lucro, é um fator essencial para o sucesso das operações empresariais atuais. Deixar de...