Dissimulation de l'origine

La dissimulation de l'origine est un ensemble de techniques visant à réduire la surface d'attaque des applications Web. Il est recommandé d'utiliser CloudFront comme point d'entrée unique vers les applications Web, où des contrôles de sécurité, tels que des protections contre les attaques DDoS et les robots indésirables, sont appliqués. La dissimulation de l'origine empêche les acteurs malveillants de contourner CloudFront et ses contrôles de sécurité pour attaquer directement l'origine, en utilisant des règles de pare-feu pour bloquer tout trafic ne provenant pas du point d'entrée de CloudFront. La dissimulation de l'origine peut être réalisé au niveau de plusieurs couches du modèle OSI.

La dissimulation de l'origine sur la couche réseau protège votre origine de toutes les attaques ciblant directement votre origine. Toutefois, un attaquant pourrait configurer une distribution CloudFront avec votre nom de domaine d'origine découvert et cibler votre origine avec des attaques de la couche applicative via sa distribution CloudFront, contournant ainsi efficacement les contrôles de sécurité que vous avez configurés sur votre propre distribution CloudFront.

En plus de masquer votre nom de domaine d'origine (par exemple, évitez origin.example.com !) , vous pouvez ajouter des contrôles d'accès à la couche applicative entre CloudFront et votre site d'origine afin de réduire les risques ci-dessus. Cela peut être mis en œuvre de différentes manières en fonction du type d'origine et des exigences de sécurité.

L'OAC est une fonctionnalité de CloudFront qui vous permet de signer des demandes pour certains types d'origines de manière native à l'aide de l'algorithme AWS Signature Version 4 (sigv4) basé sur les politiques IAM. Aujourd'hui, l'OAC est compatible avec S3, MediaStore, MediaPackage, les URL de la fonction Lambda et S3 Object Lambda. Lorsque l'OAC est utilisé avec S3, vous pouvez préserver la confidentialité de votre compartiment S3, avec un accès exclusif à CloudFront conformément aux politiques du compartiment S3.

Lorsque le type d'origine n'est pas pris en charge par l'OAC, vous pouvez signer des demandes adressées à votre origine à l'aide des fonctions de périphérie. Des exemples d'implémentations sont expliqués dans les blogs suivants :

• Signez des demandes à l'aide de Sigv4 avec Lambda@Edge vers AWS API Gateway
  
• Signez des demandes à l'aide de MD5 avec Lambda@Edge vers des serveurs NGINX

Si votre origine ne prend pas en charge la signature des demandes, ou si vous ne considérez pas que ce niveau de contrôle d'accès est nécessaire pour votre application, vous pouvez configurer CloudFront pour envoyer un en-tête personnalisé contenant un secret partagé avec votre origine, qui peut être validé par votre origine pour traiter la demande. Prenons l'exemple de mise en œuvre suivant :

• Origine basée sur ALB. Vous pouvez valider l'en-tête secret sur une origine basée sur ALB à l'aide d'une règle ALB ou d'une règle AWS WAF si votre ALB est déjà associé à une WebACL AWS WAF.
• Origine basée sur API Gateway. Vous pouvez valider l'en-tête secret sur une API Gateway à l'aide de clés d'API.
• Origine basée sur NGINX. En supposant que CloudFront envoie un en-tête personnalisé X-CloudFront avec la valeur abc123, vous pouvez valider l'en-tête secret sur un serveur Web basé sur Nginx (basé sur le cloud ou sur site) en ajoutant le code suivant dans la balise serveur du fichier de configuration Nginx /etc/nginx/nginx.conf :
  
  if ($http_x_cloudfront != "abc123") {
      return 403;
  }
• Origine basée sur Apache. En supposant que CloudFront envoie un en-tête personnalisé X-CloudFront avec la valeur abc123, vous pouvez valider l'en-tête secret sur un serveur Web basé sur Apache (basé sur le cloud ou sur site) en ajoutant le code suivant dans le fichier de configuration httpd.conf (et dans le fichier ssl.conf s'il est utilisé) :
  
  RewriteEngine On
  RewriteCond %{HTTP:x-cloudfront} !^abc123$ [NC]
  RewriteRule ^ - [F]

Dans tous les cas, il est recommandé d'alterner régulièrement ce secret partagé afin de réduire le risque de fuite de secrets. Dans les exemples d'implémentations partagés ci-dessus, celle avec API Gateway et celle avec ALB incluent une automatisation pour la rotation des secrets.

CloudFront publie les adresses IP utilisées pour établir des connexions TCP avec votre origine, avec la valeur CLOUDFRONT_ORIGIN_FACING du champ service. Vous pouvez implémenter une ACL sur le pare-feu de votre serveur d'origine pour bloquer le trafic ne provenant pas des adresses IP d'origine de CloudFront. Avec cette approche, vous devez vous abonner aux modifications d'adresse IP pour mettre à jour votre ACL. Consultez cet article de blog pour savoir comment implémenter la dissimulation de l'origine sur des serveurs Web sur site à l'aide de pare-feux tiers.

Si votre origine est hébergée sur un VPC Amazon, vous pouvez simplement implémenter la dissimulation de l'origine en ajoutant la liste de préfixes gérée par AWS pour Amazon CloudFront au groupe de sécurité associé à votre origine (EC2, NLB, ALB, etc.).

Dans les deux cas, il est recommandé d'établir des connexions sécurisées via TLS entre CloudFront et votre origine.

Si votre origine se trouve dans vos locaux, envisagez de configurer AWS Direct Connect entre votre infrastructure sur site et AWS à l'aide d'interfaces virtuelles publiques sur la connexion Direct Connect. Ainsi, le trafic entre votre point d'origine et CloudFront est transporté sur un réseau géré de manière privée, inaccessible depuis Internet.