Arquitetura de segurança para soluções de IoT

Ao projetar e arquitetar uma solução de IoT, é importante entender as ameaças potenciais e incluir defesas apropriadas. Entender como um invasor pode comprometer um sistema ajuda você a garantir que as mitigações apropriadas estejam em vigor desde o início.

Modelagem de ameaças

A Microsoft recomenda usar um processo de modelagem de ameaças como parte do design da solução de IoT. Se você não estiver familiarizado com a modelagem de ameaças e o ciclo de vida de desenvolvimento seguro, consulte:

Segurança na IoT

É útil dividir sua arquitetura de IoT em várias zonas como parte do exercício de modelagem de ameaças:

  • Dispositivo
  • Gateway de campo
  • Gateway de nuvem
  • Serviço

Cada zona geralmente tem seus próprios dados e requisitos de autenticação e autorização. Você também pode usar zonas para isolar danos e restringir o impacto de zonas de baixa confiança em zonas de confiança mais altas.

Cada zona é separada por um limite de confiança, mostrado como a linha vermelha pontilhada no diagrama a seguir. Ele representa uma transição de dados de uma fonte para outra. Durante essa transição, os dados podem estar sujeitos às seguintes ameaças:

  • Falsificação
  • Adulteração
  • Repúdio
  • Divulgação de informações confidenciais
  • Negação de serviço
  • Elevação de privilégio

Para saber mais, confira o modelo STRIDE.

Um diagrama que mostra as zonas e os limites de confiança em uma arquitetura de solução de IoT típica.

Você pode usar STRIDE para modelar as ameaças para cada componente dentro de cada zona. As seções a seguir trazem mais detalhes sobre cada um dos componentes, assim como informações sobre problemas de segurança específicos e as soluções correspondentes.

O restante deste artigo discute mais detalhadamente as ameaças e mitigações para essas zonas e componentes.

Zona do dispositivo

O ambiente do dispositivo é o espaço ao redor do dispositivo em que o acesso físico e o acesso digital de rede local ao dispositivo são viáveis. Supõe-se que uma rede local seja distinta e isolada da internet pública, mas potencialmente colocada em ponte. O ambiente do dispositivo inclui qualquer tecnologia de rádio sem fio de curto alcance que permita a comunicação ponto a ponto dos dispositivos. Ele não inclui nenhuma tecnologia de virtualização de rede criando a ilusão de tal rede local. Ele não inclui redes de operadores públicos que exigem que dois dispositivos se comuniquem entre o espaço de rede pública se entrarem em uma relação de comunicação ponto a ponto.

Zona de gateway de campo

Um gateway de campo é um dispositivo, dispositivo ou software de computador de servidor de uso geral que atua como habilitador de comunicação e, potencialmente, como um sistema de controle de dispositivo e hub de processamento de dados do dispositivo. A zona de gateway de campo inclui o próprio gateway de campo e todos os dispositivos anexados a ele. Os gateways de campo atuam fora das instalações de processamento de dados dedicados, geralmente estão associados à localização, estão potencialmente sujeitos a intrusões físicas e têm redundância operacional limitada. Um gateway de campo normalmente é algo que um invasor pode sabotar fisicamente se tiver acesso físico.

Um gateway de campo difere de um roteador de tráfego, pois ele teve uma função ativa no gerenciamento de acesso e fluxo de informações. O gateway de campo tem duas áreas de superfície distintas. Um deles enfrenta os dispositivos anexados a ele e representa o interior da zona. O outro enfrenta todas as partes externas e é a borda da zona.

Zona de gateway de nuvem

Um gateway de nuvem é um sistema que permite a comunicação remota de e para dispositivos ou gateways de campo implantados em vários sites. O gateway de nuvem normalmente habilita um sistema de análise de dados e controle baseado em nuvem ou uma federação desses sistemas. Em alguns casos, um gateway de nuvem pode imediatamente facilitar o acesso a dispositivos de finalidade especial de terminais, como telefones ou tablets. Na zona de gateway de nuvem, as medidas operacionais impedem o acesso físico direcionado e não são necessariamente expostas a uma infraestrutura de nuvem pública.

Um gateway de nuvem pode ser mapeado para uma sobreposição de virtualização de rede para isolar o gateway de nuvem e todos os seus dispositivos anexados ou gateways de campo de qualquer outro tráfego de rede. O gateway de nuvem em si não é um sistema de controle de dispositivo ou um recurso de processamento ou armazenamento para dados do dispositivo; essas instalações interface com o gateway de nuvem. A zona de gateway de nuvem inclui o próprio gateway de nuvem juntamente com todos os gateways de campo e dispositivos conectados diretamente ou indiretamente a ele. A borda da zona é uma área de superfície distinta pela qual todas as partes externas se comunicam.

Zona de serviços

Um serviço nesse contexto é qualquer componente de software ou módulo que se adapta a dispositivos por meio de um campo ou gateway de nuvem. Um serviço pode coletar dados dos dispositivos e comando e controlar esses dispositivos. Um serviço é um mediador que atua sob sua identidade em relação a gateways e outros subsistemas para:

  • Armazenar e analisar dados
  • Emitir comandos para dispositivos com base em insights ou agendamentos de dados
  • Expor informações e recursos de controle a usuários finais autorizados

Dispositivos IoT

Os dispositivos IoT geralmente são dispositivos de finalidade especial que vão desde sensores de temperatura simples até linhas de produção de fábrica complexas com milhares de componentes dentro deles. Os recursos de dispositivo IoT de exemplo incluem:

  • Medindo e relatando condições ambientais
  • Transformando válvulas
  • Controlando servos
  • Soando alarmes
  • Ativar ou desativar luzes

A finalidade desses dispositivos determina seu design técnico e o orçamento disponível para sua produção e operação de tempo de vida agendada. A combinação desses fatores restringe o orçamento de energia operacional disponível, o volume físico e os recursos de armazenamento, computação e segurança disponíveis.

As coisas que podem dar errado com um dispositivo IoT automatizado ou controlado remotamente incluem:

  • Defeitos físicos
  • Controlar defeitos lógicos
  • Intrusão e manipulação não autorizadas intencionalmente.

As consequências dessas falhas podem ser graves, como lotes de produção destruídos, edifícios queimados ou ferimentos e morte. Portanto, há uma barra de segurança alta para dispositivos que fazem as coisas se moverem ou que relatam dados do sensor que resultam em comandos que fazem com que as coisas se movam.

Controle de dispositivos e interações de dados do dispositivo

Dispositivos de finalidade especial conectados têm um número significativo de áreas de superfície de interação potencial e padrões de interação, que devem ser considerados para fornecer uma estrutura para proteger o acesso digital a esses dispositivos. O acesso digital refere-se a operações realizadas por meio de software e hardware e não por meio de acesso físico direto ao dispositivo. Por exemplo, o acesso físico pode ser controlado colocando o dispositivo em uma sala com um bloqueio na porta. Embora o acesso físico não possa ser negado por meio de hardware e software, é possível adotar medidas para impedir que o acesso físico resulte na interferência do sistema.

Ao explorar os padrões de interação, examine o controle de dispositivo e os dados do dispositivo com o mesmo nível de atenção. O controle de dispositivo refere-se a qualquer informação fornecida a um dispositivo com a intenção de modificar seu comportamento. Os dados do dispositivo referem-se a informações que um dispositivo emite a qualquer outra parte sobre seu estado e o estado observado de seu ambiente.

Modelagem de ameaças para a arquitetura de referência de IoT do Azure

Esta seção usa a arquitetura de referência de IoT do Azure para demonstrar como pensar sobre a modelagem de ameaças para IoT e como lidar com as ameaças identificadas:

Diagrama que mostra a arquitetura de referência de IoT do Azure.

O diagrama a seguir fornece uma exibição simplificada da arquitetura de referência usando um modelo de diagrama de fluxo de dados:

Um diagrama de fluxo de dados derivado da arquitetura de referência de IoT do Azure.

A arquitetura separa os recursos de gateway de campo e dispositivo. Essa abordagem permite que você use dispositivos de gateway de campo mais seguros. Os dispositivos de gateway de campo podem se comunicar com o gateway de nuvem usando protocolos seguros, que normalmente exigem maior poder de processamento do que um dispositivo simples, como um termostato, poderia fornecer por conta própria. Na Zona de Serviços do Azure no diagrama, o serviço Hub IoT do Azure é o gateway de nuvem.

Com base na arquitetura descrita anteriormente, as seções a seguir mostram alguns exemplos de modelagem de ameaças. Os exemplos se concentram nos elementos principais de um modelo de ameaça:

  • Processos
  • Comunicação
  • Armazenamento

Processos

Aqui estão alguns exemplos de ameaças na categoria processos. As ameaças são categorizadas com base no modelo STRIDE:

Falsificação: um invasor pode extrair chaves criptográficas de um dispositivo, seja no nível de software ou hardware. O atacado então usa essas chaves para acessar o sistema de um dispositivo físico ou virtual diferente usando a identidade do dispositivo original.

Negação de Serviço: um dispositivo pode ficar incapaz de funcionar ou de se comunicar interferindo em frequências de rádio ou cortando fios. Por exemplo, uma câmera de vigilância que teve sua conexão de rede ou energia derrubada intencionalmente não pode relatar dados.

Adulteração: um invasor pode substituir parcial ou totalmente o software no dispositivo. Se as chaves criptográficas do dispositivo estiverem disponíveis para o código de invasores, ele poderá usar a identidade do dispositivo.

Adulteração: Uma câmera de vigilância que está mostrando uma imagem de espectro visível de um corredor vazio poderia ser destinada a uma fotografia de tal corredor. Um sensor de fumaça ou incêndio pode relatar alguém segurando um isqueiro sob ele. Em ambos os casos, o dispositivo pode ser tecnicamente totalmente confiável para o sistema, mas ele relata informações manipuladas.

Adulteração: um invasor pode usar chaves criptográficas extraídas para interceptar e suprimir dados enviados do dispositivo e substituí-los por dados falsos autenticados com as chaves roubadas.

Divulgação não autorizada de informação: se o dispositivo estivesse executando software manipulado, tal software manipulado poderia potencialmente vazar dados para partes não autorizadas.

Divulgação de informações: um invasor pode usar chaves criptográficas extraídas para injetar código no caminho de comunicação entre o dispositivo e o gateway de campo ou o gateway de nuvem para extrair informações.

Negação de Serviço: o dispositivo pode ser desativado ou transformado em um modo em que a comunicação não é possível (o que é intencional em muitas máquinas industriais).

Violação: o dispositivo pode ser reconfigurado para operar em um estado desconhecido para o sistema de controle (fora de parâmetros de calibragem conhecidos) e, portanto, fornecer dados que podem ser interpretados incorretamente

Elevação de Privilégio: um dispositivo que realiza uma função específica pode ser forçado a fazer algo diferente. Por exemplo, uma válvula é programada para abrir a metade do caminho pode ser levada para abrir completamente.

Violação/falsificação/repúdio: se não protegido (que raramente é o caso com controles remotos do consumidor), um invasor poderá manipular o estado de um dispositivo anonimamente. Uma boa ilustração é um controle remoto que pode desativar qualquer TV.

A tabela a seguir mostra mitigações de exemplo para essas ameaças. Os valores na coluna de ameaça são abreviações:

  • Falsificação (S)
  • Adulteração (T)
  • Repúdio (R)
  • Divulgação de informações (I)
  • Negação de serviço (D)
  • Elevação de privilégio (E)
Componente Ameaça Atenuação Risco Implementação
Dispositivo S Atribuição de identidade para o dispositivo e autenticação do dispositivo Substituir o dispositivo ou parte dele por outro dispositivo. Como você sabe que está falando com o dispositivo certo? Autenticar o dispositivo, usando o protocolo TLS ou IPsec. A infraestrutura deve dar suporte ao uso de PSK (chave pré-compartilhada) nesses dispositivos que não podem lidar com criptografia assimétrica completa. Usar Azure AD, OAuth
TRID Aplicar mecanismos de prevenção de adulteração aos dispositivos, por exemplo, tornando difícil ou impossível extrair chaves e outros materiais criptográficos do dispositivo. O risco é se alguém está violando o dispositivo (interferência física). Como você tem certeza de que esse dispositivo não foi adulterado. A mitigação mais eficaz é um TPM (módulo de plataforma confiável). Um TPM armazena chaves em circuitos especiais no chip dos quais as chaves não podem ser lidas, mas só podem ser usadas para operações criptográficas que usam a chave. Criptografia de memória do dispositivo. Gerenciamento de chaves para o dispositivo. Assinar o código.
E Ter controle de acesso do dispositivo. Esquema de autorização. Se o dispositivo permitir que ações individuais sejam executadas com base em comandos de uma fonte externa, ou até mesmo sensores comprometidos, isso permite que o ataque execute operações não acessíveis de outra forma. Ter um esquema de autorização para o dispositivo
Gateway de campo S Autenticação do gateway de campo no gateway de nuvem (por exemplo, baseada em certificado, PSK ou em declarações.) Se alguém pode falsificar o gateway de campo, pode se apresentar como qualquer dispositivo. TLS RSA/PSK, IPSec, RFC 4279. As mesmas preocupações de confirmação e armazenamento de chave dos dispositivos em geral, o melhor caso é usar o TPM. Extensão de 6LowPAN para o IPsec para dar suporte a WSN (Redes de Sensores Sem Fio).
TRID Proteger o gateway de campo contra violação (TPM) Ataques de falsificação que enganam o gateway de nuvem pensando que ele está conversando com o gateway de campo podem resultar em divulgação de informações e violação de dados Criptografia de memória, TPMs, autenticação.
E Mecanismo de controle de acesso para o gateway de campo

Comunicação

Aqui estão alguns exemplos de ameaças na categoria de comunicação. As ameaças são categorizadas com base no modelo STRIDE:

Negação de Serviço: os dispositivos restritos geralmente estão sob ameaça do DoS quando escutam ativamente conexões de entrada ou datagramas não solicitados em uma rede. Um invasor pode abrir muitas conexões em paralelo e não atejá-las ou atejá-las lentamente ou inundar o dispositivo com tráfego não solicitado. Em ambos os casos, o dispositivo efetivamente pode ficar inoperante na rede.

Falsificação, Divulgação de Informações: dispositivos restritos e dispositivos de finalidade especial geralmente têm recursos de segurança um para todos, como senha ou proteção de PIN. Às vezes, eles dependem totalmente da confiança na rede e concedem acesso a informações a qualquer dispositivo na mesma rede. Se a rede estiver protegida por uma chave compartilhada que é divulgada, um invasor poderá controlar o dispositivo ou observar os dados que ele transmite.

Falsificação: um invasor pode interceptar ou substituir parcialmente a difusão e falsificar o originador.

Adulteração: um invasor pode interceptar ou substituir parcialmente a difusão e enviar informações falsas.

Divulgação de informações: Um invasor pode escutar uma transmissão e obter informações sem autorização.

Negação de serviço: Um invasor pode bloquear o sinal de difusão e negar a distribuição de informações.

A tabela a seguir mostra exemplos de mitigações para essas ameaças:

Componente Ameaça Atenuação Risco Implementação
Hub IoT de dispositivo TID (D)TLS (PSK/RSA) para criptografar o tráfego Espionagem ou interferência na comunicação entre o dispositivo e o gateway Segurança no nível do protocolo. Com os protocolos personalizados, você precisa descobrir como protegê-los. Na maioria dos casos, a comunicação ocorre do dispositivo para o Hub IoT (o dispositivo inicia a conexão).
Dispositivo para dispositivo TID (D)TLS (PSK/RSA) para criptografar o tráfego. Leitura de dados em trânsito entre os dispositivos. Violação de dados. Sobrecarga do dispositivo com novas conexões Segurança no nível do protocolo (MQTT/AMQP/HTTP/CoAP. Com os protocolos personalizados, você precisa descobrir como protegê-los. A mitigação da ameaça de DoS é para os dispositivos pares por meio de um gateway de campo ou nuvem e fazê-los agir somente como clientes para a rede. O emparelhamento pode resultar em uma conexão direta entre os pares após ter sido agenciado pelo gateway
Dispositivo de entidade externa TID Emparelhamento forte da entidade externa com o dispositivo Espionagem da conexão com o dispositivo. Interferência na comunicação com o dispositivo Emparelhar de forma segura a entidade externa com o dispositivo NFC/Bluetooth LE. Controlar o painel operacional do dispositivo (físico)
Gateway de nuvem de Gateway de campo TID TLS (PSK/RSA) para criptografar o tráfego. Espionagem ou interferência na comunicação entre o dispositivo e o gateway Segurança no nível de protocolo (MQTT/AMQP/HTTP/CoAP). Com os protocolos personalizados, você precisa descobrir como protegê-los.
Gateway de nuvem do dispositivo TID TLS (PSK/RSA) para criptografar o tráfego. Espionagem ou interferência na comunicação entre o dispositivo e o gateway Segurança no nível de protocolo (MQTT/AMQP/HTTP/CoAP). Com os protocolos personalizados, você precisa descobrir como protegê-los.

Armazenamento

A tabela a seguir mostra exemplos de mitigações para as ameaças de armazenamento:

Componente Ameaça Atenuação Risco Implementação
Armazenamento de dispositivo TRID Criptografia de armazenamento, assinar os logs Leitura de dados do armazenamento, adulteração de dados de telemetria. Violação de dados de controle de comando em cache ou enfileirados. Violação de pacotes de atualização de firmware ou configuração enquanto os armazenados em cache ou enfileirados localmente podem levar os componentes de sistema operacional e/ou sistema a serem comprometidos Criptografia, MAC (Message Authentication Code) ou assinatura digital. Onde for possível, controle de acesso forte por meio de permissões ou ACLs (listas de controle de acesso) de recurso.
Imagem do sistema operacional do dispositivo TRID Violação do sistema operacional/substituição de componentes do sistema operacional Partição do sistema operacional somente leitura, imagem do sistema operacional assinada, criptografia
Armazenamento de gateway de campo (enfileirando os dados) TRID Criptografia de armazenamento, assinar os logs Leitura de dados do armazenamento, adulteração de dados de telemetria, adulteração de dados de controle de comando em cache ou enfileirados. Violação de pacotes de atualização de firmware ou configuração (destinados a dispositivos ou gateway de campo) enquanto os armazenados em cache ou enfileirados localmente podem levar os componentes de sistema operacional e/ou sistema a serem comprometidos BitLocker
Imagem do sistema operacional do gateway de campo TRID Violação do sistema operacional/substituição de componentes do sistema operacional Partição do sistema operacional somente leitura, imagem do sistema operacional assinada, criptografia

Confira também

Leia sobre a segurança do Hub IoT em Controlar acesso ao Hub IoT no guia do desenvolvedor Hub IoT.