Prevenção contra o ataque do “substituto confuso” em todos os serviços - AWS IoT Core

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á.

Prevenção contra o ataque do “substituto confuso” em todos os serviços

O problema “confused deputy” é um problema de segurança em que uma entidade que não tem permissão para executar uma ação pode coagir uma entidade mais privilegiada a executá-la. Em AWS, a falsificação de identidade entre serviços pode resultar no problema confuso do deputado. A personificação entre serviços pode ocorrer quando um serviço (o serviço de chamada) chama outro serviço (o serviço chamado). O serviço de chamada pode ser manipulado de modo a usar suas permissões para atuar nos recursos de outro cliente de uma forma na qual ele não deveria ter permissão para acessar. Para evitar isso, AWS fornece ferramentas que ajudam você a proteger seus dados para todos os serviços com diretores de serviços que receberam acesso aos recursos em sua conta.

Para limitar as permissões que AWS IoT fornece outro serviço ao recurso. Recomendamos usar as chaves de contexto de condição aws:SourceAccountglobal aws:SourceArne as chaves de contexto nas políticas de recursos. 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.

A maneira mais eficaz de se proteger contra o confuso problema do deputado é usar a chave de contexto de condição aws:SourceArn global com o nome de recurso da Amazon completo (ARN) do recurso. Para AWS IoT, você aws:SourceArn deve estar em conformidade com o formato: arn:aws:iot:region:account-id:resource-type/resource-id para permissões específicas de recursos ouarn:aws:iot:region:account-id:*. O resource-id pode ser o nome ou ID do recurso permitido ou uma declaração curinga do recurso permitido. IDs Certifique-se de que o region combina com o seu AWS IoT Região e o account-id corresponde ao ID da sua conta de cliente.

O exemplo a seguir mostra como evitar o confuso problema auxiliar usando as chaves de contexto de condição aws:SourceAccount global aws:SourceArn e no AWS IoT política de confiança da função. Para obter mais exemplos, consulte Exemplos detalhados de prevenção policial confusa.

{ "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Principal":{ "Service":"iot.amazonaws.com" }, "Action":"sts:AssumeRole", "Condition":{ "StringEquals":{ "aws:SourceAccount":"123456789012" }, "ArnLike":{ "aws:SourceArn":"arn:aws:iot:us-east-1:123456789012:*" } } } ] }
nota

Se você receber erros de negação de acesso, pode ser porque a integração do serviço com AWS O Security Token Service (STS) não oferece suporte às chaves de aws:SourceAccount contexto aws:SourceArn e.

Exemplos detalhados de prevenção policial confusa

Esta seção fornece exemplos detalhados de como evitar o confuso problema auxiliar usando as chaves de contexto de condição aws:SourceAccount global aws:SourceArn e as chaves de contexto no AWS IoT política de confiança da função.

Provisionamento de frota

Você pode configurar o aprovisionamento da frota usando um recurso de modelo de aprovisionamento. Quando um modelo de aprovisionamento faz referência a uma função de aprovisionamento, a política de confiança dessa função pode incluir as aws:SourceArn chaves de condição e. aws:SourceAccount Essas chaves limitam os recursos para os quais a configuração pode invocar a sts:AssumeRole solicitação.

A função com a política de confiança a seguir só pode ser assumida pelo principal de IoT (iot.amazonaws.com) para o modelo de provisionamento especificado no. SourceArn

{ "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Principal":{ "Service":"iot.amazonaws.com" }, "Action":"sts:AssumeRole", "Condition":{ "StringEquals":{ "aws:SourceAccount":"123456789012" }, "ArnLike":{ "aws:SourceArn":"arn:aws:iot:us-east-1:123456789012:provisioningtemplate/example_template" } } } ] }

JITP

Em just-in-time provisioning (JITP), você pode usar o modelo de provisionamento como um recurso separado da CA ou definir o corpo do modelo e a função como parte da configuração do certificado da CA. O valor de aws:SourceArn no AWS IoT a política de confiança da função depende de como você define o modelo de provisionamento.

Se você definir seu modelo de provisionamento como um recurso separado, o valor de aws:SourceArn pode ser. "arn:aws:iot:region:account-id:provisioningtemplate/example_template" Você pode usar o mesmo exemplo de política emProvisionamento de frota.

Se você definir seu modelo de aprovisionamento em um recurso de certificado da CA, o valor de aws:SourceArn pode ser "arn:aws:iot:region:account-id:cacert/cert_id" ou. "arn:aws:iot:region:account-id:cacert/*" Você pode usar um caractere curinga quando o identificador do recurso, como a ID de um certificado de CA, é desconhecido no momento da criação.

A função com a seguinte política de confiança só pode ser assumida pelo principal de IoT (iot.amazonaws.com) para o certificado CA especificado no. SourceArn

{ "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Principal":{ "Service":"iot.amazonaws.com" }, "Action":"sts:AssumeRole", "Condition":{ "StringEquals":{ "aws:SourceAccount":"123456789012" }, "ArnLike":{ "aws:SourceArn":"arn:aws:iot:us-east-1:123456789012:cacert/8ecde6884f3d87b1125ba31ac3fcb13d7016de7f57cc904fe1cb97c6ae98196e" } } } ] }

Ao criar um certificado de CA, você pode referenciar uma função de aprovisionamento na configuração do registro. A política de confiança da função de provisionamento pode ser usada aws:SourceArn para restringir para quais recursos a função pode ser assumida. No entanto, durante a egisterCACertificate chamada R inicial para registrar o certificado CA, você não teria o ARN certificado CA para especificar na aws:SourceArn condição.

Para contornar isso, ou seja, especificar a política de confiança da função de aprovisionamento para o certificado CA específico registrado com AWS IoT Core, você pode fazer o seguinte:

  • Primeiro, chame R egisterCACertificate sem fornecer o RegistrationConfig parâmetro.

  • Depois que o certificado CA for registrado com AWS IoT Core, ligue para você pdateCACertificate sobre isso.

    Na pdateCACertificate chamada U, forneça uma RegistrationConfig que inclua a política de confiança da função de provisionamento aws:SourceArn definida como a ARN do certificado CA recém-registrado.

Provedor de credencial

Para AWS IoT Core provedor de credenciais, use o mesmo Conta da AWS você usa para criar o alias de função em aws:SourceAccount e especificar uma instrução que corresponda ao recurso do tipo ARN de recurso rolealias em. aws:SourceArn Ao criar uma IAM função para uso com AWS IoT Core provedor de credenciais, você deve incluir na aws:SourceArn condição qualquer alias ARNs de função que possa precisar assumir a função, autorizando assim a solicitação entre serviços. sts:AssumeRole

A função com a seguinte política de confiança só pode ser assumida pelo diretor da AWS IoT Core provedor de credencial (credentials.iot.amazonaws.com) para o roleAlias especificado noSourceArn. Se um principal tentar recuperar as credenciais de um alias de função diferente do especificado na aws:SourceArn condição, a solicitação será negada, mesmo que esse outro alias de função faça referência à mesma função. IAM

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "credentials.iot.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "123456789012" }, "ArnLike": { "aws:SourceArn": "arn:aws:iot:us-east-1:123456789012:rolealias/example_rolealias" } } } ] }