Las políticas de seguridad jerárquicas son una categoría de políticas de seguridad que extienden el alcance del firewall de aplicación web (WAF) y la protección DSD de Google Cloud Armor más allá de los proyectos individuales. Se adjuntan a nivel de organización, carpeta o proyecto. Estas difieren de las políticas de seguridad a nivel de servicio, que se adjuntan directamente a los servicios de backend o buckets de backend.
Cuando configuras una política de seguridad jerárquica a nivel de la organización o la carpeta, los proyectos en niveles inferiores de la jerarquía heredan esa política de seguridad. Esta herencia te permite configurar las reglas de política de seguridad que quieres aplicar a todos o varios proyectos de tu organización. Esto permite la aplicación de medidas de seguridad centralizadas y coherentes en todo tu entorno de Google Cloud .
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 la descripción general de las políticas de seguridad para asegurarte de que comprendes cómo funcionan. Además, te recomendamos que te familiarices con la jerarquía de recursos.
Casos de uso
En organizaciones grandes, administrar las políticas de seguridad en varios proyectos puede ser complejo y llevar mucho tiempo. Las políticas de seguridad jerárquicas ofrecen las siguientes ventajas para ayudarte a abordar estos desafíos:
- Control centralizado: Proporciona a los administradores de la organización y de las carpetas la capacidad 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 errores de configuración y brechas de seguridad.
- Eficiencia: Optimiza la implementación de actualizaciones de seguridad y mitigaciones, como el bloqueo de rangos de direcciones IP específicos o la solución de vulnerabilidades críticas, en una gran cantidad de recursos de forma simultánea.
- Delegación: Habilita la delegación de responsabilidades de seguridad a diferentes equipos o departamentos aplicando políticas en los niveles adecuados de la jerarquía.
Puedes aplicar y combinar estos principios generales para que se adapten a las necesidades de tu organización. Considera los siguientes casos de uso de ejemplo:
- Bloqueo de direcciones IP en toda la organización: puedes bloquear el tráfico de rangos de direcciones IP maliciosas conocidas en todos los proyectos de tu organización.
- Restricciones basadas en la ubicación geográfica: Puedes restringir el tráfico de regiones geográficas específicas a nivel de la organización o de la carpeta.
- Mitigación de CVE: Puedes implementar con rapidez reglas de WAF para mitigar vulnerabilidades críticas en varios proyectos.
- Aplicación de medidas por incumplimiento: Puedes aplicar el cumplimiento de los requisitos reglamentarios con políticas de seguridad coherentes en toda tu organización.
- Control de acceso detallado: Puedes otorgar acceso a todos los recursos de una carpeta específica a rangos de direcciones IP o regiones geográficas específicos.
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 las políticas de seguridad jerárquicas y las políticas de seguridad a nivel del servicio:
| Tipo de frontend |
|
|
| Punto de unión (recurso protegido) | Servicio de backend | Nodos de la jerarquía de recursos |
| Acciones de la regla |
|
|
| Dirección IP de cliente | ||
| Ubicación geográfica del cliente | ||
| ASN del cliente | ||
| Límite de frecuencia | ||
| Huellas digitales de TLS (JA3 y JA4) | ||
| Administración de bots | (solo
EXTERNAL_302 y decoración de solicitudes) |
|
| Filtrado de HTTP | ||
| Filtrado de cuerpos | ||
| WAF | ||
| Reglas administradas | ||
| Google Threat Intelligence | ||
| reCAPTCHA | ||
| Protección adaptable | ||
| Grupos de direcciones | ||
| Grupos de direcciones a nivel de la 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 la organización o la 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.
Luego, asocia la política de seguridad jerárquica con una organización, carpeta o proyecto, que puede ser el mismo que el recurso propietario de la política. Después de asociar una política de seguridad jerárquica con un recurso, se aplican las reglas de la política de seguridad a los recursos protegidos en ese nodo y debajo de él en 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 de uso básicos para cada recurso:
- Organización: Considera las políticas de seguridad jerárquicas a nivel de la organización como el tipo predeterminado de política de seguridad jerárquica.
Estas políticas tienen permisos amplios de Identity and Access Management (IAM)
y se aplican a todos los nodos de la organización. Especifica
estos recursos con 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
la organización. Especifica estos recursos con 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 en todos los recursos de un
proyecto, como aplicar una lista de bloqueo de direcciones IP en varios servicios de backend.
Especifica estos recursos con 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á adjunta. Especifica estos recursos con la marca
--project-number.
Solo puedes usar una de estas marcas por política de seguridad jerárquica. Especificas
el resto de las marcas, como --name o --type, tal como lo haces cuando
configuras una política de seguridad a nivel del servicio. Consulta la siguiente lista para obtener más
información sobre cómo funcionan las políticas de seguridad jerárquicas:
- Cuando una política de seguridad jerárquica se asocia con un nodo de la jerarquía de recursos, todos los recursos protegidos que se encuentran por debajo de ese nodo en la jerarquía heredan la política.
- Puedes ver las políticas de seguridad que se aplican a cada recurso protegido en 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 Visualiza todas las reglas de Cloud Armor vigentes para un recurso protegido.
- Puedes mover las políticas de seguridad jerárquicas de un nodo de jerarquía de recursos a otro. Puedes hacerlo cuando planees reorganizar la estructura de tus carpetas.
- Cuando borras un nodo de la jerarquía de recursos, como una carpeta o un proyecto, la
política de seguridad jerárquica adjunta a ese nodo solo se borra si la
creaste en ese nodo de la jerarquía de recursos.
- Si creaste la política de seguridad en otro lugar y, luego, la moviste debajo del nodo, no se borra.
- Para evitar la eliminación accidental de tus políticas de seguridad jerárquicas, te recomendamos que muevas las políticas de seguridad jerárquicas que quieras conservar a otro nodo de la jerarquía de recursos antes de borrar el nodo existente.
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 la organización
- Políticas de seguridad jerárquicas a nivel de carpeta (comenzando con la carpeta superior y, luego, procediendo a cada subcarpeta)
- Políticas de seguridad jerárquicas a nivel del proyecto
- Políticas de seguridad a nivel del servicio
Este orden de evaluación de reglas significa que puedes 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 con cuidado en las reglas de la política de seguridad de nivel de servicio de alta prioridad existentes y considera qué sucede si Cloud Armor no evalúa una solicitud que una política de seguridad jerárquica permite o rechaza.
La acción goto_next
Cloud Armor tiene una acción de regla que es 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 dentro de la política de seguridad actual y
comienza a evaluar las reglas de la siguiente política de seguridad.
Considera un ejemplo en el que tienes una
política de seguridad jerárquica a nivel de la organización con muchas reglas que quieres
usar para restringir las solicitudes en toda tu organización. Deseas permitir
que las solicitudes que provienen de un rango de direcciones IP determinado omitan la evaluación de estas
reglas para toda la organización. Por lo tanto, creas una regla de prioridad máxima que coincida
con ese rango de direcciones IP con la acción goto_next. Las solicitudes de ese rango de direcciones IP
se evalúan primero en función de esta regla y, como cumplen con la
condición de coincidencia, no se evalúan en función de ninguna otra regla de esta
política de seguridad jerárquica a nivel de la organización.
En el mismo ejemplo, si usaste una acción allow o deny en lugar de la
acción goto_next, la solicitud se permite o se rechaza en cuanto se cumple 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.
Inscripción en Google Cloud Armor Enterprise y comportamiento de la facturación
Cuando adjuntas una política de seguridad jerárquica, cada uno de los proyectos que heredan la política de seguridad jerárquica debe estar inscrito en Cloud Armor Enterprise. Esto incluye todos los proyectos de una organización o carpeta con una política de seguridad jerárquica que no se excluyen de forma explícita y todos los proyectos con una política de seguridad jerárquica adjunta directamente al proyecto.
- Los proyectos que están vinculados a una cuenta de Facturación de Cloud con una suscripción a Cloud Armor Enterprise anual se inscriben automáticamente en Cloud Armor Enterprise anual si aún no están inscritos.
- Sin una suscripción anual a Cloud Armor Enterprise, los proyectos se inscriben automáticamente en Cloud Armor Enterprise con pago por uso cuando heredan una política de seguridad jerárquica. Si suscribes la cuenta de facturación a Cloud Armor Enterprise anual después de que tu proyecto se inscribió automáticamente en Cloud Armor Enterprise de pago por uso, el proyecto no se inscribirá automáticamente en el plan anual. Para obtener más información sobre Cloud Armor Enterprise con pago por uso, consulta Cloud Armor Standard en comparación con Cloud Armor Enterprise.
- Si actualizas una política de seguridad jerárquica para excluir un proyecto después de que se haya inscrito automáticamente en Cloud Armor Enterprise, el proyecto no se dará de baja de forma automática. Para dar de baja tu proyecto de forma manual, consulta Quita 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 el siguiente día hábil en completarse. Durante este período, tus políticas de seguridad jerárquicas son efectivas y no se generan costos de Cloud Armor Enterprise. Cuando se inscribe tu proyecto, se actualizan los registros de auditoría para reflejar el estado de Cloud Armor Enterprise del proyecto. También verás el nuevo nivel del proyecto en la consola deGoogle Cloud .
Los proyectos se inscriben de forma automática solo cuando al menos un servicio de backend para balanceadores de cargas externos globales usa HTTP, HTTPS, HTTP2, H2C o GRPC.
Limitaciones
Las políticas de seguridad jerárquicas tienen las siguientes limitaciones:
- Las políticas de seguridad jerárquicas no están disponibles para los proyectos que no están dentro de una organización.
- En el caso de los proyectos nuevos o restablecidos recientemente, las políticas de seguridad heredadas pueden tardar algunas horas en propagarse.
- En el caso de un proyecto que habilitó recientemente la API de Compute Engine, es posible que las políticas de seguridad heredadas en este proyecto tarden unas horas en propagarse.
- Puedes ajustar las reglas de WAF preconfiguradas en las políticas de seguridad jerárquicas que te pertenecen, pero los propietarios de los servicios que heredan una política de seguridad jerárquica no pueden realizar ajustes de reglas.