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é um serviço de nuvem gerenciado que possibilita que dispositivos conectados interajam com aplicativos em nuvem e outros dispositivos de forma fácil e segura. AWS IoT Core suportaHTTP, WebSocket, e MQTT, um protocolo de comunicação leve projetado especificamente para tolerar conexões intermitentes. Se você estiver se conectando ao AWS IoT usandoMQTT, cada uma de suas conexões deverá estar associada a um identificador conhecido como ID do cliente. MQTTo cliente IDs identifica MQTT conexões de forma exclusiva. Se uma nova conexão for estabelecida usando um ID de cliente que já foi reivindicado para outra conexão, o agente de AWS IoT mensagens descarta a conexão antiga para permitir a nova conexão. O cliente IDs deve ser único em Conta da AWS cada um Região da AWS. Isso significa que você não precisa impor a exclusividade global do cliente IDs fora da sua Conta da AWS ou em todas as regiões da sua. Conta da AWS

O impacto e a gravidade da queda de MQTT conexões em sua frota de dispositivos dependem de muitos fatores. Isso inclui:

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 para identificar políticas e políticas excessivamente permissivas AWS IoT . IAM AWS IoT O Device Defender também fornece uma verificação de auditoria que notifica você se vários dispositivos em sua frota estão se conectando ao agente de AWS IoT mensagens usando o mesmo ID de cliente.

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 não está mais disponível. Embora a GitHubbiblioteca associada permaneça acessível, ela AWS foi descontinuada em julho de 2023 e não fornece mais manutenção ou suporte para ela. Para implementar suas próprias soluções ou explorar outras opções de suporte, acesse Contato AWS. Se houver um gerente AWS técnico de contas associado à sua conta, entre em contato com ele para obter ajuda.

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"
      }
    }
  }
}