Descripción general de las políticas de firewall jerárquicas

Las políticas de firewall jerárquicas te permiten crear y aplicar una política de firewall coherente en toda la organización. Puedes asignar políticas de firewall jerárquicas a toda la organización o a carpetas individuales. Estas políticas contienen reglas que pueden rechazar o permitir las conexiones de forma explícita, al igual que las reglas de firewall de la nube privada virtual (VPC). Además, las reglas de políticas de firewall jerárquicas pueden delegar la evaluación a políticas de nivel inferior o a las reglas de firewall de la red de VPC con una acción goto_next.

Las reglas de nivel inferior no pueden anular una regla de un nivel superior en la jerarquía de recursos. Esto permite que los administradores de toda la organización administren las reglas de firewall fundamentales en un solo lugar.

Especificaciones

  • Las políticas de firewall jerárquicas se pueden especificar en los nodos de la organización y la carpeta.
  • Las políticas de firewall jerárquicas son contenedores para las reglas de firewall. Cuando asocias una política con la organización o una carpeta, todas las reglas se aplican de inmediato. Puedes intercambiar políticas para un nodo, lo cual intercambia de forma atómica todas las reglas de firewall que se aplicaron a instancias de máquinas virtuales (VM) en ese nodo.
  • La evaluación de reglas es jerárquica según la jerarquía de recursos. Se evalúan todas las reglas asociadas al nodo de la organización, seguidas por las que se encuentran en el primer nivel de carpetas y así sucesivamente.
  • Las reglas de políticas de firewall jerárquicas tienen una acción goto_next nueva que puedes usar para delegar la evaluación de conexión a niveles inferiores de la jerarquía.
  • Las reglas de políticas de firewall jerárquicas pueden orientarse a redes de VPC y VM específicas mediante recursos de destino. Esto te permite crear excepciones para grupos de VM.
  • Una función nueva te permite ver qué reglas de firewall se aplican a una interfaz de red o de VM específica, lo que ayuda con el cumplimiento y la depuración.

Jerarquía de recursos

Puedes crear y aplicar políticas de firewall como pasos independientes. Puedes crear y aplicar políticas de firewall en los nodos de la organización o de la carpeta de la jerarquía de recursos. Una regla de políticas de firewall puede bloquear conexiones, permitirlas o aplazar la evaluación de reglas de firewall en carpetas de nivel inferior o reglas de firewall de VPC definidas en redes de VPC.

  • La organización es el nodo de nivel superior en la jerarquía de recursos de Google Cloud en la que puedes crear o asociar políticas de firewall jerárquicas. Todas las carpetas y redes de VPC de la organización heredan esta política.

  • Las carpetas son nodos de nivel intermedio en la jerarquía de recursos de Google Cloud, entre la organización y los proyectos, en las que puedes crear o asignar políticas de firewall jerárquicas. Todas las carpetas y redes de VPC de una carpeta heredan su política asociada.

  • Un proyecto reside en una organización o carpeta. Puedes mover proyectos entre los nodos de una organización. Los proyectos contienen redes de VPC. Las políticas de firewall jerárquicas no se pueden asignar a proyectos, solo a la organización o a las carpetas.

  • Una red de VPC es la partición de Google Cloud para la comunicación de espacios de IP interna aislada. Este es el nivel en el que se especifican y aplican las rutas y las reglas de firewall de VPC tradicionales. Las reglas de políticas de firewall jerárquicas pueden anular reglas de firewall de red o delegar la evaluación de conexión a ellas.

De forma predeterminada, todas las reglas de políticas de firewall jerárquicas se aplican a todas las VM en todos los proyectos de la organización o carpeta a la que está asociada la política. Sin embargo, puedes restringir qué VM obtienen una regla determinada si especificas una red de destino o una cuenta de servicio de destino.

Los niveles de la jerarquía en los que se pueden aplicar las reglas de firewall se representan en el siguiente diagrama. Los cuadros amarillos representan políticas de firewall jerárquicas que contienen reglas de firewall, y los cuadros blancos representan reglas de firewall de VPC.

Políticas de firewall jerárquicas que contienen reglas (cuadros amarillos) a nivel de organización y de carpeta, y reglas de firewall de VPC a nivel de red de VPC
Políticas de firewall jerárquicas que contienen reglas (cuadros amarillos) a nivel de organización y de carpeta, y reglas de firewall de VPC a nivel de red de VPC

Evaluación de reglas

Las reglas de políticas de firewall jerárquicas se aplican a nivel de VM, al igual que las reglas de firewall de VPC. Es decir, no se aplican en el perímetro de la red como los firewalls tradicionales.

Google Cloud evalúa las reglas de políticas de firewall jerárquicas y las reglas de firewall de VPC en este orden:

  1. Si una política de firewall está asociada con una organización, Google Cloud evalúa las reglas de esa política que se aplicaron a la VM. Cada regla da como resultado las conexiones permitidas o rechazadas, o la regla puede indicarle a la evaluación del firewall que pase al siguiente nivel de jerarquía, que puede ser una carpeta o una red de VPC.
  2. Google Cloud evalúa las reglas de políticas asociadas con cada carpeta. Comienza por la carpeta superior en la organización y sigue con las carpetas secundarias, si las hay.

    La evaluación de cada regla da como resultado las conexiones permitidas o rechazadas, o la regla puede indicarle a la evaluación del firewall que pase al siguiente nivel de jerarquía, que puede ser otra carpeta o una red de VPC.

  3. Por último, se evalúan las reglas de firewall de VPC. Las reglas de firewall de VPC permiten o rechazan las conexiones.

Flujo de resolución de las reglas de firewall
Flujo de resolución de las reglas de firewall

Detalles de las políticas de firewall jerárquicas

Las reglas de políticas de firewall jerárquicas se definen en un recurso de política de firewall que actúa como un contenedor para las reglas de firewall. Las reglas que se definen en una política de firewall no se aplican hasta que la política esté asociada con un nodo (una organización o una carpeta).

Se puede asociar una sola política con varios nodos. Si modificas una regla en una política, esa modificación se aplica a todos los nodos asociados en la actualidad.

Solo se puede asociar una política de firewall con un nodo. Las reglas de políticas de firewall jerárquicas y las reglas de firewall de VPC se evalúan en un orden bien definido.

Nombres de políticas

Cuando creas una política nueva, Google Cloud genera un ID para la política de forma automática. Además, debes especificar un nombre visible para la política. Cuando usas la interfaz de gcloud para actualizar una política existente, puedes hacer referencia al ID generado por el sistema o a una combinación del nombre visible y el ID de la organización. Cuando usas la API para actualizar la política, debes proporcionar el ID que generó el sistema.

Detalles de las reglas de políticas de firewall jerárquicas

Las políticas de firewall jerárquicas contienen reglas que suelen funcionar de la misma manera que las reglas de firewall de VPC, pero existen algunas diferencias.

Prioridad

  • A diferencia de las reglas de firewall de VPC, en las que varias reglas pueden tener la misma prioridad, las reglas de políticas de firewall jerárquicas deben tener una prioridad específica, y cada prioridad debe ser única dentro de una política de firewall.

  • Las reglas de políticas de firewall jerárquica no tienen nombres. En su lugar, la política de firewall en sí tiene un ID y un nombre, y cada regla tiene un número de prioridad único.

  • Dentro de una política de firewall jerárquica, las reglas de firewall se evalúan en orden de prioridad, y se comienza con la regla de mayor prioridad (número más bajo). Por lo tanto, una regla con prioridad 0 en una política asignada al nodo de la organización anula cualquier otra regla de la organización.

Acción en casos de coincidencia

  • allow
    Una regla de firewall jerárquica allow anula cualquier regla deny con una prioridad más baja o en un nivel inferior en la jerarquía. Usa reglas allow en una política de la organización o de la carpeta para permitir de forma incondicional ciertos tipos de conexiones a todas las VM en ese nodo de la jerarquía.

    Por ejemplo, si tienes sistemas de sondeo administrados de forma central que supervisan todas las VM de la organización, puedes crear una regla allow a nivel de organización para asegurarte de que a las solicitudes de las direcciones IP de los sistemas de sondeo no las bloquee una red en cualquier proyecto.

  • deny
    Una regla de firewall jerárquica deny anula cualquier regla allow con una prioridad más baja o en un nivel inferior en la jerarquía.

    Por ejemplo, si deseas asegurarte de que no se pueda acceder a ninguna de las VM de la organización desde un rango de IP específico, puedes crear una regla deny para ese rango.

  • goto_next
    Dirige al firewall para que cambie la evaluación del firewall al siguiente nivel inferior de la jerarquía. Puedes usar esta opción a fin de delegar tipos específicos de conexiones para que las administren los niveles inferiores.

Redes de destino

Puedes restringir una regla de políticas de firewall jerárquicas a VM solo en redes especificadas. Especificar la red de destino en la regla te permite controlar qué redes de VPC se configuran con esa regla. Si la combinas con goto_next o allow, podrás crear excepciones para redes específicas cuando quieras definir una política que de otra manera estaría restringida.

Cuentas de servicio de destino

Puedes especificar una cuenta de servicio de destino para una regla. Estas reglas se aplican solo a las VM que pertenecen a la cuenta de servicio especificada. Las reglas de políticas de firewall jerárquicas no son compatibles con la elección de un destino mediante etiquetas de instancia.

Protocolos y puertos

Al igual que con las reglas de firewall de VPC, debes especificar una o más restricciones de protocolos y puertos cuando creas una regla. Cuando especificas TCP o UDP en una regla, puedes especificar el protocolo, el protocolo y un puerto, o el protocolo y un rango de puertos. No puedes especificar solo un puerto o rango de puertos. Para ICMP, especifica icmp. Las reglas de firewall no admiten la especificación de códigos y tipos de ICMP.

Registros

El registro de las reglas de políticas de firewall jerárquicas funciona igual que el registro de reglas de firewall de VPC, excepto por las siguientes diferencias:

  • El campo de referencia incluye el ID de la política de seguridad y un número que indica el nivel jerárquico del nodo al que se adjunta la política. Por ejemplo, 0 significa que la política se aplica a una organización, y 1 significa que la política se aplica a una carpeta de nivel superior en la organización.

  • Los registros de las reglas de políticas de firewall jerárquicas incluyen un campo target_resource que identifica las redes de VPC a las que se aplica la regla.

El registro solo se puede habilitar para las reglas allow y deny; no se puede habilitar en reglas goto_next.

Reglas predefinidas

Todas las políticas de firewall jerárquicas tienen dos reglas goto_next predefinidas con la prioridad más baja. Estas reglas se aplican a cualquier conexión que no coincida con una regla definida de manera explícita en la política, lo que provoca que esas conexiones se pasen a políticas o reglas de red de nivel inferior.

  • Una regla de salida con una prioridad muy baja (2147483646) que envía el procesamiento de la conexión al siguiente nivel inferior de evaluación (goto_next)
  • Una regla de entrada con una prioridad muy baja (2147483647) que envía el procesamiento de la conexión al siguiente nivel inferior de evaluación (goto_next)

Estas reglas predefinidas son visibles, pero no pueden modificarse ni borrarse. También son diferentes de las reglas implícitas y propagadas con anterioridad de una red de VPC.

Funciones de administración de identidades y accesos (IAM)

Las siguientes funciones son pertinentes a las políticas de firewall jerárquicas.

Nombre de la función Descripción
compute.orgSecurityPolicyAdmin Se otorga a nivel de organización o a una carpeta y permite que los usuarios creen, actualicen y borren políticas de seguridad jerárquicas y sus reglas. También permite que el administrador asocie una política con un nodo si tiene la función compute.orgSecurityResourceAdmin en ese nodo.
compute.orgSecurityResourceAdmin Se otorga a nivel de organización o a una carpeta y permite que los administradores a nivel de carpeta asocien una política con ese nodo. Los administradores también deben tener la función compute.orgSecurityPolicyUser en el nodo al que pertenece la política para poder usarla.
compute.orgSecurityPolicyUser Se otorga a nivel de organización o a una carpeta y permite que los administradores usen las políticas asociadas con la organización o carpeta. Los usuarios también deben tener la función compute.orgSecurityResourceAdmin en el nodo de destino para asociar una política con ese nodo.
compute.securityAdmin
compute.viewer
compute.securityReadOnly
compute.networkUser
compute.networkViewer
Permite que los usuarios vean las reglas de firewall que se aplicaron a la red o instancia.
Incluye el permiso compute.networks.getEffectiveFirewalls para las redes y el compute.instances.getEffectiveFirewalls para las instancias.

En el siguiente ejemplo, Joe puede crear, modificar y borrar cualquier política de firewall jerárquica en la carpeta policies, pero no puede adjuntar la política de firewall jerárquica a una carpeta porque no tiene la función orgSecurityResourceAdmin en ninguna.

Sin embargo, dado que Joe le otorgó a Mary permisos para usar policy-1, puede enumerar y asociar esa política de firewall jerárquica con la carpeta dev-projects o cualquiera de sus descendientes. La función orgSecurityPolicyUser no otorga permisos para asociar las políticas a ninguna carpeta, el usuario también debe tener la función orgSecurityResourceAdmin en la carpeta de destino.

Ejemplo de policy-1
Ejemplo de policy-1

Administra recursos de políticas de firewall jerárquicas

Debido a que una política de firewall jerárquica solo define un conjunto de reglas de firewall y no dónde se aplican, puedes crear estos recursos en una parte de la jerarquía diferente de los nodos a los que se aplican. Esto te permite asociar un solo recurso de política de firewall jerárquica con varias carpetas en la organización.

En el siguiente ejemplo, policy-1 se aplica a las carpetas dev-projects y corp-projects y, por lo tanto, a todos los proyectos dentro de esas carpetas.

Asociación y ubicación de la política
Asociación y ubicación de la política

Modifica las reglas de una política

Puedes agregar, quitar y modificar reglas en una política. Los cambios se realizan de forma individual, no hay un mecanismo para actualizar las reglas de una política por lotes. Los cambios se aplican en el orden aproximado en que se ejecutan los comandos, aunque esto no está garantizado.

Si realizas cambios grandes a una política de firewall jerárquica y necesitas asegurarte de que se apliquen al mismo tiempo, puedes clonar la política en una política temporal y asignarla a los mismos nodos. Después, puedes hacer los cambios en la original y, luego, asignarla a los nodos. Si deseas obtener los pasos para realizar esta tarea, consulta Copia reglas de una política a otra.

En el siguiente ejemplo, policy-1 se adjunta a la carpeta dev-projects; te recomendamos realizar varios cambios que se apliquen de forma automática. Crea una política nueva llamada scratch-policy y, luego, copia todas las reglas existentes de policy-1 a scratch-policy para editarla. Cuando termines de editar, copia todas las reglas de scratch-policy de nuevo a policy-1.

Modifica una política
Modifica una política

Mueve una política

Las políticas de firewall jerárquicas, como los proyectos, tienen un recurso de carpeta o de organización superior. A medida que evoluciona el esquema de las carpetas, es posible que debas mover una política de firewall jerárquica a una carpeta nueva, quizás antes de la eliminación de una carpeta. Si se borra una carpeta, también se borran las políticas dentro de ella.

En el siguiente diagrama, se ilustran las asociaciones del movimiento de una política entre nodos o la evaluación de reglas en la política.

Mueve una política
Mueve una política

Asocia una política de firewall jerárquica con una carpeta

Una política de firewall jerárquica no se aplica, a menos que esté asociada con un nodo de organización o de carpeta. Una vez que se asocia, se aplica a todas las VM en todas las redes de esa organización o carpeta.

Asocia una política
Asocia una política

Cambios en la jerarquía de recursos

Es posible que los cambios en la jerarquía de recursos tomen un tiempo en propagarse en el sistema. Te recomendamos evitar las actualizaciones simultáneas de los adjuntos de la política de firewall jerárquica y de la jerarquía de recursos, ya que las redes podrían no heredar de inmediato la política de firewall jerárquica definida en la ubicación nueva en la jerarquía.

Mueve una política
Mueve una política

Por ejemplo, si mueves la carpeta dept-A de la carpeta dev-projects a la carpeta eng-projects y cambias la asociación de policy-1 por eng-projects en lugar de dev-projects, asegúrate de no desasociar policy-1 de dev-projects al mismo tiempo. Si la carpeta dev-projects pierde su asociación de política de firewall jerárquica antes de que todas las redes de VPC que contiene actualicen sus principales, policy-1 no protegerá a esas redes de VPC por un corto período.

Usa políticas de firewall jerárquicas con VPC compartida

En situaciones de VPC compartida, una interfaz de VM conectada a una red de proyecto host se rige por las reglas de políticas de firewall jerárquicas del proyecto host, no del proyecto de servicio.

VM en VPC compartida
VM en VPC compartida

Incluso si los proyectos de servicio están en una carpeta diferente a la del proyecto host, las interfaces de VM en la red compartida aún heredan de las reglas de la carpeta del proyecto host.

Las VM del proyecto de servicio heredan reglas del proyecto host
Las VM del proyecto de servicio heredan reglas del proyecto host

Usa políticas de firewall jerárquicas con intercambio de tráfico entre redes de VPC

En situaciones de intercambio de tráfico entre redes de VPC, la interfaz de VM asociada con cada una de las redes de VPC hereda las políticas en la jerarquía de las respectivas redes de VPC. A continuación, se muestra un ejemplo de intercambio de tráfico entre redes de VPC en el que las redes con intercambio de tráfico de VPC pertenecen a organizaciones diferentes.

VM heredadas de redes respectivas
VM heredadas de redes respectivas

Reglas de firewall vigentes

Debido a que las conexiones se rigen por las reglas de políticas de firewall jerárquicas y las reglas de firewall de VPC, es útil ver todas las reglas de firewall que afectan a una red individual o a una interfaz de VM individual.

Es posible que los administradores a nivel de proyecto no tengan permiso para ver las reglas en las políticas de firewall jerárquicas que afectan a las VM. Sin embargo, si un usuario tiene permisos para ver las reglas de firewall de una red, puede ver todas las reglas que se aplican a la red, incluso si las reglas se heredan de una carpeta o de la organización.

Política de seguridad vigente de la red

Puedes ver todas las reglas de firewall que se aplican a una red de VPC. En la lista, se incluyen todas las reglas heredadas de las políticas de firewall jerárquicas y todas las reglas aplicadas desde la red de VPC.

Reglas de firewall vigentes de la instancia

Puedes ver todas las reglas de firewall que se aplican a la interfaz de red de una VM. En la lista, se incluyen todas las reglas heredadas de las políticas de firewall jerárquicas y todas las reglas aplicadas desde la interfaz de la red de VPC.

Las reglas se ordenan desde el nivel de organización hasta las reglas de VPC. Solo se muestran las reglas que se aplican a la interfaz de VM. Las reglas de otras políticas no se muestran, por lo que un usuario no puede ver la política de seguridad general de la organización.

Próximos pasos