SEGURANÇA EM IOT RESIDENCIAL: UMA PROPOSTA DE ARQUITETURA BASEADA EM EDGE COMPUTING E DEFESA EM PROFUNDIDADE

REGISTRO DOI: 10.69849/revistaft/ni10202511282055


Carlos Mariano de Souza Rocha Neto
Orientador: Mauro José Araújo de Melo


Resumo

O aumento expressivo de aparelhos da Internet das Coisas (IoT) nas casas trouxe muita facilidade e automatização, só que também abriu muitas brechas para ataques cibernéticos. A variedade de aparelhos, a pouca capacidade de processamento e o descuido com a segurança por parte de quem fabrica esses produtos deixam tudo muito vulnerável, colocando em risco a privacidade e a proteção dos usuários. Este estudo busca resolver a falta de uma visão completa da segurança no ambiente doméstico da IoT. O foco principal é apresentar uma estrutura teórica com várias camadas para diminuir esses riscos de forma eficiente. O método utilizado envolveu uma análise detalhada do que já foi publicado sobre o assunto para identificar os principais problemas de segurança — como garantir a autenticidade, a criptografia, a privacidade e como lidar com ataques comuns —, e também uma comparação entre as formas de estruturar sistemas já existentes, como os que usam nuvem, computação de borda, redes em malha e blockchain — avaliando o que funciona e o que não funciona dentro de casa. A partir dessa análise, surgiu a ideia de uma estrutura que mistura o que cada um desses sistemas tem de melhor. Essa estrutura é dividida em três camadas — Dispositivo Seguro, Gateway Inteligente na Borda e Plataforma de Nuvem Segura —, especificando quais componentes usar, quais protocolos seguir, como se proteger de ataques e como garantir um fluxo de dados seguro. Para ver se o modelo funciona, foi feita uma análise teórica de possíveis ataques. A conclusão é que a estrutura proposta oferece uma solução forte e equilibrada, aumentando a proteção, a privacidade e a capacidade de reagir a ameaças, embora reconheça que ela pode ser cara e difícil de colocar em prática.

Palavras-chave: Segurança em IoT, Arquitetura de Software, IoT Doméstica, Mitigação de Riscos, Computação de Borda.

Abstract

The significant increase in Internet of Things (IoT) devices in homes has brought great convenience and automation, yet it has also exposed numerous vulnerabilities to cyberattacks. The heterogeneity of devices, their limited processing power, and the neglect of security by manufacturers leave the ecosystem highly vulnerable, jeopardizing user privacy and protection.

This study aims to address the lack of a comprehensive security overview in the domestic IoT environment. The primary focus is to present a multi-layered theoretical framework to efficiently mitigate these risks. The methodology involved a detailed literature review to identify key security challenges—such as ensuring authenticity, encryption, privacy, and handling common attacks—as well as a comparison of existing architectural models, including cloud computing, edge computing, mesh networks, and blockchain, evaluating their effectiveness within a home setting.

Based on this analysis, a framework was proposed that integrates the strengths of these systems. This structure is divided into three layers—Secure Device, Intelligent Edge Gateway, and Secure Cloud Platform—specifying components, protocols, defense mechanisms, and methods to ensure secure data flow. To validate the model, a theoretical analysis of potential attacks was conducted. The conclusion is that the proposed structure offers a robust and balanced solution, enhancing protection, privacy, and threat response capabilities, while acknowledging the potential costs and complexity of its implementation.

Keywords: IoT Security, Software Architecture, Home IoT, Risk Mitigation, Edge Computing.

1 Introdução

A vida das pessoas continua se transformando consideravelmente de modo sutil, principalmente quanto há a inserção de um novo aparato tecnológico que é capaz de afetar a sua rotina, desde organização de agenda de compromissos, até a utilização de robôs atuantes na limpeza de suas residências, resultante do avanço tecnológico denominado de Internet das Coisas (Internet of Things – IoT). Anteriormente, aparelhos como geladeiras, máquinas de lavar roupa, máquinas de lavar louças, televisão, luz e, muitos outros tinham seu funcionamento isolado e necessitava que um usuário realizasse a ação de ligá-los e desligá-los sempre que desejasse utilizá-lo, porém, com a conexão destes com a internet eles podem conectar-se e até mesmo conversar entre si, criando as chamadas casas inteligentes (BOECKL et al., 2021).

A união entre estes aparelhos promete um futuro mais fácil e automático, onde se pode controlar a tudo remotamente, pela utilização do aparelho celular ou outros aparelhos. No entanto, essa conexão também apresenta a um problema importante: para tornar a vida confortável e com uma certa praticidade, realizou a integração de aparelhos, e aumentaram assim, o número de vulnerabilidades e/ou brechas por onde criminosos virtuais podem atacar casas e empresas, expondo os usuários a vários perigos, desde o roubo de informações até riscos à segurança pessoal (HAYASHI et al., 2021).

1.1 Contexto do problema

A raiz desse problema está na natureza insegura desses dispositivos, principalmente quando se refere a pouca capacidade de interoperabilidade padronizada, com protocolos de comunicação e plataformas de softwares diferentes, o que dificulta comunicação e fragiliza a segurança (HAYASHI et al., 2021; IoT Security Foundation, 2018).

Acrescentando-se a isso a necessidade dos fabricantes de, no desejo de sempre estarem propondo soluções atualizadas, proporem gadgets com novas funcionalidades e facilidades de uso, deixando em segundo plano medidas de segurança mais resilientes e integrativas com outras tecnologias (MEDEIROS, 2023).

Somado a isso, a correta gestão do ciclo de vida dos gadgets, incluem-se atualizações contínuas disponibilizadas pelos fabricantes, além da realização de uma comunicação clara sobre o fim do suporte, ou ainda, que haverá mudança de titularidade do serviço, sendo comumente negligenciado, admitindo que os usuários estejam utilizando dispositivos vulneráveis por longos períodos.

Esse tipo de prática leva produtos com vulnerabilidades de diferentes escalas à prateleira, onde vão desde senha padrões previsíveis, passando por firmwares desatualizados ou sem previsão de atualização até a ausência de criptografia nas comunicações (Instituto Brasileiro de Cibersegurança, 2025).

Em consequência disso, ambientes domésticos, antes considerados invioláveis a ameaças cibernéticas externas, tornaram-se um campo vasto para a aplicação desses ataques, comprometendo a privacidade e integridade física dos residentes. Por conta dessas limitações, pertencentes aos dispositivos finais (KHAN; SALAH, 2018), abordagens que propõe delegação ou descarregamento (“offload”) de ações de segurança para os nós intermediários com processamento mais robusto, tais como os gateways, ou para os nós de borda, como o edge computing, em que são alternativas cada vez mais estudadas para incrementar uma segurança eficaz sem que haja sobrecarregamento dos sistemas dos dispositivos de IoT. (SHA et al., 2020).

1.2 Definição do Problema de Pesquisa

A falta de um padrão de arquitetura de segurança global na qual atenda às necessidades de um ambiente doméstico que utiliza(m) dispositivo(s) de IoT para automação de processos, gerando uma lacuna severa na prática da engenharia de software e segurança da informação e na literatura de ambas as áreas. As soluções existentes no mercado frequentemente atuam de forma isolada, como a segurança de um único dispositivo ou protocolo, ou são adaptadas a soluções em ambientes coorporativos, em que se desconsideram alguns aspectos importantes, tais como as limitações de recursos (processamento, memória, energia) dos dispositivos e também, as limitações técnicas dos usuários finais (HAYASHI et al., 2021; KHAN; SALAH, 2018).

Nessa linha de raciocínio, sistemas que usam um hub central em casas, com um único lugar para ver tudo e controlar, tornam mais fácil para as pessoas cuidarem da segurança. Contudo ainda é difícil fazer tudo funcionar junto e nem sempre dá para proteger de tudo que é importante, então precisa-se pensar em outras maneiras para solucionar a este problema (IoT Security Foundation, 2018).

Concomitantemente, tecnologias como o blockchain estão sendo estudadas porque podem ajudar a manter os dados seguros, controlar quem tem acesso e gerenciar identidades sem precisar de um hub central. Mesmo assim é complicado, pois gasta muita energia e nem sempre funciona bem em muitos aparelhos residencial que não são muito potentes (KHAN; SALAH, 2018; MINOLI; OCCHIOGROSSO, 2018).

Desta maneira, o que se quer descobrir com este estudo é: Como criar um sistema que pode associar duas ou mais formas de proteção com o intuito de otimizar o sistema diminuindo os perigos à segurança nas casas conectadas, levando-se em conta limites e a especificidade das coisas?

1.3 Justificativa e relevância

Este estudo pretende alcançar utilidade social, acadêmica e corporativa. Quanto à esfera social, a premissa que se refere à privacidade de habitações e, por conseguinte, proteção do sigilo de dados pessoais é irrefutável e reconhecida como um direito pelos cidadãos no capítulo da Constituição da República Federativa do Brasil de 1988 (Brasil, 1988).

A ampla quantidade de dados e informações pessoais coletadas pelos dispositivos IoT, desde informações diárias até mesmo conversas privadas, tornam a proteção destes equipamentos essencial para o usuário contra ações de espionagem, furtos de identidades e comércio ilícito (Kaspersky, S.d.-b). A maior procura desses dispositivos para atividades mais críticas, como a segurança residencial por fechaduras eletrônicas e câmeras de segurança, ou o uso para monitoramento de saúde, com dispositivos de verificação de sinais vitais, demonstram que uma falha de segurança pode acarretar em consequências físicas diretas aos usuários destas.

Voltando-se aos termos acadêmicos e coorporativos, este trabalho busca preencher a lacuna identificada, propondo uma proposta de arquitetura voltada a sintetizar e aprimorar aos paradigmas existentes, apresentando-se um modelo conceitual validado teoricamente, que ofereça um framework que pode servir tanto de base para novas pesquisas acadêmicas quanto a sua aplicação industrial.

1.4 Objetivos

Para abordar o problema de pesquisa definido aqui, este trabalho acadêmico propõe os seguintes objetivos:

  • Objetivo Geral:
    • Propor conceitualmente uma arquitetura para mitigação de riscos de segurança em ambientes de Internet das Coisas (IoT) domésticos.
  • Objetivos Específicos:
    • Realizar uma revisão sistemática da literatura para categorizar e identificar os principais desafios de IoT em segurança, focando em autenticidade, criptografia, privacidade e vetores de ataques comuns.
    • Realizar uma análise comparativa crítica dos paradigmas arquiteturais de segurança que são aplicados à IoT, incluindo abordagens centralizadas (nuvem), descentralizadas baseadas em edge computing, blockchain e redes em malha.
    • Detalhar e desenvolver uma arquitetura singular híbrida, especificando camadas, componentes, protocolos de comunicação recomendados e fluxo de dados seguros.
    • Discutir de forma teórica os benefícios, limitações e cenários de proposição da arquitetura aqui definida, validando sua eficácia conceitual contra ameaças previamente identificadas.

1.5 Estrutura do artigo

Este estudo está organizado em seis seções. A Seção 2 apresenta a fundamentação teórica, com a exposição dos pilares da segurança em IoT e uma taxonomia de ameaças e vulnerabilidades. Na Seção 3 realizar-se-á uma análise comparativa dos principais paradigmas arquiteturais de segurança. A Seção 4 descreve de forma detalhada a arquitetura conceitual proposta. Já a Seção 5 será realizado um debate sobre os benefícios e limitações do modelo e apresenta sua validação teórica por meio de cenários de ataque. Por fim, a Seção 6 conclui o trabalho sintetizando as contribuições e apontando os direcionamentos para futuras pesquisas.

2 Fundamentação Teórica: O panorama de ameaças em IoT doméstica

Compreender a natureza e a extensão das ameaças existentes em IoT é imprescindível para poder estabelecer uma arquitetura de segurança eficaz. Logo, esta seção encontra-se voltada a estabelecer a base teórica do estudo, detalhando os princípios fundamentais de segurança em IoT, detalhando os cenários de vulnerabilidade e de ataques que atingem os ambientes domésticos. O Resultado da análise mostra uma cadeia casual nítida: as restrições de recursos inerentes aos dispositivos IoT acarretam comprometimentos de segurança no design, explorados por ataques automatizados em larga escala, transformando um problema de um único aparelho em um risco sistêmico.

2.1 Pilares da Segurança em IoT

Em qualquer sistema de informação, incluindo IoT, o quesito segurança é sustentando por um conjunto de pilares fundamentais. No cenário de dispositivos com alta diversidade e com recursos limitados, torna-se um desafio singular a aplicação desses pilares.

2.1.1 Autenticidade e Gerenciamento de Identidade

No contexto da tecnologia da informação, autenticidade é a garantia de que um usuário ou dispositivo é quem ele afirma ser (HLTI, S.d.). Tal conceito é crucial em IoT pois previne que dispositivos ou pessoas não autorizadas se conectem à rede ou que, hackers se passem por dispositivos legítimos da rede para interceptar ou gerar comados maliciosos.

O Gerenciamento de Identidade e Acesso (Identity and Access Management – IAM) em IoT ultrapassa o modelo tradicional que é centrado no usuário, havendo uma necessidade de identidades digitais únicas para os dispositivos de IoT, que possibilitam alterar ou retirar permissões destes ao longo de seu ciclo de vida (Amazon Web Services, S.d.-a).

Este pilar possui com principal desafio uma falha comum entre os usuários de IoT domésticos: o uso de senhas fracas ou o uso de senhas que já vem pré-configuradas nos dispositivos (padrões de fábrica) que não são alteradas pelos usuários. Essas credenciais são facilmente descobertas por ataques de força bruta ou, no caso das que são padrões de fábrica, são publicadas online, tornando-se vetor de ataque mais comum e eficaz para criação de botnets, que são rede de dispositivos que são hackeados e usados para realizar outros ataques digitais (Kaspersky, S.d.-a), de IoT. Com isso, a ausência de mecanismos robustos de provisionamento de identidade e a dificuldade de criar senhas fortes e únicas para vários dispositivos diferentes acabam fragilizando a segurança do ambiente.

2.1.2 Autenticidade e Gerenciamento de Identidade

A criptografia é um processo que garante a confidencialidade dos dados ao codificar uma determinada informação, de maneira que a mesma esteja legível apenas para os dispositivos ou pessoas autorizadas para acessá-las. Essa prática assume, em IoT, um papel importante na proteção dos dados que estão em trânsito na rede ou em repouso nos dispositivos e nuvens. Mecanismos como Transport Layer Security (TLS) e Datagram Transport Layer Security (DTLS) ((Microsoft, 2023)) estabelecem os alicerces para uma comunicação segura e protegida.

Entretanto, usar os algoritmos de criptografia tradicionais acaba sendo inviável para a maioria dos dispositivos de IoT, que possuem pouca capacidade de processamento, baixo consumo de energia e pouca memória. Como solução, surgiu a criptografia leve (lightweight cryptography), método de desenvolvimento de algoritmos de segurança para dispositivos com limitações de desempenho ((REDDY; JAYALAKSHMI, 2018)). A escolha do algoritmo apropriado é decisão fundamental para garantir segurança e eficiência e é um dos principais desafios no design de sistemas seguros para IoT.

2.1.3 Privacidade dos dados

Dispositivos como os sensores IoT para uso residencial são dispositivos que, desde o primeiro dia em que são ligados, passam a coletar uma quantidade absurda de dados, indo desde a vida de consumo e rotina do usuário até gravações de conversas e vídeos. Portanto, proteger esses dados é vital, não só por motivos de segurança e privacidade para seus usuários finais, mas porque você terá consequências legais, como a LGPD no Brasil. Problemas como a coleta excessiva de dados, ou seja, coletar a mais do que o considerado estritamente necessário, além de se observar a forma como esses dados são armazenados e como eles trafegam sem a devida permissão expressa do usuário, são motivos de preocupação.

Uma violação nesse cenário pode expor o usuário e os demais dependentes da casa a atores maliciosos que podem utilizar esses dados para prática de diversos crimes, como chantagem, roubo e sequestro. Logo, considerando os riscos, o desenvolvimento de qualquer arquitetura deve seguir os princípios de Privacy by Design, garantindo que sejam coletados, protegidos e anonimizados sempre que possível ((CORDEIRO; KUKIELA, 2020)).

2.2 Taxonomia de Ataques e Vulnerabilidades Comuns

No meio digital, uma quantidade significativa de ataques pode ser realizada por agentes maliciosos, se considerarmos os pilares de segurança acima elencados e suas respectivas fraquezas. Interrupção de serviços, violação da privacidade do usuário entre outras são ameaças que agentes maliciosos conseguem fazer através da exploração dessas vulnerabilidades. A seguir, com base em uma revisão na literatura, elenca-se uma taxonomia das ameaças mais relevantes para ambientes domésticos ((HAYASHI et al., 2021)).

2.2.1 Ataques de Rede

Os ataques de rede têm como alvo a infraestrutura de comunicação que interliga e viabiliza o funcionamento dos dispositivos IoT. O principal deles e consequentemente o mais conhecido é o ataque de Negação de Serviço Distribuída (DDoS). Nessa ação, uma grande rede de dispositivos infectados e controlados pelos hackers (uma botnet) é usada para sobrecarregar o alvo (dispositivo, site, servidor etc.) com tráfego de dados, fazendo assim com que o mesmo fique indisponível. Para a formação dessa rede de ataques, os dispositivos IoT acabam sendo os alvos ideais para esse “recrutamento” devido às suas defesas frágeis. Como um exemplo, temos a botnet Mirai, que infectou centenas de milhares de gadgets IOT, aproveitando-se apenas de uma lista de 61 combinações de nomes de usuário e senha padrão ((CAMARGO, 2018)).

A botnet Reaper (ou IoTroop), considerada uma variante da Mirai, é outro famoso exemplo, no meio da tecnologia da informação, de ataques de rede utilizando dispositivos IoT. Porém, ao invés de utilizar os nomes de usuário e senha padrão para “recrutar” os gadgets, a Reaper explorava de forma incisiva vulnerabilidades conhecidas nos softwares dos alvos, o que demonstra que, mesmo os usuários utilizando de senhas fortes, o uso de firmware desatualizados destes os tornavam alvos fáceis para compor a botnet ((JIN et al., 2024)).

2.2.2 Ataques a Protocolos de Comunicação

Protocolos desenvolvidos para serem leves e funcionarem em dispositivos IoT, como o protocolo de mensagens leve para sensores e pequenos dispositivos movéis (MQTT – Message Queuing Telemetry Transport – MQTT) e o protocolo de comunicação projetado para dispositivo com recurso limitado (CoAP – Constrained Application Protocol) não incluem mecanismos de segurança. Como podem ser vistos, estes protocolos são projetados para digitalizar os dados com rapidez e eficácia; portanto, cabe ao software adicionar camadas de criptografia. No caso do MQTT, usufrui o Transport Layer Security (TLS); enquanto, no caso do CoAP, o protocolo utilizado é Datagram Transport Layer Security (DTLS). A ausência dessas camadas (TLS e DTLS) ou sua configuração inadequada expõe toda a comunicação, incluindo credenciais e dados sensíveis dos dispositivos, em situações de ataques de interceptação (eavesdropping) e Man-in-the-Middle (MitM) ((FEREIDOUNI; FADEITCHEVA; ZALAI, 2025)).

Um exemplo claro dessa exposição em massa foi a de brokers MQTT. Pesquisadores de segurança da Avast, empresa conhecida por conta de seu programa de antivírus, em um estudo realizado em 2018, descobria que mais de 49 mil servidores MQTT estavam publicamente acessíveis na internet, sendo 32 mil sem usarem senhas, incorrendo risco de vazamento de dados ((HRON, 2018)).

2.2.3 Ataques de Software e Firmware

A utilização de aparelhos tecnológicos voltados a serem usufruídos conectados pela IoT, necessitam de um software que os controla, denomina-se firmware, que é um dos principais alvos de ataques. Suas fragilidades emergem em sua grande maioria, da falta de atualizações de segurança. Esse problema se reflete em muitos aparelhos de baixo custo que são lançados no mercado, porém os fabricantes destes não disponibilizam atualizações de segurança contra ameaças descobertas após o lançamento do produto ((Instituto Brasileiro de Cibersegurança, 2025)). Mesmo que ainda ocorram as atualizações, o processo de atualização pode ser inseguro, caso não ocorra a verificação da assinatura digital do firmware, permitindo que o cibercriminoso manipule o dispositivo para instalar uma versão maliciosa do firmware, conseguindo assim controle total do gadget ((REDDY; JAYALAKSHMI, 2018)).

Para ilustrar um pouco sobre essas falhas, podemos citar o malware VPNFilter que foi descoberto em 2018. Onde o atacante infectou mais de meio milhão de roteadores e dispositivos de armazenamento de rede (NAS) em vários países. Este malware se instalava em um nível crítico no firmware do dispositivo, o que lhe garantia resiliência mesmo reinicializando o mesmo. Ele explorava uma série de vulnerabilidades conhecidas, porém, não corrigidas pelos fabricantes afetados, dentre estes a Linksys, Netgear e TP-Link. Sua atuação era interceptar o tráfego da rede e roubar credenciais. Ainda possui um módulo destrutivo que inutilizava (“brickar”) os aparelhos, deletando partes vitais do firmware ((LARGENT, 2018)).

2.2.4 Estudo de Caso: A Ameaça Assimétrica do Malware SILEX

Um poderoso exemplo para listar no estudo de caso da assimetria de ameaças é o malware SILEX, que surgiu em 2019. Apesar de não ser uma ameaça tecnicamente sofisticada, este propagava na internet procurando por dispositivos com credenciais Telnet padrão e conhecidas e, após obter o acesso ao dispositivo, apagava o armazenamento do mesmo, removia configurações de rede e reinicia o sistema, tornando o dispositivo inutilizável (processo conhecido como bricking).

O fato de milhões de dispositivos terem sido alvos de um ataque simples destaca uma falha crítica na abordagem de segurança das indústrias produtoras de dispositivos IoT. Isso evidencia a urgência na adoção de arquiteturas que definam e padronizem práticas seguras, tratando a segurança como um pilar fundamental e não como um recurso opcional. Este caso apresentado demonstra que um ataque de baixo custo, complexidade e esforço pode causar danos de alto impacto aos usuários e irreversíveis. Contra essas ameaças não deve haver uma defesa reativa, esta deve ser proativa e embutida na própria arquitetura do sistema, eliminando essas vulneráveis “fáceis” desde o princípio. O fato de milhões de dispositivos terem sido alvos de um ataque simples, destaca-se uma falha na abordagem de segurança nas industrias produtoras de dispositivos IoT. Isso reforça a urgência na adoção de arquiteturas que definam e padronizem práticas confiáveis, tratando a segurança como um pilar fundamental e não algo opcional e ignorável.

3 Análise comparativa de paradigmas arquiteturais de segurança em IoT

A resposta para os desafios existentes em IoT não é monolítica. Vários paradigmas estruturais surgiram com diferentes conjuntos de vantagens e desvantagens. Analisaremos nesta seção e forma crítica, as abordagens mais relevantes (Centralizada baseada em Nuvem, Edge Computing, Redes em Malha e Blockchain) para ambientar e justificar a proposta de uma arquitetura híbrida ((REDDY; JAYALAKSHMI, 2018)).

3.1 Arquitetura Centralizada (Baseada em Nuvem)

A arquitetura centralizada, ou baseada em nuvem é considerado o mais tradicional e utilizado por muitos dispositivos IoT. Neste, os dispositivos se conectam a um servidor central em um serviço de nuvem (como AWS IoT ou Azure IoT Hub), que é responsável por gerir a maioria das funcionalidades de segurança e gerenciamento: autenticação, autorização de acesso, processamento de dados, armazenamento e interface para o usuário final ((SIRAPARAPU; AZAD, 2024)).

  • Vantagens: Sua principal vantagem é a facilidade de gerenciamento. Com um controlador central, a aplicação de políticas de segurança consistentes, monitoramento e atualização do sistema se tornam tarefas fáceis de se fazer. Fora isso, temos a vantagem do poder de processamento e da escalabilidade da nuvem, possibilitando o uso de algoritmos complexos de inteligência artificial e análise de grandes volumes de dados.
  • Desvantagens: Como a dependência é de um único “agente” central, se este falhar ou se a conexão com ele cair, todo sistema se torna inoperante. Outra desvantagem é o tempo de duração entre uma ação e sua resposta, conhecido como latência, um problema crítico principalmente para aplicativos de tempo real de segurança, operando precisão para identificação e reação apropriada a ameaças. Por último, a privacidade dos dados, que são enviados, armazenados e recebidos em servidores de terceiros, fora do controle direto do usuário.

3.2 Arquitetura Descentralizada 1: Edge Fog Computing

O paradigma de Edge Computing, e seu conceito relacionado (Fog Computing), surgiram como uma alternativa para reduzir as desvantagens do modelo centralizado. A ideia era deslocar para “borda” da rede, mais perto dos dispositivos IoT, usando um gateway inteligente ou um dispositivo local, uma parte do processamento, armazenamento e inteligência da nuvem ((EXCEL, 2024)).

  • Vantagens: Nesse modelo de arquitetura, a baixa latência permite uma resposta melhor a ameaças, quase que em tempo real, uma vez que a mesma não depende de comunicação com a nuvem. O processamento de dados local melhora a privacidade, pois antes das informações serem enviadas para fora da rede doméstica, elas são anonimizadas e filtradas. Por fim, o sistema se torna mais resiliente, mesmo que haja quedas de conexão e reduz a superfície de ataques advindos da internet.
  • Desvantagens: Com a descentralização, surgem desafios como o aumento da complexidade de gerenciamento do sistema, pois além de administrar somente a nuvem, o usuário tem que configurar os dispositivos de borda, mantendo seus firmwares atualizados, além da proteção e cuidados físicos do equipamento.

3.3 Arquitetura Descentralizada 2: Redes em Malha (Mesh Networks)

A arquitetura das redes em malha é o modelo mais descentralizado de todos, onde os dispositivos (nós) se comunicam entre si diretamente, formando uma rede colaborativa e tornando o sistema mais resiliência a falhas. Esta arquitetura se apresenta em duas formas, malha completa, onde todos os dispositivos estão interconectados e a malha parcial, onde só alguns se conectam.

  • Vantagens: Esta arquitetura possui como principal vantagem a alta resistência a falhas, pois como não há centralização em apenas um ponto focal, caso haja falha em um ou mais dispositivos, o trafego é redirecionado por outros nós. Esta característica é denominada como self-healing (auto-cura). Por conta dessa estrutura, essa arquitetura torna ataques de negação de serviço contra um único nó ineficiente e a comunicação mais segura, pois as linhas entre os dispositivos impedem acessos desautorizados.
  • Desvantagens: Uma das dificuldades desse modelo é a alta complexidade em gerenciar as chaves de criptografia e a autenticação segura entre cada nó, principalmente quando um nó novo entra ou sai da rede. Da mesma maneira, monitorar o trafego em busca de invasões torna-se uma tarefa árdua, já que diferente do modelo centralizado, não há uma interface única integradora. Este modelo ainda pode aumentar a latência da rede e o consumo energético ((Elsevier, S.d.b)).

3.4 Arquitetura Descentralizada 3: Blockchain

A tecnologia Blockchain foca na confiança e integridade dos dados. Criada para criptomoedas, esta tecnologia utiliza um livro-razão distribuído (Distributed Ledger). O livro-razão distribuído é um banco de dados compartilhado, replicado e sincronizado pelos dispositivos da rede. Neste, todos os nós possuem a mesma hierarquia, os dados estão alocados em blocos que, são criptograficamente encadeados e imutáveis para registrar transações ((Elsevier, S.d.a)). Na esfera do ambiente IoT, o blockchain pode criar um registro imutável de registros de dispositivos, políticas de acesso e interações de informações transmitidas.

  • Vantagens: Uma das principais vantagens dessa arquitetura é a imutabilidade e rastreabilidade dos dados. Sua descentralização extingue a necessidade de um agente centralizador. Ainda conta com os smart contracts (contratos inteligentes), que podem automatizar e realizar políticas de acesso eficazes e delimitar quem pode acessar os dados ou atualiza-los.
  • Desvantagens: Muitos dispositivos IoT de ambientes domésticos não possuem poder computacional e armazenamento para o correto funcionamento do livro-razão do Blockchain. Esta tecnologia possui também menor latência, o que é prejudicial para gadgets que operam com dados em tempo real. Por último, a dificuldade de escalabilidade para redes com grandes números de dispositivos, que geram um volume massivo de mini informações que precisam ser processadas rapidamente ((ALMARRI; ALJUGHAIMAN, 2024); (KHAN; SALAH, 2018)).

3.5 Síntese comparativa

Percebe-se que a análise das arquiteturas acima não revela uma solução única. A Tabela 1 trás o resumo dessa análise.

Tabela 1 – Síntese Comparativa dos Paradigmas Arquiteturais

Critério de ComparaçãoCentralizada (Nuvem)Edge ComputingRede MeshBlockchain
Modelo de ConfiançaCentralizado: Confiança em um provedor de nuvem.Híbrido: Confiança local no gateway e remota na nuvem.Descentralizado: Confiança distribuída entre os nós.Descentralizado: Confiança algorítmica no protocolo de consenso.
Ponto Único de Fa- lhaSim (servidor de nuvem e conexão com a internet).Reduzido (operações locais persistem sem nuvem, mas o gateway é um ponto de falha local).Não (alta resiliência a falhas de nós individuais).Não (alta resiliência a falhas de nós).
Privacidade de DadosBaixa (todos os dados são enviados e processados por terceiros).Alta (dados sensíveis podem ser processados e anonimizados localmente).Média (comunicação local previne exposição externa, mas vulnerável a escuta interna).Alta (pseudoanonimato e controle de acesso via criptografia).
LatênciaAlta (dependente da comunicação de ida e volta com a nuvem).Baixa (processamento e resposta local para ameaças e comandos).Baixa                (comunicação direta entre nós próximos).Alta (devido ao tempo de consenso e validação de transações).
EscalabilidadeAlta (limitada pela capacidade do provedor de nuvem).Média    (limitada pela capacidade de processamento                do gateway).Alta (a rede se fortalece com mais nós).Baixa (desafios significativos com alto volume de transações).
Custo ComputacionalBaixo no dispositivo (tarefas pesadas são delegadas à nuvem).Baixo no dispositivo (tarefas pesadas são delegadas ao gateway).Médio (cada nó precisa participar do roteamento e da manutenção da rede).Alto (cada nó participante precisa de recursos para validar o livro-razão).
ComplexidadeBaixa (gerenciamento centralizado).Média (requer gerenciamento do gateway e da nuvem).Alta (gerenciamento de rede dinâmico e descentralizado).Muito Alta (implementação e manutenção do livro-razão distribuído).
Cenário IdealAplicações não críticas que se beneficiam de análise de dados em larga escala.Ambientes que exigem baixa latência, alta privacidade e resiliência a falhas de internet.Redes com muitos dispositivos de baixa potência espalhados por uma área, onde a conectividade direta é difícil.Sistemas que exigem uma trilha de auditoria inviolável e transações seguras sem uma autoridade central.
Fonte: O autor (2025).

Esta análise revela que a arquitetura de ambientes domésticos de IoT deve ser um modelo híbrido, tendo a baixa latência e privacidade do Edge Computing para operações em tempo real, resiliência das Redes em Malha para comunicação entre os gadgets e o poder de processamento e armazenamento da Nuvem para funções não criticas e interface do usuário.

4 Proposta de Arquitetura Conceitual para Segurança em IoT Doméstica

Após a análise dos desafios de segurança e arquiteturas existentes, esta seção apresentará a contribuição central desta pesquisa: uma proposta de arquitetura conceitual multicamadas, projetada especificamente para o contexto de IoT doméstico. A proposição aqui presente não busca reinventar componentes individuais existentes, mas sim escala-los de maneira inovadora, com a finalidade de criar um sistema doméstico de IoT coerente, balanceando segurança, privacidade, desempenho e experiência do usuário. Fundamentamos o modelo com princípios de segurança modernos e abordagem híbrida para maximizar as vantagens e minimizar as fraquezas das arquiteturas analisadas até aqui.

4.1 Princípios de Design e Justificativa do Modelo

A arquitetura aqui proposta se baseia em um conjunto de princípios de design listados a seguir:

  • Segurança por Design (Security by Design): Este princípio consiste em implementar requisitos de segurança em cada camada e componente da arquitetura, sendo assim um requisito primário no desenvolvimento ((SAUNDERS, 2021)).
  • Defesa em Profundidade (Defense in Depth): O modelo implementa várias camadas de controle, não dependendo de um único mecanismo, tornando o sistema mais resiliente em caso de falha de algum componente ((WANG; SHUMBA; KELLY, 2017)).
  • Confiança Zero (Zero Trust): Nesse princípio, consideraremos que nenhum dispositivo, usuário e comunicação da rede é confiável, sendo verificadas autenticação e autorização em cada evento acontecido ((ROSE et al., 2020)).
  • Menor Privilégio (Least Privilege): Aqui, cada dispositivo da arquitetura detém o mínimo de permissões para executar suas atividades, limitando o dano causado caso um componente seja corrompido ((SAUNDERS, 2021)).

Por conta da inadequação dos paradigmas para o cenário doméstico, emerge a justificativa para um novo modelo. A abordagem única em nuvem esbarra na privacidade e resiliência e uma descentralizada pode elevar o custo de aquisição e deter alta complexidade. Diante disso, esta pesquisa propõe um modelo híbrido, utilizando um gateway de borda como focal da segurança local, mitigando os riscos e criando uma solução equilibrada.

4.2 Camadas e Componentes da Arquitetura

Estruturamos a arquitetura em três camadas lógicas com responsabilidades de segurança distintas.

4.2.1 Camada 1: Dispositivo Seguro (Secure Endpoint)

Está é a principal camada, composta pelos próprios gadgets (sensores, câmeras, atuadores, etc.), tendo como premissa principal de que a segurança deve começar no hardware.

  • Componentes: Dispositivos IoT com recursos de segurança embutidos.
  • Mecanismos de Segurança:
    • Raiz de Confiança de Hardware (Hardware Root of Trust): Haverá um elemento de hardware seguro, como um Trusted Platform Module (TPM) ou um Secure Element (SE) equipado para cada dispositivo. Este elemento armazenará de forma segura as chaves de criptografias privadas, certificados de identidade dos dispositivos e fará operações criptográficas delicadas em um ambiente isolado e seguro ((Adaptnxt, S.d.)).
    • Inicialização Segura (Secure Boot): Consistirá em dissolver o processo de iniciação em etapas, onde há a verificação prévia da assinatura digital do próximo estágio antes de executá-lo, assegurando assim que apenas firmwares autênticos sejam inicializados ((Adaptnxt, S.d.)).
    • Atualização de Firmware Segura (Secure OTA): Os dispositivos devem possuir atualizações remotas (Over-the-Air) usando criptografia no processo de transferência de dados, como a criptografia AES-256, realizar a verificação prévia da assinatura do firmware antes de aplica-lo (processo semelhante a inicialização segura) e seguir os padrões FIPS 140-3 e ISO 27001 para garantir que estejam ativos os mecanismos de criptografia e seguridade dos dados ((RAVIV, 2025)).

4.2.2 Camada 2: Gateway de Borda Inteligente (Intelligent Edge Gateway)

Está camada é o coração da arquitetura de local, sendo representada por um dispositivo de maior capacidade de processamento na rede doméstica, como por exemplo um roteador de última geração, um dispositivo NAS (Network-Attached Storage) ou um pequeno computador dedicado, como o Raspberry Pi.

  • Componentes: Gateway de borda.
  • Mecanismos de Segurança:
    • Firewall e Segmentação de Rede: Atuando como principal ponto de controle de tráfego, este gateway cria um segmento de rede isolado, como uma VLAN, exclusivamente para dispositivos IoT, de modo que isole este de outros dispositivos críticos da rede doméstica ou de computadores pessoais. Assim, todas as comunicações entre a rede IoT e a internet ou com outras redes locais são forçadas a passar pelo firewall do gateway de inspeção ((BALLEJOS, 2025)).
    • Sistema de Detecção/Prevenção de Intrusão (IDS/IPS): O gateway executa uma versão leve de um IDS/IPS, que tem a função de monitorar o tráfego na rede IoT em busca de padrões incomuns ou assinaturas de ataques conhecidos (varreduras de portas, tentativas de exploração de vulnerabilidades, comunicação com servidores de comando e controles conhecidos). Detectando uma ameaça, este pode alertar o usuário, bloquear o tráfego malicioso ou pôr o dispositivo suspeito em quarentena ((REDDY; JAYALAKSHMI, 2018)).
    • Gerenciamento de Comunicação Local e Privacidade: O gateway atuará como um broker local para protocolos como MQTT e gerencia a topologia da rede em malha dos aparelhos. Ele realiza o pré-processamento, anonimização e agregação dos dados. Como exemplo de aplicação temos o circuito interno de tv, onde este dispositivo ao invés de enviar um fluxo de vídeo contínuo de uma câmera para a nuvem, ele pode processar o vídeo de forma local, detectar eventos de interesse (como movimentos) e enviar apenas alertas ou clipes curtos e anonimizados, garantindo assim a privacidade dos usuários.

4.2.3 Camada 3: Plataforma de Nuvem Segura (Secure Cloud Platform)

A utilização da nuvem continua tendo papel fundamental na arquitetura proposta, mas tendo suas responsabilidades redefinidas para focar em funções não críticas em tempo real e que são benéficas globalmente.

  • Componentes: Serviços de nuvem de um provedor (AWS, Azure, Google Cloud)..
  • Mecanismos de Segurança:
    • Gerenciamento de Identidade e Acesso (IAM) Centralizado: A nuvem servirá como hub central para gestão de identidades de usuários (não de dispositivos, que são gerenciados primariamente pelo gateway). Através dela, teremos políticas de acesso robustas, como a Autenticação Multifator (MFA) ((Amazon Web Services, S.d.-b); (Amazon Web Services, S.d.-c)).
    • Repositório de Políticas e Configurações: Armazenamento seguro das configurações de segurança e das políticas de acesso que possuem sincronização periódica com o gateway de borda.
    • Armazenamento Seguro Dos Dados Históricos: A nuvem é usada como um repositório de longo prazo de dados agregados e não sensíveis para análise e treinamento de modelos de aprendizado de máquina, sendo esses dados criptografados sempre. o Interface de Usuário Segura: Sendo um dos pontos mais atrativos para o usuário, as nuvens oferecem interfaces amigáveis, de modo que facilitam a interação com o sistema, sendo essa comunicação protegida por TLS.

4.3 Protocolos Recomendados e Fluxo de Dados Seguro

O fluxo de dados projetado aqui seguirá os princípios de Confiança Zero e Menor Privilégio.

  • Comunicação Dispositivo-Gateway: Os protocolos utilizados dentro da rede local devem ser leves e seguros, sendo recomendados o uso de CoAP sobre DTLS ou MQTT sobre TLS. A autenticação deve ser mútua (mutual authentication), onde tanto o dispositivo quanto o gateway se autenticam usando certificados digitais X.509 armazenados em seus respectivos elementos de hardware seguro ((REDDY; JAYALAKSHMI, 2018)).
  • Comunicação Gateway-Nuvem: Esta conexão será estabelecida através de um túnel seguro, como por exemplo uma VPN (Virtual Private Network), ou, no mínimo, conexão TLS 1.2 ou superior, também com autenticação mútua baseada em certificados ((Amazon Web Services, S.d.-a)).

O fluxo de dados para um evento comum, como de um sensor de porta sendo aberto, pode ser descrito da seguinte maneira:

  1. Onboarding do Dispositivo: Um novo dispositivo é conectado à rede. Ele entra em modo de provisionamento e se comunica com o gateway através de um canal seguro, como por exemplo o Bluetooth Low Energy. Logo, o usuário através do aplicativo, autoriza o dispositivo que recebe um certificado de identidade único do gateway. Este certificado é armazenado no TPM/SE do gateway e registrado na plataforma de nuvem.
  2. Geração do Evento: Ao abrir ou fechar a porta, é gerado um evento.
  3. Transmissão Local Segura: Através do protocolo CoAP/DTLS, o sensor envia uma mensagem criptografada e assinada para o gateway via rede mesh.
  4. Processamento na Borda: O gateway recebe esta mensagem, verifica sua assinatura e autenticidade, e a descriptografa. O módulo IDS analisa o evento no contexto de outros eventos da rede. O gateway, com base em regras pré-configuradas, determina se deve acionar um alarme local (uma sirene) e se o evento precisa ser reportado à nuvem.
  5. Transmissão para a Nuvem: Por meio da conexão TLS segura, o gateway envia uma mensagem agregada (ex: Porta da frente aberta às 18:05) para a nuvem.
  6. Notificação ao Usuário: Após a nuvem receber a mensagem e verificar a identidade do gateway, a mesma envia uma notificação push para o aplicativo do usuário.
  7. Acesso do Usuário: O usuário abre o aplicativo, realiza a autenticação via MFA e pode visualizar o histórico de eventos ou enviar um comando (ex: trancar a porta). O fluxo do comando do usuário seguirá o caminho inverso, com validação de permissões em cada camada.

4.4 Protocolos Recomendados e Fluxo de Dados Seguro

Para visualizar e comunicar a arquitetura proposta, de forma que seja nítida e em diferentes níveis de abstração, recomenda-se o uso combinado do C4 Model para a visão estrutural e de diagramas UML para a visão comportamental.

  • Visualização com o C4 Model ((BROWN, S.d.))
    • Nível 1 – Diagrama de Contexto: Este diagrama de alto nível, representado na Figura 1 (ver Apêndice A, p. 28), mostra o “Sistema de Segurança para IoT Doméstica”no centro. Ele interage com o Morador, Administrador (que pode ser o morador) e o Atacante (que tenta invadir o sistema). Há também interações com Sistemas Externos, como a Plataforma de Nuvem e um Serviço de Notificação.
    • Nível 2 – Diagrama de Contêineres: No diagrama seguinte, representado na Figura 2 (ver Apêndice A, p. 29), temos um “zoom in” no sistema, exibindo os principais blocos de construção (containers). São eles: (1) o “Dispositivo IoT”(tecnologia: microcontrolador, firmware C/C++), (2) o “Gateway de Borda”(tecnologia: Linux, Python, container Docker), (3) a “Plataforma de Nuvem”(tecnologia: AWS/Azure, banco de dados, API REST) e (4) o “Aplicativo Móvel do Usuário”(tecnologia: iOS/Android). As setas entre eles descrevem as interações, como “Envia dados de telemetria via CoAP/DTLS”(do Dispositivo para o Gateway) e “Envia comandos via HTTPS”(do Aplicativo para a Nuvem).
    • Nível 3 – Diagrama de Componentes: Este diagrama, representado na Figura 3 (ver Apêndice A, p. 30), detalha o interior de um contêiner específico, como o “Gateway de Borda”. Ele mostra seus componentes de software internos, como um “Módulo de Firewall”(responsável pelo controle de tráfego), um “Módulo IDS/IPS”(que analisa pacotes), um “Broker MQTT/CoAP Local”(que gerencia a comunicação com os dispositivos), um “Módulo de Gerenciamento de Identidade”(que lida com os certificados dos dispositivos) e um “Agente de Sincronização com a Nuvem”(que envia dados agregados).
  • Visualização com Diagramas UML ((Lucidchart, S.d.))
    • Diagrama de Sequência: Um diagrama de sequência, representado na Figura 4 (ver Apêndice A, p. 31), é ideal para ilustrar o “Fluxo de Dados Seguro”descrito na seção 4.3. Ele mostra as interações cronológicas entre os objetos: Dispositivo IoT, Gateway De Borda, Plataforma De Nuvem e Aplicativo Do Usuário, detalhando as chamadas de método e as mensagens trocadas para registrar um evento e notificar o usuário.
    • Diagrama de Atividades: Um diagrama de atividades, representado na Figura 5 (ver Apêndice A, p. 32), é usado para modelar processos complexos, como o “Onboarding de um novo dispositivo”. Ele mostra o fluxo de atividades desde a conexão física do dispositivo, passando pela autenticação via aplicativo, a geração e o provisionamento do certificado pelo gateway, até o registro final na nuvem, incluindo pontos de decisão e ações paralelas.

5 Discussão e Validação Teórica

Uma vez que a arquitetura proposta por este trabalho é conceitual e sem implementação prática, a sua validação se baseará em uma análise lógica e argumentativa de sua robustez e eficácia, não tomando como base benchmarks de desempenho. Esta seção tem como objetivo, realizar essa validação teórica, discutindo os pontos positivos e limitações do modelo proposto e, após isso, realizar a aplicação da arquitetura a cenários de ataque específicos, com intuito de demonstrar a mitigação das ameaças identificadas na Seção 2 através da ação de seus mecanismos de defesa.

5.1 Análise de Benefícios, Limitações e Trade-offs

Arquiteturas de segurança constituem um exercício de equilibrar diversos fatores. A análise a seguir irá explorar os benefícios alcançados, as limitações e os compromissos pertinentes ao design do modelo proposto.

5.1.1 Benefícios

A arquitetura híbrida proposta possui como principal diferencial a criação de uma metodologia de segurança holística e em camadas, com foco na abordagem das fraquezas dos modelos puros existentes.

  • Resiliência Aprimorada: O sistema doméstico se torna significativamente resiliente ao descentralizar funções críticas para o Gateway de Borda e habilitar a comunicação via rede mesh. Falhas de conexão com a internet, que são os principais gargalos de arquiteturas baseadas puramente em nuvem, não mais comprometerão a execução de funções essenciais de segurança e automação, dentre algumas delas o acionamento de alarmes e o travamento de portas.
  • Privacidade por design: A quantidade de informações pessoais e sensíveis que saem do ambiente doméstico para rede externa é minimizada, tendo assim a redução da exposição a vazamento de dados e/ou vigilância de dados por agentes maliciosos, uma vez que os dados podem ser analisados pelo gateway localmente e este enviar apenas metadados ou alertas para a nuvem. Como por exemplo, o já citado, o uso do gateway para analisar imagens de circuito interno de tv e enviar para nuvem apenas os alertas ou clipes de vídeo criptografados quando houver detecção de movimento.
  • Resposta Rápida a Ameaças: Com a presença de um IDS/IPS no Gateway de Borda, a arquitetura proposta permite a rápida detecção e bloqueio de ameaças internas e externas. Como exemplo, um ataque do tipo força bruta advindo de um dispositivo local comprometido pode ser identificado e contido celeremente pelo gateway, antes que possa causar danos significativos. Em uma arquitetura de nuvem, tudo demandaria mais tempo, já que esta depende da rede e do tráfego na nuvem para realizar a análise necessária para execução de determinada ação.
  • Segurança em Camadas (Defesa em Profundidade): A ação de um agente malicioso se torna mais dificultada, com maior custo e esforço para ser bem-sucedida, uma vez que o mesmo terá que enfrentar múltiplos obstáculos. Tal agente teria que violar a segurança do dispositivo no nível de hardware (como exemplo, contornar o Secure Boot), atravessar o firewall e o IDS do gateway e comprometer a plataforma de nuvem que possui suas próprias defesas de autenticação de usuário.

5.1.2 Limitações e Trade-offs

Apesar dos benefícios acima citados, a arquitetura proposta não está isenta de limitações e compromissos futuros.

  • Custo e Complexidade de Implementação: A introdução do Gateway de Borda inteligente constitui a principal desvantagem, pois roteadores domésticos padrões não possuem a capacidade de executar tarefas como IDS, gerenciamento de rede e processamento de dados, capacidade que o Gateway detém. Por conta disso, o custo de inicial de aquisição tende a ser mais alto. Também tende a ser um gargalo, a configuração inicial do sistema, não tendendo a ser fácil para usuários inexperientes.
  • Ponto Crítico de Falha Local: Na arquitetura aqui proposta, eliminamos as falhas de comunicação com a nuvem, descritas na Seção 3.1, entretanto, ao transferirmos a responsabilidade para o Gateway de Borda, este se torna o ponto crítico para a rede doméstica, uma vez que uma falha em seu hardware ou software pode impactar o ecossistema IoT. Portanto, verificar a confiabilidade e a capacidade de recuperação do Gateway de Borda Inteligente são pontos necessários ao adquirir o equipamento.
  • Gerenciamento e Manutenção: A manutenção da segurança do gateway, o que envolve aplicação de patches e atualização de regras do IDS são cruciais. Mesmos que estes procedimentos possam ser automatizados, o processo de atualização do gateway deve ser extremamente seguro, caso contrário este pode se tornar um novo vetor de ataque. Este ponto tende a exigir um nível de conhecimento técnico do usuário ou, quando o fabricante fornece, um serviço de gerenciamento confiável.

5.2 Validação Conceitual por Cenários de Ataque

A eficácia da arquitetura proposta tem sua validação demonstrada quando analisamos como ela responderia a cenários de ataque realistas, baseados nas ameaças identificadas na Seção 2. Este método nos permite fazer uma avaliação lógica da capacidade do modelo proposto de mitigar riscos.

5.2.1 Cenário 1: Tentativa de Inclusão em uma Botnet (Ataque Externo)

  • Descrição do Ataque: Um servidor malicioso na internet realiza uma varredura, com intuito de encontrar dispositivos IoT com portas abertas e, ao encontrar, tenta um ataque de força bruta para descobrir as credenciais fracas do equipamento. Ao obter êxito, instala um malware e adiciona o dispositivo a uma botnet (semelhante ao Mirai).
  • Mitigação da Arquitetura:
    • 1. Firewall do Gateway (Primeira Linha de Defesa): Por padrão, o firewall do Gateway de Borda Inteligente agiria no bloqueio de todas as conexões de entrada não solicitadas da internet para a rede IoT segmentada. Com isso, mesmos que os dispositivos tenham senhas fracas, o atacante não alcançaria os mesmos.
    • 2. IDS do Gateway (Segunda Linha de Defesa): Se, por alguma razão, como por exemplo uma configuração incorreta, uma porta estiver vulnerável, a atividade de varredura e o seu grande volume de tentativas de login sem êxito em um intervalo de tempo curto, características de um ataque de força bruta, seriam detectados pelo IDS do gateway, o que ocasionaria o bloqueio do endereço IP do atacante e a emissão de um alerta para o administrador da rede IoT.
    • 3. Dispositivo Seguro (Última Linha de Defesa): Por fim, mesmo que o atacante consiga contornar o gateway, a política de senhas fortes realizadas no onboarding do dispositivo e o não uso das credenciais padrões de fábrica ou senhas fracas, tornariam o ataque de força bruta ineficaz. Além disso, o mecanismo de Secure Boot impediria a instalação de um firmware malicioso.

5.2.2 Cenário 2: Vazamento de Dados de uma Câmera de Segurança Comprometida (Ataque Interno)

  • Descrição do Ataque: Uma vulnerabilidade de dia zero, que segundo a IBM ((IBM, S.d.)), é um ataque cibernético que explora vulnerabilidades e falhas de segurança em um software que ainda são desconhecidas pelos desenvolvedores, que ocorre no firmware de uma câmera de segurança interna, pode ser explorada por um ator malicioso para obter controle sobre ela e vazar o fluxo de vídeo ao vivo para um servidor externo de seu controle.
  • Mitigação da Arquitetura:
    • 1. Segmentação de Rede: Como na configuração do ecossistema IoT, a câmera ficou localizada em um segmento de rede isolado, as conexões de saída que podem acontecer para endereços arbitrários na internet são bloqueadas pelas regras de firewall do Gateway de Borda (princípio de menor privilégio). A única conexão externa permitida para a câmera seria com a plataforma de nuvem autorizada, através do próprio gateway.
    • 2. IDS no Gateway: A tentativa da câmera estabelecer uma comunicação além da permitida pelo gateway seria detectada pelo IDS do mesmo, colocando o dispositivo comprometido em quarentena, isolando sua comunicação da rede, e notificando o administrador do sistema.
    • 3. Privacidade por design: Mesmo em operação normal, sem o comprometimento da câmera, a arquitetura por si só, processa as imagens fornecidas pela mesma e envia apenas metadados, como alertas de movimento ou pequenos clipes, para fora da rede local, mitigando o impacto de um eventual vazamento.

5.2.3 Cenário 3: Falha na Conexão com a Internet

  • Descrição do Ataque: O provedor de serviços de internet do ambiente doméstico sofre uma queda do serviço, deixando o mesmo offline e sem conexão com a nuvem.
  • Demonstração de Resiliência pela Arquitetura:
    • 1. Operação Autônoma: Todas as interações que ocorrem na rede interna permanecem funcionando, sem interrupção. Como exemplo, em caso de detecção de fumaça pelo sensor responsável, a sirene será acionada, independentemente de haver conexão com a nuvem.
    • 2. Comunicação Local via Gateway e Mesh: O Gateway de borda gerencia a comunicação entre os dispositivos, atuando como um broker local. A rede mesh também garante que os dispositivos possam se comunicar, mesmo que alguns nós estejam fora do alcance do gateway. Um exemplo prático seria o usuário conectado à rede Wi-Fi local, conseguir acessar a câmera externa da residência através da rede interna LAN (Local Area Network) e acionar o dispositivo de destravamento do portão para entrada de um visitante. Este dispositivo por estar distante do Gateway de Borda, conseguiria se comunicar com o mesmo, através da rede mesh, usando dispositivos próximos como conectores.
    • 3. Armazenamento em Buffer: Este mecanismo, que de acordo com Akamai ((Akamai, S.d.)), é a prática de pré-carregar e armazenar uma parte de um arquivo de mídia no buffer ou memória temporária de um dispositivo, sendo o caso específico de nossa arquitetura, o Gateway de Borda, permite que as informações não sejam perdidas e, assim que a conexão for restaurada, os dados são sincronizados e retirados do buffer.

Estes cenários demostram de maneira teórica, que a arquitetura proposta por este trabalho implementa barreias eficazes contra ameaças, possui resiliência e mecanismos de privacidade essenciais para ambientes de IoT residenciais.

6 Conclusão

A promissora crescente inserção de dispositivos IoT no cotidiano das residências trouxe consigo, uma complexidade segurança superior às defesas tradicionais existentes nas redes domésticas. A análise realizada por este trabalho trás à luz um ecossistema frágil, decorrente de limitações de hardware, práticas de desenvolvimento apressadas, com foco em lançar o “novo” e uma falta de padronização de requisitos de segurança. O problema central abordado foi uma falta de arquitetura de segurança, que de forma integrada e holística, abordasse os desafios únicos deste ambiente.

6.1 Síntese das Contribuições

Ao propor uma arquitetura híbrida, que mitiga os riscos em ambientes de IoT domésticos, este trabalho contribui para a área de Engenharia de Software e Segurança da Informação. Este, não propões a criação de novas tecnologias de segurança, mas a síntese e orquestração de forma estratégica de paradigmas e mecanismos existentes — Security by Design, Defesa em Profundidade, Confiança Zero, Edge Computing, Redes em Malha e segurança na nuvem — em um modelo adaptado e coeso ao contexto do ambiente doméstico.

6.2 Retomada dos Objetivos

Todos os objetivos propostos foram alcançados ao longo deste artigo. O primeiro objetivo foi atingido na Seção 2, quando foi realizada uma revisão profunda dos desafios e ameaças de segurança IoT. O segundo objetivo foi atendido da Seção seguinte (3), com uma análise comparativa e crítica dos paradigmas arquiteturais existentes. A Seção 4 ao detalhar a arquitetura conceitual proposta, cumpriu o terceiro objetivo. Por fim, a Seção 5 alcançou o quarto e último objetivo específico, ao realizar a discussão e a validação teórica do modelo. Logo, o objetivo geral de propor uma arquitetura conceitual foi plenamente alcançado.

6.3 Limitações do Estudo

É imperativo fazer o reconhecimento, de que, o campo da Internet das Coisas e da Segurança da Informação está em constante movimento, com vasto e crescente número de produções acadêmicas. Por conta disso, o esgotamento total da literatura existente sobre o tema não foi possível devido às restrições temporais inerentes à confecção deste artigo. Consequentemente, a construção da arquitetura proposta aqui e a análise crítica cercearam-se o recorte teórico dos artigos e obras citados no decorrer desta produção acadêmica. Portanto, a validação teórica concentrou-se nos caminhos lógicos definidos por este referencial selecionado, dando prioridade para as abordagens mais aderentes ao escopo da arquitetura híbrida e doméstica proposta.

6.4 Trabalhos Futuros

Este trabalho de Conclusão de Curso teve como escopo a proposição e validação teórica de uma arquitetura de segurança IoT doméstica. Como consequência, abre um vasto campo para pesquisas futuras que, tomando este como referência, possam expandir e validar empiricamente as ideias aqui apresentadas. As principais direções para trabalhos futuros incluem:

  • Desenvolvimento de Protótipo e Avaliação de Desempenho: A implementação de um protótipo da arquitetura, utilizando um hardware de prateleira (como Raspberry Pi para o gateway e microcontroladores ESP32 para os dispositivos), possibilitaria uma avaliação quantitativa do desempenho do modelo. Métricas como latência como latência de resposta a eventos, consumo de energia dos dispositivos e a sobrecarga de processamento no gateway poderiam ser medidas e analisadas.
  • Simulação de Ataques em Ambiente Controlado: A criação de um ambiente de simulação de rede (utilizando ferramentas como GNS3 ou Mininet) permitiria testar a resiliência da arquitetura contra um leque mais amplo e sofisticado de vetores maliciosos, podendo assim, avaliar de forma controlada, a eficácia do IDS/IPS do gateway.
  • Análise de Usabilidade e Experiência do Usuário (UX): Como a arquitetura é destinada ao ambiente doméstico, é crucial que suas configurações de segurança sejam gerenciadas por usuários não técnicos. Portanto, uma pesquisa futura poderia focar no design de interfaces de gerenciamento intuitivas e acessíveis para o gateway, de modo que avalie a usabilidade e a carga cognitiva que o usuário final necessita para configurar e administrar o sistema de forma segura.

A continuidade desta linha de pesquisa é de suma importância para transformar os conceitos teóricos robustos em soluções práticas, confiáveis e acessíveis, contribuindo para transformar o futuro das casas inteligentes, assegurando comodidade, segurança e privacidade.

Referências

Adaptnxt. IoT Security Architecture: Best Practices for Protecting Connected Devices. S.l.: [s.n.], S.d. In: ADAPTNXT. Disponível em: <https://www.adaptnxt.com/blog/ iot-security-architecture-best-practices/>. Acesso em: 20 out. 2025. 14

Akamai. O que é armazenamento em buffer? S.l.: [s.n.], S.d. In: AKAMAI. Disponível em: <https://www.akamai.com/pt/glossary/what-is-buffering>. Acesso em: 21 nov. 2025. 22

ALMARRI, S.; ALJUGHAIMAN, A. Blockchain technology for iot security and trust: a comprehensive slr. Sustainability, S.l., v. 16, n. 23, p. 10177, 2024. Disponível em: <https://www.mdpi.com/2071-1050/16/23/10177>. Acesso em: 04 out. 2025. 12

Amazon Web Services. Design principles – Internet of Things (IoT) Lens: Aws well-architected framework. S.l.: [s.n.], S.d.–a. Disponível em: <https://docs.aws.amazon.com/wellarchitected/ latest/iot-lens/design-principles-sec.html>. Acesso em: 26 ago. 2025. 6, 16

Amazon Web Services. Autenticação multifatorial (MFA). S.l.: [s.n.], S.d.–b. In: AWS AMAZON. Disponível em: <https://aws.amazon.com/pt/iam/features/mfa/>. Acesso em: 10 nov. 2025. 15

Amazon Web Services. AWS Identity and Access Management (IAM). S.l.: [s.n.], S.d.–c. In: AWS AMAZON. Disponível em: <https://aws.amazon.com/pt/iam/>. Acesso em: 10 nov. 2025. 15

BALLEJOS, L. How to secure IoT devices. S.l.: [s.n.], 2025. In: NINJAONE. Disponível em: <https://www.ninjaone.com/blog/how-to-secure-iot-devices/>. Acesso em: 10 nov. 2025. 15

BOECKL, K. et al. Considerações para Gerenciar Riscos de Privacidade e Segurança Cibernética na Internet das Coisas (IoT): Nistir 8228. Gaithersburg, 2021. Disponível em: <https://nvlpubs.nist.gov/nistpubs/ir/2021/NIST.IR.8228pt.pdf>. Acesso em: 26 ago. 2025. 2

Brasil. Constituição da República Federativa do Brasil de 1988. Brasília, DF: Presidência da República, 1988. Disponível em: <http://www.planalto.gov.br/ccivil_03/constituicao/ constituicao.htm>. Acesso em: 27 ago. 2025. 4

BROWN, S. The C4 model for visualising software architecture. S.l.: [s.n.], S.d. Disponível em: <https://c4model.com/>. Acesso em: 10 nov. 2025. 17, 28, 29, 30

CAMARGO, C. I. Mirai: um estudo sobre botnets de dispositivos IoT. 174 p. Monografia (Trabalho de Conclusão de Curso (Graduação em Ciência da Computação)) — Instituto de Ciências Exatas, Universidade de Brasília, Brasília, 2018. Disponível em: <https://bdm.unb.br/bitstream/10483/21936/1/2018_CamilaImbuzeiroCamargo_tcc.pdf>. Acesso em: 02 set. 2025. 8

CORDEIRO, L. D.; KUKIELA, M. O privacy by design como requisito dos sistemas de tratamento de dados na lgpd. Informativo Justen, Pereira, Oliveira e Talamini, Curitiba, n. 163, set 2020. Disponível em: <http://justen.com.br/pdfs/IE163/IE163-Lucas-PrivacybyDesignLGPD. pdf>. Acesso em: 02 set. 2025. 7

Elsevier. Distributed ledger. S.l.: [s.n.], S.d. In: SCIENCEDIRECT TOPICS. Disponível em: <https://www.sciencedirect.com/topics/computer-science/distributed-ledger>. Acesso em: 04 out. 2025. 11

Elsevier. Mesh topology. S.l.: [s.n.], S.d. In: SCIENCEDIRECT TOPICS. Disponível em: <https://www.sciencedirect.com/topics/computer-science/mesh-topology>. Acesso em: 21 set. 2025. 11

EXCEL, D. S. Edge computing: opportunities and challenges. World Journal of Advanced Research and Reviews, S.l., v. 23, n. 3, p. 585–596, 2024. Disponível em: <https://wjarr.com/content/edge-computing-opportunities-and-challenges>. Acesso em: 21 set. 2025. 10

FEREIDOUNI, H.; FADEITCHEVA, O.; ZALAI, M. Iot and man-in-the-middle attacks. Security and Privacy, S.l., v. 8, n. 2, p. e70016, mar 2025. Disponível em: <https://onlinelibrary.wiley.com/doi/10.1002/spy2.70016>. Acesso em: 02 set. 2025. 8

HAYASHI, V. T. et al. Segurança em internet das coisas: uma revisão da literatura. In: Anais da XIX Escola Regional de Redes de Computadores (ERRC). Porto Alegre: Sociedade Brasileira de Computação, 2021. p. 103–108. Disponível em: <https://sol.sbc.org.br/index.php/errc/article/view/18550>. Acesso em: 26 ago. 2025. 3, 4, 7

HLTI. Descubra o que é segurança da informação. S.l.: [s.n.], S.d. Disponível em: <https://www.hlti.com.br/seguranca-informacao/>. Acesso em: 26 ago. 2025. 6

HRON, M. Are smart homes vulnerable to hacking? S.l.: [s.n.], 2018. In: AVAST BLOG. Disponível em: <https://blog.avast.com/mqtt-vulnerabilities-hacking-smart-homes/>. Acesso em: 02 set. 2025. 8

IBM. O que é um ataque de dia zero (zero day attack)? S.l.: [s.n.], S.d. In: IBM THINK. Disponível em: <https://www.ibm.com/br-pt/think/topics/zero-day>. Acesso em: 21 nov. 2025. 21

Instituto Brasileiro de Cibersegurança. 10 Vulnerabilidades Críticas em Dispositivos IoT que Podem Comprometer sua Rede. S.l.: [s.n.], 2025. In: BLOG IBSEC. Disponível em: <https://ibsec.com.br/10-vulnerabilidades-criticas-em-dispositivos-iot/>. Acesso em: 26 ago. 2025. 3, 8

IoT Security Foundation. IoT Security Architecture and Policy for the Home – a Hub Based Approach. Release 1. S.l., 2018. Disponível em: <https://www.iotsecurityfoundation.org/ wp-content/uploads/2019/01/IoT-Security-Architecture-and-Policy-for-the-Home.pdf>. Acesso em: 14 set. 2025. 3, 4

JIN, H. et al. A threat modeling framework for iot-based botnet attacks. Heliyon, S.l., v. 10, n. 20, p. e39192, out 2024. Disponível em: <https://pmc.ncbi.nlm.nih.gov/articles/PMC11241190/>. Acesso em: 21 out. 2025. 8

Kaspersky. O que é botnet? S.l.: [s.n.], S.d.–a. Disponível em: <https://www.kaspersky.com.br/ resource-center/threats/botnet-attacks>. Acesso em: 26 ago. 2025. 6

Kaspersky. Por que a segurança do IoT é importante para a sua rede doméstica. S.l.: [s.n.], S.d.–b. Disponível em: <https://www.kaspersky.com.br/resource-center/threats/ secure-iot-devices-on-your-home-network>. Acesso em: 26 ago. 2025. 4

KHAN, M. A.; SALAH, K. Iot security: Review, blockchain solutions, and open challenges. Future Generation Computer Systems, S.l., v. 82, p. 395–411, maio 2018. Acesso em: 14 set. 2025. 3, 4, 12

LARGENT, W. VPNFilter Update – VPNFilter exploits endpoints, targets new devices. S.l.: [s.n.], 2018. In: TALOS INTELLIGENCE BLOG. Disponível em: <https://blog.talosintelligence.com/vpnfilter-update/>. Acesso em: 02 set. 2025. 9

Lucidchart. O que é um diagrama UML? S.l.: [s.n.], S.d. Disponível em: <https: //www.lucidchart.com/pages/pt/o-que-e-uml>. Acesso em: 21 nov. 2025. 18, 31, 32

MEDEIROS, I. Tudo sobre IoT: como melhorar a segurança em dispositivos conectados. S.l.: [s.n.], 2023. In: PROTOTIPANDO. Disponível em: <https://labprototipando.com.br/ tudo-sobre-iot-como-melhorar-a-seguranca-em-dispositivos-conectados/>. Acesso em: 26 ago. 2025. 3

Microsoft. Protocolo de Segurança da Camada de Transporte de Datagrama. S.l.: [s.n.], 2023. In: MICROSOFT LEARN. Disponível em: <https://learn.microsoft.com/pt-br/windows/win32/ secauthn/datagram-transport-layer-security-protocol>. Acesso em: 02 set. 2025. 6

MINOLI, D.; OCCHIOGROSSO, B. Blockchain mechanisms for iot security. Internet of Things, S.l., v. 1-2, p. 1–13, 2018. Disponível em: <https://www.sciencedirect.com/science/article/abs/ pii/S2542660518300167>. Acesso em: 14 set. 2025. 4

RAVIV, D. Updating IoT Devices in 2025: best practices for secure and efficient IoT firmware updates. [S.l.]: [s.n.], 2025. In: UPCITI. Disponível em: <https://www.upciti.com/blog/ updating-iot-devices-in-2025-best-practices-for-secure-and-efficient-iot-firmware-updates/>. Acesso em: 20 out. 2025. 14

REDDY, V.; JAYALAKSHMI, D. S. Architectures of iot: comparison, analysis and research issues. International Journal of Research in Engineering, IT and Social Sciences, S.l., v. 8, n. esp., p. 118–129, jun 2018. 7, 9, 15, 16

ROSE, S. et al. Zero Trust Architecture: Nist special publication 800-207. Gaithersburg, 2020. Disponível em: <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf>. Acesso em: 13 out. 2025. 13

SAUNDERS, T. I. Cybersecurity Challenges of the IoT-Enabled Home Automation Technology: A Security by Design Perspective. Dissertação (Mestrado) — ProQuest Dissertations & Theses, S.l., 2021. Disponível em: <https://www.proquest.com/openview/ e70dfdcab2d7f1f8aa6a121afdd70525/1?pq-origsite=gscholar&cbl=18750&diss=y>. Acesso em: 04 out. 2025. 13

SHA, K. et al. A survey of edge computing-based designs for iot security. Digital Communications and Networks, S.l., v. 6, n. 2, p. 195–202, maio 2020. Disponível em: <https://www.sciencedirect.com/science/article/pii/S235286481930234X>. Acesso em: 14 set. 2025. 3

SIRAPARAPU, S. R.; AZAD, S. M. A. K. Securing the iot landscape: a comprehensive review of secure systems in the digital era. e-Prime – Advances in Electrical Engineering, Electronics and Energy, S.l., v. 10, p. 100798, 2024. Disponível em: <https://www.sciencedirect.com/ science/article/pii/S2772671124003784>. Acesso em: 21 set. 2025. 10

WANG, S.; SHUMBA, R.; KELLY, W. Security by design: Defense-in-depth iot architecture. Journal of The Colloquium for Information Systems Security Education, S.l., v. 4, n. 2, p. 2–9, 2017. Disponível em: <https://cisse.info/journal/index.php/cisse/article/view/65>. Acesso em: 13 out. 2025. 13

APÊNDICE A – DIAGRAMAS DO SISTEMA

Figura 1 – Diagrama de Contexto C4 – Sistema de Segurança para IoT Doméstica

Fonte: Adaptado de Brown (S.d.).

Figura 2 – Diagrama de Contêiners C4 – Sistema de Segurança para IoT Doméstica

Fonte: Adaptado de Brown (S.d.).

Figura 3 – Diagrama de Componentes C4 – Sistema de Segurança para IoT Doméstica

Fonte: Adaptado de Brown (S.d.).

Figura 4 – Diagrama de Sequência UML – Fluxo de Dados Seguro

Fonte: Adaptado de Lucidchart (S.d.).

Figura 5 – Diagrama de Atividade UML – Onboarding de Novo Dispositivo

Fonte: Adaptado de Lucidchart (S.d.).

Rolar para cima