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.

Quando la tua origine ti consente di controllare l'accesso alla rete in entrata, aggiungi delle restrizioni per consentire solo il traffico proveniente dalla rete di CloudFront.

Se la tua origine è un'istanza EC2, un Application Load Balancer o un Network Load Balancer, puoi mantenere la tua origine in una sottorete privata del tuo VPC e sfruttare la funzionalità VPC Origins di CloudFront. Ti consente di limitare l'accesso esclusivamente alle distribuzioni CloudFront configurate con VPC Origins nel tuo account AWS.

Se devi lasciare tali risorse in una sottorete pubblica (ad esempio se al tuo ALB accederanno più CDN) o hai un tipo di origine non supportato da VPC Origins di CloudFront, puoi limitare l'accesso a CloudFront utilizzando i gruppi di sicurezza. Devi associare la tua origine a un gruppo di sicurezza, a cui aggiungere l'elenco di prefissi gestito da AWS per Amazon CloudFront.

Se la tua origine è on-premises, puoi limitare l'accesso a CloudFront consentendo di elencare gli indirizzi IP di origine di CloudFront rivolti verso l'origine, che possono essere trovati in questo elenco di IP quando filtri il valore CLOUDFRONT_ORIGIN_FACING del campo servizio. 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-premises utilizzando firewall di terze parti. Per un ulteriore isolamento da Internet, valuta la possibilità di configurare AWS Direct Connect tra la tua infrastruttura on-premises e AWS utilizzando un'interfaccia virtuale pubblica sulla connessione Direct Connect.

Il controllo degli accessi a livello di rete è un inizio, ma potrebbe non essere sufficiente per le tue esigenze. Ad esempio, se qualcuno scopre il nome di dominio di origine nella tua sede, può creare una distribuzione CloudFront nel suo account AWS e bypassare la tua distribuzione. Un altro esempio è che quando utilizzi la funzionalità VPC Origins, potresti voler limitare la tua origine a una distribuzione CloudFront specifica nel tuo account AWS invece di renderla accessibile a tutte le distribuzioni CloudFront configurate con VPC Origins nel tuo account AWS. In questo caso, considera l'hardening con il controllo degli accessi a livello di applicazione.

Il blocco di alcuni tipi di origini su CloudFront è reso molto semplice con Origin Access Control (OAC), una funzionalità di CloudFront che firma le richieste a determinati tipi di origini in modo nativo utilizzando l'algoritmo AWS Signature Version 4 (sigv4) in base alle policy IAM. Oggi, OAC è compatibile con S3, MediaStore, MediaPackage, URL di funzione Lambda e Lambda per oggetti S3. Quando OAC viene utilizzato con S3, è possibile mantenere privato il proprio bucket S3 con l'accesso esclusivo a CloudFront basato sulle policy del bucket S3.

Quando il tipo di origine non è supportato da OAC, puoi firmare le richieste alla tua origine utilizzando le funzioni edge. Le implementazioni di esempio sono spiegate nei seguenti post di 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 di modo che invii 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 di divulgazione. Nelle implementazioni di esempio condivise sopra, sia quella con API Gateway sia quella con ALB includono un'automazione per la rotazione segreta.