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
Uma solicitação pré-assinada pode ser usada várias vezes? Isso é um risco de seguranç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?
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. 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?
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 e uso somente de credenciais de acesso temporário são as melhores práticas gerais que se aplicam à proteção 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 são avaliadas com base no principal associado às credenciais de assinatura.
-
As propriedades de uma sessão de função são avaliadas com base na sessão de função associada às credenciais de assinatura.
-
As propriedades da rede 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?
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. 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 a chave de acesso. Isso afeta todo o uso vinculado a essas credenciais.
