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á.
Guardrails adicionais
Quando as solicitações pré-assinadas são usadas adequadamente pelos criadores de soluções e pelos usuários, elas fornecem um mecanismo seguro para dar aos usuários acesso aos dados. Além disso, a capacidade de gerar solicitações pré-assinadas não fornece aos diretores um acesso que eles ainda não tinham.
Nesse contexto, controles adicionais são necessários? A justificativa para controles adicionais não se baseia na necessidade de negar o acesso, mas em fornecer a capacidade de monitorar, aprovar o uso, estabelecer limites e reduzir o risco de erros do usuário. Dessa forma, você pode ajudar a garantir que o uso seja apropriado e necessário.
As grades de proteção a seguir ajudam você a atingir esse objetivo. Antes de ativar esses controles, talvez você queira determinar o uso existente identificando solicitações pré-assinadas. Essa identificação ajuda você a se preparar para o impacto da grade de proteção no uso existente ou a planejar exceções quando necessário.
Guardrail para S3: SignatureAge
Uma característica definidora das solicitações pré-assinadas é que elas descrevem um prazo de expiração. A assinatura da solicitação contém uma data. Essa data é transmitida como um parâmetro de sequência de caracteres de X-Amz-Date consulta para URLs pré-assinados e como um cabeçalho de data ou x-amz-date para um POST pré-assinado.
O Amazon S3 fornece uma chave de condição, S3:SignatureAge, que você pode usar para limitar o tempo máximo entre a data de assinatura e a expiração efetiva da solicitação. Essa condição nunca pode aumentar o período de validade, mas pode reduzi-lo.
Na política a seguir, a chave de s3:signatureAge condição limita as solicitações pré-assinadas a 15 minutos de validade. Todos os exemplos a seguir usam 15 minutos para limitar a validade a um período de tempo semelhante ao suportado pela assinatura padrão.
A segunda declaração da política nega qualquer acesso ao Signature Version 2. Essa versão do protocolo de assinatura está sendo descontinuada, mas ainda é suportada em alguns. Regiões da AWS Recomendamos que você o bloqueie explicitamente antes que seja totalmente descontinuado.
Você pode aplicar a política a seguir como uma política AWS Organizations de controle de serviço (SCP). Os usuários ainda podem usar solicitações pré-assinadas e implantar soluções que dependam dessas solicitações, desde que o tempo entre a geração e o uso da assinatura seja inferior a 15 minutos. Dependendo da implementação, essa limitação pode não ter impacto, pode fazer com que uma solução se torne inutilizável ou pode causar falhas ocasionais que podem ser repetidas.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyPresignedOver15Minutes", "Effect": "Deny", "Action": "s3:*", "Resource": "*", "Condition": { "NumericGreaterThan": { "s3:signatureAge": "900000" } } }, { "Sid": "DenySignatureVersion2", "Effect": "Deny", "Action": "s3:*", "Resource": "*", "Condition": { "StringEquals": { "s3:signatureversion": "AWS" } } } ] }
Exceções
Se uma solução precisar de mais tempo antes da expiração e, portanto, for afetada pela política anterior, recomendamos que você forneça um método para aprovar exceções. Para evitar enumerar exceções em um SCP, use aws:, como na política a seguirPrincipalTag, para gerenciar exceções de forma escalável. Outros AWS exemplos, como os exemplos de políticas de perímetro de dados da AWS
Se você implementar uma política de exceção usandoaws:PrincipalTag, deverá controlar o acesso à configuração de tags nos principais. Tags desse tipo podem vir diretamente dos principais e podem ser controladas por um SCP, como neste exemplo de controle de quais valores de tag podem ser definidosaws:PrincipalTag é um tópico complexo. No entanto, uma organização com experiência no uso do controle de acesso baseado em atributos (ABAC) terá a experiência e os controles necessários para permitir o uso adequado desse caso de aws:PrincipalTag uso.
No exemplo a seguir, a aws:PrincipalTag condição cria uma exceção que permite que qualquer principal com a tag nomeada (long-presigned-allowed) seja atribuída e definida comotrue. Com essa exceção, a restrição de idade da assinatura não é aplicada.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyPresignedOver15Minutes", "Effect": "Deny", "Action": "s3:*", "Resource": "*", "Condition": { "NumericGreaterThan": { "s3:signatureAge": "900000" }, "StringNotEquals": { "aws:PrincipalTag/long-presigned-allowed": "true" } } } ] }
Políticas de buckets
Você pode aplicar políticas de bucket a todos ou a alguns buckets usando uma política como no exemplo a seguir. Ao contrário de um SCP, uma política de bucket também visa o uso principal do serviço. O Apêndice A não documenta nenhum uso esperado do principal serviço de solicitações pré-assinadas, mas se você quisesse implementar um controle para provar esse limite, a política a seguir forneceria esse controle. Além disso, diferentemente de um SCP, uma política de bucket pode ser aplicada aos diretores em sua conta de gerenciamento.
ABAC-based as exceções funcionam nas políticas de bucket da mesma forma que um SCP. Uma meta de uma política de compartimento pode ser a aplicação a diretores fora da organização, portanto, as exceções do ABAC devem ser restritas aos diretores aos quais os controles do ABAC se aplicam.
No exemplo a seguir, a aws:PrincipalTag condição na primeira instrução cria uma exceção para um principal com a tag nomeada (long-presigned-allowed) atribuída e definida comotrue. Com essa exceção, a restrição de idade da assinatura não é aplicada. A segunda declaração aplica essa restrição a todos os diretores fora da AWS
organização proprietária do bucket. O escopo dessa segunda declaração deve corresponder aos controles ABAC para definir a tag nomeada para os principais.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyPresignedOver15MinWithExceptions", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::{bucket-name}/*", "Condition": { "NumericGreaterThan": { "s3:signatureAge": "900000" }, "StringNotEquals": { "aws:PrincipalTag/long-presigned-allowed": "true" } } }, { "Sid": "DenyPresignedOver15MinutesOutsideOrg", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::{bucket-name}/*", "Condition": { "NumericGreaterThan": { "s3:signatureAge": "900000" }, "StringNotEquals": { "aws:PrincipalOrgID": "${aws:ResourceOrgID}" } } } ] }
Políticas de controle de recursos
Você pode aplicar uma política a buckets em grande escala usando políticas de controle de recursos (RCPs). Assim como os SCPs e, diferentemente das políticas de bucket, os RCPs não visam o uso principal do serviço. Os RCPs afetam diretores que não prestam serviços em nenhuma conta, mas não afetam os recursos na conta de gerenciamento. Para obter mais informações, consulte a documentação do AWS Organizations.
Assim como acontece com as políticas de bucket, se você usa aws:PrincipalTags para criar exceções para entidades principais, tenha em mente o escopo dos controles ABAC sobre a marcação de entidades principais.
O RCP a seguir restringe o uso de URL pré-assinado em todos os buckets do S3 em uma organização, limitando a duração da assinatura a 15 minutos.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyPresignedOver15MinWithExceptions", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::*/*", "Condition": { "NumericGreaterThan": { "s3:signatureAge": "900000" }, "StringNotEquals": { "aws:PrincipalTag/long-presigned-allowed": "true", } } }, { "Sid": "DenyPresignedOver15MinutesOutsideOrg", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::*/*", "Condition": { "NumericGreaterThan": { "s3:signatureAge": "900000" }, "StringNotEquals": { "aws:PrincipalOrgID": "${aws:ResourceOrgID}" } } } ] }
Guardrail para S3:AuthType
URLs pré-assinados usam autenticação de sequência de caracteres de consulta, e POSTs pré-assinados sempre usam autenticação POST. O Amazon S3 suporta a negação de solicitações com base no tipo de autenticação por meio da chave de condição s3:AuthType. REST-QUERY-STRINGé o s3:authType valor para cadeias de caracteres de consulta e POST é o s3:authType valor para POST.
Você pode aplicar a política a seguir como SCP. A política é usada s3:authType para permitir somente a autenticação baseada em cabeçalho. Ele também configura um método para fornecer exceções a usuários ou funções individuais.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyNonHeaderAuth", "Effect": "Deny", "Action": "s3:*", "Resource": "*", "Condition": { "StringNotEquals": { "s3:authType": "REST-HEADER", "aws:PrincipalTag/non-header-auth-allowed": "true" } } } ] }
Negar solicitações com base no tipo de autenticação afeta qualquer solução ou recurso que use o tipo de autenticação negada. Por exemplo, negar REST-QUERY-STRING impede que os usuários realizem uploads ou downloads a partir do console Amazon S3. Se você quiser que os usuários usem o console do Amazon S3, não use essa grade de proteção nem faça uma exceção para os usuários. Por outro lado, se você não quiser que os usuários usem o console Amazon S3, você pode negar REST-QUERY-STRING para os usuários.
Talvez você já negue aos usuários acesso direto aos recursos do Amazon S3. Nesse caso, uma grade de proteção para o tipo de autenticação é redundante. No entanto, uma declaração de s3:authType negação fornece uma utilidade de defesa profunda porque as implementações para negar acesso direto geralmente abrangem muitas instruções de controle, algumas com exceções.
As funções usadas para cargas de trabalho normalmente não precisam de acesso à sequência de caracteres de consulta ou à POST autenticação. As exceções são funções que oferecem suporte a serviços projetados para usar solicitações pré-assinadas. Você pode criar exceções específicas para essas funções.
Você também pode aplicar uma política de bucket a todos ou a alguns buckets usando uma política como a seguinte:
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyNonHeaderAuth", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::{bucket-name}/*", "Condition": { "StringNotEquals": { "s3:authType": "REST-HEADER", "aws:PrincipalTag/non-header-auth-allowed": "true" } } } ] }
Essa política de bucket tem o efeito de negar o uso das UploadPartCopyAPIs CopyObjecte para fazer cópias entre regiões. A replicação do Amazon S3 não é afetada porque não depende dessas APIs.
Se você quiser usar uma política de bucket, como a política anterior, e ainda oferecer suporte à UploadPartCopyAPI CopyObjectou Cross-region, adicione uma condição aws:ViaAWSService semelhante à seguinte:
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyNonHeaderAuth", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::{bucket-name}/*", "Condition": { "StringNotEquals": { "s3:authType": "REST-HEADER", "aws:PrincipalTag/non-header-auth-allowed": "true" }, "Bool": { "aws:ViaAWSService": "false" }, } } ] }
Combinando grades de proteção pré-assinadas e exceções a outras grades de proteção
Se você não planeja aplicar uma barreira de proteção em geral aos seus usuários e funções, convém aplicá-la às exceções de outras grades de proteção comuns, para que essas exceções não suportem solicitações pré-assinadas.
Se você tem restrições de rede, mas permite exceções para parceiros externos ou casos de uso especiais, bloqueie a sequência de caracteres de consulta ou a POST autenticação quando essas exceções forem aplicadas, a menos que elas sejam especificamente identificadas como obrigatórias.
Limitações do S3: SignatureAge
Os administradores acharão útil entender s3:signatureAge mais detalhadamente as implicações de. Cada solicitação assinada incluiX-Amz-Date, o que deve indicar a hora atual. Esse valor é preenchido pelo cliente e pelo signatário da solicitação. AWS rejeita solicitações que considere ter horários inválidos. No entanto, um signatário pode gerar assinaturas com antecedência em um horário futuro. O Amazon S3 rejeita solicitações que especificam um horário futuro se forem enviadas com muita antecedência. No entanto, se a solicitação não for enviada até o momento em que você fizer login na assinatura, a assinatura poderá ser gerada mais cedo e enviada posteriormente.
s3:signatureAgelimita a idade máxima X-Amz-Date de uma assinatura somente para solicitações pré-assinadas. Solicitações maiores que a idade especificada são negadas, mesmo que a expiração X-Amz-Expires ou uma POST política a tenha declarado válida. s3:signatureAgenão altera o período válido para solicitações que não incluem uma expiração explícita. Também não controla o valor X-Amz-Date que um cliente usa para uma assinatura.
Se o relógio do sistema estiver errado ou se um cliente solicitar intencionalmente datas futuras, a hora assinada pode não ser a hora em que a assinatura foi gerada. Isso limita o quanto as soluções s3:signatureAge podem controlar. Uma solução que usa a hora atual ao gerar assinaturas é limitada da maneira esperada: as assinaturas permanecem válidas pelo número de milissegundos especificado em. s3:signatureAge Uma solução que não usa a hora atual terá limites diferentes. Uma restrição é que as credenciais usadas para assinar a assinatura ainda devem ser válidas. Como administrador, você pode controlar a validade máxima das credenciais temporárias emitidas. Você pode permitir que as credenciais sejam válidas por até 36 horas ou restringir a validade a até 15 minutos. A expiração das credenciais temporárias não depende do valor deX-Amz-Date.
As credenciais permanentes não têm essa restrição. Usar somente credenciais temporárias é uma prática recomendada, e você pode revogar explicitamente qualquer credencial permanente, o que também invalidaria qualquer assinatura com base nessa credencial.
Embora s3:signatureAge seja medido em milissegundos, não é prático configurá-lo para menos de 60 segundos, mesmo se você tiver um relógio bem sincronizado e baixa latência de uso. Configurações com menos de 60 segundos correm o risco de rejeitar solicitações válidas. Se você espera atrasos entre a geração da assinatura e o envio da solicitação, ou problemas com a sincronização do relógio, considere esses atrasos no gerenciamento de. s3:signatureAge
Segmentação de buckets em grande escala
SCPs e RCPs podem ser usados aws:PrincipalTag para fazer exceções para os usuários. Você não pode usar tags em um bucket para controlar o acesso por meio de aws:ResourceTag ― somente tags de objeto são usadas para controle de acesso. Geralmente, não é escalável adicionar uma tag a cada objeto ao qual você deseja aplicar esse controle.
Uma solução adequada para muitos casos de uso é aplicar a política e a exceção no nível da conta, alterando as contas às quais o SCP ou o RCP se aplicam ou usando aws: ResourceAccount, aws: ResourceOrgPaths ou aws: ResourceOrg ID. Por exemplo, um SCP ou RCP pode ser aplicado a um conjunto de contas de produção.
Outra solução é usar uma AWS Config regra personalizada para implementar um controle de detetive ou controle responsivo. A meta seria que cada bucket contivesse uma política de bucket com a proteção apropriada. Além de testar o conteúdo de uma política de intervalo, a AWS Config regra personalizada pode recuperar as tags do intervalo e excluir o intervalo da regra se o intervalo estiver marcado com um valor específico. Se essa regra falhar na verificação de conformidade, ela poderá marcar o bucket como não compatível ou invocar uma remediação para adicionar a proteção à política do bucket.
nota
Você não pode restringir o conteúdo da tag das solicitações PutBucketTagginga. Para manter o controle sobre como um bucket é marcado, você deve limitar o acesso a PutBucketTagging DeleteBucketTagginge.
