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

Last reviewed 2024-05-31 UTC

Neste documento, você encontra as práticas recomendadas de segurança para gerenciar e executar um back-end de Internet das Coisas (IoT) no Google Cloud. Em uma solução de IoT, um back-end de IoT conecta dispositivos de borda a outros recursos. Este documento se concentra nos seguintes back-ends de IoT: agente do transporte telemétrico de mensagens em fila (MQTT, na sigla em inglês) e na plataforma de IoT.

Este documento faz parte de uma série de documentos que fornecem informações sobre arquiteturas de IoT no Google Cloud e como migrar do IoT Core. Os outros documentos desta série incluem:

Neste documento, apresentamos as práticas recomendadas para provisionar e gerenciar credenciais de dispositivos, autenticar e acessar dispositivos de borda de controle e permitir que dispositivos de borda de IoT acessem recursos do Google Cloud.

Arquitetura da Internet das Coisas (IoT na sigla em inglês)

Uma arquitetura de IoT inclui serviços que permitem provisionar e gerenciar credenciais de dispositivos, autenticar e acessar dispositivos de borda de controle e permitem que dispositivos de borda acessem recursos do Google Cloud. Neste documento, discutimos duas arquiteturas de back-end de IoT: uma usando o agente do MQTT e a outra usando uma plataforma de IoT. As principais diferenças de segurança entre esses dois back-ends são a identidade e o gerenciamento de dispositivos. As plataformas de IoT fornecem esses recursos como parte do sistema, enquanto os agentes do MQTT exigem que você forneça esses recursos.

O diagrama a seguir descreve a arquitetura de IoT.

Arquitetura de back-end de IoT.

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

  1. Provisionamento de certificado, que é o processo que você precisa concluir para preparar um dispositivo de borda para configuração.

  2. Autenticação e autorização, que incluem o esquema de autenticação que o dispositivo de borda e o agente do MQTT ou a plataforma de IoT usam para fazer a autenticação uns com os outros.

  3. Conexões entre dispositivos de borda e serviços do Google Cloud, que são tarefas que o dispositivo de borda conclui para se conectar a recursos da nuvem e fazer upload ou download de dados.

Este documento se concentra principalmente nas práticas recomendadas de segurança para provisionamento e autenticação.

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

  • Um dispositivo de borda (como um dispositivo médico) que você implanta nas bordas do ambiente e que está geograficamente próximo aos dados que você quer processar. Os dispositivos de borda se conectam bidirecionalmente ao seu back-end de IoT, o que significa que eles podem enviar mensagens para e receber mensagens do back-end de IoT.
  • Um back-end de IoT que pode ser um agente do MQTT ou uma plataforma de IoT.
    • Um agente do MQTT oferece uma interface segura para que dispositivos de borda se conectem usando o protocolo do MQTT. Os agentes do MQTT não têm recursos para identidade e gerenciamento de dispositivos e dependem de sistemas externos para fornecê-los.
    • Uma plataforma de IoT é um aplicativo em nuvem com que dispositivos de borda se conectam e se comunicam. As plataformas de IoT oferecem uma interface segura para que os dispositivos de borda se conectem usando o protocolo MQTT. Cada plataforma de IoT tem uma implementação de segurança própria que determina como ela autentica e autoriza dispositivos de borda e gerencia identidades de dispositivo.
  • Um repositório de certificados central que hospeda os certificados de todos os dispositivos de borda.
  • Recursos do Cloud que os dispositivos de borda precisam acessar.

Como provisionar um dispositivo de borda

Antes que um dispositivo de borda possa se conectar às cargas de trabalho de back-end, você precisa provisionar um certificado para o dispositivo de borda. Há dois cenários principais que decidem como você provisiona o certificado:

  • Se a solução for baseada em dispositivos comerciais e genéricos, você terá controle total sobre o processo de provisionamento após a compra do dispositivo.

  • Se você usa dispositivos personalizados, o processo de provisionamento inicial ocorre durante a fabricação dos dispositivos e é necessário integrar o processo de provisionamento aos fornecedores e fabricantes.

Em ambos os cenários, você precisa criar certificados de dispositivo com uma cadeia de confiança vinculada a uma autoridade certificadora raiz (CA). Esses certificados autenticam a identidade do dispositivo e ajudam a garantir que as atualizações e modificações feitas no dispositivo sejam feitas por agentes confiáveis. Use uma AC, como o Certificate Authority Service, para concluir as seguintes tarefas:

Para provisionar um certificado de dispositivo, conclua as seguintes tarefas:

  1. Gerar o par de chaves públicas/privadas usando uma solução de segurança baseada em hardware que funcione com seu dispositivo, como um elemento de segurança (SE, na sigla em inglês), ou módulo de segurança de hardware (HSM, na sigla em inglês). Por padrão, o SE ou o HSM armazena as chaves privadas localmente, e as chaves privadas nunca são expostas externamente. Se você não estiver usando uma solução de segurança baseada em hardware para gerar um par de chaves públicas/privadas, use a CA para gerar chaves. Para mais informações, consulte Como usar uma chave gerada automaticamente.

  2. Assinar e gerar um certificado de dispositivo. Depois de gerar o par de chaves públicas/privadas, faça o download da chave pública, crie uma solicitação de assinatura de certificado (CSR) e envie a CSR à CA para assinatura. A CA gera um certificado de dispositivo vinculado à CA raiz. Para mais informações, consulte Como usar uma CSR. Ao usar chaves geradas automaticamente, você pode solicitar um certificado de dispositivo diretamente da CA.

  3. Instale o certificado de dispositivo assinado no dispositivo de borda e envie-o para um repositório de certificados central, como o Secret Manager.

Para mais informações, consulte Como implantar uma infraestrutura de chave pública segura e confiável com o serviço de CA do Google Cloud (PDF).

Para informações sobre outras práticas recomendadas de provisionamento, consulte Práticas recomendadas para provisionar e configurar automaticamente sistemas e servidores bare metal.

Três tipos de certificados são usados para proteger uma solução de IoT:

  • O certificado de CA raiz fornece a raiz da cadeia de confiança de todos os outros certificados do sistema. As cargas de trabalho de back-end usam o certificado raiz para validar os certificados do cliente, e os dispositivos de borda usam o certificado raiz para validar o certificado do servidor. Distribua o certificado raiz para o back-end de IoT e para os dispositivos de borda.

  • Os certificados do servidor são usados para proteger os endpoints expostos pelo back-end de IoT. Você tem certificados de servidor para os diferentes algoritmos de criptografia compatíveis com os endpoints. Os certificados do servidor estão vinculados à CA raiz. Um gerenciador de secrets gerencia e armazena as partes privada e pública dos certificados do servidor. Você deve configurar o back-end de IoT com os certificados do servidor e as chaves privadas correspondentes.

  • Os certificados do cliente são usados para identificar dispositivos de borda. Cada dispositivo de borda tem pelo menos um certificado do cliente, o que significa que o número de certificados aumenta com o número de dispositivos de borda no seu ambiente. Os certificados do cliente estão vinculados à CA raiz. É preciso distribuir certificados de cliente para seus dispositivos de borda e para o back-end de IoT.

Processo para gerar um certificado de dispositivo usando um HSM ou SE

O diagrama a seguir mostra como um certificado do dispositivo é provisionado ao usar um HSM ou SE.

Processo para gerar um certificado de dispositivo.

Neste diagrama, as seguintes etapas ocorrem:

  1. O dispositivo de borda gera o par de chaves públicas no hardware.
  2. Você faz o download da chave pública e cria a solicitação de assinatura de certificado (CSR, na sigla em inglês).
  3. Você envia a CSR à CA para solicitar um certificado.
  4. A CA realiza as seguintes ações:
    1. Assina o certificado.
    2. Retorna o certificado do dispositivo para o provisionador.
  5. O provisionador conclui as seguintes ações:
    1. Envia o certificado para o dispositivo de borda.
    2. Armazena o certificado no repositório central.
  6. O dispositivo de borda armazena o certificado em um local seguro.

Processo para gerar um certificado de dispositivo usando a CA

O diagrama a seguir mostra como um certificado do dispositivo é provisionado ao usar uma CA.

Processo para gerar um certificado de dispositivo.

Neste diagrama, as seguintes etapas ocorrem:

  1. Você gera uma CSR e a envia à CA para solicitar um certificado.
  2. A CA realiza as seguintes ações:
    1. Gera um par de chaves públicas e assina a chave pública.
    2. Retorna o certificado do dispositivo e a chave privada para o provisionador.
  3. Você realize as seguintes ações:
    1. Envia o certificado e a chave privada para o dispositivo de borda.
    2. Armazena o certificado e a chave privada no repositório central de certificados.
  4. O dispositivo de borda armazena o certificado em um local seguro.

Práticas recomendadas para identidade de dispositivo

Esta seção descreve as práticas recomendadas para identidades de dispositivo.

Usar um provedor de identidade com agentes do MQTT

Os agentes do MQTT autenticam dispositivos de borda usando credenciais de dispositivo fornecidas por plug-ins, bancos de dados e arquivos. Para gerenciar as identidades do seu dispositivo de maneira sistemática e escalonável, use um provedor de identidade (IdP, na sigla em inglês). O IdP gerencia as identidades e credenciais de todos os dispositivos e atua como fonte principal de verdade das identidades dos dispositivos.

Para manter a identidade do dispositivo atualizada no agente do MQTT, implemente uma camada de integração específica do sistema. Para mais informações sobre o gerenciamento de credenciais do dispositivo, consulte Como provisionar um dispositivo de borda.

Usar as identidades digitais da plataforma de IoT como fonte da verdade

A plataforma de IoT tem recursos de segurança que gerenciam as identidades e as credenciais do dispositivo, além de autenticar e autorizar dispositivos que tentam acessar a plataforma. Esses recursos de segurança garantem que apenas dispositivos autorizados tenham permissão para acessar a plataforma de IoT e ajudam a garantir a integridade dos dados.

Verifique se as identidades dos dispositivos gerenciadas pela plataforma de IoT representam a principal fonte de verdade de todos os dispositivos que ela gerencia. Outros componentes em uma solução de IoT que precisam de informações de identidade do dispositivo precisam depender do sistema de segurança da plataforma de IoT. A plataforma IoT concede direitos de acesso a dispositivos e propaga quaisquer alterações de segurança na solução de IoT.

Práticas recomendadas para conectividade de rede

A segurança da conectividade de rede é importante pelos seguintes motivos:

  • As redes seguras ajudam a garantir que um dispositivo se conecte ao back-end certo. Por exemplo, uma rede segura pode impedir o spoofing de DNS, que é um ataque que tenta desviar os dispositivos para se conectar a um back-end não autorizado controlado por invasores.
  • Redes seguras ajudam a garantir que terceiros não possam ler seu tráfego de dados. Por exemplo, uma rede segura pode impedir um ataque indireto, em que os invasores leem o tráfego entre seu dispositivo e o back-end.

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

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

Para saber como usar o TLS, consulte Arquitetura do agente do MQTT independente no Google Cloud e Arquitetura de produto da plataforma IoT no Google Cloud.

Práticas recomendadas para gerenciamento de certificados de agentes do MQTT

Nesta seção, você verá as práticas recomendadas para gerenciar certificados ao usar agentes do MQTT.

Armazenar certificados de forma centralizada

Armazene e gerencie certificados do servidor e do dispositivo em um local central. Especificamente, verifique se você tem os seguintes controles:

  • Um inventário de todos os seus dispositivos e os certificados deles e os endpoints do servidor e os certificados deles.
  • Informações adicionais sobre os certificados, como validade.
  • A capacidade de adicionar e remover certificados para dispositivos para que eles possam se conectar usando novos certificados.
  • Direitos de acesso ao seu repositório 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 armazenamento e gerenciamento de secrets, como o Secret Manager ou o HashiCorp Vault. O Secret Manager permite escolher a versão, atualizar e invalidar as credenciais do dispositivo e gerenciar políticas de acesso às credenciais.

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

Proteger certificados em dispositivos de borda

Para armazenar certificados e chaves nos dispositivos de borda, use um ambiente de execução confiável ou um repositório de certificados local para proteger a credencial e bloquear acessos não autorizados. Se você precisar armazenar material secreto nos seus dispositivos, criptografe-o usando técnicas como a criptografia de flash e o armazene em elementos à prova de adulteração para evitar a extração de dados não autorizada.

Sincronizar o repositório de certificados central com o repositório de certificados do agente do MQTT

Os agentes do MQTT precisam acessar certificados do cliente para autenticação baseada em certificado. Portanto, é necessário sincronizar os armazenamentos de certificados dos agentes do MQTT com o repositório de certificados central. Verifique se as alterações no armazenamento de certificados central, como certificados de adição, atualização e exclusão, estão sincronizadas com o repositório de certificados do agente do MQTT. Os agentes do MQTT usam repositórios de certificados, como MySQL, PostgresDB e Java Key Store. Dependendo do repositório de certificados que seu agente do MQTT usa, verifique se os seguintes processos existem:

  • Um processo que monitora alterações no armazenamento de certificados central e notifica o processo de sincronização.
  • Um processo que pega alterações no armazenamento de certificados central e sincroniza as alterações no repositório de certificados central com o armazenamento de certificados usado pelo agente do MQTT.

Ao usar o Secret Manager como repositório de certificados, é possível usar notificações de eventos como o processo de monitoramento. Você pode implementar o processo de sincronização como um listener das notificações de eventos.

Distribuir certificados para dispositivos de borda com segurança

Ao usar agentes do MQTT, distribua o certificado raiz e os certificados do cliente para seus dispositivos de borda. Ao distribuir certificados, você precisa proteger seus canais de comunicação para que o tráfego não seja interceptado.

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

  • Um caminho direto do back-end de IoT para os dispositivos de borda nos canais de comunicação existentes.
  • Um caminho indireto em que os dispositivos de borda solicitam e fazem o download dos certificados.

Durante a distribuição do certificado, você precisará dos seguintes componentes:

  • Um armazenamento de certificados em que os certificados são gerenciados centralmente.
  • Um coordenador de distribuição, que envia os certificados e acompanha o processo de distribuição de cada dispositivo de borda.
  • Um gerenciador de atualização no dispositivo de borda que recebe ou faz o download dos certificados e os armazena no dispositivo.

Distribua certificados durante os processos de provisionamento para dispositivos de borda e quando você precisar fazer a rotação de certificados.

Durante o processo de provisionamento, verifique se o provisionador tem acesso direto a dispositivos de borda em canais criptografados, como SSH, e usa ferramentas como o SCP. Como os dispositivos não estão em operação, é possível enviar certificados diretamente para os dispositivos de borda.

Ao fazer a rotação de certificados, use o agente do MQTT como o canal de comunicação entre o coordenador de distribuição e os dispositivos de borda. Use outros canais para fazer o download dos certificados no dispositivo. Para minimizar a interrupção dos dispositivos de borda em operação, use um caminho de distribuição de certificado indireto. O processo consiste nas seguintes etapas lógicas:

  1. O coordenador de distribuição adquire as credenciais de acesso no repositório de certificados.
  2. O coordenador de distribuição envia as credenciais de acesso ao certificado para os dispositivos de borda com informações adicionais, como o URL de download.
  3. O gerenciador de atualização no dispositivo recebe as credenciais de acesso, armazena temporariamente as informações e confirma o recebimento.
  4. O gerenciador de atualizações coordena o download do certificado quando o dispositivo não está ativo. O gerenciador de atualização usa as credenciais de acesso para fazer o download dos certificados pelo armazenamento de credenciais.
  5. Após o download dos certificados, o gerenciador de atualização continua com o processo de rotação de certificado, que é descrito na seção de rotação de certificado.

Ao usar o Secret Manager como o repositório central de certificados, é possível gerar tokens de acesso de curta duração para conceder e restringir o acesso a certificados. Para ver mais informações, consulte Distribuir tokens de acesso para dispositivos de forma segura.

Para ajudar a evitar que os certificados sejam expostos durante o transporte, criptografe a conexão entre os dispositivos de borda e o agente do MQTT. Para mais informações, consulte Práticas recomendadas de conectividade de rede.

Rotacionar certificados automaticamente

Para limitar os danos que um certificado exposto pode causar, gere certificados com um período válido finito e faça a rotação dos certificados antes que eles expirem. Para implantações de IoT em grande escala, implemente um procedimento de rotação automática de certificados para atualizar seus dispositivos de maneira consistente com novos certificados antes que os antigos expirem. Dispositivos implantados sem certificados válidos podem parar de funcionar, o que pode custar caro para corrigir e afetar negativamente a funcionalidade geral da solução de IoT.

Seus dispositivos de borda precisam se conectar bidirecionalmente com seu agente do MQTT para garantir que possam enviar mensagens para o agente do MQTT e receber mensagens do agente do MQTT.

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

  • Um processo de monitoramento que verifica periodicamente seu inventário de certificados e procura certificados que estão prestes a expirar. O processo de monitoramento aciona a rotação para os certificados prestes a expirar.
  • Um processo de rotação que inicializa e supervisiona a rotação de certificados.
  • Um gerenciador de rotação de certificados de dispositivo no dispositivo de borda que se comunica com o agente do MQTT e executa etapas de rotação de certificado no dispositivo.

Para fazer a rotação de certificados, a solução de IoT conclui as seguintes etapas:

  1. O processo de rotação envia uma mensagem de inicialização ao dispositivo de borda para iniciar a rotação do certificado.
  2. O gerenciador de rotação de certificados de dispositivo confirma a mensagem de inicialização enviando uma resposta de volta ao job de rotação.
  3. O processo de rotação solicita um novo certificado da CA. Essa solicitação é semelhante à solicitação de provisionamento de certificados, mas as chaves e o CSR são enviados como mensagens do agente do MQTT.
  4. Depois de receber o novo certificado da CA, o job de rotação distribui o certificado para o repositório central de certificados e para o dispositivo de borda. Ele também sincroniza o certificado com o repositório de certificados do agente do MQTT.
  5. O gerenciador de rotação de certificados do dispositivo armazena o novo certificado e inicializa uma nova conexão com o agente do MQTT usando o novo certificado.
  6. Depois que a nova conexão é estabelecida, o gerenciador de rotação de certificados do dispositivo envia uma mensagem de conclusão ao agente do MQTT.
  7. Depois de receber a mensagem de conclusão, o processo de rotação invalida o certificado antigo no repositório central.

Para ajudar a proteger os certificados que estão sendo enviados durante o processo de rotação, use tópicos do MQTT dedicados para rotação de certificados. Limite o acesso a esses tópicos apenas para o job de rotação e o dispositivo de borda.

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

Para ver mais informações sobre a rotação de secrets usando o Secret Manager, consulte Rotação de secrets.

Práticas recomendadas para gerenciamento de certificados em plataformas de IoT

Se você estiver usando uma plataforma de IoT, utilize os mecanismos de atualização de certificado e de distribuição fornecidos por ela. Para fins de backup, é possível exportar regularmente as credenciais da sua plataforma de IoT para um armazenamento de secrets secundário, como o Secret Manager.

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

Durante o processo de autenticação mútua, as cargas de trabalho de back-end verificam a identidade dos dispositivos de borda, e os dispositivos de borda verificam a identidade das cargas de trabalho de back-end. Depois que as cargas de trabalho de back-end confirmarem a identidade do dispositivo de borda, elas autorizam o dispositivo a acessar os recursos.

Veja nas seções a seguir as práticas recomendadas para métodos de autenticação ao usar agentes do MQTT.

Escolher o método de autenticação para agentes do MQTT

Diferentes back-ends de IoT são compatíveis com diferentes métodos de autenticação. Os métodos mais usados são estes:

  • Autenticação por nome de usuário e senha, em que o dispositivo de borda apresenta o nome de usuário e a senha para verificar a identidade.
  • Autenticação baseada em token, em que tokens de segurança criptografados são usados para verificar a identidade do dispositivo de borda.
  • Esquemas de autenticação personalizados, em que você implementa um mecanismo personalizado para verificar a identidade do dispositivo de borda.

Como parte do padrão do MQTT, os agentes do MQTT são compatíveis com autenticação por nome de usuário e senha como padrão para pacotes MQTT CONNECT.

O pacote MQTT CONNECT também contém um campo Client Identifier que pode ser usado para identificar exclusivamente o cliente para o agente do MQTT. Os dispositivos de borda enviam o pacote MQTT CONNECT para o agente do MQTT quando estabelecem uma conexão.

Além dos campos de nome de usuário, senha e identificador de cliente no pacote MQTT CONNECT, o MQTT 5.0 trabalha com a autenticação aprimorada, que permite criar fluxos de autenticação de resposta ao desafio. O MQTT 5.0 permite várias trocas de pacote AUTH entre o dispositivo de borda e o agente do MQTT.

Usar armazenamentos de senhas com autenticação por nome de usuário e senha

Para a autenticação por nome de usuário e senha, configure o agente do MQTT para usar um armazenamento de senhas. O armazenamento de senhas fornece um local centralizado para gerenciar senhas para todos os dispositivos de borda que se conectam ao agente do MQTT. Por padrão, os campos de nome de usuário, senha e identificador de cliente são opcionais na especificação do MQTT. Portanto, projete seu mecanismo de autenticação para verificar se os campos de nome de usuário, senha e identificador de cliente estão presentes no pacote MQTT CONNECT.

Verifique se as senhas estão criptografadas em repouso e em trânsito, da seguinte maneira:

Considerar a autenticação baseada em token

Com a autenticação baseada em token, os dispositivos de borda enviam um token para o agente do MQTT para autenticação. Os dispositivos podem gerar o token por conta própria ou recebê-lo de outros serviços de autenticação. Em comparação com as senhas, os tokens são de curta duração: os tokens são válidos apenas por um período com uma data de validade explícita. Sempre verifique a expiração ao validar tokens.

Os JSON Web Tokens (JWT) são uma forma de implementar a autenticação baseada em token. Os dispositivos de borda podem gerar o JWT e fazer a autenticação com o agente do MQTT. O JWT é incorporado ao pacote MQTT CONNECT como o campo de senha.

As vantagens do JWT são as seguintes:

  • O JWT oferece opções no algoritmo de criptografia usado para assinar o token. O JWT funciona bem com dispositivos de borda restritos, em que é possível usar um algoritmo de criptografia que utiliza menos recursos, como ECC, para assinar o token.
  • Ao usar a criptografia de chave pública, a chave privada é usada somente no dispositivo de borda e nunca é compartilhada com terceiros. Uma chave privada ajuda a tornar esse método mais seguro do que a autenticação por nome de usuário e senha, em que as credenciais são enviadas pela conexão e exigem criptografia dos dados.

Considerar esquemas de autenticação personalizados

Alguns agentes do MQTT são compatíveis com diferentes mecanismos e protocolos de autenticação. Por exemplo, se o agente do MQTT oferecer suporte a esquemas de autenticação personalizados, será possível configurá-lo para:

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

Devido ao padrão de comunicação entre editores e assinantes do protocolo do MQTT, o controle de acesso ao dispositivo é definido usando tópicos do MQTT. Os tópicos do MQTT controlam como um dispositivo pode se comunicar com o back-end de IoT. Cada back-end de IoT tem implementações diferentes para controle de acesso e autorização. Portanto, consulte a documentação do back-end de IoT para ver opções de como configurar tópicos do MQTT.

Usar contas de serviço de propósito único para acessar recursos do Google Cloud

O acesso aos recursos do Google Cloud é gerenciado pelas políticas de permissão do IAM que vinculam a permissão de acesso a recursos com um conjunto de principais. Os principais comuns são contas de usuário, contas de serviço e grupos. As contas de serviço costumam ser usadas por um aplicativo ou carga de trabalho de computação para fazer chamadas de API autorizadas para recursos de nuvem. As contas de serviço permitem que os dispositivos de borda da IoT acessem recursos de nuvem.

Como a identidade do dispositivo é gerenciada pelo back-end de IoT, é necessário mapear uma identidade entre o back-end da IoT e o IAM para que o dispositivo de borda possa acessar os recursos do Google Cloud.

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

Em vez disso, crie contas de serviço vinculadas aos recursos de nuvem que sua solução de IoT precisa acessar, conforme descrito em Como criar contas de serviço de propósito único. Por exemplo, crie uma conta de serviço exclusiva para cada um dos seguintes casos de uso:

  • Download de pacotes de atualização de software
  • Upload de arquivos de mídia grandes
  • Ingestão de dados a partir de um stream de latência

Para implementar o privilégio mínimo, verifique se cada conta de serviço tem direitos de acesso suficientes para atender ao caso de uso. Por exemplo, para uma conta de serviço usada para fazer o download de pacotes de software, conceda acesso de leitura apenas ao bucket do Cloud Storage.

Distribuir tokens de acesso para os dispositivos de forma segura

Normalmente, os dispositivos de borda se comunicam com a plataforma de IoT usando o MQTT. No entanto, para casos de uso específicos, seus dispositivos podem exigir acesso direto aos recursos do Google Cloud. Por exemplo, considere o seguinte:

  • Para fazer o download de conteúdo, um dispositivo de borda precisa de acesso somente leitura a um bucket do Cloud Storage apenas durante o processo de download.
  • Para fazer upload de dados em um bucket do Cloud Storage, um dispositivo de borda requer acesso de gravação no bucket.

Para esses casos de uso, use a federação de identidade da carga de trabalho, em que o acesso aos recursos do Google Cloud é concedido usando tokens de acesso. A federação de identidade da carga de trabalho elimina a necessidade de provisionar credenciais específicas da nuvem nos dispositivos de borda, e a distribuição de acesso é feita dinamicamente com base na demanda.

Para distribuir tokens de acesso para recursos de nuvem aos seus dispositivos, configure a federação de identidade da carga de trabalho entre o provedor de identidade do dispositivo e o Google Cloud. Para dar suporte à federação de identidade da carga de trabalho, verifique se o back-end da IoT atende aos requisitos da federação de identidade da carga de trabalho e segue as práticas recomendadas de segurança que corresponderem aos seus casos de uso.

Para acessar os recursos do Google Cloud usando a federação de identidade da carga de trabalho, os dispositivos de borda precisam implementar o fluxo de trabalho do OAuth 2.0 Token Exchange, que envolve as seguintes etapas:

  • O dispositivo chama o serviço de token de segurança e fornece as próprias credenciais do dispositivo.
  • O Serviço de token de segurança verifica a identidade do dispositivo de borda validando as credenciais que o dispositivo de borda forneceu com o provedor de identidade do dispositivo.
  • Se a verificação de identidade for bem-sucedida, o Serviço de token de segurança retorna um token federado de volta para o dispositivo de borda.
  • O dispositivo de borda usa o token federado para representar a conta de serviço de propósito único e recebe um token de acesso do OAuth 2.0 de curta duração.
  • O dispositivo usa o token de acesso do OAuth 2.0 de curta duração para se autenticar com as APIs do Google Cloud e ter acesso aos recursos de nuvem necessários.

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

A federação de identidade da carga de trabalho é uma maneira escalonável de distribuir com segurança o acesso à nuvem a dispositivos de borda. Para mais informações sobre autenticação, consulte Autenticação no Google.

Monitorar e auditar o acesso aos recursos de nuvem

Ative os registros de auditoria do Cloud para criar entradas de registro quando os dispositivos de borda acessarem recursos de nuvem por meio de solicitações de API autenticadas. Os registros de auditoria do Cloud permitem monitorar ações essenciais realizadas pelos dispositivos de borda no Google Cloud. Além disso, os Registros de auditoria do Cloud criam os traces de auditoria e registros necessários para investigar problemas. Para mais informações, consulte Como representar uma conta de serviço para acessar o Google Cloud.

A seguir