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ée au niveau de plusieurs couches du modèle OSI.

Lorsque votre origine vous permet de contrôler l’accès réseau entrant, ajoutez des restrictions pour n’autoriser que le trafic provenant du réseau de CloudFront.

Si votre origine est une instance EC2, un Application Load Balancer ou un Network Load Balancer, vous pouvez conserver votre origine dans un sous-réseau privé de votre VPC et tirer parti de la fonctionnalité VPC Origins de CloudFront. Cela vous permet de restreindre l’accès exclusivement aux distributions CloudFront configurées avec VPC Origins dans votre propre compte AWS.

Si vous devez laisser ces ressources dans un sous-réseau public (par exemple, votre ALB sera accessible par plusieurs CDN), ou si vous avez un type d’origine qui n’est pas pris en charge par la fonctionnalité VPC Origins de CloudFront, vous pouvez restreindre l’accès à CloudFront à l’aide de groupes de sécurité. Vous devez associer votre origine à un groupe de sécurité, auquel vous ajoutez la liste de préfixes gérée par AWS pour Amazon CloudFront.

Si votre origine se trouve dans vos locaux, vous pouvez restreindre l’accès à CloudFront en autorisant la liste des adresses IP d’origine de CloudFront, qui figurent dans cette liste IP lorsque vous filtrez sur la valeur CLOUDFRONT_ORIGIN_FACING du champ de service. 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. Pour vous isoler davantage d’Internet, envisagez de configurer AWS Direct Connect entre votre infrastructure sur site et AWS à l’aide d’interfaces virtuelles publiques sur la connexion Direct Connect.

Le contrôle d’accès au niveau de la couche réseau est un point de départ, mais il se peut qu’il ne soit pas suffisant pour vous. Par exemple, si quelqu’un découvre le nom de domaine d’origine dans vos locaux, il peut créer une distribution CloudFront dans son propre compte AWS et contourner votre propre distribution. Autre exemple : lorsque vous utilisez la fonctionnalité VPC Origin, vous souhaiterez peut-être limiter votre origine à une distribution CloudFront spécifique dans votre compte AWS, au lieu de la rendre accessible à toutes les distributions CloudFront configurées avec VPC Origins sur votre compte AWS. Dans ce cas, pensez à renforcer le contrôle d’accès à la couche applicative.

Le verrouillage de certains types d’origines sur CloudFront est très simple avec Origin Access Control (OAC), une fonctionnalité de CloudFront qui signe les requêtes vers 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 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 requêtes à l’aide de Sigv4 avec Lambda@Edge vers AWS API Gateway
• Signez des requêtes à l’aide de MD5 avec Lambda@Edge vers des serveurs NGINX

Si votre origine ne prend pas en charge la signature des requêtes, 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 requête. 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.