Te recomendamos que definas restricciones de políticas que apliquen configuraciones de recursos aceptables y eviten configuraciones de riesgo. 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 la creación de recursos que no cumplan las directrices de tu política. Si aplicas estos controles en las primeras fases del diseño y la creación de tus cargas de trabajo, podrás evitar tener que hacer correcciones más adelante.
Restricciones de las políticas de organización
El servicio Política de organización aplica restricciones para asegurarse de que no se puedan crear determinadas configuraciones de recursos en tu Google Cloud organización, ni siquiera por alguien con un rol de gestión de identidades y accesos con suficientes privilegios.
El plano técnico aplica las políticas en el nodo de organización para que todos los controles se hereden en todas las carpetas y proyectos de la organización. Este paquete de políticas se ha diseñado para evitar determinadas configuraciones de alto riesgo, como exponer una máquina virtual a la red pública de Internet o conceder acceso público a los segmentos de almacenamiento, a menos que permitas deliberadamente una excepción a la política.
En la siguiente tabla se presentan las restricciones de las políticas de organización que se implementan en el plano:
| Restricción de política de organización | Descripción |
|---|---|
| La virtualización anidada en las VMs de Compute Engine puede eludir la monitorización y otras herramientas de seguridad de tus VMs si no se configura correctamente. Esta restricción impide la creación de virtualización anidada. |
| Los roles de IAM, como |
| Las subredes IPv6 externas pueden estar expuestas a accesos no autorizados a Internet si no están bien configuradas. Esta restricción impide la creación de subredes IPv6 externas. |
| El comportamiento predeterminado de las claves SSH en los metadatos puede permitir el acceso remoto no autorizado a las VMs si las claves están expuestas. Esta restricción obliga a usar OS Login en lugar de claves SSH basadas en metadatos. |
|
La 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 solo permite el reenvío de protocolos de máquinas virtuales para direcciones internas. |
|
Eliminar un proyecto host de VPC compartida puede afectar a todos los proyectos de servicio que utilicen recursos de red. Esta restricción evita que se eliminen de forma accidental o malintencionada los proyectos host de la VPC compartida, ya que impide que se retire la retención del proyecto de estos proyectos. |
|
No se recomienda usar la configuración antigua de DNS interno global (de todo el proyecto) porque reduce la disponibilidad del servicio. Esta restricción impide el uso del ajuste antiguo. |
| En cada proyecto nuevo que habilita la API Compute Engine, se crea una red de VPC predeterminada y reglas de cortafuegos de VPC predeterminadas demasiado permisivas. Esta restricción se salta la creación de la red predeterminada y las reglas de cortafuegos de VPC predeterminadas. |
| De forma predeterminada, se crea una VM con una dirección IPv4 externa que puede provocar un acceso no autorizado a Internet. Esta restricción configura una lista de elementos permitidos vacía de direcciones IP externas que la VM puede usar y deniega todas las demás. |
|
De forma predeterminada, Contactos esenciales se puede configurar para enviar notificaciones sobre tu dominio a cualquier otro dominio. Esta restricción obliga a que solo se puedan definir como destinatarios de Contactos esenciales las direcciones de correo de dominios aprobados. |
| De forma predeterminada, las políticas de permiso se pueden conceder a cualquier cuenta de Google, incluidas las cuentas no gestionadas y las cuentas que pertenecen a organizaciones externas. Esta restricción asegura que las políticas de permiso de tu organización solo se puedan conceder a cuentas gestionadas de tu propio dominio. Si quieres, puedes permitir dominios adicionales. |
|
De forma predeterminada, las cuentas de servicio predeterminadas reciben automáticamente roles demasiado permisivos. Esta restricción impide que se concedan automáticamente roles de gestión de identidades y accesos a las cuentas de servicio predeterminadas. |
|
Las claves de cuenta de servicio son credenciales persistentes 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 impide la creación de claves de cuentas de servicio. |
|
Subir material de clave de cuenta de servicio puede aumentar el riesgo si se expone el material de clave. Esta restricción impide que se suban claves de cuentas de servicio. |
|
Las instancias de Cloud SQL pueden estar expuestas a un acceso a Internet sin autenticación si están configuradas para usar redes autorizadas sin un proxy de autenticación de Cloud SQL. Esta política impide la configuración de redes autorizadas para acceder a la base de datos y obliga a usar el proxy de autenticación de Cloud SQL. |
| Las instancias de Cloud SQL pueden estar expuestas a un acceso a Internet no autenticado si se crean con direcciones IP públicas. Esta restricción impide que se usen direcciones IP públicas en instancias de Cloud SQL. |
| De forma predeterminada, se puede acceder a los objetos de Cloud Storage mediante las listas de control de acceso (LCAs) antiguas en lugar de IAM, lo que puede provocar que los controles de acceso sean incoherentes y que se expongan datos accidentalmente si se configuran de forma incorrecta. El acceso a las LCA antiguas no se ve afectado por la restricción |
|
Los segmentos de Cloud Storage pueden exponerse a un acceso a Internet no autenticado si están mal configurados. Esta restricción impide que las listas de control de acceso y los permisos de gestión de identidades y accesos concedan acceso a |
Estas políticas son un punto de partida que recomendamos a la mayoría de los clientes y en la mayoría de los casos, pero es posible que tengas que modificar las restricciones de las políticas de la organización para adaptarlas a determinados tipos de cargas de trabajo. Por ejemplo, storage.publicAccessPrevention bloquea una carga de trabajo que usa un segmento de Cloud Storage como backend de Cloud CDN para alojar recursos públicos, y iam.allowedPolicyMemberDomains bloquea una aplicación de Cloud Run pública que no requiere autenticación. En estos casos, modifique la política de organización a nivel de carpeta o proyecto para permitir una excepción específica.
También puedes añadir restricciones condicionalmente a una política de organización
definiendo una etiqueta que conceda una excepción o una implementación obligatoria para la política y, a continuación, aplicando la etiqueta a proyectos y carpetas.
Para ver otras restricciones, 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 gestionar la infraestructura, lo que significa que todos los cambios en la infraestructura se implementan mediante la infraestructura como código (IaC) controlada por versiones y se pueden validar antes de implementarse.
Las políticas aplicadas en el plano definen las configuraciones de recursos aceptables que puede desplegar tu canalización. Si el código que se envía a tu repositorio de GitHub no supera las comprobaciones de la política, no se desplegará ningún recurso.
Para obtener información sobre cómo se usan las canalizaciones y cómo se aplican los controles mediante la automatización de CI/CD, consulta la metodología de implementación.
Siguientes pasos
- Consulta información sobre la metodología de implementación (el siguiente documento de esta serie).