Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Guardrail aggiuntivi
Quando le richieste predefinite vengono utilizzate in modo appropriato dai costruttori di soluzioni e dagli utenti, forniscono un meccanismo sicuro per consentire agli utenti di accedere ai dati. Inoltre, la capacità di generare richieste prefirmate non fornisce ai mandanti un accesso che non avevano già.
In tale contesto, sono necessari controlli aggiuntivi? La giustificazione dei controlli aggiuntivi non si basa sulla necessità di negare l'accesso, ma di fornire la possibilità di monitorare, approvare l'utilizzo e stabilire limiti e ridurre il rischio di errori degli utenti. In questo modo puoi contribuire a garantire che l'utilizzo sia appropriato e necessario.
I seguenti guardrail ti aiutano a raggiungere questo obiettivo. Prima di abilitare questi controlli, potresti voler determinare l'utilizzo esistente identificando le richieste predefinite. Questa identificazione aiuta a prepararsi all'impatto del guardrail sull'utilizzo esistente o a pianificare le eccezioni laddove necessario.
Guardrail per S3:SignatureAge
Una caratteristica distintiva delle richieste predefinite è che descrivono un tempo di scadenza. La firma della richiesta contiene una data. Questa data viene trasmessa come parametro della stringa di X-Amz-Date query per i valori predefiniti e come data o x-amz-date intestazione per i POST URLs prefirmati.
Amazon S3 fornisce una chiave di condizione, S3:SignatureAge, che puoi utilizzare per limitare il tempo massimo tra la data di firma e la scadenza effettiva della richiesta. Questa condizione non può mai aumentare il periodo di validità, ma può ridurlo.
Nella seguente politica, la chiave s3:signatureAge condizionale limita le richieste predefinite a 15 minuti di validità. Gli esempi seguenti utilizzano tutti 15 minuti per limitare la validità a un intervallo di tempo simile a quello supportato dalla firma standard.
La seconda dichiarazione della policy nega qualsiasi accesso a Signature Version 2. Questa versione del protocollo di firma è obsoleta, ma in alcuni è ancora supportata. Regioni AWS Ti consigliamo di bloccarlo esplicitamente prima che diventi completamente obsoleto.
È possibile applicare la seguente politica come politica di controllo del AWS Organizations servizio (SCP). Gli utenti possono comunque utilizzare richieste predefinite e implementare soluzioni che dipendono da tali richieste, purché il tempo tra la generazione della firma e l'utilizzo sia inferiore a 15 minuti. A seconda dell'implementazione, questa limitazione potrebbe non avere alcun impatto, potrebbe rendere la soluzione inutilizzabile o causare errori occasionali che possono essere riprovati.
{ "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" } } } ] }
Eccezioni
Se una soluzione richiede più tempo prima della scadenza ed è quindi influenzata dalla politica precedente, si consiglia di fornire un metodo per approvare le eccezioni. Per evitare di enumerare le eccezioni in un SCP, usa aws:, come nella seguente politicaPrincipalTag, per gestire le eccezioni in modo scalabile. Altri AWS esempi, come gli esempi di policy perimetrali dei dati di AWS
Se implementi una politica di eccezione utilizzandoaws:PrincipalTag, devi controllare l'accesso all'impostazione dei tag sui principali. I tag di questo tipo possono provenire direttamente dai principali e possono essere controllati da un SCP, come in questo esempio di controllo dei valori dei tag che possono essereaws:PrincipalTag è un argomento complesso. Tuttavia, un'organizzazione con esperienza nell'uso del controllo degli accessi basato sugli attributi (ABAC) disporrà dell'esperienza e dei controlli necessari per consentirne l'uso appropriato aws:PrincipalTag per questo caso d'uso.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyPresignedOver15Minutes", "Effect": "Deny", "Action": "s3:*", "Resource": "*", "Condition": { "NumericGreaterThan": { "s3:signatureAge": "900000" }, --- Example exception --- "StringNotEquals": { "aws:PrincipalTag/long-presigned-allowed": "true" } --- Example exception end --- } } ] }
Policy di bucket
È possibile applicare le policy dei bucket a tutti i bucket o a determinati bucket utilizzando una policy come nell'esempio seguente. A differenza di una SCP, una policy bucket riguarda anche l'utilizzo principale del servizio. L'Appendice A non documenta l'utilizzo previsto del principale servizio da parte delle richieste predefinite, ma se si volesse implementare un controllo per dimostrare tale limite, la seguente politica fornirebbe tale controllo. Inoltre, a differenza di un SCP, ai responsabili del tuo account di gestione può applicarsi una policy relativa ai bucket. Le eccezioni basate su ABAC funzionano nelle bucket policy allo stesso modo di un SCP.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyPresignedOver15Minutes", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::{bucket-name}/*", "Condition": { "NumericGreaterThan": { "s3:signatureAge": "900000" }, --- Example exception --- "StringNotEquals": { "aws:PrincipalTag/long-presigned-allowed": "true" } --- Example exception end --- } } ] }
Guardrail per S3:AuthType
I predefiniti URLs utilizzano l'autenticazione tramite stringa di query e i predefiniti POSTs utilizzano sempre l'autenticazione POST. Amazon S3 supporta la negazione delle richieste in base al tipo di autenticazione tramite la chiave di condizione S3:AuthType. REST-QUERY-STRINGè il s3:authType valore per le stringhe di query ed POST è il valore per POST. s3:authType
È possibile applicare la seguente politica come SCP. La policy consente solo s3:authType l'autenticazione basata sull'intestazione. Configura inoltre un metodo per fornire eccezioni a singoli utenti o ruoli.
{ "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" } } } ] }
Il rifiuto delle richieste in base al tipo di autenticazione influisce su qualsiasi soluzione o funzionalità che utilizza il tipo di autenticazione negata. Ad esempio, la negazione REST-QUERY-STRING impedisce agli utenti di eseguire caricamenti o download dalla console Amazon S3. Se desideri che gli utenti utilizzino la console Amazon S3, non utilizzare questo guardrail o fai un'eccezione per gli utenti. D'altra parte, se non desideri che gli utenti utilizzino la console Amazon S3, puoi REST-QUERY-STRING negarla agli utenti.
Forse stai già negando agli utenti l'accesso diretto alle risorse di Amazon S3. In questo caso, un guardrail per il tipo di autenticazione è ridondante. Tuttavia, un'istruzione s3:authType deny è defense-in-depth utile perché le implementazioni per negare l'accesso diretto di solito riguardano molte istruzioni di controllo, alcune con eccezioni.
I ruoli utilizzati per i carichi di lavoro in genere non richiedono l'accesso alla stringa di query o all'autenticazione. POST Le eccezioni sono ruoli che supportano servizi progettati per utilizzare richieste predefinite. È possibile creare eccezioni specifiche per tali ruoli.
È inoltre possibile applicare una policy sui bucket a tutti i bucket o a determinati bucket utilizzando una politica come la seguente:
{ "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" } } } ] }
Questa policy bucket ha l'effetto di negare l'uso di CopyObjecte di creare copie interregionali UploadPartCopy APIs . La replica di Amazon S3 non è interessata perché non si basa su questi elementi. APIs
Se desideri utilizzare una policy bucket come quella precedente e continuare a supportare la policy interregionale CopyObjecto l'UploadPartCopyAPI, aggiungi una condizione simile alla aws:ViaAWSService seguente:
{ "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" }, } } ] }
Combinazione di guardrail ed eccezioni predefiniti con altri guardrail
Se non intendi applicare un guardrail in generale ai tuoi utenti e ruoli, potresti volerlo applicare alle eccezioni di altri guardrail comuni, in modo che tali eccezioni non supportino le richieste predefinite.
Se hai restrizioni di rete ma consenti eccezioni per partner esterni o casi d'uso speciali, dovresti bloccare la stringa di query o l'POSTautenticazione quando vengono applicate tali eccezioni, a meno che non siano specificamente identificate come obbligatorie.
Limitazioni a S3:SignatureAge
Gli amministratori troveranno utile comprendere in modo più completo le implicazioni di. s3:signatureAge Ogni richiesta firmata includeX-Amz-Date, che dovrebbe indicare l'ora corrente. Questo valore viene inserito dal cliente e dal firmatario della richiesta. AWS rifiuta le richieste che ritiene abbiano orari non validi. Tuttavia, un firmatario potrebbe generare firme in anticipo in un momento futuro. Amazon S3 rifiuta le richieste che specificano un orario futuro se vengono inviate con troppo anticipo. Tuttavia, se la richiesta non viene inviata fino al momento in cui viene apposta la firma, la firma potrebbe essere generata prima e inviata successivamente.
s3:signatureAgelimita l'età massima di registrazione X-Amz-Date di una firma solo per le richieste predefinite. Le richieste più vecchie dell'età specificata vengono rifiutate, anche se la scadenza X-Amz-Expires o una POST politica le avrebbe dichiarate valide. s3:signatureAgenon modifica il periodo di validità per le richieste che non includono una scadenza esplicita. Inoltre, non controlla il valore utilizzato da un client per la firma. X-Amz-Date
Se l'orologio di sistema è sbagliato o se un client richiede intenzionalmente date future, l'ora firmata potrebbe non essere l'ora in cui è stata generata la firma. Ciò limita la capacità di controllo delle soluzionis3:signatureAge. Una soluzione che utilizza l'ora corrente per generare le firme è limitata nel modo previsto: le firme rimangono valide per il numero di millisecondi specificato in. s3:signatureAge Una soluzione che non utilizza l'ora corrente avrà limiti diversi. Una restrizione è che le credenziali utilizzate per firmare la firma devono essere ancora valide. In qualità di amministratore, puoi controllare la validità massima delle credenziali temporanee emesse. Puoi consentire che le credenziali siano valide per un massimo di 36 ore o limitarne la validità a un massimo di 15 minuti. La scadenza delle credenziali temporanee non dipende dal valore di. X-Amz-Date
Le credenziali permanenti non hanno questa restrizione. Utilizzare solo credenziali temporanee è una procedura consigliata e puoi revocare esplicitamente qualsiasi credenziale permanente, il che invaliderebbe anche tutte le firme basate su tali credenziali.
Sebbene s3:signatureAge sia misurato in millisecondi, non è pratico impostarlo su un valore inferiore a 60 secondi, anche se si dispone di un orologio ben sincronizzato e di un utilizzo a bassa latenza. Le impostazioni inferiori a 60 secondi comportano il rischio di rifiutare richieste valide. Se si prevedono ritardi tra la generazione della firma e l'invio della richiesta o problemi con la sincronizzazione dell'orologio, è necessario tenerne conto nella gestione di. s3:signatureAge
Indirizzare i bucket su larga scala
SCPs può essere utilizzato aws:PrincipalTag per creare eccezioni per gli utenti. Non è possibile utilizzare i tag su un bucket per controllare l'accesso tramite aws:ResourceTag ― solo i tag degli oggetti vengono utilizzati per il controllo degli accessi. In genere non è scalabile aggiungere un tag a ogni oggetto a cui si desidera applicare questo controllo.
Una soluzione adatta a molti casi d'uso consiste nell'applicare la policy e l'eccezione a livello di account, modificando gli account a cui si applica l'SCP o utilizzando aws: ResourceAccount, aws: ResourceOrgPaths o aws: ResourceOrg ID. Ad esempio, un SCP potrebbe essere applicato a un set di account di produzione.
Un'altra soluzione consiste nell'utilizzare una AWS Config regola personalizzata per implementare un controllo investigativo o un controllo reattivo. L'obiettivo sarebbe che ogni bucket contenga una policy sui bucket con il guardrail appropriato. Oltre a testare il contenuto di una bucket policy, la AWS Config regola personalizzata può recuperare i tag dal bucket ed escludere il bucket dalla regola se il bucket è etichettato con un valore specifico. Se tale regola non supera il controllo di conformità, potrebbe contrassegnare il bucket come non conforme o richiamare una correzione per aggiungere il guardrail alla policy del bucket.
Nota
Non puoi limitare il contenuto dei tag delle richieste a. PutBucketTagging Per mantenere il controllo sulla modalità di etichettatura di un bucket, devi limitare l'accesso a PutBucketTagging e DeleteBucketTagging.
