

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

# Perguntas frequentes
<a name="faq"></a>

## Uma solicitação pré-assinada pode ser usada várias vezes? Isso é um risco de segurança?
<a name="faq1"></a>

Sim, uma assinatura em uma solicitação pré-assinada pode ser usada mais de uma vez. Se isso é um risco de segurança é uma questão contextual. Outros métodos de acesso aos serviços da AWS também permitem a repetição. Um usuário ou carga de trabalho com AWS credenciais pode enviar muitas solicitações para Serviços da AWS, e qualquer uma dessas solicitações pode ser duplicada.

Se seu caso de uso exigir uma única execução, você deverá implementar outros mecanismos para impor o uso único. O uso único não é um recurso de solicitações pré-assinadas. Como engenheiro de segurança, você deve analisar os casos de uso e as implementações, mas, em muitos casos, o uso múltiplo é adequado para uso aceitável.

## Alguém que não seja o usuário pretendido pode usar uma solicitação pré-assinada?
<a name="faq2"></a>

Uma assinatura em uma solicitação pré-assinada pode ser enviada por qualquer pessoa que a possua. Ele será aceito somente se passar por outras formas de validação, como [controles de perímetro de dados](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/building-a-data-perimeter-on-aws.html). Se a assinatura tiver expirado, as credenciais de assinatura expirarem ou as credenciais de assinatura não tiverem acesso aos recursos solicitados, a solicitação será negada.

O mesmo vale para outros métodos de autenticação com Serviços da AWS. Credenciais compartilhadas de forma inadequada permitem acesso inadequado. A melhor prática básica é compartilhar credenciais e assinaturas somente com o público-alvo. Se você não pode confiar em seu público-alvo para manter os dados privados seguros e não compartilhá-los com outras pessoas, isso prejudicará qualquer forma de autenticação.

## Um usuário autorizado pode usar uma solicitação pré-assinada para exfiltrar dados?
<a name="faq3"></a>

Proteger os dados exige uma ação robusta. Permitir o acesso para os fins pretendidos e, ao mesmo tempo, manter um perímetro de dados requer uma abordagem abrangente. [Acesso com privilégios mínimos, [controles de perímetro de dados](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/building-a-data-perimeter-on-aws.html) e [uso somente de credenciais de acesso temporário são as](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_unique.html) melhores práticas gerais que se aplicam à proteção](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_permissions_least_privileges.html) de dados. O uso adequado desses controles também limita a capacidade dos usuários de realizar ações por meio das solicitações pré-assinadas que eles geram.

Isso ocorre porque o acesso fornecido por uma solicitação pré-assinada é um subconjunto do acesso concedido às credenciais usadas para assinar a solicitação. Nesse contexto, as melhores práticas que se aplicam ao acesso aos dados geralmente se aplicam às solicitações pré-assinadas, mas as solicitações pré-assinadas não criam novos acessos aos dados. 
+ A expiração máxima é limitada à expiração das credenciais de assinatura. Se as credenciais de assinatura forem revogadas, as assinaturas baseadas nas credenciais não serão mais válidas.
+ Se as permissões para o principal do IAM associadas às credenciais de assinatura não incluírem a execução da ação associada à solicitação pré-assinada, invocar uma solicitação pré-assinada resultará em uma resposta de “acesso negado”. A resposta depende do estado atual das permissões no momento da invocação, que não tem relação com o momento em que a assinatura da solicitação pré-assinada foi gerada. 
+ [As propriedades do principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principal-properties) são avaliadas com base no principal associado às credenciais de assinatura. 
+ [As propriedades de uma sessão de função](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-role-session-properties) são avaliadas com base na sessão de função associada às credenciais de assinatura.
+ [As propriedades da rede](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-network-properties) são avaliadas com base em como a solicitação foi recebida, como acontece com as solicitações normais. 

Nesse contexto, o exame dos riscos associados às solicitações pré-assinadas é restrito às áreas em que elas são assinadas com credenciais diferentes das credenciais do usuário e fornecem acesso que não fazia parte do principal do usuário. Esse exame deve ser aplicado ao design do serviço, à carga de trabalho ou à solução que gera assinaturas em nome do usuário, em vez do próprio recurso de solicitação pré-assinada.

## Posso negar o acesso de um URL pré-assinado se eu suspeitar que ele foi compartilhado de forma não autorizada?
<a name="faq4"></a>

Sim. Isso requer a invalidação das credenciais com as quais o URL foi assinado. Há várias maneiras de fazer isso:
+ Remova as permissões do diretor do IAM ao qual as credenciais pertencem. Se esse diretor do IAM não tiver mais acesso ao recurso e à operação para os quais o URL está assinado, o URL não poderá executar essa operação. Isso afeta todo o uso correspondente desse principal do IAM.
+ Se as credenciais usadas para assinar o URL forem temporárias, você poderá [revogar AWS STS as permissões de sessão para credenciais temporárias emitidas antes de um horário específico para o diretor do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html#revoke-session-policy). Dependendo do caso de uso, pode haver outras sessões válidas que sejam invalidadas antes do prazo normal de expiração, mas as novas sessões não serão afetadas. A revogação das permissões da sessão também invalida todas as URLs que foram assinadas usando credenciais associadas a essas sessões, mas as novas URLs associadas às novas sessões não serão afetadas.
+ Se as credenciais usadas para assinar o URL forem permanentes, [desative](https://docs.aws.amazon.com/cli/latest/reference/iam/update-access-key.html) a chave de acesso. Isso afeta todo o uso vinculado a essas credenciais.