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 la organización, la carpeta o el proyecto. Estas difieren de las políticas de seguridad a nivel del servicio, que se adjuntan directamente a los servicios de backend o a los 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 seguridad centralizada y coherente 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 del servicio. Antes de continuar, lee la descripción general de la política de seguridad para asegurarte de comprender cómo funcionan las políticas de seguridad. Además, te recomendamos que te familiarices con la jerarquía de recursos.
Casos de uso
En las organizaciones grandes, administrar 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 abordar estos desafíos:
- Control centralizado: Proporciona a los administradores a nivel de la organización y de la carpeta 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 y mitigaciones de seguridad, 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: Permite delegar 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 satisfacer 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 la carpeta.
- Mitigación de CVE: Puedes implementar rápidamente reglas de WAF para mitigar vulnerabilidades críticas en varios proyectos.
- Aplicación del cumplimiento: Puedes aplicar el cumplimiento de los requisitos reglamentarios aplicando políticas de seguridad coherentes en toda tu organización.
- Control de acceso detallado: Puedes otorgar acceso a rangos de direcciones IP o regiones geográficas específicos a todos los recursos dentro de una carpeta específica.
Funciones
Las políticas de seguridad jerárquicas admiten un subconjunto de las funciones que admiten las políticas de seguridad a nivel del servicio. En la siguiente tabla, se comparan las funciones de Google 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 origen | ||
| Ubicación geográfica de origen | ||
| ASN de origen | ||
| Administración de bots | (solo EXTERNAL_302 y decoración de solicitudes) |
|
| Filtrado de capa 7 | ||
| WAF | ||
| 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, la creas 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.
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 que el recurso propietario de 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 por 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 tu 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 del servicio: Usa políticas de seguridad a nivel del 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 del 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, de la misma manera que 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 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 del servicio. Para obtener más información, consulta Cómo ver todas las reglas efectivas de Google Cloud Armor para un recurso protegido.
- Puedes mover 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 al nodo, no se borrará.
- Para evitar el borrado 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
Google 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 principal y, luego, continuando con 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 es posible que tengas una política de seguridad jerárquica con una prioridad baja que se evalúe antes que una política de seguridad a nivel del servicio con una prioridad alta. Piensa con cuidado en las reglas de políticas de seguridad existentes de alta prioridad a nivel del servicio y considera qué sucede si Google Cloud Armor no evalúa una solicitud que una política de seguridad jerárquica permite o rechaza en función de ellas.
La acción goto_next
Google 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 Google 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 en 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 deseas usar para restringir las solicitudes en toda tu organización. Deseas permitir que las solicitudes que provienen de un determinado rango de direcciones IP omitan la evaluación de estas reglas a nivel de 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 según esta regla y, como cumplen con la condición de coincidencia, no se evalúan según ninguna otra regla de esta política de seguridad jerárquica a nivel de la organización.
En el mismo ejemplo, si usaras una acción allow o deny en lugar de la acción goto_next, la solicitud se permitiría o rechazarí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 inscripción y la facturación de Google Cloud Armor Enterprise
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 vinculados a una cuenta de facturación de Cloud con una suscripción anual a Cloud Armor Enterprise 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 Paygo, el proyecto no se inscribirá automáticamente en la opción anual. Para obtener más información sobre Cloud Armor Enterprise con pago por uso, consulta Comparación entre Google 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 inscrito automáticamente en Cloud Armor Enterprise, el proyecto no se anulará automáticamente. Para anular la inscripción de tu proyecto de forma manual, consulta Cómo quitar un proyecto de Cloud Armor Enterprise.
- No puedes quitar un proyecto de Cloud Armor Enterprise si tiene políticas de seguridad jerárquicas heredadas.
La inscripción automática puede tardar hasta una semana en completarse. Durante este período, tus políticas de seguridad jerárquicas son efectivas y no se incurre en costos de Cloud Armor Enterprise. Cuando tu proyecto se inscribe, los registros de auditoría se actualizan para reflejar el estado de Cloud Armor Enterprise del proyecto, y verás el nuevo nivel del proyecto en la consola de Google Cloud .
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 pertenecen a una organización.
- En el caso de los proyectos nuevos o restablecidos recientemente, es posible que las políticas de seguridad heredadas del proyecto tarden algunas horas en propagarse.
- En el caso de un proyecto en el que se habilitó recientemente la API de Compute Engine, es posible que tarden algunas horas en propagarse las políticas de seguridad heredadas en este proyecto.
- 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.