Registrando interações e mitigações

Um URL pré-assinado contém uma assinatura e pode ser usado, durante o período anterior à expiração, para realizar a operação de API específica para a qual foi assinado. Ela deve ser tratada como uma credencial de acesso temporário. A assinatura deve permanecer privada somente para as partes que precisam conhecê-la. Na maioria dos ambientes, é o cliente que envia a solicitação e o servidor que a recebe. Enviar a assinatura como parte de uma sessão HTTPS direta mantém sua natureza privada, pois somente um participante da sessão HTTPS tem visibilidade do URI que transmite a assinatura.

Para pré-assinado URLs, a assinatura é transmitida como o parâmetro da sequência de caracteres de X-Amz-Signature consulta. Os parâmetros da sequência de caracteres de consulta são um componente de um URI. O risco é que os clientes possam registrar o URI e a assinatura com ele. Os clientes têm acesso a toda a solicitação HTTP e podem registrar qualquer parte da solicitação, dos dados e dos cabeçalhos (incluindo cabeçalhos de autenticação). No entanto, isso é, por convenção, menos comum. O registro de URI é mais comum e é necessário em casos como o registro de acesso. Os clientes devem usar redação ou mascaramento para remover a assinatura antes do registro. URIs

Em alguns ambientes, os usuários permitem que intermediários (proxies) tenham visibilidade em suas sessões HTTPS. A habilitação de proxies requer um alto nível de acesso privilegiado aos sistemas clientes, pois eles exigem configuração e certificados confiáveis. A instalação da configuração de proxy e certificados confiáveis, dentro do contexto local do ambiente intermediário do cliente, permite um nível muito alto de privilégio. Por esse motivo, o acesso a esses intermediários deve ser rigorosamente controlado.

O objetivo de um intermediário geralmente é bloquear saídas indesejadas e rastrear outras saídas. Dessa forma, é comum que esses intermediários registrem solicitações. Embora os intermediários possam, como os clientes, registrar qualquer conteúdo, cabeçalho e dados (todos os quais seriam muito confidenciais), é mais comum que eles registrem URIs, como aqueles que incluem o parâmetro da sequência de caracteres de X-Amz-Signature consulta.

Mitigações

Recomendamos que o registro de URI redija o parâmetro da sequência de caracteres de X-Amz-Signature consulta, redija toda a sequência de caracteres de consulta ou trate as informações como altamente confidenciais, como acontece com o acesso direto ao servidor intermediário. Embora essas proteções sejam altamente recomendadas, o fato de as assinaturas pré-assinadas URLs expirarem reduz os riscos de exposição do registro, desde que a exposição seja adiada por tempo suficiente para que as assinaturas expirem.

O Amazon S3 também vê as assinaturas e deve tratá-las adequadamente. Os logs de acesso ao servidor Amazon S3 incluem o URI da solicitação, mas o editam conforme recomendadoX-Amz-Signature. O mesmo acontece quando CloudTrail os eventos de dados são registrados para o Amazon S3. Você pode configurar o Amazon CloudWatch Logs para mascarar dados usando identificadores de dados personalizados.

A expressão regular a seguir corresponde à X-Amz-Signature que aparece em um URI:

X-Amz-Signature=[a-f0-9]{64}

A expressão regular a seguir adiciona padrões de agrupamento para identificar o texto a ser substituído mais especificamente:

(?:X-Amz-Signature=)([a-f0-9]{64})

Se você tiver uma entrada de registro de acesso como a seguinte:

X-Amz-Signature=733255ef022bec3f2a8701cd61d4b371f3f28c9f193a1f02279211d48d5193d7

A primeira expressão regular traduz a entrada do registro de acesso em:

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 

A segunda expressão regular, em sistemas que oferecem suporte a grupos sem captura, traduz a entrada do registro de acesso em:

X-Amz-Signature=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX