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 MQTT conexões em AWS IoT
AWS IoT Core
O impacto e a gravidade da queda de MQTT conexões em sua frota de dispositivos dependem de muitos 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).
-
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 IAM política AWS IoT OR que restrinja qual cliente IDs pode ser usado para MQTT conexões com o agente de AWS IoT mensagens. Por exemplo, você pode usar uma IAM política para impedir que um dispositivo feche acidentalmente a conexão de outro dispositivo usando uma ID de cliente que já esteja em uso. Para obter 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) AWS IoT MQTT ações 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, você pode usar AWS IoT Core variáveis de política variáveis IAM de política. 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 MQTT conexão enviada quando uma coisa se conecta AWS IoT a. As variáveis de política da coisa são substituídas quando uma coisa se conecta AWS IoT por MQTT meio de autenticação TLS mútua ou MQTT por meio do WebSocket protocolo usando identidades autenticadas do Amazon Cognito. Você pode usar o AttachThingPrincipalAPIpara 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 MQTT conexões 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 MQTT conexão 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 significa que o software do dispositivo deve incluir um cliente de protocolo de horário de rede (NTP). O dispositivo deve esperar até que seja sincronizado com um NTP servidor 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 NTP servidor, 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.
TLSos certificados estão no formato X.509 e incluem uma variedade de informações, como nome, localização, nome de domínio e 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 obter 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 e IAM entidades mínimas necessárias para executar os casos de teste AWS IoT do Device Advisor. Você precisará substituir your-device-role-arn com a função de 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", "iotjobsdata:DescribeJobExecution", "iot:DescribeJob", "iot:DescribeThing", "iotjobsdata:GetPendingJobExecutions", "iot:GetPolicy", "iot:ListAttachedPolicies", "iot:ListCertificates", "iot:ListPrincipalPolicies", "iot:ListThingPrincipals", "iot:ListThings", "iot:Publish", "iotjobsdata:StartNextPendingJobExecution", "iotjobsdata: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 em um problema confuso de delegado. 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 do seu recurso ARN 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 contra o confuso problema do deputado é usar a chave de contexto ARN de condição aws:SourceArn global com todo o recurso. Se você não souber a totalidade ARN do recurso ou se estiver especificando vários recursos, use a chave de condição de contexto aws:SourceArn global 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"} } } }
