As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Melhores práticas de segurança em AWS IoT Core
Esta seção contém informações sobre as melhores práticas de segurança para 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
Protegendo conexões MQTT em AWS IoT
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:
-
Seu caso de uso (por exemplo, os dados para os quais seus dispositivos enviam AWS IoT, a quantidade de dados e a frequência com 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 seus possíveis impactos negativos, certifique-se de que cada dispositivo ou aplicativo móvel tenha uma política AWS IoT ou IAM que restrinja quais IDs de cliente podem ser usadas para conexões MQTT com o agente de AWS IoT mensagens. 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 ter mais informações, consulte Autorização.
Todos os dispositivos da sua frota devem ter credenciais com privilégios que autorizem somente as ações pretendidas, que incluem (mas não se limitam a) ações do AWS IoT MQTT, 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 Core variáveis de política 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ítica relevantes para seu caso de uso com base na configuração AWS IoT da conta, no mecanismo de autenticação e no protocolo de rede usados na conexão com o agente de AWS IoT mensagens. 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ê registrou seus dispositivos no AWS IoT registro, você pode usar variáveis de política de coisas em AWS IoT políticas para conceder ou negar permissões com base em propriedades de coisas, como nomes de coisas, tipos de coisas e valores de atributos de coisas. O nome da coisa é obtido do ID do cliente na mensagem de conexão do MQTT enviada quando uma coisa se conecta a. AWS IoT As variáveis de política da coisa são substituídas quando uma coisa se conecta pelo MQTT usando a autenticação mútua TLS ou AWS IoT ao MQTT pelo WebSocket protocolo usando identidades autenticadas do Amazon Cognito. Você pode usar a AttachThingPrincipalAPI para anexar certificados e identidades autenticadas do Amazon Cognito a uma coisa. iot:Connection.Thing.ThingNameé uma variável de política útil para impor restrições de ID do cliente. O exemplo de AWS IoT política a seguir exige que o nome de uma coisa registrada seja usado como ID do cliente para conexões MQTT com o agente de AWS IoT mensagens:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "iot:Connect", "Resource": [ "arn:aws:iot:us-east-1:123456789012:client/${iot:Connection.Thing.ThingName}" ] } ] }
Se você quiser identificar conflitos contínuos de ID de cliente, você pode ativar e usar o CloudWatch Logs for AWS IoT. Para cada conexão MQTT que o agente de AWS IoT mensagens desconecta devido a conflitos de ID do cliente, um registro de 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 de CloudWatch registros {$.reason= "DUPLICATE_CLIENT_ID" } para pesquisar instâncias de conflitos de ID de cliente ou configurar filtros de CloudWatch métricas e CloudWatch alarmes correspondentes para monitoramento e geração de relatórios contínuos.
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 AWS IoT Core e seguir as melhores práticas 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 primeira coisa que um dispositivo faz para interagir AWS IoT é abrir uma conexão segura. Ao conectar seu dispositivo a AWS IoT, verifique se você está falando com outro servidor AWS IoT e não se passando AWS IoT por outro servidor. Cada um dos AWS IoT servidores é provisionado com um certificado emitido para o iot.amazonaws.com domínio. Esse certificado foi emitido AWS IoT por uma autoridade de certificação confiável que verificou nossa identidade e propriedade do domínio.
Uma das primeiras coisas AWS IoT Core que fazemos quando um dispositivo se conecta é enviar ao dispositivo um certificado de servidor. 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 AWS IoT Core usam períodos de validade limitados (por exemplo, um ano) para seus certificados de servidor e começam a oferecer novos antes que os antigos expirem.
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 IoT 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 AWS IoT política AWS IoT que permita somente a conexão com um ID de cliente conhecido e a publicação e assinatura de um conjunto fixo e identificado de tópicos.
Use um segundo Região da AWS como backup
Considere armazenar uma cópia dos seus dados em um segundo Região da AWS como backup. Observe que a AWS solução chamada Disaster Recovery AWS IoT for
Usar provisionamento just-in-time
Criar e provisionar manualmente cada dispositivo pode ser demorado. AWS IoT fornece uma maneira de definir um modelo para provisionar dispositivos quando eles se conectam pela primeira vez AWS IoT. Para ter mais informações, consulte ust-in-time Provisionamento J.
Permissões para executar testes AWS IoT do 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 AWS IoT do Device Advisor. Você precisará substituir pela função your-device-role-arnde dispositivo Amazon Resource Name (ARN) que você criou de acordo com os pré-requisitos.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": "iam:PassRole", "Resource": "your-device-role-arn", "Condition": { "StringEquals": { "iam:PassedToService": "iotdeviceadvisor.amazonaws.com" } } }, { "Sid": "VisualEditor1", "Effect": "Allow", "Action": [ "execute-api:Invoke*", "iam:ListRoles", // Required to list device roles in the Device Advisor console "iot:Connect", "iot:CreateJob", "iot:DeleteJob", "iot:DescribeCertificate", "iot:DescribeEndpoint", "iot:DescribeJobExecution", "iot:DescribeJob", "iot:DescribeThing", "iot:GetPendingJobExecutions", "iot:GetPolicy", "iot:ListAttachedPolicies", "iot:ListCertificates", "iot:ListPrincipalPolicies", "iot:ListThingPrincipals", "iot:ListThings", "iot:Publish", "iot:StartNextPendingJobExecution", "iot:UpdateJobExecution", "iot:UpdateThingShadow", "logs:CreateLogGroup", "logs:CreateLogStream", "logs:DescribeLogGroups", "logs:DescribeLogStreams", "logs:PutLogEvents", "logs:PutRetentionPolicy" ], "Resource": "*" }, { "Sid": "VisualEditor2", "Effect": "Allow", "Action": "iotdeviceadvisor:*", "Resource": "*" } ] }
Prevenção do problema do substituto confuso entre serviços para o Device Advisor
O problema de "confused deputy" é uma questão de segurança em que uma entidade que não tem permissão para executar uma ação pode coagir uma entidade mais privilegiada a executá-la. Em AWS, a falsificação de identidade entre serviços pode resultar no problema confuso do deputado. 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, AWS fornece ferramentas que ajudam você a proteger seus dados para todos os serviços com diretores de serviços 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.
{ "Version": "2012-10-17", "Statement": { "Sid": "ConfusedDeputyPreventionExamplePolicy", "Effect": "Allow", "Principal": { "Service": "iotdeviceadvisor.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "ArnLike": { "aws:SourceArn":"arn:aws:iotdeviceadvisor:us-east-1:123456789012:suitedefinition/ygp6rxa3tzvn"}, "StringEquals": { "aws:SourceAccount":"123456789012"} } } }
