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à.
Le migliori pratiche di base
Le best practice generali che costituiscono controlli efficaci per altre richieste AWS API si applicano anche alle richieste predefinite. Questa sezione esamina due delle pratiche più rilevanti: i privilegi minimi e i perimetri dei dati. Queste pratiche creano una profondità di controlli che altre pratiche estendono.
Applica il principio del privilegio minimo
Il primo passo per limitare l'uso di richieste predefinite consiste nel limitare l'accesso ad Amazon S3 in generale. Un URL predefinito non può fornire l'accesso a risorse che non sono state concesse al principale che ha generato la firma per l'URL predefinito. Né può fornire l'accesso a una risorsa in un modo che non è stato concesso a tale principale. Pertanto, applicare le migliori pratiche per concedere a tali committenti il minimo privilegio è un'efficace barriera.
Il processo di creazione di un URL predefinito è un'operazione algoritmica basata su uno standard pubblicato (Signature Version 4) per la generazione di firme. Pertanto, non è possibile porre limiti alla generazione di URL predefiniti. Tuttavia, per essere pertinente, un URL predefinito deve essere valido e consentire l'accesso alle risorse, quindi la validità di un URL predefinito è anche un efficace guardrail.
Per ulteriori informazioni sui privilegi minimi, consulta Garantire l'accesso con privilegi minimi nel pilastro Framework, Security. AWS Well-Architected
Implementa un perimetro di dati
Un'estensione del privilegio minimo consiste nel mantenere un perimetro di dati coerente con le esigenze dell'organizzazione. Gli URL predefiniti sono compatibili con i perimetri dei dati. Come per le altre richieste, la validità di una richiesta URL predefinita viene valutata al momento della richiesta. Se le proprietà della rete, della risorsa, della sessione di ruolo e del principale cambiano, vengono valutate nel momento e utilizzando il metodo con cui viene ricevuta la richiesta.
Ad esempio, supponiamo che un servizio in esecuzione in un container Amazon Elastic Kubernetes Service (Amazon EKS) firmi una richiesta. La richiesta viene successivamente inviata dal sistema di personal computer dell'utente connesso a Internet. In questo caso, la SourceIp condizione aws: valuta l'indirizzo IP pubblico visibile della richiesta dal sistema personale dell'utente, non l'indirizzo IP del servizio nel contenitore Amazon EKS.
Allo stesso modo, se i tag del principale o della risorsa cambiano prima dell'invio della richiesta, i valori aggiornati, non originali, verranno applicati alla richiesta tramite le ResourceTag/tag-key condizioni aws: PrincipalTag/tag-key e aws:.
