Cristhian Becerra

Posted on Oct 25

Protege los orígenes de Amazon CloudFront con funcionalidades de seguridad integradas: Mejores prácticas de AWS

#spanish #aws #networking #cdn

TL;DR: En este artículo te mostraré cómo y por qué debes proteger los orígenes de Amazon CloudFront usando múltiples funcionalidades de seguridad integradas que he puesto en práctica personalmente, junto con el caso de uso y los beneficios de cada una, para lograr un origen protegido y resiliente, todo ello alineado con los pilares de Seguridad y Fiabilidad del AWS Well-Architected Framework. 🌐

Tiempo estimado de lectura: 15 minutos
Nivel: 200
Versión en inglés: Protect Amazon CloudFront Origins with Built-in Security Features: AWS Best Practices

Tabla de Contenidos:

Introducción
Por qué proteger los orígenes de Amazon CloudFront
Funcionalidades de seguridad integradas de CloudFront
Lecciones Aprendidas
Conclusión
Qué sigue
Recursos oficiales

Introducción

Si has oído hablar de Amazon CloudFront, sabes que es un servicio de Content Delivery Network (CDN) que nos ayuda a distribuir contenido estático y dinámico de forma rápida y confiable. CloudFront entrega el contenido a nuestros usuarios a través de una red global de centros de datos conocidos como ubicaciones de borde. Cuando un usuario solicita contenido que estás sirviendo mediante CloudFront, la solicitud se enruta a la ubicación de borde más cercana al usuario —o a la que proporcione la menor latencia— para que el contenido sea entregado con el mejor rendimiento posible.

Si tu contenido es estático, CloudFront te permite almacenarlo en caché, de modo que las solicitudes se atiendan directamente desde el caché y no lleguen al origen, reduciendo así la carga en este. Por otro lado, si tu contenido es dinámico, no se debe almacenar en caché, pero CloudFront permite enrutar la solicitud del usuario hacia el origen a través de la infraestructura de red global de AWS, optimizando la latencia y el rendimiento. 🤩

Cuando empezamos a familiarizarnos con Amazon CloudFront, es común que no conozcamos las mejores prácticas de seguridad recomendadas y, sin querer, las omitamos, dejando nuestros orígenes desprotegidos o vulnerables. Un error frecuente es no restringir el acceso a los orígenes exclusivamente a CloudFront, lo que puede permitir el acceso directo al origen desde rutas no controladas, ocasionando comportamientos no deseados o brechas de seguridad. Para evitar estos problemas, en este artículo te explicaré por qué es importante proteger los orígenes de Amazon CloudFront, además de presentarte múltiples funcionalidades de seguridad integradas que he puesto en práctica y que están alineadas con las mejores prácticas de AWS.

Por qué proteger los orígenes de Amazon CloudFront

En el mundo actual, la tecnología avanza a un ritmo acelerado, y con ello las amenazas de ciberseguridad crecen exponencialmente. Por esta razón, la seguridad se ha convertido en una prioridad fundamental.

Amazon CloudFront nos permite añadir una capa adicional de protección entre nuestros usuarios y los orígenes, los cuales pueden ser balanceadores, servidores, contenedores, entre otros. En lugar de dirigir a los usuarios directamente hacia los orígenes, los redirigimos a través de CloudFront, que actúa como intermediario para recuperar el contenido solicitado y entregarlo posteriormente al usuario.

Al usar CloudFront para crear una distribución estamos añadiendo una capa adicional a nuestro sistema, aunque inicialmente solo se haya pensado en mejorar el rendimiento y la velocidad, estamos incorporando un nuevo componente a nuestra arquitectura que también debe ser protegido. CloudFront ofrece un conjunto de funcionalidades de seguridad integradas que ayudan a proteger nuestros orígenes. Proporciona una defensa adicional frente a múltiples tipos de ataques, incluidos los ataques DDoS, y se integra directamente con AWS WAF y AWS Shield. 🛡️

Sin embargo, de poco sirve implementar múltiples medidas de seguridad en la distribución de CloudFront si nuestros orígenes no están protegidos o si la comunicación hacia ellos no está restringida exclusivamente a CloudFront. Esto dejaría nuestros orígenes expuestos a amenazas y vulnerabilidades que podrían pasar inadvertidas bajo la falsa percepción de que todo el tráfico pasa únicamente por CloudFront. Por estas razones, proteger los orígenes de Amazon CloudFront es un paso esencial para garantizar la seguridad y la integridad de nuestras aplicaciones.

Funcionalidades de seguridad integradas de CloudFront

En las siguientes secciones te presentaré diversas funcionalidades de seguridad integradas que he puesto en práctica, las cuales están alineadas con las mejores prácticas de AWS y que considero podrían resultarte muy útiles conocer. 🚀

Nota: En la sección de recursos oficiales al final encontrarás toda la documentación de AWS correspondiente a cada una de las funcionalidades mencionadas a continuación.

Restricción del acceso al Application Load Balancer

Cuando utilizas un balanceador de carga público (ALB) como origen de una distribución de Amazon CloudFront, este sigue siendo accesible desde Internet de forma predeterminada, y no únicamente a través de CloudFront. Para restringir el acceso al balanceador público de modo que solo sea posible mediante la distribución de CloudFront, puedes usar un encabezado HTTP personalizado.

En la distribución de CloudFront, para el origen específico que deseas proteger, añade un encabezado HTTP personalizado con un valor secreto, el cual no debe exponerse públicamente. De esta forma, CloudFront incluirá este encabezado en todas las solicitudes que envíe al origen (ALB).

Posteriormente, configura el listener del Application Load Balancer para que únicamente reenvíe las solicitudes a sus targets cuando estas contengan el encabezado HTTP personalizado con el valor secreto especificado. Así, el ALB descartará cualquier solicitud que no contenga dicho encabezado, garantizando que solo el tráfico proveniente de CloudFront sea aceptado.

Te recomiendo renovar el valor secreto del encabezado HTTP personalizado al menos una vez al año, como medida preventiva ante posibles filtraciones de seguridad.

Restricción del acceso a un origen de Amazon S3

Cuando utilizas un bucket de Amazon S3 como origen de una distribución de Amazon CloudFront, este permanece accesible desde Internet de forma predeterminada, y no únicamente a través de CloudFront. Para restringir el acceso a los objetos del bucket de modo que solo sea posible mediante la distribución de CloudFront, puedes utilizar Origin Access Control (OAC).

Origin Access Control (OAC) nos permite proteger los orígenes de S3 y, a diferencia de su predecesor Origin Access Identity (OAI), es compatible con todos los buckets de S3 en todas las regiones de AWS. Además, ofrece soporte para cifrado mediante AWS KMS y permite solicitudes dinámicas (como PUT y DELETE) hacia Amazon S3.

Para implementar Origin Access Control (OAC), en el origen específico que deseas proteger, simplemente crea un nuevo origin access control en lugar de utilizar un origen de acceso público, y actualiza la bucket policy del bucket de S3 añadiendo el statement proporcionado por CloudFront, el cual tiene la siguiente estructura:

{
    "Version": "2008-10-17",
    "Id": "PolicyForCloudFrontPrivateContent",
    "Statement": [
        {
            "Sid": "AllowCloudFrontServicePrincipal",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudfront.amazonaws.com"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::<Bucket Name>/*",
            "Condition": {
                "StringEquals": {
                    "AWS:SourceArn": "arn:aws:cloudfront::<Account ID>:distribution/<Distribution ID>"
                }
            }
        }
    ]
}

Restricción del acceso con orígenes de la VPC

Hasta hace relativamente poco tiempo, CloudFront solo permitía configurar orígenes públicos. Es decir, si se deseaba colocar un balanceador de carga o una instancia EC2 detrás de una distribución de CloudFront, estos debían contar obligatoriamente con un DNS resolvible a una dirección IP pública.

A finales de 2024, AWS introdujo CloudFront Virtual Private Cloud (VPC) Origins, una funcionalidad que permite asignar como orígenes a balanceadores privados o instancias EC2 privadas ubicadas en subredes privadas dentro de una VPC. ¡Ya no es necesario que sean públicos!

Para implementar VPC Origins, simplemente crea un nuevo VPC Origin en CloudFront, especificando el ARN del ELB privado o de la instancia EC2 privada. El grupo de seguridad asociado a estos recursos privados debe seguir permitiendo el acceso desde las direcciones IP de CloudFront.

Si bien podrías permitir acceso entrante desde Internet —dado que no se trata de un recurso público—, si deseas evitar que otros recursos privados dentro de la misma VPC puedan acceder al origen y garantizar que solo CloudFront tenga acceso, lo más recomendable es utilizar prefix lists. Para ello, revisa la siguiente sección.

Listas de prefijos administradas por AWS

Cuando en múltiples grupos de seguridad necesitas permitir acceso a un mismo conjunto de direcciones IP, en lugar de agregar manualmente cada dirección IP en todos los grupos, puedes crear una prefix list. En este caso, hablamos de una lista de prefijos administrada por el cliente, es decir, por nosotros, y sería nuestra responsabilidad mantener actualizada dicha lista de direcciones IP.

Por otro lado, una necesidad común al trabajar con recursos dentro de una VPC es limitar el tráfico entrante o saliente únicamente a ciertos servicios de AWS. Aunque es posible obtener el listado de direcciones IP públicas de cada servicio, estas cambian constantemente, y mantenerlas actualizadas manualmente sería una tarea compleja y propensa a errores. Para ello, AWS ofrece las AWS-managed prefix lists, listas de prefijos administradas y actualizadas automáticamente por AWS, que permiten filtrar las direcciones IP de varios servicios como Amazon CloudFront, Amazon DynamoDB, Amazon S3, entre otros.

Como se mencionó en la sección anterior, si deseamos permitir tráfico hacia nuestros recursos en una VPC únicamente desde las direcciones IP de CloudFront, podemos aprovechar la AWS-managed prefix list correspondiente a Amazon CloudFront. Para ello, basta con especificar la Prefix List (pl) como origen o destino en las reglas del grupo de seguridad.

Esta funcionalidad resulta sumamente útil al trabajar con orígenes dentro de una VPC. Sin embargo, si el origen se encuentra On-Premises, ya sea con conectividad híbrida a AWS mediante una Site-to-Site VPN o AWS Direct Connect, o incluso totalmente desconectado de AWS y accesible mediante una dirección IP pública, en ese caso no es posible utilizar prefix lists. Para dichos escenarios, revisa la siguiente sección.

Rangos de direcciones IP de AWS

Como se mencionó en la sección anterior, sí es posible obtener el listado de direcciones IP públicas de cada servicio de AWS. Y si bien, cuando nos encontramos en una VPC podemos aprovechar las prefix lists, cuando trabajamos en entornos On-Premises fuera de AWS nos vemos obligados a utilizar el listado de direcciones IP públicas de AWS.

Para esto, AWS mantiene su listado de direcciones IP públicas actualizado en formato JSON en el archivo ip-ranges.json. Usando las direcciones IP de este listado puedes configurar tu firewall On-Premises. Pero quizá ahora te estés preguntando: ¿cómo mantendré mi firewall actualizado si las direcciones IP de Amazon cambian constantemente?

No te preocupes, Amazon pensó en eso y creó un topic de SNS al cual puedes suscribirte para recibir notificaciones sobre actualizaciones en el archivo ip-ranges.json. El ARN del topic es: arn:aws:sns:us-east-1:806199016981:AmazonIpSpaceChanged. Solo debes suscribirte al topic y desarrollar una pequeña automatización local que procese las notificaciones y actualice las reglas de tu firewall On-Premises según corresponda.

Restricción de la distribución geográfica

Esta sección es simple. Puedes mejorar la seguridad de tu origen configurando restricciones geográficas en tu distribución, siempre y cuando se adapten a tu caso de uso.

Para ello, CloudFront te permite implementar una allow list o block list en tu distribución y especificar todos los países que necesites permitir o bloquear.

Cifrado a nivel de campo

Esta sección aborda un caso de uso particular que ocurre cuando, dentro de la solicitud que realiza el cliente a CloudFront, se incluye un payload con múltiples campos, de los cuales algunos contienen datos sensibles. Los campos con datos sensibles deben ser visibles únicamente para el destino final, mientras que cualquier recurso de red o cómputo intermedio debería ver dichos campos cifrados. Sin embargo, no podemos cifrar toda la solicitud, ya que este caso de uso requiere que los recursos intermedios puedan visualizar sin problemas todos los demás campos con datos no sensibles.

Aquí es donde entra el cifrado a nivel de campo. Supongamos que el cliente envía una solicitud cuyo payload contiene tanto campos con datos no sensibles como campos con datos sensibles, tales como PII, PHI, información confidencial, credenciales, entre otros. Entre CloudFront y el destino final existen múltiples recursos intermedios, y ninguno de ellos debería ser capaz de ver los datos sensibles, aunque sí necesitan poder procesar los campos no sensibles. En este escenario, implementamos el cifrado a nivel de campo proporcionado por CloudFront.

Para implementar el cifrado a nivel de campo, simplemente debemos crear un encryption profile en CloudFront, el cual debe especificar los campos de datos a cifrar y la clave pública que se utilizará para dicho cifrado, previamente almacenada en CloudFront. Por otro lado, el destino final, por ejemplo, un servidor de aplicaciones, debe contar con la clave privada correspondiente y estar configurado para descifrar los campos cifrados. Solo el servidor final posee la clave privada, por lo que, de este modo, se protege la confidencialidad de los datos sensibles frente a los recursos intermedios, sin limitar el procesamiento de los datos no sensibles en una misma solicitud.

CloudFront Origin Shield

Origin Shield es una capa adicional de caché que puede ayudar a reducir la carga en tu origen y, con ello, proteger su disponibilidad. Los principales casos de uso incluyen escenarios con usuarios en distintas regiones geográficas o cuando se trabaja con múltiples CDN.

Origin Shield mejora la tasa de aciertos en caché, disminuye la carga en el origen y optimiza el rendimiento de la red. El flujo de una solicitud en CloudFront sin Origin Shield pasa por las Edge Locations, luego por los Regional Edge Caches y, finalmente, llega al origen. En este caso, múltiples regiones podrían estar consultando el origen de forma innecesaria. Para evitarlo, al activar Origin Shield, se coloca una capa adicional entre los Regional Edge Caches y el origen, de modo que únicamente Origin Shield enviará solicitudes al origen, reduciendo así su carga.

Para usar Origin Shield, dentro de tu distribución selecciona el origen, activa Origin Shield y elige la región de AWS donde deseas desplegarlo.

AWS WAF Core Protections

CloudFront tiene una integración directa con AWS WAF y permite añadir una capa de seguridad básica con un solo clic, lo cual crea en segundo plano un Web ACL con la protección predeterminada que tu aplicación necesita.

La protección predeterminada de WAF para CloudFront incluye defensa frente a vulnerabilidades comunes como las del OWASP Top 10, SQL Injection, Rate Limiting y bloqueo de tráfico proveniente de direcciones IP maliciosas basadas en la inteligencia de amenazas de Amazon. Sin embargo, si lo consideras necesario —y de hecho es lo recomendable—, personaliza tu Web ACL según tus requerimientos y añade las reglas adicionales que estimes convenientes para fortalecer la seguridad de tu origen.

CloudFront Origin Groups

Esta funcionalidad, técnicamente, no constituye una medida de seguridad, sino de resiliencia, pero quiero mencionarla porque la he probado y me parece particularmente interesante.

Como sabrás, CloudFront es un servicio global, pero los orígenes probablemente no lo sean. Es decir, en el evento de una caída regional o de una zona de disponibilidad, la aplicación podría dejar de responder, incluso si la distribución de CloudFront en sí misma no se ve afectada.

Para manejar este tipo de situaciones, CloudFront Origin Groups nos permite configurar una solución de failover de manera sencilla. Solo debemos crear un Origin Group en el cual se especifiquen múltiples orígenes y el criterio de conmutación por error, es decir, los HTTP Status Codes que debe recibir CloudFront para activar el failover hacia otro origen ubicado en una región distinta.

De este modo, CloudFront Origin Groups nos permite mantener una alta disponibilidad ante una falla regional: la misma distribución global sigue activa, simplemente redirigiendo las solicitudes hacia otro origen dentro del grupo, pero ubicado en una región diferente.

Lecciones Aprendidas

Nunca olvides restringir el acceso a los orígenes. En la mayoría de los casos, cuando implementas CloudFront, la distribución debería ser la única con acceso al origen. Por ello, es común implementar todos los mecanismos de defensa en la distribución de CloudFront; sin embargo, si no restringes el acceso al origen, este quedará vulnerable a amenazas que probablemente no habías considerado por haberte enfocado únicamente en proteger la distribución. 😶

Si necesitas implementar AWS WAF para tu aplicación, casi siempre deberías adjuntar el Web ACL a la distribución de CloudFront, en lugar de, por ejemplo, al origen ALB. Siempre tendrá más sentido aplicar WAF a nivel de la distribución, de modo que el tráfico sea filtrado lo más arriba posible, reduciendo así la carga y el costo del procesamiento de datos en el ALB. 😎

Te recomiendo utilizar la georrestricción siempre que sea posible y, por supuesto, cuando aplique a tu caso de uso. En mi experiencia, dependiendo de la región en la que te encuentres, la georrestricción puede ser una de las formas más sencillas de evitar tráfico no deseado de bots de scraping, dado que este tipo de tráfico suele provenir de países específicos. 🤖

Conclusión

Amazon CloudFront cuenta con múltiples funcionalidades de seguridad integradas que nos permiten proteger los orígenes, abarcando desde failover, firewall, georrestricción, capas adicionales de caché, cifrado a nivel de campo y, principalmente, la restricción del acceso al origen. Todo esto nos permite consolidar diversos mecanismos de protección a nivel perimetral en la distribución de CloudFront, reforzando así la postura de seguridad de nuestras aplicaciones mediante una estrategia de defensa en profundidad.

Qué sigue

En la siguiente sección encontrarás los recursos y documentos oficiales de AWS para las funcionalidades de seguridad integradas de Amazon CloudFront mencionadas en este artículo, por si deseas seguir aprendiendo o profundizar para evaluar si realmente aplican a tu caso de uso.

Te invito también a realizar la implementación de estas funcionalidades de seguridad integradas de CloudFront en tu propia cuenta de AWS. Cuéntame en los comentarios qué te pareció este artículo o si descubriste algo interesante sobre alguna característica de Amazon CloudFront durante tu implementación. ✍🏻

Y para mí, un próximo paso será probar la integración de AWS Shield Advanced con CloudFront en un futuro, ya que hasta ahora no he tenido la oportunidad de ver en acción la lógica de mitigación DDoS de AWS Shield aplicada a CloudFront.

DEV Community