Te recomendamos que definas las restricciones de políticas que aplican opciones de configuración de recursos aceptables y evitan las configuraciones riesgosas. El plano usa una combinación de restricciones de políticas de la organización y validación de infraestructura como código (IaC) en tu canalización. Estos controles impiden crear recursos que no cumplan con los lineamientos de tu política. Aplicar estos controles al comienzo del diseño y la compilación de tus cargas de trabajo te ayuda a evitar el trabajo de corrección más adelante.
Restricciones de las políticas de la organización
El servicio de políticas de la organización aplica restricciones para garantizar que ciertas opciones de configuración de recursos no se puedan crear en tu organización de Google Cloud, incluso por alguien que tenga un rol de IAM con privilegios suficientes.
El plano aplica políticas en el nodo de la organización para que todas las carpetas y los proyectos dentro de la organización hereden estos controles. Este conjunto de políticas está diseñado para evitar ciertas configuraciones de alto riesgo, como exponer una VM a la Internet pública u otorgar acceso público a los buckets de almacenamiento, a menos que permitas una excepción a la política de forma deliberada.
En la siguiente tabla, se presentan las restricciones de las políticas de la organización que se implementan en el plano:
| Restricción de las políticas de la organización | Descripción |
|---|---|
| La virtualización anidada en las VM de Compute Engine puede evadir la supervisión y otras herramientas de seguridad para las VM si están mal configuradas. Esta restricción evita la creación de la virtualización anidada. |
| Los roles de IAM como |
| Las subredes IPv6 externas se pueden exponer al acceso a Internet no autorizado si están mal configuradas. Esta restricción evita la creación de subredes IPv6 externas. |
| El comportamiento predeterminado de la configuración de claves SSH en metadatos puede permitir el acceso remoto no autorizado a las VM, si se exponen claves. Esta restricción aplica el uso del Acceso al SO en lugar de las claves SSH basadas en metadatos. |
|
El reenvío de protocolos de VM para direcciones IP externas puede provocar una salida de Internet no autorizada si el reenvío está mal configurado. Esta restricción permite el reenvío de protocolos de VM solo para direcciones internas. |
|
Borrar un proyecto host de VPC compartida puede ser perjudicial para todos los proyectos de servicio que usan recursos de herramientas de redes. Esta restricción evita la eliminación accidental o maliciosa de los proyectos host de VPC compartida, ya que impide la eliminación de la retención de proyecto en estos proyectos. |
|
No se recomienda una configuración heredada para el DNS interno global (para todo el proyecto), ya que reduce la disponibilidad del servicio. Esta restricción evita el uso de la configuración heredada. |
| En cada proyecto nuevo que habilite la API de Compute Engine, se crean una red de VPC predeterminada y reglas de firewall de VPC predeterminadas demasiado permisivas. Esta restricción omite la creación de la red predeterminada y las reglas de firewall de VPC predeterminadas. |
| De forma predeterminada, se crea una VM con una dirección IPv4 externa que puede provocar el acceso a Internet no autorizado. Esta restricción configura una lista de entidades permitidas vacía de direcciones IP externas que la VM puede usar y rechaza todas las demás. |
|
De forma predeterminada, se pueden configurar los contactos esenciales para que envíen notificaciones sobre tu dominio a cualquier otro dominio. Esta restricción exige que solo las direcciones de correo electrónico de los dominios aprobados se puedan configurar como destinatarios para los contactos esenciales. |
| De forma predeterminada, se pueden otorgar políticas de permisos a cualquier Cuenta de Google, incluidas las cuentas no administradas y las cuentas que pertenecen a organizaciones externas. Esta restricción garantiza que las políticas de permisos en tu organización solo se puedan otorgar a cuentas administradas de tu propio dominio. De manera opcional, puedes permitir dominios adicionales. |
|
De forma predeterminada, a las cuentas de servicio predeterminadas se les otorgan roles demasiado permisivos de forma automática. Esta restricción evita que los roles de IAM automáticos se otorguen a las cuentas de servicio predeterminadas. |
|
Las claves de cuenta de servicio son una credencial persistente de alto riesgo y, en la mayoría de los casos, se puede usar una alternativa más segura a las claves de cuenta de servicio. Esta restricción evita que se creen claves de cuenta de servicio. |
|
Subir el material de la clave de la cuenta de servicio puede aumentar el riesgo si se expone el material de la clave. Esta restricción evita que se suban claves de cuenta de servicio. |
|
Las instancias de Cloud SQL pueden exponerse al acceso a Internet no autenticado si las instancias están configuradas para usar redes autorizadas sin un proxy de autenticación de Cloud SQL. Esta política evita la configuración de redes autorizadas para el acceso a la base de datos y fuerza el uso del proxy de autenticación de Cloud SQL. |
| Las instancias de Cloud SQL pueden exponerse al acceso a Internet no autenticado si las instancias se crean con direcciones IP públicas. Esta restricción evita las direcciones IP públicas en las instancias de Cloud SQL. |
| De forma predeterminada, se puede acceder a los objetos en Cloud Storage a través de las Listas de control de acceso (LCA) heredadas, en lugar de IAM, lo que puede provocar controles de acceso incoherentes y una exposición accidental si se configura de forma incorrecta. El acceso a las LCA heredadas no se ve afectado por la restricción |
|
Los buckets de Cloud Storage pueden estar expuestos al acceso a Internet no autenticado si están mal configurados. Esta restricción evita los permisos de IAM y LCA que otorgan acceso a |
Estas políticas son un punto de partida que recomendamos para la mayoría de los clientes y la mayoría de las situaciones, pero es posible que debas modificar las restricciones de las políticas de la organización para adaptarse a ciertos tipos de cargas de trabajo. Por ejemplo, storage.publicAccessPrevention bloquea una carga de trabajo que usa un bucket de Cloud Storage como backend para Cloud CDN a fin de alojar recursos públicos, o iam.allowedPolicyMemberDomains bloquea una app de Cloud Run pública que no requiere autenticación. En estos casos, modifica la política de la organización a nivel de carpeta o de proyecto para permitir una excepción estrecha.
También puedes agregar restricciones de forma condicional a la política de la organización si defines una etiqueta que otorgue una excepción o aplicación para la política y, luego, aplicas la etiqueta a proyectos y carpetas.
Para conocer las restricciones adicionales, consulta las restricciones disponibles y las restricciones personalizadas.
Validación previa a la implementación de la infraestructura como código
El plano usa un enfoque de GitOps para administrar la infraestructura, lo que significa que todos los cambios en la infraestructura se implementan a través de la infraestructura como código (IaC) con control de versión y se pueden validar antes de la implementación.
Las políticas aplicadas en el plano definen configuraciones de recursos aceptables que puede implementar tu canalización. Si el código que se envía a tu repositorio de GitHub no pasa las verificaciones de la política, no se implementarán recursos.
Para obtener información sobre cómo se usan las canalizaciones y cómo se aplican los controles a través de la automatización de CI/CD, consulta la metodología de implementación.
¿Qué sigue?
- Lee sobre la metodología de implementación (siguiente documento de esta serie)