Decide una jerarquía de recursos para la zona de destino de Google Cloud

Last reviewed 2023-08-31 UTC

Una jerarquía de recursos ayuda a organizar los recursos en Google Cloud. En este documento, se describe cómo elegir la jerarquía de recursos como parte del diseño de la zona de destino. Está dirigido a los administradores del sistema de nube, arquitectos y profesionales técnicos que participan en el diseño de la jerarquía de recursos. Este documento es parte de una serie sobre las zonas de destino. Incluye jerarquías de muestra que demuestran formas comunes en que las empresas pueden estructurar los recursos en Google Cloud.

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

Cuando defines la jerarquía de recursos en Google Cloud, debes tener en cuenta cómo funciona la organización en la actualidad y el estado final ideal de la transformación en la nube. La mejor manera de administrar los recursos se basa en la forma prevista de trabajo de tu organización en la nube. Como cada organización es diferente, no existe un enfoque único y mejor para la jerarquía de recursos.

Sin embargo, recomendamos que evites asignar la estructura corporativa de la organización a la jerarquía de recursos. En su lugar, enfócate en las necesidades y las operaciones de tu empresa en Google Cloud.

Jerarquía de recursos de Google Cloud

La jerarquía de recursos en Google Cloud comienza en el nodo raíz, que se denomina organización. Recomendamos que las empresas tengan solo un nodo raíz, excepto en situaciones específicas. Te recomendamos definir niveles inferiores de la jerarquía mediante carpetas y proyectos, y crear carpetas dentro de carpetas para crear la jerarquía. Puedes crear los proyectos que alojen las 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 subcarpetas se crean en las carpetas en el nivel dos.

Ejemplo de una jerarquía con nodos raíz, carpetas y proyectos

Factores de jerarquía de recursos

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

  • ¿Quién es responsable de los recursos de la nube? ¿Son tus departamentos, subsidiarias, equipos técnicos o entidades legales?
  • ¿Cuáles son tus necesidades de cumplimiento?
  • ¿Tienes eventos empresariales futuros, como fusiones, adquisiciones y escisiones?

Comprende las interacciones de recursos en toda la jerarquía

Las políticas de la organización las heredan los subordinados de la jerarquía de recursos, pero pueden sustituirse por políticas definidas en un nivel inferior. Para obtener más información, consulta Comprende la evaluación de jerarquías. Usa restricciones de la política de la organización para establecer lineamientos en toda la organización o en partes significativas de ella y, aun así, permitir excepciones.

Las políticas de permiso, antes conocidas como políticas de IAM, son heredadas por los subordinados y las políticas de permiso en niveles inferiores son aditivas. Sin embargo, las políticas de permisos se pueden sustituir por políticas de denegación, que te permiten restringir los permisos a nivel de proyecto, carpeta y organización. Las políticas de denegación se aplican antes que las políticas de permisos.

También debes considerar lo siguiente:

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

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

Decisiones para las jerarquías de recursos.

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

  1. ¿Las diferentes subsidiarias, grupos regionales o unidades de negocios tienen requisitos de políticas muy distintos?
    1. Si es así, sigue el diseño basado en la región o las subsidiarias.
    2. De lo contrario, sigue con el próximo punto de decisión.

  2. ¿Tus equipos de productos o cargas de trabajo requieren una autonomía sólida sobre sus políticas? Por ejemplo, no tienes un equipo de seguridad central que determine las políticas para todos los equipos de productos o cargas de trabajo.

    1. Si es así, consulta el diseño basado en el framework de responsabilidad.

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

Tu caso de uso específico podría llevarte a otro diseño de jerarquía de recursos que se sugiere en el gráfico de decisión. La mayoría de las organizaciones eligen un enfoque híbrido y seleccionan diferentes diseños en distintos niveles de la jerarquía de recursos, a partir del diseño que más afecta a las políticas y el acceso.

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

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

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 auditoría o seguridad centralizados que un equipo de seguridad central debe poder aplicar de forma coherente en todos los datos y cargas de trabajo de producción.
  • Necesitas diferentes roles de Identity and Access Management (IAM) para acceder a los recursos de Google Cloud en diferentes entornos.

Evita esta jerarquía si se cumple lo siguiente:

  • No ejecutas varios entornos de aplicaciones.
  • No tienes dependencias de aplicaciones ni procesos empresariales variables en todos los entornos.
  • Existen grandes diferencias en las políticas para diferentes regiones, equipos o aplicaciones.

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

Diagrama de la opción 1

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

  • Entorno de desarrollo y control de calidad: Este entorno es administrado por desarrolladores que son asesores y empleados internos. Estos envían código de forma continua 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 los del entorno de producción, y a los desarrolladores se les asignan roles aprobados con los permisos adecuados. El entorno de desarrollo y control de calidad está diseñado solo para las ofertas de aplicaciones estándar de example.com.

  • Entorno de pruebas: Este entorno se utiliza para las pruebas de regresión y aplicaciones, y es compatible con las ofertas de empresa a empresa (B2B) de los clientes de example.com que usan las APIs de example.com. Para este fin, example.com crea dos tipos de proyectos:

    • Proyectos de prueba interna para completar la regresión interna, el rendimiento y la configuración de las ofertas B2B.
    • Proyectos UAT de clientes con asistencia de varios usuarios para que los clientes de empresa a empresa puedan validar sus configuraciones y alinearse con los requisitos de example.com para la experiencia del usuario, el desarrollo de la marca, los flujos de trabajo, los informes, etcétera.

  • Entorno de producción: Este entorno aloja todas las ofertas de productos que se validan, aceptan y lanzan. Está sujeto a las regulaciones del Estándar de Seguridad de Datos para la Industria de Tarjetas de Pago (PCI DSS), usa módulos de seguridad de hardware (HSM) y se integra con procesadores de terceros para elementos como acuerdos de autenticación y pago. Los equipos de auditoría y cumplimiento son partes interesadas fundamentales de este entorno. El acceso a este entorno es muy controlado y se limita más que nada a los procesos de implementación automatizados.

Para obtener más información sobre el diseño de una jerarquía basada en los entornos de aplicaciones, consulta Estructura de la organización en el plano de bases empresariales.

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

Algunas organizaciones operan en muchas regiones y tienen subsidiarias que hacen negocios en diferentes ubicaciones geográficas o son el resultado de fusiones y adquisiciones. Estas organizaciones requieren una jerarquía de recursos que use las opciones de escalabilidad y administración en Google Cloud y mantenga la independencia para los diferentes procesos y políticas que existen entre las regiones o las subsidiarias. Esta jerarquía usa subsidiarias o regiones como el nivel de carpeta más alto en la jerarquía de recursos. Los procedimientos de implementación se suelen enfocar en torno a las regiones.

Usa esta jerarquía si se cumple lo siguiente:

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

En el siguiente diagrama, se muestra una jerarquía de ejemplo de una organización global con dos subsidiarias y un grupo de cartera 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 subsidiarias de la empresa, que tienen políticas y permisos de acceso diferentes del resto de la organización. Cada subsidiaria usa IAM para restringir el acceso a sus proyectos y recursos de 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 necesarios para implementar la infraestructura de Google Cloud, como se describe en el plano de bases empresariales.
  • En el segundo nivel, dentro de la carpeta Holding group, están las siguientes carpetas:
    • Las carpetas APAC, EMEA y Americas representan las diversas regiones dentro del grupo que tienen diferente administración, permisos de acceso y políticas.
    • 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 subsidiarias o regiones.

Puedes agregar más carpetas para separar diferentes entidades legales, departamentos y equipos dentro de la empresa.

Opción 3: Jerarquía basada en un marco de trabajo de responsabilidad

Una jerarquía basada en un framework de responsabilidad funciona mejor cuando tus productos se ejecutan de forma independiente o las unidades organizativas tienen equipos definidos con claridad que son propietarios del ciclo de vida de los productos. En estas organizaciones, los propietarios del producto son responsables de todo el ciclo de vida del producto, incluidos sus procesos, asistencia, políticas, seguridad y derechos de acceso. Tus productos son independientes entre sí, y los lineamientos y controles de toda la organización son poco comunes.

Usa esta jerarquía cuando se cumpla lo siguiente:

  • Administras una organización que tiene propiedades y responsabilidades claras para cada producto.
  • Tus cargas de trabajo son independientes y no comparten muchas políticas comunes.
  • Los procesos y las plataformas de desarrolladores externas se ofrecen como ofertas de servicios o productos.

En el siguiente diagrama, se muestra una jerarquía de ejemplo para un proveedor de 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 Ecommerce Modules y Logistics and Warehousing Modules representan los módulos dentro 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 productos que son responsables de los módulos de extremo a extremo para componentes empresariales específicos dentro de la oferta de la plataforma.
    • La carpeta Bootstrap representa los recursos comunes necesarios para implementar la infraestructura de Google Cloud, como se describe en el plano de bases empresariales.
  • Dentro de cada carpeta hay varios proyectos que contienen los módulos independientes de los que son responsables los diferentes equipos de producto.

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

Prácticas recomendadas para la jerarquía de recursos

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

Si deseas obtener más prácticas recomendadas para configurar las cuentas y organizaciones de Cloud Identity y Google Workspace, consulta Prácticas recomendadas para planificar cuentas y organizaciones.

Usa un nodo de la organización único

A fin de evitar la sobrecarga de la administración, usa un solo nodo de la organización siempre que sea posible. Sin embargo, considera usar varios nodos de la organización para abordar los siguientes casos de uso:

  • Deseas probar grandes cambios en los niveles de IAM o la jerarquía de recursos.
  • Deseas experimentar en un entorno de zona de pruebas que no tenga las mismas políticas de la organización.
  • Tu organización incluye subempresas que podrían venderse o administrarse como entidades completamente separadas en el futuro.

Usa convenciones de nombres estandarizadas

Usa una convención de nombres estandarizada en toda la organización. El plano de base de seguridad tiene una convención de nombres de muestra que puedes adaptar a tus requisitos.

Mantén separados los recursos de inicio y los servicios comunes

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

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

Coloca la carpeta para los servicios comunes justo debajo del nodo de la organización cuando se cumpla lo siguiente:

  • En tu jerarquía se usan entornos de aplicación en el nivel más alto y equipos o aplicaciones en la segunda capa.
  • Tienes servicios compartidos, como la supervisión, que son comunes entre los entornos.

Coloca la carpeta para servicios comunes en un nivel inferior, debajo de las carpetas de la aplicación, cuando se cumpla lo siguiente:

  • Tienes servicios que se comparten entre aplicaciones y, además, implementas una instancia diferente 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 una jerarquía de ejemplo en la que hay una carpeta de infraestructura compartida que usan 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 en el 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 en todos los entornos, como la supervisión.
    • La carpeta Bootstrap contiene los recursos comunes necesarios para implementar tu infraestructura de Google Cloud, como se describe en el plano de bases empresariales.
  • En el segundo nivel, están 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 aplicaciones que contiene servicios compartidos entre las aplicaciones, pero que son independientes de cada entorno. Por ejemplo, puedes tener un proyecto de secretos a nivel de carpeta para que puedas aplicar diferentes políticas de permisos a tus secretos de producción y a los secretos de no producción.
  • Dentro de cada carpeta de la aplicación hay varios proyectos que contienen los módulos independientes que forman parte de cada aplicación.

¿Qué sigue?