Las políticas de seguridad jerárquicas son una categoría de políticas de seguridad que amplían el alcance del cortafuegos de aplicaciones web (WAF) y la protección frente a DDoS de Cloud Armor más allá de los proyectos individuales. Se adjuntan a nivel de organización, carpeta o proyecto. Estas políticas son diferentes de las de seguridad a nivel de servicio, que se adjuntan directamente a los servicios de backend o a los segmentos de backend.
Cuando configuras una política de seguridad jerárquica a nivel de organización o de carpeta, los proyectos de los niveles inferiores de la jerarquía heredan esa política de seguridad. Esta herencia te permite configurar reglas de políticas de seguridad que quieras aplicar a todos los proyectos de tu organización o a varios de ellos. De esta forma, se puede aplicar la seguridad de forma centralizada y coherente en todo tu Trusted Cloud by S3NS entorno.
En esta página se explica en qué se diferencian las políticas de seguridad jerárquicas de las políticas de seguridad a nivel de servicio. Antes de continuar, lee el resumen de la política de seguridad para asegurarte de que entiendes cómo funcionan las políticas de seguridad. Además, te recomendamos que te familiarices con la jerarquía de recursos.
Casos prácticos
En las organizaciones grandes, gestionar las políticas de seguridad en numerosos proyectos puede ser complejo y llevar mucho tiempo. Las políticas de seguridad jerárquicas ofrecen las siguientes ventajas para ayudarte a afrontar estos retos:
- Control centralizado: ofrece a los administradores de organizaciones y carpetas la posibilidad de definir y aplicar políticas de seguridad en varios proyectos.
- Coherencia: proporciona una postura de seguridad uniforme en toda la organización, lo que reduce el riesgo de que se produzcan errores de configuración y brechas de seguridad.
- Eficiencia: agiliza la implementación de actualizaciones de seguridad y medidas de mitigación, como el bloqueo de intervalos de direcciones IP específicos o la resolución de vulnerabilidades críticas, en un gran número de recursos simultáneamente.
- Delegación: permite delegar responsabilidades de seguridad en diferentes equipos o departamentos aplicando políticas en los niveles adecuados de la jerarquía.
Puedes aplicar y combinar estos principios generales para adaptarlos a las necesidades de tu organización. Veamos los siguientes ejemplos de casos prácticos:
- Bloqueo de direcciones IP en toda la organización: puedes bloquear el tráfico de intervalos de direcciones IP maliciosas conocidas en todos los proyectos de tu organización.
- Restricciones geográficas: puede restringir el tráfico de regiones geográficas específicas a nivel de organización o de carpeta.
- Mitigación de CVEs: puedes implementar rápidamente reglas de WAF para mitigar vulnerabilidades críticas en varios proyectos.
- Cumplimiento obligatorio: puedes obligar a cumplir los requisitos normativos aplicando políticas de seguridad coherentes en toda tu organización.
- Control de acceso granular: puedes conceder acceso a intervalos de direcciones IP o regiones geográficas específicos a todos los recursos de una carpeta concreta.
Funciones
Las políticas de seguridad jerárquicas admiten un subconjunto de las funciones que admiten las políticas de seguridad a nivel de servicio. En la siguiente tabla se comparan las funciones de Cloud Armor que puedes usar con políticas de seguridad jerárquicas y políticas de seguridad a nivel de servicio:
| Tipo de frontend |
|
|
| Punto de acoplamiento (recurso protegido) | Servicio de backend | Nodos de jerarquía de recursos |
| Acciones de regla |
|
|
| Dirección IP de origen | ||
| Geografía de origen | ||
| ASN de origen | ||
| Gestión de bots | (solo
EXTERNAL_302 y decoración de solicitudes) |
|
| Filtrado de capa 7 | ||
| WAF | ||
| Google Threat Intelligence | ||
| reCAPTCHA | ||
| Adaptive Protection | ||
| Grupos de direcciones | ||
| Grupos de direcciones a nivel de organización | ||
| Security Command Center | ||
| Cloud Monitoring | ||
| Registro de solicitudes |
Cómo funcionan las políticas de seguridad jerárquicas
Cuando creas una política de seguridad jerárquica, lo haces a nivel de organización o de carpeta, y ese recurso tiene la propiedad de la política de seguridad jerárquica. Después de crear una política de seguridad jerárquica, las reglas de la política de seguridad no se aplican a ninguno de tus recursos.
A continuación, asocia la política de seguridad jerárquica a una organización, una carpeta o un proyecto, que puede ser el mismo recurso que posee la política. Después de asociar una política de seguridad jerárquica a un recurso, se aplican las reglas de la política de seguridad a los recursos protegidos en ese nodo y en los nodos inferiores de la jerarquía de recursos. Para ayudarte a decidir a qué recurso adjuntar tus políticas de seguridad jerárquicas, consulta la siguiente lista de casos prácticos básicos para cada recurso:
- Organización: considera las políticas de seguridad jerárquicas a nivel de organización como el tipo predeterminado de política de seguridad jerárquica.
Estas políticas tienen permisos de gestión de identidades y accesos (IAM) amplios y se aplican a todos los nodos de la organización. Para especificar estos recursos, usa la marca
--organizationdurante la asociación. - Carpeta: usa estas políticas de seguridad jerárquicas cuando quieras aplicar las mismas reglas de política de seguridad en varios proyectos, pero no en toda tu organización. Para especificar estos recursos, usa la marca
--folderdurante la asociación. - Proyecto: usa este tipo de política de seguridad jerárquica cuando necesites aplicar las mismas reglas de política de seguridad a todos los recursos de un proyecto, como aplicar una lista de denegación de direcciones IP a varios servicios de backend.
Para especificar estos recursos, usa la marca
--projectdurante la asociación. - A nivel de servicio: usa políticas de seguridad a nivel de servicio cuando necesites reglas de política de seguridad únicas que difieran entre cada uno de tus servicios. Cada política de seguridad a nivel de servicio solo aplica sus reglas a la política de backend a la que está asociada. Especifica estos recursos con la marca
--project-number.
Solo puedes usar una de estas marcas por política de seguridad jerárquica. Especifica el resto de las marcas, como --name o --type, igual que cuando configuras una política de seguridad a nivel de servicio. Consulta la siguiente lista para obtener más información sobre cómo funcionan las políticas de seguridad jerárquicas:
- Cuando se asocia una política de seguridad jerárquica a un nodo de la jerarquía de recursos, todos los recursos protegidos que se encuentren por debajo de ese nodo en la jerarquía heredan la política.
- Puede ver las políticas de seguridad que se aplican a cada recurso protegido de un proyecto, en todas las políticas de seguridad jerárquicas y las políticas de seguridad a nivel de servicio. Para obtener más información, consulta Ver todas las reglas de Cloud Armor efectivas de un recurso protegido.
- Puedes mover políticas de seguridad jerárquicas de un nodo de jerarquía de recursos a otro. Puedes hacerlo cuando tengas previsto reorganizar la estructura de tus carpetas.
- Cuando eliminas un nodo de la jerarquía de recursos, como una carpeta o un proyecto, la política de seguridad jerárquica asociada a ese nodo solo se elimina si la creaste en ese nodo de la jerarquía de recursos.
- Si has creado la política de seguridad en otro lugar y, después, la has movido al nodo, no se eliminará.
- Para evitar que se eliminen por error tus políticas de seguridad jerárquicas, te recomendamos que transfieras a otro nodo de la jerarquía de recursos las políticas de seguridad jerárquicas que quieras conservar antes de eliminar el nodo actual.
Orden de evaluación de reglas
Cloud Armor evalúa las políticas de seguridad en el siguiente orden:
- Políticas de seguridad jerárquicas a nivel de organización
- Políticas de seguridad jerárquicas a nivel de carpeta (empezando por la carpeta principal y, a continuación, por cada subcarpeta)
- Políticas de seguridad jerárquicas a nivel de proyecto
- Políticas de seguridad a nivel de servicio
Este orden de evaluación de las reglas significa que puede tener una política de seguridad jerárquica con una prioridad baja que se evalúa antes que una política de seguridad a nivel de servicio con una prioridad alta. Piensa detenidamente en las reglas de política de seguridad de nivel de servicio de alta prioridad que ya tengas y considera qué ocurre si Cloud Armor no evalúa una solicitud que una política de seguridad jerárquica permite o deniega.
La acción goto_next
Cloud Armor tiene una acción de regla exclusiva de las políticas de seguridad jerárquicas: la acción goto_next. Cuando Cloud Armor aplica esta acción, deja de evaluar las reglas de la política de seguridad actual y empieza a evaluar las reglas de la siguiente política de seguridad.
Imagina que tienes una política de seguridad jerárquica a nivel de organización con muchas reglas que quieres usar para restringir las solicitudes en toda tu organización. Quieres permitir que las solicitudes que procedan de un determinado intervalo de direcciones IP omitan la evaluación de estas reglas de toda la organización. Por lo tanto, crea una regla de prioridad máxima que coincida con ese intervalo de direcciones IP y que tenga la acción goto_next. Las solicitudes de ese intervalo de direcciones IP se evalúan primero con esta regla y, como cumplen la condición de coincidencia, no se evalúan con ninguna otra regla de esta política de seguridad jerárquica a nivel de organización.
En el mismo ejemplo, si usara una acción allow o deny en lugar de la acción goto_next, la solicitud se permitiría o se denegaría en cuanto se cumpliera la condición de coincidencia. Esta evaluación jerárquica significa que no se evalúan políticas de seguridad adicionales en relación con esa solicitud.
Comportamiento de la facturación y el registro de Google Cloud Armor Enterprise
Cuando adjuntas una política de seguridad jerárquica, cada uno de los proyectos que hereda la política de seguridad jerárquica debe estar registrado en Cloud Armor Enterprise. Esto incluye todos los proyectos de una organización o una carpeta con una política de seguridad jerárquica que no se hayan excluido explícitamente, así como todos los proyectos con una política de seguridad jerárquica adjunta directamente al proyecto.
- Los proyectos vinculados a una cuenta de facturación de Cloud con una suscripción a Cloud Armor Enterprise Annual se registran automáticamente en Cloud Armor Enterprise Annual si aún no lo están.
- Si no tienes una suscripción a Cloud Armor Enterprise Annual, los proyectos se registran automáticamente en Cloud Armor Enterprise Paygo cuando heredan una política de seguridad jerárquica. Si suscribes la cuenta de facturación a Cloud Armor Enterprise Annual después de que tu proyecto se haya registrado automáticamente en Cloud Armor Enterprise Paygo, el proyecto no se registrará automáticamente en Annual. Para obtener más información sobre Cloud Armor Enterprise Paygo, consulta Cloud Armor Standard y Cloud Armor Enterprise.
- Si actualizas una política de seguridad jerárquica para excluir un proyecto después de que se haya registrado automáticamente en Cloud Armor Enterprise, el proyecto no se dará de baja automáticamente. Para dar de baja manualmente tu proyecto, consulta el artículo Quitar un proyecto de Cloud Armor Enterprise.
- No puedes quitar un proyecto de Cloud Armor Enterprise mientras tenga políticas de seguridad jerárquicas heredadas.
La inscripción automática puede tardar hasta una semana en completarse. Durante este periodo, tus políticas de seguridad jerárquicas estarán activas y no se te cobrará por Cloud Armor Enterprise. Cuando tu proyecto esté registrado, los registros de auditoría se actualizarán para reflejar el estado de Cloud Armor Enterprise del proyecto y verás el nuevo nivel del proyecto en la Trusted Cloud consola.
Limitaciones
Las políticas de seguridad jerárquicas tienen las siguientes limitaciones:
- Las políticas de seguridad jerárquicas no están disponibles en proyectos que no pertenezcan a una organización.
- En el caso de los proyectos nuevos o restaurados recientemente, las políticas de seguridad heredadas pueden tardar unas horas en propagarse.
- En un proyecto en el que se haya habilitado recientemente la API Compute Engine, las políticas de seguridad heredadas pueden tardar unas horas en propagarse.
- Puedes ajustar las reglas de WAF preconfiguradas en las políticas de seguridad jerárquicas que te pertenezcan, pero los propietarios de los servicios que hereden una política de seguridad jerárquica no podrán hacerlo.