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.
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:
- Cloud Logging incluye receptores agregados que puedes usar para agregar registros a nivel de la organización o la carpeta. Para obtener más información, consulta Decide la seguridad de tu zona de destino de Google Cloud.
- La facturación no se vincula directamente a la jerarquía de recursos, sino que se asigna a nivel de proyecto. Sin embargo, para obtener información agregada a nivel de la carpeta, puedes analizar los costos por jerarquía de proyectos mediante informes de facturación.
- Las políticas de firewall jerárquicas te permiten implementar políticas de firewall coherentes en toda la organización o en carpetas específicas. La herencia es implícita, lo que significa que puedes permitir o denegar el tráfico en cualquier nivel o puedes delegar la decisión a un nivel inferior.
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.
En el diagrama anterior, se describen los siguientes puntos de decisión:
- ¿Las diferentes subsidiarias, grupos regionales o unidades de negocios tienen requisitos de políticas muy distintos?
- Si es así, sigue el diseño basado en la región o las subsidiarias.
- De lo contrario, sigue con el próximo punto de decisión.
¿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.
Si es así, consulta el diseño basado en el framework de responsabilidad.
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.
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.
El diagrama anterior tiene la siguiente estructura de jerarquía:
- Las siguientes carpetas están en el primer nivel:
- Las carpetas
Subsidiary 1
ySubsidiary 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.
- Las carpetas
- En el segundo nivel, dentro de la carpeta Holding group, están las siguientes carpetas:
- Las carpetas
APAC
,EMEA
yAmericas
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.
- Las carpetas
- 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.
El diagrama anterior tiene la siguiente estructura de jerarquía:
- Las siguientes carpetas están en el primer nivel:
- Las carpetas
Ecommerce Modules
yLogistics 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.
- Las carpetas
- 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:
El diagrama anterior tiene la siguiente estructura de jerarquía:
- Las carpetas en el primer nivel son las siguientes:
- Las carpetas
Development environment
yProduction 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.
- Las carpetas
- En el segundo nivel, están las siguientes carpetas:
- Una carpeta en cada entorno para cada aplicación (
App 1
yApp 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.
- Una carpeta en cada entorno para cada aplicació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?
- Diseña la red para tu zona de destino (el siguiente documento de esta serie).
- Revisa el plano de bases empresariales.
- Lee los planos y los informes disponibles en el Centro de prácticas recomendadas para la seguridad de Google Cloud.