Práticas recomendadas de segurança no AWS IoT Core
Esta seção contém informações sobre as melhores práticas de segurança para o AWS IoT Core. Para obter mais informações sobre regras de segurança para soluções de IoT industrial, consulte Dez regras de ouro de segurança para soluções de IoT industrial
Proteger conexões MQTT no AWS IoT
O AWS IoT Core
O impacto e a gravidade de descartar conexões MQTT em sua frota de dispositivos dependem de vários fatores. Isso inclui:
-
O caso de uso (por exemplo, os dados que os dispositivos enviam para a AWS IoT, a quantidade de dados e a frequência em que os dados são enviados).
-
A configuração do cliente MQTT (por exemplo, as configurações de reconexão automática, as temporizações de retirada associadas e o uso de Sessões MQTT persistentes).
-
Restrições de recursos de dispositivo.
-
A causa raiz das desconexões, sua agressividade e persistência.
Para evitar conflitos de ID de cliente e os possíveis impactos negativos, certifique-se de que cada dispositivo ou aplicativo móvel tenha um política do AWS IoT ou do IAM que restrinja os IDs de cliente que têm permissão para uso em conexões MQTT ao agente de mensagens do AWS IoT. Por exemplo, você pode usar uma política do IAM para impedir que um dispositivo feche involuntariamente a conexão de outro dispositivo usando um ID de cliente que já esteja em uso. Para obter mais informações, consulte Autorização.
Todos os dispositivos em sua frota devem ter credenciais com privilégios que autorizem apenas ações planejadas, incluindo, mas não se limitando a, ações MQTT do AWS IoT, como publicar mensagens ou assinar tópicos com escopo e contexto específicos. As políticas de permissão específicas podem variar para seus casos de uso. Identifique as políticas de permissão que melhor atendem aos seus requisitos de negócios e de segurança.
Para simplificar a criação e o gerenciamento de políticas de permissão, é possível usar AWS IoT CoreVariáveis de política do e Variáveis de políticas do IAM. As variáveis de políticas podem ser colocadas em uma política e, quando a política for avaliada, as variáveis serão substituídas por valores fornecidos na solicitação do dispositivo. Usando variáveis de políticas, você pode criar uma única política para conceder permissões a vários dispositivos. Você pode identificar as variáveis de políticas relevantes para seu caso de uso com base na configuração de sua conta do AWS IoT, no mecanismo de autenticação e no protocolo de rede usado na conexão ao agente de mensagens do AWS IoT. No entanto, para escrever as melhores políticas de permissão, você precisa considerar informações específicas sobre seu caso de uso e o modelo de ameaça
Por exemplo, se você tiver registrado seus dispositivos no registro do AWS IoT, poderá usar variáveis de políticas de objetos em políticas do AWS IoT para conceder ou negar permissões com base em propriedades de objetos, como nomes, tipos e valores de atributos. O nome do objeto é obtido do ID do cliente na mensagem de conexão MQTT enviada quando um objeto se conecta ao AWS IoT. As variáveis de política de objetos são substituídas quando um objeto se conecta ao AWS IoT por meio de MQTT usando a autenticação mútua do TLS ou o MQTT por meio do protocolo WebSocket usando Identidades do Amazon Cognito autenticadas. Você pode usar a API AttachThingPrincipal para anexar certificados e identidades do Amazon Cognito autenticadas a um objeto. iot:Connection.Thing.ThingName é uma variável de política de objetos útil para impor restrições de ID de cliente. A política de exemplo do AWS IoT a seguir exige que um nome de objeto registrado seja usado como o ID de cliente para conexões MQTT com o agente de mensagens do AWS IoT:
Para identificar conflitos de ID de cliente em andamento, você pode ativar e usar o CloudWatch Logs para AWS IoT. Para cada conexão MQTT da qual o agente de mensagens do AWS IoT se desconecta devido a conflitos de ID de cliente, um registro em log semelhante ao seguinte é gerado:
{ "timestamp": "2019-04-28 22:05:30.105", "logLevel": "ERROR", "traceId": "02a04a93-0b3a-b608-a27c-1ae8ebdb032a", "accountId": "123456789012", "status": "Failure", "eventType": "Disconnect", "protocol": "MQTT", "clientId": "clientId01", "principalId": "1670fcf6de55adc1930169142405c4a2493d9eb5487127cd0091ca0193a3d3f6", "sourceIp": "203.0.113.1", "sourcePort": 21335, "reason": "DUPLICATE_CLIENT_ID", "details": "A new connection was established with the same client ID" }
Você pode usar um filtro do CloudWatch Logs, como o {$.reason= "DUPLICATE_CLIENT_ID" }, para pesquisar instâncias de conflitos de IDs de cliente ou configurar os filtros de métricas do CloudWatch e os alarmes correspondentes do CloudWatch para monitoramento contínuo e geração de relatórios.
Você pode usar o AWS IoT Device Defender
Você pode usar o AWS IoT Device Advisor para validar se seus dispositivos podem se conectar de forma confiável ao AWS IoT Core e seguir as práticas recomendadas de segurança.
Consulte também
Manter o relógio do dispositivo sincronizado
É importante ter a hora exata no seu dispositivo. Os certificados X.509 têm data e hora de expiração. O relógio em seu dispositivo é usado para verificar se um certificado de servidor ainda é válido. Se você estiver criando dispositivos comerciais de IoT, lembre-se de que seus produtos podem ser armazenados por períodos prolongados antes de serem vendidos. Os relógios em tempo real podem ter desvios durante esse período, e as baterias podem ser descarregadas, portanto, definir a hora na definição de fábrica não é suficiente.
Para a maioria dos sistemas, isso indica que o software do dispositivo deve incluir um cliente de protocolo de tempo de rede (NTP). O dispositivo deve aguardar até ser sincronizado com um servidor NTP antes de tentar se conectar ao AWS IoT Core. Se isso não for possível, o sistema deve fornecer uma maneira de um usuário definir a hora do dispositivo para que as conexões subsequentes tenham êxito.
Depois que o dispositivo for sincronizado com um servidor NTP, ele poderá abrir uma conexão com o AWS IoT Core. A inclinação do relógio que é permitida depende do que você está tentando fazer com a conexão.
Validar o certificado do servidor
A primeiro objeto que um dispositivo faz para interagir com o AWS IoT é abrir uma conexão segura. Ao conectar o dispositivo à AWS IoT, verifique se está falando com a AWS IoT e não com outro servidor se passando pela AWS IoT. Cada um dos servidores do AWS IoT é provisionado com um certificado emitido para o domínio iot.amazonaws.com. Este certificado foi emitido para o AWS IoT por uma autoridade de certificação confiável que verificou nossa identidade e propriedade do domínio.
Uma das primeiras objetos que o AWS IoT Core faz quando um dispositivo se conecta é enviar um certificado do servidor ao dispositivo. Os dispositivos podem verificar se eles esperavam se conectar ao iot.amazonaws.com e se o servidor no destino dessa conexão possui um certificado de uma autoridade confiável para esse domínio.
Os certificados TLS estão no formato X.509 e incluem uma grande variedade de informações, como nome, localização, nome de domínio e um período de validade da organização. O período de validade é especificado como um par de valores de tempo chamados notBefore e notAfter. Serviços como o AWS IoT Core usam períodos de validade limitados (por exemplo, um ano) para seus certificados de servidor e começam a atender outros novos antes de os antigos expirarem.
Usar uma identidade única por dispositivo
Use uma única identidade por cliente. Os dispositivos geralmente usam certificados de cliente X.509. Aplicações da Web e móveis usam a identidade do Amazon Cognito. Isso permite aplicar permissões refinadas aos seus dispositivos.
Por exemplo, você tem um aplicativo que consiste em um dispositivo móvel que recebe atualizações de status de dois objetos domésticos inteligentes diferentes: uma lâmpada e um termostato. A lâmpada envia o status do nível de bateria e um termostato envia mensagens que relatam a temperatura.
AWS IoTA autentica dispositivos individualmente e trata cada conexão individualmente. Você pode aplicar controles de acesso refinados usando políticas de autorização. É possível definir uma política para o termostato que permite que ele publique em um espaço de tópico. É possível definir uma política separada para a lâmpada que permite que ela publique em um espaço de tópico diferente. Por fim, é possível definir uma política para o aplicativo móvel que só permite que ele se conecte e se inscreva nos tópicos para o termostato e a lâmpada para receber mensagens desses dispositivos.
Aplique o princípio do privilégio mínimo e diminua o escopo das permissões por dispositivo o máximo possível. Todos os dispositivos ou usuários devem ter uma política de AWS IoT na AWS IoT que permita somente conectar-se a um ID de cliente conhecido, publicar e inscrever-se em um conjunto de tópicos identificado e fixo.
Use uma segunda Região da AWS como backup
Considere armazenar uma cópia dos seus dados em uma segunda Região da AWS como backup. Observe que a solução AWS chamada Recuperação de desastres para AWS IoT
Usar provisionamento just-in-time
Criar e provisionar manualmente cada dispositivo pode ser demorado. O AWS IoT fornece uma forma de definir um modelo para provisionar dispositivos quando eles se conectam pela primeira vez ao AWS IoT. Para obter mais informações, consulte Provisionamento just-in-time.
Permissões para executar testes do AWS IoT Device Advisor
O modelo de política a seguir mostra as permissões mínimas e a entidade do IAM necessárias para executar os casos de teste do AWS IoT Device Advisor. Você precisará substituir your-device-role-arn pelo nome do recurso da Amazon (ARN) do perfil do dispositivo que você criou conforme os pré-requisitos.
Prevenção do problema do substituto confuso entre serviços para o Device Advisor
“Confused deputy” é um problema de segurança no qual uma entidade sem permissão para executar uma ação pode coagir uma entidade mais privilegiada a executá-la. Na AWS, a personificação entre serviços pode resultar no problema do ‘confused deputy’. A personificação entre serviços pode ocorrer quando um serviço (o serviço de chamada) chama outro serviço (o serviço chamado). O serviço de chamada pode ser manipulado de modo a usar suas permissões para atuar nos recursos de outro cliente de uma forma na qual ele não deveria ter permissão para acessar. Para evitar isso, a AWS fornece ferramentas que ajudam você a proteger seus dados para todos os serviços com entidades principais de serviço que receberam acesso aos recursos em sua conta.
Recomendamos o uso das chaves de contexto de condição global aws:SourceArn e aws:SourceAccount em políticas de recursos para limitar as permissões que o Device Advisor concede a outro serviço para o recurso. Se você utilizar ambas as chaves de contexto de condição global, o valor aws:SourceAccount e a conta aws:SourceArn no valor deverão utilizar o mesmo ID de conta quando utilizados na mesma instrução de política.
O valor de aws:SourceArn deve ser o ARN do seu recurso de definição de suíte. O recurso de definição da suíte se refere à suíte de testes criada com o Device Advisor.
A maneira mais eficaz de se proteger do problema ‘confused deputy’ é usar a chave de contexto de condição global aws:SourceArn com o ARN completo do recurso. Se você não souber o ARN completo do recurso ou se estiver especificando vários recursos, use a chave de condição de contexto global aws:SourceArn com curingas (*) para as partes desconhecidas do ARN. Por exemplo, ., arn:aws:iotdeviceadvisor:*: account-id:suitedefinition/*
O exemplo a seguir mostra como é possível usar as chaves de contexto de condição globais aws:SourceArn e aws:SourceAccount no Device Advisor para evitar o problema de substituto confuso.
