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 creatori 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 sulla necessità 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 gli URL prefirmati e come intestazione Date o x-amz-date per un POST prefirmato.
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 inutilizzabile una soluzione 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.
Nell'esempio seguente, la aws:PrincipalTag condizione crea un'eccezione che consente a qualsiasi principale con il tag denominato (long-presigned-allowed) assegnato e impostato su. true Con questa eccezione, la restrizione sull'età della firma non viene applicata.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyPresignedOver15Minutes", "Effect": "Deny", "Action": "s3:*", "Resource": "*", "Condition": { "NumericGreaterThan": { "s3:signatureAge": "900000" }, "StringNotEquals": { "aws:PrincipalTag/long-presigned-allowed": "true" } } } ] }
Policy di bucket
È possibile applicare le policy relative ai 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.
ABAC-based le eccezioni funzionano nelle policy bucket allo stesso modo di un SCP. L'obiettivo di una bucket policy potrebbe essere quello di applicarsi ai responsabili esterni all'organizzazione, quindi le eccezioni ABAC dovrebbero essere limitate ai principi per i quali si applicano i controlli ABAC.
Nell'esempio seguente, la aws:PrincipalTag condizione della prima istruzione crea un'eccezione per un principale con il tag named () assegnato e impostato su. long-presigned-allowed true Con questa eccezione, la restrizione sull'età della firma non viene applicata. La seconda dichiarazione applica questa restrizione a tutti i responsabili esterni all' AWS
organizzazione proprietaria del bucket. L'ambito di questa seconda istruzione deve corrispondere ai controlli ABAC per impostare il tag denominato per i principali.
{ "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}" } } } ] }
Politiche di controllo delle risorse
È possibile applicare una policy ai bucket su larga scala utilizzando le politiche di controllo delle risorse (RCP). Analogamente agli SCP e a differenza delle policy relative ai bucket, gli RCP non riguardano l'utilizzo principale del servizio. Gli RCP influiscono sui principali non di servizio di qualsiasi account, ma non influiscono sulle risorse dell'account di gestione. Per ulteriori informazioni, consulta la documentazione relativa ad AWS Organizations.
Come per le policy bucket, se utilizzate aws:PrincipalTags per creare eccezioni per i principali, tenete presente l'ambito dei controlli ABAC sull'etichettatura dei principali.
Il seguente RCP limita l'utilizzo degli URL predefiniti in tutti i bucket S3 di un'organizzazione limitando la durata della firma a 15 minuti.
{ "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 per S3:AuthType
Gli URL prefirmati utilizzano l'autenticazione della stringa di query e i POST prefirmati 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 fornisce un'utilità di difesa approfondita 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 delle UploadPartCopyAPI CopyObjectand per creare copie tra regioni diverse. La replica di Amazon S3 non è interessata perché non si basa su queste API.
Se desideri utilizzare una policy bucket come quella precedente e continuare a supportare la policy interregionale CopyObjecto l'UploadPartCopyAPI, aggiungi una condizione simile alla seguente: aws:ViaAWSService
{ "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 in modo esplicito 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
Gli SCP e gli RCP possono essere utilizzati aws:PrincipalTag per creare eccezioni per gli utenti. Non è possibile utilizzare i tag su un bucket per controllare l'accesso tramite aws:ResourceTag ― per il controllo degli accessi vengono utilizzati solo i tag degli oggetti. 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 SCP o RCP o utilizzando aws:ResourceAccount, aws: o aws: ResourceOrgPaths ID. ResourceOrg Ad esempio, un SCP o RCP 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.
