

# Verificações de auditoria
<a name="device-defender-audit-checks"></a>

**nota**  
Quando você habilita uma verificação, a coleta dos dados é iniciada imediatamente. Se houver um grande volume de dados na conta para serem coletados, os resultados da verificação poderão não ficar disponíveis por algum tempo depois de habilitada.

Há suporte para as seguintes verificações de auditoria:
+ [CA intermediária revogada para verificação de certificados de dispositivos ativos](audit-chk-active-intermediary-device-revoked-CA.md)
+ [Certificado da CA revogado ainda ativo](audit-chk-revoked-ca-cert.md)
+ [Certificado de dispositivo compartilhado](audit-chk-device-cert-shared.md)
+ [Qualidade da chave do certificado de dispositivo](audit-chk-device-cert-key-quality.md)
+ [Qualidade da chave do certificado da CA](audit-chk-ca-cert-key-quality.md)
+ [Perfil não autenticado do Cognito excessivamente permissivo](audit-chk-unauth-cognito-role-permissive.md)
+ [Perfil autenticado do Cognito excessivamente permissivo](audit-chk-auth-cognito-role-permissive.md)
+ [Políticas de AWS IoT excessivamente permissivas](audit-chk-iot-policy-permissive.md)
+ [Política de AWS IoT potencialmente mal configurada](audit-chk-iot-misconfigured-policies.md)
+ [O alias de perfil é excessivamente permissivo](audit-chk-iot-role-alias-permissive.md)
+ [O alias de perfil permite acesso a serviços não utilizados](audit-chk-role-alias-unused-svcs.md)
+ [Certificado da CA expirando](audit-chk-ca-cert-approaching-expiration.md)
+ [IDs de cliente MQTT conflitantes](audit-chk-conflicting-client-ids.md)
+ [Certificado do dispositivo expirando](audit-chk-device-cert-approaching-expiration.md)
+ [Verificação da idade do certificado de dispositivo](device-certificate-age-check.md)
+ [Certificado revogado do dispositivo ainda ativo](audit-chk-revoked-device-cert.md)
+ [Registro em log desabilitado](audit-chk-logging-disabled.md)

# CA intermediária revogada para verificação de certificados de dispositivos ativos
<a name="audit-chk-active-intermediary-device-revoked-CA"></a>

Use essa verificação para identificar todos os certificados de dispositivos relacionados que ainda estão ativos, apesar da revogação de uma CA intermediária.

Essa verificação aparece como `INTERMEDIATE_CA_REVOKED_FOR_ACTIVE_DEVICE_CERTIFICATES_CHECK` na CLI e na API.

**Gravidade:** crítica

## Detalhes
<a name="audit-chk-active-device-intermediary-revoked-CA-details"></a>

Os códigos de motivo a seguir são retornados quando essa verificação encontra não compatibilidade:
+ INTERMEDIATE\$1CA\$1REVOKED\$1BY\$1ISSUER

## Por que isso importa?
<a name="audit-chk-active-device-intermediary-revoked-CA-why-it-matters"></a>

A CA intermediária revogada para certificados de dispositivos ativos avalia a identidade e a confiança do dispositivo, determinando se há certificados de dispositivo ativos no AWS IoT Core em que as CAs emissoras intermediárias foram revogadas na cadeia de CAs.

Uma CA intermediária revogada não deve mais ser usada para assinar nenhuma outra CA ou certificado de dispositivo na cadeia de CAs. Dispositivos recém-adicionados com certificados assinados usando esse certificado de CA depois que a CA intermediária for revogada representarão uma ameaça à segurança.

## Como corrigir
<a name="audit-chk-active-device-intermediary-revoked-CA-how-to-fix"></a>

Reveja a atividade de registro de certificados do dispositivo para o período após a revogação do certificado da CA. Siga as práticas recomendadas de segurança para atenuar a situação. Talvez você queira:

1. Provisionar novos certificados assinados por uma CA diferente para os dispositivos afetados.

1. Verificar se os novos certificados são válidos e se os dispositivos podem usá-los para se conectar.

1. Use [UpdateCertificate](https://docs.aws.amazon.com/iot/latest/apireference/API_UpdateCertificate.html) para marcar o certificado antigo como REVOKED no AWS IoT. Você também pode usar ações de mitigação para:
   + Aplicar a ação de mitigação `UPDATE_DEVICE_CERTIFICATE` em suas descobertas de auditoria para fazer essa mudança. 
   + Aplicar a ação de mitigação `ADD_THINGS_TO_THING_GROUP` para adicionar o dispositivo a um grupo, onde é possível executar uma ação sobre ele.
   + Aplicar a ação de mitigação `PUBLISH_FINDINGS_TO_SNS` se você desejar implementar uma resposta personalizada em resposta à mensagem do Amazon SNS. 
   + Verificar as atividades de registro de certificado de dispositivo pelo período após o qual o certificado da CA intermediário foi revogado e considerar a possibilidade de revogar todos os certificados de dispositivos que podem ter sido emitidos com ele durante esse período. Você pode usar [ListRelatedResourcesForAuditFinding](https://docs.aws.amazon.com/iot/latest/apireference/API_ListRelatedResourcesForAuditFinding.html) para listar os certificados de dispositivos assinados pelo certificado da CA e [UpdateCertificate](https://docs.aws.amazon.com/iot/latest/apireference/API_UpdateCertificate.html) para revogar um certificado de dispositivo.
   + Desanexe o antigo certificado do dispositivo. (Consulte [DetachThingPrincipal](https://docs.aws.amazon.com/iot/latest/apireference/API_DetachThingPrincipal.html).)

   Para obter mais informações, consulte [Ações de mitigação](dd-mitigation-actions.md).

# Certificado da CA revogado ainda ativo
<a name="audit-chk-revoked-ca-cert"></a>

Um certificado da CA foi revogado, mas ainda está ativo na AWS IoT.

Essa verificação aparece como `REVOKED_CA_CERTIFICATE_STILL_ACTIVE_CHECK` na CLI e na API.

**Gravidade:** crítica

## Detalhes
<a name="audit-chk-revoked-ca-cert-details"></a>

Um certificado da CA está marcado como revogado na lista de revogação de certificados mantida pela autoridade emissora, mas ainda está marcado como ACTIVE ou PENDING\$1TRANSFER na AWS IoT.

Os códigos de motivo a seguir são retornados quando essa verificação encontra um certificado da CA não compatível:
+ CERTIFICATE\$1REVOKED\$1BY\$1ISSUER

## Por que isso importa?
<a name="audit-chk-revoked-ca-cert-why-it-matters"></a>

Um certificado da CA não deve mais ser usado para assinar certificados de dispositivo. Ele pode ter sido revogado porque foi comprometido. Dispositivos recém-adicionados com certificados assinados usando esse certificado da CA podem representar uma ameaça à segurança. 

## Como corrigir
<a name="audit-chk-revoked-ca-cert-how-to-fix"></a>

1. Use [UpdateCACertificate](https://docs.aws.amazon.com/iot/latest/apireference/API_UpdateCACertificate.html) para marcar o certificado da CA como INACTIVE no AWS IoT. Você também pode usar ações de mitigação para:
   + Aplicar a ação de mitigação `UPDATE_CA_CERTIFICATE` em suas descobertas de auditoria para fazer essa mudança. 
   + Aplicar a ação de mitigação `PUBLISH_FINDINGS_TO_SNS` para implementar uma resposta personalizada em resposta à mensagem do Amazon SNS. 

   Para obter mais informações, consulte [Ações de mitigação](dd-mitigation-actions.md).

1. Revise as atividades de registro de certificado de dispositivo pelo período após o qual o certificado da CA foi revogado e considere a possibilidade de revogar todos os certificados de dispositivos que podem ter sido emitidos com ele durante esse período. Você pode usar [ ListCertificatesByCA](https://docs.aws.amazon.com/iot/latest/apireference/API_ListCertificatesByCA.html) para listar os certificados de dispositivo assinados pelo certificado da CA e [UpdateCertificate](https://docs.aws.amazon.com/iot/latest/apireference/API_UpdateCertificate.html) para revogar um certificado de dispositivo.

# Certificado de dispositivo compartilhado
<a name="audit-chk-device-cert-shared"></a>

Várias conexões simultâneas usando o mesmo certificado X.509 para ser autenticadas com a AWS IoT.

Essa verificação aparece como `DEVICE_CERTIFICATE_SHARED_CHECK` na CLI e na API.

**Gravidade:** crítica

## Detalhes
<a name="audit-chk-device-cert-shared-details"></a>

Quando executada como parte de uma auditoria sob demanda, essa verificação examina os certificados e os IDs de clientes que foram usados pelos dispositivos para se conectar durante os 31 dias anteriores ao início da auditoria, até 2 horas antes da execução da verificação. Para auditorias programadas, essa verificação examina os dados de 2 horas antes da última vez em que a auditoria foi executada até 2 horas antes do início dessa instância da auditoria. Se você tiver tomado medidas para atenuar essa condição durante a verificação, observe quando as conexões simultâneas foram estabelecidas para determinar se o problema persiste.

Os códigos de motivo a seguir são retornados quando essa verificação encontra um certificado não compatível:
+ CERTIFICATE\$1SHARED\$1BY\$1MULTIPLE\$1DEVICES

Além disso, as descobertas retornadas por essa verificação incluem o ID do certificado compartilhado, os IDs dos clientes que usam o certificado para se conectar e os horários de conexão/desconexão. Os resultados mais recentes são listados primeiro.

## Por que isso importa?
<a name="audit-chk-device-cert-shared-why-it-matters"></a>

Cada dispositivo deve ter um certificado exclusivo para se autenticar na AWS IoT. Se vários dispositivos usam o mesmo certificado, isso pode indicar que um dispositivo foi comprometido. A sua identidade pode ter sido clonada para comprometer ainda mais o sistema. 

## Como corrigir
<a name="audit-chk-device-cert-shared-how-to-fix"></a>

Verifique se o certificado de dispositivo não foi comprometido. Se foi, siga as práticas recomendadas de segurança para atenuar a situação. 

Se estiver usando o mesmo certificado em vários dispositivos, você poderá:

1. Provisionar novos certificados exclusivos e anexá-los a cada dispositivo. 

1. Verificar se os novos certificados são válidos e se os dispositivos podem usá-los para se conectar.

1. Use [UpdateCertificate](https://docs.aws.amazon.com/iot/latest/apireference/API_UpdateCertificate.html) para marcar o certificado antigo como REVOKED no AWS IoT. Você também pode usar ações de mitigação para fazer o seguinte:
   + Aplicar a ação de mitigação `UPDATE_DEVICE_CERTIFICATE` em suas descobertas de auditoria para fazer essa mudança. 
   + Aplicar a ação de mitigação `ADD_THINGS_TO_THING_GROUP` para adicionar o dispositivo a um grupo, onde é possível executar uma ação sobre ele.
   + Aplicar a ação de mitigação `PUBLISH_FINDINGS_TO_SNS` se você desejar implementar uma resposta personalizada em resposta à mensagem do Amazon SNS. 

   Para obter mais informações, consulte [Ações de mitigação](dd-mitigation-actions.md). 

1. Desanexe o antigo certificado de todos os dispositivos.

# Qualidade da chave do certificado de dispositivo
<a name="audit-chk-device-cert-key-quality"></a>

A AWS IoT frequentemente confia na autenticação mútua TLS usando certificados X.509 para autenticação no agente de mensagens da AWS IoT. Esses certificados e os respectivos certificados de autoridade de certificação devem ser registrados na conta do AWS IoT antes de serem utilizados. O AWS IoT executa verificações básicas de sanidade nesses certificados quando eles são registrados. Essas verificações incluem:
+ Devem estar em um formato válido.
+ Devem ser assinados por uma autoridade de certificação registrada.
+ Ainda devem estar dentro do prazo de validade (ou seja, não podem ter expirado).
+ Os tamanhos de chave criptográfica devem atender ao tamanho mínimo necessário (para chaves RSA, devem ter 2048 bits ou mais).

Essa verificação de auditoria fornece os seguintes testes adicionais da qualidade da chave criptográfica:
+ CVE-2008-0166 - verifique se a chave foi gerada usando OpenSSL 0.9.8c-1 até versões anteriores a 0.9.8g-9 em um sistema operacional baseado em Debian. Essas versões do OpenSSL usam um gerador de números aleatórios que gera números previsíveis, facilitando para invasores remotos realizar ataques de adivinhação de força bruta contra chaves criptográficas.
+ CVE-2017-15361 – verifique se a chave foi gerada pela biblioteca Infineon RSA 1.02.013 no firmware do Infineon Trusted Platform Module (TPM), como versões anteriores a 0000000000000422 - 4.34, anteriores a 000000000000062b - 6.43 e anteriores a 0000000000008521 - 133.33. Essa biblioteca manipula incorretamente a geração de chaves RSA, tornando mais fácil para os invasores derrotarem alguns mecanismos de proteção criptográfica por meio de ataques direcionados. Exemplos de tecnologias afetadas incluem BitLocker com TPM 1.2, geração de chaves PGP YubiKey 4 (anterior a 4.3.5) e o recurso de criptografia de dados de usuário em cache no Chrome OS.

AWS IoT Device DefenderO relata certificados como não compatíveis quando eles falham nesses testes.

Essa verificação aparece como `DEVICE_CERTIFICATE_KEY_QUALITY_CHECK` na CLI e na API.

**Gravidade:** crítica

## Detalhes
<a name="audit-chk-device-cert-key-quality-details"></a>

Essa verificação se aplica a certificados de dispositivo que estão ACTIVE ou PENDING\$1TRANSFER.

Os códigos de motivo a seguir são retornados quando essa verificação encontra um certificado não compatível:
+ CERTIFICATE\$1KEY\$1VULNERABILITY\$1CVE-2017-15361
+ CERTIFICATE\$1KEY\$1VULNERABILITY\$1CVE-2008-0166

## Por que isso importa?
<a name="audit-chk-device-cert-key-quality-why-it-matters"></a>

Quando um dispositivo usa um certificado vulnerável, os invasores podem comprometer mais facilmente esse dispositivo.

## Como corrigir
<a name="audit-chk-device-cert-key-quality-how-to-fix"></a>

Atualize seus certificados de dispositivo para substituir aqueles com vulnerabilidades conhecidas.

Se você estiver usando o mesmo certificado em vários dispositivos, poderá:

1. Provisionar novos certificados exclusivos e anexá-los a cada dispositivo. 

1. Verificar se os novos certificados são válidos e se os dispositivos podem usá-los para se conectar.

1. Use [UpdateCertificate](https://docs.aws.amazon.com/iot/latest/apireference/API_UpdateCertificate.html) para marcar o certificado antigo como REVOKED no AWS IoT. Você também pode usar ações de mitigação para:
   + Aplicar a ação de mitigação `UPDATE_DEVICE_CERTIFICATE` em suas descobertas de auditoria para fazer essa mudança. 
   + Aplicar a ação de mitigação `ADD_THINGS_TO_THING_GROUP` para adicionar o dispositivo a um grupo, onde é possível executar uma ação sobre ele.
   + Aplicar a ação de mitigação `PUBLISH_FINDINGS_TO_SNS` se você desejar implementar uma resposta personalizada em resposta à mensagem do Amazon SNS. 

   Para obter mais informações, consulte [Ações de mitigação](dd-mitigation-actions.md). 

1. Desanexe o antigo certificado de todos os dispositivos.

# Qualidade da chave do certificado da CA
<a name="audit-chk-ca-cert-key-quality"></a>

A AWS IoT frequentemente confia na autenticação mútua TLS usando certificados X.509 para autenticação no agente de mensagens da AWS IoT. Esses certificados e os respectivos certificados da autoridade de certificação devem ser registrados na sua conta do AWS IoT antes de serem utilizados. O AWS IoT executa verificações básicas de sanidade nesses certificados quando eles são registrados, incluindo:
+ Os certificados estão em um formato válido.
+ Os certificados estão dentro do período de validade (em outras palavras, não expiraram).
+ Os tamanhos de chave criptográfica atendem ao tamanho mínimo necessário (para chaves RSA, devem ter 2048 bits ou mais).

Essa verificação de auditoria fornece os seguintes testes adicionais da qualidade da chave criptográfica:
+ CVE-2008-0166 - verifique se a chave foi gerada usando OpenSSL 0.9.8c-1 até versões anteriores a 0.9.8g-9 em um sistema operacional baseado em Debian. Essas versões do OpenSSL usam um gerador de números aleatórios que gera números previsíveis, facilitando para invasores remotos realizar ataques de adivinhação de força bruta contra chaves criptográficas.
+ CVE-2017-15361 – verifique se a chave foi gerada pela biblioteca Infineon RSA 1.02.013 no firmware do Infineon Trusted Platform Module (TPM), como versões anteriores a 0000000000000422 - 4.34, anteriores a 000000000000062b - 6.43 e anteriores a 0000000000008521 - 133.33. Essa biblioteca manipula incorretamente a geração de chaves RSA, tornando mais fácil para os invasores derrotarem alguns mecanismos de proteção criptográfica por meio de ataques direcionados. Exemplos de tecnologias afetadas incluem BitLocker com TPM 1.2, geração de chaves PGP YubiKey 4 (anterior a 4.3.5) e o recurso de criptografia de dados de usuário em cache no Chrome OS.

AWS IoT Device DefenderO relata certificados como não compatíveis quando eles falham nesses testes.

Essa verificação aparece como `CA_CERTIFICATE_KEY_QUALITY_CHECK` na CLI e na API.

**Gravidade:** crítica

## Detalhes
<a name="audit-chk-ca-cert-key-quality-details"></a>

Essa verificação se aplica a certificados da CA que estão ACTIVE ou PENDING\$1TRANSFER.

Os códigos de motivo a seguir são retornados quando essa verificação encontra um certificado não compatível:
+ CERTIFICATE\$1KEY\$1VULNERABILITY\$1CVE-2017-15361
+ CERTIFICATE\$1KEY\$1VULNERABILITY\$1CVE-2008-0166

## Por que isso importa?
<a name="audit-chk-ca-cert-key-quality-why-it-matters"></a>

Dispositivos recém-adicionados usando esse certificado CA podem representar uma ameaça à segurança.

## Como corrigir
<a name="audit-chk-ca-cert-key-quality-how-to-fix"></a>

1. Use [UpdateCACertificate](https://docs.aws.amazon.com/iot/latest/apireference/API_UpdateCACertificate.html) para marcar o certificado da CA como INACTIVE no AWS IoT. Você também pode usar ações de mitigação para:
   + Aplicar a ação de mitigação `UPDATE_CA_CERTIFICATE` em suas descobertas de auditoria para fazer essa mudança. 
   + Aplicar a ação de mitigação `PUBLISH_FINDINGS_TO_SNS` se você desejar implementar uma resposta personalizada em resposta à mensagem do Amazon SNS. 

   Para obter mais informações, consulte [Ações de mitigação](dd-mitigation-actions.md).

1. Revise as atividades de registro de certificado de dispositivo pelo período após o qual o certificado da CA foi revogado e considere a possibilidade de revogar todos os certificados de dispositivos que podem ter sido emitidos com ele durante esse período. (Use [ ListCertificatesByCA](https://docs.aws.amazon.com/iot/latest/apireference/API_ListCertificatesByCA.html) para listar os certificados de dispositivo assinados pelo certificado da CA e [UpdateCertificate](https://docs.aws.amazon.com/iot/latest/apireference/API_UpdateCertificate.html) para revogar um certificado de dispositivo.)

# Perfil não autenticado do Cognito excessivamente permissivo
<a name="audit-chk-unauth-cognito-role-permissive"></a>

Uma política anexada a um perfil não autenticado do banco de identidades do Amazon Cognito é considerada excessivamente permissiva porque ela concede permissão para executar qualquer uma das seguintes ações de AWS IoT:
+ Gerenciar ou modificar objetos.
+ Ler dados administrativos das objetos.
+ Gerenciar dados ou recursos não relacionados o objetos.

Ou, porque ela concede permissão para executar as seguintes ações da AWS IoT em um amplo conjunto de dispositivos:
+ Usar MQTT para se conectar, publicar ou assinar tópicos reservados (incluindo sombra ou dados de execução de trabalhos).
+ Usar comandos de API para ler ou modificar shadow ou dados de execução de trabalhos.

Em geral, os dispositivos que se conectam usando um perfil não autenticado do banco de identidades do Amazon Cognito só devem ter permissão limitada para publicar e assinar tópicos do MQTT específicos de objetos ou usar os comandos de API para ler e modificar dados específicos de objetos relacionados a dados de execução de trabalhos ou sombra.

Essa verificação aparece como `UNAUTHENTICATED_COGNITO_ROLE_OVERLY_PERMISSIVE_CHECK` na CLI e na API.

**Gravidade:** crítica

## Detalhes
<a name="audit-chk-unauth-cognito-role-permissive-details"></a>

Para essa verificação, o AWS IoT Device Defender audita todos os bancos de identidade do Amazon Cognito que foram usados para se conectar ao agente de mensagens de AWS IoT durante os 31 dias anteriores à realização da auditoria. Todos os bancos de identidades do Amazon Cognito a partir dos quais uma identidade autenticada ou não autenticada do Amazon Cognito é conectada são incluídos na auditoria.

Os códigos de motivo a seguir são retornados quando essa verificação encontra um perfil não autenticado e não compatível do banco de identidades do Amazon Cognito:
+ ALLOWS\$1ACCESS\$1TO\$1IOT\$1ADMIN\$1ACTIONS
+ ALLOWS\$1BROAD\$1ACCESS\$1TO\$1IOT\$1DATA\$1PLANE\$1ACTIONS

## Por que isso importa?
<a name="audit-chk-unauth-cognito-role-permissive-why-it-matters"></a>

Uma vez que identidades não autenticadas nunca são autenticadas pelo usuário, elas representam um risco muito maior do que as identidades autenticadas do Amazon Cognito. Se uma identidade não autenticada estiver comprometida, ela poderá usar ações administrativas para modificar as configurações da conta, excluir recursos ou obter acesso a dados sigilosos. Ou, com amplo acesso às configurações de dispositivo, poderá acessar ou modificar shadows e trabalhos de todos os dispositivos em sua conta. Um usuário convidado pode usar as permissões para comprometer toda a sua frota ou ativar um ataque DDOS com mensagens.

## Como corrigir
<a name="audit-chk-unauth-cognito-role-permissive-how-to-fix"></a>

Uma política anexada a um perfil não autenticado do banco de identidades do Amazon Cognito deve conceder somente as permissões necessárias para um dispositivo fazer seu trabalho. Recomendamos as seguintes etapas:

1. Criar uma nova função compatível.

1. Criar um novo banco de identidades do Amazon Cognito e anexar o perfil compatível a ele.

1. Verificar se suas identidades podem acessar a AWS IoT usando o novo grupo.

1. Após a conclusão da verificação, anexar o perfil compatível ao banco de identidades do Amazon Cognito que foi sinalizado como incompatível.

Você também pode usar ações de mitigação para:
+ Aplicar a ação de mitigação `PUBLISH_FINDINGS_TO_SNS` para implementar uma resposta personalizada em resposta à mensagem do Amazon SNS. 

Para obter mais informações, consulte [Ações de mitigação](dd-mitigation-actions.md). 

## Gerenciar ou modificar objetos
<a name="manage-modify-things-check"></a>

As ações de API da AWS IoT a seguir são usadas para gerenciar ou modificar objetos. A permissão para executar essas ações não deve ser concedida a dispositivos que se conectam por meio de um banco de identidades não autenticadas do Amazon Cognito.
+ `AddThingToThingGroup` 
+ `AttachThingPrincipal` 
+ `CreateThing` 
+ `DeleteThing` 
+ `DetachThingPrincipal` 
+ `ListThings` 
+ `ListThingsInThingGroup` 
+ `RegisterThing` 
+ `RemoveThingFromThingGroup` 
+ `UpdateThing` 
+ `UpdateThingGroupsForThing` 

Qualquer função que conceda permissão para executar essas ações em até mesmo um único recurso é considerada não compatível.

## Ler dados administrativos das objetos
<a name="read-thing-admin-data-check"></a>

As seguintes ações da API da AWS IoT são usadas para ler ou modificar dados de objeto. Os dispositivos que se conectam por meio de um banco de identidades não autenticadas do Amazon Cognito não devem receber permissão para executar essas ações.
+ `DescribeThing`
+ `ListJobExecutionsForThing`
+ `ListThingGroupsForThing`
+ `ListThingPrincipals`

**Example**  
+ incompatível:

------
#### [ JSON ]

****  

  ```
  {
    "Version":"2012-10-17",		 	 	 
    "Statement": [
      {
        "Sid": "AllowIoTThingOperations",
        "Effect": "Allow",
        "Action": [ 
            "iot:DescribeThing",
            "iot:ListJobExecutionsForThing",
            "iot:ListThingGroupsForThing",
            "iot:ListThingPrincipals"
        ],
        "Resource": [
          "arn:aws:iot:us-east-1:123456789012:thing/name-of-thing"
        ]
      }
    ]
  }
  ```

------

  Permite que o dispositivo execute as ações especificadas mesmo que sejam concedidas para um objeto apenas.

## Gerenciar não objetos
<a name="manage-non-things-check"></a>

Os dispositivos que se conectam por meio de um banco de identidades não autenticadas do Amazon Cognito não devem receber permissão para executar ações de API da AWS IoT além das discutidas nessas seções. Para gerenciar sua conta com um aplicativo que se conecta por meio de um banco de identidades não autenticadas do Amazon Cognito, crie um banco de identidades separado que não é usado pelos dispositivos.

## Assinar/publicar em tópicos do MQTT
<a name="audit-chk-unauth-cognito-role-permissive-mqtt-topics"></a>

As mensagens do MQTT são enviadas por meio do agente de mensagens do AWS IoT e são usadas pelos dispositivos para executar muitas ações, incluindo acessar e modificar o estado de sombra e o estado de execução de trabalhos. Uma política que concede permissão para um dispositivo se conectar, publicar ou assinar mensagens do MQTT deve restringir essas ações a recursos específicos da seguinte forma:

**Conectar**  
+ incompatível:

  ```
  arn:aws:iot:region:account-id:client/*
  ```

  O curinga \$1 permite que qualquer dispositivo se conecte ao AWS IoT.

  ```
  arn:aws:iot:region:account-id:client/${iot:ClientId}
  ```

  A menos que `iot:Connection.Thing.IsAttached` seja definido como true nas chaves de condição, é equivalente ao curinga \$1 no exemplo anterior.
+ compatível:

------
#### [ JSON ]

****  

  ```
  {
    "Version":"2012-10-17",		 	 	 
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "iot:Connect"
        ],
        "Resource": [
          "arn:aws:iot:us-east-1:123456789012:client/${iot:Connection.Thing.ThingName}"
        ]
      }
    ]
  }
  ```

------

  A especificação de recurso contém uma variável que corresponde ao nome do dispositivo usado para se conectar. A declaração de condição restringe ainda mais a permissão, verificando se o certificado usado pelo cliente MQTT corresponde ao que é anexado ao objeto com o nome usado.

**Publicar**  
+ incompatível:

  ```
  arn:aws:iot:region:account-id:topic/$aws/things/*/shadow/update
  ```

  Isso permite que o dispositivo atualize o shadow de qualquer dispositivo (\$1 = todos os dispositivos).

  ```
  arn:aws:iot:region:account-id:topic/$aws/things/*
  ```

  Isso permite que o dispositivo leia, atualize ou exclua a sombra de qualquer dispositivo.
+ compatível:

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": [
          {
              "Effect": "Allow",
              "Action": [
                  "iot:Publish"
              ],
              "Resource": [
                  "arn:aws:iot:us-east-1:123456789012:topic/$aws/things/${iot:Connection.Thing.ThingName}/shadow/*"
              ]
          }
      ]
  }
  ```

------

  A especificação do recurso contém um caractere curinga, mas apenas corresponde a qualquer tópico relacionado a shadow para o dispositivo cujo nome do objeto é usado para se conectar.

**Assinar**  
+ incompatível:

  ```
  arn:aws:iot:region:account-id:topicfilter/$aws/things/*
  ```

  Isso permite que o dispositivo assine tópicos de shadow ou de trabalho reservados para todos os dispositivos.

  ```
  arn:aws:iot:region:account-id:topicfilter/$aws/things/*
  ```

  O mesmo do exemplo anterior, mas usando o curinga \$1.

  ```
  arn:aws:iot:region:account-id:topicfilter/$aws/things/+/shadow/update
  ```

  Isso permite que o dispositivo veja as atualizações de shadow de qualquer dispositivo (\$1 = todos os dispositivos).
+ compatível:

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": [
          {
              "Effect": "Allow",
              "Action": [
                  "iot:Subscribe"
              ],
              "Resource": [
                  "arn:aws:iot:us-east-1:123456789012:topicfilter/$aws/things/${iot:Connection.Thing.ThingName}/shadow/*",
                  "arn:aws:iot:us-east-1:123456789012:topicfilter/$aws/things/${iot:Connection.Thing.ThingName}/jobs/*"
              ]
          }
      ]
  }
  ```

------

  As especificações de recursos contêm caracteres curinga, mas eles apenas correspondem a qualquer tópico relacionado a shadow e a trabalho para o dispositivo cujo nome do objeto é usado para se conectar.

**Receber**  
+ compatível:

  ```
  arn:aws:iot:region:account-id:topicfilter/$aws/things/*
  ```

  Isso é permitido porque o dispositivo só pode receber mensagens de tópicos nos quais ele tem permissão para assinar.

## Ler/modificar dados de sombra ou de trabalho
<a name="read-modify-shadow-job-data-check"></a>

Uma política que concede permissão para um dispositivo executar uma ação de API para acessar ou modificar shadows de dispositivos ou dados de execução de trabalhos deve restringir essas ações a recursos específicos. Estas são as ações da API:
+ `DeleteThingShadow`
+ `GetThingShadow`
+ `UpdateThingShadow`
+ `DescribeJobExecution`
+ `GetPendingJobExecutions`
+ `StartNextPendingJobExecutio`n
+ `UpdateJobExecution`

**Example**  
+ incompatível:

  ```
  arn:aws:iot:region:account-id:thing/*
  ```

  Isso permite que o dispositivo realize a ação especificada em qualquer objeto.
+ compatível:

------
#### [ JSON ]

****  

  ```
  {
    "Version":"2012-10-17",		 	 	 
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [ 
            "iot:DeleteThingShadow",
            "iot:GetThingShadow",
            "iot:UpdateThingShadow",
            "iotjobsdata:DescribeJobExecution",
            "iotjobsdata:GetPendingJobExecutions",
            "iotjobsdata:StartNextPendingJobExecution",
            "iotjobsdata:UpdateJobExecution"
        ],
        "Resource": [
          "arn:aws:iot:us-east-1:123456789012:thing/MyThing1",
          "arn:aws:iot:us-east-1:123456789012:thing/MyThing2"
        ]
      }
    ]
  }
  ```

------

  Isso permite que o dispositivo execute ações específicas em duas objetos apenas.

# Perfil autenticado do Cognito excessivamente permissivo
<a name="audit-chk-auth-cognito-role-permissive"></a>

Uma política anexada a um perfil autenticado do banco de identidades do Amazon Cognito é considerada excessivamente permissiva porque ela concede permissão para executar as seguintes ações de AWS IoT:
+ Gerenciar ou modificar objetos.
+ Gerenciar dados ou recursos não relacionados o objetos.

Ou, porque ela concede permissão para executar as seguintes ações da AWS IoT em um amplo conjunto de dispositivos:
+ Ler dados administrativos das objetos.
+ Usar MQTT para se conectar/publicar/assinar tópicos reservados (incluindo shadow ou dados de execução de trabalhos).
+ Usar comandos de API para ler ou modificar shadow ou dados de execução de trabalhos.

Em geral, os dispositivos que se conectam usando um perfil autenticado do banco de identidades do Amazon Cognito só devem ter permissão limitada para ler dados administrativos específicos de objetos, publicar e assinar tópicos do MQTT específicos de objetos ou usar os comandos de API para ler e modificar dados específicos de objetos relacionados a dados de execução de trabalhos ou sombra.

Essa verificação aparece como `AUTHENTICATED_COGNITO_ROLE_OVERLY_PERMISSIVE_CHECK` na CLI e na API.

**Gravidade:** crítica

## Detalhes
<a name="audit-chk-auth-cognito-role-permissive-details"></a>

Para essa verificação, o AWS IoT Device Defender audita todos os bancos de identidade do Amazon Cognito que foram usados para se conectar ao agente de mensagens de AWS IoT durante os 31 dias anteriores à realização da auditoria. Todos os bancos de identidades do Amazon Cognito a partir dos quais uma identidade autenticada ou não autenticada do Amazon Cognito é conectada são incluídos na auditoria.

Os códigos de motivo a seguir são retornados quando essa verificação encontra um perfil autenticado e não compatível do banco de identidades do Amazon Cognito:
+ ALLOWS\$1BROAD\$1ACCESS\$1TO\$1IOT\$1THING\$1ADMIN\$1READ\$1ACTIONS
+ ALLOWS\$1ACCESS\$1TO\$1IOT\$1NON\$1THING\$1ADMIN\$1ACTIONS
+ ALLOWS\$1ACCESS\$1TO\$1IOT\$1THING\$1ADMIN\$1WRITE\$1ACTIONS

## Por que isso importa?
<a name="audit-chk-auth-cognito-role-permissive-why-it-matters"></a>

Se uma identidade autenticada estiver comprometida, ela poderá usar ações administrativas para modificar as configurações da conta, excluir recursos ou obter acesso a dados sigilosos.

## Como corrigir
<a name="audit-chk-auth-cognito-role-permissive-how-to-fix"></a>

Uma política anexada a um perfil autenticado do banco de identidades do Amazon Cognito deve conceder somente as permissões necessárias para um dispositivo fazer seu trabalho. Recomendamos as seguintes etapas:

1. Criar uma nova função compatível.

1. Criar um novo banco de identidades do Amazon Cognito e anexar o perfil compatível a ele.

1. Verificar se suas identidades podem acessar a AWS IoT usando o novo grupo.

1. Após a conclusão da verificação, anexar o perfil ao banco de identidades do Amazon Cognito que foi sinalizado como incompatível.

Você também pode usar ações de mitigação para:
+ Aplicar a ação de mitigação `PUBLISH_FINDINGS_TO_SNS` para implementar uma resposta personalizada em resposta à mensagem do Amazon SNS. 

Para obter mais informações, consulte [Ações de mitigação](dd-mitigation-actions.md). 

## Gerenciar ou modificar objetos
<a name="audit-chk-auth-cognito-role-permissive-manage-things"></a>

As seguintes ações de API da AWS IoT são usadas para gerenciar ou modificar objetos para que a permissão para executá-las não seja concedida a dispositivos que se conectem por meio de um banco de identidades não autenticadas do Amazon Cognito:
+ `AddThingToThingGroup` 
+ `AttachThingPrincipal` 
+ `CreateThing` 
+ `DeleteThing` 
+ `DetachThingPrincipal` 
+ `ListThings`
+ `ListThingsInThingGroup` 
+ `RegisterThing` 
+ `RemoveThingFromThingGroup` 
+ `UpdateThing` 
+ `UpdateThingGroupsForThing`

Qualquer função que conceda permissão para executar essas ações em até mesmo um único recurso é considerada não compatível.

## Gerenciar não objetos
<a name="audit-chk-auth-cognito-role-permissive-manage-non-things"></a>

Os dispositivos que se conectam por meio de um banco de identidades autenticadas do Amazon Cognito não devem receber permissão para executar ações de API da AWS IoT além das discutidas nessas seções. Para gerenciar sua conta com um aplicativo que se conecta por meio de um banco de identidades do Amazon Cognito, crie um banco de identidades separado não usado pelos dispositivos.

## Ler dados administrativos das objetos
<a name="audit-chk-auth-cognito-role-permissive-read-things-admin-data"></a>

As seguintes ações de API da AWS IoT são usadas para ler dados de objetos para que os dispositivos que se conectem por meio de um banco de identidades autenticadas do Amazon Cognito tenham permissão para executá-las em apenas um conjunto limitado de objetos:
+ `DescribeThing`
+ `ListJobExecutionsForThing`
+ `ListThingGroupsForThing`
+ `ListThingPrincipals`
+ incompatível:

  ```
  arn:aws:iot:region:account-id:thing/*
  ```

  Isso permite que o dispositivo realize a ação especificada em qualquer objeto.
+ compatível:

------
#### [ JSON ]

****  

  ```
  {
    "Version":"2012-10-17",		 	 	 
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [ 
            "iot:DescribeThing",
            "iot:ListJobExecutionsForThing",
            "iot:ListThingGroupsForThing",
            "iot:ListThingPrincipals"
        ],
        "Resource": [
          "arn:aws:iot:us-east-1:123456789012:thing/MyThing"
        ]
      }
    ]
  }
  ```

------

  Isso permite que o dispositivo execute as ações especificadas em apenas um objeto.
+ compatível:

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": [
          {
              "Effect": "Allow",
              "Action": [
                  "iot:DescribeThing",
                  "iot:ListJobExecutionsForThing",
                  "iot:ListThingGroupsForThing",
                  "iot:ListThingPrincipals"
              ],
              "Resource": [
                  "arn:aws:iot:us-east-1:123456789012:thing/MyThing*"
              ]
          }
      ]
  }
  ```

------

  É compatível, pois, embora o recurso seja especificado com um caractere curinga (\$1), ele é precedido por uma string específica, e isso limita o conjunto de objetos acessadas àqueles com nomes que têm um determinado prefixo.
+ incompatível:

  ```
  arn:aws:iot:region:account-id:thing/*
  ```

  Isso permite que o dispositivo realize a ação especificada em qualquer objeto.
+ compatível:

------
#### [ JSON ]

****  

  ```
  {
    "Version":"2012-10-17",		 	 	 
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [ 
            "iot:DescribeThing",
            "iot:ListJobExecutionsForThing",
            "iot:ListThingGroupsForThing",
            "iot:ListThingPrincipals"
        ],
        "Resource": [
          "arn:aws:iot:us-east-1:123456789012:thing/MyThing"
        ]
      }
    ]
  }
  ```

------

  Isso permite que o dispositivo execute as ações especificadas em apenas um objeto.
+ compatível:

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": [
          {
              "Effect": "Allow",
              "Action": [
                  "iot:DescribeThing",
                  "iot:ListJobExecutionsForThing",
                  "iot:ListThingGroupsForThing",
                  "iot:ListThingPrincipals"
              ],
              "Resource": [
                  "arn:aws:iot:us-east-1:123456789012:thing/MyThing*"
              ]
          }
      ]
  }
  ```

------

  É compatível, pois, embora o recurso seja especificado com um caractere curinga (\$1), ele é precedido por uma string específica, e isso limita o conjunto de objetos acessadas àqueles com nomes que têm um determinado prefixo.

## Assinar/publicar em tópicos do MQTT
<a name="audit-chk-auth-cognito-role-permissive-mqtt-topic"></a>

As mensagens do MQTT são enviadas por meio do agente de mensagens da AWS IoT e são usadas pelos dispositivos para executar muitas ações diferentes, incluindo acessar e modificar o estado de shadow e o estado de execução de trabalhos. Uma política que concede permissão para um dispositivo se conectar, publicar ou assinar mensagens do MQTT deve restringir essas ações a recursos específicos da seguinte forma:

**Conectar**  
+ incompatível:

  ```
  arn:aws:iot:region:account-id:client/*
  ```

  O curinga \$1 permite que qualquer dispositivo se conecte ao AWS IoT.

  ```
  arn:aws:iot:region:account-id:client/${iot:ClientId}
  ```

  A menos que `iot:Connection.Thing.IsAttached` seja definido como true nas chaves de condição, é equivalente ao curinga \$1 no exemplo anterior.
+ compatível:

------
#### [ JSON ]

****  

  ```
  {
    "Version":"2012-10-17",		 	 	 
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "iot:Connect"
        ],
        "Resource": [
          "arn:aws:iot:us-east-1:123456789012:client/${iot:Connection.Thing.ThingName}"
        ]
      }
    ]
  }
  ```

------

  A especificação do recurso contém uma variável que corresponde ao nome do dispositivo usado para se conectar, e a declaração de condição restringe ainda mais a permissão, verificando se o certificado usado pelo cliente MQTT corresponde ao anexado ao objeto com o nome usado.

**Publicar**  
+ incompatível:

  ```
  arn:aws:iot:region:account-id:topic/$aws/things/*/shadow/update
  ```

  Isso permite que o dispositivo atualize o shadow de qualquer dispositivo (\$1 = todos os dispositivos).

  ```
  arn:aws:iot:region:account-id:topic/$aws/things/*
  ```

  Isso permite que o dispositivo leia/atualize/exclua o shadow de qualquer dispositivo.
+ compatível:

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": [
          {
              "Effect": "Allow",
              "Action": [
                  "iot:Publish"
              ],
              "Resource": [
                  "arn:aws:iot:us-east-1:123456789012:topic/$aws/things/${iot:Connection.Thing.ThingName}/shadow/*"
              ]
          }
      ]
  }
  ```

------

  A especificação do recurso contém um caractere curinga, mas apenas corresponde a qualquer tópico relacionado a shadow para o dispositivo cujo nome do objeto é usado para se conectar.

**Assinar**  
+ incompatível:

  ```
  arn:aws:iot:region:account-id:topicfilter/$aws/things/*
  ```

  Isso permite que o dispositivo assine tópicos de shadow ou de trabalho reservados para todos os dispositivos.

  ```
  arn:aws:iot:region:account-id:topicfilter/$aws/things/#
  ```

  O mesmo do exemplo anterior, mas usando o curinga \$1.

  ```
  arn:aws:iot:region:account-id:topicfilter/$aws/things/+/shadow/update
  ```

  Isso permite que o dispositivo veja as atualizações de shadow de qualquer dispositivo (\$1 = todos os dispositivos).
+ compatível:

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": [
          {
              "Effect": "Allow",
              "Action": [
                  "iot:Subscribe"
              ],
              "Resource": [
                  "arn:aws:iot:us-east-1:123456789012:topicfilter/$aws/things/${iot:Connection.Thing.ThingName}/shadow/*",
                  "arn:aws:iot:us-east-1:123456789012:topicfilter/$aws/things/${iot:Connection.Thing.ThingName}/jobs/*"
              ]
          }
      ]
  }
  ```

------

  As especificações de recursos contêm caracteres curinga, mas eles apenas correspondem a qualquer tópico relacionado a shadow e a trabalho para o dispositivo cujo nome do objeto é usado para se conectar.

**Receber**  
+ compatível:

  ```
  arn:aws:iot:region:account-id:topicfilter/$aws/things/*
  ```

  Isso é compatível porque o dispositivo só pode receber mensagens de tópicos nos quais ele tem permissão para assinar.

## Ler ou modificar dados de sombra ou trabalho
<a name="audit-chk-auth-cognito-role-permissive-shadow-job-data"></a>

Uma política que concede permissão para um dispositivo executar uma ação de API para acessar ou modificar shadows de dispositivos ou dados de execução de trabalhos deve restringir essas ações a recursos específicos. Estas são as ações da API:
+ `DeleteThingShadow`
+ `GetThingShadow`
+ `UpdateThingShadow`
+ `DescribeJobExecution`
+ `GetPendingJobExecutions`
+ `StartNextPendingJobExecution`
+ `UpdateJobExecution`

**Exemplos**
+ incompatível:

  ```
  arn:aws:iot:region:account-id:thing/*
  ```

  Isso permite que o dispositivo realize a ação especificada em qualquer objeto.
+ compatível:

------
#### [ JSON ]

****  

  ```
  {
    "Version":"2012-10-17",		 	 	 
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "iot:DeleteThingShadow",
          "iot:GetThingShadow",
          "iot:UpdateThingShadow",
          "iot:DescribeJobExecution",
          "iotjobsdata:DescribeJobExecution",
          "iotjobsdata:UpdateJobExecution"
        ],
        "Resource": [
          "arn:aws:iot:us-east-1:123456789012:thing/MyThing1",
          "arn:aws:iot:us-east-1:123456789012:thing/MyThing2"
        ]
      }
    ]
  }
  ```

------

  Isso permite que o dispositivo execute as ações específicas em apenas duas objetos.

# Políticas de AWS IoT excessivamente permissivas
<a name="audit-chk-iot-policy-permissive"></a>

Uma política do AWS IoT concede permissões que são muito amplas ou irrestritas. Ela concede permissão para enviar ou receber mensagens MQTT para um amplo conjunto de dispositivos ou concede permissão para acessar ou modificar dados de execução de trabalhos e sombra para um amplo conjunto de dispositivos. 

Em geral, uma política para um dispositivo deve conceder acesso a recursos associados a apenas esse dispositivo e nenhum outro ou a muito poucos dispositivos. Com algumas exceções, o uso de um curinga (por exemplo,"\$1") para especificar recursos em uma política é considerado muito amplo ou irrestrito.

Essa verificação aparece como `IOT_POLICY_OVERLY_PERMISSIVE_CHECK` na CLI e na API.

**Gravidade:** crítica

## Detalhes
<a name="audit-chk-iot-policy-permissive-details"></a>

O código de motivo a seguir é retornado quando essa verificação encontra uma política incompatível do AWS IoT:
+ ALLOWS\$1BROAD\$1ACCESS\$1TO\$1IOT\$1DATA\$1PLANE\$1ACTIONS

## Por que isso importa?
<a name="audit-chk-iot-policy-permissive-why-it-matters"></a>

Um certificado, uma identidade do Amazon Cognito ou um grupo de objetos com uma política excessivamente permissiva podem, se comprometidos, afetar a segurança de toda a sua conta. Um invasor pode usar esse amplo acesso para ler ou modificar sombras, trabalhos ou execuções de trabalhos de todos os seus dispositivos. Ou um invasor pode usar um certificado comprometido para conectar dispositivos mal-intencionados ou ativar um ataque DDOS na rede.

## Como corrigir
<a name="audit-chk-iot-policy-permissive-how-to-fix"></a>

Siga estas etapas para corrigir todas as políticas que não estão em conformidade anexadas o objetos, grupos de objetos ou outras entidades:

1. Use [CreatePolicyVersion](https://docs.aws.amazon.com/iot/latest/apireference/API_CreatePolicyVersion.html) para criar uma nova versão compatível da política. Defina o sinalizador `setAsDefault` como verdadeiro. (Isso torna essa nova versão operacional para todas as entidades que usam a política.)

1. Use [ ListTargetsForPolicy](https://docs.aws.amazon.com/iot/latest/apireference/API_ListTargetsForPolicy.html) para obter uma lista de destinos (certificados, grupos de objetos) aos quais a política está anexada e determine quais dispositivos estão incluídos nos grupos ou que usam os certificados para se conectar.

1. Verifique se todos os dispositivos associados podem se conectar à AWS IoT. Se um dispositivo não conseguir se conectar, use [ SetPolicyVersion](https://docs.aws.amazon.com/iot/latest/apireference/API_SetPolicyVersion.html) para reverter a política padrão para a versão anterior, revise-a e tente novamente. 

Você pode usar ações de mitigação para:
+ Aplicar a ação de mitigação `REPLACE_DEFAULT_POLICY_VERSION` em suas descobertas de auditoria para fazer essa mudança. 
+ Aplicar a ação de mitigação `PUBLISH_FINDINGS_TO_SNS` se você desejar implementar uma resposta personalizada em resposta à mensagem do Amazon SNS. 

Para obter mais informações, consulte [Ações de mitigação](dd-mitigation-actions.md). 

Use as [variáveis da Política do AWS IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/iot-policy-variables.html) para fazer referência dinâmica aos recursos do AWS IoT nas suas políticas.

## Permissões MQTT
<a name="audit-chk-iot-policy-permissive-mqtt-permissions"></a>

As mensagens do MQTT são enviadas por meio do agente de mensagens do AWS IoT e são usadas pelos dispositivos para executar muitas ações, incluindo acessar e modificar o estado de sombra e o estado de execução de trabalhos. Uma política que concede permissão para um dispositivo se conectar, publicar ou assinar mensagens do MQTT deve restringir essas ações a recursos específicos da seguinte forma:

**Conectar**  
+ incompatível:

  ```
  arn:aws:iot:region:account-id:client/*
  ```

  O curinga \$1 permite que qualquer dispositivo se conecte ao AWS IoT.

  ```
  arn:aws:iot:region:account-id:client/${iot:ClientId}
  ```

  A não ser que `iot:Connection.Thing.IsAttached` seja definido como true nas chaves de condição, isso é equivalente ao curinga\$1 como no exemplo anterior.
+ compatível:

------
#### [ JSON ]

****  

  ```
  {
    "Version":"2012-10-17",		 	 	 
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "iot:Connect"
        ],
        "Resource": [
          "arn:aws:iot:us-east-1:123456789012:client/${iot:Connection.Thing.ThingName}"
        ]
      }
    ]
  }
  ```

------

  A especificação de recurso contém uma variável que corresponde ao nome do dispositivo usado para se conectar. A declaração de condição restringe ainda mais a permissão, verificando se o certificado usado pelo cliente MQTT corresponde ao que é anexado ao objeto com o nome usado.

**Publicar**  
+ incompatível:

  ```
  arn:aws:iot:region:account-id:topic/$aws/things/*/shadow/update
  ```

  Isso permite que o dispositivo atualize o shadow de qualquer dispositivo (\$1 = todos os dispositivos).

  ```
  arn:aws:iot:region:account-id:topic/$aws/things/*
  ```

  Isso permite que o dispositivo leia, atualize ou exclua a sombra de qualquer dispositivo.
+ compatível:

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": [
          {
              "Effect": "Allow",
              "Action": [
                  "iot:Publish"
              ],
              "Resource": [
                  "arn:aws:iot:us-east-1:123456789012:topic/$aws/things/${iot:Connection.Thing.ThingName}/shadow/*"
              ]
          }
      ]
  }
  ```

------

  A especificação do recurso contém um caractere curinga, mas apenas corresponde a qualquer tópico relacionado a shadow para o dispositivo cujo nome do objeto é usado para se conectar.

**Assinar**  
+ incompatível:

  ```
  arn:aws:iot:region:account-id:topicfilter/$aws/things/*
  ```

  Isso permite que o dispositivo assine tópicos de shadow ou de trabalho reservados para todos os dispositivos.

  ```
  arn:aws:iot:region:account-id:topicfilter/$aws/things/*
  ```

  O mesmo do exemplo anterior, mas usando o curinga \$1.

  ```
  arn:aws:iot:region:account-id:topicfilter/$aws/things/+/shadow/update
  ```

  Isso permite que o dispositivo veja as atualizações de shadow de qualquer dispositivo (\$1 = todos os dispositivos).
+ compatível:

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": [
          {
              "Effect": "Allow",
              "Action": [
                  "iot:Subscribe"
              ],
              "Resource": [
                  "arn:aws:iot:us-east-1:123456789012:topicfilter/$aws/things/${iot:Connection.Thing.ThingName}/shadow/*",
                  "arn:aws:iot:us-east-1:123456789012:topicfilter/$aws/things/${iot:Connection.Thing.ThingName}/jobs/*"
              ]
          }
      ]
  }
  ```

------

  As especificações de recursos contêm caracteres curinga, mas eles apenas correspondem a qualquer tópico relacionado a shadow e a trabalho para o dispositivo cujo nome do objeto é usado para se conectar.

**Receber**  
+ compatível:

  ```
  arn:aws:iot:region:account-id:topic/$aws/things/*
  ```

  Isso é compatível porque o dispositivo só pode receber mensagens de tópicos nos quais ele tem permissão para assinar.

## Permissões de sombra e trabalho
<a name="shadow-job-permissions"></a>

Uma política que concede permissão para um dispositivo executar uma ação de API para acessar ou modificar shadows de dispositivos ou dados de execução de trabalhos deve restringir essas ações a recursos específicos. Estas são as ações da API:
+ `DeleteThingShadow`
+ `GetThingShadow`
+ `UpdateThingShadow`
+ `DescribeJobExecution`
+ `GetPendingJobExecutions`
+ `StartNextPendingJobExecution`
+ `UpdateJobExecution`

**Exemplos**
+ incompatível:

  ```
  arn:aws:iot:region:account-id:thing/*
  ```

  Isso permite que o dispositivo realize a ação especificada em qualquer objeto.
+ compatível:

------
#### [ JSON ]

****  

  ```
  {
    "Version":"2012-10-17",		 	 	 
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [ 
            "iot:DeleteThingShadow",
            "iot:GetThingShadow",
            "iot:UpdateThingShadow",
            "iotjobsdata:DescribeJobExecution",
            "iotjobsdata:GetPendingJobExecutions",
            "iotjobsdata:StartNextPendingJobExecution",
            "iotjobsdata:UpdateJobExecution"
        ],
        "Resource": [
          "arn:aws:iot:us-east-1:123456789012:thing/MyThing1",
          "arn:aws:iot:us-east-1:123456789012:thing/MyThing2"
        ]
      }
    ]
  }
  ```

------

  Isso permite que o dispositivo execute as ações específicas em apenas duas objetos.

# Política de AWS IoT potencialmente mal configurada
<a name="audit-chk-iot-misconfigured-policies"></a>

Uma política de AWS IoT foi identificada como potencialmente mal configurada. Políticas mal configuradas, incluindo políticas excessivamente permissivas, podem causar incidentes de segurança, como permitir que dispositivos acessem recursos não intencionais.

A verificação da **política de AWS IoT potencialmente mal configurada** é um aviso para que você se certifique de que somente as ações pretendidas são permitidas antes de atualizar a política.

Na CLI e na API, essa verificação aparece como `IOT_POLICY_POTENTIAL_MISCONFIGURATION_CHECK`.

**Gravidade:** média

## Detalhes
<a name="audit-chk-iot-misconfigured-policies-details"></a>

A AWS IoT retorna o seguinte código de motivo quando essa verificação encontra uma política de AWS IoT potencialmente mal configurada:
+ POLICY\$1CONTAINS\$1MQTT\$1WILDCARDS\$1IN\$1DENY\$1STATEMENT
+ TOPIC\$1FILTERS\$1INTENDED\$1TO\$1DENY\$1ALLOWED\$1USING\$1WILDCARDS

## Por que isso importa?
<a name="audit-chk-iot-misconfigured-policies-why-it-matters"></a>

Políticas mal configuradas podem resultar em consequências não intencionais ao fornecer mais permissões aos dispositivos do que o necessário. Recomendamos uma análise cuidadosa da política para limitar o acesso aos recursos e evitar ameaças à segurança.

### A política contém curingas MQTT no exemplo de declaração de negação
<a name="example-section-id"></a>

A **verificação da política de AWS IoT potencialmente mal configuradas** inspeciona os caracteres curinga (`+` ou `#`) do MQTT em declarações de negação. Os curingas são tratados como strings literais pelas políticas de AWS IoT e podem tornar a política excessivamente permissiva.

O exemplo a seguir tem como objetivo negar a assinatura de tópicos relacionados a `building/control_room` do curinga do MQTT `#` nas políticas. No entanto, os curingas do MQTT não têm um significado curinga nas políticas de AWS IoT e os dispositivos podem assinar `building/control_room/data1`.

A **verificação da política de AWS IoT potencialmente mal configurada** sinalizará essa política com o código de motivo `POLICY_CONTAINS_MQTT_WILDCARDS_IN_DENY_STATEMENT`.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "iot:Subscribe",
            "Resource": "arn:aws:iot:us-east-1:123456789012:topicfilter/building/*"
        },
        {
            "Effect": "Deny",
            "Action": "iot:Subscribe",
            "Resource": "arn:aws:iot:us-east-1:123456789012:topicfilter/building/control_room/#"
        },
        {
            "Effect": "Allow",
            "Action": "iot:Receive",
            "Resource": "arn:aws:iot:us-east-1:123456789012:topic/building/*"
        }
    ]
}
```

------

Veja a seguir um exemplo de uma política configurada corretamente. Os dispositivos não têm permissão para assinar subtópicos de `building/control_room/` e para receber mensagens de subtópicos de `building/control_room/`.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "iot:Subscribe",
      "Resource": "arn:aws:iot:us-east-1:123456789012:topicfilter/building/*"
    },
    {
      "Effect": "Deny",
      "Action": "iot:Subscribe",
      "Resource": "arn:aws:iot:us-east-1:123456789012:topicfilter/building/control_room/*"
    },
    {
      "Effect": "Allow",
      "Action": "iot:Receive",
      "Resource": "arn:aws:iot:us-east-1:123456789012:topic/building/*"
    },
    {
      "Effect": "Deny",
      "Action": "iot:Receive",
      "Resource": "arn:aws:iot:us-east-1:123456789012:topic/building/control_room/*"
    }
  ]
}
```

------

### Exemplo de filtros de tópicos para negar a permissão usando curingas
<a name="example-section-id2"></a>

O exemplo de política a seguir tem como objetivo negar a assinatura de tópicos relacionados a `building/control_room` negando o recurso `building/control_room/*`. No entanto, os dispositivos podem enviar solicitações para assinar `building/#` e receber mensagens de todos os tópicos relacionados a `building`, incluindo `building/control_room/data1`.

A **verificação da política de AWS IoT potencialmente mal configurada** sinalizará essa política com o código de motivo `TOPIC_FILTERS_INTENDED_TO_DENY_ALLOWED_USING_WILDCARDS`.

O exemplo de política a seguir tem permissões para receber mensagens em `building/control_room topics`:

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "iot:Subscribe",
            "Resource": "arn:aws:iot:us-east-1:123456789012:topicfilter/building/*"
        },
        {
            "Effect": "Deny",
            "Action": "iot:Subscribe",
            "Resource": "arn:aws:iot:us-east-1:123456789012:topicfilter/building/control_room/*"
        },
        {
            "Effect": "Allow",
            "Action": "iot:Receive",
            "Resource": "arn:aws:iot:us-east-1:123456789012:topic/building/*"
        }
    ]
}
```

------

Veja a seguir um exemplo de uma política configurada corretamente. Os dispositivos não têm permissão para assinar subtópicos de `building/control_room/` e para receber mensagens de subtópicos de `building/control_room/`.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "iot:Subscribe",
            "Resource": "arn:aws:iot:us-east-1:123456789012:topicfilter/building/*"
        },
        {
            "Effect": "Deny",
            "Action": "iot:Subscribe",
            "Resource": "arn:aws:iot:us-east-1:123456789012:topicfilter/building/control_room/*"
        },
        {
            "Effect": "Allow",
            "Action": "iot:Receive",
            "Resource": "arn:aws:iot:us-east-1:123456789012:topic/building/*"
        },
        {
            "Effect": "Deny",
            "Action": "iot:Receive",
            "Resource": "arn:aws:iot:us-east-1:123456789012:topic/building/control_room/*"
        }
    ]
}
```

------

**nota**  
Essa verificação pode relatar falsos positivos. Recomendamos que você avalie todas as políticas sinalizadas e marque os recursos de falsos positivos usando supressões de auditoria.

## Como corrigir
<a name="audit-chk-iot-misconfigured-policies-how-to-fix"></a>

Essa verificação sinaliza políticas potencialmente mal configuradas, portanto, pode haver falsos positivos. Marque todos os falsos positivos usando [supressões de auditoria](audit-finding-suppressions.md) para que eles não sejam sinalizados no futuro.

Você também pode seguir estas etapas para corrigir todas as políticas que não estão em conformidade anexadas o objetos, grupos de objetos ou outras entidades:

1. Use [CreatePolicyVersion](https://docs.aws.amazon.com/iot/latest/apireference/API_CreatePolicyVersion.html) para criar uma nova versão compatível da política. Defina o sinalizador `setAsDefault` como verdadeiro. (Isso torna essa nova versão operacional para todas as entidades que usam a política.)

   Para ver exemplos de criação de políticas de AWS IoT em casos de uso comuns, consulte [exemplos de políticas de publicação/assinatura](https://docs.aws.amazon.com/iot/latest/developerguide/pub-sub-policy.html) na *Guia do desenvolvedor do AWS IoT Core*.

1. Verifique se todos os dispositivos associados podem se conectar à AWS IoT. Se um dispositivo não conseguir se conectar, use [ SetPolicyVersion](https://docs.aws.amazon.com/iot/latest/apireference/API_SetPolicyVersion.html) para reverter a política padrão para a versão anterior, revise-a e tente novamente. 

Você pode usar ações de mitigação para:
+ Aplicar a ação de mitigação `REPLACE_DEFAULT_POLICY_VERSION` em suas descobertas de auditoria para fazer essa mudança. 
+ Aplicar a ação de mitigação `PUBLISH_FINDINGS_TO_SNS` se você desejar implementar uma resposta personalizada em resposta à mensagem do Amazon SNS. 

Para obter mais informações, consulte [Ações de mitigação](dd-mitigation-actions.md). 

Use as [variáveis da política do IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/iot-policy-variables.html) no *Guia do desenvolvedor do AWS IoT Core* para fazer referência dinâmica aos recursos do AWS IoT nas suas políticas.

# O alias de perfil é excessivamente permissivo
<a name="audit-chk-iot-role-alias-permissive"></a>

O alias de perfil da AWS IoT fornece um mecanismo para dispositivos conectados serem autenticados na AWS IoT usando certificados X.509 e obterem credenciais de curta duração da AWS de um perfil do IAM associado a um alias de perfil da AWS IoT. As permissões para essas credenciais devem ser definidas com escopo usando políticas de acesso com variáveis de contexto de autenticação. Se as políticas não estiverem configuradas corretamente, você ficará exposto a um escalonamento de ataque de privilégio. Essa verificação de auditoria garante que as credenciais temporárias fornecidas pelos aliases de função da AWS IoT não sejam excessivamente permissivas. 

Essa verificação será acionada se uma das seguintes condições for encontrada:
+ A política fornece permissões administrativas para todos os serviços usados no ano passado por esse alias de função (por exemplo, “iot:\$1”, “dynamodb:\$1”, “iam:\$1” e assim por diante).
+ A política fornece amplo acesso a ações de metadados de objeto, acesso a ações restritas da AWS IoT ou amplo acesso a ações de plano de dados da AWS IoT.
+ A política fornece acesso a serviços de auditoria de segurança como “iam”, “cloudtrail”, “guardduty”, “inspector” ou “trustedadvisor”.

Essa verificação aparece como `IOT_ROLE_ALIAS_OVERLY_PERMISSIVE_CHECK` na CLI e na API.

**Gravidade:** crítica

## Detalhes
<a name="audit-chk-iot-role-alias-permissive-details"></a>

Os códigos de motivo a seguir são retornados quando essa verificação encontra uma política da IoT incompatível:
+ ALLOWS\$1BROAD\$1ACCESS\$1TO\$1USED\$1SERVICES
+ ALLOWS\$1ACCESS\$1TO\$1SECURITY\$1AUDITING\$1SERVICES
+ ALLOWS\$1BROAD\$1ACCESS\$1TO\$1IOT\$1THING\$1ADMIN\$1READ\$1ACTIONS
+ ALLOWS\$1ACCESS\$1TO\$1IOT\$1NON\$1THING\$1ADMIN\$1ACTIONS
+ ALLOWS\$1ACCESS\$1TO\$1IOT\$1THING\$1ADMIN\$1WRITE\$1ACTIONS
+ ALLOWS\$1BROAD\$1ACCESS\$1TO\$1IOT\$1DATA\$1PLANE\$1ACTIONS

## Por que isso importa?
<a name="audit-chk-iot-role-alias-permissive-why-it-matters"></a>

Ao limitar as permissões àquelas que são necessárias para que um dispositivo execute suas operações normais, você reduz os riscos para sua conta se um dispositivo estiver comprometido.

## Como corrigir
<a name="audit-chk-iot-role-alias-permissive-how-to-fix"></a>

Siga estas etapas para corrigir todas as políticas que não estão em conformidade anexadas o objetos, grupos de objetos ou outras entidades:

1. Siga as etapas em [Autorização de chamadas diretas para serviços da AWS usando o provedor de credenciais do AWS IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/authorizing-direct-aws.html) para aplicar uma política mais restritiva ao alias de seu perfil.

Você pode usar ações de mitigação para:
+ Aplique a ação de mitigação `PUBLISH_FINDINGS_TO_SNS` para implementar uma ação personalizada em resposta à mensagem do Amazon SNS. 

Para obter mais informações, consulte [Ações de mitigação](dd-mitigation-actions.md). 

# O alias de perfil permite acesso a serviços não utilizados
<a name="audit-chk-role-alias-unused-svcs"></a>

O alias de perfil da AWS IoT fornece um mecanismo para dispositivos conectados serem autenticados na AWS IoT usando certificados X.509 e obterem credenciais de curta duração da AWS de um perfil do IAM associado a um alias de perfil da AWS IoT. As permissões para essas credenciais devem ser definidas com escopo usando políticas de acesso com variáveis de contexto de autenticação. Se as políticas não estiverem configuradas corretamente, você ficará exposto a um escalonamento de ataque de privilégio. Essa verificação de auditoria garante que as credenciais temporárias fornecidas pelos aliases de função da AWS IoT não sejam excessivamente permissivas. 

Essa verificação será acionada se o alias de função tiver acesso a serviços que não foram usados para o dispositivo AWS IoT no último ano. Por exemplo, a auditoria relata se você tem um perfil do IAM vinculado ao alias de perfil que só tenha usado AWS IoT no ano passado, mas a política anexada ao perfil também concede permissão para `"iam:getRole"` e `"dynamodb:PutItem"`.

Essa verificação aparece como `IOT_ROLE_ALIAS_ALLOWS_ACCESS_TO_UNUSED_SERVICES_CHECK` na CLI e na API.

**Gravidade:** média

## Detalhes
<a name="audit-chk-role-alias-unused-svcs-details"></a>

Os códigos de motivo a seguir são retornados quando essa verificação encontra uma política de AWS IoT não compatível:
+ ALLOWS\$1ACCESS\$1TO\$1UNUSED\$1SERVICES

## Por que isso importa?
<a name="audit-chk-role-alias-unused-svcs-why-it-matters"></a>

Ao limitar as permissões aos serviços necessários para que um dispositivo execute suas operações normais, você reduz os riscos para sua conta se um dispositivo estiver comprometido.

## Como corrigir
<a name="audit-chk-role-alias-unused-svcs-how-to-fix"></a>

Siga estas etapas para corrigir todas as políticas que não estão em conformidade anexadas o objetos, grupos de objetos ou outras entidades:

1. Siga as etapas em [Autorização de chamadas diretas para serviços da AWS usando o provedor de credenciais do AWS IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/authorizing-direct-aws.html) para aplicar uma política mais restritiva ao alias de seu perfil.

Você pode usar ações de mitigação para:
+ Aplique a ação de mitigação `PUBLISH_FINDINGS_TO_SNS` para implementar uma ação personalizada em resposta à mensagem do Amazon SNS. 

Para obter mais informações, consulte [Ações de mitigação](dd-mitigation-actions.md). 

# Certificado da CA expirando
<a name="audit-chk-ca-cert-approaching-expiration"></a>

Um certificado da CA vai expirar dentro de 30 dias ou expirou.

Essa verificação aparece como `CA_CERTIFICATE_EXPIRING_CHECK` na CLI e na API.

**Gravidade:** média

## Detalhes
<a name="audit-chk-ca-cert-approaching-expiration-details"></a>

Essa verificação se aplica a certificados da CA que estão ACTIVE ou PENDING\$1TRANSFER.

Os códigos de motivo a seguir são retornados quando essa verificação encontra um certificado da CA não compatível:
+ CERTIFICATE\$1APPROACHING\$1EXPIRATION
+ CERTIFICATE\$1PAST\$1EXPIRATION

## Por que isso importa?
<a name="audit-chk-ca-cert-approaching-expiration-why-it-matters"></a>

Um certificado da CA expirado não deve ser usado para assinar novos certificados de dispositivo.

## Como corrigir
<a name="audit-chk-ca-cert-approaching-expiration-how-to-fix"></a>

Consulte as práticas recomendadas de segurança para saber como proceder. Talvez você queira:

1. Registrar um novo certificado da CA com a AWS IoT.

1. Verificar se você pode assinar certificados de dispositivo usando os novos certificados da CA.

1. Use [UpdateCACertificate](https://docs.aws.amazon.com/iot/latest/apireference/API_UpdateCACertificate.html) para marcar o certificado antigo da CA como INACTIVE no AWS IoT. Você também pode usar ações de mitigação para fazer o seguinte:
   + Aplicar a ação de mitigação `UPDATE_CA_CERTIFICATE` em suas descobertas de auditoria para fazer essa mudança. 
   + Aplicar a ação de mitigação `PUBLISH_FINDINGS_TO_SNS` se você desejar implementar uma resposta personalizada em resposta à mensagem do Amazon SNS. 

   Para obter mais informações, consulte [Ações de mitigação](dd-mitigation-actions.md). 

# IDs de cliente MQTT conflitantes
<a name="audit-chk-conflicting-client-ids"></a>

Vários dispositivos se conectam usando o mesmo ID de cliente.

Essa verificação aparece como `CONFLICTING_CLIENT_IDS_CHECK` na CLI e na API.

**Gravidade:** alta

## Detalhes
<a name="audit-chk-conflicting-client-ids-details"></a>

Várias conexões foram feitas usando o mesmo ID de cliente, fazendo com que um dispositivo já conectado seja desconectado. A especificação do MQTT permite somente uma conexão ativa por ID de cliente. Por isso, quando outro dispositivo se conecta usando o mesmo ID de cliente, ele derruba a conexão do dispositivo anterior.

Quando executada como parte de uma auditoria sob demanda, essa verificação examina como os client IDs foram usados para se conectar durante os 31 dias anteriores ao início da auditoria. Para auditorias programadas, essa verificação analisa dados da última vez em que a auditoria foi executada até o momento em que essa instância da auditoria foi iniciada. Se você tiver tomado medidas para atenuar essa condição durante a verificação, observe quando as conexões/desconexões foram estabelecidas para determinar se o problema persiste.

Os códigos de motivo a seguir são retornados quando essa verificação encontra não compatibilidade:
+ DUPLICATE\$1CLIENT\$1ID\$1ACROSS\$1CONNECTIONS

As descobertas retornadas por essa verificação também incluem o client ID usado para se conectar, IDs principais e tempos de desconexão. Os resultados mais recentes são listados primeiro.

## Por que isso importa?
<a name="audit-chk-conflicting-client-ids-why-it-matters"></a>

Os dispositivos com IDs conflitantes serão forçados a se reconectar constantemente, o que pode resultar em perda de mensagens ou incapacidade de um dispositivo de se conectar.

Isso pode indicar que um dispositivo ou credenciais de um dispositivo foram comprometidas e pode fazer parte de um ataque DDoS. Também é possível que os dispositivos não estejam configurados corretamente na conta ou que um dispositivo tenha uma conexão ruim e seja forçado a se reconectar várias vezes por minuto.

## Como corrigir
<a name="audit-chk-conflicting-client-ids-how-to-fix"></a>

Registre cada dispositivo como um objeto exclusiva na AWS IoT e use o nome do objeto como o ID de cliente para se conectar. Ou use um UUID como o ID do cliente ao se conectar ao dispositivo por MQTT. Você também pode usar ações de mitigação para:
+ Aplicar a ação de mitigação `PUBLISH_FINDINGS_TO_SNS` se você desejar implementar uma resposta personalizada em resposta à mensagem do Amazon SNS. 

Para obter mais informações, consulte [Ações de mitigação](dd-mitigation-actions.md).

# Certificado do dispositivo expirando
<a name="audit-chk-device-cert-approaching-expiration"></a>

Um certificado de dispositivo expira dentro do período limite configurado ou já expirou. O limite de verificação de expiração do certificado pode ser configurado entre 30 dias (mínimo) e 3.652 dias (10 anos, máximo) com um valor padrão de 30 dias.

Essa verificação aparece como `DEVICE_CERTIFICATE_EXPIRING_CHECK` na CLI e na API.

**Gravidade:** média

## Detalhes
<a name="audit-chk-device-cert-approaching-expiration-details"></a>

Essa verificação se aplica a certificados de dispositivo que estão ACTIVE ou PENDING\$1TRANSFER.

Os códigos de motivo a seguir são retornados quando essa verificação encontra um certificado de dispositivo não compatível:
+ CERTIFICATE\$1APPROACHING\$1EXPIRATION
+ CERTIFICATE\$1PAST\$1EXPIRATION

## Por que isso importa?
<a name="audit-chk-device-cert-approaching-expiration-why-it-matters"></a>

Um certificado de dispositivo não deve ser usado depois que ele expira.

## Configurar a verificação de expiração do certificado de dispositivo
<a name="w2aab9c11c43c13"></a>

Essa configuração permite monitorar e receber alertas para certificados que se aproximam da data de expiração em toda a frota de dispositivos. Por exemplo, se quiser receber um aviso quando os certificados estiverem a 30 dias da expiração, você poderá configurar a verificação da seguinte forma:

```
{
    "roleArn": "your-audit-role-arn",
    "auditCheckConfigurations": {
        "DEVICE_CERTIFICATE_EXPIRING_CHECK": {
            "enabled": true,
            "configuration": {
                "CERT_EXPIRATION_THRESHOLD_IN_DAYS": "30"
            }
        }
    }
}
```

## Como corrigir
<a name="audit-chk-device-cert-approaching-expiration-how-to-fix"></a>

Consulte as práticas recomendadas de segurança para saber como proceder. Talvez você queira:

1. Provisione um novo certificado e o anexe ao dispositivo. 

1. Verifique se o novo certificado é válido e se o dispositivo pode usá-lo para se conectar.

1. Use [UpdateCertificate](https://docs.aws.amazon.com/iot/latest/apireference/API_UpdateCertificate.html) para marcar o certificado antigo como INACTIVE na AWS IoT. Você também pode usar ações de mitigação para:
   + Aplicar a ação de mitigação `UPDATE_DEVICE_CERTIFICATE` em suas descobertas de auditoria para fazer essa mudança. 
   + Aplicar a ação de mitigação `ADD_THINGS_TO_THING_GROUP` para adicionar o dispositivo a um grupo, onde é possível executar uma ação sobre ele.
   + Aplicar a ação de mitigação `PUBLISH_FINDINGS_TO_SNS` se você desejar implementar uma resposta personalizada em resposta à mensagem do Amazon SNS. 

   Para obter mais informações, consulte [Ações de mitigação](dd-mitigation-actions.md). 

1. Desanexe o antigo certificado do dispositivo. (Consulte [DetachThingPrincipal](https://docs.aws.amazon.com/iot/latest/apireference/API_DetachThingPrincipal.html).)

# Verificação da idade do certificado de dispositivo
<a name="device-certificate-age-check"></a>

Essa verificação de auditoria alerta você quando um certificado de dispositivo está ativo por um número de dias maior ou igual ao número especificado. Essa verificação ajuda você com informações sobre o status dos certificados, permitindo uma ação oportuna de forma periódica, independentemente de quando o certificado atinge o fim da vida útil, melhorando a segurança ao reduzir o risco de comprometimento do certificado.

O limite de verificação de idade do certificado pode ser configurado entre 30 dias (mínimo) e 3.652 dias (10 anos, máximo), com um valor padrão de 365 dias.

Essa verificação aparece como `DEVICE_CERTIFICATE_AGE_CHECK` na CLI e na API. Essa verificação está desabilitada por padrão, com Severidade: **Baixa** 

## Detalhes
<a name="w2aab9c11c45b9"></a>

Essa verificação se aplica a certificados de dispositivo que estão ACTIVE ou PENDING\$1TRANSFER. Os códigos de motivo a seguir são retornados quando essa verificação encontra um certificado de dispositivo não compatível: 
+ CERTIFICATE\$1PAST\$1AGE\$1THRESHOLD

## Configurar a verificação de idade do certificado de dispositivo
<a name="w2aab9c11c45c11"></a>

Essa configuração permite adaptar os alertas de alternância de certificados às necessidades específicas da frota, ajudando a manter um sólido procedimento de segurança em todos os dispositivos. É possível configurar essa verificação usando a API `UpdateAccountAuditConfiguration`. Por exemplo, se quiser receber um aviso quando os certificados estiverem ativos por mais de 365 dias, você poderá configurar a verificação da seguinte forma:

```
{
    "roleArn": "your-audit-role-arn",
    "auditCheckConfigurations": {
        "DEVICE_CERTIFICATE_AGE_CHECK": {
            "enabled": true,
            "configuration": {
                "CERT_AGE_THRESHOLD_IN_DAYS": "365"
            }
        }
    }
}
```

# Certificado revogado do dispositivo ainda ativo
<a name="audit-chk-revoked-device-cert"></a>

Um certificado revogado do dispositivo ainda está ativo.

Essa verificação aparece como `REVOKED_DEVICE_CERTIFICATE_STILL_ACTIVE_CHECK` na CLI e na API.

**Gravidade:** média

## Detalhes
<a name="audit-chk-revoked-device-cert-details"></a>

Um certificado de dispositivo está na [ lista de revogação de certificados](https://en.wikipedia.org/wiki/Certificate_revocation_list), mas ainda está ativo na AWS IoT.

Essa verificação se aplica a certificados de dispositivo que estão ACTIVE ou PENDING\$1TRANSFER.

Os códigos de motivo a seguir são retornados quando essa verificação encontra não compatibilidade:
+ CERTIFICATE\$1REVOKED\$1BY\$1ISSUER

## Por que isso importa?
<a name="audit-chk-revoked-device-cert-why-it-matters"></a>

Um dispositivo de certificado, em geral, é revogado porque foi comprometido. É possível que ele ainda não tenha sido revogado na AWS IoT devido a um erro ou uma supervisão.

## Como corrigir
<a name="audit-chk-revoked-device-cert-how-to-fix"></a>

Verifique se o certificado de dispositivo não foi comprometido. Se foi, siga as práticas recomendadas de segurança para atenuar a situação. Talvez você queira:

1. Provisione um novo certificado para o dispositivo.

1. Verifique se o novo certificado é válido e se o dispositivo pode usá-lo para se conectar.

1. Use [UpdateCertificate](https://docs.aws.amazon.com/iot/latest/apireference/API_UpdateCertificate.html) para marcar o certificado antigo como REVOKED no AWS IoT. Você também pode usar ações de mitigação para:
   + Aplicar a ação de mitigação `UPDATE_DEVICE_CERTIFICATE` em suas descobertas de auditoria para fazer essa mudança. 
   + Aplicar a ação de mitigação `ADD_THINGS_TO_THING_GROUP` para adicionar o dispositivo a um grupo, onde é possível executar uma ação sobre ele.
   + Aplicar a ação de mitigação `PUBLISH_FINDINGS_TO_SNS` se você desejar implementar uma resposta personalizada em resposta à mensagem do Amazon SNS. 

   Para obter mais informações, consulte [Ações de mitigação](dd-mitigation-actions.md). 

1. Desanexe o antigo certificado do dispositivo. (Consulte [DetachThingPrincipal](https://docs.aws.amazon.com/iot/latest/apireference/API_DetachThingPrincipal.html).)

# Registro em log desabilitado
<a name="audit-chk-logging-disabled"></a>

Os logs do AWS IoT não estão habilitados no Amazon CloudWatch. Verifica o registro em log V1 e V2.

Essa verificação aparece como `LOGGING_DISABLED_CHECK` na CLI e na API.

**Gravidade:** baixa

## Detalhes
<a name="audit-chk-logging-disabled-details"></a>

Os códigos de motivo a seguir são retornados quando essa verificação encontra não compatibilidade:
+ LOGGING\$1DISABLED

## Por que isso importa?
<a name="audit-chk-logging-disabled-why-it-matters"></a>

Os logs da AWS IoT no CloudWatch fornecem visibilidade dos comportamentos da AWS IoT, incluindo falhas de autenticação e conexões e desconexões inesperadas que podem indicar que um dispositivo foi comprometido.

## Como corrigir
<a name="audit-chk-logging-disabled-how-to-fix"></a>

Ative os logs de AWS IoT no CloudWatch. Consulte [Registro em log e monitoramento](https://docs.aws.amazon.com/iot/latest/developerguide/security-logging.html) no *Guia do desenvolvedor do AWS IoT Core*. Você também pode usar ações de mitigação para:
+ Aplicar a ação de mitigação `ENABLE_IOT_LOGGING` em suas descobertas de auditoria para fazer essa mudança. 
+ Aplicar a ação de mitigação `PUBLISH_FINDINGS_TO_SNS` se você desejar implementar uma resposta personalizada em resposta à mensagem do Amazon SNS. 

Para obter mais informações, consulte [Ações de mitigação](dd-mitigation-actions.md).