Panoramica degli URL predefiniti - AWS Guida prescrittiva

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à.

Panoramica degli URL predefiniti

Un URL predefinito è un tipo di richiesta HTTP riconosciuta dal servizio AWS Identity and Access Management (IAM). Ciò che differenzia questo tipo di richiesta da tutte le altre AWS richieste è il parametro di query X-Amz-Expires. Come per le altre richieste autenticate, le richieste URL prefirmate includono una firma. Per le richieste URL prefirmate, questa firma viene trasmessa in. X-Amz-Signature La firma utilizza le operazioni crittografiche Signature Version 4 per codificare tutti gli altri parametri della richiesta.

Note

Il X-Amz-Expires parametro consente di elaborare una firma come valida con una deviazione maggiore dalla data e ora codificata. Altri aspetti della validità della firma vengono ancora valutati. Le credenziali di firma, se temporanee, non devono essere scadute al momento dell'elaborazione della firma. Le credenziali di firma devono essere allegate a un principale IAM che disponga di un'autorizzazione sufficiente al momento dell'elaborazione.

Gli URL prefirmati sono un sottoinsieme di richieste prefirmate

Un URL predefinito non è l'unico metodo per firmare una richiesta per un periodo futuro. Amazon S3 supporta anche le richieste POST, anch'esse generalmente predefinite. Una firma POST predefinita consente caricamenti conformi a una politica firmata e ha una data di scadenza incorporata in tale politica.

Le firme per le richieste possono avere date future, sebbene ciò non sia comune. Finché le credenziali sottostanti sono valide, l'algoritmo di firma non proibisce appuntamenti futuri. Tuttavia, queste richieste non possono essere elaborate con successo fino alla loro finestra temporale valida, il che rende impraticabili le datazioni future per la maggior parte dei casi d'uso.

Cosa consente una richiesta predefinita?

Una richiesta prefirmata può consentire solo azioni consentite dalle credenziali utilizzate per firmare la richiesta. Se le credenziali negano in modo implicito o esplicito l'azione specificata dalla richiesta prefirmata, la richiesta prefirmata viene rifiutata al momento dell'invio. Questo vale per quanto segue:

  • Politiche di sessione associate alle credenziali

  • Politiche associate al principale associato alle credenziali

  • Politiche relative alle risorse che influiscono sulla sessione o sul principale

  • Politiche di controllo del servizio che influiscono sulla sessione o sul principale

Motivazioni per l'utilizzo di richieste predefinite

In qualità di ingegnere della sicurezza, dovresti essere consapevole di ciò che spinge i costruttori di soluzioni a utilizzare URL predefiniti. Comprendere cosa è necessario e cosa è facoltativo ti aiuterà a comunicare con i costruttori di soluzioni. Le motivazioni potrebbero includere quanto segue:

  • Supportare un meccanismo di autenticazione non IAM beneficiando al contempo della scalabilità in Amazon S3. Una delle motivazioni principali è comunicare direttamente con Amazon S3 per beneficiare della scalabilità integrata fornita da questo servizio. Senza questa comunicazione diretta, una soluzione dovrebbe supportare il carico derivante dalla ritrasmissione dei byte inviati e delle chiamate. PutObjectGetObject A seconda del carico totale, questo requisito aggiunge sfide di scalabilità che un costruttore di soluzioni potrebbe voler evitare.

    Altri mezzi di comunicazione diretta con Amazon S3, come l'utilizzo di credenziali temporanee AWS Security Token Service nelle firme AWS STS() o Signature Version 4 al di fuori degli URL, potrebbero non essere appropriati per il tuo caso d'uso. Amazon S3 identifica gli utenti tramite AWS credenziali, mentre le richieste predefinite presuppongono l'identificazione tramite meccanismi diversi dalle credenziali. AWS Colmare questa differenza mantenendo al contempo la comunicazione diretta dei dati è possibile tramite richieste predefinite.

  • Per trarre vantaggio dalla comprensione nativa degli URL da parte di un browser. Gli URL sono compresi dai browser, mentre AWS STS le credenziali e le firme Signature Version 4 non lo sono. Ciò è utile durante l'integrazione con soluzioni basate su browser. Le soluzioni alternative richiedono più codice, utilizzeranno più memoria per file di grandi dimensioni e potrebbero essere trattate in modo diverso da estensioni come malware e antivirus.

Confronto con credenziali temporanee AWS STS

Le credenziali temporanee sono simili alle richieste prefirmate. Entrambi scadono, consentono l'ambito di accesso e vengono comunemente utilizzati per collegare credenziali non IAM a utilizzi che richiedono credenziali AWS. 

È possibile limitare strettamente l'ambito di una AWS STS credenziale temporanea a un singolo oggetto e azione S3, ma ciò può comportare problemi di scalabilità perché le API hanno dei limiti. AWS STS (Per ulteriori informazioni, consulta l'articolo Come posso risolvere gli errori di limitazione delle API o «Frequenza superata» per IAM e AWS STS sul sito Web AWS re:post.) Inoltre, ogni credenziale generata richiede una chiamata AWS STS API, che aggiunge latenza e una nuova dipendenza che potrebbe influire sulla resilienza. Una AWS STS credenziale temporanea ha anche una scadenza minima di 15 minuti, mentre una richiesta predefinita può supportare durate più brevi (60 secondi sono pratici nelle giuste condizioni).

Confronto con soluzioni basate esclusivamente sulla firma

L'unico componente intrinsecamente segreto di una richiesta prefirmata è la firma Signature Version 4. Se un cliente conosce gli altri dettagli di una richiesta e gli viene fornita una firma valida che corrisponde a tali dettagli, può inviare una richiesta valida. Senza una firma valida, non può.

Gli URL predefiniti e le soluzioni basate solo sulla firma sono crittograficamente simili. Tuttavia, le soluzioni basate sulla sola firma presentano vantaggi pratici, come la possibilità di utilizzare un'intestazione HTTP anziché un parametro di stringa di query per trasmettere la firma (vedere la sezione Interazioni e mitigazioni della registrazione). Gli amministratori devono inoltre considerare che le stringhe di query vengono trattate più comunemente come metadati, mentre le intestazioni vengono trattate meno comunemente come tali.

D'altra parte, gli AWS SDK forniscono meno supporto per la generazione e l'utilizzo diretto delle firme. La creazione di una soluzione basata esclusivamente sulle firme richiede più codice personalizzato. Da un punto di vista pratico, l'utilizzo di librerie anziché codice personalizzato per motivi di sicurezza è una best practice generale, pertanto il codice per le soluzioni basate esclusivamente sulla firma richiede un esame più approfondito.

Le soluzioni basate esclusivamente sulla firma non utilizzano la stringa di X-Amz-Expires query e non forniscono un periodo di validità esplicito. IAM gestisce i periodi di validità implicita delle firme che non hanno un orario di scadenza esplicito. Questi periodi impliciti non vengono pubblicati. In genere non cambiano, ma vengono gestiti pensando alla sicurezza, quindi non dovresti dipendere dai periodi di validità. Esiste un compromesso tra il controllo esplicito sulla data di scadenza e la gestione della scadenza da parte di IAM.

In qualità di amministratore, potresti preferire una soluzione basata esclusivamente sulla firma. Tuttavia, in senso pratico, dovrai supportare le soluzioni così come sono state create.