Visão geral dos URLs pré-assinados

Uma URL pré-assinada é um tipo de solicitação HTTP reconhecida pelo serviço AWS Identity and Access Management (IAM). O que diferencia esse tipo de solicitação de todas as outras AWS solicitações é o parâmetro de consulta X-Amz-Expires. Assim como em outras solicitações autenticadas, as solicitações de URL pré-assinadas incluem uma assinatura. Para solicitações de URL pré-assinadas, essa assinatura é transmitida emX-Amz-Signature. A assinatura usa operações criptográficas do Signature Version 4 para codificar todos os outros parâmetros da solicitação.

Observações

• A versão 2 do Signature está atualmente em processo de descontinuação, mas ainda é suportada em alguns. Regiões da AWS Este guia se aplica à assinatura do Signature versão 4.

• O serviço de recebimento pode processar cabeçalhos não assinados, mas o suporte para essa opção é limitado e direcionado, de acordo com as melhores práticas. Salvo indicação em contrário, suponha que todos os cabeçalhos devem ser assinados para que uma solicitação seja aceita.

O X-Amz-Expires parâmetro permite que uma assinatura seja processada como válida com um desvio maior da data e hora codificada. Outros aspectos da validade da assinatura ainda são avaliados. As credenciais de assinatura, se temporárias, não devem expirar no momento em que a assinatura é processada. As credenciais de assinatura devem ser anexadas a um diretor do IAM que tenha autorização suficiente no momento do processamento.

Os URLs pré-assinados são um subconjunto de solicitações pré-assinadas.

Um URL pré-assinado não é o único método para assinar uma solicitação para um horário futuro. O Amazon S3 também oferece suporte a solicitações POST, que geralmente também são pré-assinadas. Uma assinatura POST pré-assinada permite uploads que estejam em conformidade com uma política assinada e tenham uma data de expiração incorporada a essa política.

As assinaturas de solicitações podem ter data futura, embora isso seja incomum. Desde que as credenciais subjacentes sejam válidas, o algoritmo de assinatura não proíbe futuros encontros. Contudo, essas solicitações não podem ser processadas com sucesso até a janela de tempo válida, o que torna o future dating impraticável para a maioria dos casos de uso.

O que uma solicitação pré-assinada permite?

Uma solicitação pré-assinada só pode permitir ações permitidas pelas credenciais usadas para assinar a solicitação. Se as credenciais negarem implícita ou explicitamente a ação especificada pela solicitação pré-assinada, a solicitação pré-assinada será negada quando for enviada. Isso se aplica ao seguinte:

• Políticas de sessão associadas às credenciais

• Políticas associadas ao diretor associado às credenciais

• Políticas de recursos que afetam a sessão ou o diretor

• Políticas de controle de serviço que afetam a sessão ou o diretor

Motivações para usar solicitações pré-assinadas

Como engenheiro de segurança, você deve estar ciente do que motiva os criadores de soluções a usar URLs pré-assinados. Entender o que é necessário e o que é opcional ajudará você a se comunicar com os criadores de soluções. As motivações podem incluir o seguinte:

• Para oferecer suporte a um mecanismo de autenticação não IAM e, ao mesmo tempo, se beneficiar da escalabilidade no Amazon S3. A principal motivação é comunicar-se diretamente com o Amazon S3 para se beneficiar da escalabilidade integrada fornecida por esse serviço. Sem essa comunicação direta, uma solução precisaria suportar a carga de retransmissão de bytes enviados PutObjecte GetObjectchamadas. Dependendo da carga total, esse requisito adiciona desafios de escalabilidade que um criador de soluções pode querer evitar.

  Outros meios de comunicação direta com o Amazon S3, como usar credenciais temporárias AWS Security Token Service em AWS STS() ou assinaturas Signature Version 4 fora dos URLs, podem não ser apropriados para seu caso de uso. O Amazon S3 identifica os usuários por meio de AWS credenciais, enquanto as solicitações pré-assinadas presumem a identificação por meio de mecanismos que não sejam credenciais. AWS É possível superar essa diferença e, ao mesmo tempo, manter a comunicação direta dos dados por meio de solicitações pré-assinadas.

• Para se beneficiar da compreensão nativa de URLs de um navegador. Os URLs são compreendidos pelos navegadores, enquanto AWS STS as credenciais e as assinaturas do Signature Version 4 não são. Isso é benéfico na integração com soluções baseadas em navegador. Soluções alternativas exigem mais código, usam mais memória para arquivos grandes e podem ser tratadas de forma diferente por extensões, como verificadores de malware e vírus.

Comparação com AWS STS credenciais temporárias

As credenciais temporárias são semelhantes às solicitações pré-assinadas. Ambos expiram, permitem o escopo do acesso e são comumente usados para vincular credenciais não IAM a um uso que requer credenciais da AWS. 

Você pode definir um escopo rigoroso de uma AWS STS credencial temporária para um único objeto e ação do S3, mas isso pode resultar em desafios de escalabilidade, pois as AWS STS APIs têm limites. (Para obter mais informações, consulte o artigo Como posso resolver erros de limitação de API ou de “Taxa excedida” para IAM e AWS STS no site AWS re:POST.) Além disso, cada credencial gerada exige uma chamada de AWS STS API, o que adiciona latência e uma nova dependência que pode afetar a resiliência. Uma AWS STS credencial temporária também tem um tempo mínimo de expiração de 15 minutos, enquanto uma solicitação pré-assinada pode suportar durações mais curtas. (60 segundos são práticos, dadas as condições certas).

Comparação com soluções somente com assinatura

O único componente inerentemente secreto de uma solicitação pré-assinada é sua assinatura Signature Version 4. Se um cliente souber os outros detalhes de uma solicitação e receber uma assinatura válida que corresponda a esses detalhes, ele poderá enviar uma solicitação válida. Sem uma assinatura válida, não é possível.

URLs pré-assinados e soluções somente com assinatura são criptograficamente similares. No entanto, as soluções somente com assinatura têm vantagens práticas, como a capacidade de usar um cabeçalho HTTP em vez de um parâmetro de sequência de caracteres de consulta para transmitir a assinatura (consulte a seção Interações e mitigações de registros). Os administradores também devem considerar que as cadeias de caracteres de consulta são mais comumente tratadas como metadados, enquanto os cabeçalhos são menos comumente tratados como tal.

Por outro lado, AWS os SDKs oferecem menos suporte para gerar e usar assinaturas diretamente. A criação de uma solução somente com assinatura requer mais código personalizado. Do ponto de vista prático, usar bibliotecas em vez de código personalizado para fins de segurança é uma prática recomendada geral, portanto, o código para soluções somente de assinatura exige um exame mais minucioso.

As soluções somente de assinatura não usam a sequência de caracteres de X-Amz-Expires consulta e não fornecem um período de validade explícito. O IAM gerencia os períodos de validade implícita das assinaturas que não têm um prazo de expiração explícito. Esses períodos implícitos não são publicados. Normalmente, eles não mudam, mas são gerenciados pensando na segurança, portanto, você não deve depender dos períodos de validade. Há uma compensação entre ter controle explícito sobre a data de expiração e fazer com que o IAM gerencie a expiração.

Como administrador, talvez você prefira uma solução somente com assinatura. No entanto, em um sentido prático, você precisará oferecer suporte às soluções criadas.