Cloaking dell'origine

Il cloaking dell’origine è un insieme di tecniche volte a ridurre la superficie di attacco delle applicazioni web. Consigliamo di utilizzare CloudFront come punto di accesso singolo alle applicazioni web su cui vengono applicati i controlli di sicurezza, come le protezioni contro gli attacchi DDoS e i bot indesiderati. Il cloaking dell’origine impedisce agli attori malintenzionati di aggirare CloudFront e i suoi controlli di sicurezza per attaccare direttamente l'origine, utilizzando le regole del firewall per bloccare il traffico che non proviene dal punto di ingresso di CloudFront. Il cloaking dell'origine può essere ottenuto su più livelli del modello OSI.

Il cloaking dell'origine a livello di rete protegge la tua origine da tutti gli attacchi diretti alla tua origine. Tuttavia, un utente malintenzionato potrebbe configurare una distribuzione CloudFront con il tuo nome di dominio di origine che ha scoperto, prendendo di mira la tua origine con attacchi a livello di applicazione attraverso la sua distribuzione CloudFront, aggirando efficacemente i controlli di sicurezza configurati sulla tua distribuzione CloudFront.

Oltre a offuscare il tuo nome di dominio di origine (ad esempio, evita origin.example.com!), puoi aggiungere controlli di accesso a livello di applicazione tra CloudFront e la tua origine per mitigare il rischio appena descritto. Ciò può essere implementato in diversi modi a seconda del tipo di origine e del requisito di sicurezza.

OAC è una funzionalità di CloudFront che consente di firmare le richieste a determinati tipi di origini in modo nativo utilizzando l'algoritmo AWS Signature versione 4 (sigv4) basato sulle policy IAM. Oggi, OAC è compatibile con S3, MediaStore , MediaPackage, URL della funzione Lambda e Lambda per oggetti S3. Quando OAC viene utilizzato con S3, puoi mantenere privato il tuo bucket S3, con accesso esclusivo a CloudFront basato sulle policy del bucket S3.

Quando il tipo di origine non è supportato da OAC, puoi firmare le richieste della tua origine utilizzando le funzioni edge. Le implementazioni di esempio sono spiegate nei seguenti blog:

• Firmare le richieste utilizzando Sigv4 con Lambda@Edge sul Gateway AWS API
  
• Firmare le richieste utilizzando MD5 con Lambda@Edge sui server NGINX

Se la tua origine non supporta la firma delle richieste o non ritieni che questo livello di controllo degli accessi sia necessario per la tua applicazione, puoi configurare CloudFront per inviare un'intestazione personalizzata contenente un segreto condiviso con la tua origine, che può essere convalidato da quest'ultima per elaborare la richiesta. Considera il seguente esempio di implementazione:

• Origine basata su ALB. Puoi convalidare l'intestazione segreta su un'origine basata su ALB utilizzando una regola ALB o una regola AWS WAF se l'ALB è già associato a un WebACL di AWS WAF.
• Origine basata su Gateway API. Puoi convalidare l'intestazione segreta su un gateway API utilizzando le chiavi API.
• Origine basata su NGINX. Supponendo che CloudFront invii un'intestazione personalizzata x-CloudFront con valore abc123, puoi convalidare l'intestazione segreta su un server web basato su Nginx (basato su cloud o on-premise) aggiungendo il seguente codice nel tag del server del file di configurazione di Nginx /etc/nginx/nginx.conf:
  
  if ($http_x_cloudfront != "abc123") {
      return 403;
  }
• Origine basata su Apache. Supponendo che CloudFront invii un'intestazione personalizzata x-CloudFront con valore abc123, puoi convalidare l'intestazione segreta su un server web basato su Apache (basato su cloud o on-premise) aggiungendo il seguente codice nel file di configurazione httpd.conf (e nel file ssl.conf se utilizzato):
  
  RewriteEngine On
  RewriteCond %{HTTP:x-cloudfront} !^abc123$ [NC]
  RewriteRule ^ - [F]

In tutti i casi, si consiglia di ruotare questo segreto condiviso in maniera regolare per ridurre il rischio che essp sia divulgato. Nelle implementazioni di esempio condivise sopra, sia quella con API Gateway che quella con ALB includono un'automazione per la rotazione segreta.

CloudFront pubblica gli indirizzi IP utilizzati per stabilire connessioni TCP con la tua origine, con il valore CLOUDFRONT_ORIGIN_FACING del campo servizio. Puoi implementare un ACL sul firewall di origine per bloccare il traffico non proveniente dagli IP rivolti all'origine di CloudFront. Per questo approccio, è necessario abbonarsi alle modifiche IP per aggiornare l'ACL. Consulta questo post del blog per scoprire come implementare il cloaking delle origini su server Web on-premise utilizzando firewall di terze parti.

Se la tua origine è ospitata in un Amazon VPC, puoi semplicemente implementare il cloaking dell'origine aggiungendo l'elenco di prefissi gestito da AWS per Amazon CloudFront al gruppo di sicurezza collegato alla tua origine (EC2, NLB, ALB, ecc...).

In entrambi i casi, si consiglia di stabilire connessioni sicure tramite TLS tra CloudFront e la tua origine.

Se la tua origine è in sede, valuta la possibilità di configurare AWS Direct Connect tra la tua infrastruttura locale e AWS utilizzando interfacce virtuali pubbliche sulla connessione Direct Connect. In questo modo, il traffico tra l'origine e CloudFront viene trasportato su una rete gestita privatamente, non raggiungibile da Internet.