Te recomendamos que definas las restricciones de políticas que aplican opciones de configuración de recursos aceptables y evitan las configuraciones riesgosas. El modelo 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 evitan la creación de recursos que no cumplan con los lineamientos de tus políticas. 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 modelo aplica políticas en el nodo de organización para que todas las carpetas y proyectos 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 la política de la organización que se implementan en el modelo:
Restricción de las políticas de la organización | Descripción |
---|---|
| La virtualización anidada en las VMs de Compute Engine puede evadir la supervisión y otras herramientas de seguridad para las VMs si están mal configuradas. Esta restricción evita la creación de virtualización anidada. |
| Los roles de IAM como |
| Las subredes IPv6 externas pueden estar expuestas a un acceso no autorizado a Internet 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 VMs, 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 generar una salida no autorizada a Internet si el reenvío está mal configurado. Esta restricción permite el reenvío de protocolos de VM solo para direcciones internas. |
|
Si borras un proyecto host de VPC compartida, es posible que se produzcan interrupciones en todos los proyectos de servicio que usan recursos de red. 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 del proyecto en estos proyectos. |
|
No se recomienda usar 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 generar acceso no autorizado a Internet. 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, los Contactos esenciales se pueden configurar para enviar notificaciones sobre tu dominio a cualquier otro dominio. Esta restricción aplica que solo se pueden configurar como destinatarios de Contactos esenciales las direcciones de correo electrónico de los dominios aprobados. |
| De forma predeterminada, se pueden otorgar políticas de permiso a cualquier Cuenta de Google, incluidas las cuentas no administradas y las que pertenecen a organizaciones externas. Esta restricción garantiza que las políticas de autorización de tu organización solo se puedan otorgar a las cuentas administradas de tu propio dominio. De forma 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 que las claves de cuenta de servicio. Esta restricción impide la creación de claves de cuenta de servicio. |
|
Subir material de claves de cuenta de servicio puede aumentar el riesgo si se expone. Esta restricción evita la carga de 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 la LCA heredada 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 las LCA y los permisos de IAM 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
adaptarlas 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 la carpeta o el proyecto para permitir una excepción limitada.
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 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 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 modelo definen las configuraciones de recursos aceptables que puede implementar tu canalización. Si el código que se envía a tu repositorio de GitHub no supera las verificaciones de políticas, no se implementarán recursos.
Si deseas 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)