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](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTCommonRequestHeaders.html) per un POST prefirmato. Amazon S3 fornisce una chiave di condizione, [S3:SignatureAge](https://docs.aws.amazon.com/AmazonS3/latest/API/bucket-policy-s3-sigv4-conditions.html), 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](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingAWSSDK.html#UsingAWSSDK-sig2-deprecation). 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:](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principaltag), come nella seguente politicaPrincipalTag, per gestire le eccezioni in modo scalabile. Altri AWS esempi, come gli [esempi di policy perimetrali dei dati di AWS](https://github.com/aws-samples/data-perimeter-policy-examples/blob/main/README.md), utilizzano questa strategia. Se implementi una politica di eccezione utilizzando`aws: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 essere](https://github.com/aws-samples/data-perimeter-policy-examples/blob/main/service_control_policies/data_perimeter_governance_scp.json) impostati. Un tag di questo tipo può anche provenire dai [tag di sessione](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html), che vengono impostati da un provider di identità (IdP) o quando vengono utilizzati. AWS STS Il controllo dell'accesso a `aws:PrincipalTag` è un argomento complesso. Tuttavia, un'organizzazione con esperienza nell'uso del [controllo degli accessi basato sugli attributi (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) 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.](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html#principal-services) [L'Appendice A](appendix-a.md) 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 (](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html)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](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html#actions-not-restricted-by-rcps). 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](https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-query-string-auth.html) POST.](https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-authentication-HTTPPOST.html) Amazon S3 supporta la negazione delle richieste in base al tipo di autenticazione tramite la chiave di condizione [S3:AuthType](https://docs.aws.amazon.com/AmazonS3/latest/API/bucket-policy-s3-sigv4-conditions.html). `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 **UploadPartCopy**API **CopyObject**and 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 **CopyObject**o l'**UploadPartCopy**API, 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'`POST`autenticazione 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 include`X-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:signatureAge`limita 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:signatureAge`non 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 soluzioni`s3: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](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_unique.html) è 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](https://docs.aws.amazon.com/AmazonS3/latest/userguide/tagging-and-policies.html). 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:](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourceaccount) o [[aws](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourceorgid): ResourceOrgPaths](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-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](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config_develop-rules.html) per implementare un [controllo investigativo o un controllo](https://docs.aws.amazon.com/prescriptive-guidance/latest/aws-security-controls/detective-controls.html) [reattivo](https://docs.aws.amazon.com/prescriptive-guidance/latest/aws-security-controls/responsive-controls.html). 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](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketTagging.html) Per mantenere il controllo sulla modalità di etichettatura di un bucket, devi limitare l'accesso a `PutBucketTagging` e [DeleteBucketTagging](https://docs.aws.amazon.com/AmazonS3/latest/API/API_DeleteBucketTagging.html).