Práticas recomendadas para executar um back-end de IoT no Google Cloud

Este documento fornece práticas recomendadas de segurança para gerir e executar um back-end da Internet das Coisas (IdC) no Google Cloud. Numa solução de IoT, um back-end de IoT liga dispositivos periféricos a outros recursos. Este documento centra-se nos seguintes back-ends de IdC: o agente Message Queuing Telemetry Transport (MQTT) e a plataforma de IdC.

Este documento faz parte de uma série de documentos que fornecem informações sobre as arquiteturas de IoT no Google Cloud e sobre a migração do IoT Core. Os outros documentos desta série incluem o seguinte:

Este documento fornece práticas recomendadas para o aprovisionamento e a gestão de credenciais de dispositivos, a autenticação e o acesso a dispositivos periféricos de controlo, e para permitir que os dispositivos periféricos de IoT acedam a recursos. Google Cloud

Arquitetura de IdC

Uma arquitetura de IoT inclui serviços que lhe permitem aprovisionar e gerir credenciais de dispositivos, autenticar e controlar o acesso a dispositivos periféricos, bem como permitir que os dispositivos periféricos acedam a recursos Google Cloud . Este documento aborda duas arquiteturas de back-end da IdC: uma que usa o agente MQTT e outra que usa uma plataforma de IdC. As principais diferenças de segurança entre estes dois backends são a identidade do dispositivo e a gestão de dispositivos. As plataformas de IoT oferecem estas capacidades como parte do respetivo sistema, enquanto os agentes MQTT requerem que forneça estas capacidades.

O diagrama seguinte descreve a arquitetura de IoT.

Arquitetura de back-end de IdC.

A arquitetura mostra os serviços necessários para os três processos seguintes:

  1. O aprovisionamento de certificados, que é o processo que tem de concluir para preparar um dispositivo de extremidade para configuração.

  2. Autenticação e autorização, que incluem o esquema de autenticação que o dispositivo periférico e o agente MQTT ou a plataforma de IoT usam para se autenticarem entre si.

  3. Ligações entre dispositivos periféricos e serviços Google Cloud , que são tarefas que o dispositivo periférico conclui para estabelecer ligação a recursos na nuvem e carregar ou transferir dados.

Este documento foca-se principalmente nas práticas recomendadas de segurança para o aprovisionamento e a autenticação.

A arquitetura usa uma combinação dos seguintes serviços e funcionalidades:

  • Um dispositivo periférico (como um dispositivo médico) que implementa nos limites do seu ambiente e que está geograficamente próximo dos dados que quer processar. Os dispositivos periféricos estabelecem uma ligação bidirecional com o seu back-end de IoT, o que significa que podem enviar e receber mensagens do back-end de IoT.
  • Um back-end de IoT que pode ser um agente MQTT ou uma plataforma de IoT.
    • Um agente MQTT fornece uma interface segura para os dispositivos periféricos se ligarem através do protocolo MQTT. Os agentes MQTT não têm capacidades para a identidade do dispositivo e a gestão do dispositivo e dependem de sistemas externos para as fornecer.
    • Uma plataforma de IoT é uma aplicação na nuvem à qual os dispositivos periféricos se ligam e com a qual comunicam. As plataformas de IdC oferecem uma interface segura para os dispositivos periféricos se ligarem através do protocolo MQTT. Cada plataforma de IoT tem a sua própria implementação de segurança que determina como autentica e autoriza os dispositivos periféricos e como gere as identidades dos dispositivos.
  • Uma loja de certificados central que aloja os certificados para todos os dispositivos periféricos.
  • Recursos da nuvem aos quais os dispositivos periféricos têm de aceder.

Aprovisionar um dispositivo de periferia

Antes de um dispositivo periférico poder estabelecer ligação com as suas cargas de trabalho de back-end, tem de aprovisionar um certificado para o dispositivo periférico. Existem dois cenários principais que determinam como aprovisiona o certificado:

  • Se a sua solução se basear em dispositivos comerciais genéricos, tem controlo total sobre o processo de aprovisionamento após a compra do dispositivo.

  • Se usar dispositivos personalizados, o processo de aprovisionamento inicial ocorre durante o fabrico dos dispositivos, e tem de integrar o processo de aprovisionamento com os seus fornecedores e fabricantes.

Em qualquer um dos cenários, tem de criar certificados de dispositivos com uma cadeia de confiança que estabeleça uma ligação a uma autoridade de certificação (CA) raiz. Estes certificados autenticam a identidade do dispositivo e ajudam a garantir que as atualizações e as modificações feitas no dispositivo são realizadas por atores fidedignos. Use uma AC, como o serviço de autoridade de certificação para concluir as seguintes tarefas:

Para aprovisionar um certificado de dispositivo, tem de concluir as seguintes tarefas:

  • Se o seu dispositivo tiver uma solução de segurança inviolável baseada em hardware, como um elemento seguro (SE) ou um módulo seguro de hardware (HSM) que armazena as chaves privadas localmente e as chaves privadas nunca são expostas externamente, faça o seguinte:

    1. Gere o par de chaves pública/privada através da solução de segurança baseada em hardware suportada pelo seu dispositivo.
    2. Solicite um certificado através de um pedido de assinatura de certificado (CSR).

  • Se não estiver a usar uma solução de segurança baseada em hardware para gerar um par de chaves pública/privada, use a CA para gerar as chaves e o certificado. Para mais informações, consulte o artigo Usar uma chave gerada automaticamente. O certificado que transfere através deste método já está assinado.

Depois de gerar e assinar um certificado do dispositivo, instala o certificado do dispositivo assinado no dispositivo periférico e armazena o certificado num repositório de certificados central, como o Secret Manager.

Para mais informações, consulte o artigo Como implementar uma infraestrutura de chave pública segura e fiável com o Google Cloud serviço de AC (PDF).

Para informações sobre outras práticas recomendadas de aprovisionamento, consulte o artigo Práticas recomendadas para o aprovisionamento e a configuração automáticos de sistemas e servidores de metal puro e periféricos.

São usados três tipos de certificados para ajudar a proteger uma solução de IoT:

  • O certificado da CA de raiz fornece a raiz para a cadeia de confiança de todos os outros certificados no seu sistema. As cargas de trabalho de back-end usam o certificado de raiz para validar os certificados de cliente e os dispositivos periféricos usam o certificado de raiz para validar o certificado do servidor. Tem de distribuir o certificado de raiz para o back-end de IoT e para os dispositivos periféricos.

  • Os certificados das ACs intermédias fornecem uma cadeia de confiança baseada na AC de raiz. Pode usar CAs intermédias para o aprovisionamento ou para necessidades operacionais, como conceder acesso a CAs intermédias a fabricantes ou implementar processos de gestão de CAs flexíveis.

  • Os certificados de servidor são usados para proteger os pontos finais expostos pelo back-end de IoT. Tem certificados de servidor para os diferentes algoritmos de encriptação que os seus pontos finais têm de suportar. Os certificados do servidor estão associados à AC raiz. Um gestor de segredos gere e armazena as partes privadas e públicas dos certificados de servidor. Tem de configurar o back-end de IdC com os certificados do servidor e as respetivas chaves privadas.

  • Os certificados de cliente são usados para identificar dispositivos periféricos. Cada dispositivo periférico tem, pelo menos, um certificado de cliente, o que significa que o número de certificados que tem aumenta com o número de dispositivos periféricos no seu ambiente. Os certificados de cliente estão associados à CA de raiz. Tem de distribuir certificados de cliente aos seus dispositivos periféricos e ao back-end de IoT.

Processo de geração de um certificado de dispositivo através de um HSM ou um SE

O diagrama seguinte mostra como é aprovisionado um certificado de dispositivo quando usa um HSM ou um SE.

Processo de geração de um certificado do dispositivo.

Neste diagrama, ocorrem os seguintes passos:

  1. O dispositivo periférico gera o par de chaves públicas no hardware.
  2. Transfere a chave pública e cria o pedido de assinatura de certificado (CSR) para a mesma.
  3. Envia o CSR para a CA para pedir um certificado.
  4. A CA conclui as seguintes ações:
    1. Assina o certificado.
    2. Devolve o certificado assinado ao aprovisionador.
  5. O aprovisionador conclui as seguintes ações:
    1. Envia o certificado assinado para o dispositivo periférico.
    2. Armazena o certificado assinado na loja de certificados central.
  6. O dispositivo periférico armazena o certificado numa localização segura.

Processo de geração de um certificado de dispositivo através da AC

O diagrama seguinte mostra como é aprovisionado um certificado de dispositivo quando usa uma AC.

Processo de geração de um certificado do dispositivo.

Neste diagrama, ocorrem os seguintes passos:

  1. O aprovisionador pede à AC que envie um certificado assinado para o dispositivo.
  2. A CA conclui as seguintes ações:
    1. Gera um par de chaves pública/privada e assina a chave pública.
    2. Devolve o certificado do dispositivo e a chave privada ao aprovisionador.
  3. O aprovisionador conclui as seguintes ações:
    1. Envia o certificado e a chave privada para o dispositivo periférico.
    2. Armazena o certificado e a chave privada na loja de certificados central.
  4. O dispositivo periférico armazena o certificado e a chave privada numa localização segura.

Se quiser armazenar a chave privada num único local (o dispositivo), deve evitar armazená-la no arquivo secreto central. No entanto, se armazenar a chave privada fora do repositório de segredos central e perder o acesso à chave privada, o dispositivo tem de passar novamente pelo processo de aprovisionamento.

Autentique dispositivos antes de assinar certificados

O processo para gerar um certificado de dispositivo (no dispositivo ou através de uma AC) requer que o dispositivo e a AC comuniquem e se autentiquem mutuamente.

Sem a autenticação adequada, a sua AC pode confiar por engano num dispositivo malicioso. Por exemplo, um atacante com conhecimentos sobre como alcançar a infraestrutura de assinatura de certificados da sua AC pode implementar um dispositivo malicioso que pede à sua AC para assinar um certificado. Se não tiver a autenticação do dispositivo em vigor, a sua AC pode assinar o certificado que o dispositivo malicioso apresenta. Se a AC assinar o certificado, o dispositivo malicioso pode comunicar com o seu back-end como um dispositivo fidedigno.

Para ajudar a impedir que dispositivos maliciosos comuniquem com a sua AC, recomendamos que tome as seguintes medidas:

  • Implemente um mecanismo de autenticação para dispositivos que ainda não sejam fidedignos.
  • Estabelecer a autenticidade de qualquer dispositivo que solicite autenticação.
  • Estabelecer a autenticidade do dispositivo antes de um dispositivo pedir à CA para gerar um novo certificado ou assinar um certificado existente.

A implementação de um mecanismo de autenticação neste ponto do processo de aprovisionamento é difícil. Não pode confiar em certificados de dispositivos para autenticar dispositivos porque o dispositivo ainda não tem um certificado assinado da AC. Esta falta de um certificado assinado pode ocorrer pelos seguintes motivos:

  • O dispositivo ainda não gerou um certificado.
  • O dispositivo ainda não enviou um CSR para a AC.
  • A CA ainda não enviou o certificado assinado de volta para o dispositivo.

Uma forma de resolver este problema é estender o processo de aprovisionamento do dispositivo para fazer o seguinte para cada dispositivo que quer autenticar ou precisa de autenticar:

  1. Gere um certificado de aprovisionamento que usa apenas para autenticar o dispositivo na infraestrutura de assinatura de certificados.
  2. Assine o certificado de aprovisionamento com a sua CA.
  3. Armazenar o certificado de aprovisionamento assinado no SE ou no HSM no dispositivo.
  4. Armazene o certificado de aprovisionamento assinado no seu Google Cloud backend.

Antes de o dispositivo receber acesso à infraestrutura de assinatura de certificados da sua AC, tem de apresentar o certificado de aprovisionamento. Tem de apresentar o certificado para que possa validar a respetiva integridade e autenticidade, e determinar se o certificado corresponde a um dos certificados de aprovisionamento armazenados no seu back-end do Google Cloud . Se a validação for bem-sucedida, o dispositivo pode aceder à infraestrutura de assinatura de certificados da sua AC e o processo de aprovisionamento de certificados pode continuar.

Existem diferenças entre um certificado de aprovisionamento e um certificado totalmente fidedigno. Um certificado de aprovisionamento só concede acesso a uma quantidade mínima de serviços e infraestrutura. A criação de um certificado de aprovisionamento permite que a AC verifique se o dispositivo é genuíno antes de o considerar totalmente fidedigno e emitir um certificado totalmente fidedigno.

Uma extensão deste processo é que pode usar ACs subordinadas às quais os fabricantes de dispositivos têm acesso, juntamente com a sua AC, para assinar certificados de aprovisionamento. Por exemplo, um fabricante pode assinar os certificados de aprovisionamento de um dispositivo depois de concluir o processo de fabrico desse dispositivo. Em seguida, pode validar estas assinaturas para ajudar a confirmar que o dispositivo é genuíno.

Se um dispositivo for comprometido antes do aprovisionamento, recomendamos que remova o certificado de aprovisionamento correspondente do seu Google Cloud backend, para que o dispositivo não possa iniciar o processo para obter um certificado totalmente fidedigno, uma vez que não vai conseguir autenticar-se na sua AC.

Práticas recomendadas para a identidade do dispositivo

Esta secção descreve as práticas recomendadas para identidades de dispositivos.

Use um fornecedor de identidade com agentes MQTT

Os agentes MQTT autenticam os dispositivos periféricos através de credenciais de dispositivos fornecidas por plug-ins, bases de dados, e ficheiros. Para gerir as identidades dos seus dispositivos de forma sistemática e escalável, use um fornecedor de identidade (IdP). O IdP gere as identidades e as credenciais de todos os dispositivos e atua como a principal fonte de verdade para as identidades dos dispositivos.

Para manter a identidade do dispositivo atualizada no agente MQTT, implemente uma camada de integração específica do sistema. Para mais informações sobre a gestão de credenciais de dispositivos, consulte o artigo Aprovisionar um dispositivo periférico.

Use as identidades digitais da plataforma de IdC como fonte de informações fidedignas

A plataforma de IoT tem funcionalidades de segurança que gerem as identidades dos dispositivos e as credenciais dos dispositivos, e autenticam e autorizam os dispositivos que tentam aceder à plataforma. Estas funcionalidades de segurança ajudam a garantir que apenas os dispositivos autorizados podem aceder à plataforma de IoT e ajudam a garantir a integridade dos dados.

Verifique se as identidades dos dispositivos geridas pela plataforma de IdC representam a principal fonte de verdade de todos os dispositivos que a plataforma de IdC gere. Outros componentes numa solução de IoT que necessitam de informações de identidade do dispositivo devem basear-se no sistema de segurança da plataforma de IoT. A plataforma de IoT concede direitos de acesso aos dispositivos e propaga quaisquer alterações de segurança por toda a solução de IoT.

Práticas recomendadas para a conetividade de rede

A proteção da conetividade de rede é importante pelos seguintes motivos:

  • As redes seguras ajudam a garantir que um dispositivo se liga ao back-end correto. Por exemplo, uma rede segura pode impedir a falsificação de DNS, que é um ataque que tenta desviar os dispositivos para estabelecer ligação a um back-end malicioso controlado por atacantes.
  • As redes seguras ajudam a garantir que terceiros não conseguem ler o seu tráfego de dados. Por exemplo, uma rede segura pode impedir um ataque de intrusos, em que os atacantes leem o tráfego entre o seu dispositivo e o back-end.

Use o Transport Layer Security (TLS) para proteger a comunicação de rede entre os seus dispositivos periféricos e cargas de trabalho de back-end.

Estenda o TLS com o mTLS para implementar um esquema de autenticação mútua que permita que ambas as partes de ligação estabeleçam a identidade uma da outra.

Para obter instruções sobre a utilização do TLS, consulte os artigos Arquitetura de agente MQTT autónomo no Google Cloud e Arquitetura de produto da plataforma IoT no Google Cloud.

Práticas recomendadas para a gestão de certificados para agentes MQTT

Esta secção descreve as práticas recomendadas para gerir certificados quando usar agentes MQTT.

Armazene certificados de forma centralizada

Armazenar e gerir certificados de servidor e certificados de dispositivos numa localização central. Em concreto, certifique-se de que tem os seguintes controlos implementados:

  • Um inventário de todos os seus dispositivos e respetivos certificados, bem como os pontos finais do servidor e os respetivos certificados.
  • Informações adicionais sobre os certificados, como a respetiva validade.
  • A capacidade de adicionar e remover certificados para dispositivos, para que os dispositivos possam estabelecer ligação através de novos certificados.
  • Direitos de acesso ao seu armazenamento de certificados central, para limitar o que os diferentes papéis no seu back-end podem fazer com os certificados.

Use uma solução de gestão e armazenamento de segredos, como o Secret Manager ou o HashiCorp Vault. O Secret Manager permite-lhe criar versões, atualizar e invalidar credenciais de dispositivos, bem como gerir políticas de acesso às suas credenciais.

Para uma plataforma de IoT, implemente o acesso às credenciais através do acesso à API Secret Manager.

Proteja certificados em dispositivos periféricos

Para armazenar certificados e chaves nos dispositivos periféricos, use um ambiente de execução fiável local ou um arquivo de certificados para proteger a credencial e bloquear acessos não autorizados. Se precisar de armazenar material secreto nos seus dispositivos, encripte esse material usando técnicas como a encriptação flash e armazene-o em elementos invioláveis para ajudar a evitar a extração de dados não autorizada.

Sincronize o armazenamento de certificados central com o armazenamento de certificados do agente MQTT

Os agentes MQTT têm de aceder aos certificados de cliente para a autenticação baseada em certificados, pelo que tem de sincronizar as lojas de certificados dos agentes MQTT com a loja de certificados central. Verifique se as alterações na loja de certificados central, como adicionar, atualizar e eliminar certificados, estão sincronizadas com a loja de certificados do agente MQTT. Os agentes MQTT usam armazenamentos de certificados, como MySQL, PostgresDB e Java Key Store. Consoante a loja de certificados que o seu agente MQTT usa, certifique-se de que existem os seguintes processos:

  • Um processo que monitoriza as alterações no arquivo de certificados central e notifica o processo de sincronização.
  • Um processo que recebe alterações na loja de certificados central e sincroniza as alterações na loja de certificados central com a loja de certificados usada pelo agente MQTT.

Quando usa o Secret Manager como o seu repositório de certificados, pode usar notificações de eventos como o processo de monitorização. Pode implementar o processo de sincronização como um ouvinte das notificações de eventos.

Distribua certificados para dispositivos periféricos em segurança

Quando usar agentes MQTT, distribua o certificado de raiz e os certificados de cliente para os seus dispositivos periféricos. Quando distribui certificados, tem de proteger os seus canais de comunicação para que o tráfego não seja intercetado.

Os principais canais de comunicação para a distribuição de certificados são os seguintes:

  • Um caminho direto do back-end de IoT para os dispositivos periféricos através dos canais de comunicação existentes.
  • Um caminho indireto no qual os dispositivos periféricos pedem e transferem os certificados.

Durante a distribuição de certificados, precisa dos seguintes componentes:

  • Uma loja de certificados onde os certificados são geridos centralmente.
  • Um coordenador de distribuição que envia os certificados e acompanha o processo de distribuição para cada dispositivo periférico.
  • Um gestor de atualizações no dispositivo periférico que recebe ou transfere os certificados e os armazena no dispositivo.

Distribuir certificados durante os processos de aprovisionamento para dispositivos periféricos e quando precisar de rodar certificados.

Durante o processo de aprovisionamento, certifique-se de que o aprovisionador tem acesso direto aos dispositivos periféricos através de canais encriptados, como o SSH, e usa ferramentas como o SCP. Uma vez que os dispositivos não estão em funcionamento, pode enviar certificados diretamente para os dispositivos periféricos.

Quando rodar certificados, use o agente MQTT como o canal de comunicação entre o coordenador de distribuição e os dispositivos periféricos. Use outros canais para transferir certificados para o dispositivo. Para minimizar a interrupção dos dispositivos periféricos em funcionamento, use um caminho de distribuição de certificados indireto. O processo consistiria nos seguintes passos lógicos:

  1. O coordenador de distribuição adquire credenciais de acesso na loja de certificados.
  2. O coordenador de distribuição envia as credenciais de acesso ao certificado para os dispositivos periféricos juntamente com informações adicionais, como o URL de transferência.
  3. O controlador de atualizações no dispositivo recebe as credenciais de acesso e armazena temporariamente as informações e confirma a receção.
  4. O controlador de atualizações coordena a transferência do certificado quando o dispositivo não está ativo. O controlador de atualizações usa as credenciais de acesso para transferir certificados do repositório de credenciais.
  5. Depois de transferidos os certificados, o controlador de atualizações continua com o processo de rotação de certificados, que é descrito na secção Rotação de certificados.

Quando usa o Secret Manager como o repositório de certificados central, pode gerar tokens de acesso de curta duração para conceder e restringir o acesso a certificados. Para mais informações, consulte o artigo Distribua tokens de acesso aos dispositivos de forma segura.

Para ajudar a impedir que os certificados sejam expostos durante o trânsito, encriptar a ligação entre os dispositivos periféricos e o agente MQTT. Para mais informações, consulte Práticas recomendadas para a conetividade de rede.

Rode os certificados automaticamente

Para limitar os danos que um certificado exposto pode causar, gere certificados com um período de validade finito e altere os certificados antes de expirarem. Para implementações de IoT em grande escala, implemente um procedimento de rotação automática de certificados para atualizar consistentemente os seus dispositivos com novos certificados antes que os antigos expirem. Os dispositivos implementados sem certificados válidos significa que os dispositivos podem deixar de funcionar, o que pode ser dispendioso de corrigir e afetar negativamente a funcionalidade geral da sua solução de IoT.

Os seus dispositivos periféricos têm de estabelecer uma ligação bidirecional com o seu agente MQTT para garantir que podem enviar mensagens para o agente MQTT e que podem receber mensagens do agente MQTT.

Durante a rotação de certificados, precisa dos seguintes componentes:

  • Um processo de monitorização que analisa recorrentemente o seu inventário de certificados e procura certificados prestes a expirar. O processo de monitorização aciona a rotação de certificados para certificados com data de validade prestes a expirar.
  • Um processo de rotação que inicializa e supervisiona a rotação de certificados.
  • Um controlador de rotação de certificados do dispositivo no dispositivo periférico que comunica com o agente MQTT e executa passos de rotação de certificados no dispositivo.

Para rodar os certificados, a solução de IoT conclui os seguintes passos:

  1. O processo de rotação envia uma mensagem de inicialização para o dispositivo periférico para iniciar a rotação do certificado.
  2. O controlador de rotação do certificado do dispositivo confirma a mensagem de inicialização enviando uma resposta de volta para a tarefa de rotação.
  3. O processo de rotação pede um novo certificado à AC. Este pedido é semelhante ao pedido de aprovisionamento de certificados, exceto que as chaves e o CSR são enviados como mensagens do agente MQTT.
  4. Depois de receber o novo certificado da CA, a tarefa de rotação distribui o certificado para a loja de certificados central e para o dispositivo periférico. Também sincroniza o certificado com a loja de certificados do agente MQTT.
  5. O controlador de rotação do certificado do dispositivo armazena o novo certificado e inicializa uma nova ligação com o agente MQTT através do novo certificado.
  6. Depois de estabelecer a nova ligação, o controlador de rotação do certificado do dispositivo envia uma mensagem concluída para o agente MQTT.
  7. Após receber a mensagem concluída, o processo de rotação invalida o certificado antigo no repositório de certificados central.

Para ajudar a proteger os certificados que estão a ser enviados durante o processo de rotação, use tópicos MQTT dedicados para a rotação de certificados. Limite o acesso a estes tópicos apenas ao trabalho de rotação e ao dispositivo periférico.

Para ajudar a proteger o processo de rotação de certificados contra falhas de tempo de execução, ative a persistência para as alterações e o progresso.

Para mais informações sobre a rotação de segredos através do Secret Manager, consulte o artigo Rotação de segredos.

Práticas recomendadas para a gestão de certificados para plataformas de IoT

Se estiver a usar uma plataforma de IdC, use os mecanismos de atualização e distribuição de certificados fornecidos pela plataforma. Para fins de cópia de segurança, pode exportar regularmente as credenciais da sua plataforma de IoT para um armazenamento secreto secundário, como o Secret Manager.

Práticas recomendadas para a autenticação com um agente MQTT

Durante o processo de autenticação mútua, as cargas de trabalho de back-end validam a identidade dos dispositivos periféricos e os dispositivos periféricos validam a identidade das cargas de trabalho de back-end. Depois de as cargas de trabalho de back-end confirmarem a identidade do dispositivo periférico, as cargas de trabalho de back-end autorizam o acesso do dispositivo aos recursos.

As secções seguintes fornecem práticas recomendadas para métodos de autenticação quando usa agentes MQTT.

Escolha o método de autenticação para agentes MQTT

Diferentes backends de IoT suportam diferentes métodos de autenticação. Os métodos usados com frequência são os seguintes:

  • Autenticação de nome de utilizador e palavra-passe, em que o dispositivo periférico apresenta o respetivo nome de utilizador e palavra-passe para validar a respetiva identidade.
  • Autenticação baseada em tokens, em que são usados tokens de segurança encriptados para validar a identidade do dispositivo periférico.
  • Esquemas de autenticação personalizados, em que implementa um mecanismo personalizado para validar a identidade do dispositivo periférico.

Como parte da norma MQTT, os agentes MQTT suportam a autenticação de nome de utilizador e palavra-passe como predefinição para pacotes MQTT CONNECT.

O pacote MQTT CONNECT também contém um campo Client Identifier que pode usar para identificar exclusivamente o cliente junto do agente MQTT. Os dispositivos Edge enviam o pacote MQTT CONNECT para o agente MQTT quando estabelecem uma ligação.

Além dos campos de nome de utilizador, palavra-passe e identificador do cliente no pacote MQTT CONNECT, o MQTT 5.0 suporta autenticação melhorada que lhe permite criar fluxos de autenticação de desafio-resposta. O MQTT 5.0 permite várias trocas de pacotes AUTH entre o dispositivo periférico e o agente MQTT.

Use repositórios de palavras-passe com autenticação por nome de utilizador e palavra-passe

Para a autenticação de nome de utilizador e palavra-passe, configure o agente MQTT para usar um armazenamento de palavras-passe. O armazenamento de palavras-passe oferece uma localização centralizada para gerir palavras-passe para todos os dispositivos periféricos que se ligam ao agente MQTT. Por predefinição, os campos de nome de utilizador, palavra-passe e identificador do cliente são opcionais na especificação MQTT. Por conseguinte, crie o seu mecanismo de autenticação para verificar se os campos de nome de utilizador, palavra-passe e identificador do cliente estão presentes no pacote MQTT CONNECT.

Certifique-se de que as palavras-passe estão encriptadas em repouso e em trânsito, da seguinte forma:

Considere a autenticação baseada em tokens

Com a autenticação baseada em tokens, os dispositivos periféricos enviam um token ao agente MQTT para autenticação. Os dispositivos podem gerar o token ou obtê-lo a partir de outros serviços de autenticação. Em comparação com as palavras-passe, os tokens têm uma duração curta: os tokens só são válidos durante um período com uma data de validade explícita. Verifique sempre a expiração ao validar tokens.

Os símbolos da Web JSON (JWT) são uma forma de implementar a autenticação baseada em tokens. Os dispositivos periféricos podem gerar o JWT e autenticar-se com o agente MQTT. O JWT está incorporado no pacote MQTT CONNECT como o campo da palavra-passe.

As vantagens dos JWTs são as seguintes:

  • O JWT oferece-lhe opções sobre o algoritmo de encriptação usado para assinar o token. O JWT funciona bem com dispositivos periféricos restritos, onde pode usar um algoritmo de encriptação menos intensivo em recursos, como o ECC, para assinar o símbolo.
  • Através da criptografia de chave pública, a chave privada é usada apenas no dispositivo periférico e nunca é partilhada com outras partes. Uma chave privada ajuda a tornar este método mais seguro do que a autenticação de nome de utilizador e palavra-passe, em que as credenciais são enviadas através da ligação e requerem a encriptação dos dados.

Considere esquemas de autenticação personalizados

Alguns agentes MQTT suportam diferentes mecanismos e protocolos de autenticação. Por exemplo, se o seu agente MQTT for compatível com esquemas de autenticação personalizados, pode configurá-lo para suportar o seguinte:

  • Protocolos de autenticação padrão da indústria, como: OpenID Connect, Security Assertion Markup Language (SAML), LDAP, Kerberos, e Simple Authentication and Security Layer (SASL). Estes protocolos delegam a autenticação de dispositivos nos seus fornecedores de identidade existentes. Alguns agentes MQTT suportam a autenticação melhorada e os mecanismos de autenticação extensíveis que pode usar para expandir o agente MQTT de forma a suportar novos protocolos e fornecedores de identidade.
  • Autenticação mútua baseada em certificados. Alguns agentes MQTT suportam um esquema de autenticação mútua, como a autenticação baseada em mTLS.

Práticas recomendadas para a autorização e o controlo de acesso a dispositivos

Devido ao padrão de comunicação de publicador e subscritor do protocolo MQTT, o controlo de acesso ao dispositivo é definido através de tópicos MQTT. Os tópicos MQTT controlam a forma como um dispositivo pode comunicar com o seu back-end de IoT. Cada back-end de IoT tem implementações diferentes para o controlo de acesso e a autorização. Por isso, consulte a documentação do back-end de IoT para ver opções sobre como configurar tópicos MQTT.

Use contas de serviço de finalidade única para aceder a Google Cloud recursos

O acesso aos Google Cloud recursos é gerido por políticas de autorização da IAM que associam a autorização de acesso aos recursos a um conjunto de responsáveis. Os principais típicos são contas de utilizador, contas de serviço e grupos. As contas de serviço são normalmente usadas por uma aplicação ou uma carga de trabalho de computação para fazer chamadas de API autorizadas para recursos na nuvem. As contas de serviço permitem que os dispositivos IoT Edge acedam a recursos na nuvem.

Uma vez que a identidade do dispositivo é gerida pelo back-end de IoT, tem de mapear uma identidade entre o back-end de IoT e o IAM para que o dispositivo periférico possa aceder aosGoogle Cloud recursos.

Se estiver a gerir um grande conjunto de dispositivos, o limite no número de contas de serviço para cada Google Cloud projeto torna inviável ter um mapeamento direto individual entre o dispositivo e a conta de serviço.

Em alternativa, crie contas de serviço associadas aos recursos na nuvem aos quais a sua solução de IoT precisa de aceder, conforme descrito no artigo criar contas de serviço de finalidade única. Por exemplo, crie uma conta de serviço exclusiva para cada um dos seguintes exemplos de utilização:

  • A transferir pacotes de atualização de software
  • Carregar ficheiros multimédia grandes
  • Carregar dados a partir de uma stream de latência

Para implementar o privilégio mínimo, certifique-se de que cada conta de serviço tem apenas direitos de acesso suficientes para suportar o respetivo exemplo de utilização. Por exemplo, para uma conta de serviço usada para transferir pacotes de software, conceda apenas acesso de leitura ao contentor do Cloud Storage.

Distribua tokens de acesso aos dispositivos de forma segura

Normalmente, os seus dispositivos periféricos comunicam com a sua plataforma de IdC através do MQTT. No entanto, para exemplos de utilização específicos, os seus dispositivos podem exigir acesso direto a Google Cloud recursos. Por exemplo, considere o seguinte:

  • Para transferir conteúdo, um dispositivo periférico requer acesso de leitura a um contentor do Cloud Storage apenas durante o processo de transferência.
  • Para carregar dados para um contentor do Cloud Storage, um dispositivo periférico requer acesso de escrita ao contentor.

Para estes exemplos de utilização, use a federação de identidade da carga de trabalho, onde o acesso aos recursos é concedido através de tokens de acesso. Google Cloud A federação de identidade da carga de trabalho elimina a necessidade de aprovisionar credenciais específicas da nuvem nos dispositivos periféricos, e a distribuição do acesso é feita dinamicamente com base na procura.

Para distribuir tokens de acesso para recursos na nuvem aos seus dispositivos, configure a federação de identidades de cargas de trabalho entre o seu fornecedor de identidade de dispositivos e o Google Cloud. Para suportar a federação de identidade de carga de trabalho, certifique-se de que o seu back-end de IoT cumpre os requisitos da federação de identidade de carga de trabalho e segue as práticas recomendadas de segurança que correspondem aos seus exemplos de utilização.

Para aceder a Google Cloud recursos através da federação de identidades de cargas de trabalho, os seus dispositivos periféricos têm de implementar o fluxo de trabalho de troca de tokens OAuth 2.0, que envolve os seguintes passos:

  • O dispositivo chama o Security Token Service e fornece as suas próprias credenciais do dispositivo.
  • O serviço de tokens de segurança valida a identidade do dispositivo periférico através da validação das credenciais que o dispositivo periférico forneceu com o fornecedor de identidade do dispositivo.
  • Se a validação de identidade for bem-sucedida, o serviço de tokens de segurança devolve um token de acesso ao dispositivo periférico.
  • O dispositivo periférico usa esse token para se fazer passar pela conta de serviço de finalidade única e obtém um token de acesso OAuth 2.0 de curta duração.
  • O dispositivo usa a chave de acesso OAuth 2.0 de curta duração para fazer a autenticação com as APIs Google Cloud e aceder aos recursos da nuvem necessários.

Para restringir o acesso do token de acesso de curta duração a contentores e objetos específicos no Cloud Storage, use Limites de acesso de credenciais. Os limites de acesso às credenciais permitem limitar o acesso da credencial de curta duração e minimizar o número de recursos expostos nos contentores do Cloud Storage quando um token de acesso é comprometido.

A federação de identidade da carga de trabalho é uma forma escalável de distribuir o acesso à nuvem de forma segura para dispositivos periféricos. Para mais informações sobre a autenticação, consulte o artigo Autenticação na Google.

Monitorize e audite o acesso aos recursos na nuvem

Ative os registos de auditoria do Google Cloud para criar entradas de registo quando os seus dispositivos periféricos acedem a recursos na nuvem através de pedidos de API autenticados. Os registos de auditoria da nuvem permitem-lhe monitorizar ações críticas realizadas pelos seus dispositivos periféricos no Google Cloud. Além disso, os registos de auditoria do Cloud criam os rastreios de auditoria e os registos de que precisa para investigar quaisquer problemas. Para mais informações, consulte o artigo Representar uma conta de serviço para aceder Google Cloud.

O que se segue?

Colaboradores

Autores:

  • Charlie Wang | Arquiteto de soluções na nuvem
  • Marco Ferrari | Arquiteto de soluções na nuvem