Controla el acceso con firewalls

Un firewall determina qué tráfico de red puede pasar y qué tráfico se rechaza. En App Engine, puedes crear un firewall con hasta 1,000 reglas individuales priorizadas que pueden permitir o restringir un rango de direcciones IP y subredes. Tu app solo responderá a las solicitudes que el firewall permita.

Antes de comenzar

Antes de crear reglas de firewall de App Engine para tu app, debes tener una de las siguientes funciones de IAM de App Engine, que incluyen los privilegios necesarios para crear o modificar reglas de firewall:

  • Administrador de App Engine
  • Editor
  • Propietario

Crea reglas de firewall

Crea una regla de firewall mediante uno de los métodos siguientes. Repite estos pasos para crear cada regla adicional:

Console

Usa la página Reglas de firewall en Cloud Console para crear una regla de firewall:

  1. Ve a la página Crea una regla de firewall en Cloud Console:

    Ir a la página Crea una regla de firewall

  2. Específica los detalles para la regla de firewall:

    1. En Prioridad, ingresa un número entero para especificar la importancia relativa de la regla y definir el orden en que se evalúa.

      Los valores válidos van desde 1 hasta 2147483646. La regla que tiene la prioridad 1 es la que se evalúa primero. La regla que tiene la prioridad 2147483647 es la última que se evalúa y se reserva para la regla predeterminada.

    2. En Acción en caso de coincidencia, especifica si deseas permitir o rechazar el acceso a las solicitudes que coinciden con la regla. Las reglas configuradas como allow reenvían la solicitud a la app. Las reglas configuradas como deny responden a las solicitudes con un error 403 Forbidden.
    3. En el Rango de IP, debes definir el rango de direcciones IP al que se aplica la regla. El rango de direcciones IP debe definirse con la notación CIDR; puede incluir máscaras de subred y admitir IPv4 e IPv6.
    4. Opcional: en Descripción, incluye una descripción de la regla de hasta 100 caracteres.
  3. Haz clic en Guardar para crear la regla.
  4. Prueba la regla para asegurarte de que la prioridad y la acción se comporten de la manera esperada:
    1. Haz clic en Probar dirección IP.
    2. Ingresa la dirección IP que deseas validar y, luego, haz clic en Probar para asegurarte de que la regla correspondiente se evalúe de forma correcta.
gcloud

Ejecuta los siguientes comandos gcloud app firewall-rules para crear una regla de firewall:

  1. Ejecuta el siguiente comando para crear una regla de firewall:

    gcloud app firewall-rules create PRIORITY --action ALLOW_OR_DENY --source-range IP_RANGE --description DESCRIPTION
    En el ejemplo anterior, se ilustra lo siguiente:
    • PRIORITY es un número entero entre 12147483646 que define la importancia de la regla y el orden en que se evalúa. La regla que tiene la prioridad 1 es la que se evalúa primero. La regla que tiene la prioridad 2147483647 es la última que se evalúa y se reserva para la regla predeterminada.
    • ALLOW_OR_DENY especifica si se permite o se rechaza el acceso a las solicitudes que coinciden con la regla. Los valores válidos son allow o deny. Las reglas configuradas como allow reenvían la solicitud a la app. Las reglas configuradas como deny responden a las solicitudes con un error 403 Forbidden.
    • IP_RANGE define el rango de direcciones IP al que se aplica la regla. El rango de IP debe definirse con la notación CIDR; puede incluir máscaras de subred y admitir IPv4 e IPv6.
    • DESCRIPTION es una descripción opcional de la regla de hasta 100 caracteres.
  2. Ejecuta el siguiente comando para probar tu regla y asegurarte de que la prioridad y la acción se comporten de la manera esperada:
    gcloud app firewall-rules test-ip IP_ADDRESS
    en donde IP_ADDRESS es la dirección IP con la que deseas probar tu firewall.
  3. Ejecuta el siguiente comando para ver una lista de las reglas existentes:
    gcloud app firewall-rules list
  4. Ejecuta el siguiente comando para borrar una regla existente:
    gcloud app firewall-rules delete PRIORITY
    donde PRIORITY es el valor de prioridad de la regla que deseas borrar.
Ejemplos:
Usa los siguientes ejemplos a modo de ayuda para crear el firewall:
  • Agrega una regla que permita una dirección IPv6 y una máscara de subred y, luego, prueba la regla para asegurarte de que se evalúe antes que las demás:

    gcloud app firewall-rules create 123 --source-range fe80::3636:3bff:fecc:8778/128 --action allow
    gcloud app firewall-rules test-ip fe80::3636:3bff:fecc:8778
  • Agrega una regla para denegar una dirección IPv4 y una máscara de subred, y luego prueba la regla a fin de asegurarte de que se evalúe de forma apropiada:

    gcloud app firewall-rules create 123456 --source-range "74.125.0.0/16" --action deny
    gcloud app firewall-rules test-ip 74.125.0.8
  • Actualiza y prueba la regla predeterminada para asegurarte de que restringe todas las direcciones IP que no coinciden con otras reglas:

    gcloud app firewall-rules update default --action deny
    gcloud app firewall-rules test-ip 123.456.7.89
API

A fin de crear reglas de firewall de manera programática para la app de App Engine, puedes usar los métodos apps.firewall.ingressRules en la API de Administrador.

Para probar una regla de firewall y asegurarte de que la prioridad y la acción se comportan de la manera esperada, puedes usar el método apps.firewall.ingressRules.list y especificar la dirección IP que deseas probar dentro del parámetro matchingAddress.

Información sobre las reglas de firewall de App Engine

Un firewall de App Engine está compuesto por una lista ordenada de reglas que pueden permitir o rechazar el acceso de una dirección IP o un rango específico a la app. La regla se aplica a todos los recursos de la aplicación de App Engine.

Las reglas del firewall se ordenan según su importancia, que puedes definir con un valor numérico en la prioridad de cada regla. Debes especificar un único valor de prioridad para cada regla, ya que define la importancia en relación con las demás reglas del firewall. Los valores para la prioridad de las reglas van desde el más importante (1) hasta el menos importante (2147483647).

Cada firewall incluye una regla default que se crea de forma automática con la prioridad 2147483647 y se aplica al rango completo de IP de la app. La regla default siempre se evalúa después de todas las otras en el firewall y se aplica a todas las solicitudes en todas las direcciones IP.

El firewall evalúa primero la regla con mayor prioridad. Las reglas restantes se evalúan de forma secuencial hasta que una coincida con el rango de IP de esa solicitud. Cuando se encuentra una regla que coincide, se admite o se rechaza la conexión y se omiten las demás reglas de firewall. Si ninguna de las reglas definidas de forma manual en el firewall coincide con la solicitud, se evalúa la regla default.

Por ejemplo, si creas una regla con prioridad 1, siempre se evalúa primero. Si una solicitud entrante coincide con la regla de prioridad 1, solo se evalúa esa y se omiten las demás reglas de firewall, incluida la default.

En el siguiente firewall de ejemplo, se muestra cómo puede cambiar el comportamiento del firewall según la prioridad de una regla.

Firewalls de App Engine y Cloud Load Balancing

Si usas Cloud Load Balancing y NEG sin servidores, ten en cuenta lo siguiente:

  • El balanceador de cargas no interfiere ni interactúa con las reglas de firewall de App Engine. Las reglas de App Engine no se evalúan hasta que un NEG sin servidores dirige el tráfico a App Engine.
  • No puedes inhabilitar las URL que Google Cloud asigna de forma automática a los servicios de App Engine. Los usuarios que ya tienen la URL predeterminada del servicio de App Engine pueden omitir el balanceador de cargas y dirigirse directamente a la URL del servicio. Esto significa que, aunque puedas configurar las políticas de seguridad de Google Cloud Armor, los certificados SSL y las claves privadas a través del balanceador de cargas, los usuarios con la URL predeterminada pueden eludir estas políticas.

Firewall de ejemplo

En este ejemplo, una empresa configuró un firewall para que el equipo de ingenieros y la red corporativa interna tengan acceso a la app en desarrollo. Las reglas de firewall se crearon con espacios grandes entre cada prioridad para permitir el crecimiento.

Prioridad Acción Rango de IP Descripción
1000 Denegar 192.0.2.1 Rechaza el acceso a un ataque de DoS.
2,000 Permitir 198.51.100.2 Permite el acceso a un ingeniero de la oficina satélite.
3000 Denegar 198.51.100.0/24 Rechaza el acceso a los edificios que no son de ingeniería.
5000 Permitir 203.0.113.0/24 Permite el acceso a la red del edificio principal.
2147483647 Denegar * Acción predeterminada

Luego de crear el firewall, imagina que las siguientes solicitudes se envían a la aplicación de muestra y observa la respuesta:

  • La solicitud desde 198.51.100.2 coincide con la regla con prioridad 2000 y se permite.
  • La solicitud desde 198.51.100.100 coincide con la regla con prioridad 3000 y se rechaza.
  • La solicitud desde 203.0.113.54 coincide con la regla con prioridad 5000 y se permite.
  • La solicitud desde 45.123.35.242 coincide con la regla predeterminada y se rechaza.

Resuelve los conflictos de reglas

Por ejemplo, supone que se intercambian dos de las prioridades del firewall de la empresa. Observa el comportamiento no deseado si se intercambian las reglas con prioridades 2000 y 3000, observa el comportamiento no deseado.

Prioridad Acción Rango de IP Descripción
1000 Denegar 192.0.2.1 Rechaza el acceso a un ataque de DoS.
2,000 Denegar 198.51.100.0/24 Rechaza el acceso a los edificios que no son de ingeniería.
3,000 Permitir 198.51.100.2 Permite el acceso a un ingeniero de la oficina satélite.
5000 Permitir 203.0.113.0/24 Permite el acceso a la red del edificio principal.
2147483647 Denegar * Acción predeterminada

El ingeniero en la oficina satélite no podrá acceder a la app de la empresa, ya que, por la nueva prioridad de la regla, esta nunca se evaluará. La dirección IP 198.51.100.2 del ingeniero coincide con la regla que rechaza el acceso a todas las personas que no son ingenieros en el rango 198.51.100.0/24 antes de la regla que permite el acceso a la dirección IP del ingeniero.

Para solucionar el problema, debes modificar la configuración a fin de que la regla que permite el acceso a 198.51.100.2 tenga mayor prioridad que la regla que rechaza el acceso al rango de IP de 198.51.100.0/24.

Permite solicitudes de tus servicios

Cuando creas reglas, debes considerar los siguientes puntos:

  • De forma predeterminada, cualquier solicitud que no coincida con una regla tendrá acceso a la app. Si deseas bloquear todas las solicitudes que no coinciden con una regla específica, debes establecer la regla default como deny.
  • El firewall permite el tráfico de las listas de tareas en cola, incluso cuando la regla default se configura como deny.
  • Se permitirá el tráfico de cron en el entorno estándar. Para validar solicitudes cron entrantes que provienen de apps de App Engine, consulta Valida solicitudes cron.

    En el entorno flexible, debes permitir de forma explícita el tráfico de cron. Si deseas obtener más información sobre la creación de reglas de firewall en el entorno flexible de App Engine, consulta Crea firewalls.

  • Para controlar el acceso de solicitudes de otras apps o servicios de App Engine, puede que debas crear reglas que admitan las direcciones IP que se usan en comunicaciones de servicio a servicio. Si la app se comunica con otras apps o servicios en App Engine, debes tener en cuenta cómo controlar las solicitudes de las siguientes direcciones IP:

    • Solicitudes del servicio de recuperación de URL: 0.1.0.40
      • Solicitudes recibidas en el entorno estándar: 0.1.0.40
      • Solicitudes recibidas en el entorno flexible: 0.1.0.40 y 10.0.0.1
      • Puede que las solicitudes de 0.1.0.4010.0.0.1 provengan de cualquier app de App Engine
      • Puedes usar el encabezado X-Appengine-Inbound-AppId para determinar el ID de la app de origen
    • Solicitudes de Blobstore o de Cloud Storage: 0.1.0.30
    • Solicitudes recibidas solo en el entorno estándar:
      • Solicitudes de implementación de apps: 10.1.0.41
    • Solicitudes de instancias de Compute Engine con el Acceso privado a Google habilitado: 0.0.0.0
      • Las solicitudes de 0.0.0.0 provendrán de cualquier instancia de Compute Engine con el Acceso privado a Google habilitado.

    Ejemplo

    La app tiene un servicio de backend que se ejecuta en el entorno estándar (backend_std). Este servicio usa el servicio de recuperación de URL para comunicarse con backend_flex.

    Para permitir las solicitudes, debes crear dos reglas de firewall y, en backend_flex, debes leer el encabezado X-Appengine-Inbound-AppId para asegurarte de que corresponda al ID de la app de backend_std:

    • 0.1.0.40: Una regla que permite que backend_flex reciba solicitudes del servicio de recuperación de URL de backend_std.
    • 10.0.0.1: Una regla que permite la comunicación de servicio a servicio para las solicitudes del servicio de recuperación de URL en backend_flex.
    • En backend_flex, solo permite las solicitudes en las que el encabezado X-Appengine-Inbound-AppId sea igual al ID de backend_std.

Evita el acceso al contenido almacenado en caché

El firewall de App Engine se sitúa detrás de los mecanismos que almacenan contenido en caché, como proxies web y navegadores. Cuando el contenido se almacena en caché, se entrega de forma pública desde la URL específica hasta que vence, y se puede acceder a él incluso después de haber creado reglas de firewall nuevas.

Para evitar que el contenido quede almacenado en caché, usa los encabezados de respuesta HTTP Cache-Control y Expires. Para obtener más información sobre estos encabezados HTTP y sobre cómo controlar el almacenamiento en caché, consulta Evita el almacenamiento en caché.

Próximos pasos

Para asegurarte de que configuraste la app de forma segura y estableciste los niveles de acceso apropiados, consulta Seguridad para aplicaciones y Control de acceso.