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

# Configurazione dell’accesso sicuro e restrizione dell’accesso ai contenuti
<a name="SecurityAndPrivateContent"></a>

CloudFront offre diverse opzioni per proteggere i contenuti che fornisce. Di seguito sono riportati alcuni metodi che è possibile utilizzare CloudFront per proteggere e limitare l'accesso ai contenuti:
+ Configurazione di connessioni HTTPS.
+ Impedire agli utenti in località geografiche specifiche di accedere ai contenuti
+ Richiedi agli utenti di accedere ai contenuti utilizzando cookie CloudFront firmati URLs o firmati
+ Impostare la crittografia a livello di campo per campi di contenuti specifici
+  AWS WAF Utilizzalo per controllare l'accesso ai tuoi contenuti

È inoltre necessario implementare un'architettura DDo S-resiliente per l'infrastruttura e le applicazioni. Per ulteriori informazioni, consulta [AWS Best Practices for DDo S](https://docs.aws.amazon.com/whitepapers/latest/aws-best-practices-ddos-resiliency/aws-best-practices-ddos-resiliency.html) Resiliency.

Per ulteriori informazioni, consulta la seguente documentazione:
+ [Proteggi la distribuzione dei contenuti con CloudFront](https://aws.amazon.com/cloudfront/security/)
+ [SIEM su Amazon Service OpenSearch ](https://github.com/aws-samples/siem-on-amazon-opensearch-service/blob/main/README.md)

**Topics**
+ [

# Usa HTTPS con CloudFront
](using-https.md)
+ [

# Utilizzo di nomi di dominio alternativi e HTTPS
](using-https-alternate-domain-names.md)
+ [

# Autenticazione TLS reciproca con CloudFront (Viewer mTLS)
](mtls-authentication.md)
+ [

# Origin Mutual TLS con CloudFront
](origin-mtls-authentication.md)
+ [

# Offri contenuti privati con cookie firmati URLs e firmati
](PrivateContent.md)
+ [

# Limita l'accesso a un' AWS origine
](private-content-restricting-access-to-origin.md)
+ [

# Limitazione dell’accesso ad Application Load Balancer
](restrict-access-to-load-balancer.md)
+ [

# Limitazione della distribuzione geografica del contenuto
](georestrictions.md)
+ [

# Utilizzo della crittografia a livello di campo per la protezione dei dati sensibili
](field-level-encryption.md)

# Usa HTTPS con CloudFront
<a name="using-https"></a>

Puoi configurare CloudFront in modo che gli spettatori utilizzino HTTPS in modo che le connessioni siano crittografate quando CloudFront comunicano con gli spettatori. Puoi anche configurare l'utilizzo CloudFront di HTTPS con la tua origine in modo che le connessioni siano crittografate quando CloudFront comunica con la tua origine.

Se configuri CloudFront in modo da richiedere HTTPS sia per comunicare con gli spettatori sia per comunicare con l'origine, ecco cosa succede quando si CloudFront riceve una richiesta:

1. Un visualizzatore invia una richiesta HTTPS a. CloudFront C'è qualche SSL/TLS negoziazione qui tra lo spettatore e. CloudFront Alla fine, il visualizzatore invia la richiesta in formato crittografato.

1. Se la CloudFront edge location contiene una risposta memorizzata nella cache, CloudFront crittografa la risposta e la restituisce al visualizzatore, che la decrittografa.

1. Se l' CloudFront edge location non contiene una risposta memorizzata nella cache, CloudFront esegue la negoziazione SSL/TLS con l'origine e, una volta completata la negoziazione, inoltra la richiesta all'origine in un formato crittografato.

1. L'origine decrittografa la richiesta, la elabora (genera una risposta), crittografa la risposta e restituisce la risposta a. CloudFront

1. CloudFront decrittografa la risposta, la cripta nuovamente e la inoltra al visualizzatore. CloudFrontmemorizza inoltre nella cache la risposta nell'edge location in modo che sia disponibile la prossima volta che viene richiesta.

1. Il visualizzatore decripta la risposta.

Il processo funziona fondamentalmente allo stesso modo indipendentemente dal fatto che l'origine sia un bucket Amazon S3 o un'origine personalizzata come un server HTTP/S. MediaStore

**Nota**  
Per contribuire a contrastare gli attacchi di tipo SSL, non supporta la rinegoziazione per le richieste di visualizzazione e origine. CloudFront 

In alternativa, puoi attivare l'autenticazione reciproca per la tua distribuzione. CloudFront Per ulteriori informazioni, consulta [Autenticazione TLS reciproca con CloudFront (Viewer mTLS)Origin Mutual TLS con CloudFront](mtls-authentication.md).

Per informazioni su come richiedere l'HTTPS tra i visualizzatori e tra i CloudFront destinatari CloudFront e tra i destinatari, consulta i seguenti argomenti.

**Topics**
+ [Richiedi HTTPS tra i visualizzatori e CloudFront](using-https-viewers-to-cloudfront.md)
+ [Richiesta di HTTPS a un’origine personalizzata](using-https-cloudfront-to-custom-origin.md)
+ [Richiesta di HTTPS a un’origine Amazon S3](using-https-cloudfront-to-s3-origin.md)
+ [

# Protocolli e cifrari supportati tra visualizzatori e CloudFront
](secure-connections-supported-viewer-protocols-ciphers.md)
+ [

# Protocolli e cifrari supportati tra e l'origine CloudFront
](secure-connections-supported-ciphers-cloudfront-to-origin.md)

# Richiedi HTTPS per la comunicazione tra gli spettatori e CloudFront
<a name="using-https-viewers-to-cloudfront"></a>

Puoi configurare uno o più comportamenti della cache nella tua CloudFront distribuzione per richiedere HTTPS per la comunicazione tra i visualizzatori e. CloudFront Puoi anche configurare uno o più comportamenti della cache per consentire sia HTTP che HTTPS, in modo che sia CloudFront necessario HTTPS per alcuni oggetti ma non per altri. I passaggi di configurazione dipendono dal nome di dominio che stai utilizzando nell'oggetto URLs:
+ Se utilizzi il nome di dominio CloudFront assegnato alla tua distribuzione, ad esempio d111111abcdef8.cloudfront.net, modifichi l'impostazione della **Viewer Protocol Policy per uno o più comportamenti della cache in modo da richiedere** la comunicazione HTTPS. In CloudFront tale configurazione, fornisce il certificato. SSL/TLS 

  Per modificare il valore di **Viewer Protocol Policy** utilizzando la CloudFront console, consulta la procedura riportata più avanti in questa sezione.

  Per informazioni su come utilizzare l' CloudFront API per modificare il valore dell'`ViewerProtocolPolicy`elemento, consulta [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)*Amazon CloudFront API Reference*.
+ Se utilizzi il tuo nome di dominio, ad esempio example.com, devi modificare diverse impostazioni CloudFront. È inoltre necessario utilizzare un SSL/TLS certificato fornito da AWS Certificate Manager (ACM) o importare un certificato da un'autorità di certificazione di terze parti in ACM o nell'archivio certificati IAM. Per ulteriori informazioni, consulta [Utilizzo di nomi di dominio alternativi e HTTPS](using-https-alternate-domain-names.md).

**Nota**  
Se vuoi assicurarti che gli oggetti da cui gli utenti ottengono i dati siano CloudFront crittografati quando li CloudFront hai ottenuti dall'origine, utilizza sempre il protocollo HTTPS tra l'origine CloudFront e l'origine. Se di recente sei passato da HTTP a HTTPS tra CloudFront e l'origine, ti consigliamo di invalidare gli oggetti nelle CloudFront edge location. CloudFront restituirà un oggetto a un visualizzatore indipendentemente dal fatto che il protocollo utilizzato dal visualizzatore (HTTP o HTTPS) corrisponda al protocollo CloudFront utilizzato per ottenere l'oggetto. Per ulteriori informazioni su come rimuovere o sostituire gli oggetti in una distribuzione, vedi [Aggiungere, rimuovere o sostituire i contenuti che vengono CloudFront distribuiti](AddRemoveReplaceObjects.md).

## Richiesta di HTTPS per visualizzatori
<a name="configure-cloudfront-HTTPS-viewers"></a>

Per richiedere HTTPS tra i visualizzatori e CloudFront per uno o più comportamenti della cache, effettuate la procedura seguente.<a name="using-https-viewers-to-cloudfront-procedure"></a>

**Per configurare la richiesta CloudFront di HTTPS tra i visualizzatori e CloudFront**

1. Accedi a Console di gestione AWS e apri la CloudFront console all'indirizzo[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Nel riquadro superiore della CloudFront console, scegli l'ID della distribuzione che desideri aggiornare.

1. Nella scheda **Comportamenti**, seleziona il comportamento cache che desideri aggiornare, quindi seleziona **Modifica**.

1. Specifica uno dei valori seguenti per **Policy protocollo visualizzatore**:  
**Reindirizza HTTP a HTTPS**  
I visualizzatori possono utilizzare entrambi i protocolli. HTTP `GET` e `HEAD` le richieste vengono reindirizzate automaticamente alle richieste HTTPS. CloudFront restituisce il codice di stato HTTP 301 (spostato permanentemente) insieme al nuovo URL HTTPS. Il visualizzatore invia quindi nuovamente la richiesta CloudFront utilizzando l'URL HTTPS.  
Se invii`POST`,, `PUT` `DELETE``OPTIONS`, o `PATCH` tramite HTTP con un comportamento di cache da HTTP a HTTPS e una versione del protocollo di richiesta HTTP 1.1 o successiva, CloudFront reindirizza la richiesta a una posizione HTTPS con un codice di stato HTTP 307 (reindirizzamento temporaneo). Questo garantisce che la richiesta venga inviata di nuovo alla nuova posizione utilizzando lo stesso metodo e payload del corpo.  
Se invii`POST`,, `PUT` `DELETE``OPTIONS`, o `PATCH` richieste tramite il comportamento della cache da HTTP a HTTPS con una versione del protocollo di richiesta inferiore a HTTP 1.1, CloudFront restituisce un codice di stato HTTP 403 (Proibito).
Quando un visualizzatore invia una richiesta HTTP che viene reindirizzata a una richiesta HTTPS, CloudFront addebita entrambe le richieste. Per la richiesta HTTP, l'addebito riguarda solo la richiesta e le intestazioni che vengono CloudFront restituite al visualizzatore. Per la richiesta HTTPS, l'addebito è per la richiesta, per le intestazioni e per l'oggetto che vengono restituiti dal server di origine.  
**Solo HTTPS**  
I visualizzatori possono accedere ai contenuti solo se utilizzano connessioni HTTPS. Se un visualizzatore invia una richiesta HTTP anziché una richiesta HTTPS, CloudFront restituisce il codice di stato HTTP 403 (Forbidden) e non restituisce l'oggetto.

1. Scegli **Save changes** (Salva modifiche).

1. Ripeti i passaggi da 3 a 5 per ogni comportamento aggiuntivo nella cache per cui desideri richiedere HTTPS tra i visualizzatori e. CloudFront

1. Conferma ciò che segue prima di utilizzare la configurazione aggiornata in un ambiente di produzione:
   + Il modello di percorso in ciascun comportamento cache si applica solo alle richieste per le quali desideri che i visualizzatori utilizzino una connessione HTTPS.
   + I comportamenti della cache sono elencati nell'ordine in cui desideri CloudFront valutarli. Per ulteriori informazioni, consulta [Modello di percorso](DownloadDistValuesCacheBehavior.md#DownloadDistValuesPathPattern).
   + I comportamenti cache sono richieste di routing ai server di origine corretti. 

# Richiedi HTTPS per la comunicazione tra CloudFront e la tua origine personalizzata
<a name="using-https-cloudfront-to-custom-origin"></a>

Puoi richiedere HTTPS per la comunicazione tra CloudFront e la tua origine.

**Nota**  
Se la tua origine è un bucket Amazon S3 configurato come endpoint del sito Web, non puoi configurare l'utilizzo di HTTPS con la tua origine perché Amazon S3 non supporta HTTPS CloudFront per gli endpoint dei siti Web.

Per richiedere HTTPS tra CloudFront e l'origine, segui le procedure in questo argomento per effettuare le seguenti operazioni:

1. Nella distribuzione, modifica l'impostazione **Policy protocollo di origine** per l’origine.

1. Installa un SSL/TLS certificato sul tuo server di origine (non è necessario quando utilizzi un'origine Amazon S3 o determinate altre AWS origini).

**Topics**
+ [

## Richiesta di HTTPS per origini personalizzate
](#using-https-cloudfront-to-origin-distribution-setting)
+ [

## Installa un SSL/TLS certificato sulla tua origine personalizzata
](#using-https-cloudfront-to-origin-certificate)

## Richiesta di HTTPS per origini personalizzate
<a name="using-https-cloudfront-to-origin-distribution-setting"></a>

La procedura seguente spiega come configurare l'uso di HTTPS CloudFront per comunicare con un sistema di bilanciamento del carico Elastic Load Balancing, un'istanza Amazon EC2 o un'altra origine personalizzata. Per informazioni sull'utilizzo dell' CloudFront API per aggiornare una distribuzione, [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)consulta *Amazon CloudFront API Reference*. <a name="using-https-cloudfront-to-custom-origin-procedure"></a>

**Per configurare CloudFront in modo che richieda HTTPS tra CloudFront e la tua origine personalizzata**

1. Accedi a Console di gestione AWS e apri la CloudFront console all'indirizzo[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Nel riquadro superiore della CloudFront console, scegli l'ID della distribuzione che desideri aggiornare.

1. Nella scheda **Comportamenti**, seleziona l’origine che desideri aggiornare, quindi scegli **Modifica**.

1. Aggiorna le seguenti impostazioni:  
**Origin Protocol Policy (Policy protocollo origine)**  
Cambia la **Origin Protocol Policy (Policy protocollo server di origine)** per i server di origine applicabili alla distribuzione:  
   + **Solo HTTPS**: CloudFront utilizza solo HTTPS per comunicare con la tua origine personalizzata.
   + **Match Viewer**: CloudFront comunica con l'origine personalizzata tramite HTTP o HTTPS, a seconda del protocollo della richiesta del visualizzatore. Ad esempio, se scegli **Match Viewer** per **Origin Protocol Policy** e il visualizzatore utilizza HTTPS per richiedere un oggetto CloudFront, utilizza CloudFront anche HTTPS per inoltrare la richiesta all'origine.

     Seleziona **Match Viewer (Abbina visualizzatore)** solo se specifichi **Redirect HTTP to HTTPS (Reindirizza HTTP a HTTPS)** o **HTTPS Only (solo HTTPS)** per la **Viewer Protocol Policy (Policy protocollo visualizzatore)**.

     CloudFront memorizza l'oggetto nella cache una sola volta anche se i visualizzatori effettuano richieste utilizzando entrambi i protocolli HTTP e HTTPS.  
**Protocolli origine SSL**  
Seleziona **Origin SSL Protocols (Protocolli origine SSL)** per i server di origine applicabili alla tua distribuzione. Il SSLv3 protocollo è meno sicuro, quindi ti consigliamo di scegliere SSLv3 solo se la tua origine non supporta TLSv1 o versioni successive. L' TLSv1 handshake è compatibile sia con le versioni precedenti che successive SSLv3, ma TLSv1 .1 e versioni successive no. Se lo desideri SSLv3, invia CloudFront *solo* richieste di handshake. SSLv3 

1. Scegli **Save changes** (Salva modifiche).

1. Ripeti i passaggi da 3 a 5 per ogni origine aggiuntiva per cui desideri richiedere HTTPS tra CloudFront e l'origine personalizzata.

1. Conferma ciò che segue prima di utilizzare la configurazione aggiornata in un ambiente di produzione:
   + Il modello di percorso in ciascun comportamento cache si applica solo alle richieste per le quali desideri che i visualizzatori utilizzino una connessione HTTPS.
   + I comportamenti della cache sono elencati nell'ordine in cui CloudFront desideri valutarli. Per ulteriori informazioni, consulta [Modello di percorso](DownloadDistValuesCacheBehavior.md#DownloadDistValuesPathPattern).
   + I comportamenti cache sono le richieste di routing ai server di origine per cui hai modificato la **Origin Protocol Policy (Policy protocollo server di origine)**. 

## Installa un SSL/TLS certificato sulla tua origine personalizzata
<a name="using-https-cloudfront-to-origin-certificate"></a>

Puoi utilizzare un SSL/TLS certificato proveniente dalle seguenti fonti sulla tua origine personalizzata:
+ Se l'origine è un sistema di bilanciamento del carico (load balancer) Elastic Load Balancing, è possibile utilizzare un certificato fornito da AWS Certificate Manager (ACM). Puoi inoltre utilizzare un certificato firmato da un'autorità di certificazione (CA) di terze parti affidabile e importato in ACM.
+ Per origini diverse dai sistemi di bilanciamento del carico Elastic Load Balancing, è necessario utilizzare un certificato firmato da un'autorità di certificazione (CA) di terze parti affidabile, ad esempio Comodo o Symantec. DigiCert

Il certificato restituito dall'origine deve includere uno dei seguenti nomi di dominio:
+ Il nome di dominio nel campo **Dominio di origine** (il `DomainName` campo dell'API). CloudFront 
+ Il nome di dominio nell’intestazione `Host`, se il comportamento della cache è configurato per inoltrare l’intestazione `Host` all'origine.

Quando CloudFront utilizza HTTPS per comunicare con l'origine, CloudFront verifica che il certificato sia stato emesso da un'autorità di certificazione attendibile. CloudFront supporta le stesse autorità di certificazione di Mozilla. Per l'elenco corrente, consulta l'[elenco dei certificati CA inclusi in Mozilla](https://wiki.mozilla.org/CA/Included_Certificates). Non è possibile utilizzare un certificato autofirmato per la comunicazione HTTPS tra CloudFront e l'origine.

**Importante**  
Se il server di origine restituisce un certificato scaduto, un certificato non valido o un certificato autofirmato oppure se restituisce la catena di certificati nell'ordine sbagliato, CloudFront interrompe la connessione TCP, restituisce il codice di stato HTTP 502 (Bad Gateway) al visualizzatore e imposta l'intestazione su. `X-Cache` `Error from cloudfront` Inoltre, se l'intera catena di certificati, incluso il certificato intermedio, non è presente, la connessione TCP viene interrotta. CloudFront 

# Richiedi HTTPS per la comunicazione tra CloudFront e la tua origine Amazon S3
<a name="using-https-cloudfront-to-s3-origin"></a>

Se la tua origine è un bucket Amazon S3, le opzioni di utilizzo di HTTPS per le comunicazioni CloudFront dipendono da come utilizzi il bucket. Se il tuo bucket Amazon S3 è configurato come endpoint di un sito Web, non puoi configurare l'utilizzo di HTTPS CloudFront per comunicare con la tua origine perché Amazon S3 non supporta le connessioni HTTPS in quella configurazione.

Se la tua origine è un bucket Amazon S3 che supporta la comunicazione HTTPS, CloudFront inoltra le richieste a S3 utilizzando il protocollo utilizzato dai visualizzatori per inviare le richieste. L'impostazione predefinita per [Protocollo (solo origini personalizzate)](DownloadDistValuesOrigin.md#DownloadDistValuesOriginProtocolPolicy) è **Match Viewer (Visualizzatore abbinamento)** e non può essere modificata. Tuttavia, se abiliti il controllo dell'accesso all'origine (OAC) per la tua origine Amazon S3, la comunicazione utilizzata CloudFront tra Amazon S3 e Amazon S3 dipende dalle tue impostazioni. Per ulteriori informazioni, consulta [Creazione di un nuovo controllo di accesso origine](private-content-restricting-access-to-s3.md#create-oac-overview-s3).

**Se desideri richiedere HTTPS per la comunicazione tra Amazon S3 CloudFront e Amazon, devi modificare il valore di **Viewer Protocol Policy** per **reindirizzare HTTP su HTTPS o solo HTTPS**.** La procedura riportata più avanti in questa sezione spiega come utilizzare la CloudFront console per modificare la **Viewer Protocol Policy**. Per informazioni sull'utilizzo dell' CloudFront API per aggiornare l'`ViewerProtocolPolicy`elemento per una distribuzione, [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)consulta *Amazon CloudFront API Reference*. 

Quando usi HTTPS con un bucket Amazon S3 che supporta la comunicazione HTTPS, Amazon S3 fornisce il SSL/TLS certificato, quindi non devi farlo tu.

## Richiesta di HTTPS per un’origine Amazon S3
<a name="configure-cloudfront-HTTPS-S3-origin"></a>

La procedura seguente mostra come configurare la richiesta CloudFront di HTTPS alla tua origine Amazon S3.<a name="using-https-cloudfront-to-s3-origin-procedure"></a>

**CloudFront Per configurare la richiesta di HTTPS alla tua origine Amazon S3**

1. Accedi a Console di gestione AWS e apri la CloudFront console all'indirizzo[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Nel riquadro superiore della CloudFront console, scegli l'ID della distribuzione che desideri aggiornare.

1. Nella scheda **Behaviors (Comportamenti)**, seleziona il comportamento cache che desideri aggiornare, quindi seleziona **Edit (Modifica)**.

1. Specifica uno dei valori seguenti per **Viewer Protocol Policy (Policy protocollo visualizzatore)**:  
**Reindirizza HTTP a HTTPS**  
Gli spettatori possono utilizzare entrambi i protocolli, ma le richieste HTTP vengono reindirizzate automaticamente alle richieste HTTPS. CloudFront restituisce il codice di stato HTTP 301 (Spostato permanentemente) insieme al nuovo URL HTTPS. Il visualizzatore invia quindi nuovamente la richiesta CloudFront utilizzando l'URL HTTPS.  
CloudFront non reindirizza`DELETE`, `OPTIONS` `PATCH``POST`, o `PUT` le richieste da HTTP a HTTPS. Se configuri un comportamento della cache per il reindirizzamento a HTTPS, CloudFront risponde a HTTP,`DELETE`, `OPTIONS` `PATCH``POST`, o alle `PUT` richieste relative a tale comportamento nella cache con il codice di stato HTTP 403 (Proibito).
Quando un visualizzatore invia una richiesta HTTP che viene reindirizzata a una richiesta HTTPS, CloudFront addebita entrambe le richieste. Per la richiesta HTTP, l'addebito riguarda solo la richiesta e le intestazioni che vengono CloudFront restituite al visualizzatore. Per la richiesta HTTPS, l'addebito è per la richiesta, per le intestazioni e per l'oggetto restituiti dal server di origine.  
**Solo HTTPS**  
I visualizzatori possono accedere ai contenuti solo se utilizzano connessioni HTTPS. Se un visualizzatore invia una richiesta HTTP anziché una richiesta HTTPS, CloudFront restituisce il codice di stato HTTP 403 (Forbidden) e non restituisce l'oggetto.

1. Seleziona **Yes, Edit (Sì, modifica)**.

1. Ripeti i passaggi da 3 a 5 per ogni comportamento aggiuntivo nella cache per cui desideri richiedere HTTPS tra i visualizzatori e CloudFront tra CloudFront e S3.

1. Conferma ciò che segue prima di utilizzare la configurazione aggiornata in un ambiente di produzione:
   + Il modello di percorso in ciascun comportamento cache si applica solo alle richieste per le quali desideri che i visualizzatori utilizzino una connessione HTTPS.
   + I comportamenti della cache sono elencati nell'ordine in cui desideri CloudFront valutarli. Per ulteriori informazioni, consulta [Modello di percorso](DownloadDistValuesCacheBehavior.md#DownloadDistValuesPathPattern).
   + I comportamenti cache sono richieste di routing ai server di origine corretti. 

# Protocolli e cifrari supportati tra visualizzatori e CloudFront
<a name="secure-connections-supported-viewer-protocols-ciphers"></a>

Quando [richiedi l'HTTPS tra i visualizzatori e la tua CloudFront distribuzione](DownloadDistValuesCacheBehavior.md#DownloadDistValuesViewerProtocolPolicy), devi scegliere una [politica di sicurezza](DownloadDistValuesGeneral.md#DownloadDistValues-security-policy) che determini le seguenti impostazioni:
+ Il SSL/TLS protocollo minimo CloudFront utilizzato per comunicare con gli spettatori.
+ I codici che è CloudFront possibile utilizzare per crittografare la comunicazione con gli spettatori.

Per scegliere una policy di sicurezza, specifica il valore applicabile per [Politica di sicurezza ( SSL/TLS versione minima)](DownloadDistValuesGeneral.md#DownloadDistValues-security-policy). La tabella seguente elenca i protocolli e i codici che è CloudFront possibile utilizzare per ogni politica di sicurezza.

Un visualizzatore deve supportare almeno uno dei codici supportati con cui stabilire una connessione HTTPS. CloudFront CloudFront sceglie un codice nell'ordine elencato tra i codici supportati dal visualizzatore. Consulta anche [Nomi di cifratura OpenSSL, s2n e RFC](#secure-connections-openssl-rfc-cipher-names).


|  | Policy di sicurezza |  | SSLv3 | TLSv1 | TLSv1\$12016 | TLSv1.1\$12016 | TLSv1.2\$12018 | TLSv1.2\$12019 | TLSv1.2\$12021 | TLSv1.2\$12025 | TLSv1.3\$12025 | 
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | 
| Protocolli supportati SSL/TLS  | 
| TLSv13. | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLSv12. | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  | 
| TLSv11. | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 
| TLSv1 | ♦ | ♦ | ♦ |  |  |  |  |  |  | 
| SSLv3 | ♦ |  |  |  |  |  |  |  |  | 
|  TLSv1Cifre 3.0 supportate | 
| TLS\$1AES\$1128\$1GCM\$1 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1AES\$1256\$1GCM\$1 SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1 \$1 CHACHA20 POLY1305 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  | ♦ | 
| Crittografie ECDSA supportate | 
| ECDHE-ECDSA- -GCM- AES128 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  | 
| ECDHE-ECSA- - AES128 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  |  |  | 
| ECDHE-ECDSA- -SHA AES128 | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 
| ECDHE-ECDSA- -GCM- AES256 SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  | 
| ECDHE-ECSA- - CHACHA20 POLY1305 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  |  | 
| ECDHE-ECDSA- - AES256 SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  |  |  | 
| ECDHE-ECDSA- -SHA AES256 | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 
| Crittografie RSA supportate | 
| ECDH-RSA- -GCM- AES128 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  | 
| ECDHE-RSA AES128 - - SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  |  |  | 
| ECDHE-RSA- AES128 -SHA | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 
| ECDHE-RSA- AES256 -GCM- SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  | 
| ECDHE-RSA CHACHA20 - - POLY1305 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  |  | 
| ECDHE-RSA- - AES256 SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  |  |  | 
| ECDHE-RSA- AES256 -SHA | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 
| AES128-GCM- SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ |  |  |  |  | 
| AES256-GCM- SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ |  |  |  |  | 
| AES128-SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ |  |  |  |  | 
| AES256-SHA | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 
| AES128-SHA | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 
| DES- -SHA CBC3 | ♦ | ♦ |  |  |  |  |  |  |  | 
| RC4-MD5 | ♦ |  |  |  |  |  |  |  |  | 

## Nomi di cifratura OpenSSL, s2n e RFC
<a name="secure-connections-openssl-rfc-cipher-names"></a>

OpenSSL e [s2n](https://github.com/awslabs/s2n) utilizzano nomi diversi per i cifrari rispetto agli standard TLS ([RFC 2246](https://tools.ietf.org/html/rfc2246), [RFC 4346](https://tools.ietf.org/html/rfc4346), [RFC 5246](https://tools.ietf.org/html/rfc5246) e [RFC 8446](https://tools.ietf.org/html/rfc8446)). La tabella seguente mappa i nomi OpenSSL e s2n al nome RFC per ogni crittografia.

CloudFront supporta scambi di chiavi classici e sicuri da un punto di vista quantistico. Per gli scambi di chiavi classici che utilizzano curve ellittiche, supporta quanto segue: CloudFront 
+ `prime256v1`
+ `X25519`
+ `secp384r1`

Per gli scambi di chiavi sicuri da un punto di vista quantistico, supporta quanto segue: CloudFront 
+ `X25519MLKEM768`
+ `SecP256r1MLKEM768`
**Nota**  
Gli scambi di chiavi Quantum-safe sono supportati solo con TLS 1.3. TLS 1.2 e le versioni precedenti non supportano lo scambio di chiavi a sicurezza quantistica.

  Per ulteriori informazioni, consulta i seguenti argomenti:
  + [Crittografia post-quantistica](https://aws.amazon.com/security/post-quantum-cryptography/)
  + [Algoritmi di crittografia e Servizi AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/encryption-best-practices/aws-cryptography-services.html#algorithms)
  + [Scambio di chiavi ibrido in TLS 1.3](https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/)

Per ulteriori informazioni sui requisiti dei certificati per CloudFront, vedere. [Requisiti per l'utilizzo SSL/TLS di certificati con CloudFront](cnames-and-https-requirements.md)


| Nome cifrato OpenSSL e s2n | Nome crittografia RFC | 
| --- | --- | 
|  TLSv1Cifre 3.0 supportate | 
| TLS\$1AES\$1128\$1GCM\$1 SHA256 | TLS\$1AES\$1128\$1GCM\$1 SHA256 | 
| TLS\$1AES\$1256\$1GCM\$1 SHA384 | TLS\$1AES\$1256\$1GCM\$1 SHA384 | 
| TLS\$1 \$1 CHACHA20 POLY1305 SHA256 | CHACHA20TLS\$1 \$1 POLY1305 SHA256 | 
| Crittografie ECDSA supportate | 
| ECDHE-ECDSA- -GCM- AES128 SHA256 | TLS\$1ECDHE\$1ECDSA\$1CON\$1AES\$1128\$1GCM\$1 SHA256 | 
| ECDHE-ECDSA- - AES128 SHA256 | TLS\$1ECDHE\$1ECDSA\$1CON\$1AES\$1128\$1CBC\$1 SHA256 | 
| ECDHE-ECDSA- -SHA AES128 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1128\$1CBC\$1SHA | 
| ECDHE-ECDSA- -GCM- AES256 SHA384 | TLS\$1ECDHE\$1ECDSA\$1CON\$1AES\$1256\$1GCM\$1 SHA384 | 
| ECDHE-ECDSA- - CHACHA20 POLY1305 | CHACHA20TLS\$1ECDHE\$1ECDSA\$1CON\$1 \$1 \$1 POLY1305 SHA256 | 
| ECDHE-ECDSA- - AES256 SHA384 | TLS\$1ECDHE\$1ECDSA\$1CON\$1AES\$1256\$1CBC\$1 SHA384 | 
| ECDHE-ECDSA- -SHA AES256 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1CBC\$1SHA | 
| Crittografie RSA supportate | 
| ECDH-RSA- -GCM- AES128 SHA256 | TLS\$1ECDHE\$1RSA\$1CON\$1AES\$1128\$1GCM\$1 SHA256 | 
| ECDHE-RSA- - AES128 SHA256 | TLS\$1ECDHE\$1RSA\$1CON\$1AES\$1128\$1CBC\$1 SHA256  | 
| ECDHE-RSA- -SHA AES128 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA | 
| ECDHE-RSA- AES256 -GCM- SHA384 | TLS\$1ECDHE\$1RSA\$1CON\$1AES\$1256\$1GCM\$1 SHA384  | 
| ECDHE-RSA- - CHACHA20 POLY1305 | TLS\$1ECDHE\$1RSA\$1CON\$1 \$1 CHACHA20 \$1 POLY1305 SHA256 | 
| ECDHE-RSA- - AES256 SHA384 | TLS\$1ECDHE\$1RSA\$1CON\$1AES\$1256\$1CBC\$1 SHA384  | 
| ECDHE-RSA- -SHA AES256 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA | 
| AES128-GCM- SHA256 | TLS\$1RSA\$1CON\$1AES\$1128\$1GCM\$1 SHA256 | 
| AES256-GCM- SHA384 | TLS\$1RSA\$1CON\$1AES\$1256\$1GCM\$1 SHA384 | 
| AES128-SHA256 | TLS\$1RSA\$1CON\$1AES\$1128\$1CBC\$1 SHA256 | 
| AES256-SHA | TLS\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA | 
| AES128-SHA | TLS\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA | 
| DES- -SHA CBC3  | TLS\$1RSA\$1WITH\$13DES\$1EDE\$1CBC\$1SHA  | 
| RC4-MD5 | TLS\$1RSA\$1CON\$1 \$1128\$1 RC4 MD5 | 

## Schemi di firma supportati tra spettatori e CloudFront
<a name="secure-connections-viewer-signature-schemes"></a>

CloudFront supporta i seguenti schemi di firma per le connessioni tra spettatori e. CloudFront


|  | Policy di sicurezza | Schemi di firma | SSLv3 | TLSv1 | TLSv1\$12016 | TLSv1.1\$12016 | TLSv1.2\$12018 | TLSv1.2\$12019 |  TLSv1.2\$12021 | TLSv1.2\$12025 | TLSv1.3\$12025 | 
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PSS\$1PSS\$1 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PSS\$1PSS\$1 SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PSS\$1PSS\$1 SHA512 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PSS\$1RSAE\$1 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PSS\$1RSAE\$1 SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PSS\$1RSAE\$1 SHA512 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1 \$1 PKCS1 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| PKCS1TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1 \$1 SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| PKCS1TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1 \$1 SHA512 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| PKCS1TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1 \$1 SHA224 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  |  | 
| TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1 SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1 SHA512 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1 SHA224 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  |  | 
| TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1 R1\$1 SECP256 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1 SECP384 R1\$1 SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| PKCS1TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1 \$1 SHA1 | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 
| TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1 SHA1 | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 

# Protocolli e cifrari supportati tra e l'origine CloudFront
<a name="secure-connections-supported-ciphers-cloudfront-to-origin"></a>

Se scegli di [richiedere HTTPS tra CloudFront e la tua origine](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesOriginProtocolPolicy), puoi decidere [quale SSL/TLS protocollo consentire](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesOriginSSLProtocols) la connessione sicura e CloudFront puoi connetterti all'origine utilizzando uno dei codici ECDSA o RSA elencati nella tabella seguente. L'origine deve supportare almeno uno di questi codici per stabilire una connessione HTTPS CloudFront all'origine.

OpenSSL e [s2n](https://github.com/awslabs/s2n) utilizzano nomi diversi per i cifrari rispetto agli standard TLS ([RFC 2246](https://tools.ietf.org/html/rfc2246), [RFC 4346](https://tools.ietf.org/html/rfc4346), [RFC 5246](https://tools.ietf.org/html/rfc5246) e [RFC 8446](https://tools.ietf.org/html/rfc8446)). La tabella seguente mappa i nomi OpenSSL e s2n e il nome RFC per ogni cifrario.

Per i cifrari con algoritmi di scambio di chiavi a curva ellittica, supporta le seguenti curve ellittiche: CloudFront 
+ prime256v1
+ secp384r1
+ X25519


| Nome cifrato OpenSSL e s2n | Nome crittografia RFC | 
| --- | --- | 
| Crittografie ECDSA supportate | 
| AES256ECDHE-ECDSA- -GCM- SHA384 | TLS\$1ECDHE\$1ECDSA\$1CON\$1AES\$1256\$1GCM\$1 SHA384 | 
| ECDHE-ECDSA- - AES256 SHA384 | TLS\$1ECDHE\$1ECDSA\$1CON\$1AES\$1256\$1CBC\$1 SHA384 | 
| ECDHE-ECDSA- -SHA AES256 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1CBC\$1SHA | 
| ECDHE-ECDSA- -GCM- AES128 SHA256 | TLS\$1ECDHE\$1ECDSA\$1CON\$1AES\$1128\$1GCM\$1 SHA256 | 
| ECDHE-ECDSA- - AES128 SHA256 | TLS\$1ECDHE\$1ECDSA\$1CON\$1AES\$1128\$1CBC\$1 SHA256 | 
| ECDHE-ECDSA- -SHA AES128 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1128\$1CBC\$1SHA | 
| Crittografie RSA supportate | 
| ECDH-RSA- -GCM- AES256 SHA384 | TLS\$1ECDHE\$1RSA\$1CON\$1AES\$1256\$1GCM\$1 SHA384 | 
| ECDHE-RSA- - AES256 SHA384 | TLS\$1ECDHE\$1RSA\$1CON\$1AES\$1256\$1CBC\$1 SHA384 | 
| ECDHE-RSA- -SHA AES256 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA | 
| ECDHE-RSA- AES128 -GCM- SHA256 | TLS\$1ECDHE\$1RSA\$1CON\$1AES\$1128\$1GCM\$1 SHA256 | 
| ECDHE-RSA- - AES128 SHA256 | TLS\$1ECDHE\$1RSA\$1CON\$1AES\$1128\$1CBC\$1 SHA256 | 
| ECDHE-RSA- -SHA AES128 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA | 
| AES256-SHA | TLS\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA | 
| AES128-SHA | TLS\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA | 
| DES- -SHA CBC3 | TLS\$1RSA\$1WITH\$13DES\$1EDE\$1CBC\$1SHA | 
| RC4-MD5 | TLS\$1RSA\$1CON\$1 \$1128\$1 RC4 MD5 | 

**Schemi di firma supportati tra e l'origine CloudFront **

CloudFront supporta i seguenti schemi di firma per le connessioni tra CloudFront e l'origine.
+ TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1 \$1 PKCS1 SHA256
+ PKCS1TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1 \$1 SHA384
+ PKCS1TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1 \$1 SHA512
+ PKCS1TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1 \$1 SHA224
+ TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1 SHA256
+ TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1 SHA384
+ TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1 SHA512
+ TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1 SHA224
+ TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1 \$1 PKCS1 SHA1
+ TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1 SHA1

# Utilizzo di nomi di dominio alternativi e HTTPS
<a name="using-https-alternate-domain-names"></a>

Se desideri utilizzare il tuo nome di dominio URLs per i tuoi file (ad esempio`https://www.example.com/image.jpg`) e desideri che i tuoi utenti utilizzino HTTPS, devi completare i passaggi descritti nei seguenti argomenti. (Se, ad esempio, utilizzi il nome di dominio di CloudFront distribuzione predefinito nel tuo URLs, ad esempio`https://d111111abcdef8.cloudfront.net/image.jpg`, segui invece le indicazioni riportate nel seguente argomento:[Richiedi HTTPS per la comunicazione tra gli spettatori e CloudFront](using-https-viewers-to-cloudfront.md).)

**Importante**  
Quando aggiungi un certificato alla tua distribuzione, lo propaga CloudFront immediatamente a tutte le sue edge location. Quando saranno disponibili nuove edge location, CloudFront propagherà il certificato anche a tali posizioni. Non è possibile limitare le edge location verso cui CloudFront vengono propagati i certificati.

**Topics**
+ [

# Scegli in che modo CloudFront vengono servite le richieste HTTPS
](cnames-https-dedicated-ip-or-sni.md)
+ [

# Requisiti per l'utilizzo SSL/TLS di certificati con CloudFront
](cnames-and-https-requirements.md)
+ [

# Quote sull'utilizzo di SSL/TLS certificati con CloudFront (HTTPS solo tra visualizzatori e CloudFront solo tra visualizzatori)
](cnames-and-https-limits.md)
+ [

# Configurazione di nomi di dominio alternativi e HTTPS
](cnames-and-https-procedures.md)
+ [

# Determina la dimensione della chiave pubblica in un certificato SSL/TLS RSA
](cnames-and-https-size-of-public-key.md)
+ [

# Aumenta le quote per i certificati SSL/TLS
](increasing-the-limit-for-ssl-tls-certificates.md)
+ [

# Ruota SSL/TLS i certificati
](cnames-and-https-rotate-certificates.md)
+ [

# Passa da un SSL/TLS certificato personalizzato al certificato predefinito CloudFront
](cnames-and-https-revert-to-cf-certificate.md)
+ [

# Passa da un SSL/TLS certificato personalizzato con indirizzi IP dedicati a SNI
](cnames-and-https-switch-dedicated-to-sni.md)

# Scegli in che modo CloudFront vengono servite le richieste HTTPS
<a name="cnames-https-dedicated-ip-or-sni"></a>

Se desideri che i tuoi spettatori utilizzino HTTPS e utilizzino nomi di dominio alternativi per i tuoi file, scegli una delle seguenti opzioni per il modo in cui vengono gestite le richieste CloudFront HTTPS:
+ Utilizzare la [Server Name Indication (SNI)](https://en.wikipedia.org/wiki/Server_Name_Indication): scelta consigliata
+ Utilizzare un indirizzo IP dedicato in ogni edge location

Questa sezione spiega come funziona ciascuna opzione.

## Utilizzo di SNI per servire le richieste HTTPS (funziona per la maggior parte dei client)
<a name="cnames-https-sni"></a>

[Server Name Indication (SNI)](https://en.wikipedia.org/wiki/Server_Name_Indication) è un'estensione del protocollo TLS supportato da browser e client rilasciati dopo il 2010. Se configuri CloudFront per servire le richieste HTTPS utilizzando SNI, CloudFront associa il nome di dominio alternativo a un indirizzo IP per ogni edge location. Quando un visualizzatore invia una richiesta HTTPS per i tuoi contenuti, il DNS instrada la richiesta all'indirizzo IP per la edge location corretta. L'indirizzo IP del nome di dominio viene determinato durante la negoziazione dell' SSL/TLS handshake; l'indirizzo IP non è dedicato alla distribuzione.

La SSL/TLS negoziazione avviene all'inizio del processo di creazione di una connessione HTTPS. Se non è CloudFront possibile determinare immediatamente a quale dominio si riferisce la richiesta, la connessione viene interrotta. Quando un visualizzatore che supporta la SNI invia una richiesta HTTPS per i tuoi contenuti, ecco cosa succede:

1. Il visualizzatore ottiene automaticamente il nome di dominio dall’URL della richiesta e lo aggiunge all’estensione SNI del messaggio di saluto del client TLS.

1. Quando CloudFront riceve il client TLS, utilizza il nome di dominio nell'estensione SNI per trovare la CloudFront distribuzione corrispondente e restituisce il certificato TLS associato.

1. Il visualizzatore ed CloudFront eseguono la negoziazione. SSL/TLS 

1. CloudFront restituisce il contenuto richiesto al visualizzatore.

Per un elenco aggiornato dei browser che supportano la SNI, vedi la voce Wikipedia [Server Name Indication](https://en.wikipedia.org/wiki/Server_Name_Indication).

Se desideri utilizzare la SNI ma alcuni browser degli utenti non supportano le SNI, hai diverse opzioni:
+ Configura CloudFront per soddisfare le richieste HTTPS utilizzando indirizzi IP dedicati anziché SNI. Per ulteriori informazioni, consulta [Utilizzo di un indirizzo IP dedicato per servire le richieste HTTPS (funziona per tutti i client)](#cnames-https-dedicated-ip).
+ Utilizza il certificato CloudFront SSL/TLS anziché un certificato personalizzato. Ciò richiede l'utilizzo del nome di CloudFront dominio per la distribuzione in URLs per i file, ad esempio,. `https://d111111abcdef8.cloudfront.net/logo.png`

  Se utilizzi il CloudFront certificato predefinito, gli utenti devono supportare il protocollo SSL TLSv1 o versioni successive. CloudFront non supporta il SSLv3 certificato predefinitoCloudFront .

  È inoltre necessario modificare il SSL/TLS certificato in CloudFront uso da un certificato personalizzato a un CloudFront certificato predefinito:
  + Se non hai utilizzato la tua distribuzione per distribuire i contenuti, puoi modificare la configurazione. Per ulteriori informazioni, consulta [Aggiornamento di una distribuzione](HowToUpdateDistribution.md).
  + Se hai utilizzato la tua distribuzione per distribuire i contenuti, devi creare una nuova CloudFront distribuzione e modificare i file URLs per ridurre o eliminare il periodo di indisponibilità dei contenuti. Per ulteriori informazioni, consulta [Passa da un SSL/TLS certificato personalizzato al certificato predefinito CloudFront](cnames-and-https-revert-to-cf-certificate.md).
+ Se puoi verificare qual è il browser utilizzato dagli utenti, allora aggiornalo a una versione che supporta la SNI.
+ Utilizza HTTP anziché HTTPS.

## Utilizzo di un indirizzo IP dedicato per servire le richieste HTTPS (funziona per tutti i client)
<a name="cnames-https-dedicated-ip"></a>

Server Name Indication (SNI) costituisce un modo per associare una richiesta a un dominio. Un altro modo consiste nell'utilizzare un indirizzo IP dedicato. Se gli utenti non sono in grado di effettuare l'aggiornamento a un browser o un client rilasciato dopo il 2010, puoi utilizzare un indirizzo IP dedicato per fornire le richieste HTTPS. Per un elenco aggiornato dei browser che supportano la SNI, vedi la voce Wikipedia [Server Name Indication](https://en.wikipedia.org/wiki/Server_Name_Indication). 

**Importante**  
Se CloudFront configuri per soddisfare le richieste HTTPS utilizzando indirizzi IP dedicati, dovrai sostenere un costo mensile aggiuntivo. L'addebito inizia quando si associa il SSL/TLS certificato a una distribuzione e si abilita la distribuzione. Per ulteriori informazioni sui CloudFront prezzi, consulta la pagina [ CloudFront dei prezzi di Amazon](https://aws.amazon.com/cloudfront/pricing). Inoltre, fai riferimento a [Using the Same Certificate for Multiple CloudFront Distributions](cnames-and-https-limits.md#cnames-and-https-same-certificate-multiple-distributions).

Quando configuri CloudFront per soddisfare le richieste HTTPS utilizzando indirizzi IP dedicati, CloudFront associa il certificato a un indirizzo IP dedicato in ogni CloudFront edge location. Quando un visualizzatore invia una richiesta HTTPS per i tuoi contenuti, ecco cosa succede:

1. DNS instrada la richiesta all'indirizzo IP della tua distribuzione nella edge location di riferimento.

1. Se una richiesta client fornisce l'estensione SNI nel `ClientHello` messaggio, CloudFront cerca una distribuzione associata a tale SNI.
   + Se c'è una corrispondenza, CloudFront risponde alla richiesta con il certificato SSL/TLS.
   + Se non c'è alcuna corrispondenza, CloudFront utilizza invece l'indirizzo IP per identificare la distribuzione e determinare quale certificato SSL/TLS restituire al visualizzatore.

1. Il visualizzatore ed CloudFront eseguiamo la SSL/TLS negoziazione utilizzando il certificato SSL/TLS.

1. CloudFront restituisce il contenuto richiesto al visualizzatore.

Questo metodo funziona per ogni richiesta HTTPS, indipendentemente dal browser o da un altro visualizzatore che l'utente sta utilizzando. 

**Nota**  
 IPs I dedicati non sono statici IPs e possono cambiare nel tempo. L'indirizzo IP restituito per l'edge location viene allocato dinamicamente dagli intervalli di indirizzi IP dell'elenco dei [server CloudFront periferici](LocationsOfEdgeServers.md).  
Gli intervalli di indirizzi IP per i server CloudFront edge sono soggetti a modifiche. Per ricevere notifiche sulle modifiche all'indirizzo IP, [iscriviti a AWS Public IP Address Changes tramite Amazon SNS](https://aws.amazon.com/blogs/aws/subscribe-to-aws-public-ip-address-changes-via-amazon-sns/).

## Richiedi l'autorizzazione per utilizzare tre o più certificati IP SSL/TLS dedicati
<a name="cnames-and-https-multiple-certificates"></a>

Se hai bisogno dell'autorizzazione per associare permanentemente tre o più certificati IP dedicati SSL/TLS a CloudFront, esegui la procedura seguente. Per ulteriori informazioni sulle richieste HTTPS, consulta [Scegli in che modo CloudFront vengono servite le richieste HTTPS](#cnames-https-dedicated-ip-or-sni).

**Nota**  
Questa procedura consente di utilizzare tre o più certificati IP dedicati tra le distribuzioni. CloudFront Il valore predefinito è 2. Tieni presente che non è possibile associare più di un certificato SSL a una distribuzione.  
È possibile associare un solo SSL/TLS certificato alla volta a una CloudFront distribuzione. Questo numero indica il numero totale di certificati SSL IP dedicati che puoi utilizzare in tutte le tue CloudFront distribuzioni.<a name="cnames-and-https-multiple-certificates-procedure"></a>

**Per richiedere l'autorizzazione a utilizzare tre o più certificati con una distribuzione CloudFront**

1. Visita il [Centro di supporto](https://console.aws.amazon.com/support/home?#/case/create?issueType=service-limit-increase&limitType=service-code-cloudfront-distributions) e immetti una richiesta.

1. Indica il numero di certificati per i quali hai bisogno dell'autorizzazione all'utilizzo e descrivi le circostanze nella tua richiesta. Aggiorneremo il tuo account appena possibile.

1. Continua con la procedura successiva.

# Requisiti per l'utilizzo SSL/TLS di certificati con CloudFront
<a name="cnames-and-https-requirements"></a>

I requisiti per SSL/TLS i certificati sono descritti in questo argomento. Si applicano, ad eccezione di quanto indicato sopra, nei seguenti casi:
+ Certificati per l'utilizzo di HTTPS tra visualizzatori e CloudFront 
+ Certificati per l'utilizzo di HTTPS tra CloudFront e l'origine

**Topics**
+ [

## Autorità di certificazione
](#https-requirements-certificate-issuer)
+ [

## Regione AWS per AWS Certificate Manager
](#https-requirements-aws-region)
+ [

## Formato del certificato
](#https-requirements-certificate-format)
+ [

## Certificati intermedi
](#https-requirements-intermediate-certificates)
+ [

## Tipo di chiavi
](#https-requirements-key-type)
+ [

## Chiave privata
](#https-requirements-private-key)
+ [

## Permissions
](#https-requirements-permissions)
+ [

## Dimensioni della chiave di certificato
](#https-requirements-size-of-public-key)
+ [

## Tipi di certificati supportati
](#https-requirements-supported-types)
+ [

## Data di scadenza e rinnovo certificati
](#https-requirements-cert-expiration)
+ [

## Nomi di dominio nella CloudFront distribuzione e nel certificato
](#https-requirements-domain-names-in-cert)
+ [

## Versione minima SSL/TLS del protocollo
](#https-requirements-minimum-ssl-protocol-version)
+ [

## Versioni HTTP supportate
](#https-requirements-supported-http-versions)

## Autorità di certificazione
<a name="https-requirements-certificate-issuer"></a>

Ti consigliamo di usare un certificato rilasciato da [AWS Certificate Manager (ACM)](https://aws.amazon.com/certificate-manager/). Per informazioni su come ottenere un certificato da ACM, consulta la *[Guida per l'utente di AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/)*. Per utilizzare un certificato ACM con una CloudFront distribuzione, assicurati di richiedere (o importare) il certificato nella regione Stati Uniti orientali (Virginia settentrionale) (`us-east-1`).

 CloudFront supporta le stesse autorità di certificazione (CAs) di Mozilla, quindi se non usi ACM, usa un certificato emesso da una CA presente nell'elenco dei certificati CA inclusi di [Mozilla](https://wiki.mozilla.org/CA/Included_Certificates). 

I certificati TLS utilizzati dall'origine specificata per la CloudFront distribuzione devono essere emessi anche dalla CA presente nell'elenco dei certificati CA inclusi da Mozilla.

Per ulteriori informazioni su come ottenere e installare un certificato SSL/TLS, consulta la documentazione del software del server HTTP e la documentazione relativa all'autorità di certificazione.

## Regione AWS per AWS Certificate Manager
<a name="https-requirements-aws-region"></a>

Per utilizzare un certificato in AWS Certificate Manager (ACM) per richiedere HTTPS tra i visualizzatori eCloudFront, assicurati di richiedere (o importare) il certificato nella regione Stati Uniti orientali (Virginia settentrionale) (). `us-east-1`

Se desideri richiedere HTTPS tra CloudFront e la tua origine e utilizzi un sistema di bilanciamento del carico in Elastic Load Balancing come origine, puoi richiedere o importare il certificato in qualsiasi formato. Regione AWS

## Formato del certificato
<a name="https-requirements-certificate-format"></a>

Il certificato deve essere in formato PEM X.509. Questo è il formato di default se si utilizza AWS Certificate Manager.

## Certificati intermedi
<a name="https-requirements-intermediate-certificates"></a>

Se stai utilizzando un'autorità di certificazione (CA) di terza parte, nel file `.pem` elenca tutti i certificati intermedi della catena di certificati, a partire da uno per la CA che ha firmato il certificato per il tuo dominio. Di solito, puoi trovare un file sul sito Web della CA in cui vengono elencati i certificati intermedi e root concatenati nel giusto ordine.

**Importante**  
Non includere i seguenti certificati: il certificato root, i certificati intermedi che non sono nel percorso attendibile oppure il certificato della chiave pubblica della CA.

Ecco un esempio:

```
-----BEGIN CERTIFICATE-----
Intermediate certificate 2
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Intermediate certificate 1
-----END CERTIFICATE-----
```

## Tipo di chiavi
<a name="https-requirements-key-type"></a>

CloudFront supporta coppie di chiavi pubbliche-private RSA ed ECDSA.

CloudFront supporta connessioni HTTPS sia verso i visualizzatori che verso le origini utilizzando certificati RSA ed ECDSA. Con [AWS Certificate Manager (ACM)](https://console.aws.amazon.com/acm), puoi richiedere e importare certificati RSA o ECDSA e associarli alla tua distribuzione. CloudFront 

Per gli elenchi dei codici RSA ed ECDSA supportati da cui è possibile negoziare in connessioni HTTPS, CloudFront vedere e. [Protocolli e cifrari supportati tra visualizzatori e CloudFront](secure-connections-supported-viewer-protocols-ciphers.md) [Protocolli e cifrari supportati tra e l'origine CloudFront](secure-connections-supported-ciphers-cloudfront-to-origin.md)

## Chiave privata
<a name="https-requirements-private-key"></a>

Se utilizzi un certificato di un'autorità di certificazione (CA) esterna, tieni presente quanto segue: 
+ La chiave privata deve corrispondere alla chiave pubblica presente nel certificato.
+ La chiave privata deve essere nel formato PEM.
+ La chiave privata non può essere crittografata con una password.

Se AWS Certificate Manager (ACM) ha fornito il certificato, ACM non rilascia la chiave privata. La chiave privata viene archiviata in ACM per essere utilizzata dai AWS servizi integrati con ACM.

## Permissions
<a name="https-requirements-permissions"></a>

È necessario disporre dell'autorizzazione per utilizzare e importare il SSL/TLS certificato. Se utilizzi AWS Certificate Manager (ACM), ti consigliamo di utilizzare AWS Identity and Access Management le autorizzazioni per limitare l'accesso ai certificati. Per ulteriori informazioni, consulta [Identity and Access Management](https://docs.aws.amazon.com/acm/latest/userguide/security-iam.html) nella *Guida per l'utente di AWS Certificate Manager *.

## Dimensioni della chiave di certificato
<a name="https-requirements-size-of-public-key"></a>

La dimensione della chiave del certificato CloudFront supportata dipende dal tipo di chiave e di certificato.

**Per i certificati RSA:**  
CloudFront supporta chiavi RSA a 1024 bit, 2048 bit, 3072 bit e 4096 bit. La lunghezza massima della chiave per un certificato RSA da utilizzare è di 4096 bit. CloudFront   
 Nota che ACM emette certificati RSA con chiavi fino a 2048 bit. Per utilizzare un certificato RSA a 3072 o 4096 bit, è necessario ottenere il certificato esternamente e importarlo in ACM, dopodiché sarà disponibile per l'uso. CloudFront   
Per informazioni su come stabilire le dimensioni di una chiave RSA, consulta [Determina la dimensione della chiave pubblica in un certificato SSL/TLS RSA](cnames-and-https-size-of-public-key.md).

**Per i certificati ECDSA:**  
CloudFront supporta chiavi a 256 bit. Per utilizzare un certificato ECDSA in ACM per richiedere HTTPS tra i visualizzatori e CloudFront, usa la curva ellittica prime256v1.

## Tipi di certificati supportati
<a name="https-requirements-supported-types"></a>

CloudFront supporta tutti i tipi di certificati emessi da un'autorità di certificazione affidabile.

## Data di scadenza e rinnovo certificati
<a name="https-requirements-cert-expiration"></a>

Se utilizzi certificati ottenuti da un'autorità di certificazione (CA) di terze parti, devi monitorare le date di scadenza dei certificati e rinnovare i certificati importati in AWS Certificate Manager (ACM) o caricati nell'archivio AWS Identity and Access Management certificati prima della scadenza.

**Importante**  
Per evitare problemi legati alla scadenza del certificato, rinnovalo o reimportalo almeno 24 ore prima del valore `NotAfter` del certificato attuale. Se il certificato scade entro 24 ore, richiedi un nuovo certificato ad ACM o importa un nuovo certificato in ACM. Successivamente, associa il nuovo certificato alla distribuzione. CloudFront   
CloudFront potrebbe continuare a utilizzare il certificato precedente mentre è in corso il rinnovo o la reimportazione del certificato. Si tratta di un processo asincrono che può richiedere fino a 24 ore prima CloudFront che vengano visualizzate le modifiche.

Se utilizzi certificati forniti da ACM, ACM gestisce automaticamente il rinnovo dei certificati. Per ulteriori informazioni, consulta [Rinnovo gestito](https://docs.aws.amazon.com/acm/latest/userguide/managed-renewal.html) nella *Guida per l'utente di AWS Certificate Manager *.

## Nomi di dominio nella CloudFront distribuzione e nel certificato
<a name="https-requirements-domain-names-in-cert"></a>

Quando utilizzi un'origine personalizzata, il SSL/TLS certificato relativo alla tua origine include un nome di dominio nel campo **Nome comune** e probabilmente molti altri nel campo **Nomi alternativi dell'oggetto**. (CloudFront supporta caratteri jolly nei nomi di dominio dei certificati.) 

Uno dei nomi di dominio nel certificato deve corrispondere al nome di dominio specificato per Nome dominio origine. Se nessun nome di dominio corrisponde, CloudFront restituisce il codice di stato HTTP `502 (Bad Gateway)` al visualizzatore.

**Importante**  
Quando aggiungi un nome di dominio alternativo a una distribuzione, CloudFront verifica che il nome di dominio alternativo sia coperto dal certificato che hai allegato. Il certificato deve coprire il nome di dominio alternativo nel campo del nome alternativo dell'oggetto (SAN) del certificato. Ciò significa che il campo SAN deve contenere una corrispondenza esatta del nome di dominio alternativo o contenere un carattere jolly allo stesso livello del nome di dominio alternativo che si sta aggiungendo.  
Per ulteriori informazioni, consulta [Requisiti per l'utilizzo di nomi di dominio alternativi](CNAMEs.md#alternate-domain-names-requirements).

## Versione minima SSL/TLS del protocollo
<a name="https-requirements-minimum-ssl-protocol-version"></a>

Se utilizzi indirizzi IP dedicati, imposta la versione minima del SSL/TLS protocollo per la connessione tra gli spettatori e CloudFront scegli una politica di sicurezza.

Per ulteriori informazioni, consulta [Politica di sicurezza ( SSL/TLS versione minima)](DownloadDistValuesGeneral.md#DownloadDistValues-security-policy) nell'argomento [Riferimento a tutte le impostazioni di distribuzione](distribution-web-values-specify.md).

## Versioni HTTP supportate
<a name="https-requirements-supported-http-versions"></a>

Se associ un certificato a più di una CloudFront distribuzione, tutte le distribuzioni associate al certificato devono utilizzare la stessa opzione per. [Versioni HTTP supportate](DownloadDistValuesGeneral.md#DownloadDistValuesSupportedHTTPVersions) Questa opzione viene specificata quando si crea o si aggiorna una CloudFront distribuzione.

# Quote sull'utilizzo di SSL/TLS certificati con CloudFront (HTTPS solo tra visualizzatori e CloudFront solo tra visualizzatori)
<a name="cnames-and-https-limits"></a>

Nota le seguenti quote sull'utilizzo SSL/TLS dei certificati conCloudFront. Queste quote si applicano solo ai SSL/TLS certificati forniti utilizzando AWS Certificate Manager (ACM), importati in ACM o caricati nell'archivio certificati IAM per la comunicazione HTTPS tra i visualizzatori e. CloudFront

Per ulteriori informazioni, consulta [Aumenta le quote per i certificati SSL/TLS](increasing-the-limit-for-ssl-tls-certificates.md).

**Numero massimo di certificati per distribuzione CloudFront **  
È possibile associare al massimo un SSL/TLS certificato a ciascuna CloudFront distribuzione.

**Numero massimo di certificati che puoi importare in ACM o caricare nello store certificati IAM**  
Se i SSL/TLS certificati sono stati ottenuti da una CA di terze parti, è necessario archiviarli in una delle seguenti posizioni:  
+ **AWS Certificate Manager**: per la quota corrente sul numero di certificati ACM, consulta [Quote](https://docs.aws.amazon.com/acm/latest/userguide/acm-limits.html) nella *Guida per l'utente di AWS Certificate Manager *. La quota elencata è un totale che include i certificati di cui è stato effettuato il provisioning utilizzando ACM e certificati importati in ACM.
+ **Archivio certificati IAM**: per la quota attuale (precedentemente nota come limite) sul numero di certificati che puoi caricare nell'archivio certificati IAM per un AWS account, consulta IAM [and STS Limits nella IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-limits.html) *User* Guide. Puoi richiedere un aumento della quota utilizzando la console Service Quotas.

**Numero massimo di certificati per AWS account (solo indirizzi IP dedicati)**  
Se desideri servire le richieste HTTPS utilizzando indirizzi IP dedicati, tieni presente quanto segue:  
+ Per impostazione predefinita, ti CloudFront consente di utilizzare due certificati con il tuo AWS account, uno per l'uso quotidiano e uno per quando devi ruotare i certificati per più distribuzioni.
+ Se hai bisogno di più di due SSL/TLS certificati personalizzati per il tuo AWS account, puoi richiedere una quota più alta nella console Service Quotas.

**Utilizza lo stesso certificato per CloudFront le distribuzioni create utilizzando account diversi AWS **  
Se utilizzi una CA di terze parti e desideri utilizzare lo stesso certificato con più CloudFront distribuzioni create utilizzando AWS account diversi, devi importare il certificato in ACM o caricarlo nell'archivio certificati IAM una volta per ogni account. AWS   
Se utilizzi certificati forniti da ACM, non puoi configurare l'utilizzo CloudFront di certificati creati da un account diverso. AWS 

**Utilizza lo stesso certificato per CloudFront e per altri servizi AWS **  
Se hai acquistato un certificato da un'autorità di certificazione affidabile come Comodo o Symantec, puoi utilizzare lo stesso certificato per CloudFront e per altri AWS servizi. DigiCert Se stai importando il certificato in ACM, è necessario importarlo solo una volta per utilizzarlo per più servizi AWS .  
Se usi certificati forniti da ACM, i certificati vengono archiviati in ACM.

**Usa lo stesso certificato per più distribuzioni CloudFront **  
È possibile utilizzare lo stesso certificato per una o per tutte le distribuzioni CloudFront utilizzate per elaborare le richieste HTTPS. Tenere presente quanto segue:  
+ Puoi utilizzare lo stesso certificato sia per l'elaborazione di richieste tramite indirizzi IP dedicati sia per l'elaborazione di richieste tramite la SNI. 
+ È possibile associare solo un certificato a ogni distribuzione.
+ Ogni distribuzione deve includere uno o più nomi di dominio alternativi che appariranno anche nel campo **Common Name (Nome comune)** o nel campo **Subject Alternative Names (Nomi alternativi oggetto)** del certificato.
+ Se gestisci richieste HTTPS utilizzando indirizzi IP dedicati e hai creato tutte le distribuzioni utilizzando lo stesso AWS account, puoi ridurre in modo significativo i costi utilizzando lo stesso certificato per tutte le distribuzioni. CloudFront costi per ogni certificato, non per ogni distribuzione. 

  Ad esempio, supponiamo di creare tre distribuzioni utilizzando lo stesso AWS account e di utilizzare lo stesso certificato per tutte e tre le distribuzioni. Ti verrà addebitata solo una tariffa per l'utilizzo di indirizzi IP dedicati.

  Tuttavia, se gestisci richieste HTTPS utilizzando indirizzi IP dedicati e utilizzi lo stesso certificato per creare CloudFront distribuzioni in AWS account diversi, a ciascun account viene addebitata la tariffa per l'utilizzo di indirizzi IP dedicati. Ad esempio, se crei tre distribuzioni utilizzando tre AWS account diversi e utilizzi lo stesso certificato per tutte e tre le distribuzioni, a ciascun account viene addebitata l'intera tariffa per l'utilizzo di indirizzi IP dedicati.

# Configurazione di nomi di dominio alternativi e HTTPS
<a name="cnames-and-https-procedures"></a>

Per utilizzare nomi di dominio alternativi URLs per i file e utilizzare HTTPS tra i visualizzatori CloudFront, esegui le procedure applicabili.

**Topics**
+ [

## Ottieni un certificato SSL/TLS
](#cnames-and-https-getting-certificates)
+ [

## Importa un certificato SSL/TLS
](#cnames-and-https-uploading-certificates)
+ [

## Aggiorna la tua CloudFront distribuzione
](#cnames-and-https-updating-cloudfront)

## Ottieni un certificato SSL/TLS
<a name="cnames-and-https-getting-certificates"></a>

Richiedi un SSL/TLS certificato se non ne hai già uno. Per ulteriori informazioni, consulta la documentazione relativa:
+ Per utilizzare un certificato fornito da AWS Certificate Manager (ACM), consulta la [Guida per l'AWS Certificate Manager utente](https://docs.aws.amazon.com/acm/latest/userguide/). Quindi passa a [Aggiorna la tua CloudFront distribuzione](#cnames-and-https-updating-cloudfront).
**Nota**  
Si consiglia di utilizzare ACM per fornire, gestire e distribuire SSL/TLS certificati su AWS risorse gestite. È necessario richiedere un certificato ACM nella regione degli Stati Uniti orientali (Virginia settentrionale).
+ Per ottenere un certificato da un'autorità di certificazione esterna (CA), consulta la documentazione fornita dall'autorità di certificazione. Quando hai il certificato, continua con la procedura.

## Importa un certificato SSL/TLS
<a name="cnames-and-https-uploading-certificates"></a>

Se hai ricevuto il tuo certificato da un'autorità di certificazione di terze parti, importa il certificato in ACM o caricalo nello store certificati IAM:

**ACM (consigliato)**  
ACM ti consente di importare certificati di terze parti dalla console ACM, nonché in modo programmatico. Per informazioni sull'importazione di un certificato in ACM, consulta [Importazione di certificati in AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/import-certificate.html) nella *Guida per l'utente di AWS Certificate Manager *. È necessario importare il certificato nella regione Stati Uniti orientali (Virginia settentrionale).

**Archivio certificati IAM**  
(Non consigliato) Utilizza il seguente AWS CLI comando per caricare il certificato di terze parti nell'archivio certificati IAM.  

```
aws iam upload-server-certificate \
        --server-certificate-name CertificateName \
        --certificate-body file://public_key_certificate_file \
        --private-key file://privatekey.pem \
        --certificate-chain file://certificate_chain_file \
        --path /cloudfront/path/
```
Tenere presente quanto segue:  
+ **AWS account**: devi caricare il certificato nell'archivio certificati IAM utilizzando lo stesso AWS account che hai usato per creare la tua CloudFront distribuzione.
+ **--parametro del percorso** - Quando si carica il certificato in IAM, il valore del parametro `--path` (percorso certificato) deve iniziare con `/cloudfront/`, ad esempio `/cloudfront/production/` o `/cloudfront/test/`. Il percorso deve terminare con una /.
+ **Certificati esistenti**: devi specificare i valori per i parametri `--server-certificate-name` e `--path` diversi dai valori associati ai certificati esistenti.
+ **Utilizzo della CloudFront console**: il valore specificato per il `--server-certificate-name` parametro, ad esempio AWS CLI`myServerCertificate`, viene visualizzato nell'elenco dei **certificati SSL** della CloudFront console.
+ **Utilizzo dell' CloudFront API**: prendi nota della stringa alfanumerica che AWS CLI restituisce, ad esempio. `AS1A2M3P4L5E67SIIXR3J` Questo è il valore che verrà specificato nell'elemento `IAMCertificateId`. Non hai bisogno dell'ARN IAM che viene restituito dalla CLI.
Per ulteriori informazioni su AWS CLI, consulta la [Guida per l'AWS Command Line Interface utente](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) e il [AWS CLI Command](https://docs.aws.amazon.com/cli/latest/reference/) Reference.

## Aggiorna la tua CloudFront distribuzione
<a name="cnames-and-https-updating-cloudfront"></a>

Per aggiornare le impostazioni della distribuzione, esegui la procedura seguente:<a name="cnames-and-https-updating-cloudfront-procedure"></a>

**Per configurare la CloudFront distribuzione per nomi di dominio alternativi**

1. Accedi a Console di gestione AWS e apri la CloudFront console all'indirizzo[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Scegli l'ID della distribuzione che intendi aggiornare.

1. Nella scheda **General (Generale)**, seleziona **Edit (Modifica)**.

1. Aggiorna i seguenti valori:  
**Nome di dominio alternativo (CNAME)**  
Selezionare **Aggiungi elemento** per aggiungere i nomi di dominio alternativi applicabili. Separa i nomi di dominio con le virgole o digita ogni nome di dominio su una riga.  
**Certificato SSL personalizzato**  
Seleziona un certificato dall'elenco a discesa.  
Di seguito sono elencati fino a 100 certificati. Se disponi di più di 100 certificati e non riesci a visualizzare il certificato che desideri aggiungere, puoi digitare un ARN del certificato nel campo per la selezione.  
Se hai caricato un certificato nell'archivio certificati IAM ma non è elencato e non puoi selezionarlo digitandone il nome nel campo, consulta la procedura [Importa un certificato SSL/TLS](#cnames-and-https-uploading-certificates) per avere la conferma del suo corretto caricamento.   
Dopo aver associato il SSL/TLS certificato alla CloudFront distribuzione, non eliminarlo da ACM o dall'archivio certificati IAM finché non lo rimuovi da tutte le distribuzioni e tutte le distribuzioni non sono state distribuite.

1. Scegli **Save changes** (Salva modifiche).

1. Configura CloudFront per richiedere HTTPS tra i visualizzatori e: CloudFront

   1. Nella scheda **Behaviors (Comportamenti)**, seleziona il comportamento cache che desideri aggiornare, quindi seleziona **Edit (Modifica)**.

   1. Specifica uno dei valori seguenti per **Viewer Protocol Policy (Policy protocollo visualizzatore)**:  
**Reindirizza HTTP a HTTPS**  
I visualizzatori possono utilizzare entrambi i protocolli, ma le richieste HTTP vengono automaticamente reindirizzate alle richieste HTTPS. CloudFront restituisce il codice di stato HTTP `301 (Moved Permanently)` con il nuovo URL HTTPS. Il visualizzatore invia quindi nuovamente la richiesta CloudFront utilizzando l'URL HTTPS.  
CloudFront non reindirizza`DELETE`, `OPTIONS` `PATCH``POST`, o `PUT` le richieste da HTTP a HTTPS. Se configuri un comportamento della cache per il reindirizzamento a HTTPS, CloudFront risponde a HTTP,`DELETE`, `OPTIONS` `PATCH``POST`, o `PUT` alle richieste relative a tale comportamento della cache con il codice di stato HTTP. `403 (Forbidden)`
Quando un visualizzatore effettua una richiesta HTTP che viene reindirizzata a una richiesta HTTPS, vengono CloudFront addebitati i costi per entrambe le richieste. Per la richiesta HTTP, l'addebito è solo per la richiesta e per le intestazioni che CloudFront restituisce al visualizzatore. Per la richiesta HTTPS, l'addebito è per la richiesta, le intestazione e il file restituiti dal server di origine.  
**Solo HTTPS**  
I visualizzatori possono accedere ai contenuti solo se utilizzano connessioni HTTPS. Se un visualizzatore invia una richiesta HTTP anziché una richiesta HTTPS, CloudFront restituisce il codice di stato HTTP `403 (Forbidden)` e non restituisce il file.

   1. Seleziona **Yes, Edit (Sì, modifica)**.

   1. Ripeti le fasi da "a" a "c" per ciascun comportamento cache aggiuntivo per il quale desideri richiedere una connessione HTTPS tra visualizzatori e CloudFront.

1. Conferma ciò che segue prima di utilizzare la configurazione aggiornata in un ambiente di produzione:
   + Il modello di percorso in ciascun comportamento cache si applica solo alle richieste per le quali desideri che i visualizzatori utilizzino una connessione HTTPS.
   + I comportamenti cache sono elencati nell'ordine in cui desideri vengano valutati da CloudFront. Per ulteriori informazioni, consulta [Modello di percorso](DownloadDistValuesCacheBehavior.md#DownloadDistValuesPathPattern).
   + I comportamenti cache sono richieste di routing ai server di origine corretti. 

# Determina la dimensione della chiave pubblica in un certificato SSL/TLS RSA
<a name="cnames-and-https-size-of-public-key"></a>

Quando utilizzi nomi di dominio CloudFront alternativi e HTTPS, la dimensione massima della chiave pubblica in un certificato SSL/TLS RSA è di 4096 bit. (Questa è la dimensione della chiave, non si riferisce al numero di caratteri nella chiave pubblica.) Se utilizzi AWS Certificate Manager per i tuoi certificati, sebbene ACM supporti chiavi RSA più grandi, non puoi utilizzare le chiavi più grandi con. CloudFront

Puoi stabilire le dimensioni della chiave pubblica RSA eseguendo il seguente comando OpenSSL:

```
openssl x509 -in path and filename of SSL/TLS certificate -text -noout 
```

Dove:
+ `-in`specifica il percorso e il nome del file del certificato RSA. SSL/TLS 
+ `-text` fa sì che OpenSSL visualizzi la lunghezza della chiave pubblica RSA in bit.
+ `-noout` impedisce a OpenSSL di visualizzare la chiave pubblica.

Output di esempio:

```
Public-Key: (2048 bit)
```

# Aumenta le quote per i certificati SSL/TLS
<a name="increasing-the-limit-for-ssl-tls-certificates"></a>

Esistono quote sul numero di SSL/TLS certificati che puoi importare in AWS Certificate Manager (ACM) o caricare su (IAM). AWS Identity and Access Management Esiste anche una quota sul numero di SSL/TLS certificati che è possibile utilizzare Account AWS quando si configura CloudFront per soddisfare le richieste HTTPS utilizzando indirizzi IP dedicati. Tuttavia, puoi richiedere quote più elevate.

**Topics**
+ [

## Aumento della quota sui certificati importati in ACM
](#certificates-to-import-into-acm)
+ [

## Aumento della quota sui certificati caricati su IAM
](#certificates-to-upload-into-iam)
+ [

## Aumento della quota sui certificati utilizzati con indirizzi IP dedicati
](#certificates-using-dedicated-ip-address)

## Aumento della quota sui certificati importati in ACM
<a name="certificates-to-import-into-acm"></a>

Per la quota relativa al numero di certificati che puoi importare in ACM, consulta [Quote](https://docs.aws.amazon.com/acm/latest/userguide/acm-limits.html) nella *Guida per l'utente di AWS Certificate Manager *.

Per richiedere una quota più elevata, utilizza la console Service Quotas. Per ulteriori informazioni, consulta [Richiesta di un aumento delle quote nella ](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)Guida per l’utente di Service Quotas**.

## Aumento della quota sui certificati caricati su IAM
<a name="certificates-to-upload-into-iam"></a>

Per la quota (precedentemente nota come limite) sul numero di certificati che puoi caricare su IAM, consulta [IAM e quote STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-limits.html) nella *Guida per l'utente IAM*.

Per richiedere una quota più elevata, utilizza la console Service Quotas. Per ulteriori informazioni, consulta [Richiesta di un aumento delle quote nella ](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)Guida per l’utente di Service Quotas**.

## Aumento della quota sui certificati utilizzati con indirizzi IP dedicati
<a name="certificates-using-dedicated-ip-address"></a>

Per la quota relativa al numero di certificati SSL che puoi utilizzare per ciascuno di essi Account AWS quando gestisci richieste HTTPS utilizzando indirizzi IP dedicati, [Quote sui certificati SSL](cloudfront-limits.md#limits-ssl-certificates) consulta.

Per richiedere una quota più elevata, utilizza la console Service Quotas. Per ulteriori informazioni, consulta [Richiesta di un aumento delle quote nella ](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)Guida per l’utente di Service Quotas**.

# Ruota SSL/TLS i certificati
<a name="cnames-and-https-rotate-certificates"></a>

Quando i SSL/TLS certificati sono prossimi alla scadenza, devi ruotarli per garantire la sicurezza della distribuzione ed evitare interruzioni del servizio per i tuoi spettatori. Puoi ruotarli nei modi seguenti:
+ Per SSL/TLS i certificati forniti da AWS Certificate Manager (ACM), non è necessario ruotarli. ACM gestisce *automaticamente* i rinnovi dei certificati. Per ulteriori informazioni, consulta [Rinnovo dei certificati gestiti](https://docs.aws.amazon.com/acm/latest/userguide/acm-renewal.html) nella *Guida per l’utente di AWS Certificate Manager *.
+ Se si utilizza un’autorità di certificazione di terze parti e si sono importati i certificati in ACM (consigliato) o li si è caricati nell’archivio certificati IAM, è necessario sostituire occasionalmente un certificato con un altro.

  

**Importante**  
ACM non gestisce i rinnovi di certificati acquisiti da autorità di certificazione di terze parti e importati in ACM.
Se sei configurato CloudFront per soddisfare le richieste HTTPS utilizzando indirizzi IP dedicati, potresti incorrere in un costo aggiuntivo proporzionale per l'utilizzo di uno o più certificati aggiuntivi durante la rotazione dei certificati. Ti consigliamo di aggiornare le distribuzioni per ridurre al minimo i costi aggiuntivi.

## Ruota i certificati SSL/TLS
<a name="rotate-ssl-tls-certificate"></a>

Per ruotare i certificati, esegui la procedura seguente. I visualizzatori possono continuare ad accedere ai tuoi contenuti mentre ruoti i certificati e una volta completato il processo.<a name="rotate-ssl-tls-certificates-proc"></a>

**Per ruotare i certificati SSL/TLS**

1. [Aumenta le quote per i certificati SSL/TLS](increasing-the-limit-for-ssl-tls-certificates.md) per stabilire se hai bisogno dell'autorizzazione per utilizzare altri certificati SSL. In questo caso, richiedi l'autorizzazione e attendi fino a quando non l'hai ricevuta prima di continuare con la fase 2.

1. Importa il nuovo certificato in ACM o caricalo su IAM. Per ulteriori informazioni, consulta [Importazione di un SSL/TLS certificato](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cnames-and-https-procedures.html#cnames-and-https-uploading-certificates) nella *Amazon CloudFront Developer Guide*.

1. (Solo per certificati IAM) Aggiorna le distribuzioni una alla volta per utilizzare il nuovo certificato. Per ulteriori informazioni, consulta [Aggiornamento di una distribuzione](HowToUpdateDistribution.md).

1. (Facoltativo) Elimina il certificato precedente da ACM o IAM.
**Importante**  
Non eliminare un SSL/TLS certificato finché non lo rimuovi da tutte le distribuzioni e finché lo stato delle distribuzioni che hai aggiornato non è cambiato. `Deployed`

# Passa da un SSL/TLS certificato personalizzato al certificato predefinito CloudFront
<a name="cnames-and-https-revert-to-cf-certificate"></a>

Se hai configurato CloudFront l'uso di HTTPS tra i visualizzatori e CloudFront hai configurato CloudFront per utilizzare un SSL/TLS certificato personalizzato, puoi modificare la configurazione per utilizzare il certificato CloudFront SSL/TLS predefinito. Il processo dipende dal fatto se hai utilizzato la tua distribuzione per distribuire i tuoi contenuti:
+ Se non hai utilizzato la tua distribuzione per distribuire i contenuti, puoi semplicemente modificare la configurazione. Per ulteriori informazioni, consulta [Aggiornamento di una distribuzione](HowToUpdateDistribution.md).
+ Se hai utilizzato la tua distribuzione per distribuire i contenuti, devi creare una nuova CloudFront distribuzione e modificare i file URLs per ridurre o eliminare il periodo di indisponibilità dei contenuti. A questo scopo, esegui la procedura seguente.

## Ripristina il certificato predefinito CloudFront
<a name="revert-default-cloudfront-certificate"></a>

La procedura seguente mostra come tornare da un SSL/TLS certificato personalizzato al certificato predefinito CloudFront .<a name="cnames-and-https-revert-to-cf-certificate-proc"></a>

**Per tornare al certificato predefinito CloudFront**

1. Crea una nuova CloudFront distribuzione con la configurazione desiderata. Come **Certificato SSL**, seleziona **Certificato CloudFront predefinito (\$1.cloudfront.net)**. 

   Per ulteriori informazioni, consulta [Creazione di una distribuzione](distribution-web-creating-console.md).

1. Per i file che stai distribuendo utilizzando CloudFront, aggiorna l'applicazione URLs in modo da utilizzare il nome di dominio CloudFront assegnato alla nuova distribuzione. Ad esempio, modifica `https://www.example.com/images/logo.png` in `https://d111111abcdef8.cloudfront.net/images/logo.png`.

1. **Elimina la distribuzione associata a un certificato SSL/TLS personalizzato o aggiorna la distribuzione per modificare il valore del certificato **SSL** in Certificato predefinito (\$1.cloudfront.net). CloudFront ** Per ulteriori informazioni, consulta [Aggiornamento di una distribuzione](HowToUpdateDistribution.md).
**Importante**  
Finché non completerai questo passaggio, continuerai ad addebitarti i costi per l'utilizzo di un certificato personalizzato. AWS SSL/TLS 

1. (Facoltativo) Elimina il SSL/TLS certificato personalizzato.

   1. Esegui il AWS CLI comando `list-server-certificates` per ottenere l'ID del certificato che desideri eliminare. Per ulteriori informazioni, consulta [list-server-certificates](https://docs.aws.amazon.com/cli/latest/reference/iam/list-server-certificates.html) nella *documentazione di riferimento dei comandi della AWS CLI *.

   1. Esegui il AWS CLI comando `delete-server-certificate` per eliminare il certificato. Per ulteriori informazioni, consulta [delete-server-certificate](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-server-certificate.html) nella *documentazione di riferimento dei comandi della AWS CLI *.

# Passa da un SSL/TLS certificato personalizzato con indirizzi IP dedicati a SNI
<a name="cnames-and-https-switch-dedicated-to-sni"></a>

Se hai configurato CloudFront per utilizzare un SSL/TLS certificato personalizzato con indirizzi IP dedicati, puoi invece passare all'utilizzo di un SSL/TLS certificato personalizzato con SNI ed eliminare i costi associati agli indirizzi IP dedicati.

**Importante**  
Questo aggiornamento della CloudFront configurazione non ha alcun effetto sui visualizzatori che supportano SNI. Gli utenti possono accedere ai contenuti prima e dopo la modifica, nonché durante la propagazione della modifica verso le sedi periferiche. CloudFront I visualizzatori che non supportano SNI non possono accedere ai contenuti dopo la modifica. Per ulteriori informazioni, consulta [Scegli in che modo CloudFront vengono servite le richieste HTTPS](cnames-https-dedicated-ip-or-sni.md). 

## Passaggio da un certificato personalizzato a SNI
<a name="cloudfront-switch-custom-cert-sni"></a>

La procedura seguente mostra come passare da un SSL/TLS certificato personalizzato con indirizzi IP dedicati a SNI.<a name="cnames-and-https-switch-dedicated-to-sni-proc"></a>

**Per passare da un SSL/TLS certificato personalizzato con indirizzi IP dedicati a SNI**

1. Accedi a Console di gestione AWS e apri la CloudFront console all'indirizzo[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Seleziona l'ID della distribuzione che desideri visualizzare o aggiornare.

1. Seleziona **Distribution Settings (Impostazioni distribuzione)**.

1. Nella scheda **General (Generale)**, seleziona **Edit (Modifica)**.

1. In **Certificazione SSL personalizzata – *facoltativa***, deseleziona **Supporto per client legacy**.

1. Seleziona **Yes, Edit (Sì, modifica)**.

# Autenticazione TLS reciproca con CloudFront (Viewer mTLS)
<a name="mtls-authentication"></a>

L'autenticazione TLS reciproca (Mutual Transport Layer Security Authentication — MTLS) è un protocollo di sicurezza che estende l'autenticazione TLS standard richiedendo l'autenticazione bidirezionale basata su certificati, in cui sia il client che il server devono dimostrare la propria identità prima di stabilire una connessione sicura. Utilizzando Mutual TLS, puoi garantire che solo i client che presentano certificati TLS affidabili abbiano accesso alle tue distribuzioni. CloudFront 

## Come funziona
<a name="how-mtls-works"></a>

In un handshake TLS standard, solo il server presenta un certificato per dimostrare la propria identità al client. Con il TLS reciproco, il processo di autenticazione diventa bidirezionale. Quando un client tenta di connettersi alla tua CloudFront distribuzione, CloudFront richiede un certificato client durante l'handshake TLS. Il client deve presentare un certificato X.509 valido che sia CloudFront convalidato rispetto all'archivio di fiducia configurato prima di stabilire la connessione sicura.

CloudFront esegue la convalida del certificato presso le AWS edge location, alleggerendo la complessità dell'autenticazione dai server di origine e mantenendo CloudFront al contempo i vantaggi in termini di prestazioni globali. È possibile configurare gli MTL in due modalità: modalità di verifica (che richiede a tutti i client di presentare certificati validi) o modalità opzionale (che convalida i certificati quando vengono presentati ma consente anche connessioni senza certificati).

## Casi d’uso
<a name="mtls-use-cases"></a>

L'autenticazione TLS reciproca CloudFront risolve diversi scenari di sicurezza critici in cui i metodi di autenticazione tradizionali sono insufficienti:
+ **Autenticazione dei dispositivi con memorizzazione nella cache dei contenuti**: puoi autenticare console di gioco, dispositivi IoT o hardware aziendale prima di consentire l'accesso agli aggiornamenti del firmware, ai download di giochi o alle risorse interne. Ogni dispositivo contiene un certificato unico che ne dimostra l'autenticità sfruttando al contempo le funzionalità di memorizzazione nella cache. CloudFront
+ **API-to-API autenticazione**: è possibile proteggere le machine-to-machine comunicazioni tra partner commerciali, sistemi di pagamento o microservizi affidabili. L'autenticazione basata su certificati elimina la necessità di chiavi API o segreti condivisi, fornendo al contempo una solida verifica dell'identità per gli scambi automatici di dati.

**Topics**
+ [

## Come funziona
](#how-mtls-works)
+ [

## Casi d’uso
](#mtls-use-cases)
+ [

# Archivi di fiducia e gestione dei certificati
](trust-stores-certificate-management.md)
+ [

# Abilita il TLS reciproco per le distribuzioni CloudFront
](enable-mtls-distributions.md)
+ [

# Associare una funzione di CloudFront connessione
](connection-functions.md)
+ [

# Configurazione di impostazioni aggiuntive
](configuring-additional-settings.md)
+ [

# Visualizza le intestazioni MTLS per le politiche della cache e le inoltra all'origine
](viewer-mtls-headers.md)
+ [

# Revoca tramite CloudFront Connection Function e KVS
](revocation-connection-function-kvs.md)
+ [

# Osservabilità tramite log di connessione
](connection-logs.md)

# Archivi di fiducia e gestione dei certificati
<a name="trust-stores-certificate-management"></a>

La creazione e la configurazione di un trust store è un requisito obbligatorio per implementare l'autenticazione TLS reciproca con. CloudFront I trust store contengono i certificati Certificate Authority (CA) CloudFront utilizzati per convalidare i certificati client durante il processo di autenticazione.

## Cos'è un trust store?
<a name="what-is-trust-store"></a>

Un trust store è un archivio di certificati CA CloudFront utilizzato per convalidare i certificati client durante l'autenticazione TLS reciproca. Gli archivi di fiducia contengono i certificati CA root e intermedi che costituiscono la catena di fiducia per l'autenticazione dei certificati client.

Quando si implementa il TLS reciproco con CloudFront, il trust store definisce le autorità di certificazione attendibili per l'emissione di certificati client validi. CloudFront convalida ogni certificato client confrontandolo con il trust store durante l'handshake TLS. Solo i client che presentano certificati collegati a uno dei certificati presenti CAs nel tuo trust store verranno autenticati correttamente.

I trust store in CloudFront sono risorse a livello di account che puoi associare a più distribuzioni. Ciò consente di mantenere politiche di convalida dei certificati coerenti durante l'intera CloudFront distribuzione, semplificando al contempo la gestione dei certificati CA.

## Supporto dell'Autorità di Certificazione
<a name="ca-support"></a>

CloudFront supporta i certificati emessi da autorità di certificazione AWS private e autorità di certificazione private di terze parti. Questa flessibilità consente di utilizzare l'infrastruttura di certificazione esistente o di sfruttare i servizi di certificazione AWS gestiti in base ai requisiti organizzativi.
+ **AWS Autorità di certificazione privata:** è possibile utilizzare i certificati emessi da AWS Private CA, che fornisce un servizio gestito di autorità di certificazione privata. Questa integrazione semplifica la gestione del ciclo di vita dei certificati e offre una perfetta integrazione con altri servizi. AWS 
+ **Autorità di certificazione private di terze parti:** puoi anche utilizzare i certificati della tua infrastruttura di autorità di certificazione privata esistente, inclusi fornitori di certificati aziendali CAs o di altri fornitori di certificati di terze parti. Ciò consente di mantenere gli attuali processi di gestione dei certificati aggiungendo CloudFront al contempo le funzionalità mTLS.

## Requisiti e specifiche del certificato
<a name="certificate-requirements"></a>

I trust store hanno requisiti specifici per i certificati CA che contengono:

### Requisiti di formato dei certificati CA
<a name="ca-cert-format-requirements"></a>
+ **Formato: formato** PEM (Privacy Enhanced Mail)
+ **Limiti del contenuto: i certificati devono essere racchiusi entro i limiti** -----BEGIN CERTIFICATE----- e -----END CERTIFICATE-----
+ **Commenti:** deve essere preceduto da un carattere \$1 e non può contenere alcun carattere -
+ **Interruzioni di riga:** non sono consentite righe vuote tra i certificati

### Specifiche dei certificati supportate
<a name="supported-cert-specs"></a>
+ **Tipo di certificato: X.509v3**
+ **Tipi di chiavi pubbliche:**
  + RSA 2048, RSA 3072, RSA 4096
  + ECDSA: secp256r1, secp384r1
+ **Algoritmi di firma:**
  + SHA256 SHA384, SHA512 con RSA
  + SHA256 SHA384, SHA512 con EC
  + SHA256 SHA384, SHA512 con RASSA-PSS con MGF1

### Esempio di formato del pacchetto di certificati
<a name="example-cert-bundle"></a>

Certificati multipli (con codifica PEM):

```
# Root CA Certificate
-----BEGIN CERTIFICATE-----
MIIDXTCCAkWgAwIBAgIJAKoK/OvD/XqiMA0GCSqGSIb3DQEBCwUAMEUxCzAJBgNV
BAYTAkFVMRMwEQYDVQQIDApTb21lLVN0YXRlMSEwHwYDVQQKDBhJbnRlcm5ldCBX
aWRnaXRzIFB0eSBMdGQwHhcNMTcwNzEyMTU0NzQ4WhcNMjcwNzEwMTU0NzQ4WjBF
MQswCQYDVQQGEwJBVTETMBEGA1UECAwKU29tZS1TdGF0ZTEhMB8GA1UECgwYSW50
ZXJuZXQgV2lkZ2l0cyBQdHkgTHRkMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAuuExKvY1xzHFylsHiuowqpmzs7rEcuuylOuEszpFp+BtXh0ZuEtts9LP
-----END CERTIFICATE-----
# Intermediate CA Certificate
-----BEGIN CERTIFICATE-----
MIIDXTCCAkWgAwIBAgIJAKoK/OvD/XqjMA0GCSqGSIb3DQEBCwUAMEUxCzAJBgNV
BAYTAkFVMRMwEQYDVQQIDApTb21lLVN0YXRlMSEwHwYDVQQKDBhJbnRlcm5ldCBX
aWRnaXRzIFB0eSBMdGQwHhcNMTcwNzEyMTU0NzQ4WhcNMjcwNzEwMTU0NzQ4WjBF
MQswCQYDVQQGEwJBVTETMBEGA1UECAwKU29tZS1TdGF0ZTEhMB8GA1UECgwYSW50
ZXJuZXQgV2lkZ2l0cyBQdHkgTHRkMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAuuExKvY1xzHFylsHiuowqpmzs7rEcuuylOuEszpFp+BtXh0ZuEtts9LP
-----END CERTIFICATE-----
```

## Crea un archivio di fiducia
<a name="create-trust-store"></a>

Prima di creare un trust store, devi caricare il tuo pacchetto di certificati CA in formato PEM in un bucket Amazon S3. Il pacchetto di certificati deve contenere tutti i certificati CA root e intermedi affidabili necessari per convalidare i certificati client.

Il pacchetto di certificati CA viene letto solo una volta da S3 durante la creazione di un trust store. Se verranno apportate modifiche future al pacchetto di certificati CA, il trust store dovrà essere aggiornato manualmente. Non viene mantenuta alcuna sincronizzazione tra il trust store e il pacchetto di certificati CA S3.

### Prerequisiti
<a name="trust-store-prerequisites"></a>
+ Un pacchetto di certificati della tua Certificate Authority (CA) caricato in un bucket Amazon S3
+ Le autorizzazioni necessarie per creare risorse CloudFront 

### Per creare un trust store (Console)
<a name="create-trust-store-console"></a>

1. Accedi a Console di gestione AWS e apri la CloudFront console all'indirizzo[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Nel pannello di navigazione, scegli **Trust stores**.

1. Scegli **Create Trust Store**.

1. Per il **nome del Trust Store**, inserisci un nome per il tuo Trust Store.

1. Per il **pacchetto Certificate Authority (CA)**, inserisci il percorso Amazon S3 del tuo pacchetto di certificati CA in formato PEM.

1. **Scegli** Create trust store.

### Per creare un trust store (AWS CLI)
<a name="create-trust-store-cli"></a>

```
aws cloudfront create-trust-store \
  --name MyTrustStore \
  --ca-certificates-bundle-source '{"CaCertificatesBundleS3Location":{"Bucket":"my-bucket","Key":"ca-bundle.pem","Region":"bucket-region"}}' \
  --tags Items=[{Key=Environment,Value=Production}]
```

## Associa trust store alle distribuzioni
<a name="associate-trust-store"></a>

Dopo aver creato un trust store, è necessario associarlo a una CloudFront distribuzione per abilitare l'autenticazione TLS reciproca.

### Prerequisiti
<a name="associate-prerequisites"></a>
+ Una CloudFront distribuzione esistente con la politica del protocollo di visualizzazione solo HTTPS abilitata e HTTP3 il supporto disabilitato.

### Per associare un trust store (Console)
<a name="associate-trust-store-console"></a>

Esistono due modi per associare un trust store all'interno della CloudFront console: tramite la pagina dei dettagli del trust store o tramite la pagina delle impostazioni di distribuzione.

**Associare un trust store tramite la pagina dei dettagli del trust store:**

1. Accedi a Console di gestione AWS e apri la CloudFront console all'indirizzo[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Nel pannello di navigazione, scegli **Trust stores**.

1. Scegli il nome del trust store che desideri associare.

1. Scegli **Associa alla distribuzione**.

1. Configura le opzioni Viewer MTLs disponibili:
   + Modalità **di convalida del certificato client: scegli tra la modalità** obbligatoria e quella opzionale. Nella modalità richiesta, tutti i client devono presentare i certificati. In modalità opzionale, i client che presentano certificati vengono convalidati, mentre ai client che non presentano certificati è consentito l'accesso.
   + **Pubblicizza i nomi delle CA del trust store:** scegli se pubblicizzare i nomi delle CA nel tuo trust store ai clienti durante l'handshake TLS.
   + **Ignora la data di scadenza del certificato:** scegli se consentire le connessioni con certificati scaduti (valgono ancora altri criteri di convalida).
   + **Funzione di connessione:** una funzione di connessione opzionale può essere associata alle allow/deny connessioni basate su altri criteri personalizzati.

1. Seleziona una o più distribuzioni da associare al trust store. Solo le distribuzioni con comportamenti di cache HTTP3 disabilitati e con comportamento di cache basato solo su HTTPS possono supportare Viewer MTL.

1. Selezionare **Associate (Associa)**.

**Associazione di un trust store tramite la pagina delle impostazioni di distribuzione:**

1. Accedi a Console di gestione AWS e apri la CloudFront console all'indirizzo[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Seleziona la distribuzione che desideri associare

1. Nella scheda **Generale**, all'interno del contenitore **Impostazioni**, scegli **Modifica** nell'angolo in alto a destra

1. Scorri verso il basso fino alla fine della pagina, all'interno del contenitore **Connectivity**, attiva l'opzione **Viewer MTLs**

1. Configura le opzioni Viewer MTLs disponibili:
   + Modalità **di convalida del certificato client: scegli tra la modalità** obbligatoria e quella opzionale. Nella modalità richiesta, tutti i client devono presentare i certificati. In modalità opzionale, i client che presentano certificati vengono convalidati, mentre ai client che non presentano certificati è consentito l'accesso.
   + **Pubblicizza i nomi delle CA del trust store:** scegli se pubblicizzare i nomi delle CA nel tuo trust store ai clienti durante l'handshake TLS.
   + **Ignora la data di scadenza del certificato:** scegli se consentire le connessioni con certificati scaduti (valgono ancora altri criteri di convalida).
   + **Funzione di connessione:** una funzione di connessione opzionale può essere associata alle allow/deny connessioni basate su altri criteri personalizzati.

1. Scegli **Salva modifiche** nell'angolo in basso a destra.

### Per associare un trust store (AWS CLI)
<a name="associate-trust-store-cli"></a>

I trust store possono essere associati alle distribuzioni tramite. DistributionConfig ViewerMtlsConfig proprietà. Ciò significa che dobbiamo prima recuperare la configurazione della distribuzione e poi fornirla ViewerMtlsConfig in una richiesta successiva UpdateDistribution .

```
// First fetch the distribution
aws cloudfront get-distribution {DISTRIBUTION_ID}

// Update the distribution config, for example:
Distribution config, file://distConf.json: 
{
  ...other fields,
  ViewerMtlsConfig: {
    Mode: 'required',
    TrustStoreConfig: {
        AdvertiseTrustStoreCaNames: false,
        IgnoreCertificateExpiry: true,
        TrustStoreId: {TRUST_STORE_ID}
    }
  }
}

aws cloudfront update-distribution \
   --id {DISTRIBUTION_ID} \
   --if-match {ETAG} \
   --distribution-config file://distConf.json
```

## Gestisci gli archivi di fiducia
<a name="manage-trust-stores"></a>

### Visualizza i dettagli del Trust Store
<a name="view-trust-store-details"></a>

1. Accedi Console di gestione AWS e apri la CloudFront console all'indirizzo[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Nel pannello di navigazione, scegli **Trust stores**.

1. Scegli il nome del trust store per visualizzarne la pagina dei dettagli.

La pagina dei dettagli mostra:
+ Nome e ID del Trust Store
+ Numero di certificati CA
+ Data di creazione e data dell'ultima modifica
+ Distribuzioni associate
+ Tag

### Modificare un trust store
<a name="modify-trust-store"></a>

Per sostituire il pacchetto di certificati CA:

1. Accedi a Console di gestione AWS e apri la CloudFront console all'indirizzo[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Nel pannello di navigazione, scegli **Trust stores**.

1. Scegli il nome del trust store.

1. Scegli **Azioni**, quindi **Modifica**.

1. Per il **pacchetto Certificate Authority (CA)**, inserisci la posizione Amazon S3 del file PEM del pacchetto CA aggiornato.

1. **Scegli Update trust store.**

### Elimina un trust store
<a name="delete-trust-store"></a>

**Prerequisiti:** è innanzitutto necessario dissociare il trust store da tutte le CloudFront distribuzioni.

1. Accedi a Console di gestione AWS e apri la console all' CloudFront indirizzo. [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home)

1. Nel pannello di navigazione, scegli **Trust stores**.

1. Scegli il nome del trust store.

1. Scegli **Elimina trust store**.

1. Seleziona **Elimina** per confermare.

### Fasi successive
<a name="trust-store-next-steps"></a>

Dopo aver creato e associato il tuo trust store a una CloudFront distribuzione, puoi procedere ad abilitare l'autenticazione TLS reciproca sulla tua distribuzione e configurare impostazioni aggiuntive come l'inoltro delle intestazioni dei certificati alle tue origini. Per istruzioni dettagliate sull'abilitazione degli MTL sulle distribuzioni, consulta. [Abilita il TLS reciproco per le distribuzioni CloudFront](enable-mtls-distributions.md)

# Abilita il TLS reciproco per le distribuzioni CloudFront
<a name="enable-mtls-distributions"></a>

## Prerequisiti e requisiti
<a name="mtls-prerequisites-requirements"></a>

CloudFrontla modalità di verifica TLS reciproca richiede che tutti i client presentino certificati validi durante l'handshake TLS e rifiuta le connessioni senza certificati validi. Prima di abilitare il TLS reciproco su una CloudFront distribuzione, assicurati di avere:
+ Hai creato un trust store con i tuoi certificati di Certificate Authority
+ Hai associato il trust store alla tua CloudFront distribuzione
+ È stato garantito che tutti i comportamenti della cache di distribuzione utilizzino una politica del protocollo di visualizzazione solo HTTPS
+ Assicurati che la tua distribuzione utilizzi HTTP/2 (l'impostazione predefinita, Viewer MTLs non è supportata su HTTP/3)

**Nota**  
L'autenticazione TLS reciproca richiede connessioni HTTPS tra i visualizzatori e. CloudFront Non è possibile abilitare MTL su una distribuzione con comportamenti di cache che supportano le connessioni HTTP.

## Abilita il TLS reciproco (Console)
<a name="enable-mtls-console"></a>

### Per nuove distribuzioni
<a name="enable-mtls-new-distributions"></a>

I Viewer MTL non possono essere configurati durante il processo di creazione di una nuova distribuzione nella CloudFront console. Innanzitutto crea la distribuzione con qualsiasi mezzo (console, CLI, API), quindi modifica le impostazioni di distribuzione per abilitare Viewer MTL secondo le istruzioni di distribuzione esistenti riportate di seguito.

### Per le distribuzioni esistenti
<a name="enable-mtls-existing-distributions"></a>

1. Accedi a Console di gestione AWS e apri la CloudFront console all'indirizzo[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Dalla lista di distribuzione, seleziona la distribuzione che desideri modificare.

1. Assicurati che la politica del protocollo Viewer sia impostata su **Reindirizza HTTP su HTTPS** o **Solo HTTPS** per tutti i comportamenti della cache. (Puoi scegliere la scheda **Comportamenti della cache** per visualizzare e aggiornare qualsiasi comportamento della cache con le politiche del protocollo HTTP).

1. Scegli la scheda **Generale**.

1. Nella sezione **Settings** (Impostazioni), scegli **Edit** (Modifica).

1. Nella sezione **Connettività**, trova **Viewer Mutual Authentication (MTLs).**

1. Attiva **Abilita l'autenticazione reciproca**.

1. Per la **modalità di convalida del certificato client**, seleziona **Obbligatorio** (tutti i client devono presentare certificati) o **Facoltativo (i client possono facoltativamente** presentare certificati).

1. Per **Trust store**, seleziona il trust store creato in precedenza.

1. (Facoltativo) Seleziona **Pubblicizza i nomi CA del trust store se desideri CloudFront inviare i nomi** CA ai client durante l'handshake TLS.

1. (Facoltativo) Attiva **Ignora la data di scadenza del certificato** se desideri consentire le connessioni con certificati scaduti.

1. Scegli **Save changes** (Salva modifiche).

## Abilita TLS reciproco (AWS CLI)
<a name="enable-mtls-cli"></a>

### Per nuove distribuzioni
<a name="enable-mtls-cli-new"></a>

L'esempio seguente mostra come creare un file di configurazione della distribuzione (distribution-config.json) che includa le impostazioni MTLS:

```
{
  "CallerReference": "cli-example-1",
  "Origins": {
    "Quantity": 1,
    "Items": [
      {
        "Id": "my-origin",
        "DomainName": "example.com",
        "CustomOriginConfig": {
          "HTTPPort": 80,
          "HTTPSPort": 443,
          "OriginProtocolPolicy": "https-only"
        }
      }
    ]
  },
  "DefaultCacheBehavior": {
    "TargetOriginId": "my-origin",
    "ViewerProtocolPolicy": "https-only",
    "MinTTL": 0,
    "ForwardedValues": {
      "QueryString": false,
      "Cookies": {
        "Forward": "none"
      }
    }
  },
  "ViewerCertificate": {
    "CloudFrontDefaultCertificate": true
  },
  "ViewerMtlsConfig": {
    "Mode": "required", 
    "TrustStoreConfig": {
        "TrustStoreId": {TRUST_STORE_ID},
        "AdvertiseTrustStoreCaNames": true,
        "IgnoreCertificateExpiry": true
    }
  },
  "Enabled": true
}
```

Crea la distribuzione con MTL abilitati utilizzando il seguente comando di esempio:

```
aws cloudfront create-distribution --distribution-config file://distribution-config.json
```

### Per le distribuzioni esistenti
<a name="enable-mtls-cli-existing"></a>

Ottieni la configurazione corrente della distribuzione utilizzando il seguente comando di esempio:

```
aws cloudfront get-distribution-config --id E1A2B3C4D5E6F7 --output json > dist-config.json
```

Modifica il file per aggiungere le impostazioni mTLS. Aggiungete la seguente sezione di esempio alla configurazione della distribuzione:

```
"ViewerMtlsConfig": {
    "Mode": "required", 
    "TrustStoreConfig": {
        "TrustStoreId": {TRUST_STORE_ID},
        "AdvertiseTrustStoreCaNames": true,
        "IgnoreCertificateExpiry": true
    }
}
```

Rimuovi il ETag campo dal file ma salva il suo valore separatamente.

Aggiorna la distribuzione con la nuova configurazione usando il seguente comando di esempio:

```
aws cloudfront update-distribution \
    --id E1A2B3C4D5E6F7 \
    --if-match YOUR-ETAG-VALUE \
    --distribution-config file://dist-config.json
```

## Politiche del protocollo Viewer
<a name="viewer-protocol-policies"></a>

Quando si utilizza il protocollo TLS reciproco, tutti i comportamenti della cache di distribuzione devono essere configurati con una politica del protocollo di visualizzazione basata esclusivamente su HTTPS:
+ **Reindirizza da HTTP a HTTPS**: reindirizza le richieste HTTP a HTTPS prima di eseguire la convalida del certificato.
+ **Solo HTTPS: accetta solo** richieste HTTPS ed esegue la convalida dei certificati.

**Nota**  
La politica del protocollo di visualizzazione HTTP e HTTPS non è supportata con TLS reciproco poiché le connessioni HTTP non possono eseguire la convalida dei certificati.

## Fasi successive
<a name="enable-mtls-next-steps"></a>

Dopo aver abilitato Viewer TLS sulla tua CloudFront distribuzione, puoi associare le funzioni di connessione per implementare una logica di convalida dei certificati personalizzata. Le funzioni di connessione consentono di estendere le funzionalità di autenticazione MTLS integrate con regole di convalida personalizzate, controllo della revoca dei certificati e registrazione. Per i dettagli sulla creazione e l'associazione delle funzioni di connessione, vedere. [Associare una funzione di CloudFront connessione](connection-functions.md)

# Associare una funzione di CloudFront connessione
<a name="connection-functions"></a>

CloudFront Le funzioni di connessione consentono di implementare una logica di convalida dei certificati personalizzata durante gli handshake TLS, fornendo estensioni alle funzionalità di autenticazione MTLS integrate.

## Cosa sono le funzioni di connessione?
<a name="what-are-connection-functions"></a>

Le funzioni di connessione sono JavaScript funzioni che vengono eseguite durante l'handshake TLS dopo la convalida dei certificati client. Il certificato client convalidato viene passato alla funzione di connessione, a quel punto la funzione di connessione può determinare ulteriormente se concedere o meno l'accesso. Per informazioni dettagliate sulle funzioni di connessione, vedere[Personalizza a 360° con CloudFront Functions](cloudfront-functions.md).

## Come funzionano le funzioni di connessione con le MTL
<a name="how-connection-functions-work"></a>

Quando un client tenta di stabilire una connessione mTLS alla CloudFront distribuzione, si verifica la seguente sequenza:

1. Il client avvia l'handshake TLS con edge location. CloudFront 

1. CloudFront richiede e riceve il certificato del cliente.

1. CloudFront esegue la convalida standard dei certificati rispetto al trust store.

1. Se il certificato supera la convalida standard, CloudFront richiama la funzione di connessione. Se **IgnoreCertificateExpiry**è abilitato all'interno del tuo **ViewerMtlsConfig**, anche i certificati scaduti, ma per il resto validi, vengono passati alla Funzione di connessione. Se i certificati client non sono validi, le funzioni di connessione non verranno richiamate.

1. La tua funzione di connessione riceve informazioni sui certificati e dettagli di connessione analizzati.

1. La tua funzione prende una allow/deny decisione in base a una logica personalizzata.

1. CloudFront completa o termina la connessione TLS in base alla tua decisione.

Le funzioni di connessione vengono richiamate sia per la modalità di verifica che per la modalità opzionale (quando i client presentano certificati).

## Crea una funzione di connessione
<a name="create-connection-function"></a>

È possibile creare funzioni di connessione utilizzando la CloudFront console o la AWS CLI.

### Per creare una funzione di connessione (console)
<a name="create-connection-function-console"></a>

1. Accedi a Console di gestione AWS e apri la CloudFront console all'indirizzo[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Nel riquadro di navigazione, seleziona **Funzioni**.

1. Scegli la scheda **Funzioni di connessione** e scegli **Crea funzione di connessione**.

1. Inserisci un nome di funzione univoco all'interno del tuo AWS account.

1. Scegli **Continua**.

1. Nell'editor delle funzioni, scrivi il JavaScript codice per la convalida del certificato. Il gestore della funzione deve chiamare allow o deny.

1. Facoltativo: è possibile associare un KeyValue archivio alla funzione di connessione per implementare il controllo delle revoce.

1. Scegli **Save changes** (Salva modifiche).

### Per creare una funzione di connessione (AWS CLI)
<a name="create-connection-function-cli"></a>

L'esempio seguente mostra come creare una funzione di connessione:

Scrivi il codice della funzione in un file separato, ad esempio code.js:

```
function connectionHandler(connection) {
  connection.allow();
}
```

```
aws cloudfront create-connection-function \
  --name "certificate-validator" \
  --connection-function-config '{
      "Comment": "Client certificate validation function",
      "Runtime": "cloudfront-js-2.0"
  }' \
  --connection-function-code fileb://code.js
```

## Struttura del codice della funzione di connessione
<a name="connection-function-code-structure"></a>

Le funzioni di connessione implementano la funzione ConnectionHandler che riceve un oggetto di connessione contenente il certificato e le informazioni di connessione. La funzione deve utilizzare una delle due `connection.allow()` opzioni o `connection.deny()` per prendere una decisione sulla connessione.

### Esempio di funzione di connessione di base
<a name="basic-connection-function-example"></a>

L'esempio seguente mostra una semplice funzione di connessione che verifica il campo dell'oggetto dei certificati client:

```
function connectionHandler(connection) {
    // Only process if a certificate was presented
    if (!connection.clientCertificate) {
        console.log("No certificate presented");
        connection.deny();
    }
    
    // Check the subject field for specific organization
    const subject = connection.clientCertificate.certificates.leaf.subject;
    if (!subject.includes("O=ExampleCorp")) {
        console.log("Certificate not from authorized organization");
       connection.deny();
    } else {
        // All checks passed
        console.log("Certificate validation passed");
        connection.allow();
    }
}
```

La specifica completa delle proprietà dei certificati client disponibili sull'oggetto di connessione è disponibile qui:

```
{
  "connectionId": "Fdb-Eb7L9gVn2cFakz7wWyBJIDAD4-oNO6g8r3vXDV132BtnIVtqDA==", // Unique identifier for this TLS connection
  "clientIp": "203.0.113.42", // IP address of the connecting client (IPv4 or IPv6)
  "clientCertificate": {
    "certificates": {
      "leaf": {
        "subject": "CN=client.example.com,O=Example Corp,C=US", // Distinguished Name (DN) of the certificate holder
        "issuer": "CN=Example Corp Intermediate CA,O=Example Corp,C=US", // Distinguished Name (DN) of the certificate authority that issued this certificate
        "serialNumber": "4a:3f:5c:92:d1:e8:7b:6c", // Unique serial number assigned by the issuing CA (hexadecimal)
        "validity": {
          "notBefore": "2024-01-15T00:00:00Z", // Certificate validity start date (ISO 8601 format)
          "notAfter": "2025-01-14T23:59:59Z"   // Certificate expiration date (ISO 8601 format)
        },
        "sha256Fingerprint": "a1b2c3d4e5f6...abc123def456", // SHA-256 hash of the certificate (64 hex characters)
      },
    },
  },
}
```

## Associa una funzione di connessione
<a name="associate-connection-function-section"></a>

Dopo aver creato la funzione di connessione, è necessario pubblicarla nella fase LIVE e associarla alla distribuzione.

### Per pubblicare e associare una funzione di connessione (console)
<a name="publish-associate-console"></a>

1. Accedi a Console di gestione AWS e apri la CloudFront console all'indirizzo[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Nel riquadro di navigazione, scegli **Funzioni**

1. Scegli la scheda **Funzioni di connessione** e seleziona la tua funzione di connessione.

1. Scegli **Pubblica** per spostarlo nella fase LIVE.

1. Scegli **Aggiungi associazione** nella tabella delle distribuzioni associate sotto la sezione di pubblicazione.

1. Seleziona la distribuzione con Viewer MTLs abilitato che desideri associare.

In alternativa, è possibile associare le funzioni di connessione pubblicate anche dalla pagina dei dettagli della distribuzione.

1. Vai alla home page della console dove sono elencate tutte le tue distribuzioni.

1. Seleziona la distribuzione che desideri associare.

1. Scegli la scheda **Generale**.

1. Nella sezione **Settings** (Impostazioni), scegli **Edit** (Modifica).

1. Nella sezione **Connettività**, trova **Viewer Mutual Authentication (MTLs).**

1. Per **Funzione di connessione**, seleziona la tua funzione.

1. Scegli **Save changes** (Salva modifiche).

### Per associare una funzione di connessione (AWS CLI)
<a name="associate-connection-function-cli"></a>

L'esempio seguente mostra come associare una funzione di connessione a una distribuzione:

```
// DistributionConfig:
{
   ...other settings,
    "ConnectionFunctionAssociation": {
        "Id": "cf_30c2CV2elHwCoInb3LtcaUJkZeD"
    }
}
```

## Casi d'uso per le funzioni di connessione
<a name="connection-function-use-cases"></a>

Le funzioni di connessione consentono diversi casi d'uso avanzati di MTL:
+ **Convalida degli attributi del certificato**: verifica campi specifici nei certificati client, come i requisiti delle unità organizzative o i modelli di denominazione alternativi dei soggetti.
+ **Controllo della revoca dei certificati**: implementa il controllo personalizzato della revoca dei certificati utilizzando KeyValueStore per archiviare i numeri di serie dei certificati revocati.
+ **Politiche di certificazione basate su IP: applica politiche di** certificazione diverse in base agli indirizzi IP dei client o alle restrizioni geografiche.
+ Convalida **multi-tenant: implementa regole di convalida** specifiche del tenant in cui si applicano requisiti di certificato diversi in base ai nomi host o agli attributi del certificato.

**Nota**  
Le funzioni di connessione vengono eseguite una volta per connessione client durante l'handshake TLS.  
Le funzioni di connessione possono solo consentire o negare le connessioni, non modificare le richieste/risposte HTTP.  
Solo le funzioni LIVE stage (pubblicate) possono essere associate alle distribuzioni.  
Ogni distribuzione può avere al massimo una funzione di connessione.

## Fasi successive
<a name="connection-function-next-steps"></a>

Dopo aver associato una funzione di connessione alla CloudFront distribuzione, è possibile configurare impostazioni opzionali per personalizzare il comportamento dell'implementazione di MTLS. Per istruzioni dettagliate sulla configurazione di impostazioni aggiuntive come una modalità opzionale di convalida del certificato client, consulta. [Configurazione di impostazioni aggiuntive](configuring-additional-settings.md)

# Configurazione di impostazioni aggiuntive
<a name="configuring-additional-settings"></a>

Dopo aver abilitato l'autenticazione TLS reciproca di base, è possibile configurare impostazioni aggiuntive per personalizzare il comportamento di autenticazione per casi d'uso e requisiti specifici.

## Convalida del certificato client (modalità opzionale)
<a name="optional-mode"></a>

CloudFront offre una modalità alternativa di convalida dei certificati client opzionale che convalida i certificati client presentati ma consente l'accesso ai client che non presentano certificati.

### Comportamento in modalità opzionale
<a name="optional-mode-behavior"></a>
+ Concede la connessione ai client con certificati validi (i certificati non validi vengono negati).
+ Consente la connessione a client senza certificati
+ Consente scenari di autenticazione client misti tramite un'unica distribuzione.

La modalità opzionale è ideale per la migrazione graduale all'autenticazione MTLS, per supportare client con certificati e client senza certificati o per mantenere la retrocompatibilità con i client legacy.

**Nota**  
In modalità opzionale, le funzioni di connessione vengono ancora richiamate anche quando i client non presentano certificati. Ciò consente di implementare una logica personalizzata come la registrazione degli indirizzi IP dei client o l'applicazione di politiche diverse in base alla presentazione dei certificati.

### Per configurare la modalità opzionale (console)
<a name="configure-optional-mode-console"></a>

1. Nelle impostazioni di distribuzione, vai alla scheda **Generale**, scegli **Modifica**.

1. Scorri fino alla sezione **Viewer Mutual Authentication (mTLS)** all'interno del contenitore **Connectivity**.

1. **Per la **modalità di convalida del certificato Client**, seleziona Opzionale.**

1. Salva le modifiche.

### Per configurare la modalità opzionale (AWS CLI)
<a name="configure-optional-mode-cli"></a>

L'esempio seguente mostra come configurare la modalità opzionale:

```
"ViewerMtlsConfig": {
   "Mode": "optional",
   ...other settings
}
```

## Pubblicità dell'Autorità di Certificazione
<a name="ca-advertisement"></a>

Il AdvertiseTrustStoreCaNames campo controlla se CloudFront inviare l'elenco di nomi CA affidabili ai client durante l'handshake TLS, aiutandoli a selezionare il certificato appropriato.

### Per configurare CA advertising (Console)
<a name="configure-ca-advertisement-console"></a>

1. Nelle impostazioni di distribuzione, vai alla scheda **Generale**, scegli **Modifica**.

1. Scorri fino alla sezione **Viewer Mutual Authentication (mTLS)** all'interno del contenitore **Connectivity**.

1. Seleziona o deseleziona la casella di controllo **Advertise trust store CA names**.

1. Scegli **Save changes** (Salva modifiche).

### Per configurare la pubblicità CA (AWS CLI)
<a name="configure-ca-advertisement-cli"></a>

L'esempio seguente mostra come abilitare la pubblicità CA:

```
"ViewerMtlsConfig": {
   "Mode": "required", // or "optional"
   "TrustStoreConfig": {
      "AdvertiseTrustStoreCaNames": true,
      ...other settings
   } 
}
```

## Gestione della scadenza dei certificati
<a name="certificate-expiration-handling"></a>

La IgnoreCertificateExpiry proprietà determina la modalità di CloudFront risposta ai certificati client scaduti. Per impostazione predefinita, CloudFront rifiuta i certificati client scaduti, ma è possibile configurarlo per accettarli quando necessario. In genere è abilitato per i dispositivi con certificati scaduti che non possono essere aggiornati prontamente.

### Per configurare la gestione della scadenza dei certificati (Console)
<a name="configure-expiration-console"></a>

1. Nelle impostazioni di distribuzione, vai alla scheda **Generale**, scegli **Modifica**.

1. Scorri fino alla sezione **Viewer Mutual Authentication (mTLS)** del contenitore **Connectivity**.

1. Seleziona o deseleziona la casella di controllo **Ignora la data di scadenza del certificato**.

1. Scegli **Save changes** (Salva modifiche).

### Per configurare la gestione della scadenza dei certificati (AWS CLI)
<a name="configure-expiration-cli"></a>

L'esempio seguente mostra come ignorare la scadenza dei certificati:

```
"ViewerMtlsConfig": {
  "Mode": "required", // or "optional"
  "TrustStoreConfig": {
     "IgnoreCertificateExpiry": false,
     ...other settings
  }
}
```

**Nota**  
**IgnoreCertificateExpiry**si applica solo alle date di validità dei certificati. Tutti gli altri controlli di convalida dei certificati sono ancora validi (catena di fiducia, convalida della firma).

## Fasi successive
<a name="additional-settings-next-steps"></a>

Dopo aver configurato impostazioni aggiuntive, è possibile configurare l'inoltro delle intestazioni per trasmettere le informazioni del certificato alle origini, implementare la revoca dei certificati utilizzando Connection Functions e KeyValueStore abilitare i log di connessione per il monitoraggio. [Per i dettagli sull'inoltro delle informazioni sui certificati alle origini, consulta Forward Headers to origin.](viewer-mtls-headers.md)

# Visualizza le intestazioni MTLS per le politiche della cache e le inoltra all'origine
<a name="viewer-mtls-headers"></a>

Quando si utilizza l'autenticazione TLS reciproca, CloudFront è possibile estrarre informazioni dai certificati client e inoltrarle alle origini come intestazioni HTTP. Ciò consente ai server di origine di accedere ai dettagli dei certificati senza implementare la logica di convalida dei certificati.

Le seguenti intestazioni sono disponibili per la creazione di comportamenti di cache:


| Nome intestazione | Description | Valore di esempio | 
| --- | --- | --- | 
| CloudFront-Viewer-Cert-Serial-Number | Rappresentazione esadecimale del numero di serie del certificato | 4a:3f:5c:92:d1:e 8:7b:6c | 
| CloudFront-Viewer-Cert-Emittente | RFC2253 rappresentazione in formato stringa del nome distinto (DN) dell'emittente | CN=rootcamtls.com, OU=RootCA, o=MTLS, L=Seattle, ST=Washington, C=USA | 
| CloudFront-Viewer-Cert-Subject | RFC2253 rappresentazione in formato stringa del nome distinto (DN) del soggetto | CN=client\$1.com, OU=Client-3, o=MTLS, ST=Washington, C=US | 
| CloudFront-Viewer-Cert-Present | 1 (presente) o 0 (non presente) indica se il certificato è presente. Questo valore è sempre 1 in modalità Obbligatoria. | 1 | 
| CloudFront-Viewer-Cert-Sha256 | L'hash del certificato client SHA256  | 01fbf94fef5569753420c349f49adbfd80af5275377816e3ab1fb371b29cb586 | 

Per le richieste di origine, vengono fornite due intestazioni aggiuntive, oltre alle intestazioni sopra rese disponibili per i comportamenti della cache. A causa della potenziale dimensione dell'intestazione, l' CloudFront-Viewer-Cert-Pemintestazione non è esposta alle funzioni edge (Lambda @Edge o CloudFront Functions) e viene inoltrata solo all'origine.


| Nome intestazione | Description | Valore di esempio | 
| --- | --- | --- | 
| CloudFront-Viewer-Cert-Validity | ISO8601 formato della data NotBefore e NotAfter | CloudFront-Viewer-Cert-Validity: =2023-09-21T 01:50:17 Z; =2024-09-20T 01:50:17 Z NotBefore NotAfter | 
| CloudFront-Viewer-Cert-Pem | Formato PEM con codifica URL del certificato leaf | CloudFront-Viewer-Cert-Pem: -----BEGIN%20CERTIFICATE-----%0AMIIG<... ridotto... -Viewer-Cert-Pem: -----INIZIO%20CERTIFICATO-----%0AMIIG %0A-----FINE NmrUlw CERTIFICATO-----%0A | 

## Configura l'inoltro degli header
<a name="configure-header-forwarding"></a>

### Console
<a name="configure-headers-console"></a>

In modalità di verifica, aggiunge CloudFront automaticamente le intestazioni CloudFront-Viewer-Cert -\$1 a tutte le richieste dei visualizzatori. Per inoltrare queste intestazioni alla tua origine:

1. **Dalla pagina principale delle distribuzioni dell'elenco, seleziona la tua distribuzione con i viewer MTL abilitati e vai alla scheda Comportamenti**

1. **Seleziona il comportamento della cache e scegli Modifica**

1. Nella sezione **Politica di richiesta Origin**, scegli **Crea policy** o seleziona una policy esistente

1. Assicurati che le seguenti intestazioni siano incluse nella politica di richiesta di origine:
   + CloudFront-Viewer-Cert-Serial-Number
   + CloudFront-Viewer-Cert-Issuer
   + CloudFront-Viewer-Cert-Subject
   + CloudFront-Viewer-Cert-Present
   + Cloudfront-Viewer-Cert-Sha256
   + CloudFront-Viewer-Cert-Validity
   + CloudFront-Visualizzatore-Cert-Pem

1. Scegli **Crea** (per nuove politiche) o **Salva** modifiche (per le politiche esistenti)

1. Seleziona la politica all'interno del comportamento della cache e salva le modifiche

### Utilizzo della AWS CLI
<a name="configure-headers-cli"></a>

L'esempio seguente mostra come creare una policy di richiesta di origine che includa le intestazioni MTL per la modalità di verifica:

```
aws cloudfront create-origin-request-policy \
  --origin-request-policy-config '{
    "Name": "MTLSHeadersPolicy",
    "HeadersConfig": {
      "HeaderBehavior": "whitelist",
      "Headers": {
        "Quantity": 5,
        "Items": [
          "CloudFront-Viewer-Cert-Serial-Number",
          "CloudFront-Viewer-Cert-Issuer",
          "CloudFront-Viewer-Cert-Subject",
          "CloudFront-Viewer-Cert-Validity",
          "CloudFront-Viewer-Cert-Pem"
        ]
      }
    },
    "CookiesConfig": {
      "CookieBehavior": "none"
    },
    "QueryStringsConfig": {
      "QueryStringBehavior": "none"
    }
  }'
```

## Considerazioni sull'elaborazione delle intestazioni
<a name="header-processing-considerations"></a>

Quando lavori con le intestazioni dei certificati, prendi in considerazione queste best practice:
+ **Convalida dell'intestazione:** verifica i valori dell'intestazione del certificato all'origine come misura di sicurezza aggiuntiva
+ **Limiti di dimensione delle intestazioni:** le intestazioni dei certificati PEM possono essere grandi, assicuratevi che il server di origine sia in grado di gestirle
+ **Considerazioni sulla cache: l'utilizzo delle intestazioni** dei certificati nella chiave della cache aumenta la frammentazione della cache
+ **Richieste provenienti da più origini:** se l'applicazione utilizza CORS, potrebbe essere necessario configurarla per consentire le intestazioni dei certificati

## Fasi successive
<a name="headers-next-steps"></a>

Dopo aver configurato l'inoltro delle intestazioni, è possibile implementare il controllo della revoca dei certificati utilizzando Connection Functions e. CloudFront KeyValueStore Per i dettagli sull'implementazione dei controlli di revoca, vedere. [Revoca tramite CloudFront Connection Function e KVS](revocation-connection-function-kvs.md)

# Revoca tramite CloudFront Connection Function e KVS
<a name="revocation-connection-function-kvs"></a>

È possibile implementare il controllo della revoca dei certificati per l'autenticazione TLS reciproca combinando CloudFront Connection Functions con. KeyValueStore Questo approccio fornisce un meccanismo di revoca dei certificati scalabile e in tempo reale che integra CloudFront la convalida dei certificati integrata.

Le funzioni di connessione sono JavaScript funzioni che vengono eseguite durante la creazione della connessione TLS nelle sedi CloudFront periferiche e consentono di implementare una logica di convalida dei certificati personalizzata per l'autenticazione MTLS. Per informazioni dettagliate sulle funzioni di connessione, vedere. [Associare una funzione di CloudFront connessione](connection-functions.md)

## Come funziona la revoca dei certificati con Connection Functions
<a name="how-revocation-works"></a>

CloudFrontla convalida standard dei certificati verifica la catena, la firma e la scadenza del certificato, ma non include il controllo integrato della revoca del certificato. Utilizzando Connection Functions, è possibile implementare un controllo di revoca personalizzato durante l'handshake TLS.

Il processo di revoca del certificato funziona come segue:

1. Memorizza i numeri di serie dei certificati revocati in un. CloudFront KeyValueStore

1. Quando un client presenta un certificato, viene richiamata la funzione di connessione.

1. La funzione confronta il numero di serie del certificato con il KeyValueStore.

1. Se il numero di serie viene trovato nell'archivio, il certificato viene revocato.

1. La tua funzione nega la connessione per i certificati revocati.

Questo approccio fornisce il controllo near-real-time delle revoche attraverso la rete CloudFront perimetrale globale.

## Configurazione KeyValueStore per i certificati revocati
<a name="setup-kvs-revoked-certs"></a>

Innanzitutto, crea un file KeyValueStore per memorizzare i numeri di serie dei certificati revocati:

### Per creare una KeyValueStore (Console)
<a name="create-kvs-console"></a>

1. Accedi a Console di gestione AWS e apri la CloudFront console all'indirizzo[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Nel riquadro di navigazione, scegli **Key value stores**.

1. Scegli **Crea archivio di valori chiave**.

1. Inserisci un nome per il tuo archivio di valori chiave (ad esempio, certificati revocati).

1. (Facoltativo) Aggiungi una descrizione.

1. Scegli **Crea archivio di valori chiave**.

### Per creare una KeyValueStore (AWS CLI)
<a name="create-kvs-cli"></a>

L'esempio seguente mostra come creare un KeyValueStore:

```
aws cloudfront create-key-value-store \
  --name "revoked-certificates" \
  --comment "Store for revoked certificate serial numbers"
```

## Importa i numeri di serie dei certificati revocati
<a name="import-revoked-serials"></a>

Dopo aver creato un KeyValueStore, devi importare i numeri di serie dei certificati revocati:

### Preparare i dati di revoca
<a name="prepare-revocation-data"></a>

Crea un file JSON con i numeri di serie del certificato revocato:

```
{
  "data": [
    {
      "key": "ABC123DEF456",
      "value": ""
    },
    {
      "key": "789XYZ012GHI",
      "value": ""
    }
  ]
}
```

### Importazione da S3
<a name="import-from-s3"></a>

1. Carica il file JSON in un bucket S3

1. Importa il file su: KeyValueStore

   ```
   aws cloudfront create-key-value-store \
     --name "revoked-certificates" \
     --import-source '{
       "SourceType": "S3",
       "SourceARN": "arn:aws:s3:::amzn-s3-demo-bucket1/revoked-serials.json"
     }'
   ```

## Crea una funzione di connessione per il controllo delle revoce
<a name="create-revocation-connection-function"></a>

Crea una funzione di connessione che confronti i numeri di serie dei certificati con i tuoi KeyValueStore:

### Esempio di codice della funzione di connessione
<a name="revocation-function-example"></a>

L'esempio seguente mostra una funzione di connessione che esegue il controllo della revoca dei certificati:

```
import cf from 'cloudfront';

async function connectionHandler(connection) {
    const kvsHandle = cf.kvs();
    
    // Get client certificate serial number
    const clientSerialNumber = connection.clientCertificate.certificates.leaf.serialNumber;
    
    // Check if the serial number exists in the KeyValueStore
    const isRevoked = await kvsHandle.exists(clientSerialNumber.replaceAll(':', ''));
    
    if (isRevoked) {
        console.log(`Certificate ${clientSerialNumber} is revoked. Denying connection.`);
        connection.logCustomData(`REVOKED:${clientSerialNumber}`);
        connection.deny();
    } else {
        console.log(`Certificate ${clientSerialNumber} is valid. Allowing connection.`);
        connection.allow();
    }
    
}
```

### Per creare la funzione di connessione (AWS CLI)
<a name="create-revocation-function-cli"></a>

L'esempio seguente mostra come creare una funzione di connessione con KeyValueStore associazione:

```
aws cloudfront create-connection-function \
  --name "revocation-checker" \
  --connection-function-config '{
      "Comment": "Certificate revocation checking function",
      "Runtime": "cloudfront-js-2.0",
      "KeyValueStoreAssociations": {
          "Quantity": 1,
          "Items": [
              {
                  "KeyValueStoreARN": "arn:aws:cloudfront::123456789012:key-value-store/revoked-certificates"
              }
          ]
      }
  }' \
  --connection-function-code fileb://revocation-checker.js
```

## Associate la funzione alla vostra distribuzione
<a name="associate-revocation-function"></a>

Dopo aver creato e pubblicato la tua Connection Function, associala alla tua CloudFront distribuzione abilitata per MTLS come descritto nella sezione. [Associare una funzione di CloudFront connessione](connection-functions.md)

# Osservabilità tramite log di connessione
<a name="connection-logs"></a>

CloudFront i registri di connessione forniscono una visibilità dettagliata degli eventi di autenticazione TLS reciproca, consentendo di monitorare la convalida dei certificati, tenere traccia dei tentativi di connessione e risolvere i problemi di autenticazione.

## Cosa sono i log di connessione?
<a name="what-are-connection-logs"></a>

I log di connessione raccolgono informazioni dettagliate sugli handshake TLS e sulla convalida dei certificati per le distribuzioni reciproche abilitate per TLS. A differenza dei log di accesso standard che registrano le informazioni sulle richieste HTTP, i log di connessione si concentrano specificamente sulla fase di creazione della connessione TLS, tra cui:
+ Stato della connessione (successo/errore)
+ Dettagli del certificato del cliente
+ Informazioni sul protocollo TLS e sulla cifratura
+ Metriche sulla tempistica della connessione
+ Dati personalizzati da Connection Functions

Questi registri offrono una visibilità completa sugli eventi di autenticazione basati su certificati, aiutandovi a monitorare la sicurezza, risolvere i problemi e soddisfare i requisiti di conformità.

## Abilita i registri di connessione
<a name="enable-connection-logs"></a>

I log di connessione sono disponibili solo per le distribuzioni con l'autenticazione TLS reciproca abilitata. Puoi inviare i log di connessione a più destinazioni, tra cui CloudWatch Logs, Amazon Data Firehose e Amazon S3.

### Prerequisiti
<a name="connection-logs-prerequisites"></a>

Prima di abilitare i log di connessione:
+ Configura il TLS reciproco per la tua distribuzione CloudFront 
+ Abilita i log di connessione per la tua distribuzione CloudFront 
+ Assicurati di disporre delle autorizzazioni necessarie per la destinazione di registrazione scelta
+ Per la distribuzione tra più account, configura le politiche IAM appropriate

### Per abilitare i registri di connessione (Console)
<a name="enable-connection-logs-console"></a>

1. Accedi a Console di gestione AWS e apri la CloudFront console all'indirizzo[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Dalla lista di distribuzione, seleziona la tua distribuzione abilitata per MTLS.

1. Scegli la scheda **Logging** (Utilizzo log).

1. Scegliere **Aggiungi**.

1. Seleziona il servizio per ricevere i log:
   + **CloudWatch Log**
   + **Firehose**
   + **Amazon S3**

1. Per **Destinazione**, seleziona la risorsa per il servizio scelto:
   + Per CloudWatch Log, inserisci il nome del **gruppo di log**
   + **Per Firehose, selezionare lo stream di distribuzione Firehose**
   + Per Amazon S3, inserisci il **nome del bucket** (facoltativamente con un prefisso)

1. (Facoltativo) Configura le impostazioni aggiuntive:
   + **Selezione dei campi:** seleziona campi di registro specifici da includere.
   + **Formato di output:** scegli tra JSON, Plain, w3c, Raw o Parquet (solo S3).
   + **Delimitatore di campo:** specifica come separare i campi del registro.

1. Scegliere **Salva modifiche**.

### Per abilitare i log di connessione (AWS CLI)
<a name="enable-connection-logs-cli"></a>

L'esempio seguente mostra come abilitare i log di connessione utilizzando l'API: CloudWatch 

```
# Step 1: Create a delivery source
aws logs put-delivery-source \
  --name "cf-mtls-connection-logs" \
  --resource-arn "arn:aws:cloudfront::123456789012:distribution/E1A2B3C4D5E6F7" \
  --log-type CONNECTION_LOGS

# Step 2: Create a delivery destination
aws logs put-delivery-destination \
  --name "s3-destination" \
  --delivery-destination-configuration \
  "destinationResourceArn=arn:aws:s3:::amzn-s3-demo-bucket1"

# Step 3: Create the delivery
aws logs create-delivery \
  --delivery-source-name "cf-mtls-connection-logs" \
  --delivery-destination-arn "arn:aws:logs:us-east-1:123456789012:delivery-destination:s3-destination"
```

**Nota**  
Quando si utilizza l' CloudWatch API, è necessario specificare la regione Stati Uniti orientali (Virginia settentrionale) (us-east-1) anche quando si consegnano i log in altre regioni.

## Campi del registro delle connessioni
<a name="connection-log-fields"></a>

I registri di connessione includono informazioni dettagliate su ogni tentativo di connessione TLS:


| Campo | Description | Esempio | 
| --- | --- | --- | 
| eventTimestamp | Timestamp ISO 8601 quando la connessione è stata stabilita o non è riuscita | 1731620046814 | 
| connectionId | Identificatore univoco per la connessione TLS | oLHiEKbQSn8lkvJfA3D4gFowK3\$1iZ0g4i5nMUjE1Akod8TuAzn5nzg== | 
| connectionStatus |  Lo stato del tentativo di connessione mTLS.  | Success o Failed | 
| clientIp | Indirizzo IP del client di connessione | 2001:0db8:85a3:0000:0000:8a2e:0370:7334 | 
| clientPort | Porta utilizzata dal client | 12137 | 
| serverIp | Indirizzo IP del server CloudFront perimetrale | 99.84.71.136 | 
| distributionId | CloudFront ID di distribuzione | E2DX1SLDPK0123 | 
| distributionTenantId | CloudFront ID del tenant di distribuzione (se applicabile) | dt\$12te1Ura9X3R2iCGNjW123 | 
| tlsProtocol | versione del protocollo TLS utilizzata | TLSv1.3 | 
| tlsCipher | Suite di crittografia TLS utilizzata per la connessione | TLS\$1AES\$1128\$1GCM\$1SHA256 | 
| tlsHandshakeDuration | Durata dell'handshake TLS in millisecondi | 153 | 
| tlsSni | Valore di indicazione del nome del server ricavato dall'handshake TLS | d111111abcdef8.cloudfront.net | 
| clientLeafCertSerialNumber | Numero di serie del certificato del client | 00:b1:43:ed:93:d2:d8:f3:9d | 
| clientLeafCertSubject | Campo relativo all'oggetto del certificato del cliente | C=US, ST=WA, L=Seattle, O=Amazon.com, OU=CloudFront, CN=client.test.mtls.net | 
| clientLeafCertIssuer | Campo dell'emittente del certificato del cliente | C=US, ST=WA, L=Seattle, O=Amazon.com, OU=CloudFront, CN=test.mtls.net | 
| clientLeafCertValidity | Periodo di validità del certificato del cliente | NotBefore=2025-06-05T23:28:21Z;NotAfter=2125-05-12T23:28:21Z | 
| connectionLogCustomData | Dati personalizzati aggiunti tramite Connection Functions | REVOKED:00:b1:43:ed:93:d2:d8:f3:9d | 

## Codici di errore di connessione
<a name="connection-error-codes"></a>

```
Failed:ClientCertMaxChainDepthExceeded
Failed:ClientCertMaxSizeExceeded
Failed:ClientCertUntrusted
Failed:ClientCertNotYetValid
Failed:ClientCertExpired
Failed:ClientCertTypeUnsupported
Failed:ClientCertInvalid
Failed:ClientCertIntentInvalid
Failed:ClientCertRejected
Failed:ClientCertMissing
Failed:TcpError
Failed:TcpTimeout
Failed:ConnectionFunctionError
Failed:ConnectionFunctionDenied
Failed:Internal
Failed:UnmappedConnectionError
```

Quando le connessioni falliscono, CloudFront registra codici di motivo specifici:


| Codice | Description | 
| --- | --- | 
| ClientCertMaxChainDepthExceeded | È stata superata la profondità massima della catena di certificati | 
| ClientCertMaxSizeExceeded | Dimensione massima del certificato superata | 
| ClientCertUntrusted | Il certificato non è attendibile | 
| ClientCertNotYetValid | Il certificato non è ancora valido | 
| ClientCertExpired | Il certificato è scaduto | 
| ClientCertTypeUnsupported | Il tipo di certificato non è supportato | 
| ClientCertInvalid | Il certificato non è valido | 
| ClientCertIntentInvalid | L'intento del certificato non è valido | 
| ClientCertRejected | Certificato rifiutato mediante convalida personalizzata | 
| ClientCertMissing | Manca il certificato | 
| TcpError |  Si è verificato un errore durante il tentativo di stabilire una connessione  | 
| TcpTimeout |  Non è stato possibile stabilire la connessione entro il periodo di timeout  | 
| ConnectionFunctionError |  È stata generata un'eccezione non rilevata durante l'esecuzione della funzione di connessione  | 
| Interno |  Si è verificato un errore interno del servizio  | 
| UnmappedConnectionError |  Si è verificato un errore che non rientra in nessuna delle altre categorie  | 

# Origin Mutual TLS con CloudFront
<a name="origin-mtls-authentication"></a>

L'autenticazione TLS reciproca (Mutual Transport Layer Security Authentication — MTLS) è un protocollo di sicurezza che estende l'autenticazione TLS standard richiedendo l'autenticazione bidirezionale basata su certificati, in cui sia il client che il server devono dimostrare la propria identità prima di stabilire una connessione sicura.

## Viewer MTLs e Origin MTLs
<a name="viewer-mtls-vs-origin-mtls"></a>

L'autenticazione reciproca (MTL) può essere abilitata tra i visualizzatori e la CloudFront distribuzione (Viewer MTL) and/or e tra la CloudFront distribuzione e l'origine (MTL di origine). Questa documentazione riguarda la configurazione degli MTL di origine. Per la configurazione degli MTL del visualizzatore, fare riferimento a:. [Autenticazione TLS reciproca con CloudFront (Viewer mTLS)Origin Mutual TLS con CloudFront](mtls-authentication.md)

Origin MTLs consente CloudFront di autenticarsi sui server di origine utilizzando certificati client. Con Origin MTL, puoi assicurarti che solo le tue CloudFront distribuzioni autorizzate possano stabilire connessioni con i server delle tue applicazioni, proteggendoti dai tentativi di accesso non autorizzati.

**Nota**  
Nelle connessioni MTLS di origine, CloudFront funge da client e presenta il relativo certificato client al server di origine durante l'handshake TLS. CloudFront non esegue la convalida della validità o dello stato di revoca del certificato client: questa è la responsabilità del server di origine. L'infrastruttura di origine deve essere configurata per convalidare il certificato client rispetto al relativo archivio di fiducia, verificare la scadenza del certificato ed eseguire controlli di revoca (come la convalida CRL o OCSP) in base ai requisiti di sicurezza. CloudFrontsi limita alla presentazione del certificato; tutta la logica di convalida dei certificati e le politiche di sicurezza vengono applicate dai server di origine.

## Come funziona
<a name="how-origin-mtls-works"></a>

In un handshake TLS standard tra CloudFront e un'origine, solo il server di origine presenta un certificato a cui dimostrare la propria identità. CloudFront Con Origin MTLS, il processo di autenticazione diventa bidirezionale. Quando CloudFront tenta di connettersi al server di origine, CloudFront presenta un certificato client durante l'handshake TLS. Il server di origine convalida questo certificato confrontandolo con il relativo archivio attendibile prima di stabilire la connessione sicura.

## Casi d’uso
<a name="origin-mtls-use-cases"></a>

Origin MTLs affronta diversi scenari di sicurezza critici in cui i metodi di autenticazione tradizionali creano un sovraccarico operativo:
+ **Sicurezza ibrida e multi-cloud**: puoi proteggere le connessioni CloudFront e le origini ospitate all'esterno AWS o le origini pubbliche su. AWS Ciò elimina la necessità di gestire elenchi di indirizzi IP consentiti o soluzioni di intestazione personalizzate, fornendo un'autenticazione coerente basata sui certificati tra AWS i data center locali e i provider di terze parti. Le società di media, i rivenditori e le imprese che gestiscono un'infrastruttura distribuita traggono vantaggio dai controlli di sicurezza standardizzati sull'intera infrastruttura.
+ **API B2B e sicurezza del backend**: puoi proteggere il backend APIs e i microservizi dai tentativi di accesso diretto, mantenendo al contempo i vantaggi in termini di prestazioni. CloudFront Le piattaforme SaaS, i sistemi di elaborazione dei pagamenti e le applicazioni aziendali con requisiti di autenticazione rigorosi possono verificare che le richieste API provengano solo da CloudFront distribuzioni autorizzate, prevenendo man-in-the-middle attacchi e tentativi di accesso non autorizzati.

## Importante: requisiti del server Origin
<a name="important-origin-server-requirements"></a>

Origin mTLS richiede che i server di origine siano configurati per supportare l'autenticazione TLS reciproca. La tua infrastruttura di origine deve essere in grado di:
+ Richiesta e convalida dei certificati client durante gli handshake TLS
+ Mantenimento di un archivio affidabile con i certificati dell'Autorità di Certificazione che ha emesso i certificati client CloudFront
+ Registrazione e monitoraggio degli eventi di connessione TLS reciproca
+ Gestione delle politiche di convalida dei certificati e gestione degli errori di autenticazione

CloudFront gestisce la presentazione dei certificati sul lato client, ma i server di origine sono responsabili della convalida di questi certificati e della gestione della connessione TLS reciproca. Assicurati che l'infrastruttura di origine sia configurata correttamente prima di abilitare gli MTL di origine. CloudFront

## Nozioni di base
<a name="how-origin-mtls-getting-started"></a>

Per implementare gli MTL di origine con CloudFront, dovrai importare il certificato client in AWS Certificate Manager, configurare il server di origine in modo che richieda il TLS reciproco e abilitare gli MTL di origine sulla tua distribuzione. CloudFront Le seguenti sezioni forniscono step-by-step istruzioni per ogni attività di configurazione.

**Topics**
+ [

## Viewer MTLs e Origin MTLs
](#viewer-mtls-vs-origin-mtls)
+ [

## Come funziona
](#how-origin-mtls-works)
+ [

## Casi d’uso
](#origin-mtls-use-cases)
+ [

## Importante: requisiti del server Origin
](#important-origin-server-requirements)
+ [

## Nozioni di base
](#how-origin-mtls-getting-started)
+ [

# Gestione dei certificati con AWS Certificate Manager
](origin-certificate-management-certificate-manager.md)
+ [

# Abilita Origin Mutual TLS per le distribuzioni CloudFront
](origin-enable-mtls-distributions.md)
+ [

# Utilizzo di CloudFront funzioni con Origin Mutual TLS
](origin-mtls-cloudfront-functions.md)

# Gestione dei certificati con AWS Certificate Manager
<a name="origin-certificate-management-certificate-manager"></a>

[AWS Certificate Manager (ACM)](https://aws.amazon.com/certificate-manager/) archivia i certificati client che vengono CloudFront presentati ai server di origine durante l'autenticazione TLS reciproca di origine.

## Supporto dell'Autorità di certificazione
<a name="origin-ca-support"></a>

CloudFront origin mTLS richiede certificati client con Extended Key Usage (EKU) per l'autenticazione del client TLS. A causa di questo requisito, è necessario emettere certificati dall'Autorità di certificazione e importarli in AWS Certificate Manager. Le funzionalità di fornitura e rinnovo automatico dei certificati di ACM non sono disponibili per i certificati client MTLs di origine. CloudFront origin MTLs supporta i certificati client provenienti da due fonti:
+ **AWS Autorità di certificazione privata:** è possibile emettere certificati da AWS Private CA utilizzando modelli di certificato che includono l'autenticazione del client TLS nel campo Extended Key Usage (come il EndEntityClientAuthCertificate modello). Dopo aver emesso il certificato da AWS Private CA, è necessario importarlo in ACM nella regione Stati Uniti orientali (Virginia settentrionale) (us-east-1). Questo approccio offre i vantaggi in termini di sicurezza di AWS Private CA, garantendo al contempo il controllo sulla gestione del ciclo di vita dei certificati.
+ **Autorità di certificazione private di terze parti:** puoi anche emettere certificati dalla tua infrastruttura privata di autorità di certificazione esistente e importarli in ACM. Ciò consente di mantenere gli attuali processi di gestione dei certificati sfruttando al contempo le funzionalità CloudFront MTL di origine. I certificati devono includere l'autenticazione del client TLS nel campo Extended Key Usage e devono essere in formato PEM con il certificato, la chiave privata e la catena di certificati.

**Importante**  
Sia per AWS Private CA che per terze parti CAs, sei responsabile del monitoraggio delle date di scadenza dei certificati e dell'importazione dei certificati rinnovati in ACM prima della scadenza. La funzionalità di rinnovo automatico di ACM non si applica ai certificati importati utilizzati per gli MTL di origine.

## Requisiti e specifiche dei certificati
<a name="origin-certificate-requirements"></a>

### Requisiti del certificato del cliente
<a name="origin-ca-cert-format-requirements"></a>
+ **Formato: formato** PEM (Privacy Enhanced Mail)
+ **Componenti:** certificato, chiave privata e catena di certificati
+ **Profondità massima della catena di certificati:** 3 (certificato fogliare\$1certificato intermedio\$1certificato radice)
+ **Dimensione massima della catena di certificati:** 64 KB
+ **Dimensione del certificato:** non può superare i 96 KB
+ **Dimensione massima della chiave privata:** 5 KB (restrizione ACM)
+ **Numero massimo di certificati MTLS di origine univoci ARNs che possono essere aggiunti o modificati per ogni CloudFront distribuzione, creazione o aggiornamento della chiamata API**: 5
+ **Regione:** i certificati devono essere archiviati in ACM nella regione Stati Uniti orientali (Virginia settentrionale) (us-east-1)

### Specifiche dei certificati supportate
<a name="origin-supported-cert-specs"></a>
+ **Tipo di certificato: X.509v3**
+ **Algoritmi a chiave pubblica:**
  + RSA: 2048 bit
  + ECDSA: P-256
+ **Algoritmi di firma:**
  + SHA256 SHA384, SHA512 con RSA
  + SHA256 SHA384, SHA512 con ECSA
  + SHA256, con SHA384 RASSA-PSS SHA512 con MGF1
+ **Utilizzo esteso delle chiavi (richiesto):** il certificato richiede l'estensione Extended Key Usage (EKU) impostata su TLS Client Authentication, che ne garantisce l'autorizzazione per scopi mTLS

### Requisiti del certificato del server
<a name="origin-server-certificate-requirements"></a>

I server di origine devono presentare certificati emessi da autorità di certificazione pubblicamente attendibili durante l'handshake TLS reciproco. Per i dettagli completi sui requisiti dei certificati del server di origine, consulta [Requisiti per l'utilizzo dei SSL/TLS certificati con](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https-cloudfront-to-custom-origin.html#using-https-cloudfront-to-origin-certificate). CloudFront

### Richiedi o importa un certificato
<a name="origin-request-import-certificate"></a>

Prima di abilitare gli MTL di origine, è necessario disporre di un certificato client disponibile in ACM.

#### Richiedi e importa un certificato da Private CA AWS
<a name="request-certificate-aws-private-ca"></a>

Prerequisiti:
+ Un'autorità di certificazione AWS privata configurata nel tuo account
+ Autorizzazione a emettere certificati da AWS Private CA
+ Autorizzazione a importare certificati in ACM
+ Un [modello di certificato](https://docs.aws.amazon.com/privateca/latest/userguide/UsingTemplates.html) ARN adatto al tuo caso `Extended key usage:TLS web client authentication` d'uso
+ Installa OpenSSL AWS , CLI e jq (per l'analisi di JSON).

##### Per richiedere un certificato da PCA e importarlo in ACM (CLI AWS )
<a name="request-certificate-cli"></a>

1. Imposta il tuo ARN CA privato in una variabile per facilitarne il riutilizzo.

   ```
   PCA_ARN="arn:aws:acm-pca:region:account:certificate-authority/12345678..."
   ```

1. Usa OpenSSL per generare una chiave privata ECDSA P-256 (curva prime256v1) e una richiesta di firma del certificato (CSR), assicurandoti che venga utilizzato il flag -nodes per mantenere la chiave privata non crittografata come richiesto per l'importazione ACM.

   ```
   openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -nodes \
       -keyout private.key \
       -out request.csr \
       -subj "/CN=client.example.com"
   ```

1. Invia la CSR alla tua CA AWS privata per emettere un certificato, che restituisce l'ARN del certificato appena emesso.

   ```
   CERT_ARN=$(aws acm-pca issue-certificate \
       --certificate-authority-arn "$PCA_ARN" \
       --csr fileb://request.csr \
       --signing-algorithm "SHA256WITHECDSA" \
       --validity Value=365,Type="DAYS" \
       --template-arn arn:aws:acm-pca:::template/EndEntityCertificate/V1 \
       --query 'CertificateArn' --output text)
   ```

1. Recupera il pacchetto di certificati da AWS PCA utilizzando il comando get-certificate, che restituisce sia il certificato leaf che la catena, quindi usa jq per separarli in file distinti.

   ```
   # Retrieve the full certificate bundle in JSON format
   aws acm-pca get-certificate \
       --certificate-authority-arn "$PCA_ARN" \
       --certificate-arn "$CERT_ARN" \
       --output json > full_cert.json
   
   # Split into Leaf and Chain
   jq -r '.Certificate' full_cert.json > leaf_cert.pem
   jq -r '.CertificateChain' full_cert.json > cert_chain.pem
   ```

1. Importa la chiave privata non crittografata, il certificato leaf e la catena di certificati in AWS ACM, utilizzando il protocollo fileb://per gestire correttamente i dati dei file binari nella CLI.

   ```
   aws acm import-certificate \
       --certificate fileb://leaf_cert.pem \
       --private-key fileb://private.key \
       --certificate-chain fileb://cert_chain.pem \
       --region us-east-1 \
       --query 'CertificateArn' \
       --output text
   ```

#### Importa un certificato da una CA di terze parti
<a name="import-certificate-third-party-ca"></a>

Prerequisiti:
+ Un certificato, una chiave privata non crittografata e una catena di certificati dall'Autorità di certificazione in formato PEM
+ Il certificato deve includere l'utilizzo esteso delle chiavi per l'autenticazione del client TLS
+ Autorizzazioni per importare certificati in ACM

##### Per importare un certificato in ACM (AWS CLI)
<a name="import-certificate-cli"></a>

```
aws acm import-certificate \
  --certificate fileb://certificate.pem \
  --private-key fileb://private-key.pem \
  --certificate-chain fileb://certificate-chain.pem \
  --region us-east-1 \
  --query 'CertificateArn' \
  --output text
```

#### Fasi successive
<a name="certificate-next-steps"></a>

Dopo aver ottenuto o importato il certificato client in ACM, puoi configurare il server di origine in modo che richieda l'autenticazione TLS reciproca e abiliti gli MTL di origine sulla tua distribuzione. CloudFront Per istruzioni su come abilitare gli MTL di origine in CloudFront, consulta la sezione successiva «Abilitare Origin Mutual TLS per le distribuzioni». CloudFront 

# Abilita Origin Mutual TLS per le distribuzioni CloudFront
<a name="origin-enable-mtls-distributions"></a>

Dopo aver ottenuto un certificato client tramite AWS Certificate Manager e aver configurato il server di origine per richiedere il TLS reciproco, puoi abilitare gli MTL di origine sulla tua distribuzione. CloudFront 

## Prerequisiti e requisiti
<a name="origin-mtls-prerequisites-requirements"></a>

Prima di abilitare gli MTL di origine su una CloudFront distribuzione, assicurati di avere:
+ Un certificato client archiviato in AWS Certificate Manager nella regione Stati Uniti orientali (Virginia settentrionale) (us-east-1)
+ Server di origine configurati per richiedere l'autenticazione TLS reciproca e convalidare i certificati client
+ Server di origine che presentano certificati emessi da autorità di certificazione pubblicamente attendibili
+ Autorizzazioni per modificare CloudFront le distribuzioni
+ Origin MTLs è disponibile solo con i piani tariffari Business, Premium o Pay as you go.

**Nota**  
Gli MTL di origine possono essere configurati per origini personalizzate (incluse le origini ospitate all'esterno AWS) e AWS origini che supportano TLS reciproco come Application Load Balancer e API Gateway.

**Importante**  
Le seguenti CloudFront funzionalità non sono supportate con gli MTL di origine:  
**Traffico gRPC: il protocollo gRPC** non è supportato per le origini con MTL di origine abilitati
**WebSocket connessioni:** il WebSocket protocollo non è supportato per le origini con MTL di origine abilitati
**Origini VPC:** gli MTL di origine non possono essere utilizzati con le origini VPC
**Trigger Origin Request e Origin Response con Lambda @Edge:** le funzioni Lambda @Edge nelle posizioni Origin Request e Origin Response non sono supportate con Origin MTL
**Incorporato POPs:** gli MTL di origine non sono supportati per quelli incorporati POPs

## Abilita gli MTL di origine
<a name="origin-enable-mtls-per-origin"></a>

La configurazione per origine consente di specificare certificati client diversi per origini diverse all'interno della stessa distribuzione. Questo approccio offre la massima flessibilità quando le origini hanno requisiti di autenticazione diversi.

### Per nuove distribuzioni (Console)
<a name="origin-enable-mtls-new-distributions"></a>

1. Accedi a Console di gestione AWS e apri la CloudFront console all'indirizzo[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Scegli **Crea distribuzione**

1. Seleziona un piano tariffario: scegli **Business** o **Premium** o **Pay As You Go** (Origin MTLs non è disponibile nel piano gratuito)

1. Nella sezione Impostazioni Origin, scegli Origin Type as Other

1. Nella sezione **Impostazioni di origine**, scegli **Personalizza le impostazioni di origine**

1. Configura la tua prima origine (nome di dominio, protocollo, ecc.)

1. Nella configurazione di origine, trova **MTL**

1. **Attiva gli MTL**

1. Per **il certificato client**, seleziona il tuo certificato da AWS Certificate Manager

1. (Facoltativo) Aggiungi origini aggiuntive con le proprie configurazioni MTL di origine

1. **Completa le impostazioni di distribuzione rimanenti e scegli Crea distribuzione**

### Per le distribuzioni esistenti (Console)
<a name="origin-enable-mtls-existing-distributions"></a>

1. Accedi a Console di gestione AWS e apri la CloudFront console all'indirizzo[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Dalla lista di distribuzione, seleziona la distribuzione che desideri modificare. (Nota: assicurati che la tua distribuzione includa un piano tariffario **Pro, Premium o Pay As You Go**. In caso contrario, è necessario aggiornare il piano tariffario prima di abilitare Origin (MTL)

1. Scegli la scheda **Origins**

1. Seleziona l'origine che desideri configurare e scegli **Modifica**

1. Nelle impostazioni di origine, trova **MTL**

1. **Attiva gli MTL**

1. Per **il certificato client**, seleziona il tuo AWS certificato da Certificate Manager. (Nota: verranno elencati solo i certificati client con la proprietà EKU (Extended Key Usage) impostata su «TLS Client Authentication»)

1. Scegliere **Salva modifiche**.

1. Ripetere l'operazione per altre origini, se necessario

## Utilizzo della AWS CLI
<a name="origin-enable-mtls-cli"></a>

Per la configurazione per origine, specifica le impostazioni MTLS di origine all'interno della configurazione di ciascuna origine:

```
{
  "Origins": {
    "Quantity": 2,
    "Items": [
      {
        "Id": "origin-1",
        "DomainName": "api.example.com",
        "CustomOriginConfig": {
          "HTTPSPort": 443,
          "OriginProtocolPolicy": "https-only"
        },
        "OriginMtlsConfig": {
          "ClientCertificateArn": "arn:aws:acm:us-east-1:123456789012:certificate/cert-1"
        }
      },
      {
        "Id": "origin-2",
        "DomainName": "backend.example.com",
        "CustomOriginConfig": {
          "HTTPSPort": 443,
          "OriginProtocolPolicy": "https-only"
        },
        "OriginMtlsConfig": {
          "CertificateArn": "arn:aws:acm:us-east-1:123456789012:certificate/cert-2"
        }
      }
    ]
  }
}
```

**Nota**  
CloudFront non fornirà il certificato client se il server non lo richiede, permettendo alla connessione di procedere normalmente.

## Fasi successive
<a name="origin-enable-mtls-next-steps"></a>

Dopo aver abilitato Origin MTL sulla vostra CloudFront distribuzione, potete monitorare gli eventi di autenticazione utilizzando i log di CloudFront accesso.

# Utilizzo di CloudFront funzioni con Origin Mutual TLS
<a name="origin-mtls-cloudfront-functions"></a>

CloudFront Functions fornisce un'elaborazione leggera e senza server all'edge per personalizzare la distribuzione dei contenuti. Quando si utilizza Origin Mutual TLS con CloudFront Functions, esistono comportamenti e limitazioni specifici di cui tenere conto per quanto riguarda la selezione e la manipolazione dell'origine.

## Operazioni sulle funzioni supportate CloudFront
<a name="supported-cloudfront-functions-operations"></a>

CloudFront Le funzioni possono interagire con le origini abilitate per MTLS nei seguenti modi:

### updateRequestOrigin()
<a name="update-request-origin-function"></a>

La funzione updateRequestOrigin () supporta modifiche limitate quando si lavora con origini abilitate per MTLS:
+ **Passaggio da un'origine MTL all'altra:** **è possibile aggiornare la richiesta per instradare verso un'origine diversa che utilizzi MTL di origine, a condizione che entrambe le origini utilizzino lo stesso certificato client.** Ciò consente di implementare una logica di routing personalizzata mantenendo l'autenticazione TLS reciproca.
+ **Disabilitazione degli MTL di origine:** è possibile passare da un'origine abilitata per MTLS a un'origine non MTLS impostando la funzione. `mTLSConfig: 'off'` Ciò offre la flessibilità necessaria per disabilitare in modo condizionale l'autenticazione TLS reciproca in base alle caratteristiche della richiesta.

#### Esempio: passaggio da un'origine MTLS di origine all'altra con lo stesso certificato
<a name="example-switching-mtls-origins"></a>

```
function handler(event) {
    var request = event.request;

    // Route to different origin based on request path
    if (request.uri.startsWith('/api/v2')) {
        request.origin = {
            domainName: 'api-v2.example.com',
            customHeaders: {},
            // Both origins must use the same certificate
        };
    }

    return request;
}
```

#### Esempio: disabilitazione condizionale degli MTL di origine
<a name="example-disabling-mtls"></a>

```
function handler(event) {
    var request = event.request;

    // Disable mTLS for specific paths
    if (request.uri.startsWith('/public')) {
        request.origin = {
            domainName: 'public-origin.example.com',
            customHeaders: {},
            mTLSConfig: 'off'
        };
    }

    return request;
}
```

## Operazioni sulle funzioni non supportate CloudFront
<a name="unsupported-cloudfront-functions-operations"></a>

Le seguenti operazioni CloudFront Functions non supportano le origini abilitate per MTLS al momento della disponibilità generale:

### selectRequestOriginById()
<a name="select-request-origin-by-id-function"></a>

La `selectRequestOriginById()` funzione non può selezionare un'origine con MTL di origine abilitata. Il tentativo di selezionare un'origine abilitata per MTLS utilizzando questa funzione genererà un errore di convalida.

Se il tuo caso d'uso richiede una selezione dinamica dell'origine con MTL di origine, utilizza `updateRequestOrigin()` invece, assicurandoti che tutte le origini di destinazione utilizzino lo stesso certificato client.

### createRequestOriginGruppo ()
<a name="create-request-origin-group-function"></a>

La `createRequestOriginGroup()` funzione non supporta la creazione di gruppi di origine che includono origini abilitate per MTLS. I gruppi di origine con origini MTL di origine non possono essere creati dinamicamente tramite Functions. CloudFront 

Se hai bisogno di funzionalità di failover di origine con Origin MTL, configura i gruppi di origine direttamente nelle impostazioni di CloudFront distribuzione anziché crearli dinamicamente nelle funzioni.

# Offri contenuti privati con cookie firmati URLs e firmati
<a name="PrivateContent"></a>

Molte aziende che distribuiscono contenuto tramite Internet vogliono limitare l'accesso a documenti, dati aziendali, flussi multimediali o contenuto destinato a utenti selezionati, ad esempio, utenti paganti. Per servire in modo sicuro questi contenuti privati utilizzando CloudFront, puoi fare quanto segue:
+ Richiedi che gli utenti accedano ai tuoi contenuti privati utilizzando speciali cookie CloudFront firmati URLs o firmati. 
+ Richiedi che i tuoi utenti accedano ai tuoi contenuti utilizzando CloudFront URLs, non URLs che accedano ai contenuti direttamente sul server di origine (ad esempio, Amazon S3 o un server HTTP privato). La richiesta CloudFront URLs non è necessaria, ma la consigliamo per impedire agli utenti di aggirare le restrizioni specificate nei cookie firmati URLs o firmati.

Per ulteriori informazioni, consulta [Limitazione dell’accesso ai file](private-content-overview.md).

## Come gestire contenuti privati
<a name="private-content-task-list"></a>

 CloudFront Per configurare la visualizzazione di contenuti privati, esegui le seguenti operazioni:

1. (Facoltativo ma consigliato) Richiedi agli utenti di accedere ai tuoi contenuti solo tramite CloudFront. Il metodo utilizzato varia a seconda se utilizzi origini Amazon S3 o origini personalizzate:
   + **Amazon S3** - Vedere [Limitazione dell’accesso a un’origine Amazon S3](private-content-restricting-access-to-s3.md).
   + **Origine personalizzata** - Consulta [Limitazione dell’accesso ai file su origini personalizzate](private-content-overview.md#forward-custom-headers-restrict-access).

   Le origini personalizzate includono Amazon EC2, bucket Amazon S3 configurati come endpoint del sito Web, Elastic Load Balancing e server Web HTTP personalizzati.

1. Specificate i *gruppi di chiavi* *attendibili o i firmatari fidati* che desiderate utilizzare per creare cookie firmati URLs o firmati. Ti consigliamo di utilizzare gruppi di chiavi attendibili. Per ulteriori informazioni, consulta [Specificate i firmatari che possono creare cookie firmati e firmati URLs](private-content-trusted-signers.md).

1. Scrivi la tua applicazione per rispondere alle richieste degli utenti autorizzati con cookie firmati URLs o con `Set-Cookie` intestazioni che impostano cookie firmati. Segui le fasi in uno dei seguenti argomenti: 
   + [Usa firmato URLs](private-content-signed-urls.md)
   + [Utilizzo di cookie firmati](private-content-signed-cookies.md)

   Se non si è certi del metodo da utilizzare, consultare [Decidi di utilizzare cookie firmati URLs o firmati](private-content-choosing-signed-urls-cookies.md).

**Topics**
+ [

## Come gestire contenuti privati
](#private-content-task-list)
+ [

# Limitazione dell’accesso ai file
](private-content-overview.md)
+ [

# Specificate i firmatari che possono creare cookie firmati e firmati URLs
](private-content-trusted-signers.md)
+ [

# Decidi di utilizzare cookie firmati URLs o firmati
](private-content-choosing-signed-urls-cookies.md)
+ [

# Usa firmato URLs
](private-content-signed-urls.md)
+ [

# Utilizzo di cookie firmati
](private-content-signed-cookies.md)
+ [

# Comandi Linux e OpenSSL per la crittografia e la codifica base64
](private-content-linux-openssl.md)
+ [

# Codice di esempio per la creazione di una firma per un URL firmato
](PrivateCFSignatureCodeAndExamples.md)

# Limitazione dell’accesso ai file
<a name="private-content-overview"></a>

Puoi controllare l'accesso degli utenti ai tuoi contenuti privati in due modi:
+ [Limita l'accesso ai file nelle CloudFront cache](#private-content-overview-edge-caches).
+ Limita l'accesso ai file nel server di origine in uno dei seguenti modi:
  + [Imposta un controllo di accesso origine (OAC) per il bucket Amazon S3](private-content-restricting-access-to-s3.md).
  + [Configura intestazioni personalizzate per un server HTTP privato (un'origine personalizzata)](#forward-custom-headers-restrict-access).

## Limita l'accesso ai file nelle cache CloudFront
<a name="private-content-overview-edge-caches"></a>

Puoi configurare in modo CloudFront da richiedere che gli utenti accedano ai tuoi file utilizzando *cookie *firmati URLs* o firmati*. Successivamente, sviluppate l'applicazione per creare e distribuire i cookie firmati URLs agli utenti autenticati o per inviare `Set-Cookie` intestazioni che impostano cookie firmati per gli utenti autenticati. (Per consentire ad alcuni utenti l'accesso a lungo termine a un numero limitato di file, puoi anche creare file firmati URLs manualmente.) 

Quando crei cookie firmati URLs o firmati per controllare l'accesso ai tuoi file, puoi specificare le seguenti restrizioni:
+ Una data e un'ora di fine, dopo le quali l'URL non è più valido. 
+ (Facoltativo) La data e l'ora in cui l'URL diventa valido.
+ (Facoltativo) L'indirizzo IP o l'intervallo di indirizzi dei computer che possono essere utilizzati per accedere al tuo contenuto. 

Una parte di un URL o di un cookie firmato viene sottoposta a hashing e firmata utilizzando la chiave privata di una coppia di chiavi pubblica/privata. Quando qualcuno utilizza un URL firmato o un cookie firmato per accedere a un file, CloudFront confronta le parti firmate e non firmate dell'URL o del cookie. Se non corrispondono, CloudFront non serve il file.

È necessario utilizzare le chiavi private RSA 2048 o ECDSA 256 per la firma o i cookie. URLs 

## Limitazione dell’accesso ai file nei bucket Amazon S3
<a name="private-content-overview-s3"></a>

Facoltativamente, puoi proteggere i contenuti nel tuo bucket Amazon S3 in modo che gli utenti possano accedervi tramite la distribuzione CloudFront specificata ma non possono accedervi direttamente utilizzando Amazon S3. URLs Ciò impedisce a qualcuno di aggirare CloudFront e utilizzare l'URL di Amazon S3 per ottenere contenuti a cui desideri limitare l'accesso. Questo passaggio non è necessario per utilizzare signedURLs, ma lo consigliamo.

Per richiedere agli utenti di accedere ai tuoi contenuti tramite CloudFront URLs, esegui le seguenti attività:
+ Concedi a un'autorizzazione *di controllo dell'accesso all' CloudFront origine* per leggere i file nel bucket S3.
+ Crea il controllo di accesso di origine e associalo alla tua CloudFront distribuzione.
+ Rimuovi l'autorizzazione a chiunque altro a utilizzare Amazon S3 URLs per leggere i file.

Per ulteriori informazioni, consulta [Limitazione dell’accesso a un’origine Amazon S3](private-content-restricting-access-to-s3.md) o [Limita l'accesso all'origine di un punto di accesso multiregionale Amazon S3](private-content-restricting-access-to-s3-mrap.md).

## Limitazione dell’accesso ai file su origini personalizzate
<a name="forward-custom-headers-restrict-access"></a>

Se utilizzi un'origine personalizzata, puoi facoltativamente configurare le intestazioni personalizzate per limitare l'accesso. CloudFront Per ottenere i file da un'origine personalizzata, è necessario che i file siano accessibili CloudFront tramite una richiesta HTTP (o HTTPS) standard. Tuttavia, utilizzando intestazioni personalizzate, puoi limitare ulteriormente l'accesso ai tuoi contenuti in modo che gli utenti possano accedervi solo tramite CloudFront e non direttamente. Questo passaggio non è necessario per utilizzare signed URLs, ma lo consigliamo.

Per richiedere agli utenti di accedere ai contenuti tramite CloudFront, modifica le seguenti impostazioni nelle tue CloudFront distribuzioni:

**Origin Custom Headers (Intestazioni personalizzate origine)**  
Configura CloudFront per inoltrare le intestazioni personalizzate alla tua origine. Per informazioni, consulta [Configura CloudFront per aggiungere intestazioni personalizzate alle richieste di origine](add-origin-custom-headers.md#add-origin-custom-headers-configure).

**Viewer Protocol Policy (Policy protocollo visualizzatore)**  
Configura la distribuzione in modo che i visualizzatori utilizzino HTTPS per accedere a CloudFront. Per informazioni, consulta [Viewer Protocol Policy (Policy protocollo visualizzatore)](DownloadDistValuesCacheBehavior.md#DownloadDistValuesViewerProtocolPolicy). 

**Origin Protocol Policy (Policy protocollo origine)**  
Configura la tua distribuzione in modo CloudFront che richieda l'utilizzo dello stesso protocollo dei visualizzatori per inoltrare le richieste all'origine. Per informazioni, consulta [Protocollo (solo origini personalizzate)](DownloadDistValuesOrigin.md#DownloadDistValuesOriginProtocolPolicy). 

Dopo aver apportato queste modifiche, aggiorna l'applicazione sull'origine personalizzata per accettare solo le richieste che includono le intestazioni personalizzate che hai configurato CloudFront per l'invio.

La combinazione della **Policy del protocollo del visualizzatore** e della **Policy del protocollo di origine** garantisce che le intestazioni personalizzate siano crittografate durante il transito. Tuttavia, ti consigliamo di eseguire periodicamente le seguenti operazioni per ruotare le intestazioni personalizzate che vengono CloudFront inoltrate all'origine:

1. Aggiorna la CloudFront distribuzione per iniziare a inoltrare una nuova intestazione all'origine personalizzata.

1. Aggiorna l'applicazione per accettare la nuova intestazione come conferma dell'origine della richiesta. CloudFront

1. Quando le richieste non includono più l'intestazione che stai sostituendo, aggiorna l'applicazione in modo che non accetti più la vecchia intestazione come conferma dell'origine della richiesta. CloudFront

# Specificate i firmatari che possono creare cookie firmati e firmati URLs
<a name="private-content-trusted-signers"></a>

**Topics**
+ [

## Scegli tra gruppi di chiavi affidabili (consigliato) e Account AWS
](#choosing-key-groups-or-AWS-accounts)
+ [

## Creazione di coppie di chiavi per i firmatari
](#private-content-creating-cloudfront-key-pairs)
+ [

## Riformattazione della chiave privata (solo .NET e Java)
](#private-content-reformatting-private-key)
+ [

## Aggiunta di un firmatario a una distribuzione
](#private-content-adding-trusted-signers)
+ [

## Rotazione di coppie di chiavi
](#private-content-rotating-key-pairs)

Per creare cookie firmati URLs o firmati, è necessario un *firmatario*. Un firmatario è un gruppo di chiavi attendibile in cui CloudFront crei o un AWS account che contiene una coppia di CloudFront chiavi. Ti consigliamo di utilizzare gruppi di chiavi affidabili con cookie firmati URLs e firmati. Per ulteriori informazioni, consulta [Scegli tra gruppi di chiavi affidabili (consigliato) e Account AWS](#choosing-key-groups-or-AWS-accounts).

Il firmatario ha due scopi:
+ Non appena aggiungi il firmatario alla tua distribuzione, CloudFront inizia a richiedere che gli spettatori utilizzino cookie firmati URLs o firmati per accedere ai tuoi file.
+ Quando crei cookie firmati URLs o firmati, utilizzi la chiave privata della coppia di chiavi del firmatario per firmare una parte dell'URL o del cookie. Quando qualcuno richiede un file con restrizioni, CloudFront confronta la firma nell'URL o nel cookie con l'URL o il cookie non firmato, per verificare che non sia stata manomessa. CloudFront verifica inoltre che l'URL o il cookie siano validi, vale a dire, ad esempio, che la data e l'ora di scadenza non siano trascorse.

Quando specifichi un firmatario, specifichi anche indirettamente i file che richiedono cookie firmati URLs o firmati aggiungendo il firmatario a un comportamento di cache. Se la tua distribuzione ha un solo comportamento nella cache, gli utenti devono utilizzare cookie firmati URLs o firmati per accedere a qualsiasi file della distribuzione. Se crei più comportamenti di cache e aggiungi firmatari ad alcuni comportamenti di cache e non ad altri, puoi richiedere che gli utenti utilizzino i cookie firmati URLs o firmati per accedere ad alcuni file e non ad altri.

Per specificare i firmatari (le chiavi private) autorizzati a creare cookie firmati URLs o firmati e per aggiungere i firmatari alla tua CloudFront distribuzione, esegui le seguenti operazioni:

1. Decidi se utilizzare un gruppo di chiavi attendibile o un altro Account AWS come firmatario. Ti consigliamo di utilizzare un gruppo di chiavi attendibile. Per ulteriori informazioni, consulta [Scegli tra gruppi di chiavi affidabili (consigliato) e Account AWS](#choosing-key-groups-or-AWS-accounts).

1. Per il firmatario scelto nel passaggio 1, crea una coppia di chiavi pubbliche-private. Per ulteriori informazioni, consulta [Creazione di coppie di chiavi per i firmatari](#private-content-creating-cloudfront-key-pairs).

1. Se utilizzi .NET o Java per creare cookie firmati URLs o firmati, riformatta la chiave privata. Per ulteriori informazioni, consulta [Riformattazione della chiave privata (solo .NET e Java)](#private-content-reformatting-private-key).

1. Nella distribuzione per la quale stai creando cookie firmati URLs o firmati, specifica il firmatario. Per ulteriori informazioni, consulta [Aggiunta di un firmatario a una distribuzione](#private-content-adding-trusted-signers).

## Scegli tra gruppi di chiavi affidabili (consigliato) e Account AWS
<a name="choosing-key-groups-or-AWS-accounts"></a>

Per utilizzare i cookie firmati URLs o firmati, è necessario un *firmatario.* Un firmatario è un gruppo di chiavi attendibile in CloudFront cui crei o un gruppo Account AWS che contiene una coppia di CloudFront chiavi. Ti consigliamo di utilizzare i gruppi di chiavi attendibili per i seguenti motivi:
+ Con i gruppi di CloudFront chiavi, non è necessario utilizzare l' AWS account utente root per gestire le chiavi pubbliche per i cookie CloudFront firmati URLs e firmati. [AWS le migliori pratiche](https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html#aws_tasks-that-require-root) consigliano di non utilizzare l'utente root quando non è necessario.
+ Con i gruppi di CloudFront chiavi, puoi gestire chiavi pubbliche, gruppi di chiavi e firmatari attendibili utilizzando l' CloudFront API. Puoi utilizzare l'API per automatizzare la creazione e la rotazione delle chiavi. Quando si utilizza l'utente AWS root, è necessario utilizzare il per Console di gestione AWS gestire le coppie di CloudFront chiavi, quindi non è possibile automatizzare il processo.
+ Poiché puoi gestire i gruppi di chiavi con l' CloudFront API, puoi anche utilizzare le politiche di autorizzazione AWS Identity and Access Management (IAM) per limitare ciò che i diversi utenti sono autorizzati a fare. Ad esempio, puoi consentire agli utenti di caricare chiavi pubbliche, ma non eliminarle. In alternativa, puoi consentire agli utenti di eliminare le chiavi pubbliche, ma solo quando vengono soddisfatte determinate condizioni, ad esempio l'utilizzo dell'autenticazione a più fattori, l'invio della richiesta da una determinata rete o l'invio della richiesta entro un determinato intervallo di data e ora.
+ Con i gruppi di CloudFront chiavi, puoi associare un numero maggiore di chiavi pubbliche alla tua CloudFront distribuzione, offrendoti una maggiore flessibilità nel modo in cui utilizzi e gestisci le chiavi pubbliche. Per impostazione predefinita, puoi associare fino a quattro gruppi di chiavi a una singola distribuzione e disporre di un massimo di cinque chiavi pubbliche in un gruppo di chiavi.

  Quando si utilizza l'utente root dell' AWS account per gestire le coppie di CloudFront chiavi, è possibile avere solo fino a due coppie di CloudFront chiavi attive per AWS account.

## Creazione di coppie di chiavi per i firmatari
<a name="private-content-creating-cloudfront-key-pairs"></a>

Ogni firmatario utilizzato per creare cookie CloudFront firmati URLs o firmati deve disporre di una coppia di key pair pubblica-privata. Il firmatario utilizza la propria chiave privata per firmare l'URL o i cookie e CloudFront utilizza la chiave pubblica per verificare la firma.

Il modo in cui si crea una coppia di chiavi dipende dal fatto che si utilizzi un gruppo di chiavi attendibile come firmatario (consigliato) o una coppia di CloudFront chiavi. Per ulteriori informazioni, consultare le sezioni indicate di seguito. La coppia di chiavi creata deve soddisfare i seguenti requisiti:
+ Deve essere una coppia di chiavi SSH-2 RSA 2048 o ECDSA 256.
+ Deve essere in formato PEM codificato in base64.

Per proteggere le applicazioni, ti consigliamo di ruotare periodicamente le coppie di chiavi. Per ulteriori informazioni, consulta [Rotazione di coppie di chiavi](#private-content-rotating-key-pairs).

### Crea una coppia di chiavi per un gruppo di chiavi attendibile (scelta consigliata)
<a name="create-key-pair-and-key-group"></a>

Per creare una coppia di chiavi per un gruppo di chiavi attendibile, attieniti alla seguente procedura:

1. Creare la coppia di chiavi pubbliche-private.

1. Carica la chiave pubblica su CloudFront.

1. Aggiungi la chiave pubblica a un gruppo di CloudFront chiavi.

Per ulteriori informazioni, consulta le procedure seguenti.<a name="private-content-uploading-cloudfront-public-key-procedure"></a>

**Per creare una coppia di chiavi**
**Nota**  
Le fasi seguenti utilizzano OpenSSL come esempio di un metodo per creare una coppia di chiavi. Esistono molti altri modi per creare una coppia di chiavi RSA o ECDSA.

1. Eseguire uno dei seguenti comandi di esempio:
   + Il comando di esempio seguente utilizza OpenSSL per generare una coppia di chiavi RSA con una lunghezza di 2048 bit e salvarla nel file denominato `private_key.pem`.

     ```
     openssl genrsa -out private_key.pem 2048
     ```
   + Il comando di esempio seguente utilizza OpenSSL per generare una coppia di chiavi ECDSA con una curva `prime256v1` e salvarla nel file denominato `private_key.pem`.

     ```
     openssl ecparam -name prime256v1 -genkey -noout -out privatekey.pem
     ```

1. Il file risultante contiene la chiave pubblica e quella privata. Il comando di esempio seguente estrae la chiave pubblica dal file denominato `private_key.pem`.

   ```
   openssl rsa -pubout -in private_key.pem -out public_key.pem
   ```

   Puoi caricare la chiave pubblica (nel file `public_key.pem`) in un secondo momento, nella procedura seguente.

**Per caricare la chiave pubblica su CloudFront**

1. Accedi a Console di gestione AWS e apri la CloudFront console all'indirizzo[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Nel menu di navigazione, scegli **Public keys (Chiavi pubbliche)**.

1. Scegli **Crea chiave pubblica**.

1. Nella finestra **Crea chiave pubblica**, effettua le operazioni seguenti:

   1. In **Key name (Nome chiave)**, digita un nome per identificare la chiave pubblica.

   1. In **Key value (Valore chiave)**, incolla la chiave pubblica. Se hai seguito i passaggi descritti nella procedura precedente, la chiave pubblica si trova nel file denominato `public_key.pem`. Per copiare e incollare il contenuto della chiave pubblica, puoi procedere come segue:
      + Usa il comando **cat** sulla riga di comando macOS o Linux, in questo modo:

        ```
        cat public_key.pem
        ```

        Copia l'output di quel comando, quindi incollalo nel campo **Key value (Valore chiave)**.
      + Apri il `public_key.pem` file con un editor di testo semplice come Notepad (su Windows) o (su macOS). TextEdit Copia il contenuto del file, quindi incollalo nel campo **Key value (Valore chiave)**.

   1. (Facoltativo) Per **Comment (Commento)**, aggiungi un commento per descrivere la chiave pubblica.

   Al termine, scegli **Add (Aggiungi)**.

1. Registra l'ID della chiave pubblica. Lo utilizzerai in seguito quando crei cookie firmati URLs o firmati, come valore del campo. `Key-Pair-Id`

**Per aggiungere la chiave pubblica a un gruppo di chiavi**

1. Apri la CloudFront console all'indirizzo[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Nel menu di navigazione, scegli **Key groups (Gruppi di chiavi)**.

1. Scegli **Add key group (Aggiungi gruppo di chiavi)**.

1. Nella pagina **Create key group (Crea gruppo di chiavi)** effettua le operazioni seguenti:

   1. In **Key group name (Nome gruppo di chiavi)**, digita un nome per identificare il gruppo di chiavi.

   1. (Facoltativo) Per **Comment (Commento)**, digita un commento per descrivere il gruppo di chiavi.

   1. Per **Public keys (Chiavi pubbliche)**, seleziona la chiave pubblica da aggiungere al gruppo di chiavi, quindi scegli **Add (Aggiungi)**. Ripeti questo passaggio per ogni chiave pubblica che desideri aggiungere al gruppo di chiavi.

1. Scegli **Create key group (Crea gruppo di chiavi)**.

1. Registra il nome del gruppo di chiavi. La si usa in seguito per associare il gruppo di chiavi a un comportamento della cache in una CloudFront distribuzione. (Nell' CloudFront API, si utilizza l'ID del gruppo di chiavi per associare il gruppo di chiavi a un comportamento della cache.)

### Creare una CloudFront key pair (scelta non consigliata, richiede l'utente Account AWS root)
<a name="create-key-pair-aws-account"></a>

**Importante**  
Ti consigliamo di creare una chiave pubblica per un gruppo di chiavi attendibili invece della seguente procedura. Per il metodo consigliato per creare chiavi pubbliche per i cookie firmati URLs e firmati, consulta[Crea una coppia di chiavi per un gruppo di chiavi attendibile (scelta consigliata)](#create-key-pair-and-key-group).

È possibile creare una CloudFront key pair nei seguenti modi:
+ Crea una coppia di chiavi in Console di gestione AWS e scarica la chiave privata. Segui la procedura descritta di seguito.
+ Crea un coppia di chiavi RSA utilizzando un'applicazione, ad esempio OpenSSL, e poi carica la chiave pubblica nella Console di gestione AWS. Per ulteriori informazioni sulla creazione di una coppia di chiavi RSA, consulta [Crea una coppia di chiavi per un gruppo di chiavi attendibile (scelta consigliata)](#create-key-pair-and-key-group).<a name="private-content-creating-cloudfront-key-pairs-procedure"></a>

**Per creare coppie di CloudFront chiavi in Console di gestione AWS**

1. Accedi Console di gestione AWS utilizzando le credenziali dell' AWS account utente root.
**Importante**  
Gli utenti IAM non possono creare coppie di CloudFront chiavi. Devi accedere utilizzando le credenziali utente root per creare coppie di chiavi.

1. Scegli il nome dell'account, quindi scegli **My Security Credentials (Le mie credenziali di sicurezza)**.

1. Scegli **coppie di CloudFront chiavi**.

1. Conferma di non avere più di una coppia di chiavi attiva. Non puoi creare una coppia di chiavi se hai già due coppie di chiavi attive.

1. Scegli **Create New Key Pair (Crea nuova coppia di chiavi)**.
**Nota**  
Puoi anche scegliere di creare la tua coppia di chiavi e caricare la chiave pubblica. CloudFront le coppie di chiavi supportano chiavi a 1024, 2048 o 4096 bit.

1. Nella finestra di dialogo **Create Key Pair (Crea coppia di chiavi)** scegli **Download Private Key File (Scarica il file della chiave privata)**, quindi salva il file nel computer.
**Importante**  
Salva la chiave privata per la tua coppia di CloudFront chiavi in una posizione sicura e imposta le autorizzazioni sul file in modo che solo gli amministratori desiderati possano leggerlo. Se qualcuno ottiene la tua chiave privata, può generare cookie firmati URLs e firmati validi e scaricare i tuoi contenuti. Non è possibile recuperare nuovamente la chiave privata, quindi se la si perde o la si elimina, è necessario creare una nuova coppia di CloudFront chiavi.

1. Registra l'ID per la tua coppia di chiavi. (Nel Console di gestione AWS, questo è chiamato **Access Key ID**.) Lo utilizzerai quando crei cookie firmati URLs o firmati.

## Riformattazione della chiave privata (solo .NET e Java)
<a name="private-content-reformatting-private-key"></a>

Se utilizzi .NET o Java per creare cookie firmati URLs o firmati, non puoi utilizzare la chiave privata della tua coppia di chiavi nel formato PEM predefinito per creare la firma. Effettua invece le seguenti operazioni:
+ **.NET Framework**: converti la chiave privata nel formato XML utilizzato da .NET Framework. Sono disponibili vari strumenti per eseguire la conversione.
+ **Java**: converti la chiave privata nel formato DER. Un modo per farlo è con il seguente comando OpenSSL. Nel comando seguente, `private_key.pem` è il nome del file che contiene la chiave privata con formattazione PEM e `private_key.der` è il nome del file che contiene la chiave privata con formattazione DER dopo l'esecuzione del comando.

  ```
  openssl pkcs8 -topk8 -nocrypt -in private_key.pem -inform PEM -out private_key.der -outform DER
  ```

  Per assicurarti che l'encoder funzioni correttamente, aggiungi il JAR per la crittografia Java Bouncy Castle APIs al tuo progetto, quindi aggiungi il provider Bouncy Castle.

## Aggiunta di un firmatario a una distribuzione
<a name="private-content-adding-trusted-signers"></a>

Un firmatario è il gruppo di chiavi attendibile (consigliato) o CloudFront la coppia di chiavi che può creare cookie firmati URLs e firmati per una distribuzione. Per utilizzare i cookie firmati URLs o firmati con una CloudFront distribuzione, devi specificare un firmatario.

I firmatari sono associati ai comportamenti cache. Ciò consente di richiedere cookie firmati URLs o firmati per alcuni file e non per altri della stessa distribuzione. Una distribuzione richiede cookie firmati URLs o cookie solo per i file associati ai comportamenti di cache corrispondenti.

Analogamente, un firmatario può firmare URLs o utilizzare cookie solo per i file associati ai comportamenti di cache corrispondenti. Ad esempio, se hai un firmatario per un comportamento di cache e un firmatario diverso per un diverso comportamento di cache, nessuno dei due firmatari può creare cookie firmati URLs o cookie per i file associati all'altro comportamento di cache.

**Importante**  
Prima di aggiungere un firmatario alla distribuzione, effettua le seguenti operazioni:  
Definisci con attenzione i pattern di percorso nei comportamenti cache e la sequenza dei comportamenti cache in modo da non concedere agli utenti l'accesso non intenzionale al contenuto o impedisca loro di accedere ai contenuti che desideri essere disponibili per tutti.  
Ad esempio, supponiamo che una richiesta corrisponda al modello di percorso per due comportamenti cache. Il primo comportamento di cache non richiede cookie firmati URLs o firmati, mentre il secondo lo richiede. Gli utenti saranno in grado di accedere ai file senza utilizzare cookie firmati URLs o firmati perché CloudFront elabora il comportamento della cache associato alla prima corrispondenza.  
Per ulteriori informazioni sui modelli di percorso, consulta [Modello di percorso](DownloadDistValuesCacheBehavior.md#DownloadDistValuesPathPattern).
Per una distribuzione che stai già utilizzando per distribuire contenuti, assicurati di essere pronto a iniziare a generare cookie firmati URLs e firmati prima di aggiungere un firmatario. Quando aggiungi un firmatario, CloudFront rifiuta le richieste che non includono un URL firmato o un cookie firmato valido.

Puoi aggiungere firmatari alla tua distribuzione utilizzando la CloudFront console o l'API. CloudFront

------
#### [ Console ]

La procedura seguente illustra come aggiungere un gruppo di chiavi attendibili come firmatario. Puoi anche aggiungerne uno Account AWS come firmatario attendibile, ma non è consigliato.<a name="private-content-adding-trusted-signers-console-procedure"></a>

**Per aggiungere un firmatario a una distribuzione utilizzando la console**

1. Registra l'ID gruppo di chiavi del gruppo di chiavi che desideri utilizzare come firmatario attendibile. Per ulteriori informazioni, consulta [Crea una coppia di chiavi per un gruppo di chiavi attendibile (scelta consigliata)](#create-key-pair-and-key-group).

1. Apri la CloudFront console all'indirizzo[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Scegli la distribuzione di cui desideri proteggere i file con cookie firmati URLs o firmati.
**Nota**  
Per aggiungere un firmatario a una nuova distribuzione, specifica le stesse impostazioni descritte nel passaggio 6 per la creazione della distribuzione.

1. Scegli la scheda **Behaviors** (Comportamenti).

1. Seleziona il comportamento della cache il cui modello di percorso corrisponde ai file che desideri proteggere con cookie firmati URLs o firmati, quindi scegli **Modifica**.

1. Nella pagina **Edit Behavior (Modifica comportamento)** effettua le operazioni seguenti:

   1. Per **Limita l'accesso degli spettatori (utilizza cookie firmati URLs o firmati)**, scegli **Sì**.

   1. Per **Trusted Key Groups or Trusted Signer (Gruppi di chiavi attendibili o Firmatari attendibili)**, scegli **Trusted Key Groups (Gruppi di chiavi attendibili)**

   1. Per **Trusted Key Groups (Gruppi di chiavi attendibili)**, scegli il gruppo di chiavi da aggiungere, quindi scegli **Add (Aggiungi)**. Ripeti l'operazione se desideri aggiungere più di un gruppo di chiavi.

1. Scegli **Yes, Edit (Sì, Modifica)** per aggiornare il comportamento cache.

------
#### [ API ]

Puoi utilizzare l' CloudFront API per aggiungere un gruppo di chiavi attendibile come firmatario. Puoi aggiungere un firmatario a una distribuzione esistente o a una nuova distribuzione. In entrambi i casi, specifica i valori nell'elemento `TrustedKeyGroups`.

Puoi anche aggiungerne uno Account AWS come firmatario attendibile, ma non è consigliato.

Consulta i seguenti argomenti nell'*Amazon CloudFront API Reference*:
+ **Aggiorna una distribuzione esistente**: [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)
+ **Crea una nuova distribuzione** — [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html)

------

## Rotazione di coppie di chiavi
<a name="private-content-rotating-key-pairs"></a>

Ti consigliamo di ruotare (modificare) periodicamente le coppie di chiavi per i cookie firmati URLs e firmati. Per ruotare le coppie di chiavi che utilizzi per creare cookie firmati URLs o firmati senza invalidarli URLs o cookie che non sono ancora scaduti, esegui le seguenti operazioni:

1. Crea una nuova coppia di chiavi e aggiungi la chiave pubblica a un gruppo di chiavi. Per ulteriori informazioni, consulta [Crea una coppia di chiavi per un gruppo di chiavi attendibile (scelta consigliata)](#create-key-pair-and-key-group).

1. Se nel passaggio precedente hai creato un nuovo gruppo di chiavi, [aggiungi il gruppo di chiavi alla distribuzione come firmatario](#private-content-adding-trusted-signers).
**Importante**  
Non rimuovere le chiavi pubbliche esistenti dal gruppo di chiavi o i gruppi di chiavi dalla distribuzione. Aggiungi solo nuovi elementi.

1. Aggiorna la tua applicazione per creare firme utilizzando la chiave privata della nuova coppia di chiavi. Verifica che i cookie firmati URLs o quelli firmati con le nuove chiavi private funzionino.

1. Attendi che sia trascorsa la data di scadenza URLs o che i cookie siano stati firmati utilizzando la chiave privata precedente. Quindi rimuovi la vecchia chiave pubblica dal gruppo di chiavi. Se hai creato un nuovo gruppo di chiavi nel passaggio 2, rimuovi il vecchio gruppo di chiavi dalla distribuzione.

# Decidi di utilizzare cookie firmati URLs o firmati
<a name="private-content-choosing-signed-urls-cookies"></a>

CloudFront i cookie firmati URLs e firmati offrono le stesse funzionalità di base: consentono di controllare chi può accedere ai contenuti. Se desideri pubblicare contenuti privati CloudFront e stai cercando di decidere se utilizzare cookie firmati URLs o firmati, prendi in considerazione quanto segue.

Utilizza i file firmati URLs nei seguenti casi:
+ Intendi limitare l'accesso a singoli file, ad esempio, il download di un'installazione per l'applicazione.
+ I tuoi utenti stanno utilizzando un client (ad esempio, un client HTTP personalizzato) che non supporta i cookie.

Utilizza cookie firmati nei seguenti casi:
+ Intendi fornire accesso a più file con restrizioni, ad esempio, tutti i file per un video in formato HLS o tutti i file nell'area abbonati di un sito Web.
+ Non vuoi cambiare la tua versione attuale URLs.

Se attualmente non utilizzi signed URLs e se il file (unsigned) URLs contiene uno dei seguenti parametri della stringa di query, non puoi utilizzare cookie firmati URLs o firmati:
+ `Expires`
+ `Policy`
+ `Signature`
+ `Key-Pair-Id`
+ `Hash-Algorithm`

CloudFront presuppone URLs che i parametri della stringa di query che contengono uno di questi parametri siano firmati URLs e quindi non esaminerà i cookie firmati.

## Utilizza sia i cookie firmati che URLs quelli firmati
<a name="private-content-using-signed-urls-and-cookies"></a>

I cookie firmati URLs hanno la precedenza sui cookie firmati. Se utilizzi sia cookie firmati URLs che firmati per controllare l'accesso agli stessi file e un visualizzatore utilizza un URL firmato per richiedere un file, CloudFront determina se restituire il file al visualizzatore solo in base all'URL firmato.

# Usa firmato URLs
<a name="private-content-signed-urls"></a>

Un URL firmato include ulteriori informazioni, ad esempio, una data e un'ora di scadenza, che offrono un maggiore controllo sull'accesso al tuo contenuto. Queste informazioni aggiuntive appaiono in una dichiarazione di policy, basata su una policy predefinita o personalizzata. Le differenze tra policy predefinite e personalizzate sono descritte nelle due sezioni successive.

**Nota**  
È possibile crearne alcuni firmati URLs utilizzando criteri predefiniti e crearne alcuni firmati URLs utilizzando criteri personalizzati per la stessa distribuzione.

**Topics**
+ [

## Decidi di utilizzare politiche predefinite o personalizzate per la firma URLs
](#private-content-choosing-canned-custom-policy)
+ [

## Come funzionano i URLs firmatari
](#private-content-how-signed-urls-work)
+ [

## Decidi per quanto tempo i firmi URLs sono validi
](#private-content-overview-choosing-duration)
+ [

## When CloudFront controlla la data e l'ora di scadenza in un URL firmato
](#private-content-check-expiration)
+ [

## Codice di esempio e strumenti di terza parte.
](#private-content-overview-sample-code)
+ [

# Creazione di un URL firmato utilizzando una policy di accesso predefinita
](private-content-creating-signed-url-canned-policy.md)
+ [

# Creazione di un URL firmato utilizzando una policy personalizzata
](private-content-creating-signed-url-custom-policy.md)

## Decidi di utilizzare politiche predefinite o personalizzate per la firma URLs
<a name="private-content-choosing-canned-custom-policy"></a>

Quando crei un URL firmato, scrivi una dichiarazione di policy in formato JSON che specifica le restrizioni sull'URL firmato, ad esempio, il periodo di validità dell'URL. Puoi utilizzare una policy predefinita o una personalizzata. Di seguito sono riportate le differenze tra policy predefinite e personalizzate:


****  

| Descrizione | Policy predefinita | Policy personalizzata | 
| --- | --- | --- | 
| Puoi riutilizzare la dichiarazione di policy per più file. Per riutilizzare la dichiarazione di policy, devi utilizzare caratteri jolly nell'oggetto `Resource`. Per ulteriori informazioni, consulta [Valori da specificare in una dichiarazione di policy per un URL firmato che utilizza una policy personalizzata](private-content-creating-signed-url-custom-policy.md#private-content-custom-policy-statement-values).)  | No | Sì | 
| Puoi specificare la data e l'ora in cui gli utenti possono iniziare ad accedere al tuo contenuto. | No | Sì (facoltativo) | 
| Puoi specificare la data e l'ora in cui gli utenti non possono più accedere al tuo contenuto. | Sì | Sì | 
| Puoi specificare l'indirizzo IP o l'intervallo di indirizzi IP degli utenti che possono accedere al tuo contenuto. | No | Sì (facoltativo) | 
| L'URL firmato include una versione con codifica base64 della policy, che risulta in un URL più lungo. | No | Sì | 

Per informazioni sulla creazione di criteri URLs *predefiniti firmati*, consulta. [Creazione di un URL firmato utilizzando una policy di accesso predefinita](private-content-creating-signed-url-canned-policy.md)

Per informazioni sulla creazione di una politica firmata URLs utilizzando una politica *personalizzata*, vedere[Creazione di un URL firmato utilizzando una policy personalizzata](private-content-creating-signed-url-custom-policy.md).

## Come funzionano i URLs firmatari
<a name="private-content-how-signed-urls-work"></a>

Ecco una panoramica di come CloudFront configuri Amazon S3 for signed URLs e di come CloudFront risponde quando un utente utilizza un URL firmato per richiedere un file. 

1. Nella tua CloudFront distribuzione, specifica uno o più gruppi di chiavi affidabili, che contengono le chiavi pubbliche da CloudFront utilizzare per verificare la firma dell'URL. Utilizzi le chiavi private corrispondenti per firmare il URLs.

   CloudFront supporta firme a URLs chiave firmate con RSA 2048 ed ECDSA 256.

   Per ulteriori informazioni, consulta [Specificate i firmatari che possono creare cookie firmati e firmati URLs](private-content-trusted-signers.md).

1. Sviluppa la tua applicazione per determinare se un utente debba avere accesso ai tuoi contenuti e creane una versione firmata URLs per i file o le parti dell'applicazione a cui desideri limitare l'accesso. Per ulteriori informazioni, consulta i seguenti argomenti:
   + [Creazione di un URL firmato utilizzando una policy di accesso predefinita](private-content-creating-signed-url-canned-policy.md)
   + [Creazione di un URL firmato utilizzando una policy personalizzata](private-content-creating-signed-url-custom-policy.md)

1. Un utente richiede la firma di un file per il quale si desidera richiedere la firma URLs.

1. La tua applicazione verifica che l'utente è autorizzato ad accedere al file: ha eseguito l'accesso, ha pagato per accedere al contenuto o ha soddisfatto altri requisiti per l'accesso.

1. La tua applicazione crea e restituisce un URL firmato all'utente.

1. L'URL firmato consente all'utente di scaricare o riprodurre in streaming il contenuto.

   Questa fase è automatica; l'utente in genere non deve eseguire ulteriori operazioni per accedere al contenuto. Ad esempio, se un utente accede al tuo contenuto in un browser Web, l'applicazione restituisce l'URL firmato al browser. Il browser utilizza immediatamente l'URL firmato per accedere al file nella cache CloudFront edge senza alcun intervento da parte dell'utente.

1. CloudFront utilizza la chiave pubblica per convalidare la firma e confermare che l'URL non è stato manomesso. Se la firma non è valida, la richiesta viene respinta. 

   Se la firma è valida, CloudFront esamina l'informativa nell'URL (o ne costruisce una se utilizzi una politica predefinita) per confermare che la richiesta è ancora valida. Ad esempio, se hai specificato una data e un'ora di inizio e di fine per l'URL, CloudFront conferma che l'utente sta tentando di accedere ai tuoi contenuti durante il periodo di tempo in cui desideri consentire l'accesso. 

   Se la richiesta soddisfa i requisiti dell'informativa, CloudFront esegue le operazioni standard: determina se il file è già presente nella cache edge, inoltra la richiesta all'origine se necessario e restituisce il file all'utente.

**Nota**  
Se un URL non firmato contiene parametri di stringa di query, assicurati di includerli nella parte dell'URL che firmi. Se aggiungi una stringa di query a un URL firmato dopo la sua creazione, l'URL restituisce uno stato HTTP 403.

## Decidi per quanto tempo i firmi URLs sono validi
<a name="private-content-overview-choosing-duration"></a>

Puoi distribuire contenuto privato utilizzando un URL firmato valido soltanto per un breve periodo di tempo, anche di pochi minuti. I URLs documenti firmati e validi per un periodo così breve sono utili per distribuire contenuti on-the-fly a un utente per uno scopo specifico, come la distribuzione di film a noleggio o download di musica ai clienti su richiesta. Se i file firmati URLs saranno validi solo per un breve periodo, probabilmente vorrai generarli automaticamente utilizzando un'applicazione sviluppata da te. Quando l'utente inizia a scaricare un file o inizia a riprodurre un file multimediale, CloudFront confronta l'ora di scadenza dell'URL con l'ora corrente per determinare se l'URL è ancora valido.

Puoi anche distribuire contenuto privato utilizzando un URL firmato valido per un periodo di tempo più lungo, anche di vari anni. I URLs documenti firmati validi per un periodo più lungo sono utili per distribuire contenuti privati a utenti noti, ad esempio per distribuire un piano aziendale agli investitori o distribuire materiali di formazione ai dipendenti. Puoi sviluppare un'applicazione per generare questi messaggi firmati a lungo termine per te. URLs 

## When CloudFront controlla la data e l'ora di scadenza in un URL firmato
<a name="private-content-check-expiration"></a>

CloudFront controlla la data e l'ora di scadenza in un URL firmato al momento della richiesta HTTP. Se un client inizia a scaricare un file di grandi dimensioni immediatamente prima della scadenza, il download viene completato anche se la scadenza avviene durante il download. Se la connessione TCP viene interrotta e il client tenta di riavviare il download dopo la scadenza, il download non riesce.

Se un client utilizza Range GETs per ottenere un file in parti più piccole, qualsiasi richiesta GET che si verifica dopo la scadenza avrà esito negativo. Per ulteriori informazioni su RangeGETs, vedere[Come CloudFront elabora le richieste parziali per un oggetto (intervallo GETs)](RangeGETs.md).

## Codice di esempio e strumenti di terza parte.
<a name="private-content-overview-sample-code"></a>

Per un esempio di codice che crea la parte con hash e firma di signed URLs, consulta i seguenti argomenti:
+ [Creazione di una firma per URL utilizzando Perl](CreateURLPerl.md)
+ [Creazione di una firma per URL utilizzando PHP](CreateURL_PHP.md)
+ [Crea una firma per URL utilizzando C\$1 e .NET Framework](CreateSignatureInCSharp.md)
+ [Creazione di una firma per URL utilizzando Java](CFPrivateDistJavaDevelopment.md)

# Creazione di un URL firmato utilizzando una policy di accesso predefinita
<a name="private-content-creating-signed-url-canned-policy"></a>

Per creare un URL firmato utilizzando una policy predefinita, completa la procedura seguente.<a name="private-content-creating-signed-url-canned-policy-procedure"></a>

**Creazione di un URL firmato utilizzando una policy predefinita**

1. Se stai usando .NET o Java per creare un file firmato URLs e se non hai riformattato la chiave privata per la tua coppia di chiavi dal formato.pem predefinito a un formato compatibile con.NET o con Java, fallo ora. Per ulteriori informazioni, consulta [Riformattazione della chiave privata (solo .NET e Java)](private-content-trusted-signers.md#private-content-reformatting-private-key).

1. Concatena i seguenti valori. Puoi utilizzare il formato in questo URL firmato di esempio. 

   ```
   https://d111111abcdef8.cloudfront.net/image.jpg?color=red&size=medium&Expires=1767290400&Signature=nitfHRCrtziwO2HwPfWw~yYDhUF5EwRunQA-j19DzZrvDh6hQ73lDx~-ar3UocvvRQVw6EkC~GdpGQyyOSKQim-TxAnW7d8F5Kkai9HVx0FIu-5jcQb0UEmatEXAMPLE3ReXySpLSMj0yCd3ZAB4UcBCAqEijkytL6f3fVYNGQI6&Key-Pair-Id=K2JCJMDEHXQW5F&Hash-Algorithm=SHA256
   ```

   Rimuovi tutti gli spazi vuoti (compresi i caratteri di tabulazione e di nuova riga). È possibile che tu debba includere caratteri di escape nella stringa del codice dell'applicazione. Tutti i valori hanno un tipo `String`.  
**1. *Base URL for the file***  
L'URL di base è l' CloudFront URL che utilizzeresti per accedere al file se non utilizzassi signed URLs, inclusi i parametri della stringa di query, se presenti. Nell’esempio precedente, l’URL di base è `https://d111111abcdef8.cloudfront.net/image.jpg`. Per ulteriori informazioni sul formato delle URLs distribuzioni, vedere[Personalizza il formato URL per i file in CloudFront](LinkFormat.md).  
   + L' CloudFront URL seguente riguarda un file di immagine in una distribuzione (utilizzando il nome di CloudFront dominio). Nota che `image.jpg` è una directory `images`. Il percorso al file nell'URL deve corrispondere al percorso al file nel server HTTP o nel bucket Amazon S3.

     `https://d111111abcdef8.cloudfront.net/images/image.jpg`
   + Il seguente CloudFront URL include una stringa di query:

     `https://d111111abcdef8.cloudfront.net/images/image.jpg?size=large`
   + Di seguito CloudFront URLs sono riportati i file di immagine in una distribuzione. Entrambi utilizzano un nome di dominio alternativo. Il secondo include una stringa di query:

     `https://www.example.com/images/image.jpg`

     `https://www.example.com/images/image.jpg?color=red`
   + L' CloudFront URL seguente riguarda un file di immagine in una distribuzione che utilizza un nome di dominio alternativo e il protocollo HTTPS:

     `https://www.example.com/images/image.jpg`  
** 2. `?`**  
Il carattere `?` indica che i parametri di query seguono l’URL di base. Includi il carattere `?` anche senza specificare alcun parametro di query.  
Puoi specificare i seguenti parametri di query in qualsiasi ordine.  
**3. *Your query string parameters, if any*`&`**  
(Facoltativo) Puoi immettere parametri della stringa di query personalizzati. A tale scopo, aggiungi una e commerciale (`&`) tra ciascuno di essi, ad esempio `color=red&size=medium`. Puoi specificare parametri della stringa di query in qualsiasi ordine all’interno dell’URL.  
I parametri della stringa di query non possono essere denominati `Expires``Signature`,`Key-Pair-Id`, o`Hash-Algorithm`.  
** 4. `Expires=`*date and time in Unix time format (in seconds) and Coordinated Universal Time (UTC)***  
La data e l'ora in cui desideri che l'URL blocchi l'accesso al file.  
Specifica la data e l'ora di scadenza in formato Unix (in secondi) e UTC. Ad esempio, la data 1 gennaio 2026 10:00 UTC viene convertita in `1767290400` in un formato Unix, come illustrato nell’esempio all’inizio di questo argomento.   
Per usare il tempo epoch, specifica un numero intero a 64 bit per una data non posteriore a `9223372036854775807` (venerdì 11 aprile 2262 alle 23:47:16.854 UTC).  
  
Per informazioni sul formato UTC, consulta [RFC 3339, Date and Time on the Internet: Timestamps](https://tools.ietf.org/html/rfc3339).  
** 5. `&Signature=`*hashed and signed version of the policy statement***  
Una versione con hash, firma e codifica base64 della dichiarazione di policy JSON. Per ulteriori informazioni, consulta [Creazione di una firma per un URL firmato che utilizza una policy di accesso predefinita](#private-content-canned-policy-creating-signature).  
** 6. `&Key-Pair-Id=`*public key ID for the CloudFront public key whose corresponding private key you're using to generate the signature***  
L'ID di una chiave CloudFront pubblica, ad esempio`K2JCJMDEHXQW5F`. L'ID della chiave pubblica indica CloudFront quale chiave pubblica utilizzare per convalidare l'URL firmato. CloudFront confronta le informazioni contenute nella firma con quelle contenute nell'informativa per verificare che l'URL non sia stato manomesso.  
Questa chiave pubblica deve appartenere a un gruppo di chiavi che sia un firmatario attendibile nella distribuzione. Per ulteriori informazioni, consulta [Specificate i firmatari che possono creare cookie firmati e firmati URLs](private-content-trusted-signers.md).  
** 7. `&Hash-Algorithm=`*SHA1 or SHA256***  
(Facoltativo) L'algoritmo hash utilizzato per creare la firma. I valori supportati sono `SHA1` e `SHA256`. Se non si specifica questo parametro, il valore CloudFront predefinito è. `SHA1`

## Creazione di una firma per un URL firmato che utilizza una policy di accesso predefinita
<a name="private-content-canned-policy-creating-signature"></a>

Per creare la firma per un URL firmato che utilizza una policy di accesso predefinita, completa le seguenti procedure.

**Topics**
+ [

### Creazione di una dichiarazione di policy per un URL firmato che utilizza una policy di accesso predefinita
](#private-content-canned-policy-creating-policy-statement)
+ [

### Creazione di una firma per un URL firmato che utilizza una policy di accesso predefinita
](#private-content-canned-policy-signing-policy-statement)

### Creazione di una dichiarazione di policy per un URL firmato che utilizza una policy di accesso predefinita
<a name="private-content-canned-policy-creating-policy-statement"></a>

Quando crei un URL firmato utilizzando una policy predefinita, il parametro `Signature` è una versione con hash e firma di una dichiarazione di policy. Per i criteri firmati URLs che utilizzano una politica predefinita, non includi l'informativa nell'URL, mentre per quelli firmati URLs che utilizzano una politica personalizzata. Per creare una dichiarazione di policy, esegui la procedura descritta di seguito.<a name="private-content-canned-policy-creating-policy-statement-procedure"></a>

**Per creare la dichiarazione di policy per un URL firmato che utilizza una policy predefinita**

1. Crea la dichiarazione di policy utilizzando il formato JSON seguente e la codifica caratteri UTF-8. Includi tutta le punteggiatura e altri valori letterali esattamente come specificato. Per informazioni sui parametri `Resource` e `DateLessThan`, consulta [Valori da specificare in una dichiarazione di policy per un URL firmato che utilizza una policy predefinita](#private-content-canned-policy-statement-values).

   ```
   {
       "Statement": [
           {
               "Resource": "base URL or stream name",
               "Condition": {
                   "DateLessThan": {
                       "AWS:EpochTime": ending date and time in Unix time format and UTC
                   }
               }
           }
       ]
   }
   ```

1. Rimuovi tutti gli spazi vuoti (inclusi i caratteri di nuova riga e le tabulazioni) dalla dichiarazione di policy. È possibile che tu debba includere caratteri di escape nella stringa del codice dell'applicazione.

#### Valori da specificare in una dichiarazione di policy per un URL firmato che utilizza una policy predefinita
<a name="private-content-canned-policy-statement-values"></a>

Quando crei una dichiarazione di policy per una policy predefinita, specifichi i valori seguenti.

**Risorsa**  
Puoi specificare un solo valore per `Resource`.
L'URL di base che include le stringhe di query, se presenti, ma escludendo CloudFront `Expires`, `Signature``Key-Pair-Id`, e `Hash-Algorithm` i parametri, ad esempio:  
`https://d111111abcdef8.cloudfront.net/images/horizon.jpg?size=large&license=yes`  
Tenere presente quanto segue:  
+ **Protocollo**: il valore deve iniziare con `http://` o `https://`.
+ **Parametri di stringa di query**: se non hai parametri di stringa di query, ometti il punto di domanda.
+ **Nomi di dominio alternativi**: se specifichi un nome di dominio alternativo (CNAME) nell'URL, devi specificarlo quando fai riferimento al file nella pagina Web o nell'applicazione. Non specificare l'URL di Amazon S3 per l'oggetto.

**DateLessThan**  
La data e l'ora di scadenza per l'URL in formato Unix (in secondi) e UTC. Ad esempio, le 10:00 UTC del 1° gennaio 2026 vengono convertite in 1767290400 nel formato orario Unix.  
Questo valore deve corrispondere al valore del parametro di stringa di query `Expires` nell'URL firmato. Non racchiudere il valore tra virgolette.  
Per ulteriori informazioni, consulta [When CloudFront controlla la data e l'ora di scadenza in un URL firmato](private-content-signed-urls.md#private-content-check-expiration).

#### Esempio di dichiarazione di policy per un URL firmato che utilizza una policy predefinita
<a name="private-content-canned-policy-creating-policy-statement-example"></a>

Quando si utilizza la seguente dichiarazione politica di esempio in un URL firmato, un utente può accedere al file `https://d111111abcdef8.cloudfront.net/horizon.jpg` fino alle 10:00 UTC del 1° gennaio 2026:

```
{
    "Statement": [
        {
            "Resource": "https://d111111abcdef8.cloudfront.net/horizon.jpg?size=large&license=yes",
            "Condition": {
                "DateLessThan": {
                    "AWS:EpochTime": 1767290400
                }
            }
        }
    ]
}
```

### Creazione di una firma per un URL firmato che utilizza una policy di accesso predefinita
<a name="private-content-canned-policy-signing-policy-statement"></a>

Per creare il valore per il parametro `Signature` in un URL firmato, devi sottoporre a hashing e firmare la dichiarazione di policy creata in [Creazione di una dichiarazione di policy per un URL firmato che utilizza una policy di accesso predefinita](#private-content-canned-policy-creating-policy-statement).

Per ulteriori informazioni ed esempi su come sottoporre a hashing, firmare e codificare la dichiarazione di policy, consulta:
+ [Comandi Linux e OpenSSL per la crittografia e la codifica base64](private-content-linux-openssl.md)
+ [Codice di esempio per la creazione di una firma per un URL firmato](PrivateCFSignatureCodeAndExamples.md)

**Nota**  
Gli esempi collegati utilizzano SHA-1 per impostazione predefinita. Per utilizzare invece SHA-256, sostituiscilo `sha1` con `sha256` nei comandi OpenSSL e includi il parametro di `Hash-Algorithm=SHA256` query nell'URL firmato.<a name="private-content-canned-policy-creating-signature-download-procedure"></a>

**Opzione 1: per creare una firma utilizzando una policy predefinita**

1. Utilizzate la funzione hash SHA-1 o SHA-256 e la chiave privata RSA o ECDSA generata per eseguire l'hash e firmare la dichiarazione di policy creata nella procedura. [Per creare la dichiarazione di policy per un URL firmato che utilizza una policy predefinita](#private-content-canned-policy-creating-policy-statement-procedure) Utilizza la versione della dichiarazione di policy che non include più spazi vuoti.

   Se si utilizza SHA-256, è necessario includerlo nell'URL firmato. `&Hash-Algorithm=SHA256`

   Per la chiave privata richiesta dalla funzione hash, utilizza una chiave privata la cui chiave pubblica si trova in un gruppo di chiavi attendibili attivo per la distribuzione.
**Nota**  
Il metodo utilizzato per sottoporre a hashing e firmare la dichiarazione di policy dipende dalla piattaforma e dal linguaggio di programmazione. Per il codice di esempio, consulta [Codice di esempio per la creazione di una firma per un URL firmato](PrivateCFSignatureCodeAndExamples.md).

1. Rimuovi gli spazi vuoti (inclusi i caratteri di nuova riga e le tabulazioni) dalla stringa con hash e firmata.

1. Codifica la stringa utilizzando la codifica base64 MIME. Per ulteriori informazioni, vedere [Sezione 6.8, Base64 Content-Transfer-Encoding in RFC 2045,](https://tools.ietf.org/html/rfc2045#section-6.8) *MIME (Multipurpose Internet Mail Extensions), parte prima: Formato dei corpi dei messaggi Internet*.

1. Sostituisci i caratteri non validi nella stringa di query dell'URL con caratteri validi. La tabella seguente elenca i caratteri validi e non validi.  
****    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonCloudFront/latest/DeveloperGuide/private-content-creating-signed-url-canned-policy.html)

1. Aggiungi il valore risultante all'URL firmato dopo `&Signature=` e ritorna a [Creazione di un URL firmato utilizzando una policy predefinita](#private-content-creating-signed-url-canned-policy-procedure) per completare il concatenamento delle parti dell'URL firmato.

# Creazione di un URL firmato utilizzando una policy personalizzata
<a name="private-content-creating-signed-url-custom-policy"></a>

Per creare un URL firmato utilizzando una policy personalizzata, completa la procedura seguente.<a name="private-content-creating-signed-url-custom-policy-procedure"></a>

**Per creare un URL firmato utilizzando una policy personalizzata**

1. Se stai usando .NET o Java per creare un file firmato URLs e se non hai riformattato la chiave privata per la tua coppia di chiavi dal formato.pem predefinito a un formato compatibile con.NET o con Java, fallo ora. Per ulteriori informazioni, consulta [Riformattazione della chiave privata (solo .NET e Java)](private-content-trusted-signers.md#private-content-reformatting-private-key).

1. Concatena i seguenti valori. Puoi utilizzare il formato in questo URL firmato di esempio.

   

   ```
   https://d111111abcdef8.cloudfront.net/image.jpg?color=red&size=medium&Policy=eyANCiAgICEXAMPLEW1lbnQiOiBbeyANCiAgICAgICJSZXNvdXJjZSI6Imh0dHA6Ly9kemJlc3FtN3VuMW0wLmNsb3VkZnJvbnQubmV0L2RlbW8ucGhwIiwgDQogICAgICAiQ29uZGl0aW9uIjp7IA0KICAgICAgICAgIklwQWRkcmVzcyI6eyJBV1M6U291cmNlSXAiOiIyMDcuMTcxLjE4MC4xMDEvMzIifSwNCiAgICAgICAgICJEYXRlR3JlYXRlclRoYW4iOnsiQVdTOkVwb2NoVGltZSI6MTI5Njg2MDE3Nn0sDQogICAgICAgICAiRGF0ZUxlc3NUaGFuIjp7IkFXUzpFcG9jaFRpbWUiOjEyOTY4NjAyMjZ9DQogICAgICB9IA0KICAgfV0gDQp9DQo&Signature=nitfHRCrtziwO2HwPfWw~yYDhUF5EwRunQA-j19DzZrvDh6hQ73lDx~-ar3UocvvRQVw6EkC~GdpGQyyOSKQim-TxAnW7d8F5Kkai9HVx0FIu-5jcQb0UEmatEXAMPLE3ReXySpLSMj0yCd3ZAB4UcBCAqEijkytL6f3fVYNGQI6&Key-Pair-Id=K2JCJMDEHXQW5F&Hash-Algorithm=SHA256
   ```

   Rimuovi tutti gli spazi vuoti (compresi i caratteri di tabulazione e di nuova riga). È possibile che tu debba includere caratteri di escape nella stringa del codice dell'applicazione. Tutti i valori hanno un tipo `String`.  
**1. *Base URL for the file***  
L'URL di base è l' CloudFront URL che utilizzeresti per accedere al file se non utilizzassi signed URLs, inclusi i parametri della stringa di query, se presenti. Nell’esempio precedente, l’URL di base è `https://d111111abcdef8.cloudfront.net/image.jpg`. Per ulteriori informazioni sul formato delle URLs distribuzioni, vedere[Personalizza il formato URL per i file in CloudFront](LinkFormat.md).  
I seguenti esempi mostrano i valori che specifichi per le distribuzioni.  
   + L' CloudFront URL seguente riguarda un file di immagine in una distribuzione (utilizzando il nome di CloudFront dominio). Nota che `image.jpg` è una directory `images`. Il percorso al file nell'URL deve corrispondere al percorso al file nel server HTTP o nel bucket Amazon S3.

     `https://d111111abcdef8.cloudfront.net/images/image.jpg`
   + Il seguente CloudFront URL include una stringa di query:

     `https://d111111abcdef8.cloudfront.net/images/image.jpg?size=large`
   + Di seguito CloudFront URLs sono riportati i file di immagine in una distribuzione. Entrambi utilizzano un nome di dominio alternativo; il secondo include una stringa di query:

     `https://www.example.com/images/image.jpg`

     `https://www.example.com/images/image.jpg?color=red`
   + L' CloudFront URL seguente riguarda un file di immagine in una distribuzione che utilizza un nome di dominio alternativo e il protocollo HTTPS:

     `https://www.example.com/images/image.jpg`  
**2. `?`**  
Il carattere `?` indica che i parametri della stringa di query seguono l’URL di base. Includi il carattere `?` anche senza specificare alcun parametro di query.  
Puoi specificare i seguenti parametri di query in qualsiasi ordine.  
**3. *Your query string parameters, if any*`&`**  
(Facoltativo) Puoi immettere parametri della stringa di query personalizzati. A tale scopo, aggiungi una e commerciale (&) tra ciascuno di essi, ad esempio `color=red&size=medium`. Puoi specificare parametri della stringa di query in qualsiasi ordine all’interno dell’URL.  
I parametri della stringa di query non possono essere denominati `Policy``Signature`,`Key-Pair-Id`, o`Hash-Algorithm`.
Se aggiungi parametri personalizzati, aggiungi un carattere `&` dopo ciascuno di essi, compreso l’ultimo.   
**4. `Policy=`*base64 encoded version of policy statement***  
La dichiarazione di policy in formato JSON, con spazi vuoti rimossi e codifica base64. Per ulteriori informazioni, consulta [Creazione di una dichiarazione di policy per un URL firmato che utilizza una policy personalizzata](#private-content-custom-policy-statement).  
La dichiarazione di policy controlla l'accesso che un URL firmato concede a un utente. Include l'URL del file, una data e un'ora di scadenza, una data e un'ora facoltative in cui l'URL diventa valido e un indirizzo IP facoltativo o un intervallo di indirizzi IP a cui è consentito accedere al file.  
**5. `&Signature=`*hashed and signed version of the policy statement***  
Una versione con hash, firma e codifica base64 della dichiarazione di policy JSON. Per ulteriori informazioni, consulta [Creazione di una firma per un URL firmato che utilizza una policy personalizzata](#private-content-custom-policy-creating-signature).  
**6. `&Key-Pair-Id=`*public key ID for the CloudFront public key whose corresponding private key you're using to generate the signature***  
L'ID di una chiave CloudFront pubblica, ad esempio`K2JCJMDEHXQW5F`. L'ID della chiave pubblica indica CloudFront quale chiave pubblica utilizzare per convalidare l'URL firmato. CloudFrontconfronta le informazioni contenute nella firma con quelle contenute nell'informativa per verificare che l'URL non sia stato manomesso.  
Questa chiave pubblica deve appartenere a un gruppo di chiavi che sia un firmatario attendibile nella distribuzione. Per ulteriori informazioni, consulta [Specificate i firmatari che possono creare cookie firmati e firmati URLs](private-content-trusted-signers.md).  
**7. `&Hash-Algorithm=`*SHA1 or SHA256***  
(Facoltativo) L'algoritmo hash utilizzato per creare la firma. I valori supportati sono `SHA1` e `SHA256`. Se non si specifica questo parametro, il valore CloudFront predefinito è. `SHA1`

## Creazione di una dichiarazione di policy per un URL firmato che utilizza una policy personalizzata
<a name="private-content-custom-policy-statement"></a>

Completa i passaggi seguenti per creare un’istruzione di policy per un URL firmato che utilizza una policy personalizzata.

Per esempi di istruzioni di policy che controllano l'accesso a file in vari modi, consultare [Esempi di dichiarazioni di policy per un URL firmato che utilizza una policy personalizzata](#private-content-custom-policy-statement-examples).<a name="private-content-custom-policy-creating-policy-procedure"></a>

**Creazione di una dichiarazione di policy per un URL firmato che utilizza una policy personalizzata**

1. Crea la dichiarazione di policy utilizzando il formato JSON seguente. Sostituisci i simboli minore di (`<`) e maggiore di (`>`) e le relative descrizioni con i tuoi valori. Per ulteriori informazioni, consulta [Valori da specificare in una dichiarazione di policy per un URL firmato che utilizza una policy personalizzata](#private-content-custom-policy-statement-values).

   ```
   {
       "Statement": [
           {
               "Resource": "<Optional but recommended: URL of the file>",
               "Condition": {
                   "DateLessThan": {
   	                "AWS:EpochTime": <Required: ending date and time in Unix time format and UTC>
                   },
                   "DateGreaterThan": {
   	                "AWS:EpochTime": <Optional: beginning date and time in Unix time format and UTC>
                   },
                   "IpAddress": {
   	                "AWS:SourceIp": "<Optional: IP address>"
                   }
               }
           }
       ]
   }
   ```

   Tenere presente quanto segue:
   + Puoi includere una sola istruzione nella policy.
   + Utilizza la codifica caratteri UTF-8.
   + Includi tutta le punteggiatura e nomi di parametro esattamente come specificato. Le abbreviazioni per i nomi di parametro non sono accettate.
   + L'ordine dei parametri nella sezione `Condition` non è rilevante.
   + Per informazioni sui valori per `Resource`, `DateLessThan`, `DateGreaterThan` e `IpAddress`, consulta [Valori da specificare in una dichiarazione di policy per un URL firmato che utilizza una policy personalizzata](#private-content-custom-policy-statement-values).

1. Rimuovi tutti gli spazi vuoti (inclusi i caratteri di nuova riga e le tabulazioni) dalla dichiarazione di policy. È possibile che tu debba includere caratteri di escape nella stringa del codice dell'applicazione.

1. Codifica la dichiarazione di policy utilizzando la codifica base64 MIME. Per ulteriori informazioni, vedere [Sezione 6.8, Base64 Content-Transfer-Encoding in RFC 2045,](https://tools.ietf.org/html/rfc2045#section-6.8) *MIME (Multipurpose Internet Mail Extensions), parte prima: Formato dei corpi dei messaggi Internet*.

1. Sostituisci i caratteri non validi nella stringa di query dell'URL con caratteri validi. La tabella seguente elenca i caratteri validi e non validi.  
****    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonCloudFront/latest/DeveloperGuide/private-content-creating-signed-url-custom-policy.html)

1. Aggiungi il valore risultante al tuo URL firmato dopo `Policy=`.

1. Crea una firma per l'URL firmato sottoponendo a hashing, firmando e codificando in base64 la dichiarazione di policy. Per ulteriori informazioni, consulta [Creazione di una firma per un URL firmato che utilizza una policy personalizzata](#private-content-custom-policy-creating-signature).

### Valori da specificare in una dichiarazione di policy per un URL firmato che utilizza una policy personalizzata
<a name="private-content-custom-policy-statement-values"></a>

Quando crei una dichiarazione di policy per una policy personalizzata, specifichi i valori seguenti.

**Risorsa**  
L'URL, incluse tutte le stringhe di query, ma esclusi i parametri,, e. CloudFront `Policy` `Signature` `Key-Pair-Id` `Hash-Algorithm` Esempio:  
`https://d111111abcdef8.cloudfront.net/images/horizon.jpg\?size=large&license=yes`  
Puoi specificare un solo valore URL per `Resource`.  
È possibile omettere il parametro `Resource` in una policy, ma in questo caso chiunque con l’URL firmato può accedere a *tutti* i file in *qualsiasi* distribuzione associata alla coppia di chiavi utilizzata per creare l’URL firmato.
Tenere presente quanto segue:  
+ **Protocollo**: il valore deve iniziare con `http://` `https://` o `*://`.
+ **Parametri della stringa** di query: se l'URL contiene parametri della stringa di query, non utilizzate una barra rovesciata (`\`) per evitare il carattere del punto interrogativo (`?`) che inizia la stringa di query. Esempio:

  `https://d111111abcdef8.cloudfront.net/images/horizon.jpg?size=large&license=yes`
+ **Caratteri jolly**: puoi utilizzare caratteri jolly nell'URL della policy. Sono supportati i seguenti caratteri jolly:
  + asterisco (`*`), che corrisponde a zero o più caratteri
  + punto interrogativo (`?`), che corrisponde esattamente a un carattere

  Quando l'URL nella policy CloudFront corrisponde all'URL nella richiesta HTTP, l'URL nella policy viene diviso in quattro sezioni: protocol, domain, path e query string, come segue:

  `[protocol]://[domain]/[path]\?[query string]`

  Quando si utilizza un carattere jolly nell'URL nella policy, la corrispondenza con i caratteri jolly si applica solo entro i limiti della sezione che contiene il carattere jolly. Ad esempio, considera questo URL in una policy:

  `https://www.example.com/hello*world`

  In questo esempio, l'asterisco wildcard (`*`) si applica solo all'interno della sezione path, quindi corrisponde a URLs `https://www.example.com/helloworld` and`https://www.example.com/hello-world`, ma non all'URL. `https://www.example.net/hello?world`

  Le seguenti eccezioni si applicano ai limiti delle sezioni per la corrispondenza con i caratteri jolly:
  + Un asterisco finale nella sezione del percorso implica un asterisco nella sezione della stringa di query. Ad esempio, `http://example.com/hello*` è uguale a `http://example.com/hello*\?*`.
  + Un asterisco finale nella sezione del dominio implica un asterisco nelle sezioni del percorso e della stringa di query. Ad esempio, `http://example.com*` è uguale a `http://example.com*/*\?*`.
  + Un URL nella policy può omettere la sezione del protocollo e iniziare con un asterisco nella sezione del dominio. In tal caso, la sezione del protocollo è impostata implicitamente su un asterisco. Ad esempio, l'URL `*example.com` in una policy è equivalente a `*://*example.com/`.
  + Un asterisco da solo (`"Resource": "*"`) corrisponde a qualsiasi URL.

  Ad esempio, il valore: `https://d111111abcdef8.cloudfront.net/*game_download.zip*` in una policy corrisponde a tutti i seguenti valori: URLs
  + `https://d111111abcdef8.cloudfront.net/game_download.zip`
  + `https://d111111abcdef8.cloudfront.net/example_game_download.zip?license=yes`
  + `https://d111111abcdef8.cloudfront.net/test_game_download.zip?license=temp`
+ **Nomi di dominio alternativi**: se specifichi un nome di dominio alternativo (CNAME) nell'URL nella policy, la richiesta HTTP deve utilizzare il nome di dominio alternativo nella pagina Web o nell’applicazione. Non specificare l'URL Amazon S3 per il file in una policy.

**DateLessThan**  
La data e l'ora di scadenza per l'URL in formato Unix (in secondi) e UTC. Nella policy, non racchiudere il valore tra virgolette. Per informazioni sul formato UTC, consultare [Date and Time on the Internet: Timestamps](https://tools.ietf.org/html/rfc3339).  
Ad esempio, la data 31 gennaio 2023 10:00 UTC viene convertita in 1675159200 nel formato Unix.  
Questo è l'unico parametro obbligatorio nella `Condition` sezione. CloudFront richiede questo valore per impedire agli utenti di avere accesso permanente ai tuoi contenuti privati.  
Per ulteriori informazioni, consulta [When CloudFront controlla la data e l'ora di scadenza in un URL firmato](private-content-signed-urls.md#private-content-check-expiration)

**DateGreaterThan (Facoltativo)**  
Una data e un'ora di inizio (facoltative) per l'URL in formato Unix (in secondi) e UTC. Agli utenti non è consentito accedere al file prima o in corrispondenza della data e ora specificate. Non racchiudere il valore tra virgolette. 

**IpAddress (Opzionale)**  
L'indirizzo IP del client che esegue la richiesta HTTP. Tenere presente quanto segue:  
+ Per consentire a qualsiasi indirizzo IP di accedere al file, ometti il parametro `IpAddress`.
+ Puoi specificare un indirizzo IP o un intervallo di indirizzi IP. Non puoi utilizzare la policy per consentire l'accesso se l'indirizzo IP del client si trova in uno dei due intervalli distinti.
+ Per consentire l'accesso da un singolo indirizzo IP, specifica:

  `"`*IPv4 IP address*`/32"`
+ È necessario specificare gli intervalli di indirizzi IP nel formato IPv4 CIDR standard (ad esempio,`192.0.2.0/24`). Per ulteriori informazioni, consultare [Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan](https://tools.ietf.org/html/rfc4632).
**Importante**  
Gli indirizzi IP in IPv6 formato, ad esempio 2001:0 db 8:85 a3: :8a2e: 0370:7334, non sono supportati. 

  Se utilizzi una politica personalizzata che include, non abilitarla per la distribuzione. `IpAddress` IPv6 Se desideri limitare l'accesso ad alcuni contenuti in base all'indirizzo IP e IPv6 alle richieste di supporto per altri contenuti, puoi creare due distribuzioni. Per ulteriori informazioni, consulta [Abilita IPv6 (richieste del visualizzatore)](DownloadDistValuesGeneral.md#DownloadDistValuesEnableIPv6) nell'argomento [Riferimento a tutte le impostazioni di distribuzione](distribution-web-values-specify.md).

## Esempi di dichiarazioni di policy per un URL firmato che utilizza una policy personalizzata
<a name="private-content-custom-policy-statement-examples"></a>

Gli esempi di dichiarazioni di policy seguenti mostrano il modo in cui controllare l'accesso a un determinato file, a tutti i file in una directory o a tutti i file associati a un ID di coppia di chiavi. Gli esempi mostrano inoltre come controllare l'accesso da un singolo indirizzo IP o da un intervallo di indirizzi IP e come impedire agli utenti di utilizzare l'URL firmato dopo una data e un'ora specificate.

Se copi e incolli uno di questi esempi, devi rimuovere gli eventuali spazi vuoti (inclusi i caratteri di nuova riga e le tabulazioni), sostituire i valori con i tuoi valori e includere un carattere di nuova riga dopo la parentesi graffa di chiusura (`}`).

Per ulteriori informazioni, consulta [Valori da specificare in una dichiarazione di policy per un URL firmato che utilizza una policy personalizzata](#private-content-custom-policy-statement-values).

**Topics**
+ [

### Esempio di dichiarazione di policy: accesso a un file da un intervallo di indirizzi IP
](#private-content-custom-policy-statement-example-one-object)
+ [

### Esempio di dichiarazione di policy: accesso a tutti i file in una directory da un intervallo di indirizzi IP
](#private-content-custom-policy-statement-example-all-objects)
+ [

### Esempio di dichiarazione di policy: accesso a tutti i file associati a un ID di coppia di chiavi da un indirizzo IP
](#private-content-custom-policy-statement-example-one-ip)

### Esempio di dichiarazione di policy: accesso a un file da un intervallo di indirizzi IP
<a name="private-content-custom-policy-statement-example-one-object"></a>

L'esempio di policy personalizzata seguente in un URL firmato specifica che un utente può accedere al file `https://d111111abcdef8.cloudfront.net/game_download.zip` dagli indirizzi IP nell'intervallo `192.0.2.0/24` fino al 31 gennaio 2023 10:00 UTC:

```
{
    "Statement": [
        {
            "Resource": "https://d111111abcdef8.cloudfront.net/game_download.zip",
            "Condition": {
                "IpAddress": {
                    "AWS:SourceIp": "192.0.2.0/24"
                },
                "DateLessThan": {
                    "AWS:EpochTime": 1675159200
                }
            }
        }
    ]
}
```

### Esempio di dichiarazione di policy: accesso a tutti i file in una directory da un intervallo di indirizzi IP
<a name="private-content-custom-policy-statement-example-all-objects"></a>

Il seguente esempio di politica personalizzata consente di creare un carattere firmato URLs per qualsiasi file nella `training` directory, come indicato dal carattere jolly asterisco (`*`) nel parametro. `Resource` Gli utenti possono accedere al file da un indirizzo IP incluso nell'intervallo `192.0.2.0/24` fino al 31 gennaio 2023 10:00 UTC:

```
{
    "Statement": [
        {
            "Resource": "https://d111111abcdef8.cloudfront.net/training/*",
            "Condition": {
                "IpAddress": {
                    "AWS:SourceIp": "192.0.2.0/24"
                },
                "DateLessThan": {
                    "AWS:EpochTime": 1675159200
                }
            }
        }
    ]
}
```

Ogni URL firmato con cui utilizzi questa policy, dispone di un URL che identifica un file specifico, ad esempio:

`https://d111111abcdef8.cloudfront.net/training/orientation.pdf`

### Esempio di dichiarazione di policy: accesso a tutti i file associati a un ID di coppia di chiavi da un indirizzo IP
<a name="private-content-custom-policy-statement-example-one-ip"></a>

La politica personalizzata di esempio seguente consente di creare un carattere firmato URLs per qualsiasi file associato a qualsiasi distribuzione, come indicato dal carattere jolly asterisco (`*`) nel parametro. `Resource` L'URL firmato deve utilizzare il protocollo `https://`, non `http://`. L'utente deve utilizzare l'indirizzo I `192.0.2.10/32`. (il valore `192.0.2.10/32` nella notazione CIDR fa riferimento a un singolo indirizzo IP, `192.0.2.10`). I file sono disponibili solo dal 31 gennaio 2023 10:00 UTC fino al 2 febbraio 2023 10:00 UTC:

```
{
    "Statement": [
       {
            "Resource": "https://*",
            "Condition": {
                "IpAddress": {
                    "AWS:SourceIp": "192.0.2.10/32"
                },
                "DateGreaterThan": {
                    "AWS:EpochTime": 1675159200
                },
                "DateLessThan": {
                    "AWS:EpochTime": 1675332000
                }
            }
        }
    ]
}
```

Ogni URL firmato con cui utilizzate questa politica ha un URL che identifica un file specifico in una CloudFront distribuzione specifica, ad esempio:

`https://d111111abcdef8.cloudfront.net/training/orientation.pdf`

L'URL firmato include inoltre un ID di coppia di chiavi, che deve essere associato a un gruppo di chiavi attendibili nella distribuzione (d111111abcdef8.cloudfront.net) specificata nell'URL.

## Creazione di una firma per un URL firmato che utilizza una policy personalizzata
<a name="private-content-custom-policy-creating-signature"></a>

La firma per un URL firmato che utilizza una policy personalizzata è una versione con firma, hash e codifica base64 della dichiarazione della policy. Per creare una firma per una policy personalizzata, procedi come indicato di seguito.

Per ulteriori informazioni ed esempi su come sottoporre a hashing, firmare e codificare la dichiarazione di policy, consulta:
+ [Comandi Linux e OpenSSL per la crittografia e la codifica base64](private-content-linux-openssl.md)
+ [Codice di esempio per la creazione di una firma per un URL firmato](PrivateCFSignatureCodeAndExamples.md)

**Nota**  
Gli esempi collegati utilizzano SHA-1 per impostazione predefinita. Per utilizzare invece SHA-256, sostituiscilo `sha1` con `sha256` nei comandi OpenSSL e includi il parametro di `Hash-Algorithm=SHA256` query nell'URL firmato.<a name="private-content-custom-policy-creating-signature-download-procedure"></a>

**Opzione 1: per creare una firma utilizzando una policy personalizzata**

1. Utilizzate la funzione hash SHA-1 o SHA-256 e la chiave privata RSA o ECDSA generata per eseguire l'hash e firmare la dichiarazione di policy JSON creata nella procedura. [Creazione di una dichiarazione di policy per un URL firmato che utilizza una policy personalizzata](#private-content-custom-policy-creating-policy-procedure) Utilizza la versione della dichiarazione di policy che non include più spazi vuoti, ma che non è ancora stata codificata in base64.

   Se utilizzi SHA-256, devi includerlo nell'URL firmato. `&Hash-Algorithm=SHA256`

   Per la chiave privata richiesta dalla funzione hash, utilizza una chiave privata la cui chiave pubblica si trova in un gruppo di chiavi attendibili attivo per la distribuzione.
**Nota**  
Il metodo utilizzato per sottoporre a hashing e firmare la dichiarazione di policy dipende dalla piattaforma e dal linguaggio di programmazione. Per il codice di esempio, consulta [Codice di esempio per la creazione di una firma per un URL firmato](PrivateCFSignatureCodeAndExamples.md).

1. Rimuovi gli spazi vuoti (inclusi i caratteri di nuova riga e le tabulazioni) dalla stringa con hash e firmata.

1. Codifica la stringa utilizzando la codifica base64 MIME. Per ulteriori informazioni, vedere [Sezione 6.8, Base64 Content-Transfer-Encoding in RFC 2045,](https://tools.ietf.org/html/rfc2045#section-6.8) *MIME (Multipurpose Internet Mail Extensions), parte prima: Formato dei corpi dei messaggi Internet*.

1. Sostituisci i caratteri non validi nella stringa di query dell'URL con caratteri validi. La tabella seguente elenca i caratteri validi e non validi.  
****    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonCloudFront/latest/DeveloperGuide/private-content-creating-signed-url-custom-policy.html)

1. Aggiungi il valore risultante all'URL firmato dopo `&Signature=` e ritorna a [Per creare un URL firmato utilizzando una policy personalizzata](#private-content-creating-signed-url-custom-policy-procedure) per completare il concatenamento delle parti dell'URL firmato.

# Utilizzo di cookie firmati
<a name="private-content-signed-cookies"></a>

CloudFront i cookie firmati consentono di controllare chi può accedere ai contenuti quando non si desidera modificare quelli correnti URLs o quando si desidera consentire l'accesso a più file con restrizioni, ad esempio tutti i file presenti nell'area riservata agli abbonati di un sito Web. Questo argomento descrive le considerazioni relative all'utilizzo di cookie firmati e come definire cookie firmati utilizzando policy predefinite e personalizzate.

**Topics**
+ [

## Scelta se utilizzare policy di accesso predefinite o personalizzate per cookie firmati
](#private-content-choosing-canned-custom-cookies)
+ [

## Funzionamento di cookie firmati
](#private-content-how-signed-cookies-work)
+ [

## Prevenzione contro l’uso improprio di cookie firmati
](#private-content-signed-cookie-misuse)
+ [

## When CloudFront controlla la data e l'ora di scadenza in un cookie firmato
](#private-content-check-expiration-cookie)
+ [

## Codice di esempio e strumenti di terza parte.
](#private-content-overview-sample-code-cookies)
+ [

# Impostazione di cookie firmati mediante una policy di accesso predefinita
](private-content-setting-signed-cookie-canned-policy.md)
+ [

# Impostazione di cookie firmati che utilizzano una policy personalizzata
](private-content-setting-signed-cookie-custom-policy.md)
+ [

# Creazione di cookie firmati utilizzando PHP
](signed-cookies-PHP.md)

## Scelta se utilizzare policy di accesso predefinite o personalizzate per cookie firmati
<a name="private-content-choosing-canned-custom-cookies"></a>

Quando crei un cookie firmato, scrivi una dichiarazione di policy in formato JSON che specifica le restrizioni sul cookie firmato, ad esempio, il periodo di validità del cookie. Puoi utilizzare policy predefinite o policy personalizzate. La seguente tabella confronta questi due tipi di policy:


****  

| Descrizione | Policy predefinita | Policy personalizzata | 
| --- | --- | --- | 
| Puoi riutilizzare la dichiarazione di policy per più file. Per riutilizzare la dichiarazione di policy, devi utilizzare caratteri jolly nell'oggetto `Resource`. Per ulteriori informazioni, consulta [Valori da specificare in una dichiarazione di policy per cookie firmati che utilizzano una policy personalizzata](private-content-setting-signed-cookie-custom-policy.md#private-content-custom-policy-statement-cookies-values).)  | No | Sì | 
| Puoi specificare la data e l'ora in cui gli utenti possono iniziare ad accedere al tuo contenuto. | No | Sì (facoltativo) | 
| Puoi specificare la data e l'ora in cui gli utenti non possono più accedere al tuo contenuto. | Sì | Sì | 
| Puoi specificare l'indirizzo IP o l'intervallo di indirizzi IP degli utenti che possono accedere al tuo contenuto | No | Sì (facoltativo) | 

Per informazioni sulla creazione di cookie firmati utilizzando una policy predefinita, consulta [Impostazione di cookie firmati mediante una policy di accesso predefinita](private-content-setting-signed-cookie-canned-policy.md).

Per informazioni sulla creazione di cookie firmati utilizzando una policy personalizzata, consulta [Impostazione di cookie firmati che utilizzano una policy personalizzata](private-content-setting-signed-cookie-custom-policy.md).

## Funzionamento di cookie firmati
<a name="private-content-how-signed-cookies-work"></a>

Ecco una panoramica di come CloudFront configuri i cookie firmati e di come CloudFront reagisce quando un utente invia una richiesta che contiene un cookie firmato. 

1. Nella tua CloudFront distribuzione, specifica uno o più gruppi di chiavi affidabili, che contengono le chiavi pubbliche che CloudFront possono essere utilizzate per verificare la firma dell'URL. Utilizzi le chiavi private corrispondenti per firmare il URLs.

   Per ulteriori informazioni, consulta [Specificate i firmatari che possono creare cookie firmati e firmati URLs](private-content-trusted-signers.md).

1. Sviluppa la tua applicazione per determinare se un utente deve avere accesso al tuo contenuto e, in caso affermativo, per inviare tre intestazioni `Set-Cookie` al visualizzatore (Ogni `Set-Cookie` intestazione può contenere solo una coppia nome-valore e un cookie CloudFront firmato richiede tre coppie nome-valore.) Devi inviare le intestazioni `Set-Cookie` al visualizzatore prima che il visualizzatore richieda il tuo contenuto privato. Se hai impostato un breve periodo di scadenza sul cookie, è possibile che tu intenda inviare tre ulteriori intestazioni `Set-Cookie` in risposta a richieste successive, in modo che l'utente continui ad avere accesso.

   In genere, la CloudFront distribuzione avrà almeno due comportamenti di cache, uno che non richiede l'autenticazione e uno che richiede l'autenticazione. La pagina di errore della parte protetta del sito include un redirector o un collegamento a una pagina di login.

   Se configuri la distribuzione per memorizzare nella cache i file basati sui cookie, CloudFront non memorizza nella cache file separati in base agli attributi dei cookie firmati.

1. Un utente accede al tuo sito Web e paga per il contenuto o soddisfa alcuni altri requisiti per l'accesso.

1. La tua applicazione restituisce le intestazioni `Set-Cookie` nella risposta e il visualizzatore archivia la coppia nome-valore.

1. L'utente richiede un file.

   Il browser dell'utente o un altro visualizzatore ottiene le coppie nome-valore della fase 4 e le aggiunge alla richiesta in un'intestazione `Cookie`. Questo è il cookie firmato.

1. CloudFront utilizza la chiave pubblica per convalidare la firma nel cookie firmato e per confermare che il cookie non è stato manomesso. Se la firma non è valida, la richiesta viene respinta.

   Se la firma nel cookie è valida, CloudFront esamina l'informativa contenuta nel cookie (o ne crea una se utilizzi una politica predefinita) per confermare che la richiesta è ancora valida. Ad esempio, se hai specificato una data e un'ora di inizio e di fine per il cookie, CloudFront conferma che l'utente sta tentando di accedere ai tuoi contenuti durante il periodo di tempo in cui desideri consentire l'accesso.

   Se la richiesta soddisfa i requisiti dell'informativa, CloudFront serve i contenuti come per i contenuti non soggetti a restrizioni: determina se il file è già presente nella cache edge, inoltra la richiesta all'origine se necessario e restituisce il file all'utente.

## Prevenzione contro l’uso improprio di cookie firmati
<a name="private-content-signed-cookie-misuse"></a>

Se specifichi il parametro `Domain` in un'intestazione `Set-Cookie`, specifica il valore più preciso possibile per ridurre l'accesso potenziale da parte di un utente con lo stesso nome di dominio radice. Ad esempio, ape.example.com è preferibile a example.com, soprattutto quando non controlli example.com. In questo modo, impedisci agli utenti di accedere al tuo contenuto a partire da www.example.com.

Per impedire questo tipo di attacco, procedi come segue:
+ Escludi gli attributi di cookie `Expires` e `Max-Age`, in modo che l'intestazione `Set-Cookie` crei un cookie di sessione. I cookie di sessione vengono eliminati automaticamente quando l'utente chiude il browser, cosa che riduce la possibilità che qualcuno ottenga accesso non autorizzato al tuo contenuto.
+ Includi l'attributo `Secure`, in modo che il cookie sia crittografato quando un visualizzatore lo include in una richiesta.
+ Quando possibile, utilizza una policy personalizzata e includi l'indirizzo IP del visualizzatore.
+ Nell'attributo `CloudFront-Expires`, specifica la scadenza ragionevole più corta basata sul periodo di tempo durante il quale intendi autorizzare gli utenti ad accedere al tuo contenuto.

## When CloudFront controlla la data e l'ora di scadenza in un cookie firmato
<a name="private-content-check-expiration-cookie"></a>

Per determinare se un cookie firmato è ancora valido, CloudFront controlla la data e l'ora di scadenza nel cookie al momento della richiesta HTTP. Se un client inizia a scaricare un file di grandi dimensioni immediatamente prima della scadenza, il download viene completato anche se la scadenza avviene durante il download. Se la connessione TCP viene interrotta e il client tenta di riavviare il download dopo la scadenza, il download non riesce.

Se un client utilizza Range GETs per ottenere un file in parti più piccole, qualsiasi richiesta GET che si verifica dopo la scadenza avrà esito negativo. Per ulteriori informazioni su Range GETs, vedere[Come CloudFront elabora le richieste parziali per un oggetto (intervallo GETs)](RangeGETs.md).

## Codice di esempio e strumenti di terza parte.
<a name="private-content-overview-sample-code-cookies"></a>

Il codice di esempio per i contenuti privati mostra solo come creare la firma per signed URLs. Tuttavia, il processo per la creazione di una firma per un cookie firmato è molto simile, di conseguenza una gran parte del codice di esempio è ancora rilevante. Per ulteriori informazioni, consultare i seguenti argomenti: 
+ [Creazione di una firma per URL utilizzando Perl](CreateURLPerl.md)
+ [Creazione di una firma per URL utilizzando PHP](CreateURL_PHP.md)
+ [Crea una firma per URL utilizzando C\$1 e .NET Framework](CreateSignatureInCSharp.md)
+ [Creazione di una firma per URL utilizzando Java](CFPrivateDistJavaDevelopment.md)

# Impostazione di cookie firmati mediante una policy di accesso predefinita
<a name="private-content-setting-signed-cookie-canned-policy"></a>

Per definire un cookie firmato utilizzando una policy predefinita, completa la procedura descritta di seguito. Per creare la firma, consulta [Creazione di una firma per un cookie firmato che utilizza una policy di accesso predefinita](#private-content-canned-policy-signature-cookies).<a name="private-content-setting-signed-cookie-canned-policy-procedure"></a>

**Definizione di un cookie firmato utilizzando una policy predefinita**

1. Se utilizzi .NET o Java per creare cookie firmati e non hai riformattato la chiave privata per la coppia di chiavi dal formato default .pem a un formato compatibile con .NET o Java, fallo adesso. Per ulteriori informazioni, consulta [Riformattazione della chiave privata (solo .NET e Java)](private-content-trusted-signers.md#private-content-reformatting-private-key).

1. Programma l'applicazione per inviare tre `Set-Cookie` header a utenti approvati (o quattro, se desideri specificare un algoritmo hash). Sono necessarie tre intestazioni `Set-Cookie` in quanto ogni intestazione `Set-Cookie` può contenere una sola coppia nome-valore e un cookie firmato di CloudFront richiede tre coppie nome-valore. Le coppie nome-valore sono: `CloudFront-Expires`, `CloudFront-Signature` e `CloudFront-Key-Pair-Id`. Facoltativamente, puoi includere una quarta coppia nome-valore per specificare l'algoritmo `CloudFront-Hash-Algorithm` hash utilizzato per la firma. I valori devono essere presenti sul visualizzatore prima che un utente effettui la prima richiesta per un file di cui intendi controllare l'accesso. 
**Nota**  
Come regola generale, ti consigliamo di escludere attributi `Expires` e `Max-Age`. In seguito all'esclusione degli attributi, il browser elimina il cookie quando l'utente chiude il browser e ciò riduce la possibilità che qualcuno ottenga accesso non autorizzato al tuo contenuto. Per ulteriori informazioni, consulta [Prevenzione contro l’uso improprio di cookie firmati](private-content-signed-cookies.md#private-content-signed-cookie-misuse).

   **I nomi degli attributi di cookie fanno distinzione tra maiuscole e minuscole**. 

   Le interruzioni di riga sono incluse solo per rendere gli attributi più leggibili.

   ```
   Set-Cookie: 
   CloudFront-Expires=date and time in Unix time format (in seconds) and Coordinated Universal Time (UTC); 
   Domain=optional domain name; 
   Path=/optional directory path; 
   Secure; 
   HttpOnly
   
   Set-Cookie: 
   CloudFront-Signature=hashed and signed version of the policy statement; 
   Domain=optional domain name; 
   Path=/optional directory path; 
   Secure; 
   HttpOnly
   
   Set-Cookie: 
   CloudFront-Key-Pair-Id=public key ID for the CloudFront public key whose corresponding private key you're using to generate the signature; 
   Domain=optional domain name; 
   Path=/optional directory path; 
   Secure; 
   HttpOnly
   
   Set-Cookie: 
   CloudFront-Hash-Algorithm=SHA1 or SHA256; 
   Domain=optional domain name; 
   Path=/optional directory path; 
   Secure; 
   HttpOnly
   ```  
**(Facoltativo) `Domain`**  
Il nome di dominio per il file richiesto. Se non specifichi un attributo `Domain`, il valore di default è il nome di dominio nell'URL e viene applicato solo al nome di dominio specificato, non ai sottodomini. Se specifichi un attributo `Domain`, è applicabile anche ai sottodomini. Un punto all'inizio del nome di dominio (ad esempio `Domain=.example.com`) è facoltativo. Inoltre, se specifichi un attributo `Domain`, il nome di dominio nell'URL e il valore dell'attributo `Domain` devono corrispondere.  
Puoi specificare il nome di dominio CloudFront assegnato alla tua distribuzione, ad esempio d111111abcdef8.cloudfront.net, ma non puoi specificare \$1.cloudfront.net per il nome di dominio.  
Se desideri utilizzare un nome di dominio alternativo come example.com in, devi aggiungere il nome di dominio alternativo alla tua distribuzione indipendentemente dal fatto che tu specifichi l'attributo. URLs `Domain` Per ulteriori informazioni, consulta [Nomi di dominio alternativi () CNAMEs](DownloadDistValuesGeneral.md#DownloadDistValuesCNAME) nell'argomento [Riferimento a tutte le impostazioni di distribuzione](distribution-web-values-specify.md).  
**(Facoltativo) `Path`**  
Il percorso per il file richiesto. Se non si specifichi un attributo `Path`, il valore di default è il percorso nell'URL.  
**`Secure`**  
Richiede al visualizzatore di crittografare i cookie prima dell'invio di una richiesta. Ti consigliamo di inviare l'`Set-Cookie`intestazione tramite una connessione HTTPS per assicurarti che gli attributi del cookie siano protetti dagli attacchi. man-in-the-middle  
**`HttpOnly`**  
Definisce in che modo il browser (ove supportato) interagisce con il valore del cookie. Con`HttpOnly`, i valori dei cookie sono inaccessibili a. JavaScript Questa precauzione può aiutare a mitigare gli attacchi di cross-site scripting (XSS). Per ulteriori informazioni, consulta [Utilizzo di cookie HTTP](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies).  
**`CloudFront-Expires`**  
Specifica la data e l'ora di scadenza in formato Unix (in secondi) e UTC. Ad esempio, le 10:00 UTC del 1° gennaio 2026 vengono convertite in 1767290400 nel formato orario Unix.   
Per usare il tempo epoch, specifica un numero intero a 64 bit per una data non posteriore a `9223372036854775807` (venerdì 11 aprile 2262 alle 23:47:16.854 UTC).  
Per informazioni sul formato UTC, consulta *RFC 3339, Date and Time on the Internet: Timestamps*, [https://tools.ietf.org/html/rfc3339](https://tools.ietf.org/html/rfc3339).  
**`CloudFront-Signature`**  
Una versione con hash, firma e codifica base64 di una dichiarazione di policy JSON. Per ulteriori informazioni, consulta [Creazione di una firma per un cookie firmato che utilizza una policy di accesso predefinita](#private-content-canned-policy-signature-cookies).  
**`CloudFront-Key-Pair-Id`**  
L'ID di una chiave pubblica, ad esempio,. CloudFront `K2JCJMDEHXQW5F` L'ID della chiave pubblica indica CloudFront quale chiave pubblica utilizzare per convalidare l'URL firmato. CloudFront confronta le informazioni contenute nella firma con quelle contenute nell'informativa per verificare che l'URL non sia stato manomesso.  
Questa chiave pubblica deve appartenere a un gruppo di chiavi che sia un firmatario attendibile nella distribuzione. Per ulteriori informazioni, consulta [Specificate i firmatari che possono creare cookie firmati e firmati URLs](private-content-trusted-signers.md).  
**`CloudFront-Hash-Algorithm`**  
(Facoltativo) L'algoritmo hash utilizzato per creare la firma. I valori supportati sono `SHA1` e `SHA256`. Se non includi questo cookie, l'CloudFront impostazione predefinita è. `SHA1`

L'esempio seguente mostra le `Set-Cookie` intestazioni per un cookie firmato quando utilizzi il nome di dominio associato alla distribuzione in URLs for your files:

```
Set-Cookie: CloudFront-Expires=1426500000; Domain=d111111abcdef8.cloudfront.net; Path=/images/*; Secure; HttpOnly
Set-Cookie: CloudFront-Signature=yXrSIgyQoeE4FBI4eMKF6ho~CA8_; Domain=d111111abcdef8.cloudfront.net; Path=/images/*; Secure; HttpOnly
Set-Cookie: CloudFront-Key-Pair-Id=K2JCJMDEHXQW5F; Domain=d111111abcdef8.cloudfront.net; Path=/images/*; Secure; HttpOnly
Set-Cookie: CloudFront-Hash-Algorithm=SHA256; Domain=d111111abcdef8.cloudfront.net; Path=/images/*; Secure; HttpOnly
```

L'esempio seguente mostra le `Set-Cookie` intestazioni per un cookie firmato quando utilizzi il nome di dominio alternativo example.org nella cartella per i tuoi file: URLs 

```
Set-Cookie: CloudFront-Expires=1426500000; Domain=example.org; Path=/images/*; Secure; HttpOnly
Set-Cookie: CloudFront-Signature=yXrSIgyQoeE4FBI4eMKF6ho~CA8_; Domain=example.org; Path=/images/*; Secure; HttpOnly
Set-Cookie: CloudFront-Key-Pair-Id=K2JCJMDEHXQW5F; Domain=example.org; Path=/images/*; Secure; HttpOnly
Set-Cookie: CloudFront-Hash-Algorithm=SHA256; Domain=example.org; Path=/images/*; Secure; HttpOnly
```

Se desideri utilizzare un nome di dominio alternativo come example.com in URLs, devi aggiungere il nome di dominio alternativo alla tua distribuzione indipendentemente dal fatto che tu specifichi l'attributo. `Domain` Per ulteriori informazioni, consulta [Nomi di dominio alternativi () CNAMEs](DownloadDistValuesGeneral.md#DownloadDistValuesCNAME) nell'argomento [Riferimento a tutte le impostazioni di distribuzione](distribution-web-values-specify.md).

## Creazione di una firma per un cookie firmato che utilizza una policy di accesso predefinita
<a name="private-content-canned-policy-signature-cookies"></a>

Per creare la firma per un cookie firmato che utilizza una policy di accesso predefinita, completa le seguenti procedure.

**Topics**
+ [

### Creazione di una dichiarazione di policy per un cookie firmato che utilizza una policy di accesso predefinita
](#private-content-canned-policy-statement-cookies)
+ [

### Firma di una dichiarazione di policy per creare una firma per un cookie firmato che utilizza una policy di accesso predefinita
](#private-content-canned-policy-cookies-signing-policy-statement)

### Creazione di una dichiarazione di policy per un cookie firmato che utilizza una policy di accesso predefinita
<a name="private-content-canned-policy-statement-cookies"></a>

Quando definisci un cookie firmato che utilizza una policy predefinita, l'attributo `CloudFront-Signature` è una versione con hash e firma di una dichiarazione di policy. Per i cookie firmati che utilizzano una policy predefinita, non includi la dichiarazione di policy nell'intestazione `Set-Cookie`, come avviene per i cookie firmati che utilizzano una policy personalizzata. Per creare una dichiarazione di policy, esegui la procedura descritta di seguito.<a name="private-content-canned-policy-statement-cookies-procedure"></a>

**Creazione di una dichiarazione di policy per un cookie firmato che utilizza una policy predefinita**

1. Crea la dichiarazione di policy utilizzando il formato JSON seguente e la codifica caratteri UTF-8. Includi tutta le punteggiatura e altri valori letterali esattamente come specificato. Per informazioni sui parametri `Resource` e `DateLessThan`, consulta [Valori da specificare in una dichiarazione di policy per cookie firmati che utilizzano una policy predefinita](#private-content-canned-policy-statement-cookies-values).

   ```
   {
       "Statement": [
           {
               "Resource": "base URL or stream name",
               "Condition": {
                   "DateLessThan": {
                       "AWS:EpochTime": ending date and time in Unix time format and UTC
                   }
               }
           }
       ]
   }
   ```

1. Rimuovi tutti gli spazi vuoti (inclusi i caratteri di nuova riga e le tabulazioni) dalla dichiarazione di policy. È possibile che tu debba includere caratteri di escape nella stringa del codice dell'applicazione.

#### Valori da specificare in una dichiarazione di policy per cookie firmati che utilizzano una policy predefinita
<a name="private-content-canned-policy-statement-cookies-values"></a>

Quando crei una dichiarazione di policy per una policy predefinita, specifichi i valori seguenti:

**Risorsa**  
L'URL di base che include le eventuali stringhe di query, ad esempio:  
`https://d111111abcdef8.cloudfront.net/images/horizon.jpg?size=large&license=yes`  
Puoi specificare un solo valore per `Resource`.  
Tieni presente quanto segue:  
+ **Protocollo**: il valore deve iniziare con `http://` o `https://`.
+ **Parametri di stringa di query**: se non hai parametri di stringa di query, ometti il punto di domanda.
+ **Nomi di dominio alternativi**: se specifichi un nome di dominio alternativo (CNAME) nell'URL, devi specificarlo quando fai riferimento al file nella pagina Web o nell'applicazione. Non specificare l'URL Amazon S3 per il file.

**DateLessThan**  
La data e l'ora di scadenza per l'URL in formato Unix (in secondi) e UTC. Non racchiudere il valore tra virgolette.  
Ad esempio, 16 marzo 2015 10:00 UTC viene convertito in 1426500000 nel formato Unix.  
Questo valore deve corrispondere al valore dell'attributo `CloudFront-Expires` nell'intestazione `Set-Cookie`. Non racchiudere il valore tra virgolette.  
Per ulteriori informazioni, consulta [When CloudFront controlla la data e l'ora di scadenza in un cookie firmato](private-content-signed-cookies.md#private-content-check-expiration-cookie).

#### Esempio di dichiarazione di policy per una policy predefinita
<a name="private-content-canned-policy-cookies-sample-policy-statement"></a>

Quando utilizzi l'esempio di dichiarazione di policy seguente in un cookie firmato, un utente può accedere al file `https://d111111abcdef8.cloudfront.net/horizon.jpg` fino al 16 marzo 2015 10:00 UTC:

```
{
    "Statement": [
        {
            "Resource": "https://d111111abcdef8.cloudfront.net/horizon.jpg?size=large&license=yes",
            "Condition": {
                "DateLessThan": {
                    "AWS:EpochTime": 1426500000
                }
            }
        }
    ]
}
```

### Firma di una dichiarazione di policy per creare una firma per un cookie firmato che utilizza una policy di accesso predefinita
<a name="private-content-canned-policy-cookies-signing-policy-statement"></a>

Per creare il valore per l'attributo `CloudFront-Signature` in un'intestazione `Set-Cookie`, sottoponi a hashing e firmi la dichiarazione di policy che hai creato in [Creazione di una dichiarazione di policy per un cookie firmato che utilizza una policy predefinita](#private-content-canned-policy-statement-cookies-procedure). 

Per ulteriori informazioni ed esempi su come sottoporre a hashing, firmare e codificare la dichiarazione di policy, consulta i seguenti argomenti:
+ [Comandi Linux e OpenSSL per la crittografia e la codifica base64](private-content-linux-openssl.md)
+ [Codice di esempio per la creazione di una firma per un URL firmato](PrivateCFSignatureCodeAndExamples.md)

**Nota**  
Gli esempi collegati utilizzano SHA-1 per impostazione predefinita. Per utilizzare invece SHA-256, sostituiscilo `sha1` con `sha256` nei comandi OpenSSL e includi il cookie con il `CloudFront-Hash-Algorithm` valore di. `SHA256`<a name="private-content-canned-policy-cookie-creating-signature-procedure"></a>

**Creazione di una firma per un cookie firmato che utilizza una policy predefinita**

1. Utilizzate la funzione hash SHA-1 o SHA-256 e RSA per eseguire l'hash e firmare la dichiarazione politica creata durante la procedura. [Creazione di una dichiarazione di policy per un cookie firmato che utilizza una policy predefinita](#private-content-canned-policy-statement-cookies-procedure) Utilizza la versione della dichiarazione di policy che non include più spazi vuoti.

   Se si utilizza SHA-256, è necessario includere il cookie con un valore di. `CloudFront-Hash-Algorithm` `SHA256`

   Per la chiave privata richiesta dalla funzione hash, utilizza una chiave privata la cui chiave pubblica si trova in un gruppo di chiavi attendibili attivo per la distribuzione.
**Nota**  
Il metodo utilizzato per sottoporre a hashing e firmare la dichiarazione di policy dipende dalla piattaforma e dal linguaggio di programmazione. Per il codice di esempio, consulta [Codice di esempio per la creazione di una firma per un URL firmato](PrivateCFSignatureCodeAndExamples.md).

1. Rimuovi gli spazi vuoti (inclusi i caratteri di nuova riga e le tabulazioni) dalla stringa con hash e firmata.

1. Codifica la stringa utilizzando la codifica base64 MIME. Per ulteriori informazioni, vedere [Sezione 6.8, Base64 Content-Transfer-Encoding in RFC 2045,](https://tools.ietf.org/html/rfc2045#section-6.8) *MIME (Multipurpose Internet Mail Extensions), parte prima: Formato dei corpi dei messaggi Internet*.

1. Sostituisci i caratteri non validi nella stringa di query dell'URL con caratteri validi. La tabella seguente elenca i caratteri validi e non validi.  
****    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonCloudFront/latest/DeveloperGuide/private-content-setting-signed-cookie-canned-policy.html)

1. Includi il valore risultante nell'intestazione `Set-Cookie` per la coppia nome-valore `CloudFront-Signature`. Quindi ritorna a [Definizione di un cookie firmato utilizzando una policy predefinita](#private-content-setting-signed-cookie-canned-policy-procedure) e aggiungi l'intestazione `Set-Cookie` per `CloudFront-Key-Pair-Id`.

# Impostazione di cookie firmati che utilizzano una policy personalizzata
<a name="private-content-setting-signed-cookie-custom-policy"></a>

Per definire un cookie firmato che utilizza una policy personalizzata, procedi come indicato di seguito.<a name="private-content-setting-signed-cookie-custom-policy-procedure"></a>

**Impostazione di un cookie firmato che utilizza una policy personalizzata**

1. Se stai usando .NET o Java per creare un file firmato URLs e se non hai riformattato la chiave privata per la tua coppia di chiavi dal formato.pem predefinito a un formato compatibile con.NET o con Java, fallo ora. Per ulteriori informazioni, consulta [Riformattazione della chiave privata (solo .NET e Java)](private-content-trusted-signers.md#private-content-reformatting-private-key).

1. Programma l'applicazione per inviare tre `Set-Cookie` intestazioni ai visualizzatori approvati (o quattro, se desideri specificare un algoritmo hash). Sono necessarie tre `Set-Cookie` intestazioni perché ogni `Set-Cookie` intestazione può contenere solo una coppia nome-valore e un CloudFront cookie firmato richiede tre coppie nome-valore. Le coppie nome-valore sono: `CloudFront-Policy`, `CloudFront-Signature` e `CloudFront-Key-Pair-Id`. Facoltativamente, puoi includere una quarta coppia nome-valore per specificare l'algoritmo hash utilizzato per `CloudFront-Hash-Algorithm` la firma. I valori devono essere presenti sul visualizzatore prima che un utente effettui la prima richiesta per un file di cui intendi controllare l'accesso. 
**Nota**  
Come regola generale, ti consigliamo di escludere attributi `Expires` e `Max-Age`. Ciò comporta l'eliminazione del cookie da parte del browser quando l'utente chiude il browser, cosa che riduce la possibilità che qualcuno ottenga accesso non autorizzato al tuo contenuto. Per ulteriori informazioni, consulta [Prevenzione contro l’uso improprio di cookie firmati](private-content-signed-cookies.md#private-content-signed-cookie-misuse).

   **I nomi degli attributi di cookie fanno distinzione tra maiuscole e minuscole**. 

   Le interruzioni di riga sono incluse solo per rendere gli attributi più leggibili.

   ```
   Set-Cookie: 
   CloudFront-Policy=base64 encoded version of the policy statement; 
   Domain=optional domain name; 
   Path=/optional directory path; 
   Secure; 
   HttpOnly
   
   
   Set-Cookie: 
   CloudFront-Signature=hashed and signed version of the policy statement; 
   Domain=optional domain name; 
   Path=/optional directory path; 
   Secure; 
   HttpOnly
   
   Set-Cookie: 
   CloudFront-Key-Pair-Id=public key ID for the CloudFront public key whose corresponding private key you're using to generate the signature; 
   Domain=optional domain name; 
   Path=/optional directory path; 
   Secure; 
   HttpOnly
   
   Set-Cookie: 
   CloudFront-Hash-Algorithm=SHA1 or SHA256; 
   Domain=optional domain name; 
   Path=/optional directory path; 
   Secure; 
   HttpOnly
   ```  
**(Facoltativo) `Domain`**  
Il nome di dominio per il file richiesto. Se non specifichi un attributo `Domain`, il valore di default è il nome di dominio nell'URL e viene applicato solo al nome di dominio specificato, non ai sottodomini. Se specifichi un attributo `Domain`, è applicabile anche ai sottodomini. Un punto all'inizio del nome di dominio (ad esempio `Domain=.example.com`) è facoltativo. Inoltre, se specifichi un attributo `Domain`, il nome di dominio nell'URL e il valore dell'attributo `Domain` devono corrispondere.  
Puoi specificare il nome di dominio CloudFront assegnato alla tua distribuzione, ad esempio d111111abcdef8.cloudfront.net, ma non puoi specificare \$1.cloudfront.net per il nome di dominio.  
Se desideri utilizzare un nome di dominio alternativo come example.com in, devi aggiungere il nome di dominio alternativo alla tua distribuzione indipendentemente dal fatto che tu specifichi l'attributo. URLs `Domain` Per ulteriori informazioni, consulta [Nomi di dominio alternativi () CNAMEs](DownloadDistValuesGeneral.md#DownloadDistValuesCNAME) nell'argomento [Riferimento a tutte le impostazioni di distribuzione](distribution-web-values-specify.md).  
**(Facoltativo) `Path`**  
Il percorso per il file richiesto. Se non si specifichi un attributo `Path`, il valore di default è il percorso nell'URL.  
**`Secure`**  
Richiede al visualizzatore di crittografare i cookie prima dell'invio di una richiesta. Ti consigliamo di inviare l'`Set-Cookie`intestazione tramite una connessione HTTPS per assicurarti che gli attributi del cookie siano protetti dagli attacchi. man-in-the-middle  
**`HttpOnly`**  
Richiede al visualizzatore di inviare il cookie solo nelle richieste HTTP o HTTPS.  
**`CloudFront-Policy`**  
La dichiarazione di policy in formato JSON, con spazi vuoti rimossi e codifica base64. Per ulteriori informazioni, consulta [Creazione di una firma per un cookie firmato che utilizza una policy personalizzata](#private-content-custom-policy-signature-cookies).  
La dichiarazione di policy controlla l'accesso che un cookie firmato concede a un utente. Include i file a cui l'utente può accedere, una data e un'ora di scadenza, una data e un'ora facoltative in cui l'URL diventa valido e un indirizzo IP facoltativo o un intervallo di indirizzi IP a cui è consentito accedere al file.  
**`CloudFront-Signature`**  
Una versione con hash, firma e codifica base64 della dichiarazione di policy JSON. Per ulteriori informazioni, consulta [Creazione di una firma per un cookie firmato che utilizza una policy personalizzata](#private-content-custom-policy-signature-cookies).  
**`CloudFront-Key-Pair-Id`**  
L'ID di una chiave CloudFront pubblica, ad esempio,`K2JCJMDEHXQW5F`. L'ID della chiave pubblica indica CloudFront quale chiave pubblica utilizzare per convalidare l'URL firmato. CloudFrontconfronta le informazioni contenute nella firma con quelle contenute nell'informativa per verificare che l'URL non sia stato manomesso.  
Questa chiave pubblica deve appartenere a un gruppo di chiavi che sia un firmatario attendibile nella distribuzione. Per ulteriori informazioni, consulta [Specificate i firmatari che possono creare cookie firmati e firmati URLs](private-content-trusted-signers.md).  
**`CloudFront-Hash-Algorithm`**  
(Facoltativo) L'algoritmo hash utilizzato per creare la firma. I valori supportati sono `SHA1` e `SHA256`. Se non includi questo cookie, l'CloudFront impostazione predefinita è. `SHA1`

## Intestazioni `Set-Cookie` di esempio per policy personalizzate
<a name="example-set-cookie-headers-custom-policy"></a>

Vedi i seguenti esempi di coppie di intestazioni `Set-Cookie`. 

Se desideri utilizzare un nome di dominio alternativo come example.org in URLs, devi aggiungere il nome di dominio alternativo alla tua distribuzione indipendentemente dal fatto che tu specifichi l'attributo. `Domain` Per ulteriori informazioni, consulta [Nomi di dominio alternativi () CNAMEs](DownloadDistValuesGeneral.md#DownloadDistValuesCNAME) nell'argomento [Riferimento a tutte le impostazioni di distribuzione](distribution-web-values-specify.md).

**Example Esempio 1**  
Puoi utilizzare le `Set-Cookie` intestazioni per un cookie firmato quando utilizzi il nome di dominio associato alla tua distribuzione in for your files. URLs   

```
Set-Cookie: CloudFront-Policy=eyJTdGF0ZW1lbnQiOlt7IlJlc291cmNlIjoiaHR0cDovL2QxMTExMTFhYmNkZWY4LmNsb3VkZnJvbnQubmV0L2dhbWVfZG93bmxvYWQuemlwIiwiQ29uZGl0aW9uIjp7IklwQWRkcmVzcyI6eyJBV1M6U291cmNlSXAiOiIxOTIuMC4yLjAvMjQifSwiRGF0ZUxlc3NUaGFuIjp7IkFXUzpFcG9jaFRpbWUiOjE0MjY1MDAwMDB9fX1dfQ__; Domain=d111111abcdef8.cloudfront.net; Path=/; Secure; HttpOnly
Set-Cookie: CloudFront-Signature=dtKhpJ3aUYxqDIwepczPiDb9NXQ_; Domain=d111111abcdef8.cloudfront.net; Path=/; Secure; HttpOnly
Set-Cookie: CloudFront-Key-Pair-Id=K2JCJMDEHXQW5F; Domain=d111111abcdef8.cloudfront.net; Path=/; Secure; HttpOnly
Set-Cookie: CloudFront-Hash-Algorithm=SHA256; Domain=d111111abcdef8.cloudfront.net; Path=/; Secure; HttpOnly
```

**Example Esempio 2**  
Puoi utilizzare le `Set-Cookie` intestazioni per un cookie firmato quando utilizzi un nome di dominio alternativo (example.org) nella cartella per i tuoi file. URLs   

```
Set-Cookie: CloudFront-Policy=eyJTdGF0ZW1lbnQiOlt7IlJlc291cmNlIjoiaHR0cDovL2QxMTExMTFhYmNkZWY4LmNsb3VkZnJvbnQubmV0L2dhbWVfZG93bmxvYWQuemlwIiwiQ29uZGl0aW9uIjp7IklwQWRkcmVzcyI6eyJBV1M6U291cmNlSXAiOiIxOTIuMC4yLjAvMjQifSwiRGF0ZUxlc3NUaGFuIjp7IkFXUzpFcG9jaFRpbWUiOjE0MjY1MDAwMDB9fX1dfQ__; Domain=example.org; Path=/; Secure; HttpOnly
Set-Cookie: CloudFront-Signature=dtKhpJ3aUYxqDIwepczPiDb9NXQ_; Domain=example.org; Path=/; Secure; HttpOnly
Set-Cookie: CloudFront-Key-Pair-Id=K2JCJMDEHXQW5F; Domain=example.org; Path=/; Secure; HttpOnly
Set-Cookie: CloudFront-Hash-Algorithm=SHA256; Domain=example.org; Path=/; Secure; HttpOnly
```

**Example Esempio 3**  
Puoi utilizzare le coppie di `Set-Cookie` intestazioni per una richiesta firmata quando utilizzi il nome di dominio associato alla tua distribuzione in for your files. URLs   

```
Set-Cookie: CloudFront-Policy=eyJTdGF0ZW1lbnQiOlt7IlJlc291cmNlIjoiaHR0cDovL2QxMTExMTFhYmNkZWY4LmNsb3VkZnJvbnQubmV0L2dhbWVfZG93bmxvYWQuemlwIiwiQ29uZGl0aW9uIjp7IklwQWRkcmVzcyI6eyJBV1M6U291cmNlSXAiOiIxOTIuMC4yLjAvMjQifSwiRGF0ZUxlc3NUaGFuIjp7IkFXUzpFcG9jaFRpbWUiOjE0MjY1MDAwMDB9fX1dfQ__; Domain=d111111abcdef8.cloudfront.net; Path=/; Secure; HttpOnly
Set-Cookie: CloudFront-Signature=dtKhpJ3aUYxqDIwepczPiDb9NXQ_; Domain=d111111abcdef8.cloudfront.net; Path=/; Secure; HttpOnly
Set-Cookie: CloudFront-Key-Pair-Id=K2JCJMDEHXQW5F; Domain=dd111111abcdef8.cloudfront.net; Path=/; Secure; HttpOnly
Set-Cookie: CloudFront-Hash-Algorithm=SHA256; Domain=d111111abcdef8.cloudfront.net; Path=/; Secure; HttpOnly
```

**Example Esempio 4**  
Puoi utilizzare le coppie di `Set-Cookie` intestazioni per una richiesta firmata quando utilizzi un nome di dominio alternativo (example.org) associato alla tua distribuzione nella sezione per i tuoi file. URLs   

```
Set-Cookie: CloudFront-Policy=eyJTdGF0ZW1lbnQiOlt7IlJlc291cmNlIjoiaHR0cDovL2QxMTExMTFhYmNkZWY4LmNsb3VkZnJvbnQubmV0L2dhbWVfZG93bmxvYWQuemlwIiwiQ29uZGl0aW9uIjp7IklwQWRkcmVzcyI6eyJBV1M6U291cmNlSXAiOiIxOTIuMC4yLjAvMjQifSwiRGF0ZUxlc3NUaGFuIjp7IkFXUzpFcG9jaFRpbWUiOjE0MjY1MDAwMDB9fX1dfQ__; Domain=example.org; Path=/; Secure; HttpOnly
Set-Cookie: CloudFront-Signature=dtKhpJ3aUYxqDIwepczPiDb9NXQ_; Domain=example.org; Path=/; Secure; HttpOnly
Set-Cookie: CloudFront-Key-Pair-Id=K2JCJMDEHXQW5F; Domain=example.org; Path=/; Secure; HttpOnly
Set-Cookie: CloudFront-Hash-Algorithm=SHA256; Domain=example.org; Path=/; Secure; HttpOnly
```

## Creazione di una dichiarazione di policy per un cookie firmato che utilizza una policy personalizzata
<a name="private-content-custom-policy-statement-cookies"></a>

Per creare una dichiarazione di policy per una policy personalizzata, completa i seguenti passaggi. Per vari esempi di dichiarazioni di policy che controllano l'accesso a file in vari modi, consulta [Esempi di dichiarazioni di policy per un cookie firmato che utilizza una policy personalizzata](#private-content-custom-policy-statement-signed-cookies-examples).<a name="private-content-custom-policy-statement-cookies-procedure"></a>

**Creazione di una dichiarazione di policy per un cookie firmato che utilizza una policy personalizzata**

1. Crea la dichiarazione di policy utilizzando il formato JSON seguente.

   ```
   {
       "Statement": [
           {
               "Resource": "URL of the file",
               "Condition": {
                   "DateLessThan": {
                       "AWS:EpochTime":required ending date and time in Unix time format and UTC
                   },
                   "DateGreaterThan": {
                       "AWS:EpochTime":optional beginning date and time in Unix time format and UTC
                   },
                   "IpAddress": {
                       "AWS:SourceIp": "optional IP address"
                   }
               }
           }
       ]
   }
   ```

   Tieni presente quanto segue:
   + Puoi includere solo una dichiarazione.
   + Utilizza la codifica caratteri UTF-8.
   + Includi tutta le punteggiatura e nomi di parametro esattamente come specificato. Le abbreviazioni per i nomi di parametro non sono accettate.
   + L'ordine dei parametri nella sezione `Condition` non è rilevante.
   + Per informazioni sui valori per `Resource`, `DateLessThan`, `DateGreaterThan` e `IpAddress`, consulta [Valori da specificare in una dichiarazione di policy per cookie firmati che utilizzano una policy personalizzata](#private-content-custom-policy-statement-cookies-values).

1. Rimuovi tutti gli spazi vuoti (inclusi i caratteri di nuova riga e le tabulazioni) dalla dichiarazione di policy. È possibile che tu debba includere caratteri di escape nella stringa del codice dell'applicazione.

1. Codifica la dichiarazione di policy utilizzando la codifica base64 MIME. Per ulteriori informazioni, vedere [Sezione 6.8, Base64 Content-Transfer-Encoding in RFC 2045,](https://tools.ietf.org/html/rfc2045#section-6.8) *MIME (Multipurpose Internet Mail Extensions),* parte prima: Formato dei corpi dei messaggi Internet.

1. Sostituisci i caratteri non validi nella stringa di query dell'URL con caratteri validi. La tabella seguente elenca i caratteri validi e non validi.  
****    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonCloudFront/latest/DeveloperGuide/private-content-setting-signed-cookie-custom-policy.html)

1. Includi il valore risultante nella tua intestazione `Set-Cookie` dopo `CloudFront-Policy=`.

1. Crea una firma per l'intestazione `Set-Cookie` per `CloudFront-Signature` sottoponendo a hashing, firmando e codificando in base64 la dichiarazione di policy. Per ulteriori informazioni, consulta [Creazione di una firma per un cookie firmato che utilizza una policy personalizzata](#private-content-custom-policy-signature-cookies).

### Valori da specificare in una dichiarazione di policy per cookie firmati che utilizzano una policy personalizzata
<a name="private-content-custom-policy-statement-cookies-values"></a>

Quando crei una dichiarazione di policy per una policy personalizzata, specifichi i valori seguenti.

**Risorsa**  
L'URL di base che include le eventuali stringhe di query:  
`https://d111111abcdef8.cloudfront.net/images/horizon.jpg?size=large&license=yes`  
Se ometti il parametro `Resource`, gli utenti possono accedere a tutti i file associati a qualsiasi distribuzione associata alla coppia di chiavi che utilizzi per creare l'URL firmato.
Puoi specificare un solo valore per `Resource`.  
Tieni presente quanto segue:  
+ **Protocollo**: il valore deve iniziare con `http://` o `https://`.
+ **Parametri di stringa di query**: se non hai parametri di stringa di query, ometti il punto di domanda.
+ **Caratteri jolly**: puoi utilizzare il carattere jolly che corrisponde a zero o più caratteri (\$1) o il carattere jolly che corrisponde esattamente a un carattere (?) in qualsiasi punto della stringa. Ad esempio, il valore:

  `https://d111111abcdef8.cloudfront.net/*game_download.zip*`

  includerebbe (ad esempio) i seguenti file:
  + `https://d111111abcdef8.cloudfront.net/game_download.zip`
  + `https://d111111abcdef8.cloudfront.net/example_game_download.zip?license=yes`
  + `https://d111111abcdef8.cloudfront.net/test_game_download.zip?license=temp`
+ **Nomi di dominio alternativi**: se specifichi un nome di dominio alternativo (CNAME) nell'URL, devi specificarlo quando fai riferimento al file nella pagina Web o nell'applicazione. Non specificare l'URL Amazon S3 per il file.

**DateLessThan**  
La data e l'ora di scadenza per l'URL in formato Unix (in secondi) e UTC. Non racchiudere il valore tra virgolette.  
Ad esempio, 16 marzo 2015 10:00 UTC viene convertito in 1426500000 nel formato Unix.  
Per ulteriori informazioni, consulta [When CloudFront controlla la data e l'ora di scadenza in un cookie firmato](private-content-signed-cookies.md#private-content-check-expiration-cookie).

**DateGreaterThan (Facoltativo)**  
Una data e un'ora di inizio (facoltative) per l'URL in formato Unix (in secondi) e UTC. Agli utenti non è consentito accedere al file prima o in corrispondenza della data e ora specificate. Non racchiudere il valore tra virgolette. 

**IpAddress (Opzionale)**  
L'indirizzo IP del client che esegue la richiesta GET. Tieni presente quanto segue:  
+ Per consentire a qualsiasi indirizzo IP di accedere al file, ometti il parametro `IpAddress`.
+ Puoi specificare un indirizzo IP o un intervallo di indirizzi IP. Ad esempio, non puoi definire la policy per consentire l'accesso se l'indirizzo IP del client è in uno dei due intervalli distinti.
+ Per consentire l'accesso da un singolo indirizzo IP, specifica:

  `"`*IPv4 IP address*`/32"`
+ È necessario specificare gli intervalli di indirizzi IP nel formato IPv4 CIDR standard (ad esempio,`192.0.2.0/24`). Per ulteriori informazioni, consulta *RFC 4632, Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan*, [https://tools.ietf.org/html/rfc4632](https://tools.ietf.org/html/rfc4632).
**Importante**  
Gli indirizzi IP in IPv6 formato, ad esempio 2001:0 db 8:85 a3: :8a2e: 0370:7334, non sono supportati. 

  Se utilizzi una politica personalizzata che include, non abilitarla per la distribuzione. `IpAddress` IPv6 Se desideri limitare l'accesso ad alcuni contenuti in base all'indirizzo IP e IPv6 alle richieste di supporto per altri contenuti, puoi creare due distribuzioni. Per ulteriori informazioni, consulta [Abilita IPv6 (richieste del visualizzatore)](DownloadDistValuesGeneral.md#DownloadDistValuesEnableIPv6) nell'argomento [Riferimento a tutte le impostazioni di distribuzione](distribution-web-values-specify.md).

## Esempi di dichiarazioni di policy per un cookie firmato che utilizza una policy personalizzata
<a name="private-content-custom-policy-statement-signed-cookies-examples"></a>

Gli esempi di dichiarazioni di policy seguenti mostrano il modo in cui controllare l'accesso a un determinato file, a tutti i file in una directory o a tutti i file associati a un ID di coppia di chiavi. Gli esempi mostrano inoltre come controllare l'accesso da un singolo indirizzo IP o da un intervallo di indirizzi IP e come impedire agli utenti di utilizzare il cookie firmato dopo una data e un'ora specificate.

Se copi e incolli uno di questi esempi, devi rimuovere gli eventuali spazi vuoti (inclusi i caratteri di nuova riga e le tabulazioni), sostituire i valori con i tuoi valori e includere un carattere di nuova riga dopo la parentesi graffa di chiusura ( \$1 ).

Per ulteriori informazioni, consulta [Valori da specificare in una dichiarazione di policy per cookie firmati che utilizzano una policy personalizzata](#private-content-custom-policy-statement-cookies-values).

**Topics**
+ [

### Esempio di dichiarazione di policy: accesso a un file da un intervallo di indirizzi IP
](#private-content-custom-policy-statement-signed-cookies-example-one-object)
+ [

### Esempio di dichiarazione di policy: accesso a tutti i file in una directory da un intervallo di indirizzi IP
](#private-content-custom-policy-statement-signed-cookies-example-all-objects)
+ [

### Esempio di dichiarazione di policy: accesso a tutti i file associati a un ID di coppia di chiavi da un indirizzo IP
](#private-content-custom-policy-statement-signed-cookies-example-one-ip)

### Esempio di dichiarazione di policy: accesso a un file da un intervallo di indirizzi IP
<a name="private-content-custom-policy-statement-signed-cookies-example-one-object"></a>

L'esempio seguente di policy personalizzata in un cookie firmato specifica che un utente può accedere al file `https://d111111abcdef8.cloudfront.net/game_download.zip` dagli indirizzi IP nell'intervallo `192.0.2.0/24` fino al 1° gennaio 2013 10:00 UTC:

```
{
    "Statement": [
        {
            "Resource": "https://d111111abcdef8.cloudfront.net/game_download.zip",
            "Condition": {
                "IpAddress": {
                    "AWS:SourceIp": "192.0.2.0/24"
                },
                "DateLessThan": {
                    "AWS:EpochTime": 1767290400
                }
            }
        }
    ]
}
```

### Esempio di dichiarazione di policy: accesso a tutti i file in una directory da un intervallo di indirizzi IP
<a name="private-content-custom-policy-statement-signed-cookies-example-all-objects"></a>

L'esempio di policy personalizzata seguente consente di creare cookie firmati per qualsiasi file nella directory `training`, come indicato dal carattere jolly \$1 nel parametro `Resource`. Gli utenti possono accedere al file da un indirizzo IP incluso nell'intervallo `192.0.2.0/24` fino al 1° gennaio 2013 10:00 UTC:

```
{
    "Statement": [
        {
            "Resource": "https://d111111abcdef8.cloudfront.net/training/*",
            "Condition": {
                "IpAddress": {
                    "AWS:SourceIp": "192.0.2.0/24"
                },
                "DateLessThan": {
                    "AWS:EpochTime": 1767290400
                }
            }
        }
    ]
}
```

Ogni cookie firmato in cui utilizzi questa policy include un URL di base che identifica un file specifico, ad esempio:

`https://d111111abcdef8.cloudfront.net/training/orientation.pdf`

### Esempio di dichiarazione di policy: accesso a tutti i file associati a un ID di coppia di chiavi da un indirizzo IP
<a name="private-content-custom-policy-statement-signed-cookies-example-one-ip"></a>

L'esempio di policy personalizzata seguente ti consente di definire cookie firmati per qualsiasi file associato a qualsiasi distribuzione, come indicato dal carattere jolly \$1 nel parametro `Resource`. L'utente deve utilizzare l'indirizzo I `192.0.2.10/32`. (il valore `192.0.2.10/32` nella notazione CIDR fa riferimento a un singolo indirizzo IP, `192.0.2.10`). I file sono disponibili solo dal 1° gennaio 2013 10:00 UTC fino al 2 gennaio 2013 10:00 UTC:

```
{
    "Statement": [
        {
            "Resource": "https://*",
            "Condition": {
                "IpAddress": {
                    "AWS:SourceIp": "192.0.2.10/32"
                },
                "DateGreaterThan": {
                    "AWS:EpochTime": 1767290400
                },
                "DateLessThan": {
                    "AWS:EpochTime": 1767376800
                }
            }
        }
    ]
}
```

Ogni cookie firmato in cui si utilizza questa politica include un URL di base che identifica un file specifico in una CloudFront distribuzione specifica, ad esempio:

`https://d111111abcdef8.cloudfront.net/training/orientation.pdf`

Il cookie firmato include inoltre un ID di coppia di chiavi, che deve essere associato a un firmatario attendibile nella distribuzione (d111111abcdef8.cloudfront.net) specificato nell'URL di base.

## Creazione di una firma per un cookie firmato che utilizza una policy personalizzata
<a name="private-content-custom-policy-signature-cookies"></a>

La firma di un cookie firmato che utilizza una policy personalizzata è una versione con hash, firma e codifica base64 della dichiarazione di policy. 

Per ulteriori informazioni ed esempi su come sottoporre a hashing, firmare e codificare la dichiarazione di policy, consulta:
+ [Comandi Linux e OpenSSL per la crittografia e la codifica base64](private-content-linux-openssl.md)
+ [Codice di esempio per la creazione di una firma per un URL firmato](PrivateCFSignatureCodeAndExamples.md)

**Nota**  
Gli esempi collegati utilizzano SHA-1 per impostazione predefinita. Per utilizzare invece SHA-256, sostituiscilo `sha1` con `sha256` nei comandi OpenSSL e includi il cookie con il `CloudFront-Hash-Algorithm` valore di. `SHA256`<a name="private-content-custom-policy-signature-cookies-procedure"></a>

**Creazione di una firma per un cookie firmato utilizzando una policy personalizzata**

1. Utilizzate la funzione hash SHA-1 o SHA-256 e RSA per eseguire l'hash e firmare la dichiarazione di policy JSON creata durante la procedura. [Creazione di una dichiarazione di policy per un URL firmato che utilizza una policy personalizzata](private-content-creating-signed-url-custom-policy.md#private-content-custom-policy-creating-policy-procedure) Utilizza la versione della dichiarazione di policy che non include più spazi vuoti, ma che non è ancora stata codificata in base64.

   Se si utilizza SHA-256, è necessario includere il cookie con un valore di. `CloudFront-Hash-Algorithm` `SHA256`

   Per la chiave privata richiesta dalla funzione hash, utilizza una chiave privata la cui chiave pubblica si trova in un gruppo di chiavi attendibili attivo per la distribuzione.
**Nota**  
Il metodo utilizzato per sottoporre a hashing e firmare la dichiarazione di policy dipende dalla piattaforma e dal linguaggio di programmazione. Per il codice di esempio, consulta [Codice di esempio per la creazione di una firma per un URL firmato](PrivateCFSignatureCodeAndExamples.md).

1. Rimuovi gli spazi vuoti (inclusi i caratteri di nuova riga e le tabulazioni) dalla stringa con hash e firmata.

1. Codifica la stringa utilizzando la codifica base64 MIME. Per ulteriori informazioni, vedere [Sezione 6.8, Base64 Content-Transfer-Encoding in RFC 2045,](https://tools.ietf.org/html/rfc2045#section-6.8) *MIME (Multipurpose Internet Mail Extensions), parte prima: Formato dei corpi dei messaggi Internet*.

1. Sostituisci i caratteri non validi nella stringa di query dell'URL con caratteri validi. La tabella seguente elenca i caratteri validi e non validi.  
****    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonCloudFront/latest/DeveloperGuide/private-content-setting-signed-cookie-custom-policy.html)

1. Includi il valore risultante nell'intestazione `Set-Cookie` per la coppia nome-valore `CloudFront-Signature=` e ritorna a [Impostazione di un cookie firmato che utilizza una policy personalizzata](#private-content-setting-signed-cookie-custom-policy-procedure) per aggiungere l'intestazione `Set-Cookie` per `CloudFront-Key-Pair-Id`.

# Creazione di cookie firmati utilizzando PHP
<a name="signed-cookies-PHP"></a>

Il seguente esempio di codice è simile all’esempio in [Creazione di una firma per URL utilizzando PHP](CreateURL_PHP.md) in quanto crea un collegamento a un video. Tuttavia, invece di firmare l’URL nel codice, questo esempio firma i cookie con la funzione `create_signed_cookies()`. Il player lato client utilizza i cookie per autenticare ogni richiesta alla distribuzione. CloudFront

Questo approccio è utile per lo streaming di contenuti, come HTTP Live Streaming (HLS) o Dynamic Adaptive Streaming over HTTP (DASH), in cui il client deve effettuare più richieste per recuperare il manifesto, i segmenti e gli asset di riproduzione correlati. Utilizzando i cookie firmati, il client può autenticare ogni richiesta senza dover generare un nuovo URL firmato per ogni segmento. 

**Nota**  
La creazione di una firma URL è solo una parte del processo di gestione di contenuti privati tramite cookie firmati. Per ulteriori informazioni, consulta [Utilizzo di cookie firmati](private-content-signed-cookies.md).



**Topics**
+ [

## Crea la firma RSA SHA-1 o SHA-256
](#create-rsa-sha-1signature-cookies)
+ [

## Creazione di cookie firmati
](#create-the-signed-cookie)
+ [

## Codice completo
](#full-code-signed-cookies)

Nelle sezioni seguenti, l’esempio di codice viene suddiviso in singole parti. Di seguito è riportato l’[esempio di codice](#full-code-signed-cookies) completo.

## Crea la firma RSA SHA-1 o SHA-256
<a name="create-rsa-sha-1signature-cookies"></a>

In questo codice di esempio vengono eseguite le seguenti operazioni:

1. La funzione esegue l'`rsa_sha1_sign`hashing e firma l'informativa sulla politica utilizzando SHA-1. Per utilizzare invece SHA-256, utilizzate la funzione rsa\$1sha256\$1sign mostrata di seguito. Gli argomenti richiesti sono una dichiarazione di policy e la chiave privata che corrisponde a una chiave pubblica appartenente a un gruppo di chiavi attendibili per la distribuzione.

1. Successivamente, la funzione `url_safe_base64_encode` crea una versione URL-safe della firma.

   ```
   function rsa_sha1_sign($policy, $private_key_filename) {
       $signature = "";
       $fp = fopen($private_key_filename, "r");
       $priv_key = fread($fp, 8192);
       fclose($fp);
       $pkeyid = openssl_get_privatekey($priv_key);
       openssl_sign($policy, $signature, $pkeyid);
       openssl_free_key($pkeyid);
       return $signature;
   }
   
   function url_safe_base64_encode($value) {
       $encoded = base64_encode($value);
       return str_replace(
           array('+', '=', '/'),
           array('-', '_', '~'),
           $encoded);
   }
   ```

   La seguente funzione utilizza SHA-256 anziché SHA-1:

   ```
   function rsa_sha256_sign($policy, $private_key_filename) {
       $signature = "";
       $fp = fopen($private_key_filename, "r");
       $priv_key = fread($fp, 8192);
       fclose($fp);
       $pkeyid = openssl_get_privatekey($priv_key);
       openssl_sign($policy, $signature, $pkeyid, OPENSSL_ALGO_SHA256);
       openssl_free_key($pkeyid);
       return $signature;
   }
   ```

   La `rsa_sha256_sign` funzione è la stessa di`rsa_sha1_sign`, tranne per il fatto che passa a. `OPENSSL_ALGO_SHA256` `openssl_sign` Quando usi SHA-256, includi il `CloudFront-Hash-Algorithm` cookie con un valore di. `SHA256`

## Creazione di cookie firmati
<a name="create-the-signed-cookie"></a>

Il codice seguente costruisce a crea i cookie firmati, utilizzando i seguenti attributi dei cookie:`CloudFront-Expires`, `CloudFront-Signature` e. `CloudFront-Key-Pair-Id` `CloudFront-Hash-Algorithm` Il codice utilizza una policy personalizzata.

```
function create_signed_cookies($resource, $private_key_filename, $key_pair_id, $expires, $client_ip = null, $hash_algorithm = 'SHA1') {
    $policy = array(
        'Statement' => array(
            array(
                'Resource' => $resource,
                'Condition' => array(
                    'DateLessThan' => array('AWS:EpochTime' => $expires)
                )
            )
        )
    );

    if ($client_ip) {
        $policy['Statement'][0]['Condition']['IpAddress'] = array('AWS:SourceIp' => $client_ip . '/32');
    }

    $policy = json_encode($policy);
    $encoded_policy = url_safe_base64_encode($policy);
    if ($hash_algorithm === 'SHA256') {
        $signature = rsa_sha256_sign($policy, $private_key_filename);
    } else {
        $signature = rsa_sha1_sign($policy, $private_key_filename);
    }
    $encoded_signature = url_safe_base64_encode($signature);

    $cookies = array(
        'CloudFront-Policy' => $encoded_policy,
        'CloudFront-Signature' => $encoded_signature,
        'CloudFront-Key-Pair-Id' => $key_pair_id
    );

    if ($hash_algorithm === 'SHA256') {
        $cookies['CloudFront-Hash-Algorithm'] = 'SHA256';
    }

    return $cookies;
}
```

Per ulteriori informazioni, consulta [Impostazione di cookie firmati che utilizzano una policy personalizzata](private-content-setting-signed-cookie-custom-policy.md).

## Codice completo
<a name="full-code-signed-cookies"></a>

Il codice di esempio seguente fornisce una dimostrazione completa della creazione di cookie CloudFront firmati con PHP. Puoi scaricare l’esempio completo dal file [demo-php.zip](samples/demo-php.zip).

Nell'esempio seguente, è possibile modificare l'`$policy Condition`elemento per consentire sia gli intervalli di indirizzi che gli intervalli IPv4 di IPv6 indirizzi. Per un esempio, [ IPv6 consulta Using address in IAM policies](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ipv6-access.html#ipv6-access-iam) nella *Amazon Simple Storage Service User Guide*.

```
<?php

function rsa_sha1_sign($policy, $private_key_filename) {
    $signature = "";
    $fp = fopen($private_key_filename, "r");
    $priv_key = fread($fp, 8192);
    fclose($fp);
    $pkeyid = openssl_get_privatekey($priv_key);
    openssl_sign($policy, $signature, $pkeyid);
    openssl_free_key($pkeyid);
    return $signature;
}

function url_safe_base64_encode($value) {
    $encoded = base64_encode($value);
    return str_replace(
        array('+', '=', '/'),
        array('-', '_', '~'),
        $encoded);
}

function rsa_sha256_sign($policy, $private_key_filename) {
    $signature = "";
    $fp = fopen($private_key_filename, "r");
    $priv_key = fread($fp, 8192);
    fclose($fp);
    $pkeyid = openssl_get_privatekey($priv_key);
    openssl_sign($policy, $signature, $pkeyid, OPENSSL_ALGO_SHA256);
    openssl_free_key($pkeyid);
    return $signature;
}

function create_signed_cookies($resource, $private_key_filename, $key_pair_id, $expires, $client_ip = null, $hash_algorithm = 'SHA1') {
    $policy = array(
        'Statement' => array(
            array(
                'Resource' => $resource,
                'Condition' => array(
                    'DateLessThan' => array('AWS:EpochTime' => $expires)
                )
            )
        )
    );

    if ($client_ip) {
        $policy['Statement'][0]['Condition']['IpAddress'] = array('AWS:SourceIp' => $client_ip . '/32');
    }

    $policy = json_encode($policy);
    $encoded_policy = url_safe_base64_encode($policy);
    if ($hash_algorithm === 'SHA256') {
        $signature = rsa_sha256_sign($policy, $private_key_filename);
    } else {
        $signature = rsa_sha1_sign($policy, $private_key_filename);
    }
    $encoded_signature = url_safe_base64_encode($signature);

    $cookies = array(
        'CloudFront-Policy' => $encoded_policy,
        'CloudFront-Signature' => $encoded_signature,
        'CloudFront-Key-Pair-Id' => $key_pair_id
    );

    if ($hash_algorithm === 'SHA256') {
        $cookies['CloudFront-Hash-Algorithm'] = 'SHA256';
    }

    return $cookies;
}



$private_key_filename = '/home/test/secure/example-priv-key.pem';
$key_pair_id = 'K2JCJMDEHXQW5F';
$base_url = 'https://d1234.cloudfront.net';

$expires = time() + 3600; // 1 hour from now

// Get the viewer real IP from the x-forward-for header as $_SERVER['REMOTE_ADDR'] will return viewer facing IP. An alternative option is to use CloudFront-Viewer-Address header. Note that this header is a trusted CloudFront immutable header. Example format: IP:PORT ("CloudFront-Viewer-Address": "1.2.3.4:12345")
$client_ip = $_SERVER['HTTP_X_FORWARDED_FOR'];


// For HLS manifest and segments (using wildcard)
$hls_resource = $base_url . '/sign/*';
$signed_cookies = create_signed_cookies($hls_resource, $private_key_filename, $key_pair_id, $expires, $client_ip, 'SHA256');

// Set the cookies
$cookie_domain = parse_url($base_url, PHP_URL_HOST);
foreach ($signed_cookies as $name => $value) {
    setcookie($name, $value, $expires, '/', $cookie_domain, true, true);
}

?>

<!DOCTYPE html>
<html>
<head>
    <title>CloudFront Signed HLS Stream with Cookies</title>
</head>
<body>
    <h1>Amazon CloudFront Signed HLS Stream with Cookies</h1>
    <h2>Expires at <?php echo gmdate('Y-m-d H:i:s T', $expires); ?> only viewable by IP <?php echo $client_ip; ?></h2>
    
    <div id='hls-video'>
        <video id="video" width="640" height="360" controls></video>
    </div>

    <script src="https://cdn.jsdelivr.net/npm/hls.js@latest"></script>
    <script>
        var video = document.getElementById('video');
        var manifestUrl = '<?php echo $base_url; ?>/sign/manifest.m3u8';
        
        if (Hls.isSupported()) {
            var hls = new Hls();
            hls.loadSource(manifestUrl);
            hls.attachMedia(video);
        }
        else if (video.canPlayType('application/vnd.apple.mpegurl')) {
            video.src = manifestUrl;
        }
    </script>
</body>
</html>
```

Invece di utilizzare cookie firmati, puoi utilizzare cookie firmati URLs. Per ulteriori informazioni, consulta [Creazione di una firma per URL utilizzando PHP](CreateURL_PHP.md).

# Comandi Linux e OpenSSL per la crittografia e la codifica base64
<a name="private-content-linux-openssl"></a>

Puoi utilizzare il seguente comando della riga di comando Linux e OpenSSL per sottoporre a hashing e firmare la dichiarazione di policy, codificare in base64 la firma e sostituire i caratteri non validi nei parametri di stringa di query degli URL con caratteri validi.

Per informazioni su OpenSSL, consulta [https://www.openssl.org](https://www.openssl.org).

SHA-1 (impostazione predefinita):

```
cat policy | tr -d "\n" | tr -d " \t\n\r" | openssl sha1 -sign private_key.pem | openssl base64 -A | tr -- '+=/' '-_~'
```

SHA-256:

```
cat policy | tr -d "\n" | tr -d " \t\n\r" | openssl sha256 -sign private_key.pem | openssl base64 -A | tr -- '+=/' '-_~'
```

Nel precedente comando:
+ `cat` legge il file `policy`.
+ `tr -d "\n" | tr -d " \t\n\r"` rimuove gli spazi e il carattere di nuova riga aggiunti da `cat`.
+ OpenSSL esegue l'hash del file utilizzando SHA-1 (o SHA-256) e lo firma utilizzando il file della chiave privata. `private_key.pem` La firma chiave privata può essere RSA 2048 o ECDSA 256. Se utilizzi SHA-256, includi il parametro di `Hash-Algorithm=SHA256` query nell'URL firmato o il cookie per i cookie firmati. `CloudFront-Hash-Algorithm=SHA256`
+ OpenSSL codifica in base64 la dichiarazione di policy con hash e firmata.
+ `tr` sostituisce i caratteri non validi nei parametri di stringa di query dell’URL con caratteri validi.

Per ulteriori codici di esempio che illustrano la creazione di una firma, consulta [Codice di esempio per la creazione di una firma per un URL firmato](PrivateCFSignatureCodeAndExamples.md).

# Codice di esempio per la creazione di una firma per un URL firmato
<a name="PrivateCFSignatureCodeAndExamples"></a>

Questa sezione include esempi di applicazioni scaricabili che dimostrano come creare firme per signed. URLs Vengono forniti esempi in Perl, PHP, C\$1 e Java. È possibile utilizzare uno qualsiasi degli esempi per creare firme firmate. URLs Lo script Perl viene eseguito su piattaforme Linux e macOS. L'esempio PHP funzionerà su qualsiasi server che esegue PHP. L'esempio C\$1 utilizza .NET Framework.

Gli esempi di questa sezione utilizzano SHA-1 per eseguire l'hash e firmare la dichiarazione politica. È inoltre possibile utilizzare SHA-256. Per usare SHA-256, aggiorna l'algoritmo hash nella funzione di firma (ad esempio, sostituiscilo con `sha1` nelle chiamate `sha256` OpenSSL o usa la costante SHA-256 equivalente nella libreria crittografica della tua lingua). Quando usi SHA-256, includi il parametro di query nell'URL firmato. `Hash-Algorithm=SHA256`

Ad esempio, codice in JavaScript (Node.js), consulta [Creazione di Amazon CloudFront Signed URLs in Node.js](https://aws.amazon.com/blogs/developer/creating-amazon-cloudfront-signed-urls-in-node-js/) sul blog AWS degli sviluppatori.

[Per un esempio di codice in Python, consulta [Generare un URL firmato per Amazon CloudFront](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/cloudfront.html#examples) nell'API di riferimento dell'*AWS SDK for Python (Boto3) e questo codice di esempio nel repository Boto3*.](https://github.com/boto/boto3/blob/develop/boto3/examples/cloudfront.rst) GitHub 

**Topics**
+ [

# Creazione di una firma per URL utilizzando Perl
](CreateURLPerl.md)
+ [

# Creazione di una firma per URL utilizzando PHP
](CreateURL_PHP.md)
+ [

# Crea una firma per URL utilizzando C\$1 e .NET Framework
](CreateSignatureInCSharp.md)
+ [

# Creazione di una firma per URL utilizzando Java
](CFPrivateDistJavaDevelopment.md)

# Creazione di una firma per URL utilizzando Perl
<a name="CreateURLPerl"></a>

Questa sezione include uno script Perl per Linux/Mac piattaforme che è possibile utilizzare per creare la firma per contenuti privati. Per creare la firma, esegui lo script con argomenti della riga di comando che specificano l' CloudFront URL, il percorso della chiave privata del firmatario, l'ID della chiave e una data di scadenza dell'URL. Lo strumento può anche decodificare i segni firmati. URLs 

**Note**  
La creazione di una firma per URL è solo una parte del processo di distribuzione di contenuto privato mediante un URL firmato. Per ulteriori informazioni sul end-to-end processo, vedere[Usa firmato URLs](private-content-signed-urls.md). 
Nel comando di firma, nota che `sha1` può essere sostituito con `sha256` nella `openssl dgst` chiamata.

**Topics**
+ [

## Origine dello script Perl per la creazione di un URL firmato
](#CreateURLPerlScriptSource)

## Origine dello script Perl per la creazione di un URL firmato
<a name="CreateURLPerlScriptSource"></a>

Il seguente codice sorgente Perl può essere usato per creare un URL firmato per CloudFront. I commenti del codice includono informazioni sulle opzioni della riga di comando e le caratteristiche dello strumento.

```
#!/usr/bin/perl -w

# Copyright 2008 Amazon Technologies, Inc.  Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License. You may obtain a copy of the License at:
#
# https://aws.amazon.com/apache2.0
#
# This file is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and limitations under the License.

=head1 cfsign.pl

cfsign.pl - A tool to generate and verify Amazon CloudFront signed URLs

=head1 SYNOPSIS

This script uses an existing RSA key pair to sign and verify Amazon CloudFront signed URLs

View the script source for details as to which CPAN packages are required beforehand. 

For help, try:

cfsign.pl --help

URL signing examples:

cfsign.pl --action encode --url https://images.my-website.com/gallery1.zip --policy sample_policy.json --private-key privkey.pem --key-pair-id mykey

cfsign.pl --action encode --url https://images.my-website.com/gallery1.zip --expires 1257439868 --private-key privkey.pem --key-pair-id mykey

URL decode example:

cfsign.pl --action decode --url "http//mydist.cloudfront.net/?Signature=AGO-PgxkYo99MkJFHvjfGXjG1QDEXeaDb4Qtzmy85wqyJjK7eKojQWa4BCRcow__&Policy=eyJTdGF0ZW1lbnQiOlt7IlJlc291cmNlIjoiaHR0cDovLypicmFkbS5qcGciLCJDb25kaXRpb24iOnsiSXBBZGRyZXNzIjp7IkFXUzpTb3VyY2VJcCI6IjEwLjUyLjE3LjkvMCJ9LCJEYXRlR3JlYXRlclRoYW4iOnsiQVdTOkVwb2NoVGltZSI6MTI1MjUyMDgzMH19fV19Cg__&Key-Pair-Id=mykey"


To generate an RSA key pair, you can use openssl and the following commands:

# Generate a 2048 bit key pair
openssl genrsa -out private-key.pem 2048
openssl rsa -in private-key.pem -pubout -out public-key.pem


=head1 OPTIONS

=over 8

=item B<--help>

Print a help message and exits.

=item B<--action> [action]

The action to execute.  action can be one of:

  encode - Generate a signed URL (using a canned policy or a user policy)
  decode - Decode a signed URL

=item B<--url>

The URL to en/decode

=item B<--stream>

The stream to en/decode

=item B<--private-key>

The path to your private key.

=item B<--key-pair-id>

The key pair identifier.

=item B<--policy>

The CloudFront policy document.

=item B<--expires>

The Unix epoch time when the URL is to expire. If both this option and
the --policy option are specified, --policy will be used. Otherwise, this 
option alone will use a canned policy.

=back

=cut

use strict;
use warnings;

# you might need to use CPAN to get these modules.
# run perl -MCPAN -e "install <module>" to get them.
# The openssl command line will also need to be in your $PATH.
use File::Temp qw/tempfile/;
use File::Slurp;
use Getopt::Long;
use IPC::Open2;
use MIME::Base64 qw(encode_base64 decode_base64);
use Pod::Usage;
use URI;

my $CANNED_POLICY 
    = '{"Statement":[{"Resource":"<RESOURCE>","Condition":{"DateLessThan":{"AWS:EpochTime":<EXPIRES>}}}]}';

my $POLICY_PARAM      = "Policy";
my $EXPIRES_PARAM     = "Expires";
my $SIGNATURE_PARAM   = "Signature";
my $KEY_PAIR_ID_PARAM = "Key-Pair-Id";

my $verbose = 0;
my $policy_filename = "";
my $expires_epoch = 0;
my $action = "";
my $help = 0;
my $key_pair_id = "";
my $url = "";
my $stream = "";
my $private_key_filename = "";

my $result = GetOptions("action=s"      => \$action,
                        "policy=s"      => \$policy_filename,
                        "expires=i"     => \$expires_epoch,
                        "private-key=s" => \$private_key_filename,
                        "key-pair-id=s" => \$key_pair_id,
                        "verbose"       => \$verbose,
                        "help"          => \$help,
                        "url=s"         => \$url,
                        "stream=s"      => \$stream,
                    );

if ($help or !$result) {
    pod2usage(1);
    exit;
}

if ($url eq "" and $stream eq "") {
    print STDERR "Must include a stream or a URL to encode or decode with the --stream or --url option\n";
    exit;
}

if ($url ne "" and $stream ne "") {
    print STDERR "Only one of --url and --stream may be specified\n";
    exit;
}

if ($url ne "" and !is_url_valid($url)) {
    exit;
}

if ($stream ne "") {
    exit unless is_stream_valid($stream);

    # The signing mechanism is identical, so from here on just pretend we're
    # dealing with a URL
    $url = $stream;
} 

if ($action eq "encode") {
    # The encode action will generate a private content URL given a base URL, 
    # a policy file (or an expires timestamp) and a key pair id parameter
    my $private_key;
    my $public_key;
    my $public_key_file;
    
    my $policy;
    if ($policy_filename eq "") {
        if ($expires_epoch == 0) {
            print STDERR "Must include policy filename with --policy argument or an expires" . 
                          "time using --expires\n";            
        }
        
        $policy = $CANNED_POLICY;
        $policy =~ s/<EXPIRES>/$expires_epoch/g;
        $policy =~ s/<RESOURCE>/$url/g;
    } else {
        if (! -e $policy_filename) {
            print STDERR "Policy file $policy_filename does not exist\n";
            exit;
        }
        $expires_epoch = 0; # ignore if set
        $policy = read_file($policy_filename);
    }

    if ($private_key_filename eq "") {
        print STDERR "You must specific the path to your private key file with --private-key\n";
        exit;
    }

    if (! -e $private_key_filename) {
        print STDERR "Private key file $private_key_filename does not exist\n";
        exit;
    }

    if ($key_pair_id eq "") {
        print STDERR "You must specify a key pair id with --key-pair-id\n";
        exit;
    }

    my $encoded_policy = url_safe_base64_encode($policy);
    my $signature = rsa_sha1_sign($policy, $private_key_filename);
    my $encoded_signature = url_safe_base64_encode($signature);

    my $generated_url = create_url($url, $encoded_policy, $encoded_signature, $key_pair_id, $expires_epoch);


    if ($stream ne "") {
        print "Encoded stream (for use within a swf):\n" . $generated_url . "\n";
        print "Encoded and escaped stream (for use on a webpage):\n" .  escape_url_for_webpage($generated_url) . "\n"; 
    } else {
        print "Encoded URL:\n" . $generated_url . "\n";
    }
} elsif ($action eq "decode") {
    my $decoded = decode_url($url);
    if (!$decoded) {
        print STDERR "Improperly formed URL\n";
        exit;
    }

    print_decoded_url($decoded);
} else {
    # No action specified, print help.  But only if this is run as a program (caller will be empty)
    pod2usage(1) unless caller();
}

# Decode a private content URL into its component parts
sub decode_url {
    my $url = shift;

    if ($url =~ /(.*)\?(.*)/) {
        my $base_url = $1;
        my $params = $2;

        my @unparsed_params = split(/&/, $params);
        my %params = ();
        foreach my $param (@unparsed_params) {
            my ($key, $val) = split(/=/, $param);
            $params{$key} = $val;
        }

        my $encoded_signature = "";
        if (exists $params{$SIGNATURE_PARAM}) {
            $encoded_signature = $params{"Signature"};
        } else {
            print STDERR "Missing Signature URL parameter\n";
            return 0;
        }

        my $encoded_policy = "";
        if (exists $params{$POLICY_PARAM}) {
            $encoded_policy = $params{$POLICY_PARAM};
        } else {
            if (!exists $params{$EXPIRES_PARAM}) {
                print STDERR "Either the Policy or Expires URL parameter needs to be specified\n";
                return 0;    
            }
            
            my $expires = $params{$EXPIRES_PARAM};
            
            my $policy = $CANNED_POLICY;
            $policy =~ s/<EXPIRES>/$expires/g;
            
            my $url_without_cf_params = $url;
            $url_without_cf_params =~ s/$SIGNATURE_PARAM=[^&]*&?//g;
            $url_without_cf_params =~ s/$POLICY_PARAM=[^&]*&?//g;
            $url_without_cf_params =~ s/$EXPIRES_PARAM=[^&]*&?//g;
            $url_without_cf_params =~ s/$KEY_PAIR_ID_PARAM=[^&]*&?//g;
            
            if ($url_without_cf_params =~ /(.*)\?$/) {
                $url_without_cf_params = $1;
            }
            
            $policy =~ s/<RESOURCE>/$url_without_cf_params/g;
            
            $encoded_policy = url_safe_base64_encode($policy);
        }

        my $key = "";
        if (exists $params{$KEY_PAIR_ID_PARAM}) {
            $key = $params{$KEY_PAIR_ID_PARAM};
        } else {
            print STDERR "Missing $KEY_PAIR_ID_PARAM parameter\n";
            return 0;
        }

        my $policy = url_safe_base64_decode($encoded_policy);

        my %ret = ();
        $ret{"base_url"} = $base_url;
        $ret{"policy"} = $policy;
        $ret{"key"} = $key;

        return \%ret;
    } else {
        return 0;
    }
}

# Print a decoded URL out
sub print_decoded_url {
    my $decoded = shift;

    print "Base URL: \n" . $decoded->{"base_url"} . "\n";
    print "Policy: \n" . $decoded->{"policy"} . "\n";
    print "Key: \n" . $decoded->{"key"} . "\n";
}

# Encode a string with base 64 encoding and replace some invalid URL characters
sub url_safe_base64_encode {
    my ($value) = @_;

    my $result = encode_base64($value);
    $result =~ tr|+=/|-_~|;

    return $result;
}

# Decode a string with base 64 encoding.  URL-decode the string first
# followed by reversing any special character ("+=/") translation.
sub url_safe_base64_decode {
    my ($value) = @_;

    $value =~ s/%([0-9A-Fa-f]{2})/chr(hex($1))/eg;
    $value =~ tr|-_~|+=/|;

    my $result = decode_base64($value);

    return $result;
}

# Create a private content URL
sub create_url {
    my ($path, $policy, $signature, $key_pair_id, $expires) = @_;
    
    my $result;
    my $separator = $path =~ /\?/ ? '&' : '?';
    if ($expires) {
        $result = "$path$separator$EXPIRES_PARAM=$expires&$SIGNATURE_PARAM=$signature&$KEY_PAIR_ID_PARAM=$key_pair_id";
    } else {
        $result = "$path$separator$POLICY_PARAM=$policy&$SIGNATURE_PARAM=$signature&$KEY_PAIR_ID_PARAM=$key_pair_id";
    }
    $result =~ s/\n//g;

    return $result;
}

# Sign a document with given private key file.
# The first argument is the document to sign
# The second argument is the name of the private key file
sub rsa_sha1_sign {
    my ($to_sign, $pvkFile) = @_;
    print "openssl sha1 -sign $pvkFile $to_sign\n";

    return write_to_program($pvkFile, $to_sign);
}

# Helper function to write data to a program
sub write_to_program {
my ($keyfile, $data) = @_;
unlink "temp_policy.dat" if (-e "temp_policy.dat");
unlink "temp_sign.dat" if (-e "temp_sign.dat");

write_file("temp_policy.dat", $data);

system("openssl dgst -sha1 -sign \"$keyfile\" -out temp_sign.dat temp_policy.dat");

my $output = read_file("temp_sign.dat");

    return $output;
}

# Read a file into a string and return the string
sub read_file {
    my ($file) = @_;

    open(INFILE, "<$file") or die("Failed to open $file: $!");
    my $str = join('', <INFILE>);
    close INFILE;

    return $str;
}

sub is_url_valid {
    my ($url) = @_;

    # HTTP distributions start with http[s]:// and are the correct thing to sign
    if ($url =~ /^https?:\/\//) {
        return 1;
    } else {
        print STDERR "CloudFront requires absolute URLs for HTTP distributions\n";
        return 0;
    }
}

sub is_stream_valid {
    my ($stream) = @_;

    if ($stream =~ /^rtmp:\/\// or $stream =~ /^\/?cfx\/st/) {
        print STDERR "Streaming distributions require that only the stream name is signed.\n";
        print STDERR "The stream name is everything after, but not including, cfx/st/\n";
        return 0;
    } else {
        return 1;
    }
}

# flash requires that the query parameters in the stream name are url
# encoded when passed in through javascript, etc.  This sub handles the minimal
# required url encoding.
sub escape_url_for_webpage {
    my ($url) = @_;

    $url =~ s/\?/%3F/g;
    $url =~ s/=/%3D/g;
    $url =~ s/&/%26/g;

    return $url;
}

1;
```

# Creazione di una firma per URL utilizzando PHP
<a name="CreateURL_PHP"></a>

Qualsiasi server Web che esegue PHP può utilizzare questo codice di esempio PHP per creare dichiarazioni politiche e firme per distribuzioni private. CloudFront L'esempio completo crea una pagina Web funzionante con collegamenti URL firmati che riproducono uno streaming video utilizzando lo streaming. CloudFront Puoi scaricare l’esempio completo dal file [demo-php.zip](samples/demo-php.zip).

**Note**  
La creazione di una firma per URL è solo una parte del processo di distribuzione di contenuto privato mediante un URL firmato. Per ulteriori informazioni sull'intero processo, consulta [Usa firmato URLs](private-content-signed-urls.md). 
È inoltre possibile creare un URLs file firmato utilizzando la `UrlSigner` classe in. AWS SDK per PHP Per ulteriori informazioni, vedete [Class UrlSigner](https://docs.aws.amazon.com/aws-sdk-php/v3/api/class-Aws.CloudFront.UrlSigner.html) nel *AWS SDK per PHP API Reference*.
Nella `openssl_sign` chiamata, notate che passando `OPENSSL_ALGO_SHA256` come quarto argomento si passa a SHA-256. (Vedi anche [Creazione di cookie firmati utilizzando PHP](signed-cookies-PHP.md) per un esempio completo).

**Topics**
+ [

## Creazione della firma RSA SHA-1
](#sample-rsa-sign)
+ [

## Creazione di una policy di accesso predefinita
](#sample-canned-policy)
+ [

## Creare una policy personalizzata
](#sample-custom-policy)
+ [

## Esempio di codice completo
](#full-example)

Nelle sezioni seguenti, l’esempio di codice viene suddiviso in singole parti. Di seguito è riportato il [Esempio di codice completo](#full-example) completo.

## Creazione della firma RSA SHA-1
<a name="sample-rsa-sign"></a>

In questo codice di esempio vengono eseguite le seguenti operazioni:
+ La funzione `rsa_sha1_sign` esegue l’hashing e firma la dichiarazione di policy. Gli argomenti richiesti sono una dichiarazione di policy e la chiave privata che corrisponde a una chiave pubblica appartenente a un gruppo di chiavi attendibili per la distribuzione. 
+ Successivamente, la funzione `url_safe_base64_encode` crea una versione URL-safe della firma.

```
function rsa_sha1_sign($policy, $private_key_filename) {
    $signature = "";

    // load the private key
    $fp = fopen($private_key_filename, "r");
    $priv_key = fread($fp, 8192);
    fclose($fp);
    $pkeyid = openssl_get_privatekey($priv_key);

    // compute signature
    openssl_sign($policy, $signature, $pkeyid);

    // free the key from memory
    openssl_free_key($pkeyid);

    return $signature;
}

function url_safe_base64_encode($value) {
    $encoded = base64_encode($value);
    // replace unsafe characters +, = and / with 
    // the safe characters -, _ and ~
    return str_replace(
        array('+', '=', '/'),
        array('-', '_', '~'),
        $encoded);
}
```

Il seguente frammento di codice utilizza le funzioni `get_canned_policy_stream_name()` e `get_custom_policy_stream_name()` crea una politica predefinita e personalizzata. CloudFront utilizza le politiche per creare l'URL per lo streaming del video, inclusa la specifica dell'ora di scadenza. 

Puoi quindi utilizzare una policy di accesso predefinita o una policy personalizzata per determinare come gestire l’accesso ai contenuti. Per ulteriori informazioni su quale scegliere, consulta la sezione [Decidi di utilizzare politiche predefinite o personalizzate per la firma URLs](private-content-signed-urls.md#private-content-choosing-canned-custom-policy).

## Creazione di una policy di accesso predefinita
<a name="sample-canned-policy"></a>

Il codice di esempio seguente crea una dichiarazione di policy *predefinita* per la firma. 

**Nota**  
La `$expires` variabile è un date/time timbro che deve essere un numero intero, non una stringa.

```
function get_canned_policy_stream_name($video_path, $private_key_filename, $key_pair_id, $expires) {
    // this policy is well known by CloudFront, but you still need to sign it, since it contains your parameters
    $canned_policy = '{"Statement":[{"Resource":"' . $video_path . '","Condition":{"DateLessThan":{"AWS:EpochTime":'. $expires . '}}}]}';
    // the policy contains characters that cannot be part of a URL, so we base64 encode it
    $encoded_policy = url_safe_base64_encode($canned_policy);
    // sign the original policy, not the encoded version
    $signature = rsa_sha1_sign($canned_policy, $private_key_filename);
    // make the signature safe to be included in a URL
    $encoded_signature = url_safe_base64_encode($signature);

    // combine the above into a stream name
    $stream_name = create_stream_name($video_path, null, $encoded_signature, $key_pair_id, $expires);
    // URL-encode the query string characters
    return $stream_name;
}
```

Per ulteriori informazioni sulle policy predefinite, consulta [Creazione di un URL firmato utilizzando una policy di accesso predefinita](private-content-creating-signed-url-canned-policy.md).

## Creare una policy personalizzata
<a name="sample-custom-policy"></a>

Il codice di esempio seguente crea una dichiarazione di policy *personalizzata* per la firma. 

```
function get_custom_policy_stream_name($video_path, $private_key_filename, $key_pair_id, $policy) {
    // the policy contains characters that cannot be part of a URL, so we base64 encode it
    $encoded_policy = url_safe_base64_encode($policy);
    // sign the original policy, not the encoded version
    $signature = rsa_sha1_sign($policy, $private_key_filename);
    // make the signature safe to be included in a URL
    $encoded_signature = url_safe_base64_encode($signature);

    // combine the above into a stream name
    $stream_name = create_stream_name($video_path, $encoded_policy, $encoded_signature, $key_pair_id, null);
    // URL-encode the query string characters
    return $stream_name;
}
```

Per ulteriori informazioni sulle policy personalizzate, consulta [Creazione di un URL firmato utilizzando una policy personalizzata](private-content-creating-signed-url-custom-policy.md).

## Esempio di codice completo
<a name="full-example"></a>

Il codice di esempio seguente fornisce una dimostrazione completa della creazione di CloudFront signed URLs with PHP. Puoi scaricare l’esempio completo dal file [demo-php.zip](samples/demo-php.zip).

Nell'esempio seguente, è possibile modificare l'`$policy``Condition`elemento per consentire sia gli intervalli di indirizzi che gli intervalli IPv4 di IPv6 indirizzi. Per un esempio, [ IPv6consulta Using address in IAM policies](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ipv6-access.html#ipv6-access-iam) nella *Amazon Simple Storage Service User Guide*.

```
<?php

function rsa_sha1_sign($policy, $private_key_filename) {
    $signature = "";

    // load the private key
    $fp = fopen($private_key_filename, "r");
    $priv_key = fread($fp, 8192);
    fclose($fp);
    $pkeyid = openssl_get_privatekey($priv_key);

    // compute signature
    openssl_sign($policy, $signature, $pkeyid);

    // free the key from memory
    openssl_free_key($pkeyid);

    return $signature;
}

function url_safe_base64_encode($value) {
    $encoded = base64_encode($value);
    // replace unsafe characters +, = and / with the safe characters -, _ and ~
    return str_replace(
        array('+', '=', '/'),
        array('-', '_', '~'),
        $encoded);
}

function create_stream_name($stream, $policy, $signature, $key_pair_id, $expires) {
    $result = $stream;
    // if the stream already contains query parameters, attach the new query parameters to the end
    // otherwise, add the query parameters
    $separator = strpos($stream, '?') == FALSE ? '?' : '&';
    // the presence of an expires time means we're using a canned policy
    if($expires) {
        $result .= $separator . "Expires=" . $expires . "&Signature=" . $signature . "&Key-Pair-Id=" . $key_pair_id;
    }
    // not using a canned policy, include the policy itself in the stream name
    else {
        $result .= $separator . "Policy=" . $policy . "&Signature=" . $signature . "&Key-Pair-Id=" . $key_pair_id;
    }

    // new lines would break us, so remove them
    return str_replace('\n', '', $result);
}


function get_canned_policy_stream_name($video_path, $private_key_filename, $key_pair_id, $expires) {
    // this policy is well known by CloudFront, but you still need to sign it, since it contains your parameters
    $canned_policy = '{"Statement":[{"Resource":"' . $video_path . '","Condition":{"DateLessThan":{"AWS:EpochTime":'. $expires . '}}}]}';
    // the policy contains characters that cannot be part of a URL, so we base64 encode it
    $encoded_policy = url_safe_base64_encode($canned_policy);
    // sign the original policy, not the encoded version
    $signature = rsa_sha1_sign($canned_policy, $private_key_filename);
    // make the signature safe to be included in a URL
    $encoded_signature = url_safe_base64_encode($signature);

    // combine the above into a stream name
    $stream_name = create_stream_name($video_path, null, $encoded_signature, $key_pair_id, $expires);
    // URL-encode the query string characters
    return $stream_name;
}

function get_custom_policy_stream_name($video_path, $private_key_filename, $key_pair_id, $policy) {
    // the policy contains characters that cannot be part of a URL, so we base64 encode it
    $encoded_policy = url_safe_base64_encode($policy);
    // sign the original policy, not the encoded version
    $signature = rsa_sha1_sign($policy, $private_key_filename);
    // make the signature safe to be included in a URL
    $encoded_signature = url_safe_base64_encode($signature);

    // combine the above into a stream name
    $stream_name = create_stream_name($video_path, $encoded_policy, $encoded_signature, $key_pair_id, null);
    // URL-encode the query string characters
    return $stream_name;
}


// Path to your private key.  Be very careful that this file is not accessible
// from the web!

$private_key_filename = '/home/test/secure/example-priv-key.pem';
$key_pair_id = 'K2JCJMDEHXQW5F';

// Make sure you have "Restrict viewer access" enabled on this path behaviour and using the above Trusted key groups (recommended).
$video_path = 'https://example.com/secure/example.mp4';

$expires = time() + 300; // 5 min from now
$canned_policy_stream_name = get_canned_policy_stream_name($video_path, $private_key_filename, $key_pair_id, $expires);

// Get the viewer real IP from the x-forward-for header as $_SERVER['REMOTE_ADDR'] will return viewer facing IP. An alternative option is to use CloudFront-Viewer-Address header. Note that this header is a trusted CloudFront immutable header. Example format: IP:PORT ("CloudFront-Viewer-Address": "1.2.3.4:12345")
$client_ip = $_SERVER['HTTP_X_FORWARDED_FOR'];
$policy =
'{'.
    '"Statement":['.
        '{'.
            '"Resource":"'. $video_path . '",'.
            '"Condition":{'.
                '"IpAddress":{"AWS:SourceIp":"' . $client_ip . '/32"},'.
                '"DateLessThan":{"AWS:EpochTime":' . $expires . '}'.
            '}'.
        '}'.
    ']' .
    '}';
$custom_policy_stream_name = get_custom_policy_stream_name($video_path, $private_key_filename, $key_pair_id, $policy);

?>

<html>

<head>
    <title>CloudFront</title>
</head>

<body>
    <h1>Amazon CloudFront</h1>
    <h2>Canned Policy</h2>
    <h3>Expires at <?php echo gmdate('Y-m-d H:i:s T', $expires); ?></h3>
    <br />

    <div id='canned'>The canned policy video will be here: <br>
    
        <video width="640" height="360" autoplay muted controls>
        <source src="<?php echo $canned_policy_stream_name; ?>" type="video/mp4">
        Your browser does not support the video tag.
        </video>
    </div>

    <h2>Custom Policy</h2>
    <h3>Expires at <?php echo gmdate('Y-m-d H:i:s T', $expires); ?> only viewable by IP <?php echo $client_ip; ?></h3>
    <div id='custom'>The custom policy video will be here: <br>

         <video width="640" height="360" autoplay muted controls>
         <source src="<?php echo $custom_policy_stream_name; ?>" type="video/mp4">
         Your browser does not support the video tag.
        </video>
    </div> 

</body>

</html>
```

Per ulteriori esempi di firme URL, consulta i seguenti argomenti:
+ [Creazione di una firma per URL utilizzando Perl](CreateURLPerl.md)
+ [Crea una firma per URL utilizzando C\$1 e .NET Framework](CreateSignatureInCSharp.md)
+ [Creazione di una firma per URL utilizzando Java](CFPrivateDistJavaDevelopment.md)

Invece di utilizzare signed URLs per creare la firma, puoi utilizzare cookie firmati. Per ulteriori informazioni, consulta [Creazione di cookie firmati utilizzando PHP](signed-cookies-PHP.md).

# Crea una firma per URL utilizzando C\$1 e .NET Framework
<a name="CreateSignatureInCSharp"></a>

Gli esempi in C\$1 in questa sezione implementano un'applicazione di esempio che dimostra come creare le firme per le distribuzioni CloudFront private utilizzando istruzioni di policy predefinite e personalizzate. Gli esempi includono funzioni utility basate sul [AWS SDK per .NET](https://aws.amazon.com/sdkfornet) che può rivelarsi utile nelle applicazioni .NET.

È inoltre possibile creare cookie firmati URLs e firmati utilizzando. SDK per .NET Nella *Documentazione di riferimento delle API di SDK per .NET *, consulta i seguenti argomenti:
+ **Firmato URLs**: [AmazonCloudFrontUrlSigner](https://docs.aws.amazon.com/sdkfornet/v3/apidocs/items/CloudFront/TCloudFrontUrlSigner.html) 
+ **Cookie firmati** — [AmazonCloudFrontCookieSigner](https://docs.aws.amazon.com/sdkfornet/v3/apidocs/items/CloudFront/TCloudFrontCookieSigner.html) 

Per scaricare il codice, consulta [Signature Code in C\$1](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/samples/AWS_PrivateCF_Distributions.zip).

**Note**  
Le classi `AmazonCloudFrontUrlSigner` e `AmazonCloudFrontCookieSigner` sono state spostate in un pacchetto separato. Per ulteriori informazioni sul loro utilizzo, consulta [CookieSigner e UrlSigner](https://docs.aws.amazon.com/sdk-for-net/v4/developer-guide/net-dg-v4.html#net-dg-v4-CookieSigner-UrlSigner) nella *AWS SDK per .NET (V4) Developer Guide*. 
La creazione di una firma per URL è solo una parte del processo di distribuzione di contenuto privato mediante un URL firmato. Per ulteriori informazioni, consulta [Usa firmato URLs](private-content-signed-urls.md). Per ulteriori informazioni sull’utilizzo di cookie firmati, consulta [Utilizzo di cookie firmati](private-content-signed-cookies.md).
Nella chiamata di firma RSA, tieni presente che `SHA1` può essere sostituito con il parametro dell'`SHA256`algoritmo hash.

## Utilizzo di una chiave RSA in .NET Framework
<a name="rsa-key-sdk-net"></a>

Per utilizzare una chiave RSA in.NET Framework, è necessario convertire il file.pem AWS fornito nel formato XML utilizzato da .NET Framework.

Dopo la conversione, il file di chiave privata RSA è nel seguente formato:

**Example : chiave privata RSA nel formato .NET Framework XML**  <a name="RSAPrivateKeyXML.NETFrameworkFormat"></a>

```
<RSAKeyValue>
  <Modulus>
    wO5IvYCP5UcoCKDo1dcspoMehWBZcyfs9QEzGi6Oe5y+ewGr1oW+vB2GPB
    ANBiVPcUHTFWhwaIBd3oglmF0lGQljP/jOfmXHUK2kUUnLnJp+oOBL2NiuFtqcW6h/L5lIpD8Yq+NRHg
    Ty4zDsyr2880MvXv88yEFURCkqEXAMPLE=
  </Modulus>
  <Exponent>AQAB</Exponent>
  <P>
    5bmKDaTz
    npENGVqz4Cea8XPH+sxt+2VaAwYnsarVUoSBeVt8WLloVuZGG9IZYmH5KteXEu7fZveYd9UEXAMPLE==
  </P>
  <Q>
    1v9l/WN1a1N3rOK4VGoCokx7kR2SyTMSbZgF9IWJNOugR/WZw7HTnjipO3c9dy1Ms9pUKwUF4
    6d7049EXAMPLE==
  </Q>
  <DP>
    RgrSKuLWXMyBH+/l1Dx/I4tXuAJIrlPyo+VmiOc7b5NzHptkSHEPfR9s1
    OK0VqjknclqCJ3Ig86OMEtEXAMPLE==
  </DP>
  <DQ>
    pjPjvSFw+RoaTu0pgCA/jwW/FGyfN6iim1RFbkT4
    z49DZb2IM885f3vf35eLTaEYRYUHQgZtChNEV0TEXAMPLE==
  </DQ>
  <InverseQ>
    nkvOJTg5QtGNgWb9i
    cVtzrL/1pFEOHbJXwEJdU99N+7sMK+1066DL/HSBUCD63qD4USpnf0myc24in0EXAMPLE==</InverseQ>
  <D>
      Bc7mp7XYHynuPZxChjWNJZIq+A73gm0ASDv6At7F8Vi9r0xUlQe/v0AQS3ycN8QlyR4XMbzMLYk
      3yjxFDXo4ZKQtOGzLGteCU2srANiLv26/imXA8FVidZftTAtLviWQZBVPTeYIA69ATUYPEq0a5u5wjGy
      UOij9OWyuEXAMPLE=
   </D>
</RSAKeyValue>
```

## Metodo di firma di policy predefinita in C\$1
<a name="canned-policy-signed-url-net"></a>

Il codice C\$1 esposto di seguito crea un URL firmato che utilizza una policy predefinita eseguendo la procedura seguente:
+ Crea una dichiarazione di policy.
+ Esegue l'hash della dichiarazione politica utilizzando SHA1 e firma il risultato utilizzando RSA e la chiave privata la cui chiave pubblica corrispondente si trova in un gruppo di chiavi attendibili.
+ Codifica in base64 la dichiarazione di policy con firma e hash e sostituisce i caratteri speciali per rendere sicura la stringa da utilizzare come parametro di richiesta URL.
+ Concatena i valori.

Per l'implementazione completa, vedi l'esempio in [Signature Code in C\$1](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/samples/AWS_PrivateCF_Distributions.zip). 

**Nota**  
`keyId`Viene restituito quando si carica una chiave pubblica su. CloudFront Per ulteriori informazioni, consulta ![\[6\]](http://docs.aws.amazon.com/it_it/AmazonCloudFront/latest/DeveloperGuide/images/callouts/6.png)[ &Key-Pair-Id](private-content-creating-signed-url-canned-policy.md).

**Example : metodo di firma di policy di accesso predefinita in C\$1**  <a name="ExampleCannedPolicySigningMethod-CSharp"></a>

```
public static string ToUrlSafeBase64String(byte[] bytes)
{
    return System.Convert.ToBase64String(bytes)
        .Replace('+', '-')
        .Replace('=', '_')
        .Replace('/', '~');
}

public static string CreateCannedPrivateURL(string urlString, 
    string durationUnits, string durationNumber, string pathToPolicyStmnt, 
    string pathToPrivateKey, string keyId)
{
    // args[] 0-thisMethod, 1-resourceUrl, 2-seconds-minutes-hours-days 
    // to expiration, 3-numberOfPreviousUnits, 4-pathToPolicyStmnt, 
    // 5-pathToPrivateKey, 6-keyId

    TimeSpan timeSpanInterval = GetDuration(durationUnits, durationNumber);

    // Create the policy statement.
    string strPolicy = CreatePolicyStatement(pathToPolicyStmnt,
        urlString, 
        DateTime.Now, 
        DateTime.Now.Add(timeSpanInterval), 
        "0.0.0.0/0");
    if ("Error!" == strPolicy) return "Invalid time frame." + 
        "Start time cannot be greater than end time.";

    // Copy the expiration time defined by policy statement.
    string strExpiration = CopyExpirationTimeFromPolicy(strPolicy);

    // Read the policy into a byte buffer.
    byte[] bufferPolicy = Encoding.ASCII.GetBytes(strPolicy);

    // Initialize the SHA1CryptoServiceProvider object and hash the policy data.
    using (SHA1CryptoServiceProvider 
        cryptoSHA1 = new SHA1CryptoServiceProvider())
    {
        bufferPolicy = cryptoSHA1.ComputeHash(bufferPolicy);

        // Initialize the RSACryptoServiceProvider object.
        RSACryptoServiceProvider providerRSA = new RSACryptoServiceProvider();
        XmlDocument xmlPrivateKey = new XmlDocument();

        // Load your private key, which you created by converting your 
        // .pem file to the XML format that the .NET framework uses.  
        // Several tools are available. 
        xmlPrivateKey.Load(pathToPrivateKey);

        // Format the RSACryptoServiceProvider providerRSA and 
        // create the signature.
        providerRSA.FromXmlString(xmlPrivateKey.InnerXml);
        RSAPKCS1SignatureFormatter rsaFormatter = 
            new RSAPKCS1SignatureFormatter(providerRSA);
        rsaFormatter.SetHashAlgorithm("SHA1");
        byte[] signedPolicyHash = rsaFormatter.CreateSignature(bufferPolicy);

        // Convert the signed policy to URL-safe base64 encoding and 
        // replace unsafe characters + = / with the safe characters - _ ~
        string strSignedPolicy = ToUrlSafeBase64String(signedPolicyHash);

        // Concatenate the URL, the timestamp, the signature, 
        // and the key pair ID to form the signed URL.
        return urlString + 
            "?Expires=" + 
            strExpiration + 
            "&Signature=" + 
            strSignedPolicy + 
            "&Key-Pair-Id=" + 
            keyId;
    }
}
```

## Metodo di firma di policy personalizzata in C\$1
<a name="custom-policy-signed-url-net"></a>

Il codice C\$1 esposto di seguito crea un URL firmato che utilizza una policy personalizzata mediante le seguenti operazioni:

1. Crea una dichiarazione di policy.

1. Codifica in base64 la dichiarazione di policy e sostituisce caratteri speciali per rendere sicura la stringa da utilizzare come parametro di richiesta URL.

1. Esegue l'hash della dichiarazione politica utilizzando SHA1 e crittografa il risultato utilizzando RSA e la chiave privata la cui chiave pubblica corrispondente si trova in un gruppo di chiavi attendibile.

1. Codifica in base64 la dichiarazione di policy con hash e sostituisce i caratteri speciali per rendere sicura la stringa da utilizzare come parametro di richiesta URL.

1. Concatena i valori.

Per l'implementazione completa, vedi l'esempio in [Signature Code in C\$1](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/samples/AWS_PrivateCF_Distributions.zip). 

**Nota**  
`keyId`Viene restituito quando si carica una chiave pubblica su. CloudFront Per ulteriori informazioni, consulta ![\[6\]](http://docs.aws.amazon.com/it_it/AmazonCloudFront/latest/DeveloperGuide/images/callouts/6.png)[ &Key-Pair-Id](private-content-creating-signed-url-canned-policy.md).

**Example : metodo di firma di policy personalizzato in C\$1**  <a name="ExampleCustomPolicySigningMethod-CSharp"></a>

```
public static string ToUrlSafeBase64String(byte[] bytes)
{
    return System.Convert.ToBase64String(bytes)
        .Replace('+', '-')
        .Replace('=', '_')
        .Replace('/', '~');
}

public static string CreateCustomPrivateURL(string urlString, 
    string durationUnits, string durationNumber, string startIntervalFromNow, 
    string ipaddress, string pathToPolicyStmnt, string pathToPrivateKey, 
    string keyId)
{
    // args[] 0-thisMethod, 1-resourceUrl, 2-seconds-minutes-hours-days 
    // to expiration, 3-numberOfPreviousUnits, 4-starttimeFromNow, 
    // 5-ip_address, 6-pathToPolicyStmt, 7-pathToPrivateKey, 8-keyId

    TimeSpan timeSpanInterval = GetDuration(durationUnits, durationNumber);
    TimeSpan timeSpanToStart = GetDurationByUnits(durationUnits, 
        startIntervalFromNow);
    if (null == timeSpanToStart) 
        return "Invalid duration units." + 
            "Valid options: seconds, minutes, hours, or days";
            
    string strPolicy = CreatePolicyStatement(
        pathToPolicyStmnt, urlString, DateTime.Now.Add(timeSpanToStart), 
        DateTime.Now.Add(timeSpanInterval), ipaddress);

    // Read the policy into a byte buffer.
    byte[] bufferPolicy = Encoding.ASCII.GetBytes(strPolicy);

    // Convert the policy statement to URL-safe base64 encoding and 
    // replace unsafe characters + = / with the safe characters - _ ~

    string urlSafePolicy = ToUrlSafeBase64String(bufferPolicy);

    // Initialize the SHA1CryptoServiceProvider object and hash the policy data.
    byte[] bufferPolicyHash;
    using (SHA1CryptoServiceProvider cryptoSHA1 = 
        new SHA1CryptoServiceProvider())
    {
        bufferPolicyHash = cryptoSHA1.ComputeHash(bufferPolicy);

        // Initialize the RSACryptoServiceProvider object.
        RSACryptoServiceProvider providerRSA = new RSACryptoServiceProvider();
        XmlDocument xmlPrivateKey = new XmlDocument();

        // Load your private key, which you created by converting your 
        // .pem file to the XML format that the .NET framework uses.  
        // Several tools are available. 
        xmlPrivateKey.Load(pathToPrivateKey);

        // Format the RSACryptoServiceProvider providerRSA 
        // and create the signature.
        providerRSA.FromXmlString(xmlPrivateKey.InnerXml);
        RSAPKCS1SignatureFormatter RSAFormatter = 
            new RSAPKCS1SignatureFormatter(providerRSA);
        RSAFormatter.SetHashAlgorithm("SHA1");
        byte[] signedHash = RSAFormatter.CreateSignature(bufferPolicyHash);

        // Convert the signed policy to URL-safe base64 encoding and 
        // replace unsafe characters + = / with the safe characters - _ ~
        string strSignedPolicy = ToUrlSafeBase64String(signedHash);

        return urlString + 
            "?Policy=" + 
            urlSafePolicy + 
            "&Signature=" + 
            strSignedPolicy + 
            "&Key-Pair-Id=" + 
            keyId;
    }
}
```

## Metodi utility per generazione di firme
<a name="utility-methods-signed-url"></a>

I seguenti metodi ottengono la dichiarazione di policy da un file e analizzano gli intervalli di tempo per la generazione di firme.

**Example : metodi di utilità per generazione di firme**  <a name="UtilityMethodsForSignatureGeneration"></a>

```
public static string CreatePolicyStatement(string policyStmnt, 
   string resourceUrl, 
   DateTime startTime, 
   DateTime endTime, 
   string ipAddress)
   
{
   // Create the policy statement.
   FileStream streamPolicy = new FileStream(policyStmnt, FileMode.Open, FileAccess.Read);
   using (StreamReader reader = new StreamReader(streamPolicy))
   {
      string strPolicy = reader.ReadToEnd();

      TimeSpan startTimeSpanFromNow = (startTime - DateTime.Now);
      TimeSpan endTimeSpanFromNow = (endTime - DateTime.Now);
      TimeSpan intervalStart = 
         (DateTime.UtcNow.Add(startTimeSpanFromNow)) - 
         new DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc);
      TimeSpan intervalEnd = 
         (DateTime.UtcNow.Add(endTimeSpanFromNow)) - 
         new DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc);

      int startTimestamp = (int)intervalStart.TotalSeconds; // START_TIME
      int endTimestamp = (int)intervalEnd.TotalSeconds;  // END_TIME

      if (startTimestamp > endTimestamp)
         return "Error!";

      // Replace variables in the policy statement.
      strPolicy = strPolicy.Replace("RESOURCE", resourceUrl);
      strPolicy = strPolicy.Replace("START_TIME", startTimestamp.ToString());
      strPolicy = strPolicy.Replace("END_TIME", endTimestamp.ToString());
      strPolicy = strPolicy.Replace("IP_ADDRESS", ipAddress);
      strPolicy = strPolicy.Replace("EXPIRES", endTimestamp.ToString());
      return strPolicy;
   }   
}

public static TimeSpan GetDuration(string units, string numUnits)
{
   TimeSpan timeSpanInterval = new TimeSpan();
   switch (units)
   {
      case "seconds":
         timeSpanInterval = new TimeSpan(0, 0, 0, int.Parse(numUnits));
         break;
      case "minutes":
         timeSpanInterval = new TimeSpan(0, 0, int.Parse(numUnits), 0);
         break;
      case "hours":
         timeSpanInterval = new TimeSpan(0, int.Parse(numUnits), 0 ,0);
         break;
      case "days":
         timeSpanInterval = new TimeSpan(int.Parse(numUnits),0 ,0 ,0);
         break;
      default:
         Console.WriteLine("Invalid time units;" + 
            "use seconds, minutes, hours, or days");
         break;
   }
   return timeSpanInterval;
}

private static TimeSpan GetDurationByUnits(string durationUnits, 
   string startIntervalFromNow)
{
   switch (durationUnits)
   {
      case "seconds":
         return new TimeSpan(0, 0, int.Parse(startIntervalFromNow));
      case "minutes":
         return new TimeSpan(0, int.Parse(startIntervalFromNow), 0);
      case "hours":
         return new TimeSpan(int.Parse(startIntervalFromNow), 0, 0);
      case "days":
         return new TimeSpan(int.Parse(startIntervalFromNow), 0, 0, 0);
      default:
         return new TimeSpan(0, 0, 0, 0);
   }
}

public static string CopyExpirationTimeFromPolicy(string policyStatement)
{
   int startExpiration = policyStatement.IndexOf("EpochTime");
   string strExpirationRough = policyStatement.Substring(startExpiration + 
      "EpochTime".Length);
   char[] digits = { '0', '1', '2', '3', '4', '5', '6', '7', '8', '9' };
         
   List<char> listDigits = new List<char>(digits);
   StringBuilder buildExpiration = new StringBuilder(20);
         
   foreach (char c in strExpirationRough)
   {
      if (listDigits.Contains(c))
         buildExpiration.Append(c);
   }
   return buildExpiration.ToString();   
}
```

Consulta anche
+ [Creazione di una firma per URL utilizzando Perl](CreateURLPerl.md)
+ [Creazione di una firma per URL utilizzando PHP](CreateURL_PHP.md)
+ [Creazione di una firma per URL utilizzando Java](CFPrivateDistJavaDevelopment.md)

# Creazione di una firma per URL utilizzando Java
<a name="CFPrivateDistJavaDevelopment"></a>

Oltre al seguente esempio di codice, è possibile utilizzare [la classe di `CloudFrontUrlSigner` utilità nella AWS SDK per Java (versione 1)](https://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/cloudfront/CloudFrontUrlSigner.html) per creare [CloudFront signed URLs](private-content-signed-urls.md).

Per altri esempi, consulta [Creare cookie firmati URLs e cookie utilizzando un AWS SDK nella libreria](https://docs.aws.amazon.com/code-library/latest/ug/cloudfront_example_cloudfront_CloudFrontUtilities_section.html) di codici *AWS SDK Code Examples.* 

**Note**  
La creazione di un URL firmato è solo una parte del processo di [pubblicazione di contenuti privati](PrivateContent.md). CloudFront Per ulteriori informazioni sull'intero processo, consulta [Usa firmato URLs](private-content-signed-urls.md).
Nella `Signature.getInstance` chiamata, nota che `SHA1withRSA` può essere sostituito con`SHA256withRSA`.

**Example Metodi di policy e di crittografia di firme Java**  <a name="ExampleJavaPolicyAndSignatureEncryptionMethods"></a>

```
package org.example;

import java.time.Instant;
import java.time.temporal.ChronoUnit;
import software.amazon.awssdk.services.cloudfront.CloudFrontUtilities;
import software.amazon.awssdk.services.cloudfront.model.CannedSignerRequest;
import software.amazon.awssdk.services.cloudfront.url.SignedUrl;

public class Main {

    public static void main(String[] args) throws Exception {
        CloudFrontUtilities cloudFrontUtilities = CloudFrontUtilities.create();
        Instant expirationDate = Instant.now().plus(7, ChronoUnit.DAYS);
        String resourceUrl = "https://a1b2c3d4e5f6g7.cloudfront.net";
        String keyPairId = "K1UA3WV15I7JSD";
        CannedSignerRequest cannedRequest = CannedSignerRequest.builder()
                .resourceUrl(resourceUrl)
                .privateKey(new java.io.File("/path/to/private_key.pem").toPath())
                .keyPairId(keyPairId)
                .expirationDate(expirationDate)
                .build();
        SignedUrl signedUrl = cloudFrontUtilities.getSignedUrlWithCannedPolicy(cannedRequest);
        String url = signedUrl.url();
        System.out.println(url);

    }
}
```

**Example Esempio di firma di policy predefinite con SHA256 in Java**  <a name="ExampleJavaPolicySHA256AndSignatureEncryptionMethods"></a>

```
package org.example;

import java.io.File;
import java.nio.file.Files;
import java.security.KeyFactory;
import java.security.PrivateKey;
import java.security.Signature;
import java.security.spec.PKCS8EncodedKeySpec;
import java.time.Instant;
import java.time.temporal.ChronoUnit;
import java.util.Base64;

public class Main {

    public static void main(String[] args) throws Exception {
        String resourceUrl = "https://a1b2c3d4e5f6g7.cloudfront.net/myfile.html";
        String keyPairId = "K1UA3WV15I7JSD";
        Instant expiration = Instant.now().plus(7, ChronoUnit.DAYS);
        PrivateKey privateKey = loadPrivateKey("/path/to/private_key.der");

        System.out.println(createSignedUrl(resourceUrl, keyPairId, privateKey, expiration, "SHA1"));
        System.out.println(createSignedUrl(resourceUrl, keyPairId, privateKey, expiration, "SHA256"));
    }

    static String createSignedUrl(String resourceUrl, String keyPairId,
                                  PrivateKey privateKey, Instant expiration,
                                  String hashAlgorithm) throws Exception {
        long epochSeconds = expiration.getEpochSecond();

        String policy = "{\"Statement\":[{\"Resource\":\"" + resourceUrl
                + "\",\"Condition\":{\"DateLessThan\":{\"AWS:EpochTime\":" + epochSeconds + "}}}]}";

        String jcaAlgorithm = hashAlgorithm.equals("SHA256") ? "SHA256withRSA" : "SHA1withRSA";

        Signature sig = Signature.getInstance(jcaAlgorithm);
        sig.initSign(privateKey);
        sig.update(policy.getBytes("UTF-8"));
        String signature = base64UrlEncode(sig.sign());

        String url = resourceUrl
                + (resourceUrl.contains("?") ? "&" : "?")
                + "Expires=" + epochSeconds
                + "&Signature=" + signature
                + "&Key-Pair-Id=" + keyPairId;

        if (hashAlgorithm.equals("SHA256")) {
            url += "&Hash-Algorithm=SHA256";
        }

        return url;
    }

    static String base64UrlEncode(byte[] bytes) {
        return Base64.getEncoder().encodeToString(bytes)
                .replace('+', '-')
                .replace('=', '_')
                .replace('/', '~');
    }

    static PrivateKey loadPrivateKey(String path) throws Exception {
        byte[] keyBytes = Files.readAllBytes(new File(path).toPath());
        return KeyFactory.getInstance("RSA")
                .generatePrivate(new PKCS8EncodedKeySpec(keyBytes));
    }
}
```

Consulta anche:
+ [Creazione di una firma per URL utilizzando Perl](CreateURLPerl.md)
+ [Creazione di una firma per URL utilizzando PHP](CreateURL_PHP.md)
+ [Crea una firma per URL utilizzando C\$1 e .NET Framework](CreateSignatureInCSharp.md)

# Limita l'accesso a un' AWS origine
<a name="private-content-restricting-access-to-origin"></a>

Puoi configurare CloudFront alcune AWS origini in modo da offrire i seguenti vantaggi:
+ Limita l'accesso all' AWS origine in modo che non sia accessibile pubblicamente.
+ Garantisce che gli spettatori (utenti) possano accedere al contenuto dell' AWS origine solo tramite la distribuzione specificata CloudFront . Ciò impedisce agli spettatori di accedere al contenuto direttamente dall'origine o tramite una distribuzione CloudFront involontaria.

A tale scopo, configura CloudFront l'invio di richieste autenticate all' AWS origine e configura l' AWS origine per consentire l'accesso solo alle richieste autenticate da. CloudFront Per ulteriori informazioni, consulta gli argomenti seguenti per i tipi di AWS origini compatibili.

**Topics**
+ [

# Limita l'accesso a un' AWS Elemental MediaPackage origine v2
](private-content-restricting-access-to-mediapackage.md)
+ [

# Limita l'accesso a un' AWS Elemental MediaStore origine
](private-content-restricting-access-to-mediastore.md)
+ [

# Limita l'accesso all'origine dell'URL di una AWS Lambda funzione
](private-content-restricting-access-to-lambda.md)
+ [

# Limitazione dell’accesso a un’origine Amazon S3
](private-content-restricting-access-to-s3.md)
+ [

# Limitazione dell’accesso con VPC Origins
](private-content-vpc-origins.md)
+ [

# Limita l'accesso all'origine di un punto di accesso multiregionale Amazon S3
](private-content-restricting-access-to-s3-mrap.md)

# Limita l'accesso a un' AWS Elemental MediaPackage origine v2
<a name="private-content-restricting-access-to-mediapackage"></a>

CloudFront fornisce il *controllo dell'accesso all'origine* (OAC) per limitare l'accesso a un'origine v2. MediaPackage 

**Nota**  
CloudFront OAC supporta solo la versione 2. MediaPackage MediaPackage la v1 non è supportata.

**Topics**
+ [

## Creazione di un nuovo OAC
](#create-oac-overview-mediapackage)
+ [

## Impostazioni avanzate per il controllo dell’accesso all’origine
](#oac-advanced-settings-mediapackage)

## Creazione di un nuovo OAC
<a name="create-oac-overview-mediapackage"></a>

Completa i passaggi descritti nei seguenti argomenti per configurare un nuovo OAC in. CloudFront

**Topics**
+ [

### Prerequisiti
](#oac-prerequisites-mediapackage)
+ [

### Concedi CloudFront l'autorizzazione per accedere all'origine v2 MediaPackage
](#oac-permission-to-access-mediapackage)
+ [

### Creazione dell’OAC
](#create-oac-mediapackage)

### Prerequisiti
<a name="oac-prerequisites-mediapackage"></a>

Prima di creare e configurare OAC, è necessario disporre di una CloudFront distribuzione con origine MediaPackage v2. Per ulteriori informazioni, consulta [Usa un MediaStore contenitore o un canale MediaPackage](DownloadDistS3AndCustomOrigins.md#concept_AWS_Media).

### Concedi CloudFront l'autorizzazione per accedere all'origine v2 MediaPackage
<a name="oac-permission-to-access-mediapackage"></a>

Prima di creare un OAC o configurarlo in una CloudFront distribuzione, assicurati che CloudFront disponga dell'autorizzazione per accedere all'origine MediaPackage v2. Esegui questa operazione dopo aver creato una CloudFront distribuzione, ma prima di aggiungere l'OAC all'origine MediaPackage v2 nella configurazione di distribuzione.

Utilizza una policy IAM per consentire al CloudFront service principal (`cloudfront.amazonaws.com`) di accedere all'origine. L'`Condition`elemento della policy consente di accedere CloudFront all'origine MediaPackage v2 *solo* quando la richiesta è per conto della CloudFront distribuzione che contiene l'origine MediaPackage v2. Questa è la distribuzione con l'origine MediaPackage v2 a cui desideri aggiungere OAC.

**Example : policy IAM che consente l'accesso in sola lettura per una CloudFront distribuzione con OAC abilitato**  
La seguente politica consente alla CloudFront distribuzione (`E1PDK09ESKHJWT`) l'accesso all'origine v2. MediaPackage L’origine è l’ARN specificato per l’elemento `Resource`.    
****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowCloudFrontServicePrincipal",
            "Effect": "Allow",
            "Principal": {"Service": "cloudfront.amazonaws.com"},
            "Action": "mediapackagev2:GetObject",
            "Resource": "arn:aws:mediapackagev2:us-east-1:123456789012:channelGroup/channel-group-name/channel/channel-name/originEndpoint/origin_endpoint_name",
            "Condition": {
                "StringEquals": {"AWS:SourceArn": "arn:aws:cloudfront::123456789012:distribution/E1PDK09ESKHJWT"}
            }
        }
    ]
}
```

**Note**  
Se hai abilitato la funzionalità MQAR e il controllo di accesso origine (OAC), aggiungi l’azione `mediapackagev2:GetHeadObject` alla policy IAM. MQAR richiede questa autorizzazione per inviare `HEAD` richieste all'origine MediaPackage v2. Per ulteriori informazioni su MQAR, consulta [MQAR (Media Quality-Aware Resiliency)](media-quality-score.md).
Se crei una distribuzione che non dispone dell'autorizzazione per la tua origine MediaPackage v2, puoi scegliere **Copy policy** dalla CloudFront console e quindi scegliere **Update** endpoint permissions. Puoi quindi collegare l’autorizzazione copiata all’endpoint. Per ulteriori informazioni, consulta [Campi della policy dell’endpoint](https://docs.aws.amazon.com/mediapackage/latest/userguide/endpoints-policy.html) nella *Guida per l’utente di AWS Elemental MediaPackage *. 

### Creazione dell’OAC
<a name="create-oac-mediapackage"></a>

Per creare un OAC, puoi utilizzare l' Console di gestione AWS, CloudFormation, o l'API AWS CLI. CloudFront 

------
#### [ Console ]

**Come creare un OAC**

1. Accedi Console di gestione AWS e apri la CloudFront console all'indirizzo[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Nel pannello di navigazione a sinistra, scegli **Accesso origine**.

1. Scegli **Crea un'impostazione di controllo**.

1. Nel modulo **Crea nuovo OAC**, procedi come indicato di seguito:

   1. Immetti un **Nome** e (facoltativamente) una **Descrizione** per l’OAC.

   1. Per **Comportamento di firma**, si consiglia di lasciare l’impostazione predefinita (**Richieste di firma (consigliato)**). Per ulteriori informazioni, consulta [Impostazioni avanzate per il controllo dell’accesso all’origine](#oac-advanced-settings-mediapackage).

1. Per il **tipo Origin**, scegli **MediaPackage V2**. 

1. Scegli **Create** (Crea).
**Suggerimento**  
Dopo aver creato l’OAC, prendi nota del **Nome**. In questa procedura, eseguire le seguenti operazioni:

**Per aggiungere un OAC a un'origine MediaPackage v2 in una distribuzione**

1. Apri la CloudFront console all'indirizzo. [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home)

1. Scegli una distribuzione con un'origine MediaPackage V2 a cui desideri aggiungere l'OAC, quindi scegli la scheda **Origins**.

1. **Seleziona l'origine MediaPackage v2 a cui desideri aggiungere l'OAC, quindi scegli Modifica.**

1. Seleziona **HTTPS solo** per il **protocollo** di origine.

1. Nel menu a discesa **Controllo di accesso origine**, scegli il nome OAC che desideri utilizzare.

1. Scegli **Save changes** (Salva modifiche).

La distribuzione inizia a essere distribuita in tutte le edge location. CloudFront Quando una edge location riceve la nuova configurazione, firma tutte le richieste che invia all'origine MediaPackage v2.

------
#### [ CloudFormation ]

Per creare un OAC con CloudFormation, usa il tipo di `AWS::CloudFront::OriginAccessControl` risorsa. L'esempio seguente mostra la sintassi del CloudFormation modello, in formato YAML, per la creazione di un OAC.

```
Type: AWS::CloudFront::OriginAccessControl
Properties: 
  OriginAccessControlConfig: 
      Description: An optional description for the origin access control
      Name: ExampleOAC
      OriginAccessControlOriginType: mediapackagev2
      SigningBehavior: always
      SigningProtocol: sigv4
```

*Per ulteriori informazioni, vedere [AWS::CloudFront::OriginAccessControl](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-cloudfront-originaccesscontrol.html) nella Guida per l'utente.AWS CloudFormation *

------
#### [ CLI ]

Per creare un controllo di accesso all'origine con AWS Command Line Interface (AWS CLI), utilizzate il **aws cloudfront create-origin-access-control** comando. È possibile utilizzare un file di input per fornire i parametri di input del comando, anziché specificare ogni singolo parametro come input della riga di comando.

**Per creare un controllo di accesso all'origine (CLI con file di input)**

1. Per creare un file denominato `origin-access-control.yaml`, utilizza il comando seguente. Tale file contiene tutti i parametri di input per il comando **create-origin-access-control**.

   ```
   aws cloudfront create-origin-access-control --generate-cli-skeleton yaml-input > origin-access-control.yaml
   ```

1. Aprire il file `origin-access-control.yaml` appena creato. Modifica il file per aggiungere un nome per l'OAC, una descrizione (opzionale) e modificare `SigningBehavior` in `always`. Quindi salvare il file.

   Per ulteriori informazioni sulle impostazioni OAC, consultare [Impostazioni avanzate per il controllo dell’accesso all’origine](#oac-advanced-settings-mediapackage).

1. Utilizzare il comando seguente per creare il controllo di accesso origine utilizzando i parametri di input dal file `origin-access-control.yaml`.

   ```
   aws cloudfront create-origin-access-control --cli-input-yaml file://origin-access-control.yaml
   ```

   Prendere nota del valore `Id` nell'output del comando. È necessario per aggiungere l'OAC a un'origine MediaPackage v2 in una CloudFront distribuzione.

**Per collegare un OAC a un'origine MediaPackage v2 in una distribuzione esistente (CLI con file di input)**

1. Usa il comando seguente per salvare la configurazione di distribuzione per la CloudFront distribuzione a cui desideri aggiungere l'OAC. La distribuzione deve avere un'origine MediaPackage v2.

   ```
   aws cloudfront get-distribution-config --id <CloudFront distribution ID> --output yaml > dist-config.yaml
   ```

1. Aprire il file denominato `dist-config.yaml` appena creato. Modifica il file apportando le seguenti modifiche:
   + Nell'oggetto `Origins`, aggiungi l'ID dell'OAC al campo a cui è stato assegnato il nome `OriginAccessControlId`.
   + Rimuovi il valore dal campo denominato `OriginAccessIdentity`, se esiste.
   + Rinominare il campo `ETag` in `IfMatch`, ma non modificare il valore del campo.

   Salvare il file al termine.

1. Utilizzare il comando seguente per aggiornare la distribuzione e utilizzare il controllo di accesso origine.

   ```
   aws cloudfront update-distribution --id <CloudFront distribution ID> --cli-input-yaml file://dist-config.yaml
   ```

La distribuzione inizia a essere distribuita in tutte le CloudFront edge location. Quando una edge location riceve la nuova configurazione, firma tutte le richieste che invia all'origine MediaPackage v2.

------
#### [ API ]

Per creare un OAC con l' CloudFront API, usa. [CreateOriginAccessControl](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateOriginAccessControl.html) Per ulteriori informazioni sui campi specificati in questa chiamata API, consulta la documentazione di riferimento sull'API per il tuo AWS SDK o altro client API.

Dopo aver creato un OAC, puoi collegarlo a un'origine MediaPackage v2 in una distribuzione, utilizzando una delle seguenti chiamate API:
+ Per collegarlo a una distribuzione esistente, usa. [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)
+ Per collegarlo a una nuova distribuzione, usa [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html).

Per entrambe queste chiamate API, fornire l’ID di OAC nel campo `OriginAccessControlId`, all’interno di un’origine. Per ulteriori informazioni sugli altri campi specificati in queste chiamate API, consulta [Riferimento a tutte le impostazioni di distribuzione](distribution-web-values-specify.md) la documentazione di riferimento sull'API per il tuo AWS SDK o altro client API.

------

## Impostazioni avanzate per il controllo dell’accesso all’origine
<a name="oac-advanced-settings-mediapackage"></a>

La funzionalità CloudFront OAC include impostazioni avanzate destinate solo a casi d'uso specifici. Usa le impostazioni consigliate a meno che tu non abbia una necessità specifica per le impostazioni avanzate.

OAC contiene un'impostazione denominata **Signing behavior** (nella console) o `SigningBehavior` (nell'API, nella CLI e). CloudFormation Questa impostazione offre le seguenti opzioni:

**Firma sempre le richieste di origine (impostazione consigliata)**  
Si consiglia di utilizzare questa impostazione, denominata **Richieste di firma (consigliata)** nella console, oppure `always` nell'API, nell'interfaccia a riga di comando e CloudFormation. Con questa impostazione, firma CloudFront sempre tutte le richieste che invia all'origine MediaPackage v2.

**Non firmare le richieste di origine**  
Questa impostazione è denominata **Non firmare le richieste** nella console, oppure `never`nell'API, nell'interfaccia a riga di comando e CloudFormation. Usa questa impostazione per disattivare OAC per tutte le origini in tutte le distribuzioni che utilizzano questo OAC. Ciò consente di risparmiare tempo e fatica rispetto alla rimozione di un OAC da tutte le origini e le distribuzioni che lo utilizzano, uno per uno. Con questa impostazione, CloudFront non firma alcuna richiesta inviata all'origine MediaPackage v2.  
Per utilizzare questa impostazione, l'origine MediaPackage v2 deve essere accessibile pubblicamente. Se utilizzi questa impostazione con un'origine MediaPackage v2 che non è accessibile pubblicamente, non CloudFront puoi accedere all'origine. L'origine MediaPackage v2 restituisce gli errori CloudFront e li CloudFront trasmette agli spettatori. *Per ulteriori informazioni, consulta l'esempio della politica MediaPackage v2 per [le politiche e le autorizzazioni MediaPackage nella](https://docs.aws.amazon.com/mediapackage/latest/userguide/policies-permissions.html) Guida per l'utente.AWS Elemental MediaPackage *

**Non ignorare l'intestazione del visualizzatore (client) `Authorization`**  
Questa impostazione è denominata **Non sovrascrivere l'intestazione di autorizzazione**nella console, oppure `no-override` nell'API, nell'interfaccia a riga di comando e CloudFormation. Utilizzate questa impostazione quando desiderate firmare CloudFront le richieste di origine solo quando la richiesta del visualizzatore corrispondente non include un'`Authorization`intestazione. Con questa impostazione, CloudFront trasmette l'`Authorization`intestazione della richiesta del visualizzatore quando ne è presente una, ma firma la richiesta di origine (aggiungendo la propria `Authorization` intestazione) quando la richiesta del visualizzatore non include un'intestazione. `Authorization`  
Per trasmettere l'`Authorization`intestazione dalla richiesta del visualizzatore, è *necessario* aggiungere l'`Authorization`intestazione a una [politica di cache per tutti i comportamenti della cache](controlling-the-cache-key.md) che utilizzano le origini MediaPackage v2 associate a questo controllo di accesso all'origine.

# Limita l'accesso a un' AWS Elemental MediaStore origine
<a name="private-content-restricting-access-to-mediastore"></a>

CloudFront fornisce il *controllo dell'accesso all'origine* (OAC) per limitare l'accesso a un'origine. AWS Elemental MediaStore 

**Topics**
+ [

## Creazione di un nuovo controllo di accesso origine
](#create-oac-overview-mediastore)
+ [

## Impostazioni avanzate per il controllo dell’accesso all’origine
](#oac-advanced-settings-mediastore)

## Creazione di un nuovo controllo di accesso origine
<a name="create-oac-overview-mediastore"></a>

Completa i passaggi descritti nei seguenti argomenti per configurare un nuovo controllo di accesso all'origine in. CloudFront

**Topics**
+ [

### Prerequisiti
](#oac-prerequisites-mediastore)
+ [

### Concedi CloudFront l'autorizzazione per accedere all' MediaStore origine
](#oac-permission-to-access-mediastore)
+ [

### Creazione del controllo di accesso origine
](#create-oac-mediastore)

### Prerequisiti
<a name="oac-prerequisites-mediastore"></a>

Prima di creare e configurare il controllo di accesso all'origine, è necessario disporre di una CloudFront distribuzione con un' MediaStore origine. 

### Concedi CloudFront l'autorizzazione per accedere all' MediaStore origine
<a name="oac-permission-to-access-mediastore"></a>

Prima di creare un controllo di accesso all'origine o di configurarlo in una CloudFront distribuzione, assicurati che CloudFront disponga dell'autorizzazione per accedere all' MediaStore origine. Fatelo dopo aver creato una CloudFront distribuzione, ma prima di aggiungere l'OAC all' MediaStoreorigine nella configurazione di distribuzione. 

Utilizza una politica del MediaStore contenitore per consentire al CloudFront service principal (`cloudfront.amazonaws.com`) di accedere all'origine. Utilizzate un `Condition` elemento della policy per consentire l'accesso CloudFront al MediaStore contenitore solo quando la richiesta è per conto della CloudFront distribuzione che contiene l' MediaStore origine. Questa è la distribuzione con l' MediaStore origine a cui vuoi aggiungere OAC.

Di seguito sono riportati alcuni esempi di politiche relative ai MediaStore contenitori che consentono a una CloudFront distribuzione di accedere a un' MediaStore origine.

**Example MediaStore politica dei contenitori che consente l'accesso in sola lettura per una CloudFront distribuzione con OAC abilitato**    
****  

```
{
        "Version":"2012-10-17",		 	 	 
        "Statement": [
            {
                "Sid": "AllowCloudFrontServicePrincipalReadOnly",
                "Effect": "Allow",
                "Principal": {
                  "Service": "cloudfront.amazonaws.com"
                },
                "Action": [ 
                  "mediastore:GetObject"
                ],
                "Resource": "arn:aws:mediastore:us-east-1:111122223333:container/<container name>/*",
                "Condition": {
                    "StringEquals": {
                      "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/CloudFront-distribution-ID"
                    },
                    "Bool": {
                      "aws:SecureTransport": "true"
                    }
                }
            }
        ]
}
```

**Example MediaStore politica del contenitore che consente l'accesso in lettura e scrittura per una CloudFront distribuzione con OAC abilitato**    
****  

```
{
        "Version":"2012-10-17",		 	 	 
        "Statement": [
            {
                "Sid": "AllowCloudFrontServicePrincipalReadWrite",
                "Effect": "Allow",
                "Principal": {
                  "Service": "cloudfront.amazonaws.com"
                },
                "Action": [ 
                  "mediastore:GetObject",
                  "mediastore:PutObject"
                ],
                "Resource": "arn:aws:mediastore:us-east-1:111122223333:container/container-name/*",
                "Condition": {
                    "StringEquals": {
                      "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/CloudFront-distribution-ID"
                    },
                    "Bool": {
                      "aws:SecureTransport": "true"
                    }
                }
            }
        ]
}
```

**Nota**  
Per consentire l'accesso in scrittura, è necessario configurare **i metodi HTTP consentiti** da includere `PUT` nelle impostazioni di comportamento della CloudFront distribuzione.

### Creazione del controllo di accesso origine
<a name="create-oac-mediastore"></a>

Per creare un OAC, puoi utilizzare Console di gestione AWS, CloudFormation AWS CLI, the o l' CloudFrontAPI.

------
#### [ Console ]

**Per creare un controllo di accesso all'origine**

1. Accedi Console di gestione AWS e apri la CloudFront console all'indirizzo[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Nel pannello di navigazione a sinistra, scegli **Accesso origine**.

1. Scegli **Crea un'impostazione di controllo**.

1. Nel modulo **Crea un'impostazione di controllo**, effettua le seguenti operazioni:

   1. Nel riquadro **Dettagli**, inserisci un **Nome** e (facoltativamente) una **Descrizione** per il controllo degli accessi all'origine.

   1. Nel riquadro **Impostazioni**, si consiglia di mantenere l'impostazione predefinita (**Richieste di firma (consigliato)**). Per ulteriori informazioni, consulta [Impostazioni avanzate per il controllo dell’accesso all’origine](#oac-advanced-settings-mediastore).

1. Scegli MediaStore dal menu a discesa del **tipo di origine**.

1. Scegli **Create** (Crea).

   Dopo aver creato l'OAC, prendere nota del **Nome**. In questa procedura, eseguire le seguenti operazioni:

**Per aggiungere un controllo di accesso all'origine a un' MediaStore origine in una distribuzione**

1. Apri la CloudFront console all'indirizzo[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Scegli una distribuzione con un' MediaStore origine a cui desideri aggiungere l'OAC, quindi scegli la scheda **Origins**.

1. **Seleziona l' MediaStore origine a cui vuoi aggiungere l'OAC, quindi scegli Modifica.**

1. Seleziona **HTTPS solo** per il **protocollo** di origine.

1. Nel menu a discesa **Controllo degli accessi origine**, scegliere l'OAC che desideri utilizzare.

1. Scegli **Save changes** (Salva modifiche).

La distribuzione inizia a essere distribuita in tutte le CloudFront edge location. Quando un'edge location riceve la nuova configurazione, firma tutte le richieste che invia all'origine del MediaStore bucket.

------
#### [ CloudFormation ]

Per creare un controllo di accesso all'origine (OAC) con CloudFormation, usa il tipo di `AWS::CloudFront::OriginAccessControl` risorsa. L'esempio seguente mostra la sintassi del CloudFormation modello, in formato YAML, per creare un controllo di accesso all'origine.

```
Type: AWS::CloudFront::OriginAccessControl
Properties: 
  OriginAccessControlConfig: 
      Description: An optional description for the origin access control
      Name: ExampleOAC
      OriginAccessControlOriginType: mediastore
      SigningBehavior: always
      SigningProtocol: sigv4
```

*Per ulteriori informazioni, consulta [AWS::CloudFront::OriginAccessControl nella Guida](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-cloudfront-originaccesscontrol.html) per l'AWS CloudFormation utente.*

------
#### [ CLI ]

Per creare un controllo di accesso all'origine con AWS Command Line Interface (AWS CLI), utilizzate il **aws cloudfront create-origin-access-control** comando. È possibile utilizzare un file di input per fornire i parametri di input del comando, anziché specificare ogni singolo parametro come input della riga di comando.

**Per creare un controllo di accesso all'origine (CLI con file di input)**

1. Per creare un file denominato `origin-access-control.yaml`, utilizza il comando seguente. Tale file contiene tutti i parametri di input per il comando **create-origin-access-control**.

   ```
   aws cloudfront create-origin-access-control --generate-cli-skeleton yaml-input > origin-access-control.yaml
   ```

1. Aprire il file `origin-access-control.yaml` appena creato. Modifica il file per aggiungere un nome per l'OAC, una descrizione (opzionale) e modificare `SigningBehavior` in `always`. Quindi salvare il file.

   Per ulteriori informazioni sulle impostazioni OAC, consultare [Impostazioni avanzate per il controllo dell’accesso all’origine](#oac-advanced-settings-mediastore).

1. Utilizzare il comando seguente per creare il controllo di accesso origine utilizzando i parametri di input dal file `origin-access-control.yaml`.

   ```
   aws cloudfront create-origin-access-control --cli-input-yaml file://origin-access-control.yaml
   ```

   Prendere nota del valore `Id` nell'output del comando. È necessario per aggiungere l'OAC a un' MediaStore origine in una CloudFront distribuzione.

**Per collegare un OAC a un' MediaStore origine in una distribuzione esistente (CLI con file di input)**

1. Utilizzate il comando seguente per salvare la configurazione di distribuzione per la CloudFront distribuzione a cui desiderate aggiungere l'OAC. La distribuzione deve avere un' MediaStoreorigine.

   ```
   aws cloudfront get-distribution-config --id <CloudFront distribution ID> --output yaml > dist-config.yaml
   ```

1. Aprire il file denominato `dist-config.yaml` appena creato. Modifica il file apportando le seguenti modifiche:
   + Nell'oggetto `Origins`, aggiungi l'ID dell'OAC al campo a cui è stato assegnato il nome `OriginAccessControlId`.
   + Rimuovi il valore dal campo denominato `OriginAccessIdentity`, se esiste.
   + Rinominare il campo `ETag` in `IfMatch`, ma non modificare il valore del campo.

   Salvare il file al termine.

1. Utilizzare il comando seguente per aggiornare la distribuzione e utilizzare il controllo di accesso origine.

   ```
   aws cloudfront update-distribution --id <CloudFront distribution ID> --cli-input-yaml file://dist-config.yaml
   ```

La distribuzione inizia a essere distribuita in tutte le CloudFront edge location. Quando una edge location riceve la nuova configurazione, firma tutte le richieste inviate all' MediaStore origine.

------
#### [ API ]

Per creare un controllo di accesso all'origine con l' CloudFront API, usa [CreateOriginAccessControl](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateOriginAccessControl.html). Per ulteriori informazioni sui campi specificati in questa chiamata API, consulta la documentazione di riferimento sull'API per il tuo AWS SDK o altro client API.

Dopo aver creato un controllo di accesso di origine, puoi collegarlo a un' MediaStore origine in una distribuzione, utilizzando una delle seguenti chiamate API:
+ Per collegarlo a una distribuzione esistente, usa [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html).
+ Per collegarlo a una nuova distribuzione, usa [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html).

Per entrambe queste chiamate API, fornire l'ID di controllo dell'accesso origine nel campo `OriginAccessControlId`, all'interno di un'origine. Per ulteriori informazioni sugli altri campi specificati in queste chiamate API, consulta [Riferimento a tutte le impostazioni di distribuzione](distribution-web-values-specify.md) la documentazione di riferimento sull'API per il tuo AWS SDK o altro client API.

------

## Impostazioni avanzate per il controllo dell’accesso all’origine
<a name="oac-advanced-settings-mediastore"></a>

La funzionalità di controllo dell'accesso all' CloudFront origine include impostazioni avanzate destinate solo a casi d'uso specifici. Usa le impostazioni consigliate a meno che tu non abbia una necessità specifica per le impostazioni avanzate.

Origin Access Control contiene un'impostazione denominata **Signing behavior** (nella console) o `SigningBehavior` (nell'API, CLI e CloudFormation). Questa impostazione offre le seguenti opzioni:

**Firma sempre le richieste di origine (impostazione consigliata)**  
Si consiglia di utilizzare questa impostazione, denominata **Richieste di firma (consigliata)** nella console, oppure `always` nell'API, nell'interfaccia a riga di comando e CloudFormation. Con questa impostazione, firma CloudFront sempre tutte le richieste che invia all' MediaStore origine.

**Non firmare le richieste di origine**  
Questa impostazione è denominata **Non firmare le richieste** nella console, oppure `never`nell'API, nell'interfaccia a riga di comando e CloudFormation. Usa questa impostazione per disattivare il controllo dell'accesso all'origine per tutte le origini in tutte le distribuzioni che utilizzano questo controllo di accesso all'origine. Ciò consente di risparmiare tempo e fatica rispetto alla rimozione di un controllo di accesso all'origine da tutte le origini e le distribuzioni che lo utilizzano, uno per uno. Con questa impostazione, CloudFront non firma alcuna richiesta inviata all' MediaStoreorigine.  
Per utilizzare questa impostazione, l' MediaStore origine deve essere accessibile pubblicamente. Se utilizzi questa impostazione con un' MediaStore origine non accessibile pubblicamente, CloudFront non puoi accedere all'origine. L' MediaStore origine restituisce gli errori CloudFront e li CloudFront trasmette agli spettatori. Per ulteriori informazioni, consulta l'esempio di politica del MediaStore contenitore per l'[accesso pubblico in lettura tramite HTTPS](https://docs.aws.amazon.com/mediastore/latest/ug/policies-examples-public-https.html).

**Non ignorare l'intestazione del visualizzatore (client) `Authorization`**  
Questa impostazione è denominata **Non sovrascrivere l'intestazione di autorizzazione**nella console, oppure `no-override` nell'API, nell'interfaccia a riga di comando e CloudFormation. Utilizza questa impostazione quando desideri firmare CloudFront le richieste di origine solo quando la richiesta del visualizzatore corrispondente non include un'`Authorization`intestazione. Con questa impostazione, CloudFront trasmette l'`Authorization`intestazione della richiesta del visualizzatore quando ne è presente una, ma firma la richiesta di origine (aggiungendo la propria `Authorization` intestazione) quando la richiesta del visualizzatore non include un'intestazione. `Authorization`  
Per trasmettere l'`Authorization`intestazione dalla richiesta del visualizzatore, è *necessario* aggiungere l'`Authorization`intestazione a una [politica di cache per tutti i comportamenti della cache](controlling-the-cache-key.md) che utilizzano le MediaStore origini associate a questo controllo di accesso all'origine.

# Limita l'accesso all'origine dell'URL di una AWS Lambda funzione
<a name="private-content-restricting-access-to-lambda"></a>

CloudFront fornisce *il controllo dell'accesso all'origine* (OAC) per limitare l'accesso all'origine dell'URL di una funzione Lambda.

**Topics**
+ [

## Creazione di un nuovo OAC
](#create-oac-overview-lambda)
+ [

## Impostazioni avanzate per il controllo dell’accesso all’origine
](#oac-advanced-settings-lambda)
+ [

## Esempio di codice modello
](#example-template-code-lambda-oac)

## Creazione di un nuovo OAC
<a name="create-oac-overview-lambda"></a>

Completa i passaggi descritti nei seguenti argomenti per configurare un nuovo OAC in. CloudFront

**Importante**  
Se utilizzi `PUT` o `POST` metodi con l'URL della funzione Lambda, gli utenti devono calcolare il corpo SHA256 del corpo e includere il valore hash del payload del corpo della richiesta nell'`x-amz-content-sha256`intestazione quando inviano la richiesta a. CloudFront Lambda non supporta i payload non firmati.

**Topics**
+ [

### Prerequisiti
](#oac-prerequisites-lambda)
+ [

### Concedi CloudFront l'autorizzazione per accedere all'URL della funzione Lambda
](#oac-permission-to-access-lambda)
+ [

### Creazione dell’OAC
](#create-oac-lambda)

### Prerequisiti
<a name="oac-prerequisites-lambda"></a>

Prima di creare e configurare OAC, è necessario disporre di una CloudFront distribuzione con un URL della funzione Lambda come origine. Per utilizzare OAC, deve specificare `AWS_IAM` come il valore per il parametro `AuthType`. Per ulteriori informazioni, consulta [Utilizzo dell’URL di una funzione Lambda](DownloadDistS3AndCustomOrigins.md#concept_lambda_function_url).

### Concedi CloudFront l'autorizzazione per accedere all'URL della funzione Lambda
<a name="oac-permission-to-access-lambda"></a>

Prima di creare un OAC o configurarlo in una CloudFront distribuzione, assicurati che CloudFront disponga dell'autorizzazione per accedere all'URL della funzione Lambda. Esegui questa operazione dopo aver creato una CloudFront distribuzione, ma prima di aggiungere l'OAC all'URL della funzione Lambda nella configurazione di distribuzione.

**Nota**  
Per aggiornare la policy IAM per l’URL della funzione Lambda, devi usare AWS Command Line Interface (AWS CLI). La modifica della policy IAM nella console Lambda non è attualmente supportata.

Il AWS CLI comando seguente concede al CloudFront service principal (`cloudfront.amazonaws.com`) l'accesso all'URL della funzione Lambda. L'`Condition`elemento della policy consente di accedere CloudFront a Lambda *solo* quando la richiesta è per conto della CloudFront distribuzione che contiene l'URL della funzione Lambda. Questa è la distribuzione con l’origine dell’URL della funzione Lambda a cui desideri aggiungere l’OAC.

**Example : AWS CLI comando per aggiornare una policy per consentire l'accesso in sola lettura a una CloudFront distribuzione con OAC abilitato**  
I seguenti AWS CLI comandi consentono alla CloudFront distribuzione (`E1PDK09ESKHJWT`) di accedere alla tua *`FUNCTION_URL_NAME`* Lambda.

```
aws lambda add-permission \
--statement-id "AllowCloudFrontServicePrincipal" \
--action "lambda:InvokeFunctionUrl" \
--principal "cloudfront.amazonaws.com" \
--source-arn "arn:aws:cloudfront::123456789012:distribution/E1PDK09ESKHJWT" \
--function-name FUNCTION_URL_NAME
```

```
aws lambda add-permission \
--statement-id "AllowCloudFrontServicePrincipalInvokeFunction" \
--action "lambda:InvokeFunction" \
--principal "cloudfront.amazonaws.com" \
--source-arn "arn:aws:cloudfront::123456789012:distribution/E1PDK09ESKHJWT" \
--function-name FUNCTION_URL_NAME
```

**Nota**  
Se crei una distribuzione e questa non dispone dell'autorizzazione per l'URL della funzione Lambda, puoi scegliere Copia il comando **CLI dalla CloudFront console e quindi immettere questo comando** dal tuo terminale a riga di comando. Per ulteriori informazioni, consulta [Concedere alla funzione l’accesso a Servizi AWS](https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html#permissions-resource-serviceinvoke) nella *Guida per gli sviluppatori di AWS Lambda *. 

### Creazione dell’OAC
<a name="create-oac-lambda"></a>

Per creare un OAC, puoi usare l' Console di gestione AWS, CloudFormation AWS CLI, o l'API. CloudFront 

------
#### [ Console ]

**Come creare un OAC**

1. Accedi Console di gestione AWS e apri la CloudFront console all'indirizzo[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Nel pannello di navigazione a sinistra, scegli **Accesso origine**.

1. Scegli **Crea un'impostazione di controllo**.

1. Nel modulo **Crea nuovo OAC**, procedi come indicato di seguito:

   1. Immetti un **Nome** e (facoltativamente) una **Descrizione** per l’OAC.

   1. Per **Comportamento di firma**, si consiglia di lasciare l’impostazione predefinita (**Richieste di firma (consigliato)**). Per ulteriori informazioni, consulta [Impostazioni avanzate per il controllo dell’accesso all’origine](#oac-advanced-settings-lambda).

1. Per **Tipo di origine**, scegli **Lambda**. 

1. Scegli **Create** (Crea).
**Suggerimento**  
Dopo aver creato l’OAC, prendi nota del **Nome**. In questa procedura, eseguire le seguenti operazioni:

**Come aggiungere un controllo di accesso origine all’URL di una funzione Lambda in una distribuzione**

1. Apri la CloudFront console all'indirizzo[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Scegli una distribuzione con un’URL della funzione Lambda a cui desideri aggiungere l’OAC, quindi scegli la scheda **Origini**.

1. Seleziona l’URL della funzione Lambda a cui desideri aggiungere l’OAC, quindi scegli **Modifica**.

1. Seleziona **HTTPS solo** per il **protocollo** di origine.

1. Nel menu a discesa **Controllo di accesso origine**, scegli il nome OAC che desideri utilizzare.

1. Scegli **Save changes** (Salva modifiche).

La distribuzione inizia a essere distribuita in tutte le CloudFront edge location. Quando una posizione edge riceve la nuova configurazione, firma tutte le richieste che invia all’URL della funzione Lambda.

------
#### [ CloudFormation ]

Per creare un OAC con CloudFormation, usa il tipo di `AWS::CloudFront::OriginAccessControl` risorsa. L'esempio seguente mostra la sintassi del CloudFormation modello, in formato YAML, per la creazione di un OAC.

```
Type: AWS::CloudFront::OriginAccessControl
Properties: 
  OriginAccessControlConfig: 
      Description: An optional description for the origin access control
      Name: ExampleOAC
      OriginAccessControlOriginType: lambda
      SigningBehavior: always
      SigningProtocol: sigv4
```

*Per ulteriori informazioni, vedere [AWS::CloudFront::OriginAccessControl](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-cloudfront-originaccesscontrol.html) nella Guida per l'utente.AWS CloudFormation *

------
#### [ CLI ]

Per creare un controllo di accesso all'origine con AWS Command Line Interface (AWS CLI), utilizzate il **aws cloudfront create-origin-access-control** comando. È possibile utilizzare un file di input per fornire i parametri di input del comando, anziché specificare ogni singolo parametro come input della riga di comando.

**Per creare un controllo di accesso all'origine (CLI con file di input)**

1. Per creare un file denominato `origin-access-control.yaml`, utilizza il comando seguente. Tale file contiene tutti i parametri di input per il comando **create-origin-access-control**.

   ```
   aws cloudfront create-origin-access-control --generate-cli-skeleton yaml-input > origin-access-control.yaml
   ```

1. Aprire il file `origin-access-control.yaml` appena creato. Modifica il file per aggiungere un nome per l'OAC, una descrizione (opzionale) e modificare `SigningBehavior` in `always`. Quindi salvare il file.

   Per ulteriori informazioni sulle impostazioni OAC, consultare [Impostazioni avanzate per il controllo dell’accesso all’origine](#oac-advanced-settings-lambda).

1. Utilizzare il comando seguente per creare il controllo di accesso origine utilizzando i parametri di input dal file `origin-access-control.yaml`.

   ```
   aws cloudfront create-origin-access-control --cli-input-yaml file://origin-access-control.yaml
   ```

   Prendere nota del valore `Id` nell'output del comando. È necessario per aggiungere l'OAC all'URL di una funzione Lambda in CloudFront una distribuzione.

**Come collegare un OAC all’URL di una funzione Lambda in una distribuzione esistente (CLI con file di input)**

1. Usa il comando seguente per salvare la configurazione di distribuzione per la CloudFront distribuzione a cui desideri aggiungere l'OAC. La distribuzione deve avere come origine l’URL di una funzione Lambda.

   ```
   aws cloudfront get-distribution-config --id <CloudFront distribution ID> --output yaml > dist-config.yaml
   ```

1. Aprire il file denominato `dist-config.yaml` appena creato. Modifica il file apportando le seguenti modifiche:
   + Nell'oggetto `Origins`, aggiungi l'ID dell'OAC al campo a cui è stato assegnato il nome `OriginAccessControlId`.
   + Rimuovi il valore dal campo denominato `OriginAccessIdentity`, se esiste.
   + Rinominare il campo `ETag` in `IfMatch`, ma non modificare il valore del campo.

   Salvare il file al termine.

1. Utilizzare il comando seguente per aggiornare la distribuzione e utilizzare il controllo di accesso origine.

   ```
   aws cloudfront update-distribution --id <CloudFront distribution ID> --cli-input-yaml file://dist-config.yaml
   ```

La distribuzione inizia a essere distribuita in tutte le CloudFront edge location. Quando una posizione edge riceve la nuova configurazione, firma tutte le richieste che invia all’URL della funzione Lambda.

------
#### [ API ]

Per creare un OAC con l' CloudFront API, usa. [CreateOriginAccessControl](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateOriginAccessControl.html) Per ulteriori informazioni sui campi specificati in questa chiamata API, consulta la documentazione di riferimento sull'API per il tuo AWS SDK o altro client API.

Dopo aver creato un OAC, puoi collegarlo all’URL di una funzione Lambda in una distribuzione, utilizzando una delle seguenti chiamate API:
+ Per collegarlo a una distribuzione esistente, usa [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html).
+ Per collegarlo a una nuova distribuzione, usa [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html).

Per entrambe queste chiamate API, fornire l’ID di OAC nel campo `OriginAccessControlId`, all’interno di un’origine. Per ulteriori informazioni sugli altri campi specificati in queste chiamate API, consulta la documentazione di riferimento sull'API per il tuo AWS SDK o altro client API.

------

## Impostazioni avanzate per il controllo dell’accesso all’origine
<a name="oac-advanced-settings-lambda"></a>

La funzionalità CloudFront OAC include impostazioni avanzate destinate solo a casi d'uso specifici. Usa le impostazioni consigliate a meno che tu non abbia una necessità specifica per le impostazioni avanzate.

OAC contiene un'impostazione denominata **Signing behavior** (nella console) o `SigningBehavior` (nell'API, nella CLI e). CloudFormation Questa impostazione offre le seguenti opzioni:

**Firma sempre le richieste di origine (impostazione consigliata)**  
Si consiglia di utilizzare questa impostazione, denominata **Richieste di firma (consigliata)** nella console, oppure `always` nell'API, nell'interfaccia a riga di comando e CloudFormation. Con questa impostazione, firma CloudFront sempre tutte le richieste inviate all'URL della funzione Lambda.

**Non firmare le richieste di origine**  
Questa impostazione è denominata **Non firmare le richieste** nella console, oppure `never`nell'API, nell'interfaccia a riga di comando e CloudFormation. Usa questa impostazione per disattivare OAC per tutte le origini in tutte le distribuzioni che utilizzano questo OAC. Ciò consente di risparmiare tempo e fatica rispetto alla rimozione di un OAC da tutte le origini e le distribuzioni che lo utilizzano, uno per uno. Con questa impostazione, CloudFront non firma alcuna richiesta inviata all'URL della funzione Lambda.  
Per utilizzare questa impostazione, l’URL della funzione Lambda deve essere accessibile pubblicamente. Se usi questa impostazione con un URL della funzione Lambda non accessibile pubblicamente, non CloudFront puoi accedere all'origine. L'URL della funzione Lambda restituisce gli errori CloudFront e li CloudFront trasmette ai visualizzatori. Per ulteriori informazioni, consulta il [modello di sicurezza e autenticazione per la URLs funzione Lambda](https://docs.aws.amazon.com/lambda/latest/dg/urls-auth.html) nella Guida per *AWS Lambda l'*utente.

**Non ignorare l'intestazione del visualizzatore (client) `Authorization`**  
Questa impostazione è denominata **Non sovrascrivere l'intestazione di autorizzazione**nella console, oppure `no-override` nell'API, nell'interfaccia a riga di comando e CloudFormation. Utilizzate questa impostazione quando desiderate firmare CloudFront le richieste di origine solo quando la richiesta del visualizzatore corrispondente non include un'`Authorization`intestazione. Con questa impostazione, CloudFront trasmette l'`Authorization`intestazione della richiesta del visualizzatore quando ne è presente una, ma firma la richiesta di origine (aggiungendo la propria `Authorization` intestazione) quando la richiesta del visualizzatore non include un'intestazione. `Authorization`  
+ Se utilizzi questa impostazione, devi specificare la firma Signature Version 4 per l'URL della funzione Lambda anziché il nome o il CNAME della CloudFront distribuzione. Quando CloudFront inoltra l'`Authorization`intestazione dalla richiesta del visualizzatore all'URL della funzione Lambda, Lambda convalida la firma rispetto all'host del dominio URL Lambda. Se la firma non è basata sul dominio URL Lambda, l’host nella firma non corrisponderà all’host utilizzato dall’origine dell’URL Lambda. Ciò significa che la richiesta non andrà a buon fine, causando un errore di convalida della firma.
+ Per trasmettere l'`Authorization`intestazione dalla richiesta del visualizzatore, è *necessario* aggiungere l'`Authorization`intestazione a una [politica di cache per tutti i comportamenti della cache](controlling-the-cache-key.md) che utilizzano la funzione Lambda URLs associata a questo controllo di accesso all'origine.

## Esempio di codice modello
<a name="example-template-code-lambda-oac"></a>

Se la tua CloudFront origine è l'URL di una funzione Lambda associata a un OAC, puoi usare il seguente script Python per caricare file nella funzione Lambda con il metodo. `POST` 

Questo codice presuppone che l’OAC sia stato configurato con il comportamento di firma predefinito impostato su **Firma sempre le richieste di origine** e che non sia stata selezionata l’impostazione **Non sovrascrivere l’intestazione di autorizzazione**.

Questa configurazione consente all’OAC di gestire correttamente l’autorizzazione SigV4 con Lambda utilizzando il nome host Lambda. Il payload viene firmato utilizzando SigV4 dall’identità IAM autorizzata per l’URL della funzione Lambda, che è designato come tipo `IAM_AUTH`. 

Il modello mostra come gestire i valori hash del payload firmato nell’intestazione x-amz-content-sha256 per le richieste `POST` dal lato client. Nello specifico, questo modello è progettato per gestire i payload dei dati dei moduli. Il modello consente il caricamento sicuro dei file su un URL CloudFront della funzione Lambda e AWS utilizza meccanismi di autenticazione per garantire che solo le richieste autorizzate possano accedere alla funzione Lambda.

**Il codice include la seguente funzionalità:**  
Soddisfa il requisito di includere l’hash del payload nell’intestazione x-amz-content-sha256
Utilizza l'autenticazione SigV4 per un accesso sicuro Servizio AWS 
Supporta caricamenti di file utilizzando dati di moduli multiparte
Include la gestione degli errori per le eccezioni richiesta

```
import boto3
from botocore.auth import SigV4Auth
from botocore.awsrequest import AWSRequest
import requests
import hashlib
import os


def calculate_body_hash(body):
    return hashlib.sha256(body).hexdigest()


def sign_request(request, credentials, region, service):
    sigv4 = SigV4Auth(credentials, service, region)
    sigv4.add_auth(request)


def upload_file_to_lambda(cloudfront_url, file_path, region):
    # AWS credentials
    session = boto3.Session()
    credentials = session.get_credentials()

    # Prepare the multipart form-data
    boundary = "------------------------boundary"

    # Read file content
    with open(file_path, 'rb') as file:
        file_content = file.read()

    # Get the filename from the path
    filename = os.path.basename(file_path)

    # Prepare the multipart body
    body = (
        f'--{boundary}\r\n'
        f'Content-Disposition: form-data; name="file"; filename="{filename}"\r\n'
        f'Content-Type: application/octet-stream\r\n\r\n'
    ).encode('utf-8')
    body += file_content
    body += f'\r\n--{boundary}--\r\n'.encode('utf-8')

    # Calculate SHA256 hash of the entire body
    body_hash = calculate_body_hash(body)

    # Prepare headers
    headers = {
        'Content-Type': f'multipart/form-data; boundary={boundary}',
        'x-amz-content-sha256': body_hash
    }

    # Create the request
    request = AWSRequest(
        method='POST',
        url=cloudfront_url,
        data=body,
        headers=headers
    )

    # Sign the request
    sign_request(request, credentials, region, 'lambda')

    # Get the signed headers
    signed_headers = dict(request.headers)

    # Print request headers before sending
    print("Request Headers:")
    for header, value in signed_headers.items():
        print(f"{header}: {value}")

    try:
        # Send POST request with signed headers
        response = requests.post(
            cloudfront_url,
            data=body,
            headers=signed_headers
        )

        # Print response status and content
        print(f"\nStatus code: {response.status_code}")
        print("Response:", response.text)

        # Print response headers
        print("\nResponse Headers:")
        for header, value in response.headers.items():
            print(f"{header}: {value}")

    except requests.exceptions.RequestException as e:
        print(f"An error occurred: {e}")


# Usage
cloudfront_url = "https://d111111abcdef8.cloudfront.net"
file_path = r"filepath"
region = "us-east-1"  # example: "us-west-2"

upload_file_to_lambda(cloudfront_url, file_path, region)
```

# Limitazione dell’accesso a un’origine Amazon S3
<a name="private-content-restricting-access-to-s3"></a>

CloudFront offre due modi per inviare richieste autenticate a un'origine Amazon S3*: Origin Access Control (OAC) *e Origin Access** Identity (OAI). OAC consente di proteggere le origini, come Amazon S3. 

Ti *consigliamo* di utilizzare OAC perché supporta le seguenti funzionalità:
+ Tutti i bucket Amazon S3 in totale Regioni AWS, comprese le regioni opt-in lanciate dopo dicembre 2022
+ [Crittografia lato server con chiavi AWS KMS](https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html) (SSE-KMS) Amazon S3
+ Richieste dinamiche (`PUT` e `DELETE`) su Amazon S3

OAI non supporta queste funzionalità o richiede soluzioni alternative aggiuntive in tali scenari. Se stai già utilizzando OAI e desideri migrare, consulta [Migrazione dell'identità di accesso origine (OAI) al controllo degli accessi origine (OAC)](#migrate-from-oai-to-oac).

**Note**  
Quando usi CloudFront OAC con le origini dei bucket Amazon S3, devi impostare **Amazon S3 Object** Ownership su **Bucket owner enforced, l'impostazione predefinita per i nuovi bucket** Amazon S3. Se necessario ACLs, utilizza l'impostazione **preferita del proprietario di Bucket per mantenere il controllo sugli oggetti caricati** tramite. CloudFront
Se la tua origine è un bucket Amazon S3 configurato come [endpoint di un sito Web](https://docs.aws.amazon.com/AmazonS3/latest/userguide/WebsiteEndpoints.html), devi configurarlo CloudFront come origine personalizzata. Ciò significa che non è possibile utilizzare OAC (o OAI). OAC non supporta il reindirizzamento dell’origine tramite Lambda@Edge.
Se utilizzi un punto di accesso multiregionale Amazon S3 come CloudFront origine, vedi. [Limita l'accesso all'origine di un punto di accesso multiregionale Amazon S3](private-content-restricting-access-to-s3-mrap.md) Gli access point multiregionali S3 richiedono una configurazione OAC diversa.

I seguenti argomenti descrivono come utilizzare OAC con origine Amazon S3. 

**Argomenti**
+ [Creazione di un nuovo controllo di accesso origine](#create-oac-overview-s3)
+ [Eliminazione di una distribuzione con un OAC collegato a un bucket S3](#delete-oac-distribution-s3)
+ [Migrazione dell'identità di accesso origine (OAI) al controllo degli accessi origine (OAC)](#migrate-from-oai-to-oac)
+ [Impostazioni avanzate per il controllo dell'accesso all'origine](#oac-advanced-settings-s3)

## Creazione di un nuovo controllo di accesso origine
<a name="create-oac-overview-s3"></a>

Completa i passaggi descritti nei seguenti argomenti per configurare un nuovo controllo di accesso di origine in. CloudFront

**Topics**
+ [

### Prerequisiti
](#oac-prerequisites-s3)
+ [

### Concedi l' CloudFront autorizzazione per accedere al bucket S3
](#oac-permission-to-access-s3)
+ [

### Creazione del controllo di accesso origine
](#create-oac-s3)

### Prerequisiti
<a name="oac-prerequisites-s3"></a>

Prima di creare e configurare Origin Access Control (OAC), devi disporre di una CloudFront distribuzione con un'origine di bucket Amazon S3. Questa origine deve essere un normale bucket S3, non un bucket configurato come [endpoint del sito Web](https://docs.aws.amazon.com/AmazonS3/latest/userguide/WebsiteEndpoints.html). Per ulteriori informazioni sulla configurazione di una CloudFront distribuzione con un'origine del bucket S3, consulta. [Inizia con una distribuzione CloudFront standard](GettingStarted.SimpleDistribution.md)

**Importante**  
*Quando usi OAC per proteggere la tua origine Amazon S3, la comunicazione CloudFront tra Amazon S3 e Amazon S3 *avviene* sempre tramite HTTPS, ma solo quando scegli di firmare sempre le richieste.* Devi scegliere **Sign request (consigliato)** nella console o specificarlo `always` nell' CloudFront API, AWS CLI oppure. CloudFormation   
Se scegli invece l'opzione **Do not sign requests** o **Do not override authorization header**, CloudFront utilizza il protocollo di connessione specificato nelle seguenti politiche:  
[Politica del protocollo Viewer](using-https-viewers-to-cloudfront.md) 
[Policy del protocollo di origine](DownloadDistValuesOrigin.md#DownloadDistValuesOriginProtocolPolicy) (solo origini personalizzate)
[Ad esempio, se scegli **Non sovrascrivere l'intestazione di autorizzazione** e desideri utilizzare HTTPS tra CloudFront e la tua origine Amazon S3, **utilizza Redirect HTTP to** HTTPS **o HTTPS** solo per la policy del protocollo del visualizzatore.](using-https-viewers-to-cloudfront.md)

### Concedi l' CloudFront autorizzazione per accedere al bucket S3
<a name="oac-permission-to-access-s3"></a>

Prima di creare un controllo di accesso all'origine (OAC) o configurarlo in una CloudFront distribuzione, assicurati che CloudFront disponga dell'autorizzazione per accedere all'origine del bucket S3. Esegui questa operazione dopo aver creato una CloudFront distribuzione, ma prima di aggiungere l'OAC all'origine S3 nella configurazione di distribuzione.

Utilizza una [policy del bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-policies.html) S3 per consentire al CloudFront service principal (`cloudfront.amazonaws.com`) di accedere al bucket. Utilizza un `Condition` elemento della policy per consentire l'accesso CloudFront al bucket solo quando la richiesta è per conto della CloudFront distribuzione che contiene l'origine S3. Questa è la distribuzione con l’origine S3 a cui desideri aggiungere l’OAC.

Per informazioni sull'aggiunta o la modifica di una politica del bucket, consulta [Aggiunta di una policy di bucket utilizzando la console Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-bucket-policy.html) nella *Guida per l'utente di Amazon S3*.

Di seguito sono riportati alcuni esempi di policy relative ai bucket S3 che consentono una CloudFront distribuzione con accesso abilitato all'OAC a un'origine S3.

**Example Policy sui bucket S3 che consente l'accesso in sola lettura per una distribuzione con OAC abilitato CloudFront**    
****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "AllowCloudFrontServicePrincipalReadOnly",
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudfront.amazonaws.com"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*",
      "Condition": {
        "StringEquals": {
          "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/<CloudFront distribution ID>"
        }
      }
    }
  ]
}
```

**Example Policy S3 bucket che consente l'accesso in lettura e scrittura per una distribuzione con OAC abilitato CloudFront**    
****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "AllowCloudFrontServicePrincipalReadWrite",
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudfront.amazonaws.com"
      },
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*",
      "Condition": {
        "StringEquals": {
          "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/CloudFront-distribution-ID>"
        }
      }
    }
  ]
}
```

#### SSE-KMS
<a name="oac-permissions-sse-kms"></a>

Se gli oggetti nell'origine del bucket S3 sono crittografati utilizzando la [crittografia lato server con AWS Key Management Service (SSE-KMS)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html), devi assicurarti che la distribuzione disponga dell'autorizzazione per utilizzare la chiave. CloudFront AWS KMS [Per concedere alla CloudFront distribuzione l'autorizzazione all'uso della chiave KMS, aggiungi una dichiarazione alla politica della chiave KMS.](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) Per informazioni su come modificare un criterio delle chiavi, consulta [Modifica di una policy delle chiavi](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying.html)nella *Guida per gli sviluppatori AWS Key Management Service *.

**Example Dichiarazione della policy della chiave KMS**  
L'esempio seguente mostra una dichiarazione AWS KMS politica che consente alla CloudFront distribuzione con OAC di accedere a una chiave KMS per SSE-KMS.  

```
{
    "Sid": "AllowCloudFrontServicePrincipalSSE-KMS",
    "Effect": "Allow",
    "Principal": {
        "Service": [
            "cloudfront.amazonaws.com"
        ]
     },
    "Action": [
        "kms:Decrypt",
        "kms:Encrypt",
        "kms:GenerateDataKey*"
    ],
    "Resource": "*",
    "Condition": {
            "StringEquals": {
                "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/<CloudFront distribution ID>"
            }
        }
}
```

### Creazione del controllo di accesso origine
<a name="create-oac-s3"></a>

Per creare un controllo di accesso all'origine (OAC), puoi utilizzare l', Console di gestione AWS CloudFormation, o l'API. AWS CLI CloudFront 

------
#### [ Console ]

**Per creare un controllo di accesso all'origine**

1. Accedi Console di gestione AWS e apri la CloudFront console all'indirizzo[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Nel pannello di navigazione a sinistra, scegli **Accesso origine**.

1. Scegli **Crea un'impostazione di controllo**.

1. Nel modulo **Crea un'impostazione di controllo**, effettua le seguenti operazioni:

   1. Nel riquadro **Dettagli**, inserisci un **Nome** e (facoltativamente) una **Descrizione** per il controllo degli accessi all'origine.

   1. Nel riquadro **Impostazioni**, si consiglia di mantenere l'impostazione predefinita (**Richieste di firma (consigliato)**). Per ulteriori informazioni, consulta [Impostazioni avanzate per il controllo dell'accesso all'origine](#oac-advanced-settings-s3).

1. Scegli S3 dal menu a discesa **tipo di origine**.

1. Scegli **Create** (Crea).

   Dopo aver creato l'OAC, prendere nota del **Nome**. In questa procedura, eseguire le seguenti operazioni:

**Per aggiungere un controllo di accesso di origine a un'origine S3 in una distribuzione**

1. Apri la CloudFront console all'indirizzo[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Scegli una distribuzione con un'origine S3 a cui desideri aggiungere l'OAC, quindi scegli lascheda **Origini**.

1. Selezionare l'origine S3 alla quale si desidera aggiungere l'OAC, quindi scegliere **Modifica**.

1. Per **Accesso origine**, scegli **Impostazioni di controllo di accesso origine (consigliato)**.

1. Nel menu a discesa **Controllo degli accessi origine**, scegliere l'OAC che desideri utilizzare.

1. Scegli **Save changes** (Salva modifiche).

La distribuzione inizia a essere distribuita in tutte le CloudFront edge location. Quando una edge location riceve la nuova configurazione, firma tutte le richieste che invia all'origine del bucket S3.

------
#### [ CloudFormation ]

Per creare un controllo di accesso all'origine (OAC) con CloudFormation, usa il tipo di `AWS::CloudFront::OriginAccessControl` risorsa. L'esempio seguente mostra la sintassi del CloudFormation modello, in formato YAML, per creare un controllo di accesso all'origine.

```
Type: AWS::CloudFront::OriginAccessControl
Properties: 
  OriginAccessControlConfig: 
      Description: An optional description for the origin access control
      Name: ExampleOAC
      OriginAccessControlOriginType: s3
      SigningBehavior: always
      SigningProtocol: sigv4
```

*Per ulteriori informazioni, consulta [AWS::CloudFront::OriginAccessControl nella Guida](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-cloudfront-originaccesscontrol.html) per l'AWS CloudFormation utente.*

------
#### [ CLI ]

Per creare un controllo di accesso all'origine con AWS Command Line Interface (AWS CLI), utilizzate il **aws cloudfront create-origin-access-control** comando. È possibile utilizzare un file di input per fornire i parametri di input del comando, anziché specificare ogni singolo parametro come input della riga di comando.

**Per creare un controllo di accesso all'origine (CLI con file di input)**

1. Per creare un file denominato `origin-access-control.yaml`, utilizza il comando seguente. Tale file contiene tutti i parametri di input per il comando **create-origin-access-control**.

   ```
   aws cloudfront create-origin-access-control --generate-cli-skeleton yaml-input > origin-access-control.yaml
   ```

1. Aprire il file `origin-access-control.yaml` appena creato. Modifica il file per aggiungere un nome per l'OAC, una descrizione (opzionale) e modificare `SigningBehavior` in `always`. Quindi salvare il file.

   Per ulteriori informazioni sulle impostazioni OAC, consultare [Impostazioni avanzate per il controllo dell'accesso all'origine](#oac-advanced-settings-s3).

1. Utilizzare il comando seguente per creare il controllo di accesso origine utilizzando i parametri di input dal file `origin-access-control.yaml`.

   ```
   aws cloudfront create-origin-access-control --cli-input-yaml file://origin-access-control.yaml
   ```

   Prendere nota del valore `Id` nell'output del comando. È necessario per aggiungere l'OAC a un'origine del bucket S3 in una distribuzione. CloudFront 

**Per allegare un OAC a un'origine bucket S3 in una distribuzione esistente (CLI con file di input)**

1. Usa il comando seguente per salvare la configurazione di distribuzione per la CloudFront distribuzione a cui desideri aggiungere l'OAC. La distribuzione deve avere un'origine del bucket S3.

   ```
   aws cloudfront get-distribution-config --id <CloudFront distribution ID> --output yaml > dist-config.yaml
   ```

1. Aprire il file denominato `dist-config.yaml` appena creato. Modifica il file apportando le seguenti modifiche:
   + Nell'oggetto `Origins`, aggiungi l'ID dell'OAC al campo a cui è stato assegnato il nome `OriginAccessControlId`.
   + Rimuovi il valore dal campo denominato `OriginAccessIdentity`, se esiste.
   + Rinominare il campo `ETag` in `IfMatch`, ma non modificare il valore del campo.

   Salvare il file al termine.

1. Utilizzare il comando seguente per aggiornare la distribuzione e utilizzare il controllo di accesso origine.

   ```
   aws cloudfront update-distribution --id <CloudFront distribution ID> --cli-input-yaml file://dist-config.yaml
   ```

La distribuzione inizia a essere distribuita in tutte le CloudFront edge location. Quando una edge location riceve la nuova configurazione, firma tutte le richieste che invia all'origine del bucket S3.

------
#### [ API ]

Per creare un controllo di accesso all'origine con l' CloudFront API, usa [CreateOriginAccessControl](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateOriginAccessControl.html). Per ulteriori informazioni sui campi specificati in questa chiamata API, consulta la documentazione di riferimento sull'API per il tuo AWS SDK o altro client API.

Dopo aver creato un controllo di accesso origine, è possibile collegarlo all'origine del bucket S3 in una distribuzione, utilizzando una delle seguenti chiamate API:
+ Per collegarlo a una distribuzione esistente, usa [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html).
+ Per collegarlo a una nuova distribuzione, usa [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html).

Per entrambe queste chiamate API, fornire l'ID di controllo dell'accesso origine nel campo `OriginAccessControlId`, all'interno di un'origine. Per ulteriori informazioni sugli altri campi specificati in queste chiamate API, consulta [Riferimento a tutte le impostazioni di distribuzione](distribution-web-values-specify.md) la documentazione di riferimento sull'API per il tuo AWS SDK o altro client API.

------

## Eliminazione di una distribuzione con un OAC collegato a un bucket S3
<a name="delete-oac-distribution-s3"></a>

Se è necessario eliminare una distribuzione con un OAC collegato a un bucket S3, occorre eliminare la distribuzione prima di eliminare l’origine del bucket S3. In alternativa, includi la Regione nel nome di dominio di origine. Se ciò non è possibile, puoi rimuovere l’OAC dalla distribuzione passando a pubblico prima dell’eliminazione. Per ulteriori informazioni, consulta [Eliminazione di una distribuzione](HowToDeleteDistribution.md).

## Migrazione dell'identità di accesso origine (OAI) al controllo degli accessi origine (OAC)
<a name="migrate-from-oai-to-oac"></a>

Per migrare da un’identità di accesso origine (OAI) legacy a un controllo di accesso origine (OAC), aggiorna innanzitutto l’origine del bucket S3 per consentire sia all’OAI che all’OAC di accedere al contenuto del bucket. Questo assicura che CloudFront non perda mai l'accesso al bucket durante la transizione. Per consentire sia a OAI che alla distribuzione con OAC abilitato di accedere a un bucket S3, aggiorna la [policy di bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-policies.html) per includere due dichiarazioni, una per ogni tipo di principale.

Il seguente esempio di policy di bucket S3 consente sia a un OAI che a una distribuzione con OAC abilitato di accedere a un’origine S3.

**Example Policy del bucket S3 che consente l'accesso in sola lettura per un OAI e una distribuzione con OAC abilitato CloudFront**    
****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowCloudFrontServicePrincipalReadOnly",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudfront.amazonaws.com"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::<S3 bucket name>/*",
            "Condition": {
                "StringEquals": {
                    "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/<CloudFront distribution ID>"
                }
            }
        },
        {
            "Sid": "AllowLegacyOAIReadOnly",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity <origin access identity ID>"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::<S3 bucket name>/*"
        }
    ]
}
```

Dopo aver aggiornato la politica dei bucket di S3 Origin per consentire l'accesso sia all'OAI che all'OAC, puoi aggiornare la configurazione di distribuzione per utilizzare OAC anziché OAI. Per ulteriori informazioni, consulta [Creazione di un nuovo controllo di accesso origine](#create-oac-overview-s3).

Dopo che la distribuzione è stata completamente distribuita, puoi rimuovere l'istruzione nella politica del bucket che consente l'accesso all'OAI. Per ulteriori informazioni, consulta [Concedi l' CloudFront autorizzazione per accedere al bucket S3](#oac-permission-to-access-s3).

## Impostazioni avanzate per il controllo dell'accesso all'origine
<a name="oac-advanced-settings-s3"></a>

La funzionalità di controllo dell'accesso all' CloudFront origine include impostazioni avanzate destinate solo a casi d'uso specifici. Usa le impostazioni consigliate a meno che tu non abbia una necessità specifica per le impostazioni avanzate.

Origin Access Control contiene un'impostazione denominata **Signing behavior** (nella console) o `SigningBehavior` (nell'API, CLI e CloudFormation). Questa impostazione offre le seguenti opzioni:

**Firma sempre le richieste di origine (impostazione consigliata)**  
Si consiglia di utilizzare questa impostazione, denominata **Richieste di firma (consigliata)** nella console, oppure `always` nell'API, nell'interfaccia a riga di comando e CloudFormation. Con questa impostazione, firma CloudFront sempre tutte le richieste che invia all'origine del bucket S3.

**Non firmare le richieste di origine**  
Questa impostazione è denominata **Non firmare le richieste** nella console, oppure `never`nell'API, nell'interfaccia a riga di comando e CloudFormation. Usa questa impostazione per disattivare il controllo dell'accesso all'origine per tutte le origini in tutte le distribuzioni che utilizzano questo controllo di accesso all'origine. Ciò consente di risparmiare tempo e fatica rispetto alla rimozione di un controllo di accesso all'origine da tutte le origini e le distribuzioni che lo utilizzano, uno per uno. Con questa impostazione, CloudFront non firma alcuna richiesta inviata all'origine del bucket S3.  
Per utilizzare questa impostazione, l'origine del bucket S3 deve essere accessibile al pubblico. Se utilizzi questa impostazione con un'origine del bucket S3 che non è accessibile pubblicamente, CloudFront non puoi accedere all'origine. L'origine del bucket S3 restituisce gli errori CloudFront e li CloudFront trasmette agli spettatori.

**Non ignorare l'intestazione del visualizzatore (client) `Authorization`**  
Questa impostazione è denominata **Non sovrascrivere l'intestazione di autorizzazione**nella console, oppure `no-override` nell'API, nell'interfaccia a riga di comando e CloudFormation. Utilizza questa impostazione quando desideri firmare le richieste CloudFront di origine solo quando la richiesta del visualizzatore corrispondente non include un'intestazione. `Authorization` Con questa impostazione, CloudFront trasmette l'`Authorization`intestazione della richiesta del visualizzatore quando ne è presente una, ma firma la richiesta di origine (aggiungendo la propria `Authorization` intestazione) quando la richiesta del visualizzatore non include un'intestazione. `Authorization`  
Per passare lungo l'intestazione `Authorization` della richiesta del visualizzatore, *devi* aggiungere l'intestazione `Authorization` a una [policy della cache](controlling-the-cache-key.md) per tutti i comportamenti della cache che utilizzano le origini del bucket S3 associate a questo controllo di accesso all'origine.

## Utilizzo di un’identità di accesso origine (legacy, non consigliata)
<a name="private-content-restricting-access-to-s3-oai"></a>

### Panoramica dell'identità di accesso origine
<a name="private-content-restricting-access-to-s3-overview"></a>

CloudFront *origin access identity* (OAI) offre funzionalità simili a quelle di *Origin Access Control* (OAC), ma non funziona per tutti gli scenari. Nello specifico, l'OAI non supporta:
+ Bucket Amazon S3 in tutto Regioni AWS, comprese le regioni con attivazione
+ [Crittografia lato server con chiavi AWS KMS](https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html) (SSE-KMS) Amazon S3
+ Richieste dinamiche (`PUT`, `POST` o `DELETE`) su Amazon S3
+ Nuovo Regioni AWS lanciato dopo gennaio 2023

**Suggerimento**  
Ti consigliamo di utilizzare invece OAC. Per configurare OAC, consulta [Creazione di un nuovo controllo di accesso origine](#create-oac-overview-s3). Per informazioni su come eseguire la migrazione da OAI a OAC, consulta [Migrazione dell'identità di accesso origine (OAI) al controllo degli accessi origine (OAC)](#migrate-from-oai-to-oac).

### Concedere a un’identità di accesso origine l’autorizzazione per leggere i file nel bucket Amazon S3
<a name="private-content-granting-permissions-to-oai"></a>

Quando crei un OAI o ne aggiungi uno a una distribuzione con la CloudFront console, puoi aggiornare automaticamente la policy del bucket Amazon S3 per concedere all'OAI l'autorizzazione ad accedere al tuo bucket. In alternativa, è possibile scegliere di creare o aggiornare manualmente la policy di bucket. Qualunque sia il metodo utilizzato, è comunque necessario esaminare le autorizzazioni per assicurarsi che:
+ Il tuo CloudFront OAI può accedere ai file nel bucket per conto degli utenti che li richiedono. CloudFront
+ Gli utenti non possono utilizzare Amazon URLs S3 per accedere ai tuoi file dall'esterno. CloudFront

**Importante**  
Se configuri CloudFront per accettare e inoltrare tutti i metodi HTTP CloudFront supportati, assicurati di concedere all' CloudFront OAI le autorizzazioni desiderate. Ad esempio, se CloudFront configuri l'accettazione e l'inoltro delle richieste che utilizzano questo `DELETE` metodo, configura la tua bucket policy per gestire `DELETE` le richieste in modo appropriato in modo che gli utenti possano eliminare solo i file che desideri.

#### Utilizzo di policy di bucket di Amazon S3
<a name="private-content-updating-s3-bucket-policies"></a>

Puoi consentire a un CloudFront OAI di accedere ai file in un bucket Amazon S3 creando o aggiornando la policy del bucket nei seguenti modi:
+ Utilizzo della scheda **Permissions (Autorizzazioni)** del bucket Amazon S3 nella [console Amazon S3](https://console.aws.amazon.com/s3/home).
+ Utilizzo [PutBucketPolicy](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketPolicy.html)nell'API Amazon S3.
+ Utilizzo della [console CloudFront](https://console.aws.amazon.com/cloudfront/v4/home). Quando aggiungi un OAI alle impostazioni di origine nella CloudFront console, puoi scegliere **Sì, aggiorna la policy del bucket per dire di aggiornare la policy** del bucket CloudFront per tuo conto.

Se si aggiorna manualmente la policy del bucket, assicurarsi di:
+ Specificare l'OAI corretto come `Principal` nella policy.
+ Dare all'OAI le autorizzazioni necessarie per accedere agli oggetti per conto dei visualizzatori.

Per ulteriori informazioni, consultare le sezioni indicate di seguito.

##### Specificare un OAI come `Principal` in una policy di bucket
<a name="private-content-updating-s3-bucket-policies-principal"></a>

Per specificare un OAI come `Principal` in una policy del bucket Amazon S3, usa l'Amazon Resource Name (ARN) della OAI, che include il relativo ID. Esempio:

```
"Principal": {
    "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity <origin access identity ID>"
}
```

Trova l'ID OAI nella CloudFront console in **Security**, **Origin access**, **Identities** (legacy). In alternativa, utilizzalo [ListCloudFrontOriginAccessIdentities](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_ListCloudFrontOriginAccessIdentities.html)nell'API. CloudFront

##### Concessione di autorizzazioni a una OAI
<a name="private-content-updating-s3-bucket-policies-permissions"></a>

Per concedere alla OAI le autorizzazioni per accedere agli oggetti nel bucket Amazon S3, utilizzare le azioni nella policy relative a operazioni API Amazon S3 specifiche. Ad esempio, l'azione `s3:GetObject` consente all'OAI di leggere gli oggetti nel bucket. Per ulteriori informazioni, consulta gli esempi riportati nella sezione seguente oppure consulta la sezione [Operazioni Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/dev/using-with-s3-actions.html) nella *Guida per l'utente di Amazon Simple Storage Service*.

##### Esempi di policy del bucket Amazon S3
<a name="private-content-updating-s3-bucket-policies-examples"></a>

Gli esempi seguenti mostrano le policy dei bucket Amazon S3 che consentono a CloudFront OAI di accedere a un bucket S3.

**Trova l'ID OAI nella CloudFront console in **Security**, **Origin access**, Identities (legacy).** In alternativa, utilizzalo [ListCloudFrontOriginAccessIdentities](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_ListCloudFrontOriginAccessIdentities.html)nell'API. CloudFront

**Example Policy bucket Amazon S3 che fornisce l'accesso in lettura dell'OAI**  
L'esempio seguente consente all'OAI di leggere gli oggetti nel bucket (`s3:GetObject`) specificato.    
****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Id": "PolicyForCloudFrontPrivateContent",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity <origin access identity ID>"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::<S3 bucket name>/*"
        }
    ]
}
```

**Example Policy bucket Amazon S3 che fornisce all'OAI l'accesso in lettura e scrittura**  
L'esempio seguente consente all'OAI di leggere e scrivere oggetti nel bucket specificato (`s3:GetObject` e `s3:PutObject`). Ciò consente agli utenti di caricare file nel tuo bucket Amazon S3 tramite. CloudFront    
****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Id": "PolicyForCloudFrontPrivateContent",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity <origin access identity ID>"
            },
            "Action": [
                "s3:GetObject",
                "s3:PutObject"
            ],
            "Resource": "arn:aws:s3:::<S3 bucket name>/*"
        }
    ]
}
```

#### Usa oggetto Amazon S3 ACLs (non consigliato)
<a name="private-content-updating-s3-acls"></a>

**Importante**  
Consigliamo [l'utilizzo delle policy di bucket Amazon S3](#private-content-updating-s3-bucket-policies) per consentire a un OAI l'accesso a un bucket S3. Puoi usare le liste di controllo degli accessi (ACLs) come descritto in questa sezione, ma non è consigliabile.  
Amazon S3 consiglia di impostare [S3 Object Ownership](https://docs.aws.amazon.com/AmazonS3/latest/userguide/about-object-ownership.html) su **bucket owner enforced**, il che significa che ACLs sono disabilitati per il bucket e gli oggetti in esso contenuti. Quando si applica questa impostazione per la proprietà degli oggetti, è necessario utilizzare le policy del bucket per consentire l'accesso all'OAI (vedere la sezione precedente).  
La sezione seguente riguarda solo i casi d'uso precedenti che lo richiedono. ACLs

Puoi consentire a un CloudFront OAI di accedere ai file in un bucket Amazon S3 creando o aggiornando l'ACL del file nei seguenti modi:
+ Utilizzo della scheda **Permissions (Autorizzazioni)** dell'oggetto Amazon S3 nella [Console Amazon S3](https://console.aws.amazon.com/s3/home).
+ Utilizzo [PutObjectAcl](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObjectAcl.html)nell'API Amazon S3.

Quando si concede l'accesso a una OAI utilizzando un ACL, è necessario specificare l'OAI utilizzando il relativo ID utente Amazon S3 canonico. Nella CloudFront console, puoi trovare questo ID in **Security**, **Origin access**, **Identities (legacy)**. Se utilizzi l' CloudFront API, utilizza il valore dell'`S3CanonicalUserId`elemento che è stato restituito quando hai creato l'OAI o richiama [ListCloudFrontOriginAccessIdentities](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_ListCloudFrontOriginAccessIdentities.html)l' CloudFrontAPI.

### Utilizzo di un’identità di accesso origine nelle Regioni Amazon S3 che supportano solo l’autenticazione Signature Version 4
<a name="private-content-origin-access-identity-signature-version-4"></a>

Le regioni Amazon S3 più recenti richiedono l'utilizzo di Signature Version 4 per le richieste autenticate. (Per le versioni di firma supportate in ogni regione Amazon S3, consultare [Endpoint e quote Amazon Simple Storage Service](https://docs.aws.amazon.com/general/latest/gr/s3.html) nei *Riferimenti generali di AWS*.) Se utilizzi un'identità di accesso origine e se il bucket si trova in una delle regioni che richiedono Signature Version 4, nota quanto segue:
+ Le richieste `DELETE`, `GET`, `HEAD`, `OPTIONS` e `PATCH` sono supportate senza qualifiche.
+ Le richieste `POST` non sono supportate.

# Limitazione dell’accesso con VPC Origins
<a name="private-content-vpc-origins"></a>

È possibile CloudFront utilizzarlo per distribuire contenuti da applicazioni ospitate nelle sottoreti private del cloud privato virtuale (VPC). Puoi utilizzare Application Load Balancer (ALB), Network Load Balancer (NLB) e istanze EC2 in sottoreti private come VPC Origins.

Di seguito sono riportati alcuni motivi per cui è possibile utilizzare VPC Origins:
+ **Sicurezza**: VPC Origins è progettato per migliorare il livello di sicurezza dell'applicazione posizionando i sistemi di bilanciamento del carico e le istanze EC2 in sottoreti private, creando un unico punto di ingresso. CloudFront Le richieste degli utenti passano dalle CloudFront origini del VPC tramite una connessione privata e sicura, che fornisce una sicurezza aggiuntiva per le tue applicazioni.
+ **Gestione**: le origini VPC riducono il sovraccarico operativo richiesto per una connettività sicura tra e CloudFront origini. È possibile spostare le origini in sottoreti private senza accesso pubblico e non è necessario implementare liste di controllo degli accessi (ACLs) o altri meccanismi per limitare l'accesso alle origini. In questo modo, non è necessario investire in attività di sviluppo indifferenziate con cui proteggere le applicazioni web. CloudFront 
+ **Scalabilità e prestazioni**: VPC Origins ti aiuta a proteggere le tue applicazioni web, liberando tempo per concentrarti sulla crescita delle tue applicazioni aziendali critiche, migliorando al contempo la sicurezza e mantenendo alte prestazioni e scalabilità globale con. CloudFront VPC Origins semplifica la gestione della sicurezza e riduce la complessità operativa in modo da poterlo utilizzare CloudFront come unico punto di accesso per le applicazioni.

**Suggerimento**  
CloudFront supporta la condivisione delle origini VPC all'interno Account AWS dell'organizzazione o meno. Puoi condividere le origini del VPC dalla CloudFront console o utilizzare AWS Resource Access Manager ()AWS RAM. Per ulteriori informazioni, consulta [Utilizzo di risorse condivise in CloudFront](sharing-resources.md).

## Prerequisiti
<a name="vpc-origin-prerequisites"></a>

Prima di creare un'origine VPC per la tua CloudFront distribuzione, devi completare quanto segue:

### Configurazione del VPC
<a name="vpc-configuration"></a>

**Crea un cloud privato virtuale (VPC) su Amazon VPC** in uno dei sistemi Regioni AWS supportati per le origini VPC. Per informazioni sulla creazione di un VPC, consulta [Creazione di un VPC e altre risorse VPC](https://docs.aws.amazon.com/vpc/latest/userguide/create-vpc.html#create-vpc-and-other-resources) nella *Guida per l’utente di Amazon VPC*. Per un elenco delle regioni supportate, consulta [Supportato Regioni AWS per le origini VPC](#vpc-origins-supported-regions).

Il tuo VPC deve includere quanto segue:
+ **Gateway Internet**: devi aggiungere un gateway Internet al VPC che contiene le risorse di origine VPC. Il gateway Internet è necessario per indicare che il VPC può ricevere traffico da Internet. Il gateway Internet non viene utilizzato per instradare il traffico verso le origini all’interno della sottorete e non è necessario aggiornare le policy di instradamento.
+ **Sottorete privata con almeno un IPv4 indirizzo disponibile**: effettua il CloudFront routing verso la sottorete utilizzando un'interfaccia di rete elastica (ENI) gestita dai servizi che CloudFront viene creata dopo aver definito la risorsa di origine VPC con. CloudFront È necessario disporre di almeno un IPv4 indirizzo disponibile nella sottorete privata in modo che il processo di creazione dell'ENI possa avere successo. L' IPv4 indirizzo può essere privato e non prevede costi aggiuntivi. IPv6-solo le sottoreti non sono supportate.

### Risorse Origin
<a name="origin-resources"></a>

Nella sottorete privata, avvia un Application Load Balancer, un Network Load Balancer o un’istanza EC2 da usare come origine. La risorsa avviata deve essere completamente distribuita e in stato Attivo prima di poterla utilizzare per un’origine VPC.

**Restrizioni all'origine:**
+ I Gateway Load Balancer non possono essere aggiunti come origini
+ I Network Load Balancer dual-stack non possono essere aggiunti come origini
+ I Network Load Balancer con listener TLS non possono essere aggiunti come origini
+ Per essere utilizzato come origine VPC, un Network Load Balancer deve avere un gruppo di sicurezza collegato

### Configurazione del gruppo di sicurezza
<a name="security-group-configuration"></a>

Le tue risorse di origine VPC (Application Load Balancer, Network Load Balancer o istanza EC2) devono avere un gruppo di sicurezza collegato. Quando crei un'origine VPC, crea CloudFront automaticamente un gruppo di sicurezza gestito dai servizi con lo schema di denominazione. `CloudFront-VPCOrigins-Service-SG` Questo gruppo di sicurezza è completamente gestito da AWS e non deve essere modificato.

Per consentire al traffico di CloudFront raggiungere l'origine del VPC, aggiorna il gruppo di sicurezza collegato alla risorsa di origine (ALB, NLB o istanza EC2) per consentire il traffico in entrata utilizzando uno dei seguenti metodi:
+ **Opzione 1:** consenti il traffico proveniente dall'elenco dei prefissi gestiti. CloudFront Per ulteriori informazioni, consulta [Utilizza l'elenco dei prefissi CloudFront gestiti](LocationsOfEdgeServers.md#managed-prefix-list). Questa operazione può essere eseguita anche prima della creazione dell'origine del VPC.
+ **Opzione 2:** consenti il traffico proveniente dal gruppo di sicurezza CloudFront gestito dal servizio (). `CloudFront-VPCOrigins-Service-SG` Questa operazione può essere eseguita solo dopo la creazione dell'origine del VPC e la creazione del gruppo di sicurezza gestito dal servizio. Questa configurazione è ulteriormente restrittiva in quanto limita il traffico solo alle distribuzioni. CloudFront 

**Importante**  
Non create il vostro gruppo di sicurezza con un nome che inizia con. `CloudFront-VPCOrigins-Service-SG` Si tratta di un modello di denominazione AWS riservato per i gruppi di sicurezza gestiti dai servizi. Per ulteriori informazioni, consulta [Creazione di un gruppo di sicurezza](https://docs.aws.amazon.com/vpc/latest/userguide/creating-security-groups.html).

### Restrizioni relative a protocolli e funzionalità
<a name="protocol-feature-restrictions"></a>

Le origini VPC non supportano quanto segue:
+ WebSockets
+ Traffico gRPC
+ Trigger di richiesta e risposta all'origine con Lambda @Edge

## Creazione di un’origine VPC (nuova distribuzione)
<a name="new-vpc-origin"></a>

La procedura seguente mostra come creare un'origine VPC per la nuova CloudFront distribuzione nella CloudFront console. In alternativa, puoi utilizzare le operazioni [CreateVpcOrigin](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateVpcOrigin.html)e [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html)API con AWS CLI o un AWS SDK.

**Per creare un'origine VPC per una nuova distribuzione CloudFront**

1. Apri la CloudFront console all'indirizzo[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Scegli **VPC Origins**, **Crea origine VPC**.

1. Compila i campi obbligatori. Per **ARN origine**, seleziona l’ARN di Application Load Balancer, Network Load Balancer o Istanza EC2. Se non vedi l’ARN, puoi copiare l’ARN specifico della risorsa e incollarlo qui.

1. Scegli **Crea origine VPC**.

1. Attendi che lo stato dell’origine VPC cambi in **Implementato**. Questa operazione può richiedere fino a 15 minuti.

1. Scegli **Distribuzioni**, **Crea distribuzione**.

1. Per **Dominio origine**, seleziona la risorsa VPC Origins dall’elenco a discesa.

   Se l’origine VPC è un’istanza EC2, copia e incolla il **Nome DNS IP privato** dell’istanza nel campo **Dominio origine**.

1. Completa la creazione della distribuzione. Per ulteriori informazioni, consulta [Crea una CloudFront distribuzione nella console](distribution-web-creating-console.md#create-console-distribution).

## Creazione di un’origine VPC (distribuzione esistente)
<a name="existing-vpc-origin"></a>

La procedura seguente mostra come creare un'origine VPC per la CloudFront distribuzione esistente nella CloudFront console, che aiuta a garantire la disponibilità continua delle applicazioni. In alternativa, puoi utilizzare le operazioni [CreateVpcOrigin](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateVpcOrigin.html)e [UpdateDistributionWithStagingConfig](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistributionWithStagingConfig.html)API con AWS CLI o un AWS SDK.

Facoltativamente, puoi scegliere di aggiungere l’origine VPC alla distribuzione esistente senza creare una distribuzione temporanea.

**Per creare un'origine VPC per la distribuzione esistente CloudFront**

1. Apri la CloudFront console all'indirizzo[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Scegli **VPC Origins**, **Crea origine VPC**.

1. Compila i campi obbligatori. Per **ARN origine**, seleziona l’ARN di Application Load Balancer, Network Load Balancer o Istanza EC2. Se non vedi l’ARN, puoi copiare l’ARN specifico della risorsa e incollarlo qui.

1. Scegli **Crea origine VPC**.

1. Attendi che lo stato dell’origine VPC cambi in **Implementato**. Questa operazione può richiedere fino a 15 minuti.

1. Nel riquadro di navigazione seleziona **Distributions (Distribuzioni)**.

1. Scegli l’ID della distribuzione.

1. Nella scheda **Generale**, in **Implementazione continua**, scegli **Crea distribuzione di gestione temporanea**. Per ulteriori informazioni, consulta [Utilizza la distribuzione CloudFront continua per testare in sicurezza le modifiche alla configurazione CDN](continuous-deployment.md).

1. Segui le fasi della procedura guidata **Creazione distribuzione di gestione temporanea** per creare una distribuzione temporanea. Includi le fasi seguenti:
   + Per **Origini**, scegli **Crea origine**.
   + Per **Dominio origine**, seleziona la risorsa VPC Origins dal menu a discesa.

     Se l’origine VPC è un’istanza EC2, copia e incolla il **Nome DNS IP privato** dell’istanza nel campo **Dominio origine**.
   + Scegli **Create Origin** (Crea origine).

1. Nella distribuzione temporanea, verifica l’origine VPC.

1. Promuovi la configurazione della distribuzione temporanea nella distribuzione primaria. Per ulteriori informazioni, consulta [Promozione di una configurazione di distribuzione temporanea](working-with-staging-distribution-continuous-deployment-policy.md#promote-staging-distribution-configuration).

1. Rimuovi l’accesso pubblico all’origine VPC rendendo privata la sottorete. Dopo aver eseguito questa operazione, l'origine del VPC non sarà più individuabile su Internet, ma CloudFront avrà comunque accesso privato ad essa. Per ulteriori informazioni, consulta [Associare o dissociare una sottorete con una tabella di routing](https://docs.aws.amazon.com/vpc/latest/userguide/WorkWithRouteTables.html#AssociateSubnet) nella *Guida per l’utente di Amazon VPC*.

## Aggiornamento di un’origine VPC
<a name="update-vpc-origin"></a>

La procedura seguente mostra come aggiornare un'origine VPC per la CloudFront distribuzione nella CloudFront console. In alternativa, puoi utilizzare le operazioni [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)e [UpdateVpcOrigin](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateVpcOrigin.html)API con AWS CLI o un AWS SDK.

**Per aggiornare un'origine VPC esistente per la tua distribuzione CloudFront**

1. Apri la CloudFront console all'indirizzo[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Nel riquadro di navigazione seleziona **Distributions (Distribuzioni)**.

1. Scegli l’ID della distribuzione.

1. Scegli la scheda **Behaviors** (Comportamenti).

1. Assicurati che l’origine VPC non sia l’origine predefinita per il comportamento cache. 

1. Seleziona la scheda **Origins (Origini)**.

1. Seleziona l’origine VPC che intendi aggiornare e scegli **Elimina**. L’origine VPC viene dissociata dalla distribuzione. Ripeti i passaggi da 2 a 7 per dissociare l’origine VPC da qualsiasi altra distribuzione.

1. Scegli **VPC Origins**.

1. Seleziona l’origine VPC e scegli **Modifica**.

1. Effettua gli aggiornamenti e scegli **Aggiorna origine VPC**.

1. Attendi che lo stato dell’origine VPC cambi in **Implementato**. Questa operazione può richiedere fino a 15 minuti.

1. Nel riquadro di navigazione seleziona **Distributions (Distribuzioni)**.

1. Scegli l’ID della distribuzione.

1. Seleziona la scheda **Origins (Origini)**.

1. Scegli **Create Origin** (Crea origine).

1. Per **Dominio origine**, seleziona la risorsa VPC Origins dal menu a discesa.

   Se l’origine VPC è un’istanza EC2, copia e incolla il **Nome DNS IP privato** dell’istanza nel campo **Dominio origine**.

1. Scegli **Create Origin** (Crea origine). L’origine VPC viene nuovamente associata alla distribuzione. Ripeti i passaggi da 12 a 17 per associare l’origine VPC aggiornata a qualsiasi altra distribuzione.

## Supportato Regioni AWS per le origini VPC
<a name="vpc-origins-supported-regions"></a>

Le origini VPC sono attualmente supportate nelle seguenti pubblicità. Regioni AWS Sono indicate le eccezioni relative alla zona di disponibilità (AZ).

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonCloudFront/latest/DeveloperGuide/private-content-vpc-origins.html)

# Limita l'accesso all'origine di un punto di accesso multiregionale Amazon S3
<a name="private-content-restricting-access-to-s3-mrap"></a>

Puoi utilizzare Origin Access Control (OAC) per limitare l'accesso all'origine di un punto di accesso multiregionale Amazon S3. Gli access point multiregionali S3 forniscono un endpoint globale che indirizza le richieste al bucket S3 più vicino in base alla latenza di rete.

Per informazioni sull'uso di OAC con un'origine di bucket Amazon S3 standard, consulta. [Limitazione dell’accesso a un’origine Amazon S3](private-content-restricting-access-to-s3.md)

## Prerequisiti
<a name="oac-prerequisites-s3-mrap"></a>

Prima di creare e configurare l'OAC, è necessario disporre di una CloudFront distribuzione con un punto di accesso multiregionale Amazon S3. Il nome di dominio di origine deve utilizzare il formato del nome host S3 Multi-Region Access Point:

`multi-region-access-point-alias.accesspoint.s3-global.amazonaws.com`

Per ulteriori informazioni sulla creazione di un punto di accesso multiregionale S3, consulta [Creazione di punti di accesso multiregionali nella Guida](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingMultiRegionAccessPoints.html) per l'utente di *Amazon Simple Storage Service*.

## Concedi CloudFront l'autorizzazione per accedere al punto di accesso multiregionale S3
<a name="oac-permission-to-access-s3-mrap"></a>

Aggiorna la politica del punto di accesso multiregionale per consentire al principale del CloudFront servizio (`cloudfront.amazonaws.com`) di accedere al punto di accesso multiregionale. Utilizzate un `Condition` elemento della politica per consentire l'accesso CloudFront al punto di accesso multiregionale solo quando la richiesta è per conto della CloudFront distribuzione che contiene l'origine.

Per informazioni sull'aggiunta o la modifica di una policy Multi-Region Access Point, consulta gli [esempi di policy Multi-Region Access Point nella Guida](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPointPermissions.html) per l'utente di *Amazon Simple Storage Service*.

**Example Policy per punti di accesso multiregionali per OAC CloudFront**  

```
{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowCloudFrontOACAccess",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudfront.amazonaws.com"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3::111122223333:accesspoint/Multi-Region-Access-Point-Alias.mrap/object/*",
            "Condition": {
                "StringEquals": {
                    "aws:SourceArn": "arn:aws:cloudfront::111122223333:distribution/CloudFront distribution ID"
                }
            }
        }
    ]
}
```

## Concedi CloudFront l'autorizzazione per accedere ai bucket S3 sottostanti
<a name="oac-permission-to-access-s3-mrap-buckets"></a>

Oltre alla politica del punto di accesso multiregionale, devi anche concedere l' CloudFrontautorizzazione per accedere a ciascuno dei bucket S3 sottostanti associati al punto di accesso multiregionale. Ci sono due modi per farlo:

### Opzione 1: concedere l'accesso solo a CloudFront
<a name="oac-s3-mrap-bucket-option1"></a>

Aggiungi una policy sui bucket a ciascun bucket S3 che consenta al responsabile del CloudFront servizio di accedere al bucket. Utilizza questa opzione quando devi consentire anche l'accesso diretto al bucket da altre fonti.

**Example Politica del bucket S3 per un bucket sottostante**  

```
{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowCloudFrontOACAccessViaMRAP",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudfront.amazonaws.com"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::amzn-s3-demo-bucket-us-east-1/*",
            "Condition": {
                "StringEquals": {
                    "aws:SourceArn": "arn:aws:cloudfront::111122223333:distribution/CloudFront distribution ID"
                }
            }
        }
    ]
}
```

### Opzione 2: delega l'accesso completo al punto di accesso multiregionale
<a name="oac-s3-mrap-bucket-option2"></a>

Concedi al punto di accesso multiregionale l'accesso completo a ciascun bucket sottostante. Con questo approccio, tutti gli accessi al bucket sono controllati dalla politica Multi-Region Access Point, che semplifica la gestione degli accessi. Consigliamo questa opzione per i casi d'uso che non richiedono l'accesso diretto al bucket.

**Example Policy del bucket S3 che delega l'accesso al punto di accesso multiregionale**  

```
{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "DelegateAccessToMRAP",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::amzn-s3-demo-bucket-us-east-1",
                "arn:aws:s3:::amzn-s3-demo-bucket-us-east-1/*"
            ],
            "Condition": {
                "StringEquals": {
                    "s3:DataAccessPointArn": "arn:aws:s3::111122223333:accesspoint/Multi-Region-Access-Point-Alias.mrap"
                }
            }
        }
    ]
}
```

Per ulteriori informazioni, consulta l'[esempio di policy Multi-Region Access Point](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPointPermissions.html#MultiRegionAccessPointPolicyExamples) nella *Guida per l'utente di Amazon Simple Storage Service*.

**Importante**  
È necessario aggiungere questa policy sui bucket a ogni bucket S3 associato al punto di accesso multiregionale. Se in un bucket manca la policy, le CloudFront richieste indirizzate a quel bucket verranno rifiutate.

### SSE-KMS
<a name="oac-s3-mrap-sse-kms"></a>

Se gli oggetti nei bucket S3 sottostanti sono crittografati utilizzando la crittografia lato server con AWS KMS (SSE-KMS), devi assicurarti che la distribuzione disponga dell'autorizzazione per utilizzare la chiave. CloudFront AWS KMS Poiché i punti di accesso multiregionali S3 possono instradare le richieste verso i bucket in più regioni, è necessario aggiungere una dichiarazione alla politica chiave KMS in ogni regione in cui un bucket sottostante utilizza SSE-KMS. Per informazioni su come modificare un criterio delle chiavi, consulta [Modifica di una policy delle chiavi](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying.html)nella *Guida per gli sviluppatori AWS Key Management Service *.

**Example Dichiarazione della policy della chiave KMS**  
L'esempio seguente mostra una dichiarazione politica chiave KMS che consente alla CloudFront distribuzione con OAC di accedere a una chiave KMS per SSE-KMS.  

```
{
    "Sid": "AllowCloudFrontServicePrincipalSSE-KMS",
    "Effect": "Allow",
    "Principal": {
        "Service": "cloudfront.amazonaws.com"
    },
    "Action": [
        "kms:Decrypt",
        "kms:Encrypt",
        "kms:GenerateDataKey*"
    ],
    "Resource": "*",
    "Condition": {
        "StringEquals": {
            "aws:SourceArn": "arn:aws:cloudfront::111122223333:distribution/CloudFront distribution ID"
        }
    }
}
```

**Importante**  
È necessario aggiungere questa dichiarazione politica chiave alla chiave KMS in ogni regione in cui un bucket S3 sottostante utilizza la crittografia SSE-KMS.

## Creazione del controllo di accesso origine
<a name="create-oac-s3-mrap"></a>

Per creare un controllo di accesso all'origine (OAC), puoi utilizzare l',, o l'API Console di gestione AWS. CloudFormation AWS CLI CloudFront 

------
#### [ Console ]

**Per creare un controllo di accesso all'origine**

1. Accedi Console di gestione AWS e apri la CloudFront console all'indirizzo[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Nel pannello di navigazione a sinistra, scegli **Accesso origine**.

1. Scegli **Crea un'impostazione di controllo**.

1. Nel modulo **Crea un'impostazione di controllo**, effettua le seguenti operazioni:

   1. Nel riquadro **Dettagli**, inserisci un **Nome** e (facoltativamente) una **Descrizione** per il controllo degli accessi all'origine.

   1. Nel riquadro **Impostazioni**, si consiglia di mantenere l'impostazione predefinita (**Richieste di firma (consigliato)**). Per ulteriori informazioni, consulta [Impostazioni avanzate per il controllo dell'accesso all'origine](private-content-restricting-access-to-s3.md#oac-advanced-settings-s3).

1. Scegli **S3 Multi-Region Access Point dal menu** a discesa del **tipo Origin**.

1. Scegli **Create** (Crea).

   Dopo aver creato l'OAC, prendere nota del **Nome**. In questa procedura, eseguire le seguenti operazioni:

**Per aggiungere un controllo di accesso di origine a un'origine S3 Multi-Region Access Point in una distribuzione**

1. Apri la CloudFront console all'indirizzo. [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home)

1. **Scegli una distribuzione con un'origine S3 Multi-Region Access Point a cui desideri aggiungere l'OAC, quindi scegli la scheda Origins.**

1. **Seleziona l'origine del punto di accesso multiregionale S3 a cui desideri aggiungere l'OAC, quindi scegli Modifica.**

1. Per **Accesso origine**, scegli **Impostazioni di controllo di accesso origine (consigliato)**.

1. Nel menu a discesa **Controllo degli accessi origine**, scegliere l'OAC che desideri utilizzare.

1. Scegli **Save changes** (Salva modifiche).

La distribuzione inizia a essere distribuita in tutte le edge location. CloudFront Quando una edge location riceve la nuova configurazione, firma tutte le richieste che invia all'origine del punto di accesso multiregionale S3.

------
#### [ CLI ]

Utilizza il comando **create-origin-access-control**:

```
aws cloudfront create-origin-access-control \
    --origin-access-control-config '{
        "Name": "my-s3-mrap-oac",
        "Description": "OAC for S3 Multi-Region Access Point",
        "SigningProtocol": "sigv4a",
        "SigningBehavior": "always",
        "OriginAccessControlOriginType": "s3mrap"
    }'
```

------
#### [ CloudFormation ]

Specificare i seguenti valori in: `OriginAccessControlConfig`
+ `SigningProtocol`: `sigv4a`
+ `SigningBehavior`: `always``never`, o `no-override`
+ `OriginAccessControlOriginType`: `s3mrap`

**Example CloudFormation modello**  

```
Type: AWS::CloudFront::OriginAccessControl
Properties:
  OriginAccessControlConfig:
    Description: An optional description for the origin access control
    Name: my-s3-mrap-oac
    OriginAccessControlOriginType: s3mrap
    SigningBehavior: always
    SigningProtocol: sigv4a
```

------

## Comportamento della firma
<a name="oac-signing-behavior-s3-mrap"></a>

Le opzioni di comportamento di firma per le origini dei punti di accesso multiregione S3 sono le stesse delle normali origini dei bucket Amazon S3. Per ulteriori informazioni, consulta [Impostazioni avanzate per il controllo dell'accesso all'origine](private-content-restricting-access-to-s3.md#oac-advanced-settings-s3) la sezione *Limitare l'accesso a un'origine Amazon S3*.

# Limitazione dell’accesso ad Application Load Balancer
<a name="restrict-access-to-load-balancer"></a>

Puoi utilizzare Application Load Balancer interni e con accesso a Internet con Amazon. CloudFront È possibile utilizzare Application Load Balancer interni all'interno di sottoreti private CloudFront utilizzando origini VPC. CloudFront Le origini VPC consentono di servire contenuti da applicazioni ospitate in sottoreti VPC private senza esporli alla rete Internet pubblica. Per ulteriori informazioni, consulta [Limitazione dell’accesso con VPC Origins](private-content-vpc-origins.md).

Se si utilizza un Application Load Balancer CloudFront con accesso a Internet con, è possibile utilizzare le seguenti mitigazioni di sicurezza per impedire agli utenti di accedere direttamente a un Application Load Balancer e consentire l'accesso solo tramite. CloudFront

1. Configura CloudFront per aggiungere un'intestazione HTTP personalizzata alle richieste inviate all'Application Load Balancer.

1. Configura Application Load Balancer per inoltrare solo le richieste che contengono l'intestazione HTTP personalizzata.

1. Richiedi HTTPS per migliorare la sicurezza di questa soluzione.

CloudFront può anche contribuire a ridurre la latenza e persino ad assorbire alcuni attacchi Distributed Denial of Service (S)DDo.

Se il tuo caso d'uso richiede un doppio accesso alle applicazioni Web da entrambi CloudFront e da Application Load Balancer direttamente su Internet, valuta la possibilità di suddividere l'applicazione APIs Web come segue:
+ APIs che deve passare. CloudFront In questo caso, valuta la possibilità di utilizzare un Application Load Balancer privato separato come origine.
+ APIs che richiedono l'accesso tramite Application Load Balancer. In questo caso, si CloudFront ignora.

In alternativa, per un'applicazione Web o altri contenuti forniti da un Application Load Balancer con accesso a Internet in Elastic Load Balancing CloudFront , puoi memorizzare nella cache gli oggetti e servirli direttamente agli utenti (visualizzatori), riducendo il carico sull'Application Load Balancer. Un bilanciatore del carico connesso a Internet ha un nome DNS risolvibile pubblicamente e instrada le richieste dei client verso le destinazioni su Internet.

Per ulteriori informazioni, consulta i seguenti argomenti. Dopo aver completato questi passaggi, gli utenti possono accedere all'Application Load Balancer solo tramite. CloudFront

**Topics**
+ [

## Configura CloudFront per aggiungere un'intestazione HTTP personalizzata alle richieste
](#restrict-alb-add-custom-header)
+ [

## Configurazione di un Application Load Balancer per inoltrare solo le richieste che contengono un’intestazione specifica
](#restrict-alb-route-based-on-header)
+ [

## (Facoltativo) Migliorare la sicurezza di questa soluzione
](#restrict-alb-improve-security)
+ [

## (Facoltativo) Limita l'accesso all'origine utilizzando l'elenco di prefissi AWS-managed per CloudFront
](#limit-access-to-origin-using-aws-managed-prefixes)

## Configura CloudFront per aggiungere un'intestazione HTTP personalizzata alle richieste
<a name="restrict-alb-add-custom-header"></a>

È possibile CloudFront configurare l'aggiunta di un'intestazione HTTP personalizzata alle richieste inviate all'origine (in questo caso, un Application Load Balancer).

**Importante**  
Questo caso d'uso si basa sul mantenere segreti il nome dell'intestazione e il valore personalizzati. Se il nome e il valore dell'intestazione non sono segreti, altri client HTTP potrebbero potenzialmente includerli nelle richieste inviate direttamente a Application Load Balancer. Ciò può far sì che l'Application Load Balancer si comporti come se le richieste provenissero da CloudFront quando non provenivano. Per evitare ciò, mantieni segreti il nome dell'intestazione e il valore personalizzati.

È possibile CloudFront configurare l'aggiunta di un'intestazione HTTP personalizzata alle richieste di origine con la CloudFront console o CloudFormation l'API. CloudFront 

**Per aggiungere un'intestazione HTTP personalizzata (console) CloudFront **  
Nella CloudFront console, usa l'impostazione **Origin Custom Headers** nelle impostazioni di **Origin**. Immetti il **Nome intestazione** e il relativo **Valore**.  
In produzione, utilizza nomi e valori intestazione generati casualmente. Tratta i nomi e i valori delle intestazioni come credenziali sicure, ad esempio, nomi utente e password.
Puoi modificare l'impostazione **Origin Custom Headers** quando crei o modifichi un'origine per una CloudFront distribuzione esistente e quando crei una nuova distribuzione. Per ulteriori informazioni, consultare [Aggiornamento di una distribuzione](HowToUpdateDistribution.md) e [Creazione di una distribuzione](distribution-web-creating-console.md).

**Come aggiungere un'intestazione HTTP personalizzata (CloudFormation)**  
In un CloudFormation modello, utilizzate la `OriginCustomHeaders` proprietà, come illustrato nell'esempio seguente.  
Il nome e il valore dell'intestazione in questo esempio sono solo per dimostrazione. In produzione, utilizza valori generati casualmente. Considera il nome e il valore dell'intestazione come credenziali protette, ad esempio un nome utente e una password.

```
AWSTemplateFormatVersion: '2010-09-09'
Resources:
  TestDistribution:
    Type: 'AWS::CloudFront::Distribution'
    Properties:
      DistributionConfig:
        Origins:
          - DomainName: app-load-balancer.example.com
            Id: Example-ALB
            CustomOriginConfig:
              OriginProtocolPolicy: https-only
              OriginSSLProtocols:
                - TLSv1.2
            OriginCustomHeaders:
               - HeaderName: X-Custom-Header
                 HeaderValue: random-value-1234567890
        Enabled: 'true'
        DefaultCacheBehavior:
          TargetOriginId: Example-ALB
          ViewerProtocolPolicy: allow-all
          CachePolicyId: 658327ea-f89d-4fab-a63d-7e88639e58f6
        PriceClass: PriceClass_All
        ViewerCertificate:
          CloudFrontDefaultCertificate: 'true'
```
Per ulteriori informazioni, consultate [Origin](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cloudfront-distribution-origin.html) and [OriginCustomHeader](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cloudfront-distribution-origincustomheader.html)properties nella *Guida AWS CloudFormation per l'utente*.

**Per aggiungere un'intestazione HTTP (CloudFront API) personalizzata**  
Nell' CloudFront API, usa l'`CustomHeaders`oggetto contenuto all'interno`Origin`. Per ulteriori informazioni, consulta [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html)e [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)consulta *Amazon CloudFront API Reference* e la documentazione per il tuo SDK o altro client API.

Esistono alcuni nomi di intestazione che non è possibile specificare come intestazioni personalizzate di origine. Per ulteriori informazioni, consulta [Intestazioni personalizzate che CloudFront non possono essere aggiunte alle richieste di origine](add-origin-custom-headers.md#add-origin-custom-headers-denylist).

## Configurazione di un Application Load Balancer per inoltrare solo le richieste che contengono un’intestazione specifica
<a name="restrict-alb-route-based-on-header"></a>

Dopo aver CloudFront configurato l'aggiunta di un'intestazione HTTP personalizzata alle richieste inviate all'Application Load Balancer ([vedi la sezione precedente), puoi configurare il](#restrict-alb-add-custom-header) load balancer per inoltrare solo le richieste che contengono questa intestazione personalizzata. A tale scopo, aggiungere una nuova regola e modificando la regola predefinita nel listener del sistema di bilanciamento del carico.

**Prerequisiti**  
Per utilizzare le procedure seguenti, è necessario un Application Load Balancer con almeno un listener. Se non ne hai ancora creato uno, vedere [Creare un Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-application-load-balancer.html) nella *Guida dell'utente per Application Load Balancer*.

Le procedure seguenti modificano un listener HTTPS. È possibile utilizzare lo stesso processo per modificare un listener HTTP.

**Per aggiornare le regole in un listener di Application Load Balancer**

1. Aggiungi una nuova regola. Usa le istruzioni di [Aggiungi una regola](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-update-rules.html#add-rule), con le seguenti modifiche:
   + Aggiungi la regola al load balancer che è l'origine della tua distribuzione. CloudFront 
   + Per **Aggiungi condizione**, scegli **Intestazione HTTP**. Specificate il nome e il valore dell'intestazione HTTP che avete aggiunto come intestazione personalizzata di origine. CloudFront
   + Per **Aggiungi azione**, scegli **Inoltra a**. Scegliere il gruppo target in cui si desidera inoltrare le richieste.

1. Modifica la regola predefinita nel listener del bilanciatore del carico. Usa le istruzioni di [Modifica una regola](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-update-rules.html#edit-rule), con le seguenti modifiche:
   + Modifica la regola predefinita del load balancer che è l'origine della tua distribuzione. CloudFront 
   + Elimina l’azione predefinita, quindi per **Aggiungi azione**, scegli **Restituzione risposta fissa**. 
   + Per **Codice risposta**, immettere **403**.
   + Per **Corpo risposta**, immettere **Access denied**.

Dopo aver completato queste fasi, il listener del bilanciatore del carico dispone di due regole. Una regola inoltra le richieste che contengono l'intestazione HTTP (richieste che provengono da). CloudFront L'altra regola invia una risposta fissa a tutte le altre richieste (richieste che non provengono da CloudFront).

Puoi verificare che la soluzione funzioni inviando una richiesta alla tua CloudFront distribuzione e una all'Application Load Balancer. La richiesta di CloudFront restituzione dell'applicazione o del contenuto Web e quella inviata direttamente all'Application Load Balancer restituiscono una `403` risposta con un messaggio di testo semplice. `Access denied`

## (Facoltativo) Migliorare la sicurezza di questa soluzione
<a name="restrict-alb-improve-security"></a>

Per migliorare la sicurezza di questa soluzione, puoi configurare la tua CloudFront distribuzione in modo che utilizzi sempre HTTPS quando invii richieste all'Application Load Balancer. Ricorda che questa soluzione funziona solo se si mantengono segreti il nome dell'intestazione e il valore personalizzati. L'utilizzo di HTTPS può aiutare a impedire a un intercettore di scoprire il nome e il valore dell'intestazione. Si consiglia inoltre di ruotare periodicamente il nome e il valore dell'intestazione.

**Usa HTTPS per le richieste di origine**  
 CloudFront Per configurare l'utilizzo di HTTPS per le richieste di origine, imposta l'impostazione **Origin Protocol Policy** su **Solo HTTPS**. Questa impostazione è disponibile nella CloudFront console CloudFormation e nell' CloudFront API. Per ulteriori informazioni, consulta [Protocollo (solo origini personalizzate)](DownloadDistValuesOrigin.md#DownloadDistValuesOriginProtocolPolicy).

Quanto segue si applica anche quando si configura l'utilizzo CloudFront di HTTPS per le richieste di origine:
+ È necessario CloudFront configurare l'inoltro dell'`Host`intestazione all'origine con la policy di richiesta di origine. È possibile utilizzare la [policy di richiesta di origine AllViewer gestita](using-managed-origin-request-policies.md#managed-origin-request-policy-all-viewer).
+ Assicurati che Application Load Balancer disponga di un listener HTTPS (come illustrato nella [sezione precedente](#restrict-alb-route-based-on-header)). Per ulteriori informazioni, consulta la sezione relativa alla [creazione di un listener HTTPS](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html) nella *Guida utente per Application Load Balancer*. L'utilizzo di un listener HTTPS richiede un SSL/TLS certificato che corrisponda al nome di dominio indirizzato all'Application Load Balancer.
+ I certificati SSL/TLS per CloudFront possono essere richiesti (o importati) solo in (ACM). `us-east-1` Regione AWS AWS Certificate Manager CloudFront Trattandosi di un servizio globale, distribuisce automaticamente il certificato dalla `us-east-1` regione a tutte le regioni associate alla distribuzione. CloudFront
  + Ad esempio, se disponi di un Application Load Balancer (ALB) nella `ap-southeast-2` regione, devi configurare SSL/TLS i certificati sia nella `ap-southeast-2` regione (per utilizzare HTTPS tra CloudFront e l'origine ALB) che `us-east-1` nella regione (per utilizzare HTTPS tra i visualizzatori e). CloudFront Entrambi i certificati devono corrispondere al nome di dominio che viene instradato ad Application Load Balancer. Per ulteriori informazioni, consulta [Regione AWS per AWS Certificate Manager](cnames-and-https-requirements.md#https-requirements-aws-region).
+ Se gli utenti finali (noti anche come *visualizzatori* o *client*) della tua applicazione Web possono utilizzare HTTPS, puoi anche configurare in modo CloudFront da preferire (o addirittura richiedere) le connessioni HTTPS degli utenti finali. A tale scopo, utilizzare l'impostazione del **criterio del protocollo Viewer**. È possibile impostarlo per reindirizzare gli utenti finali da HTTP a HTTPS o per rifiutare le richieste che utilizzano HTTP. Questa impostazione è disponibile nella CloudFront console e CloudFormation nell' CloudFront API. Per ulteriori informazioni, consulta [Viewer Protocol Policy (Policy protocollo visualizzatore)](DownloadDistValuesCacheBehavior.md#DownloadDistValuesViewerProtocolPolicy).

**Ruotare il nome e il valore dell'intestazione**  
Oltre a utilizzare HTTPS, si consiglia anche di ruotare periodicamente il nome e il valore dell'intestazione. I passaggi di alto livello per eseguire questa operazione sono i seguenti:

1. Configura CloudFront per aggiungere un'intestazione HTTP personalizzata aggiuntiva alle richieste inviate all'Application Load Balancer.

1. Aggiornare la regola del listener Application Load Balancer per inoltrare le richieste che contengono questa intestazione HTTP personalizzata aggiuntiva.

1. Configura CloudFront per interrompere l'aggiunta dell'intestazione HTTP personalizzata originale alle richieste inviate all'Application Load Balancer.

1. Aggiornare la regola del listener di Application Load Balancer per interrompere l'inoltro delle richieste contenenti l'intestazione HTTP personalizzata originale.

Per ulteriori informazioni sull'esecuzione di questi passaggi, vedere le sezioni precedenti.

## (Facoltativo) Limita l'accesso all'origine utilizzando l'elenco di prefissi AWS-managed per CloudFront
<a name="limit-access-to-origin-using-aws-managed-prefixes"></a>

Per limitare ulteriormente l'accesso all'Application Load Balancer, è possibile configurare il gruppo di sicurezza associato all'Application Load Balancer in modo che accetti solo il traffico CloudFront proveniente da quando il servizio utilizza AWS un elenco di prefissi -managed. Ciò impedisce al traffico non originario di raggiungere l'Application Load Balancer a livello di rete (livello 3) o livello di trasporto (livello 4). CloudFront 

Per ulteriori informazioni, consulta il post del CloudFront blog [Limita l'accesso alle tue origini utilizzando l'elenco dei prefissi AWS-managed per Amazon](https://aws.amazon.com//blogs/networking-and-content-delivery/limit-access-to-your-origins-using-the-aws-managed-prefix-list-for-amazon-cloudfront/).

# Limitazione della distribuzione geografica del contenuto
<a name="georestrictions"></a>

Puoi utilizzare *le restrizioni geografiche*, a volte note come *blocchi geografici*, per impedire agli utenti in aree geografiche specifiche di accedere ai contenuti che distribuisci tramite una distribuzione Amazon CloudFront . Per utilizzare le restrizioni geografiche, sono disponibili due opzioni:
+ Utilizza la funzione di restrizioni CloudFront geografiche. Utilizzare questa opzione per limitare l'accesso a tutti i file associati a una distribuzione e per limitare l'accesso a livello di Paese.
+ Utilizzare un servizio di geolocalizzazione di terze parti. Utilizza questa opzione per limitare l'accesso a un sottoinsieme dei file associati a una distribuzione o per limitare l'accesso a un livello più dettagliato che a livello di paese.

**Topics**
+ [

## Usa le restrizioni CloudFront geografiche
](#georestrictions-cloudfront)
+ [

## Utilizzo di un servizio di geolocalizzazione di terze parti
](#georestrictions-geolocation-service)

## Usa le restrizioni CloudFront geografiche
<a name="georestrictions-cloudfront"></a>

Quando un utente richiede i tuoi contenuti, CloudFront in genere fornisce il contenuto richiesto indipendentemente da dove si trova l'utente. Se devi impedire agli utenti di determinati paesi di accedere ai tuoi contenuti, puoi utilizzare la funzionalità di restrizioni CloudFront geografiche per eseguire una delle seguenti operazioni:
+ Accordare agli utenti il permesso di accedere al contenuto solo se si trovano in uno dei Paesi inclusi in una lista di Paesi consentiti.
+ Impedire agli utenti di accedere al contenuto se si trovano in uno dei Paesi inclusi in un elenco di Paesi rifiutati.

Ad esempio, se una richiesta proviene da un paese in cui non sei autorizzato a distribuire i tuoi contenuti, puoi utilizzare le restrizioni CloudFront geografiche per bloccare la richiesta.

**Nota**  
CloudFront determina la posizione degli utenti utilizzando un database di terze parti. La precisione della mappatura tra indirizzi IP e paesi varia in base alla regione. Sulla base di test recenti, la precisione globale è del 99,8%. Se non è in CloudFront grado di determinare la posizione di un utente, CloudFront fornisce il contenuto richiesto dall'utente.

Di seguito viene descritto il funzionamento delle restrizioni geografiche:

1. Supponiamo che hai i diritti per distribuire il tuo contenuto solo in Liechtenstein. Aggiorna la tua CloudFront distribuzione per aggiungere una lista consentita che contiene solo il Liechtenstein. In alternativa, puoi aggiungere un elenco di Paesi rifiutati che contiene ogni Paese eccetto il Liechtenstein.

1. Un utente di Monaco richiede i tuoi contenuti e il DNS indirizza la richiesta a una CloudFront edge location a Milano, Italia.

1. La posizione edge a Milano cerca la distribuzione e determina che l'utente a Monaco non ha l'autorizzazione per scaricare il contenuto.

1. CloudFront restituisce un codice di stato HTTP `403 (Forbidden)` all'utente.

Facoltativamente, è possibile CloudFront configurare la restituzione di un messaggio di errore personalizzato all'utente e specificare per quanto tempo si desidera CloudFront memorizzare nella cache la risposta all'errore per il file richiesto. Il valore predefinito è 10 secondi. Per ulteriori informazioni, consulta [Creazione di una pagina di errore personalizzata per codici di stato HTTP specifici](creating-custom-error-pages.md).

Le restrizioni geografiche sono applicabili a un'intera distribuzione. Se devi applicare una restrizione a una parte dei tuoi contenuti e una restrizione diversa (o nessuna restrizione) a un'altra parte dei tuoi contenuti, devi creare CloudFront distribuzioni separate o [utilizzare](#georestrictions-geolocation-service) un servizio di geolocalizzazione di terze parti.

Se abiliti [i log CloudFront standard (log](AccessLogs.md) di accesso), puoi identificare le richieste CloudFront rifiutate cercando le voci di registro in cui è riportato il valore di (il codice di `sc-status` stato HTTP). `403` Tuttavia, utilizzando solo i log standard, non è possibile distinguere una richiesta CloudFront rifiutata in base alla posizione dell'utente da una richiesta CloudFront rifiutata perché l'utente non aveva l'autorizzazione ad accedere al file per un altro motivo. Se disponi di un servizio di geolocalizzazione di terze parti come Digital Element or MaxMind, puoi identificare la posizione delle richieste in base all'indirizzo IP nella colonna `c-ip` (IP client) nei log di accesso. Per ulteriori informazioni sui log CloudFront standard, vedere. [Registri di accesso (registri standard)](AccessLogs.md)

La procedura seguente spiega come utilizzare la CloudFront console per aggiungere restrizioni geografiche a una distribuzione esistente. Per informazioni su come utilizzare la console per creare una distribuzione, consulta [Creazione di una distribuzione](distribution-web-creating-console.md).<a name="restrictions-geo-procedure"></a>

**Per aggiungere restrizioni geografiche alla tua distribuzione CloudFront web (console)**

1. Accedi a Console di gestione AWS e apri la CloudFront console all'indirizzo[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Nel pannello di navigazione, scegli **Distribuzioni**, quindi scegli la distribuzione che desideri aggiornare.

1. Scegli la scheda **Sicurezza**, quindi scegli **Restrizioni geografiche**.

1. Scegli **Modifica**.

1. Seleziona **Allow list** (Elenco consentiti) per creare un elenco di Paesi consentiti, oppure **Block list** (Elenco di blocchi) per creare un elenco di Paesi bloccati.

1. Aggiungi i Paesi desiderati all'elenco, quindi scegli **Save changes** (Salva modifiche).

## Utilizzo di un servizio di geolocalizzazione di terze parti
<a name="georestrictions-geolocation-service"></a>

Con la funzione di restrizioni CloudFront geografiche, puoi controllare la distribuzione dei tuoi contenuti a livello nazionale per tutti i file che distribuisci con una determinata distribuzione web. Se hai un caso d'uso per le restrizioni geografiche in cui le restrizioni non seguono i confini nazionali o se desideri limitare l'accesso solo ad alcuni dei file che servi tramite una determinata distribuzione, puoi utilizzare un servizio di geolocalizzazione di terze parti. CloudFront Puoi così avere il controllo del contenuto in base non solo al Paese ma anche alla città, al CAP o persino alla latitudine e longitudine.

Quando utilizzi un servizio di geolocalizzazione di terze parti, ti consigliamo di utilizzare CloudFront signedURLs, con il quale puoi specificare una data e un'ora di scadenza dopo le quali l'URL non è più valido. Inoltre, ti consigliamo di utilizzare un bucket Amazon S3 come origine perché puoi quindi utilizzare un [controllo di accesso di CloudFront origine](private-content-restricting-access-to-s3.md) per impedire agli utenti di accedere ai tuoi contenuti direttamente dall'origine. Per ulteriori informazioni sul controllo degli accessi firmati URLs e di origine, consulta. [Offri contenuti privati con cookie firmati URLs e firmati](PrivateContent.md)

La procedura seguente descrive come controllare l'accesso ai file utilizzando un servizio di geolocalizzazione di terza parte.

**Per utilizzare un servizio di geolocalizzazione di terze parti per limitare l'accesso ai file di una distribuzione CloudFront**

1. Ottieni un account con un servizio di geolocalizzazione.

1. Carica il tuo contenuto in un bucket Amazon S3 (S3).

1. Configura Amazon CloudFront e Amazon S3 per offrire contenuti privati. Per ulteriori informazioni, consulta [Offri contenuti privati con cookie firmati URLs e firmati](PrivateContent.md).

1. Scrivi la tua applicazione Web per eseguire le operazioni seguenti:
   + Inviare l'indirizzo IP per ogni richiesta utente al servizio di geolocalizzazione.
   + Valuta il valore restituito dal servizio di geolocalizzazione per determinare se l'utente si trova in un luogo in cui desideri CloudFront distribuire i tuoi contenuti.
   + Se desideri distribuire i tuoi contenuti nella posizione dell'utente, genera un URL firmato per i tuoi CloudFront contenuti. Se non si desidera distribuire i contenuti in tale posizione, restituire il codice di stato HTTP `403 (Forbidden)` all'utente. In alternativa, puoi CloudFront configurare la restituzione di un messaggio di errore personalizzato. Per ulteriori informazioni, consulta [Creazione di una pagina di errore personalizzata per codici di stato HTTP specifici](creating-custom-error-pages.md).

   Per ulteriori informazioni, consulta la documentazione del servizio di geolocalizzazione che stai utilizzando.

Puoi utilizzare una variabile di server Web per ottenere gli indirizzi IP degli utenti che visitano il tuo sito Web. Nota quanto segue:
+ Se il tuo server Web non è connesso a Internet attraverso un sistema di bilanciamento del carico, puoi utilizzare una variabile di server Web per ottenere l'indirizzo IP remoto. Tuttavia, questo indirizzo IP non è sempre l'indirizzo IP dell'utente. Può anche essere l'indirizzo IP di un server proxy, a seconda di come l'utente è connesso a Internet.
+ Se il server Web è connesso a Internet attraverso un sistema di bilanciamento del carico, una variabile di server Web potrebbe contenere l'indirizzo IP del sistema di bilanciamento del carico e non l'indirizzo IP dell'utente. In questa configurazione, consigliamo di utilizzare l'ultimo indirizzo IP nell'intestazione HTTP `X-Forwarded-For`. Questa intestazione in genere contiene più di un indirizzo IP, molti dei quali sono per proxy o sistemi di bilanciamento del carico. L'ultimo indirizzo IP nell'elenco è quello che probabilmente è associato alla posizione geografica dell'utente.

Se il server Web non è connesso a un sistema di bilanciamento del carico, ti consigliamo di utilizzare variabili di server Web anziché l'intestazione `X-Forwarded-For` per evitare lo spoof di indirizzi IP.

# Utilizzo della crittografia a livello di campo per la protezione dei dati sensibili
<a name="field-level-encryption"></a>

Con Amazon CloudFront, puoi applicare end-to-end connessioni sicure ai server di origine utilizzando HTTPS. La crittografia a livello di campo aggiunge un ulteriore livello di sicurezza che consente di proteggere dati specifici durante l'elaborazione del sistema, di modo che solo alcune applicazioni possano visualizzarli.

La crittografia a livello di campo consente agli utenti di caricare in modo sicuro informazioni sensibili nel server Web. Le informazioni sensibili fornite dagli utenti sono crittografate a livello di edge, vicino all'utente e rimangono crittografate in tutto lo stack di applicazioni. Questa crittografia garantisce che solo le applicazioni che necessitano dei dati, e dispongono delle credenziali per decrittarli, siano in grado di farlo.

Per utilizzare la crittografia a livello di campo, quando configuri la CloudFront distribuzione, specifica il set di campi nelle richieste POST che desideri crittografare e la chiave pubblica da utilizzare per crittografarle. Puoi crittografare fino a 10 campi dati in una richiesta Non puoi crittografare tutti i dati in una richiesta con la crittografia a livello di campo; devi specificare singoli campi da crittografare.

Quando la richiesta HTTPS con crittografia a livello di campo viene inoltrata all'origine e la richiesta viene instradata al sottosistema o all'applicazione di origine, i dati sensibili sono ancora crittografati, riducendo il rischio di violazione o di perdita accidentale di dati sensibili. I componenti che richiedono l'accesso ai dati sensibili per ragioni commerciali, come un sistema di elaborazione dei pagamenti che richiede un numero di carta di credito, possono utilizzare la chiave privata appropriata per decrittografare i dati e accedervi.

**Nota**  
Per utilizzare la crittografia a livello di campo, la tua origine deve supportare la codifica in blocchi.

![\[Crittografia a livello di campo in CloudFront\]](http://docs.aws.amazon.com/it_it/AmazonCloudFront/latest/DeveloperGuide/images/fleoverview.png)


CloudFront la crittografia a livello di campo utilizza la crittografia asimmetrica, nota anche come crittografia a chiave pubblica. Fornisci una chiave pubblica e tutti i dati sensibili che specifichi vengono crittografati automaticamente. CloudFront La chiave fornita CloudFront non può essere utilizzata per decrittografare i valori crittografati; solo la tua chiave privata può farlo.

![\[Crittografare unicamente dati sensibili\]](http://docs.aws.amazon.com/it_it/AmazonCloudFront/latest/DeveloperGuide/images/encryptedfields.png)


**Topics**
+ [

## Panoramica della crittografia a livello di campo
](#field-level-encryption-overview)
+ [

## Configurazione della crittografia a livello di campo
](#field-level-encryption-setting-up)
+ [

## Decrittografia dei campi dati nell’origine
](#field-level-encryption-decrypt)

## Panoramica della crittografia a livello di campo
<a name="field-level-encryption-overview"></a>

Di seguito viene fornita una panoramica della configurazione della crittografia a livello di campo. Per informazioni su specifiche fasi, consulta [Configurazione della crittografia a livello di campo](#field-level-encryption-setting-up).

1. **Ottieni una coppia chiave pubblica-chiave privata.** Devi ottenere e aggiungere la chiave pubblica prima di iniziare la configurazione della crittografia a livello di campo in CloudFront.

1. **Crea un profilo di crittografia a livello di campo.** I profili di crittografia a livello di campo, utilizzati dall'utente CloudFront, definiscono i campi da crittografare.

1. **Crea una configurazione di crittografia a livello di campo.** Una configurazione specifica i profili da utilizzare, in base al tipo di contenuto della richiesta o a un argomento di query, per crittografare specifici campi dati. È inoltre possibile scegliere le opzioni di comportamento di inoltro richieste desiderate per diversi scenari. Ad esempio, è possibile impostare il comportamento in base al quale il nome del profilo specificato dall'argomento di interrogazione in un URL di richiesta non esiste in. CloudFront

1. **Crea un collegamento a un comportamento cache.** Collega la configurazione a un comportamento cache per una distribuzione, in modo da specificare quando CloudFront deve crittografare i dati.

## Configurazione della crittografia a livello di campo
<a name="field-level-encryption-setting-up"></a>

Segui le fasi riportate di seguito per iniziare a utilizzare la crittografia a livello di campo. Per informazioni sulle quote (precedentemente note come limiti) relative alla crittografia a livello di campo, consulta [Quote](cloudfront-limits.md).
+ [Fase 1: Creare una coppia di chiavi RSA](#field-level-encryption-setting-up-step1)
+ [Passaggio 2: aggiungi la tua chiave pubblica a CloudFront](#field-level-encryption-setting-up-step2)
+ [Fase 3. Creazione di un profilo per la crittografia a livello di campo](#field-level-encryption-setting-up-step3)
+ [Fase 4: Creazione di una configurazione](#field-level-encryption-setting-up-step4)
+ [Fase 5. Aggiunta di una configurazione a un comportamento cache](#field-level-encryption-setting-up-step5)

### Fase 1: Creare una coppia di chiavi RSA
<a name="field-level-encryption-setting-up-step1"></a>

Per iniziare, è necessario creare una coppia di chiavi RSA che include una chiave pubblica e una chiave privata. La chiave pubblica consente di CloudFront crittografare i dati e la chiave privata consente ai componenti all'origine di decrittografare i campi che sono stati crittografati. Per creare una coppia di chiavi, puoi utilizzare OpenSSL o un altro strumento. La dimensione della chiave deve essere 2048 bit.

Ad esempio, se utilizzi OpenSSL, puoi utilizzare il seguente comando per generare una coppia di chiavi con una lunghezza di 2048 bit e salvarla nel file `private_key.pem`:

```
openssl genrsa -out private_key.pem 2048
```

Il file risultante contiene la chiave pubblica e quella privata. Per estrarre la chiave pubblica da quel file, esegui il seguente comando:

```
openssl rsa -pubout -in private_key.pem -out public_key.pem
```

Il file della chiave pubblica (`public_key.pem`) contiene il valore della chiave codificata che verrà incollato nella fase seguente.

### Passaggio 2: aggiungi la tua chiave pubblica a CloudFront
<a name="field-level-encryption-setting-up-step2"></a>

Dopo aver ottenuto la coppia di chiavi RSA, aggiungi la tua chiave pubblica a CloudFront.<a name="field-level-encryption-setting-up-step2-procedure"></a>

**Per aggiungere la tua chiave pubblica a CloudFront (console)**

1. Accedi a Console di gestione AWS e apri la CloudFront console all'indirizzo[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Nel riquadro di navigazione, scegli **Public key (Chiave pubblica)**.

1. Scegli **Add public key (Aggiungi chiave pubblica)**.

1. Per **Key name (Nome chiave)**, digita un nome univoco per la chiave. Il nome non può contenere spazi e può includere solo caratteri alfanumerici, di sottolineatura (\$1) e trattini (-). Il numero massimo di caratteri è 128.

1. Per **Key value (Valore chiave)**, incollare il valore della chiave codificata per la chiave pubblica, incluse le righe `-----BEGIN PUBLIC KEY-----` e `-----END PUBLIC KEY-----`.

1. Per **Comment (Commento)**, aggiungi un commento facoltativo. Ad esempio, la data di scadenza della chiave pubblica.

1. Scegliere **Aggiungi**.

È possibile aggiungere altre chiavi da utilizzare CloudFront ripetendo i passaggi della procedura.

### Fase 3. Creazione di un profilo per la crittografia a livello di campo
<a name="field-level-encryption-setting-up-step3"></a>

Dopo aver aggiunto almeno una chiave pubblica CloudFront, create un profilo che indichi CloudFront quali campi crittografare.<a name="field-level-encryption-setting-up-step3-procedure"></a>

**Creazione di un profilo per la crittografia a livello di campo (console)**

1. Nel riquadro di navigazione, scegli **Field-level encryption (Crittografia a livello di campo)**.

1. Scegli **Create profile (Crea profilo)**.

1. Riempi i seguenti campi:  
**Nome del profilo**  
Digita un nome univoco per il profilo. Il nome non può contenere spazi e può includere solo caratteri alfanumerici, di sottolineatura (\$1) e trattini (-). Il numero massimo di caratteri è 128.  
**Public key name (Nome chiave pubblica)**  
Nell'elenco a discesa, scegli il nome di una chiave pubblica a cui hai aggiunto CloudFront nel passaggio 2. CloudFront utilizza la chiave per crittografare i campi specificati in questo profilo.  
**Nome del provider**  
Digitare una descrizione che consenta di identificare la chiave, ad esempio il provider dove hai ottenuto la coppia di chiavi. Questa informazione, insieme alla chiave privata, è necessaria quando le applicazioni decrittano i campi di dati. Il nome di provider non può contenere spazi e può includere solo caratteri alfanumerici, due punti (:), caratteri di sottolineatura (\$1) e trattini (-). Il numero massimo di caratteri è 128.  
**Field name pattern to match (Modello di nome di campo da abbinare)**  
Digita i nomi di campi dati, oppure i modelli che identificano i nomi di campi dati nella richiesta, che CloudFront deve crittografare. Scegli l'opzione \$1 per aggiungere tutti i campi che desideri crittografare con questa chiave.  
Per lo schema del nome del campo, puoi digitare il nome completo del campo dati, ad esempio DateOfBirth, o solo la prima parte del nome con un carattere jolly (\$1), ad esempio CreditCard \$1. Il modello di nome di campo deve includere solo caratteri alfanumerici, parentesi quadre ([ e ]), punti (.), caratteri di sottolineatura (\$1) e trattini (-), oltre al carattere jolly facoltativo (\$1).  
Assicurati di non utilizzare caratteri che si sovrappongono per diversi modelli di nome di campo. Ad esempio, se disponi di un modello di nome di campo ABC\$1, non puoi aggiungere un altro modello di nome di campo AB\$1. Inoltre, i nomi di campo fanno distinzione tra maiuscole e minuscole e il numero massimo di caratteri che puoi utilizzare è 128.  
**Commento**  
(Facoltativo) Digita un commento sul profilo. Il numero massimo di caratteri che puoi utilizzare è 128.

1. Dopo che hai riempito i campi, scegli **Create profile (Crea profilo)**.

1. Se desideri aggiungere ulteriori profili, scegli **Add profile (Aggiungi profilo)**.

### Fase 4: Creazione di una configurazione
<a name="field-level-encryption-setting-up-step4"></a>

Dopo aver creato uno o più profili di crittografia a livello di campo, create una configurazione che specifichi il tipo di contenuto della richiesta che include i dati da crittografare, il profilo da utilizzare per la crittografia e altre opzioni che specificano come gestire la crittografia. CloudFront 

Ad esempio, quando non è CloudFront possibile crittografare i dati, è possibile specificare se bloccare o CloudFront inoltrare una richiesta all'origine nei seguenti scenari:
+ **Quando il tipo di contenuto di una richiesta non è in una configurazione**: se non hai aggiunto un tipo di contenuto a una configurazione, puoi specificare se CloudFront inoltrare la richiesta con quel tipo di contenuto all'origine senza crittografare i campi di dati oppure bloccare la richiesta e restituire un errore.
**Nota**  
Se aggiungi un tipo di contenuto a una configurazione ma non hai specificato un profilo da utilizzare con quel tipo, inoltra CloudFront sempre le richieste con quel tipo di contenuto all'origine.
+ **Quando il nome di profilo fornito in un argomento di query è sconosciuto**: quando specifichi l'argomento della `fle-profile` query con un nome di profilo che non esiste per la tua distribuzione, puoi CloudFront specificare se inviare la richiesta all'origine senza crittografare i campi di dati oppure bloccare la richiesta e restituire un errore.

In una configurazione, puoi anche specificare se fornire un profilo come argomento di query in un URL sostituisce un profilo che hai mappato al tipo di contenuto per quella query. Per impostazione predefinita, CloudFront utilizza il profilo che hai mappato a un tipo di contenuto, se ne specifichi uno. Ciò ti consente di avere un profilo che viene utilizzato per impostazione predefinita ma di decidere, per alcune richieste, di applicare un altro profilo.

Quindi, ad esempio, puoi specificare nella tua configurazione **SampleProfile** come il profilo di argomento di query da utilizzare. Quindi puoi utilizzare l'URL `https://d1234.cloudfront.net?fle-profile=SampleProfile` anziché`https://d1234.cloudfront.net`, da CloudFront utilizzare **SampleProfile** per questa richiesta, anziché il profilo che configureresti per il tipo di contenuto della richiesta.

Puoi creare fino a 10 configurazioni per un singolo account e quindi associare una delle configurazioni al comportamento cache di qualsiasi distribuzione per l'account.<a name="field-level-encryption-setting-up-step4-procedure"></a>

**Creazione di una configurazione per la crittografia a livello di campo (console)**

1. Nella pagina **Field-level encryption (Crittografia a livello di campo)**, scegli **Create configuration (Crea configurazione)**.

   Nota: se non hai creato almeno un profilo, l'opzione per la creazione di una configurazione non sarà visualizzata.

1. Riempi i campi riportati di seguito per specificare il profilo da utilizzare Alcuni campi non possono essere modificati.  
**Content type (Tipo di contenuto) (non modificabile)**  
Il tipo di contenuto è impostato su `application/x-www-form-urlencoded` e non può essere modificato.  
**Default profile ID (ID profilo di default) (facoltativo)**  
Nell'elenco a discesa, scegli il profilo che intendi mappare al tipo di contenuto nel campo **Content type (Tipo di contenuto)**.  
**Content format (Formato contenuto) (non modificabile)**  
Il formato del contenuto è impostato su `URLencoded` e non può essere modificato.

1. Se desideri modificare il comportamento CloudFront predefinito per le seguenti opzioni, seleziona la casella di controllo appropriata.  
**Forward request to origin when request's content type is not configured (Inoltra richiesta all'origine quando il tipo di contenuto non è configurato)**  
Seleziona la casella di controllo per consentire l'inoltro della richiesta all'origine *se non hai specificato un profilo da utilizzare per il tipo di contenuto della richiesta*.  
**Override the profile for a content type with a provided query argument (Sovrascrivi il profilo per un tipo di contenuto con un argomento di query fornito)**  
Seleziona la casella di controllo per consentire a un profilo fornito in un argomento di query di *sovrascrivere il profilo che hai specificato per un tipo di contenuto*.

1. Se selezioni la casella di controllo per consentire a un argomento di query di sovrascrivere il profilo di default, devi riempire i seguenti campi aggiuntivi per la configurazione. Puoi creare fino a cinque di queste mappature di argomento di query da utilizzare con le query.  
**Query argument (Argomento di query)**  
Digitate il valore che desiderate includere nell' URLs argomento della `fle-profile` query. Questo valore indica a CloudFront di utilizzare l'ID profilo (che specifichi nel campo successivo) associato a questo argomento di query per la crittografia a livello di campo di questa query.  
Il numero massimo di caratteri che puoi utilizzare è 128. Questo valore non può contenere spazi e deve utilizzare solo caratteri alfanumerici o i seguenti caratteri: trattini (-), punti (.), caratteri di sottolineatura (\$1), asterischi (\$1), segni più (\$1), percentuali (%).  
**Profile ID (ID profilo)**  
Nell'elenco a discesa, scegli il profilo da associare al valore che hai digitato per **Query argument (Argomento di query)**.  
**Forward request to origin when the profile specified in a query argument does not exist (Inoltra richiesta all'origine quando il profilo specificato in un argomento di query non esiste)**  
Seleziona la casella di controllo per consentire l'inoltro della richiesta all'origine *se il profilo specificato in un argomento di query non è definito in CloudFront*.

### Fase 5. Aggiunta di una configurazione a un comportamento cache
<a name="field-level-encryption-setting-up-step5"></a>

Per utilizzare la crittografia a livello di campo, collega una configurazione a un comportamento cache per una distribuzione aggiungendo l'ID configurazione come valore per la distribuzione.

**Importante**  
Per collegare una configurazione di crittografia a livello di campo a un comportamento della cache, la distribuzione deve essere configurata per utilizzare sempre HTTPS e per accettare HTTP e richieste `POST` e `PUT` dai visualizzatori. Deve essere vera una delle condizioni seguenti:  
**Viewer Protocol Policy (Policy protocollo visualizzatore)** del comportamento della cache deve essere impostato su **Redirect HTTP to HTTPS (Reindirizza HTTP a HTTPS)** o su **HTTPS Only (Solo HTTPS)**. (In CloudFormation o nell' CloudFront API, `ViewerProtocolPolicy` deve essere impostato su `redirect-to-https` o`https-only`.)
Il valore **Allowed HTTP Methods (Metodi HTTP consentiti)** del comportamento della cache deve essere impostato su **GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE**. (In CloudFormation o l' CloudFront API, `AllowedMethods` deve essere impostato su `GET``HEAD`,`OPTIONS`,`PUT`,`POST`,`PATCH`,`DELETE`. Questi possono essere specificati in qualsiasi ordine.)
**Origin Protocol Policy (Policy protocollo origine)** delle impostazioni dell'origine deve essere impostato su **Match Viewer (Corrispondenza visualizzatore)** o **HTTPS Only (Solo HTTPS)**. (In CloudFormation o nell' CloudFront API, `OriginProtocolPolicy` deve essere impostato su `match-viewer` o`https-only`.)

Per ulteriori informazioni, consulta [Riferimento a tutte le impostazioni di distribuzione](distribution-web-values-specify.md).

## Decrittografia dei campi dati nell’origine
<a name="field-level-encryption-decrypt"></a>

CloudFront crittografa i campi di dati utilizzando. [AWS Encryption SDK](https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/introduction.html) I dati rimangono crittografati nell'intero stack di applicazioni e sono accessibili solo alle applicazioni che dispongono delle credenziali per decrittografarli.

Dopo la crittografia, il testo cifrato è codificato in base64. Quando le applicazioni eseguono la decrittazione del testo nell'origine, devono prima decodificarlo e quindi utilizzare il kit SDK di crittografia AWS per decrittare i dati.

Il codice di esempio che segue illustra il modo in cui le applicazioni possono decrittare i dati nell'origine. Tieni presente quanto segue: 
+ Per semplificare l'esempio, le chiavi private e pubbliche (in formato DER) vengono caricate dai file nella directory di lavoro. In pratica, devi archiviare la chiave privata in una posizione offline protetta, ad esempio un modulo di protezione hardware offline, e distribuire la chiave pubblica al team di sviluppo.
+ CloudFront utilizza informazioni specifiche durante la crittografia dei dati e lo stesso set di parametri deve essere utilizzato all'origine per decrittografarli. I parametri CloudFront utilizzati durante l'inizializzazione includono quanto segue: MasterKey 
  + PROVIDER\$1NAME: hai specificato questo valore quando hai creato un profilo di crittografia a livello di campo. Utilizza lo stesso valore qui.
  + KEY\$1NAME: hai creato un nome per la tua chiave pubblica quando l'hai caricata su CloudFront, quindi hai specificato il nome della chiave nel profilo. Utilizza lo stesso valore qui.
  + ALGORITMO: CloudFront utilizza `RSA/ECB/OAEPWithSHA-256AndMGF1Padding` come algoritmo per la crittografia, quindi è necessario utilizzare lo stesso algoritmo per decrittografare i dati.
+ Se esegui il codice di esempio riportato di seguito con il testo cifrato come input, i dati decrittati vengono inviati alla console. Per ulteriori informazioni, consulta il [codice di esempio Java](https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/java-example-code.html) nell'Encryption SDK. AWS 

### Codice di esempio
<a name="field-level-encryption-decrypt-sample"></a>

```
import java.nio.file.Files;
import java.nio.file.Paths;
import java.security.KeyFactory;
import java.security.PrivateKey;
import java.security.PublicKey;
import java.security.spec.PKCS8EncodedKeySpec;
import java.security.spec.X509EncodedKeySpec;

import org.apache.commons.codec.binary.Base64;

import com.amazonaws.encryptionsdk.AwsCrypto;
import com.amazonaws.encryptionsdk.CryptoResult;
import com.amazonaws.encryptionsdk.jce.JceMasterKey;

/**
 * Sample example of decrypting data that has been encrypted by CloudFront field-level encryption.
 */
public class DecryptExample {

    private static final String PRIVATE_KEY_FILENAME = "private_key.der";
    private static final String PUBLIC_KEY_FILENAME = "public_key.der";
    private static PublicKey publicKey;
    private static PrivateKey privateKey;

    // CloudFront uses the following values to encrypt data, and your origin must use same values to decrypt it.
    // In your own code, for PROVIDER_NAME, use the provider name that you specified when you created your field-level
    // encryption profile. This sample uses 'DEMO' for the value.
    private static final String PROVIDER_NAME = "DEMO";
    // In your own code, use the key name that you specified when you added your public key to CloudFront. This sample
    // uses 'DEMOKEY' for the key name.
    private static final String KEY_NAME = "DEMOKEY";
    // CloudFront uses this algorithm when encrypting data.
    private static final String ALGORITHM = "RSA/ECB/OAEPWithSHA-256AndMGF1Padding";

    public static void main(final String[] args) throws Exception {

        final String dataToDecrypt = args[0];

        // This sample uses files to get public and private keys.
        // In practice, you should distribute the public key and save the private key in secure storage.
        populateKeyPair();

        System.out.println(decrypt(debase64(dataToDecrypt)));
    }

    private static String decrypt(final byte[] bytesToDecrypt) throws Exception {
        // You can decrypt the stream only by using the private key.

        // 1. Instantiate the SDK
        final AwsCrypto crypto = new AwsCrypto();

        // 2. Instantiate a JCE master key
        final JceMasterKey masterKey = JceMasterKey.getInstance(
                publicKey,
                privateKey,
                PROVIDER_NAME,
                KEY_NAME,
                ALGORITHM);

        // 3. Decrypt the data
        final CryptoResult <byte[], ? > result = crypto.decryptData(masterKey, bytesToDecrypt);
        return new String(result.getResult());
    }

    // Function to decode base64 cipher text.
    private static byte[] debase64(final String value) {
        return Base64.decodeBase64(value.getBytes());
    }

    private static void populateKeyPair() throws Exception {
        final byte[] PublicKeyBytes = Files.readAllBytes(Paths.get(PUBLIC_KEY_FILENAME));
        final byte[] privateKeyBytes = Files.readAllBytes(Paths.get(PRIVATE_KEY_FILENAME));
        publicKey = KeyFactory.getInstance("RSA").generatePublic(new X509EncodedKeySpec(PublicKeyBytes));
        privateKey = KeyFactory.getInstance("RSA").generatePrivate(new PKCS8EncodedKeySpec(privateKeyBytes));
    }
}
```