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.

El ocultamiento de origen en la capa de red protege su origen de todos los ataques que se dirigen directamente a él. Sin embargo, un atacante podría configurar una distribución de CloudFront con el nombre de su dominio de origen descubierto y atacar su origen con ataques de capa de aplicación a través de su distribución de CloudFront y pasar por alto de manera efectiva los controles de seguridad configurados en su propia distribución de CloudFront.

Además de ofuscar el nombre del dominio de origen (por ejemplo, evite origin.example.com), puede agregar controles de acceso en la capa de aplicación entre CloudFront y el origen para mitigar el riesgo mencionado anteriormente. Esto se puede implementar de diferentes formas según el tipo de origen y el requisito de seguridad.

El control de acceso de origen (OAC) es una funcionalidad de CloudFront que le permite firmar solicitudes para ciertos tipos de orígenes de forma nativa mediante el algoritmo de AWS Signature Version 4 (sigv4) en función de 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:

• Sign requests using Sigv4 with Lambda@Edge to AWS API Gateway
  
• Sign requests using MD5 with Lambda@Edge to NGINX servers

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.

CloudFront publica las direcciones IP que se utilizan para establecer conexiones TCP con su origen, con el valor de CLOUDFRONT_ORIGIN_FACING del campo service. Puede implementar una ACL en el firewall de su origen para bloquear el tráfico que no se origina en las IP orientadas al origen de CloudFront. 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.

Si su origen está alojado en Amazon VPC, simplemente tiene que agregar la lista de prefijos administrada por AWS para Amazon CloudFront al grupo de seguridad adjunto a su origen (EC2, NLB, ALB, etc.) para implementar el ocultamiento de origen.

En ambos casos, se recomienda establecer conexiones seguras a través de TLS entre CloudFront y su origen.

Si su origen se encuentra en sus instalaciones, 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. De esta forma, el tráfico entre su origen y CloudFront se transporta en una red administrada de forma privada a la que no se puede acceder desde Internet.