Decidir una jerarquía de recursos para tu zona de aterrizaje de Google Cloud

Last reviewed 2024-10-31 UTC

Una jerarquía de recursos te ayuda a organizar tus recursos en Google Cloud. En este documento se describe cómo elegir la jerarquía de recursos como parte del diseño de tu zona de aterrizaje. Está dirigido a administradores de sistemas en la nube, arquitectos y profesionales técnicos que participan en el diseño de la jerarquía de recursos. Este documento forma parte de una serie sobre zonas de aterrizaje. Incluye jerarquías de ejemplo que muestran las formas habituales en las que las empresas pueden estructurar los recursos enGoogle Cloud.

Factores de diseño de la jerarquía de recursos

Cuando definas tu jerarquía de recursos en Google Cloud, debes tener en cuenta cómo funciona tu organización actualmente y el estado final ideal de tu transformación en la nube. La mejor forma de gestionar los recursos se basa en la forma de trabajar en la nube que tenga tu organización. Como cada organización es diferente, no hay un único enfoque óptimo para la jerarquía de recursos.

Sin embargo, te recomendamos que no asignes la estructura de tu organización a la jerarquía de recursos. En su lugar, céntrate en las necesidades y las operaciones de tu empresa en Google Cloud.

Jerarquía de recursosGoogle Cloud

La jerarquía de recursos de Google Cloud empieza en el nodo raíz, que se denomina organización. Recomendamos que las empresas tengan un solo nodo raíz, excepto en situaciones específicas. Los niveles inferiores de la jerarquía se definen mediante carpetas y proyectos. Puedes crear carpetas dentro de otras carpetas para crear tu jerarquía. Puede crear los proyectos que alojan sus cargas de trabajo en cualquier nivel de la jerarquía.

En el siguiente diagrama se muestra un nodo raíz llamado Organización y carpetas en los niveles uno, dos y tres. Los proyectos y las subcarpetas se crean en las carpetas del segundo nivel.

Ejemplo de jerarquía con un nodo raíz, carpetas y proyectos.

Factores de la jerarquía de recursos

Cuando decidas la jerarquía de recursos, ten en cuenta los siguientes factores:

  • ¿Quién es responsable de los recursos en la nube? ¿Se trata de tus departamentos, filiales, equipos técnicos o entidades legales?
  • ¿Cuáles son tus necesidades de cumplimiento?
  • ¿Tienes eventos empresariales próximos, como fusiones, adquisiciones y escisiones?

Entender las interacciones de los recursos en toda la jerarquía

Las políticas de organización se heredan en los descendientes de la jerarquía de recursos, pero pueden sustituirse por políticas definidas en un nivel inferior. Para obtener más información, consulta Información sobre la evaluación de la jerarquía. Puedes usar restricciones de políticas de la organización para definir directrices en toda la organización o en partes importantes de ella, y seguir permitiendo excepciones.

Las políticas de permiso, antes conocidas como políticas de gestión de identidades y accesos, se heredan de los elementos superiores y las políticas de permiso de los niveles inferiores se suman. Sin embargo, las políticas de permiso se pueden sustituir por políticas de denegación, que te permiten restringir permisos a nivel de proyecto, carpeta y organización. Las políticas de denegación se aplican antes que las de permiso.

También debes tener en cuenta lo siguiente:

Puntos de decisión para diseñar la jerarquía de recursos

En el siguiente diagrama de flujo se muestran los aspectos que debes tener en cuenta para elegir la mejor jerarquía de recursos para tu organización.

Decisiones sobre las jerarquías de recursos.

En el diagrama anterior se describen los siguientes puntos de decisión:

  1. ¿Las distintas filiales, grupos regionales o unidades de negocio tienen requisitos de políticas muy diferentes?
    1. Si es así, sigue el diseño en función de la región o las filiales.
    2. Si no, ve al siguiente punto de decisión.

  2. ¿Tus equipos de cargas de trabajo o de productos necesitan tener mucha autonomía sobre sus políticas? Por ejemplo, no tienes un equipo de seguridad central que determine las políticas de todos los equipos de cargas de trabajo o productos.

    1. En caso afirmativo, consulta el diseño basado en el marco de rendición de cuentas.

    2. Si no es así, consulta el apartado Diseño basado en el entorno de la aplicación.

En tu caso concreto, puede que te convenga usar otra jerarquía de recursos diferente a la que se sugiere en el diagrama de decisiones. La mayoría de las organizaciones optan por un enfoque híbrido y seleccionan diferentes diseños en distintos niveles de la jerarquía de recursos, empezando por el diseño que más afecta a las políticas y al acceso.

Opción 1: Jerarquía basada en entornos de aplicaciones

En muchas organizaciones, se definen diferentes políticas y controles de acceso para distintos entornos de aplicaciones, como el de desarrollo, el de producción y el de pruebas. Tener políticas independientes y estandarizadas en cada entorno facilita la gestión y la configuración. Por ejemplo, puede que tengas políticas de seguridad más estrictas en los entornos de producción que en los de prueba.

Usa una jerarquía basada en entornos de aplicaciones si se cumple lo siguiente:

  • Tienes entornos de aplicaciones independientes con diferentes requisitos de políticas y administración.
  • Tienes requisitos de seguridad o auditoría centralizados que un equipo de seguridad central debe poder aplicar de forma coherente en todas las cargas de trabajo y los datos de producción.
  • Necesitas diferentes roles de gestión de identidades y accesos para acceder a tus Google Cloud recursos en distintos entornos.

Evita esta jerarquía si se cumple lo siguiente:

  • No ejecutas varios entornos de aplicaciones.
  • No tienes dependencias de aplicaciones ni procesos empresariales diferentes en los distintos entornos.
  • Tienes grandes diferencias en las políticas de distintas regiones, equipos o aplicaciones.

En el siguiente diagrama se muestra una jerarquía de example.com, que es una empresa ficticia de tecnología financiera.

Diagrama de la opción 1.

Como se muestra en el diagrama anterior, example.com tiene tres entornos de aplicación con diferentes políticas, controles de acceso, requisitos normativos y procesos. Los entornos son los siguientes:

  • Entorno de desarrollo y control de calidad: este entorno lo gestionan desarrolladores que son tanto empleados internos como consultores. Publican código continuamente y son responsables del control de calidad. Este entorno nunca está disponible para los consumidores de tu empresa. El entorno tiene requisitos de integración y autenticación menos estrictos que el entorno de producción, y a los desarrolladores se les asignan roles aprobados con permisos adecuados. El entorno de desarrollo y control de calidad está diseñado únicamente para las ofertas de aplicaciones estándar de example.com.

  • Entorno de pruebas: este entorno se usa para las pruebas de regresión y de aplicaciones, y admite las ofertas de empresa a empresa (B2B) de los clientes de example.com que usan las APIs de example.com. Para ello, example.com crea dos tipos de proyectos:

    • Proyectos de pruebas internas para completar la regresión interna, el rendimiento y la configuración de las ofertas B2B.
    • Proyectos de pruebas de aceptación de usuarios de clientes con asistencia multitenant para que los clientes B2B puedan validar sus configuraciones y cumplir los requisitos de example.com en cuanto a experiencia de usuario, marca, flujos de trabajo, informes, etc.

  • Entorno de producción: este entorno aloja todos los productos que se han validado, aceptado y lanzado. Este entorno está sujeto a las normativas de la normativa de seguridad de datos del sector de las tarjetas de pago (Payment Card Industry Data Security Standard, PCI DSS), utiliza módulos de seguridad de hardware (HSMs) y se integra con procesadores externos para elementos como la autenticación y las liquidaciones de pagos. Los equipos de auditoría y cumplimiento son partes interesadas fundamentales de este entorno. El acceso a este entorno está estrictamente controlado y se limita principalmente a los procesos de implementación automatizados.

Para obtener más información sobre cómo diseñar una jerarquía basada en entornos de aplicaciones, consulta Estructura organizativa en el plan técnico de las bases de la empresa.

Opción 2: Jerarquía basada en regiones o filiales

Algunas organizaciones operan en muchas regiones y tienen filiales que hacen negocios en diferentes zonas geográficas o son el resultado de fusiones y adquisiciones. Estas organizaciones necesitan una jerarquía de recursos que utilice las opciones de escalabilidad y gestión de Google Cloudy que mantenga la independencia de los diferentes procesos y políticas que existen entre las regiones o las filiales. En esta jerarquía, las filiales o las regiones son el nivel de carpeta más alto de la jerarquía de recursos. Los procedimientos de implementación suelen centrarse en las regiones.

Usa esta jerarquía si se cumple lo siguiente:

  • Las diferentes regiones o filiales operan de forma independiente.
  • Las regiones o las filiales tienen diferentes infraestructuras operativas, ofertas de plataformas digitales y procesos.
  • Tu empresa tiene diferentes estándares de cumplimiento y normativas para regiones o filiales.

En el siguiente diagrama se muestra un ejemplo de jerarquía de una organización global con dos filiales y un grupo de sociedades holding con una estructura regionalizada.

Diagrama de la opción 2.

El diagrama anterior tiene la siguiente estructura de jerarquía:

  • Las siguientes carpetas están en el primer nivel:
    • Las carpetas Subsidiary 1 y Subsidiary 2 representan las dos filiales de la empresa que tienen permisos de acceso y políticas diferentes al resto de la organización. Cada filial usa IAM para restringir el acceso a sus proyectos y recursos. Google Cloud
    • La carpeta Holding group representa los grupos que tienen políticas comunes de alto nivel en todas las regiones.
    • La carpeta Bootstrap representa los recursos comunes que se necesitan para desplegar tu infraestructura, tal como se describe en el Google Cloud blueprint de las bases de la empresa.
  • En el segundo nivel, dentro de la carpeta Grupo de retención, se encuentran las siguientes carpetas:
    • Las carpetas APAC, EMEA y Americas representan las distintas regiones del grupo que tienen diferentes políticas, permisos de acceso y normas.
    • La carpeta Shared infrastructure representa los recursos que se usan de forma global en todas las regiones.
  • Dentro de cada carpeta hay varios proyectos que contienen los recursos de los que son responsables estas filiales o regiones.

Puedes añadir más carpetas para separar las distintas entidades jurídicas, departamentos y equipos de tu empresa.

Opción 3: Jerarquía basada en un marco de rendición de cuentas

Una jerarquía basada en un marco de rendición de cuentas funciona mejor cuando tus productos se gestionan de forma independiente o cuando las unidades organizativas tienen equipos claramente definidos que se encargan del ciclo de vida de los productos. En estas organizaciones, los responsables de producto se encargan de todo el ciclo de vida del producto, incluidos sus procesos, asistencia, políticas, seguridad y derechos de acceso. Sus productos son independientes entre sí y no suelen aplicarse directrices ni controles a nivel de organización.

Usa esta jerarquía cuando se cumplan las siguientes condiciones:

  • Diriges una organización que tiene una propiedad y una responsabilidad claras para cada producto.
  • Tus cargas de trabajo son independientes y no comparten muchas políticas comunes.
  • Tus procesos y plataformas de desarrolladores externos se ofrecen como servicios o productos.

En el siguiente diagrama se muestra un ejemplo de jerarquía de un proveedor de una plataforma de comercio electrónico.

Diagrama de la opción 3.

El diagrama anterior tiene la siguiente estructura de jerarquía:

  • Las siguientes carpetas están en el primer nivel:
    • Las carpetas llamadas Ecommerce Modules y Logistics and Warehousing Modules representan los módulos de la oferta de la plataforma que requieren los mismos permisos de acceso y políticas durante el ciclo de vida del producto.
    • La carpeta Reconciliation and Billing representa a los equipos de producto responsables de los módulos integrales de componentes empresariales específicos de la oferta de la plataforma.
    • La carpeta Bootstrap representa los recursos comunes que se necesitan para desplegar tu infraestructura, tal como se describe en el Google Cloud blueprint de las bases de la empresa.
  • Dentro de cada carpeta hay varios proyectos que contienen los módulos independientes de los que se encargan los diferentes equipos de producto.

Para obtener más información, consulta Jerarquía de recursos del framework de Terraform de Fabric FAST.

Prácticas recomendadas para la jerarquía de recursos

En las siguientes secciones se describen las prácticas recomendadas para diseñar una jerarquía de recursos, independientemente de la que elijas.

Para obtener más información sobre las prácticas recomendadas para configurar tus cuentas y organizaciones de Cloud Identity y Google Workspace, consulta el artículo Prácticas recomendadas para planificar cuentas y organizaciones.

Usar un solo nodo de organización

Para evitar una sobrecarga de gestión, utiliza un solo nodo de organización siempre que sea posible. Sin embargo, te recomendamos que uses varios nodos de organización para abordar los siguientes casos prácticos:

  • Quieres probar cambios importantes en tus niveles de gestión de identidades y accesos o en tu jerarquía de recursos.
  • Quieres experimentar en un entorno aislado que no tenga las mismas políticas de la organización.
  • Tu organización incluye subempresas que probablemente se vendan o funcionen como entidades completamente independientes en el futuro.

Usar convenciones de nomenclatura estandarizadas

Utiliza una convención de nomenclatura estandarizada en toda tu organización. El plan de seguridad tiene una convención de nomenclatura de ejemplo que puedes adaptar a tus requisitos.

Mantener separados los recursos de arranque y los servicios comunes

Mantén carpetas independientes para iniciar el Google Cloud entorno con la infraestructura como código (IaC) y para los servicios comunes que se comparten entre entornos o aplicaciones. Coloca la carpeta de bootstrap justo debajo del nodo de organización en la jerarquía de recursos.

Coloca las carpetas de los servicios comunes en diferentes niveles de la jerarquía, según la estructura que elijas.

Coloca la carpeta de servicios comunes justo debajo del nodo de la organización cuando se cumplan las siguientes condiciones:

  • Tu jerarquía usa entornos de aplicación en el nivel más alto y equipos o aplicaciones en el segundo nivel.
  • Tienes servicios compartidos, como la monitorización, que son comunes en todos los entornos.

Coloca la carpeta de servicios comunes en un nivel inferior, debajo de las carpetas de aplicaciones, cuando se cumplan las siguientes condiciones:

  • Tienes servicios que se comparten entre aplicaciones y despliegas una instancia independiente para cada entorno de implementación.

  • Las aplicaciones comparten microservicios que requieren desarrollo y pruebas para cada entorno de implementación.

En el siguiente diagrama se muestra un ejemplo de jerarquía en el que hay una carpeta de infraestructura compartida que utilizan todos los entornos y carpetas de servicios compartidos para cada entorno de aplicación en un nivel inferior de la jerarquía:

Ejemplo de jerarquía con una carpeta de infraestructura compartida.

El diagrama anterior tiene la siguiente estructura de jerarquía:

  • Las carpetas del primer nivel son las siguientes:
    • Las carpetas Development environment y Production environment contienen los entornos de la aplicación.
    • La carpeta Shared infrastructure contiene recursos comunes que se comparten entre entornos, como la monitorización.
    • La carpeta Bootstrap contiene los recursos comunes necesarios para implementar tu infraestructura, tal como se describe en el blueprint de las bases de la empresa. Google Cloud
  • En el segundo nivel, se encuentran las siguientes carpetas:
    • Una carpeta en cada entorno para cada aplicación (App 1 y App 2) que contiene los recursos de estas aplicaciones.
    • Una carpeta Shared para ambos entornos de aplicación que contiene servicios que se comparten entre las aplicaciones, pero que son independientes para cada entorno. Por ejemplo, puedes tener un proyecto de secretos a nivel de carpeta para aplicar diferentes políticas de permiso a tus secretos de producción y a los que no son de producción.
  • Dentro de cada carpeta de aplicación, hay varios proyectos que contienen los módulos independientes que forman parte de cada aplicación.

Siguientes pasos