top of page
Foto del escritorRan Isenberg

Consejos y trucos para proteger sus servicios SaaS con el firewall de aplicaciones web (WAF) de AWS


AWS WAF protege contra bots maliciosos
AWS WAF protege contra bots maliciosos

Trabajo en una empresa de ciberseguridad, CyberArk , y la seguridad es un concepto que tengo constantemente presente cuando desarrollo servicios SaaS en AWS. Tiene que ser así: los actores maliciosos buscan constantemente vulnerabilidades, esperando que alguien cometa un desliz o el momento perfecto para lanzar un ataque DDoS contra su servicio en la nube. Como resultado, debemos preparar y proteger nuestros servicios. Podemos delegar la mayor parte del trabajo pesado (con un costo) a AWS.

En esta publicación, aprenderá sobre el firewall de aplicaciones web (WAF) de AWS, para qué sirve, consejos e información sobre visibilidad, propiedad, gobernanza (y más) para proteger sus servicios SaaS.


Esta es la primera de tres publicaciones de la serie.

En la segunda publicación, proporcionaré el código AWS CDK para la implementación de WAF y la asociación de API Gateway.

En la tercera publicación, revisaremos AWS Firewall Manager y cómo permite a la organización administrar las ACL de AWS Application Web Firewall a escala de manera centralizada.

 

Tabla de contenido

 

Debes proteger tu aplicación SaaS

Los ataques DDoS, ya sea implementados por individuos o botnets, inundan los servidores con solicitudes y los sobrecargan con tráfico, lo que hace que los servicios y sitios alojados no estén disponibles para los usuarios y visitantes - Akamai

Cuando crea API públicas o aplicaciones basadas en la nube, es posible que actores maliciosos intenten eventualmente interrumpir y dañar la experiencia de sus clientes.

Estos ataques, conocidos como ataques de denegación de servicio distribuido ( DDoS ), se llevan a cabo de forma automática. Están orquestados por una red de máquinas comprometidas y controladas de forma remota, también conocidas como bots, que se utilizan para inundar el objetivo con una cantidad abrumadora de tráfico.


Un bot es un programa informático que automatiza las interacciones con las propiedades web a través de Internet - CloudFlare

Sin embargo, los bots no siempre lanzan ataques a gran escala. Acceden a los sitios por diversos motivos, incluida la indexación (pensemos en el motor de búsqueda de Google), lo que los convierte en bots "buenos".

Un bot malicioso es un programa informático que intenta robar datos mediante el raspado de datos o la búsqueda de vulnerabilidades en preparación para un ataque entrante. Afortunadamente, podemos protegernos de los bots maliciosos y al mismo tiempo permitir que los bots "buenos" hagan su trabajo. Si desea obtener más información sobre los bots buenos y malos, consulte el artículo de CloudFlare .

El bloqueo de ataques DDoS y bots maliciosos mantendrá la integridad y el rendimiento de su servicio SaaS. Veamos cómo podemos lograrlo con AWS Web Application Firewall .


Si quieres saber más sobre DDoS y los ataques DDoS más famosos de la historia, consulta este artículo .

 

Introducción al firewall de aplicaciones web (WAF) de AWS

AWS WAF es un firewall de aplicaciones web que le permite supervisar o bloquear las solicitudes HTTP(S) reenviadas a los recursos de su aplicación web protegida. Puede proteger los siguientes tipos de recursos:

  • Distribución de Amazon CloudFront

  • API REST de Amazon API Gateway

  • Balanceador de carga de aplicaciones

  • API GraphQL de AWS AppSync

  • Grupo de usuarios de Amazon Cognito

  • Servicio AWS App Runner

  • Instancia de acceso verificado de AWS


Como puede ver en la lista anterior, AWS WAF puede proteger sus servicios basados en contenedores y sin servidor.

Para entender cómo WAF proporciona una capa adicional de seguridad, primero debemos entender cómo funciona. Veamos cómo podemos configurar WAF para proteger nuestro servicio SaaS.


ACL y reglas

Para utilizar WAF con sus recursos de AWS (como se define anteriormente), cree una lista de control de acceso (ACL) de WAF, defina sus reglas y asocie la ACL con el recurso que desea proteger.

Los recursos asociados reenvían las solicitudes entrantes a AWS WAF para que la ACL web las inspeccione. En la ACL web, se crean reglas para definir los patrones de tráfico que se deben buscar en las solicitudes y para especificar las acciones que se deben tomar en las solicitudes coincidentes. - AWS

Cada regla tiene una acción que se ejecuta cuando se cumple. Las opciones de acción incluyen lo siguiente:

  • Permitir que las solicitudes vayan al recurso protegido para su procesamiento y respuesta.

  • Bloquear las solicitudes.

  • Cuente las solicitudes.

  • Ejecute CAPTCHA o verificaciones de desafío contra solicitudes para verificar usuarios humanos y el uso estándar del navegador.


AWS ofrece reglas administradas listas para usar y le recomiendo que las use tanto como sea posible. Estas reglas, que AWS actualiza constantemente, son fáciles de usar y realmente no hay motivo para reinventar la rueda.


Sin embargo, a veces necesitamos utilizar reglas personalizadas.

Una regla puede tener varias condiciones con un 'y', 'o' o 'no' entre ellas. Una condición puede usar una expresión regular para hacer coincidir el encabezado HTTP, un elemento basado en la tasa, bloquear el tráfico que se origina en países específicos o incluso un conjunto de IP (por ejemplo, bloquear el tráfico que no se origina en los rangos de IP de su VPN de trabajo). WAF también tiene la opción de alterar los encabezados (transformarlos) antes de examinarlos. Tiene muchas opciones personalizadas; solo tenga en cuenta que cuanto más avanzada y personalizada sea, más WCU utilizará (consulte la sección WCU ).


https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-statements.html
https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-statements.html

Otra noción importante que hay que recordar es que las reglas tienen prioridad . WAF examina el tráfico desde la prioridad más alta hasta la más baja y, cuando una regla coincide con sus condiciones, realiza la acción definida, sea cual sea.

Por último, puedes habilitar las métricas de CloudWatch para tus reglas WAF. Te sugiero que las habilites, ya que brindan información valiosa sobre si marcan una diferencia (¡conoce qué y por qué estás pagando!). Para obtener más información, consulta la documentación de AWS .

Para obtener otros consejos sobre cómo crear reglas, consulte esta publicación y siempre consulte con un experto en seguridad.


Ahora que ya nos sacamos de encima los conceptos básicos, pasemos a mi sección de consejos y trucos, que analiza cómo trabajar con WAF y usarlo en un entorno SaaS empresarial.

 

Consejos y trucos de AWS WAF

En esta sección, brindaré información y sugerencias que he recopilado al usar AWS WAF en mi organización. Las sugerencias abarcan la propiedad del equipo, la gobernanza organizacional, los registros y los problemas de depuración en la producción y el mantenimiento continuo de las listas de control de acceso de WAF.


Propiedad

Los expertos en seguridad, ya sean arquitectos de seguridad internos o asesores de seguridad externos, desempeñan un papel crucial en el análisis del vector de ataque de su servicio y la construcción del conjunto de reglas de ACL. El arquitecto de seguridad también tiene la tarea de supervisar la adopción general de WAF en toda la organización y las métricas de las reglas a lo largo del tiempo (¿tienen un impacto? ¿Coinciden?).

Por otro lado, los desarrolladores son responsables de traducir estas reglas a plantillas IaC de AWS CDK o Terraform (hablaremos más sobre esto en la segunda publicación de la serie). Los desarrolladores implementarán la ACL de WAF, la asociarán con su recurso de servicio (API Gateway) y agregarán reglas personalizadas si es necesario.

Si hay un problema con WAF, los clientes no pueden conectarse al servicio, etc., los desarrolladores pueden ver los registros y el tráfico de WAF y resolver el incidente con la ayuda de los arquitectos de seguridad.

Este enfoque constituye un buen equilibrio entre gobernanza e independencia del equipo.


Gobernancia

Hablando de gobernanza, en la próxima publicación, analizaremos cómo gestionar estas reglas de manera centralizada. Mientras tanto, se recomienda utilizar una construcción CDK o una plantilla Terraform como patrón arquitectónico de caja negra que contenga todas las reglas recomendadas e implementarlas en toda la organización. Puede leer más sobre este concepto en mi artículo de AWS.com con Anton Aleksandrov " Optimización de la gobernanza sin servidor mediante la codificación de planos arquitectónicos ".

En mi tercer artículo de la serie, analizaremos cómo llevamos la gobernanza más allá y utilizamos AWS Firewall Manager para la gobernanza de seguridad centralizada con AWS WAF.


Agregar reglas de ACL a lo largo del tiempo

La seguridad cambia y se adapta con el tiempo. Las reglas de ACL cambiarán. Sin embargo, agregar una nueva regla (especialmente con una acción de "bloqueo") puede dañar la experiencia de los clientes o incluso bloquearlos si está mal configurada. Por eso, es esencial tener dos variantes de ACL: dev y production. Como indica el nombre, las ACL dev se utilizan en las cuentas de desarrollo y son un excelente campo de pruebas para probar nuevas reglas, patrones de bloqueo u otras técnicas. Trate de pensar de manera innovadora y simule el tráfico de clientes tanto como sea posible.

Una vez que esté seguro de que las nuevas reglas no alterarán la experiencia del cliente, agréguelas a la ACL del WAF de producción.

Aún pueden ocurrir errores y se pueden obstaculizar flujos de clientes inesperados. Por ello, es necesario planificar un método rápido de "ruptura de cristal" que los desarrolladores entrenarán de antemano y sabrán cómo iniciar en caso de un problema de producción. El método de ruptura de cristal puede ser tan simple como una rápida reversión de GitHub para eliminar o ajustar la nueva regla de ACL. Los desarrolladores deben saber sobre un cambio de WAF pendiente y cómo depurarlo correctamente.


Visibilidad y registros

Los desarrolladores deben comprender fácilmente los problemas de los clientes que se originan cuando WAF bloquea sus solicitudes. Afortunadamente, AWS WAF tiene soporte de registro, que debe habilitar por ACL.

Hay tres posibles destinos de registro de WAF:

  1. Cubo S3

  2. Manguera contra incendios Kinesis

  3. Grupo de registros de CloudWatch


Las opciones uno y dos son buenas opciones para la supervisión centralizada, donde todos los registros se envían a una cuenta de AWS, se almacenan, se analizan y se analizan. La desventaja es que requiere que cree una canalización de datos para esos registros y luego administre el acceso para todos los desarrolladores de la organización, ya que necesitan medios para depurar sus problemas de producción de servicios.

AWS ha publicado recientemente un vídeo que muestra cómo se puede crear un pipeline de este tipo:



Sin embargo, mi opción preferida es la opción número tres , usar un grupo CloudWatch local, ya que es simple y permite a los desarrolladores usar información y herramientas de CloudWatch para depurar los registros WAF en su cuenta, por lo que no se requieren permisos especiales. Si elige esta opción, configure el tiempo de retención de registros en 7 a 14 días como máximo para reducir los costos de almacenamiento de registros.

Para obtener más información, consulte la documentación de AWS .


Unidad de agua potable WAF y precios

AWS WAF utiliza WCU para calcular y controlar los recursos operativos necesarios para ejecutar sus reglas, grupos de reglas y listas de control de acceso web. Los requisitos de WCU para un grupo de reglas están determinados por las reglas que usted define dentro del grupo de reglas. La capacidad máxima para un grupo de reglas es de 5000 WCU. - AWS

Si bien preferiría agregar la máxima seguridad y crear la ACL perfecta con todas las reglas posibles, no es posible debido al límite de 5000 WCU. Debe encontrar el equilibrio correcto entre la cobertura de seguridad y el WCU general. Intente usar las reglas administradas por AWS tanto como sea posible, ya que están más optimizadas para WCU y bien mantenidas.

Otro problema crítico es el costo. WAF es caro porque se paga por reglas, listas de control de acceso y volumen de tráfico que pasa por la lista de control de acceso. Para obtener más detalles, consulte la calculadora de precios .

 

Resumen

En esta publicación, presento el firewall de aplicaciones web de AWS y explico por qué debería usarlo. También cubrimos los conceptos básicos de las ACL y las reglas. Por último, compartí algunos consejos cruciales que aprendí al usar y actualizar WAF en una gran empresa.

En la próxima publicación de la serie , proporcionaré el código AWS CDK para la implementación de WAF y lo asociaré con una API Gateway.

En esa tercera publicación, revisaremos AWS Firewall Manager y cómo permite a la organización administrar las ACL de AWS Application Web Firewall a escala.

bottom of page