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

Práticas recomendadas fundamentais

As melhores práticas gerais que são controles eficazes para outras solicitações de AWS API também se aplicam às solicitações pré-assinadas. Esta seção analisa duas das práticas mais relevantes: privilégios mínimos e perímetros de dados. Essas práticas criam uma profundidade de controles que outras práticas ampliam.

Aplicação do princípio de privilégio mínimo

A primeira etapa para limitar o uso de solicitações pré-assinadas é limitar o acesso ao Amazon S3 em geral. Um URL pré-assinado não pode fornecer acesso a recursos que não foram concedidos ao principal que gerou a assinatura do URL pré-assinado. Também não pode fornecer acesso a um recurso de uma forma que não tenha sido concedida a esse diretor. Dessa forma, aplicar as melhores práticas para conceder a esses diretores o mínimo de privilégio é uma barreira eficaz.

O processo de criação de uma URL pré-assinada é uma operação algorítmica baseada em um padrão publicado (Signature Version 4) para geração de assinaturas. Portanto, não é possível colocar limites na geração de URLs pré-assinados. No entanto, para ser relevante, um URL pré-assinado deve ser válido e fornecer acesso aos recursos, portanto, a validade de um URL pré-assinado também é uma barreira eficaz.

Para obter mais informações sobre privilégios mínimos, consulte Conceder acesso com privilégios mínimos no pilar AWS Well-Architected Estrutura, Segurança.

Implemente um perímetro de dados

Uma extensão de menor privilégio é manter um perímetro de dados consistente com as necessidades da sua organização. Os URLs pré-assinados são compatíveis com os perímetros de dados. Assim como em outras solicitações, a validade de uma solicitação de URL pré-assinada é avaliada no momento da solicitação. Se as propriedades da rede, do recurso, da sessão de função e do principal mudarem, elas serão avaliadas no momento e usando o método pelo qual a solicitação é recebida.

Por exemplo, digamos que um serviço executado em um contêiner do Amazon Elastic Kubernetes Service (Amazon EKS) assine uma solicitação. Posteriormente, a solicitação é enviada do sistema de computador pessoal do usuário conectado à Internet. Nesse caso, a SourceIp condição aws: avalia o endereço IP público visível da solicitação do sistema pessoal do usuário, não o endereço IP do serviço no contêiner Amazon EKS.

Da mesma forma, se as tags do principal ou do recurso mudarem antes do envio da solicitação, os valores atualizados, não originais, serão aplicados à solicitação por meio das ResourceTag/tag-key condições aws: PrincipalTag/tag-key e aws:.