Ocultamiento de origen

El ocultamiento de origen es un conjunto de técnicas que tienen como objetivo reducir la superficie expuesta a ataques de las aplicaciones web. Se recomienda utilizar CloudFront como punto de entrada único a las aplicaciones web, donde se aplican los controles de seguridad, como las protecciones contra los ataques DDoS y los bots no deseados. El ocultamiento de origen evita que los actores malintencionados pasen por alto CloudFront y sus controles de seguridad para atacar el origen directamente mediante reglas de firewall para bloquear el tráfico que no proceda del punto de entrada de CloudFront. El ocultamiento de origen se puede lograr en varias capas del modelo OSI.

Cuando su origen le permita controlar el acceso entrante a la red, añada restricciones para permitir únicamente el tráfico que proviene de la red de CloudFront.

Si su origen es una instancia EC2, un equilibrador de carga de aplicación o un equilibrador de carga de red, puede mantener su origen en una subred privada de su VPC y aprovechar la característica Orígenes de VPC de CloudFront. Le permite restringir el acceso exclusivamente a las distribuciones de CloudFront configuradas con Orígenes de VPC en su propia cuenta de AWS.

Si tiene que dejar dichos recursos en una subred pública (por ejemplo, varias CDN accederán a su ALB) o si tiene un tipo de origen que no es compatible con Orígenes de VPC de CloudFront, puede restringir el acceso a CloudFront mediante grupos de seguridad. Debe asociar su origen a un grupo de seguridad, al que debe agregar la lista de prefijos administrada por AWS para Amazon CloudFront.

Si su origen está en sus instalaciones, puede restringir el acceso a CloudFront permitiendo listas de las direcciones IP de origen de CloudFront, que se encuentran en esta lista de IP al filtrar por el valor CLOUDFRONT_ORIGIN_FACING del campo servicio. Con este enfoque, debe suscribirse a los cambios de IP para actualizar la ACL. Consulte esta entrada de blog para obtener información sobre cómo implementar el ocultamiento de origen en servidores web en las instalaciones mediante firewalls de terceros. Para aislarse aún más de internet, considere la posibilidad de configurar AWS Direct Connect entre su infraestructura en las instalaciones y AWS mediante una interfaz virtual pública en la conexión de Direct Connect.

El control de acceso en la capa de red es un punto de partida, pero puede que no sea suficiente para usted. Por ejemplo, si alguien descubre el nombre de dominio de origen en sus instalaciones, puede crear una distribución de CloudFront en su propia cuenta de AWS y omitir su propia distribución. Otro ejemplo es que, cuando utiliza la característica Orígenes de VPC, es posible que desee restringir su origen a una distribución de CloudFront específica en su cuenta de AWS, en lugar de hacerlo accesible a todas las distribuciones de CloudFront configuradas con Orígenes de VPC en su cuenta de AWS. En este caso, considere la posibilidad de reforzarlo con el control de acceso a la capa de aplicación.

El bloqueo de algunos tipos de orígenes en CloudFront es muy sencillo con control de acceso de origen (OAC), una característica de CloudFront que firma las solicitudes para ciertos tipos de orígenes de forma nativa mediante el algoritmo AWS Signature Version 4 (sigv4) basado en las políticas de IAM. En la actualidad, OAC es compatible con S3, MediaStore, MediaPackage, las URL de función de Lambda y S3 Object Lambda. Cuando se usa el OAC con S3, puede mantener su bucket de S3 privado, con acceso exclusivo a CloudFront en función de las políticas de bucket de S3.

Cuando el OAC no admite el tipo de origen, puede firmar solicitudes a su origen mediante funciones de periferia. En los siguientes blogs se explican ejemplos de implementaciones:

• Firme solicitudes usando Sigv4 con Lambda@Edge en AWS API Gateway
• Firme solicitudes usando MD5 con Lambda@Edge en los servidores NGINX

Si su origen no admite la firma de solicitudes o no considera que su aplicación necesite este nivel de control de acceso, puede configurar CloudFront para que envíe un encabezado personalizado que contenga un secreto compartido con su origen, que este pueda validar para procesar la solicitud. Considere el siguiente ejemplo de implementación:

• Origen basado en ALB. Puede validar el encabezado del secreto en un origen basado en ALB mediante una regla de ALB o una regla de AWS WAF si su ALB ya está asociado a una ACL web de AWS WAF.
• Origen basado en API Gateway. Puede validar el encabezado del secreto en una instancia de API Gateway mediante claves de API.
• Origen basado en NGINX. Si se supone que CloudFront envía un encabezado personalizado X-CloudFront con el valor abc123, puede validar el encabezado del secreto en un servidor web basado en Nginx (basado en la nube o en las instalaciones); para ello, se debe agregar el siguiente código en la etiqueta de servidor del archivo de configuración de Nginx /etc/nginx/nginx.conf:
  
  if ($http_x_cloudfront != "abc123") {
      return 403;
  }
• Origen basado en Apache. Si se supone que CloudFront envía un encabezado personalizado X-CloudFront con el valor abc123, puede validar el encabezado del secreto en un servidor web basado en Apache (basado en la nube o en las instalaciones); para ello, se debe agregar el siguiente código en el archivo de configuración httpd.conf (y el archivo ssl.conf si se usa):
  
  RewriteEngine On
  RewriteCond %{HTTP:x-cloudfront} !^abc123$ [NC]
  RewriteRule ^ - [F]

En todos los casos, se recomienda rotar este secreto compartido de forma regular para reducir el riesgo de que se filtren secretos. En las implementaciones de ejemplo compartidas anteriormente, tanto la de API Gateway como la del ALB, se incluye una automatización para la rotación de secretos.