Seguridad para portales y aplicaciones web on-premises con servicios de AWS

Por Claudia Izquierdo, Arquitecta de Soluciones para Sector Público en AWS
Claudia Pico, Sr. Executive Security Advisor para Sector Público en AWS
y Mauricio Romero, Arquitecto de Soluciones Sr. en Amazon Web Services para Sector Público.

Los servicios en nube para aceleración de entrega de contenido, seguridad perimetral externa y detección de amenazas, pueden ser utilizados para la protección de portales y aplicaciones web que estén alojados fuera de la nube de AWS.

En este blog abordaremos una arquitectura de referencia que permite con facilidad proteger aplicaciones on-premise y que puede también acelerar la entrega de contenido sin ampliar las capacidades locales.

Para utilizar una aplicación web, el usuario resuelve un nombre de dominio (DNS) a una dirección IP y establece una conexión por medio de protocolos seguros a través de su proveedor de Internet, y el proveedor de Internet de la entidad a un sitio web, usualmente protegido por un firewall perimetral y y soportado en una infraestructura de cómputo con capacidad limitada.

1. Escenario de aplicacion web on-premises

En este escenario, eventos de seguridad y desborde de peticiones impactan directamente los canales de comunicación e infraestructura on-premises, lo que requiere, entre otros, inversión en elementos de seguridad perimetral balanceo de carga y capacidad de cómputo dimensionada para picos en la demanda.

Una alternativa es migrar la carga a la nube en una arquitectura que incorpora la seguridad desde el diseño, pero en ocasiones la migración es compleja o de largo plazo por dependencias locales o componentes que el cliente no puede migrar oportunamente. En este escenario hemos ayudado a clientes a implementar servicios de seguridad de AWS al frente de la aplicación on-premises sin requerir migración o cambios en sus aplicaciones.

Aceleración y seguridad con servicios de nube

Para proteger una aplicación on-premises, proponemos una arquitectura de nube híbrida, sin mover la aplicación, usando servicios de AWS para obtener los beneficios siguientes:

Uso de servicios de seguridad con una integración sin fricción para complementar la protección de las aplicaciones y plataformas web.
Agilidad en el desarrollo de las reglas para los servicios de protección perimetral con la disponibilidad de reglas administradas.
Incremento de la resiliencia y escalabilidad de los servicios de seguridad utilizados, gracias al uso de la infraestructura global de AWS y características de los servicios a emplear.
Aceleración en la entrega de contenido al delegar en la nube el punto de conexión de los protocolos de red y seguridad hacia los usuarios finales.
Incremento en la observabilidad de las cargas de trabajo, evolucionando del monitoreo hacia procesos y tableros que pueden aplicar Machine Learning e Inteligencia Artificial para una gestión proactiva.

Partiendo de un portal o aplicación web soportada por medio una plataforma externa a AWS, como podría ser un centro de datos, un servicio de colocación o un alojamiento en nube, vamos a emplear servicios de AWS para obtener los beneficios mencionados.

Resiliencia en la resolución de nombres

Cambiar el proveedor de DNS que se tenga no es indispensable, pero este servicio es un punto de falla y puede ser objetivo de incidentes de seguridad, se recomienda delegar la resolución de nombres en Amazon Route 53, servicio DNS escalable y de alta disponibilidad, brinda resiliencia y facilita la administración al automatizar la actualización de los registros de IP que AWS opera dinámicamente conforme la elasticidad y respuesta de incidentes lo requieren.

Route 53 permite la configuración de esquemas de failover automático por medio de monitores de salud de los servicios que en este caso se encuentran on-premises. En caso de no tener respuesta en la dirección IP primaria, el dominio es resuelto hacia una IP secundaria previamente configurada, cuyo destino puede ser una segunda ubicación o un sitio de contingencia que puede estar en la nube o en otro centro de datos. Un potencial caso de uso, es la configuración de este mecanismo para que, en caso de falla de una región primaria, pueda automáticamente resolver hacia una región secundaria.

2. Configuración failover en Amazon Route 53

3. Configuración de healthcheck en Amazon Route 53

Aceleración de entrega segura de contenido

El servicio Amazon CloudFront será responsable por entregar contenidos de forma segura, con baja latencia y alta velocidad de transferencia. Este servicio utiliza puntos de presencia local (Edge Locations) existentes, más de 550 al momento de escribir este blog, el cliente tiene el control si los utiliza todos o aquellos que sean adecuados según al acceso de la aplicación. Desde este servicio se brinda la funcionalidad de contar con un caché en nube y se integrará con AWS Certificate Manager (ACM) y a AWS WAF como se indica más adelante.

En CloudFront se configura la aplicación web actual, política de caché y otros comportamientos que incluyen la capacidad de un origen de contingencia. Amazon Cloudfront brindará un nombre de dominio público de la distribución con múltiples IPs de la red global de AWS a los que los usuarios accederán. Es decir, el sitio web origen se puede configurar para que únicamente acepte conexiones desde el servicio de Cloudfront, reduciendo la exposición de la aplicación al Internet.

4. Configuración de origen en Amazon Cloudfront

CloudFront será también el punto de terminación de la conexión entre el usuario final y el portal, es decir, en él se configura un certificado digital para el dominio y la política usada para establecer el canal seguro HTTPS. El certificado digital se configura por medio de AWS Certificate Manager (ACM) se puede utilizar un certificado previamente adquirido o utilizar un certificado digital emitido por Amazon sin costo adicional. El mover la terminación de la conexión a AWS descarga el manejo de estas sesiones de los servidores on-premises y es la plataforma de nube la que ayuda a soportar incremento de conexiones por tráfico válido o peticiones maliciosas.

5. Estado de certificado digital emitido desde AWS Certificate Manager

Seguridad perimetral

Las aplicaciones expuestas en AWS por medio de CloudFront, Elastic Load Balancing y API Gateway cuentan con el servicio AWS Shield Standard, que brinda protección de ataques DDoS en capa 3 y 4 sin costo adicional, el cual es brindado de forma global por AWS y no requiere activación o configuración particular dentro de la cuenta del cliente.

6. Ejemplo grupo de reglas configuradas en AWS WAF

Para incrementar el nivel de protección se puede activar el servicio AWS Shield Advanced, que lleva la protección a la capa 7, brinda visibilidad y configuración en la cuenta del cliente, pero el valor más importante es que agrega soporte especializado 24/7 por el equipo de AWS Shield Response Team; este equipo ayuda en la atención del incidente, análisis de causa raíz y aplicación de medidas de mitigación y tiene la experiencia en respuesta a incidentes a nivel global.

Los portales y aplicaciones web son susceptibles a ataques a nivel de aplicación, por ejemplo, inundación de peticiones http, inyección SQL, explotación de vulnerabilidades, bots maliciosos y peticiones malformadas, entre otros. Utilizaremos AWS WAF, un firewall de aplicaciones nativo de nube que, de forma transparente a la configuración de red, permite la implementación de reglas creadas por el usuario, administradas por AWS y reglas administradas por socios reconocidos en la industria de seguridad, todas a elección y configuración del cliente el cual vincularemos con la distribución de Amazon Cloudfront. El despliegue y configuración puede ser facilitado por medio de la solución Automatizaciones de seguridad para AWS WAF.

Para que esta arquitectura sea el punto único de acceso a la aplicación on-premises se sugiere localmente aplicar una regla que permita comunicaciones exclusivamente desde Cloudfront, el método más efectivo es la inclusión de una cabecera (header) que pueda ser verificada por capa de publicación de la aplicación on-premises.

Arquitectura de referencia y despliegue

De acuerdo con los elementos explicados, la arquitectura de acceso al sitio queda de la forma siguiente:

7. Arquitectura de referencia con único origen

El usuario resuelve el nombre del domino, alojado en Route53 para mayor resiliencia.
El usuario realiza la petición hacia un IP de la distribución de Cloudfront, en la conexión, AWS Shield previene DDoS.
Se establece la conexión HTTPS hacia Cloudfront, para lo cual se utiliza el certificado SSL gestionado en nube.
Las peticiones son inspeccionadas por AWS WAF.
Si no se encuentra en caché, se realiza la petición hacia la aplicación web on-premises.
La aplicación web origen verifica que la misma proviene de Cloudfront y atiende la petición.
El usuario recibe respuesta de Amazon Cloudfront

Recomendaciones y recursos

A continuación, presentamos de forma general los pasos y recomendaciones a seguir, así como enlaces de referencia para otros artículos o documentación en los cuales encontrarán información más detallada al respecto.

Consideraciones iniciales:

En esta arquitectura básica, el sitio web origen es accedido por CloudFront a través de Internet, la comunicación hacia el sitio origen debe ser por https con un certificado válido emitido por una Autoridad Certificadora de confianza pública.
Es recomendable delegar el DNS en Amazon Route 53, los beneficios de resiliencia y facilitación de actualización de direcciones IP y simplificación en la emisión y renovación de certificados digitales son ventajas importantes; puede consultar la Guía de configuración de Amazon Route 53. La implementación en un DNS de terceros es posible a través de registros de tipo CNAME, sin embargo, estos registros no pueden utilizarse para el dominio principal (entidad.gob) por lo que en ese caso la gestión de IP deberá realizarse manualmente.

En DNS se requiere lo siguiente:

Generar un registro tipo A que resuelva hacia las direcciones IP de cada sitio origen, este registro se puede crear un identificador arbitrario que no requiere ser conocido por el público, por ejemplo 1.sitio.gobo un identificador difícil de adivinar agregando algo que lo haga único, por ejemplo torigx32k.sitio.gob.
Agregado el dominio, es conveniente verificar que, al acceder por este nombre, el sitio origen responde las peticiones, esto puede requerir alguna configuración a nivel de listener o host en el sitio on-premises.

Para preparar el certificado digital, debemos elegir un camino:

Si tenemos un certificado público emitido por terceros y queremos utilizar el mismo en CloudFront, seguimos los pasos para importar el certificado público a AWS Certificate Manager, que aloja de forma segura el certificado y facilita su utilización en servicios de AWS.
Si preferimos utilizar un nuevo certificado, desde ACM vamos a seguir los pasos para solicitar un nuevo certificado público, este podrá ser para un dominio específico (FQDN), tener varios o utilizar un comodín (*.entidad.gob). Este proceso pedirá comprobar tener autoridad sobre el dominio por medio de registros DNS o aprobación por correo electrónico a la dirección registrada como el propietario del dominio.

Para el firewall de aplicación, se requiere implementar una lista de control de acceso web, denominadas WebACL, para esto hay que considerar:

Si decidimos crear desde cero la protección sugerimos revisar la documentación de las listas de control de acceso web (WebACL). Sugerimos considerar siempre seleccionar reglas administradas de AWS o de terceros para asegurar que estas consideren y protejan de escenarios comunes y tengan una actualización respaldada. por equipos dedicados a esta tarea.
Para agilizar el proceso de despliegue, pueden utilizar la solución de Automatizaciones de seguridad para AWS WAF, que por medio de infraestructura como código implementa un conjunto de reglas preconfiguradas de AWS WAF para filtrar los ataques web más comunes y facilita la configuración y consulta de logs.
Si es un portal o aplicación que tiene una página de inicio de sesión, sugerimos revise el blog sobre como habilitar Account Takeover Prevention.

Adelantados los pasos anteriores, podemos proceder a seguir los pasos para crear una distribución de CloudFront, en este proceso considerar lo siguiente:

Si el sitio es accedido uno o varios nombres de dominios propios, utilizaremos nombres de dominio alternativos (CNAME), que deben estar configurados como nombres alternos en la distribución que luego será configurada en el DNS.
En la configuración de Cloudfront establecimos la política para el protocolo de acceso, elegir si el sitio responderá únicamente por https, si se redireccionará cualquier requerimiento http hacia https, o si el sitio responderá en ambos protocolos.
En la configuración de HTTPS también podemos seleccionar la política de seguridad que determina protocolos y algoritmos soportados, en lo que sugerimos atender recomendaciones de seguridad sobre versiones de TLS, algoritmos de cifrado. AWS ofrece conjuntos predefinidos y documentados, algunos de los cuales incluso atienden los estándares que establece FIPS.
En esta configuración también habilitamos la WebACL previamente creada. Es importante que la WebACL se haya creado para uso global con el servicio de CloudFront.
De acuerdo al tipo de sitio o aplicación web, sugerimos revisar las alternativas de configuración del comportamiento de la cachéy comprender las políticas de caché para que sean las adecuadas al comportamiento del sitio y compatible con aspectos como gestión de sesiones de usuario.
El usuario también elige una de las combinaciones de ubicaciones de borde que serán utilizada por Cloudfront para atender los requerimientos, por ejemplo, si los usuarios se encuentran en Colombia, la configuración sugerida es activar los puntos de presencia de América del Sur.
Es importante configurar los logs de Amazon CloudFronty comprender su monitorización.

Una vez creada la distribución en CloudFront vamos a obtener un nombre de dominio, algo como ab12cd35.cloudfront.net, que resolverá hacia las IP de infraestructura global provistas por AWS. Para continuar con nuestro proceso:

Antes de sustituir el registro principal del sitio, se puede tomar una de las IP que resuelven el nombre de la distribución y configurar la resolución local (en el archivo hosts de una maquina cliente) para poder verificar que la configuración opera adecuadamente.
Algunos de los problemas que pueden surgir pueden ser que la conexión https hacia el sitio origen tenga certificados considerados no seguros o que no correspondan al nombre de dominio, que el sitio origen no esté configurado para atender el sitio con el nombre de dominio alterno que se configura, que los nombres de dominio no estén configurados en CloudFront. Puede consultar la documentación de solución de problemas de Amazon CloudFront.

Una vez realizadas con éxito las pruebas, se procede a crear o sustituir el registro para el dominio por un registro de tipo CNAME cuyo valor se configura con el FQDN de la distribución creada en CloudFront.

Failover en CloudFront

CloudFront tiene la facilidad de crear una configuración con failover por error en el origen configurado:

8. Arquitectura de referencia con origen de contingencia

Para lo cual se requiere configurar por lo menos dos orígenes, uno será declarado como primario y CloudFront va a realizar sus requerimientos normalmente al origen primario, pero si este no responde, realizará sus requerimientos a un sitio secundario. En este escenario, ambos orígenes deben estar disponibles, aunque Cloudfront solo enviará tráfico al origen secundario en caso de falla. Consulte la sección de conmutación por error de origen de CloudFront.

Este origen secundario puede ser una infraestructura de ISP y centro de datos diferente por completo, o bien, una configuración donde exista solo una de las partes en failover, es decir, podrían ser IP que brinden conectividad por dos ISP distintos, pero hacia un mismo centro de datos, o bien, que sean dos direcciones IP que van por el mismo ISP, pero existan dos infraestructuras de la aplicación disponibles en el mismo centro de datos.

Dos orígenes activo – activo

Un tercer escenario, es tener dos ubicaciones de la aplicación que puedan operar activo-activo, para lo cual es necesario balancear las peticiones entre ambos sitios. Para esta arquitectura, agregamos el servicio de Application Load Balancer que balanceará las peticiones desde CloudFront hacia los dos sitios activos.

9. Arquitectura de referencia con balanceo de carga

Por medio de un Application Load Balancer que tenga como destino los diferentes IP donde esté operando la carga de trabajo.

Como se aprecia en el diagrama, por medio de Certificate Manager es posible también habilitar HTTPS en el balanceador, para que CloudFront quede siempre habilitado a ir por el origen por medio de este protocolo.

Una vez creado el balanceador, vamos a utilizar el FQDN que el balanceador genera para configurarlo como el origen de la distribución de CloudFront. En este escenario no se requiere utilizar la función de failover de CloudFront porque la distribución y verificación de health checks se realiza en el balanceador. Para más información consulte la documentación sobre el uso de Application Load Balancer como origen para Amazon CloudFront.

Observabilidad

Sobre las arquitecturas propuestas, es importante que consideremos monitoreo y observabilidad de la solución, para lo cual podemos considerar:

Se pueden crear tableros para monitorear métricas de los servicios por medio de Amazon Cloudwatch.
Amazon Athena brinda la posibilidad de consultar vía SQL los logs de servicios de AWS que sean almacenados en S3.
Existen otras soluciones creadas por AWS que automatizan la creación de estos tableros e integran capacidades adicionales de búsqueda y visualización, por ejemplo, un tablero a partir de los logs de AWS WAF.
Si necesitamos monitorear en tiempo real los registros de CloudFront con el fin de tener mayor visibilidad del comportamiento del tráfico sugerimos revisar la documentación correspondiente.
Existe la posibilidad de enviar los logs o alertas hacia SIEM (Security Information and Event Management) o soluciones de SOC (Security Operation Centers) de terceros, o bien, utilizar AWS Security Lake en AWS.

Conclusiones

Las arquitecturas híbridas descritas anteriormente permiten que sin ampliar capacidades on-premises ni migrar las cargas de trabajo, incrementemos la resiliencia, seguridad y velocidad de respuesta de portales o aplicaciones web gracias a características de servicios nativos de AWS que nos proveen:

Mayor resiliencia gracias a la infraestructura global que soporta Amazon Route 53, Amazon CloudFront y AWS WAF.
Agregamos seguridad en capas gracias a la protección de los servicios de AWS Shield, AWS WAF y cifrado en tránsito soportada en Amazon CloudFront con políticas de seguridad adecuadas.
Aceleración en la entrega de contenido que pueda aprovechar el caché de Amazon CloudFront, reduciendo peticiones hacia la infraestructura on-premises.
Implementación de failover con Amazon CloudFront o distribución de cargas con Elastic Load Balancer.
Mejorar la observabilidad desde AWS con servicios como Amazon Athena, Amazon Quicksight y Amazon Cloudwatch, o bien, integrando hacia sistemas de terceros.

Para finalizar, resaltamos que las arquitecturas explicadas son elásticas y serverless, es decir, no requieren el provisionamiento o reserva de capacidades específicas de cómputo, memoria o red. El principal beneficio es que no estamos limitados por capacidad de hardware ni obligados a contratar soluciones con límites de ancho de banda o que requieran licenciamientos.

Sobre los Autores

Claudia Izquierdo es Arquitecta de Soluciones para Sector Público en AWS. Claudia ha ayudado a múltiples entidades de gobierno y organizaciones no gubernamentales en Latinoamérica a cumplir con sus misiones y objetivos de negocio. Le apasionan los temas de cloud, networking, seguridad y ciberseguridad de la información. Claudia también es una instructora Cisco premiada mundialmente y apoya en proyectos para más mujeres en tecnología.

Claudia Pico es Sr. Executive Security Advisor para Sector Público en AWS. Claudia ha ayudado entidades de gobierno y empresas del sector privado a definir y a ejecutar su transformación Digital, enfocada en definir la estrategia de seguridad digital para mitigar riesgos cibernéticos. Experta en adopción de nube y el cumplimiento regulatorio para los sectores público y privado en la región de América Latina.

Mauricio Romero es Arquitecto de Soluciones Sr. en Amazon Web Services para Sector Público. Mauricio ha liderado proyectos de gobierno electrónico y transformación digital y apoya a entidades de gobierno en Latinoamérica en su camino hacia la nube. Le apasionan los temas de transformación digital, seguridad de la información y modernización con servicios de nube.

Revisores Técnicos

Jorge Morales es Sr. Security Consultant de servicios profesionales para Sector Público en AWS. Con más de 10 años de experiencia en ciberseguridad ha aportado en la adopción segura de la nube a clientes en Latinoamérica y Brasil. Jorge colabora constantemente con comunidades de conocimiento de seguridad cloud con miras a que más profesionales se sientan cómodos con la tecnología de nube y sus capacidades.

Giovanni Rodríguez es Head of Solutions Architect para Sector Público en AWS. Ha ayudado a múltiples entidades de gobierno, organizaciones no gubernamentales, y empresas privadas, en Latinoamérica, a cumplir con sus misiones y objetivos de negocio. Le apasionan los temas de cloud, seguridad de la información, y analítica.

Blog de Amazon Web Services (AWS)