En este documento se presentan las prácticas recomendadas para decidir cuántas cuentas de Cloud Identity,Google Workspace, organizaciones y cuentas de facturación necesitas usar. Google Cloud El documento ofrece directrices para identificar un diseño que cumpla los requisitos de seguridad y de la organización.
En Google Cloud, la gestión de identidades y accesos se basa en dos pilares:
Las cuentas de Cloud Identity y Google Workspace son contenedores de usuarios y grupos. Por lo tanto, estas cuentas son fundamentales para autenticar a los usuarios de tu empresa y gestionar el acceso a tusGoogle Cloud recursos. Una cuenta de Cloud Identity o de Google Workspace hace referencia a un directorio de usuarios, no a una cuenta de usuario individual. Las cuentas de usuario individuales se denominan usuarios o cuentas de usuario.
Las organizaciones son contenedores de proyectos y recursos en Google Cloud. Las organizaciones permiten estructurar los recursos de forma jerárquica y son fundamentales para gestionarlos de forma centralizada y eficiente.
Este documento está dirigido principalmente a los clientes que configuran entornos empresariales.
Cuentas de Cloud Identity y Google Workspace
Google Workspace es un paquete integrado de aplicaciones de colaboración y productividad nativas de la nube. Incluye herramientas que te permiten gestionar usuarios, grupos y autenticación.
Cloud Identity ofrece un subconjunto de las funciones de Google Workspace. Al igual que Google Workspace, Cloud Identity te permite gestionar usuarios, grupos y autenticación, pero no incluye todas las funciones de colaboración y productividad de Google Workspace.
Cloud Identity y Google Workspace comparten una plataforma técnica común y usan el mismo conjunto de APIs y herramientas administrativas. Los productos comparten el concepto de cuenta como contenedor de usuarios y grupos. Este contenedor se identifica mediante un nombre de dominio, como example.com. Para gestionar usuarios, grupos y autenticación, los dos productos se pueden considerar equivalentes.
Combinar Cloud Identity y Google Workspace en una sola cuenta
Como Cloud Identity y Google Workspace comparten una plataforma común, puedes combinar el acceso a los productos en una sola cuenta.
Si ya administras una cuenta de Google Workspace y quieres que más usuarios utilicen Google Cloud, puede que no quieras asignar una licencia de Google Workspace a todos los usuarios. En este caso, añade Cloud Identity Free a tu cuenta. Después, puedes incorporar a más usuarios sin coste adicional y decidir quiénes deben tener acceso a Google Workspace asignándoles una licencia de Google Workspace.
Del mismo modo, si ya administras una cuenta de Cloud Identity Free o Premium, puede que quieras conceder a determinados usuarios el derecho a usar Google Workspace. En lugar de crear cuentas de Google Workspace independientes para esos usuarios, puedes añadir Google Workspace a una cuenta de Cloud Identity que ya tengas. Una vez que hayas asignado la licencia de Google Workspace a los usuarios seleccionados, podrán usar las aplicaciones de productividad y colaboración.
Usa el menor número posible de cuentas, pero tantas como sean necesarias
Para que tus usuarios puedan colaborar con Google Workspace y minimizar la carga administrativa, lo mejor es gestionar a todos los usuarios a través de una sola cuenta de Cloud Identity o Google Workspace y proporcionar una sola cuenta de usuario a cada persona. De esta forma, se asegura que los ajustes, como las políticas de contraseñas, el inicio de sesión único y la verificación en dos pasos, se apliquen de forma coherente a todos los usuarios.
A pesar de las ventajas de usar una sola cuenta de Cloud Identity o Google Workspace, puedes disfrutar de flexibilidad y autonomía administrativa si usas varias cuentas. Cuando decidas cuántas cuentas de Cloud Identity o Google Workspace vas a usar, ten en cuenta todos los requisitos que sugieran usar varias cuentas. Después, usa el número más pequeño de cuentas de Cloud Identity o Google Workspace que cumpla tus requisitos.
Usar cuentas independientes para las fases de staging y producción
En la mayoría de los ajustes que puedes configurar en Cloud Identity y Google Workspace, puedes elegir el ámbito en el que se debe aplicar cada ajuste. Por ejemplo, puedes especificar la ubicación geográfica de tus datos por usuario, por grupo o por unidad organizativa. Cuando tengas previsto aplicar una nueva configuración, puedes elegir un ámbito pequeño (por ejemplo, por usuario) y verificar si la configuración cumple tus expectativas. Cuando hayas verificado la configuración, podrás aplicar el mismo ajuste a un conjunto más amplio de grupos o unidades organizativas.
A diferencia de la mayoría de los ajustes, la integración de una cuenta de Cloud Identity o Google Workspace con un proveedor de identidades (IdP) externo tiene un impacto global:
- Habilitar el inicio de sesión único es un ajuste global que se aplica a todos los usuarios, excepto a los superadministradores.
- En función de tu proveedor de identidades externo, la configuración del aprovisionamiento de usuarios también puede tener un impacto global. Una configuración incorrecta accidental en el IdP externo puede provocar que los usuarios se modifiquen, suspendan o incluso eliminen por error.
Para mitigar estos riesgos, ten cuentas de Cloud Identity o Google Workspace independientes para las fases de desarrollo y producción:
- Usa la cuenta de staging para verificar los cambios de configuración arriesgados antes de aplicarlos a tu cuenta de producción.
- Crea algunos usuarios de prueba en las cuentas de staging que tú y otros administradores podáis usar para verificar los cambios de configuración. Sin embargo, no concedas acceso a tus usuarios a la cuenta de staging.
Si tienes instancias de staging y de producción independientes de tu proveedor de identidades externo, sigue estos pasos:
- Integra tu cuenta de Cloud Identity o Google Workspace de staging con tu instancia de IdP de staging.
- Integra tu cuenta de Cloud Identity o Google Workspace de producción con tu instancia de IdP de producción.
Por ejemplo, supongamos que quieres configurar la federación con Active Directory y tienes un bosque de Active Directory independiente para hacer pruebas. En este caso, integra tu cuenta de Cloud Identity o Google Workspace de prueba con el bosque de prueba y la cuenta de Cloud Identity o Google Workspace de producción con tu bosque principal. Aplica el mismo enfoque de mapeo a los dominios DNS, los usuarios y los grupos de ambos pares de bosques o cuentas, como se muestra en el siguiente diagrama:
Es posible que los bosques y dominios de Active Directory de producción y de pruebas usen dominios DNS que no te permitan aplicar el mismo método de asignación de dominios para las pruebas y la producción. En este caso, te recomendamos que registres más dominios de sufijo de nombre principal de usuario (UPN) en tu bosque de ensayo.
Del mismo modo, si tienes previsto configurar la federación con Microsoft Entra ID, te recomendamos que sigas estos pasos:
- Integra la cuenta de Cloud Identity o Google Workspace de prueba con un inquilino de Entra ID de prueba.
- Integra la cuenta de producción de Cloud Identity o Google Workspace con tu inquilino principal de Entra ID.
Aplica el mismo método de asignación a los dominios DNS, los usuarios y los grupos de ambos pares de inquilinos o cuentas:
Es posible que tus tenants de Entra ID de producción y de staging usen dominios DNS que no te permitan aplicar el mismo método de asignación de dominios para staging y producción. En ese caso, puedes añadir un dominio adicional a tu inquilino de staging.
Usar dominios DNS disjuntos entre cuentas de Cloud Identity y Google Workspace
Cuando añades por primera vez un dominio, como example.com, a tu cuenta de Cloud Identity o Google Workspace, debes verificar que eres el propietario del dominio.
Una vez que hayas añadido y verificado un dominio, puedes añadir subdominios como marketing.example.com y finance.example.com sin tener que verificar cada subdominio individualmente.
Sin embargo, si añades subdominios sin verificar cada uno de ellos, pueden producirse conflictos si tienes otra cuenta de Cloud Identity o Google Workspace que ya utilice ese subdominio. Para evitar estos conflictos, es preferible usar dominios disjuntos para cada cuenta. Por ejemplo, si necesitas dos cuentas de Cloud Identity o Google Workspace, intenta no usar dos dominios en los que uno sea un subdominio del otro. En su lugar, usa dos dominios que no sean subdominios de otro. Esta práctica se aplica al dominio principal y a los dominios secundarios.
No separar Google Workspace y Google Cloud
Si ya usas Google Workspace, es posible que algunos usuarios de tu cuenta de Google Workspace tengan privilegios de superadministrador para poder llevar a cabo tareas administrativas.
Los usuarios con privilegios de superadministrador tienen permiso implícito para modificar la política de Gestión de Identidades y Accesos (IAM) del nodo de organización. Este permiso permite a los superadministradores asignarse el rol de administrador de la organización u otro rol de la Google Cloud organización. Si un usuario tiene acceso de superadministrador a una cuenta de Cloud Identity o Google Workspace, también podrá eliminar la cuenta, la organización asociada Google Cloud y todos sus recursos. Por lo tanto, debes dar por hecho que los superadministradores tienen acceso completo a todos los recursos de una organización.
El hecho de que los superadministradores también sean administradores de la organización puede suponer un problema de seguridad si los administradores de Google Workspace que ya tienes son un conjunto de usuarios diferente de los que se encargarán de gestionar tuGoogle Cloud organización. En este caso, puedes crear una cuenta de Cloud Identity independiente dedicada a Google Cloud para limitar el acceso de los superadministradores de Google Workspace a los recursos deGoogle Cloud . Separar Google Workspace yGoogle Cloud puede tener varias consecuencias no deseadas.
Por ejemplo, puedes crear usuarios independientes en la cuenta de Cloud Identity y, a continuación, restringir el acceso de los usuarios de la organización a la cuenta de Cloud Identity Google Cloud . De esta forma, te asegurarías de que tu Google Cloud despliegue y Google Workspace estén completamente aislados. Sin embargo, duplicar usuarios afecta negativamente tanto a la experiencia de usuario como a la carga administrativa. Además, no podrías recibir ningún correo de notificación enviado por Google Cloud, ya que el dominio usado por Cloud Identity debe ser diferente del dominio usado en Google Workspace y, por lo tanto, no es adecuado para enrutar correos.
Si, en su lugar, haces referencia a usuarios de la cuenta de Google Workspace de tu Google Cloud organización, se verá afectada la separación entre Google Workspace y Google Cloud:
Los superadministradores de Google Workspace pueden usar la delegación en todo el dominio para suplantar la identidad de cualquier usuario de la misma cuenta de Google Workspace. Un superadministrador no autorizado podría usar sus privilegios elevados para recuperar el acceso aGoogle Cloud.
Una estrategia más eficaz que usar cuentas independientes es segregar las responsabilidades entre los administradores de Google Workspace y los de Google Cloudpara reducir el número de superadministradores:
Para la mayoría de las tareas administrativas de Google Workspace no se necesitan privilegios de superadministrador. Usa roles de administrador predefinidos o roles de administrador personalizados en lugar de privilegios de superadministrador para conceder a los administradores de Google Workspace los permisos necesarios para llevar a cabo sus tareas.
Conserva solo un número mínimo de usuarios superadministradores y desaconseja su uso diario.
Aprovecha la auditoría para detectar actividad sospechosa entre los usuarios administradores.
Proteger tu proveedor de identidades externo al usar el inicio de sesión único
Cloud Identity y Google Workspace te permiten configurar el inicio de sesión único con tu proveedor de identidades externo, como Active Directory, Entra ID u Okta (por mencionar algunos). Si el inicio de sesión único está habilitado, Cloud Identity y Google Workspace confían en el proveedor de identidades externo para autenticar a los usuarios en nombre de Google.
Habilitar el inicio de sesión único ofrece varias ventajas:
- Los usuarios pueden usar sus credenciales para iniciar sesión en los servicios de Google.
- Los usuarios no tienen que volver a introducir sus contraseñas si ya tienen una sesión de inicio de sesión.
- Puedes aplicar políticas de autenticación multifactor coherentes en todas tus aplicaciones y en todos los servicios de Google.
Sin embargo, habilitar el inicio de sesión único también conlleva riesgos. Cuando el inicio de sesión único está habilitado y un usuario necesita autenticarse, Cloud Identity o Google Workspace lo redirige a tu IdP externo. Después de autenticar al usuario, el proveedor de identidades devuelve a Google una aserción SAML que indica la identidad del usuario. La aserción SAML está firmada. Por lo tanto, Google puede verificar la autenticidad de la aserción SAML y comprobar que se ha usado el proveedor de identidades correcto. Sin embargo, Cloud Identity o Google Workspace no pueden verificar que el IdP haya tomado la decisión de autenticación correcta y haya indicado correctamente la identidad del usuario.
Si el inicio de sesión único está habilitado, la seguridad y la integridad generales de tu implementación de Google dependen de la seguridad y la integridad de tu proveedor de identidades. Tu cuenta de Cloud Identity o Google Workspace y todos los recursos que dependen de los usuarios gestionados por la cuenta corren peligro si alguno de los siguientes elementos no está configurado de forma segura:
- El propio proveedor de identidades
- Las máquinas en las que se ejecuta el proveedor
- La base de datos de usuarios de la que el proveedor obtiene información de los usuarios
- Cualquier otro sistema del que dependa el proveedor
Para evitar que el inicio de sesión único se convierta en un punto débil de tu postura de seguridad, asegúrate de que tu proveedor de identidades y todos los sistemas de los que depende estén configurados de forma segura:
- Limita el número de usuarios con acceso de administrador a tu IdP o a cualquiera de los sistemas en los que se basa el proveedor.
- No concedas acceso de administrador a estos sistemas a ningún usuario al que no le darías privilegios de superadministrador en Cloud Identity o Google Workspace.
- No utilices el inicio de sesión único si no tienes claro qué controles de seguridad se han implementado en tu proveedor de identidades externo.
Acceso seguro a tus zonas DNS
Las cuentas de Cloud Identity y Google Workspace se identifican mediante un nombre de dominio DNS principal. Cuando creas una cuenta de Cloud Identity o de Google Workspace, debes verificar la propiedad del dominio DNS creando un registro DNS especial en la zona DNS correspondiente.
La importancia del DNS y el impacto en la seguridad general de tu implementación de Google van más allá del proceso de registro:
Google Workspace utiliza registros MX de DNS para enrutar los correos. Si se modifican estos registros MX, un atacante podría enrutar correos a otro servidor y obtener acceso a información sensible.
Si un atacante puede añadir registros a la zona DNS, podría cambiar la contraseña de un usuario superadministrador y obtener acceso a la cuenta.
Para evitar que el DNS se convierta en un punto débil de tu postura de seguridad, asegúrate de que tu servidor DNS esté configurado de forma segura:
Limita el número de usuarios que tienen acceso de administrador al servidor DNS que gestiona el dominio principal usado en Cloud Identity o Google Workspace.
No concedas acceso administrativo a tu servidor DNS a ningún usuario al que no le darías privilegios de superadministrador en Cloud Identity o Google Workspace.
Si tienes previsto implementar una carga de trabajo en Google Cloud que tenga requisitos de seguridad que no cumpla tu infraestructura de DNS, considera la posibilidad de registrar para esa carga de trabajo un nuevo dominio DNS que utilice servidores DNS independientes o un servicio DNS gestionado.
Exportar registros de auditoría a BigQuery
Cloud Identity y Google Workspace mantienen varios registros de auditoría para monitorizar los cambios de configuración y otras actividades que puedan ser relevantes para la seguridad de tu cuenta de Cloud Identity o Google Workspace. En la siguiente tabla se resumen estos registros de auditoría.
| Registro | Actividades registradas |
|---|---|
| Administrador | Acciones realizadas en la consola de administración de Google |
| Iniciar sesión | Intentos de inicio de sesión correctos, fallidos y sospechosos en tu dominio |
| Token | Instancias de autorización o revocación del acceso a aplicaciones móviles o web de terceros |
| Grupos | Cambios en grupos y en la pertenencia a grupos |
Puedes acceder a estos registros de auditoría a través de la consola de administración o de la API Reports. En la mayoría de los registros de auditoría, los datos se conservan durante 6 meses.
Si opera en un sector regulado, es posible que no sea suficiente con conservar los datos de auditoría durante 6 meses. Para conservar los datos durante más tiempo, configura la exportación de los registros de auditoría a BigQuery.
Para limitar el riesgo de que se acceda sin autorización a los registros de auditoría exportados, utiliza un Google Cloud proyecto específico para el conjunto de datos de BigQuery. Para proteger los datos de auditoría frente a manipulaciones o eliminaciones, concede acceso al proyecto y al conjunto de datos según el principio de mínimos accesos.
Los registros de auditoría de Cloud Identity y Google Workspace son complementarios a los registros de Cloud Audit Logs. Si también usa BigQuery para recoger registros de auditoría de Cloud y otros registros de auditoría específicos de aplicaciones, puede correlacionar los eventos de inicio de sesión con las actividades que ha realizado un usuario en Google Cloud o en sus aplicaciones. La posibilidad de correlacionar datos de auditoría de varias fuentes puede ayudarte a detectar y analizar actividades sospechosas.
Para configurar la exportación a BigQuery, se necesita una licencia de Google Workspace Enterprise. Una vez que hayas configurado los registros de auditoría principales, se exportarán para todos los usuarios, incluidos aquellos que no tengan una licencia de Google Workspace. Determinados registros, como los de auditoría de Drive y de dispositivos móviles, se exportan para los usuarios que tienen al menos una licencia de Google Workspace Business.
Si usas Cloud Identity Free para la mayoría de tus usuarios, puedes seguir exportando a BigQuery si añades Google Workspace Enterprise a tu cuenta de Cloud Identity y compras licencias de Google Workspace para un conjunto de administradores.
Organizaciones
Las organizaciones te permiten organizar los recursos en una jerarquía de proyectos y carpetas, donde el nodo de la organización es la raíz. Las organizaciones están asociadas a una cuenta de Cloud Identity o Google Workspace, y su nombre se deriva del nombre de dominio principal de la cuenta asociada. Una organización se crea automáticamente cuando un usuario de la cuenta de Cloud Identity o Google Workspace crea un proyecto por primera vez.
Cada cuenta de Cloud Identity o Google Workspace solo puede tener una organización. De hecho, no es posible crear una organización sin una cuenta correspondiente. A pesar de esta dependencia, puedes conceder acceso a los usuarios de varias cuentas diferentes a los recursos de una sola organización:
La flexibilidad para hacer referencia a usuarios de diferentes cuentas de Cloud Identity o Google Workspace te permite separar la forma en que tratas las cuentas y las organizaciones. Puedes separar la decisión de cuántas cuentas de Cloud Identity o Google Workspace necesitas para gestionar a tus usuarios de la decisión de cuántas organizaciones necesitas para gestionar tus recursos.
El número de organizaciones que crees y sus finalidades pueden influir considerablemente en tu postura de seguridad, la autonomía de tus equipos y departamentos, y la coherencia y la eficiencia de tu administración.
En las siguientes secciones se describen las prácticas recomendadas para decidir cuántas organizaciones usar.
Usa el menor número posible de organizaciones, pero tantas como sean necesarias
La jerarquía de recursos de una organización te permite reducir el esfuerzo necesario para gestionar las políticas de gestión de identidades y accesos y las políticas de la organización aprovechando la herencia. Si configuras las políticas a nivel de carpeta o de organización, te aseguras de que se apliquen de forma coherente en una subjerarquía de recursos y evitas tener que repetir la configuración. Para minimizar la carga administrativa, lo mejor es usar el menor número de organizaciones posible.
Por el contrario, puedes obtener más flexibilidad y autonomía administrativa si usas varias organizaciones. En las secciones siguientes se describe cuándo puede necesitar esta flexibilidad o autonomía adicional.
En cualquier caso, cuando decidas cuántas organizaciones vas a usar, ten en cuenta todos los requisitos que sugieran usar varias organizaciones. A continuación, usa el menor número de organizaciones que cumpla tus requisitos.
Usar organizaciones para delimitar la autoridad administrativa
En una jerarquía de recursos, puedes conceder permisos a nivel de recurso, proyecto o carpeta. El nivel más alto en el que puedes conceder permisos a un usuario es la organización.
Un usuario al que se le ha asignado el rol Administrador de la organización a nivel de organización tiene control total sobre la organización, sus recursos y sus políticas de gestión de identidades y accesos. Un administrador de la organización puede tomar el control de cualquier recurso de la organización y delegar el acceso de administrador a cualquier otro usuario.
Sin embargo, las funciones de un administrador de la organización se limitan a la organización, por lo que esta es el ámbito último de la autoridad administrativa:
- Un administrador de la organización no puede acceder a ningún recurso de otras organizaciones a menos que se le conceda permiso explícitamente.
- Ningún usuario ajeno a la organización puede quitar el control a un administrador de la organización.
El número adecuado de organizaciones que debes usar depende del número de grupos independientes de usuarios administradores de tu empresa:
- Si tu empresa está organizada por funciones, puede que tengas un solo departamento encargado de supervisar todas las implementaciones. Google Cloud
- Si tu empresa está organizada por divisiones o tiene varias filiales que funcionan de forma autónoma, es posible que no haya un único departamento encargado.
Si un solo departamento se encarga de supervisar las implementaciones, lo mejor es usar un solo nodo de organización. Google Cloud Google Cloud Dentro de la organización, usa carpetas para estructurar los recursos y conceder diferentes niveles de acceso a otros equipos y departamentos.
Si trabajas con varios departamentos independientes, intentar centralizar la administración mediante una sola organización puede generar fricciones:
- Si designas un solo departamento para gestionar la organización, es posible que otros departamentos se opongan.
- Si permites que varios equipos o departamentos compartan la propiedad de una misma organización, puede resultar difícil mantener una jerarquía de recursos coherente y asegurarte de que las políticas de gestión de identidades y accesos y las políticas de la organización se usen de forma coherente en todos tus recursos.
Para evitar este tipo de fricción, utiliza varias organizaciones y crea estructuras de carpetas independientes en cada una de ellas. Si usas organizaciones independientes, podrás establecer límites entre diferentes grupos de usuarios administradores y, de este modo, delimitar su autoridad administrativa.
Usar una organización de staging independiente
Para garantizar la coherencia y evitar el trabajo de configuración repetitivo, organiza tus proyectos en una jerarquía de carpetas y aplica políticas de gestión de identidades y accesos y políticas de empresa a nivel de carpeta o de organización.
Sin embargo, tener políticas que se apliquen a muchos proyectos y recursos tiene un inconveniente. Cualquier cambio en la política o en la jerarquía de recursos a la que se aplique puede tener consecuencias de gran alcance e imprevistas. Para reducir este riesgo, es mejor que pruebe los cambios en las políticas antes de aplicarlos en su organización principal.
Te recomendamos que crees una organización de prueba independiente. Esta organización te ayuda a probar los cambios en la jerarquía de recursos, las políticas de gestión de identidades y accesos, las políticas de la organización u otras configuraciones que puedan tener un impacto en toda la organización, como los niveles de acceso y las políticas.
Para asegurarte de que los resultados de las pruebas o los experimentos realizados en la organización de staging también se apliquen a la organización de producción, configura la organización de staging para que use la misma estructura de carpetas que tu organización principal, pero con solo un pequeño número de proyectos. En cualquier momento, las políticas de IAM y de la organización de staging deben coincidir con las políticas de tu organización de producción o reflejar la siguiente versión de las políticas que quieras aplicar a tu organización de producción.
Como se muestra en el siguiente diagrama, puedes usar tu cuenta de Cloud Identity o Google Workspace de staging como base para la organización de staging. Utilizas la cuenta de staging (o el IdP externo con el que está integrada tu cuenta de staging) para crear usuarios de prueba específicos y una estructura de grupos que refleje los grupos que utilizas en tu cuenta de producción de Cloud Identity o Google Workspace. Después, puedes usar estos usuarios y grupos de prueba específicos para probar las políticas de gestión de identidades y accesos sin que afecten a los usuarios actuales.
Evitar usar una organización de pruebas independiente
Para cada carga de trabajo de producción que quieras implementar en Google Cloud, probablemente necesites uno o varios entornos de prueba que tus equipos de desarrollo y DevOps puedan usar para validar nuevas versiones.
Desde el punto de vista de la seguridad, para evitar que las versiones no probadas afecten accidentalmente a las cargas de trabajo de producción, es conveniente separar claramente los entornos de prueba de los de producción. Del mismo modo, los dos tipos de entornos tienen requisitos diferentes para las políticas de gestión de identidades y accesos. Por ejemplo, para que los desarrolladores y los testers tengan la flexibilidad que necesitan, los requisitos de seguridad de tus entornos de pruebas pueden ser mucho menos estrictos que los de tus entornos de producción.
Como se muestra en el siguiente diagrama, desde el punto de vista de la configuración, es recomendable que los entornos de prueba sean lo más parecidos posible a los entornos de producción. Cualquier divergencia aumenta el riesgo de que una implementación que haya funcionado correctamente en un entorno de prueba falle cuando se implemente en un entorno de producción.
Para encontrar el equilibrio entre mantener los entornos aislados y coherentes, usa carpetas de la misma organización para gestionar los entornos de prueba y de producción:
- Aplica las políticas de gestión de identidades y accesos o las políticas de la organización que sean comunes en todos los entornos a nivel de organización (o mediante una carpeta principal común).
- Usa las carpetas individuales para gestionar las políticas de IAM y las políticas de la organización que difieren entre los distintos tipos de entornos.
No uses tu organización de staging para gestionar entornos de prueba. Los entornos de pruebas son fundamentales para la productividad de los equipos de desarrollo y DevOps. Si gestionas estos entornos en tu entorno de preproducción, no podrás usar la organización de preproducción para experimentar y probar cambios en las políticas, ya que cualquier cambio podría interrumpir el trabajo de estos equipos. En resumen, si usas una organización de staging para gestionar entornos de prueba, no estarás aprovechando el propósito de la organización de staging.
Usar una organización independiente para experimentar
Para sacar el máximo partido a Google Cloud, deja que tus equipos de desarrollo, DevOps y operaciones se familiaricen con la plataforma y amplíen su experiencia con los tutoriales. Anímales a probar nuevas funciones y servicios.
Usa una organización independiente como entorno de pruebas para llevar a cabo este tipo de actividades experimentales. Si usas una organización independiente, puedes evitar que las políticas, la configuración o la automatización que utilices en tu organización de producción afecten a los experimentos.
No uses tu organización de preproducción para hacer pruebas. Tu entorno de staging debe usar políticas de IAM y de organización similares a las de tu organización de producción. Por lo tanto, es probable que el entorno de pruebas esté sujeto a las mismas limitaciones que el entorno de producción. Al mismo tiempo, flexibilizar las políticas para permitir experimentos socavaría el propósito de tu organización de staging.
Para evitar que tu organización experimental se desorganice, genere costes excesivos o se convierta en un riesgo para la seguridad, publica directrices que definan cómo pueden usar la organización los equipos y quién es responsable de mantenerla. Además, puedes configurar la automatización para eliminar recursos o incluso proyectos enteros automáticamente al cabo de un número determinado de días.
Como se muestra en el siguiente diagrama, cuando creas una organización para experimentar, primero creas una cuenta de Cloud Identity específica. A continuación, usa los usuarios de tu cuenta principal de Cloud Identity o Google Workspace para conceder acceso a la organización experimental.
Para gestionar la cuenta adicional de Cloud Identity, necesitas al menos una cuenta de usuario superadministrador en la cuenta de Cloud Identity. Para obtener información sobre cómo proteger estas cuentas de usuario de superadministrador, consulta el artículo Prácticas recomendadas para cuentas de superadministrador.
Usar el uso compartido restringido por dominio para reforzar las relaciones de confianza
Las políticas de gestión de identidades y accesos te permiten añadir cualquier identidad de Google válida como miembro. Esto significa que, cuando editas la política de IAM de un recurso, proyecto, carpeta u organización, puedes añadir miembros de diferentes fuentes, entre las que se incluyen las siguientes:
- Usuarios de la cuenta de Cloud Identity o Google Workspace a la que está asociada la organización, así como cuentas de servicio de la misma organización
- Usuarios de otras cuentas de Cloud Identity o Google Workspace
- Cuentas de servicio de otras organizaciones
- Cuentas de usuarios particulares, incluidas las de
gmail.comy las cuentas de particulares que usan una dirección de correo de empresa
Poder hacer referencia a usuarios de diferentes fuentes es útil en situaciones y proyectos en los que necesites colaborar con afiliados u otras empresas. En la mayoría de los demás casos, es mejor restringir las políticas de gestión de identidades y accesos para que solo permitan miembros de fuentes de confianza.
Usa la función para compartir con restricciones de dominio para definir un conjunto de cuentas de Cloud Identity o Google Workspace de confianza desde las que quieras permitir que se añadan miembros a las políticas de gestión de identidades y accesos. Define esta política de empresa a nivel de organización (para que se aplique a todos los proyectos) o en una carpeta situada cerca de la parte superior de la jerarquía de recursos (para permitir que se excluyan determinados proyectos).
Si usas cuentas y organizaciones de Cloud Identity o Google Workspace independientes para separar los entornos de desarrollo, producción y experimentación, utiliza políticas de uso compartido restringido por dominio para aplicar la separación, tal como se indica en la siguiente tabla:
| Organización | Cuenta de Cloud Identity o Google Workspace de confianza |
|---|---|
| Staging | Staging |
| Producción | Producción |
| Experimentos | Producción |
Usar nombres de dominio neutros para las organizaciones
Las organizaciones se identifican mediante un nombre de dominio DNS, como example.com. El nombre de dominio se deriva del nombre de dominio principal de la cuenta de Cloud Identity o Google Workspace asociada.
Si hay un nombre de dominio DNS canónico que se usa en toda tu empresa, utiliza ese dominio como dominio principal en tu cuenta de producción de Cloud Identity o Google Workspace. Al usar el nombre de DNS canónico, te aseguras de que los empleados puedan reconocer fácilmente el nombre del nodo de la organización.
Si tu empresa tiene varias filiales o es propietaria de varias marcas diferentes, es posible que no haya un nombre de dominio canónico. En lugar de elegir uno de los dominios existentes de forma arbitraria, te recomendamos que registres un nuevo dominio DNS que sea neutral y esté dedicado al uso de Google Cloud. Al usar un nombre de DNS neutro, evitas expresar una preferencia por una marca, una filial o un departamento específicos de tu empresa, lo que podría afectar negativamente a la adopción de la nube. Añade tus otros dominios específicos de marca como dominios secundarios para que se puedan usar en los IDs de usuario y para el inicio de sesión único.
Usar cuentas de facturación en varias organizaciones Google Cloud
Las cuentas de facturación definen quién paga un conjunto determinado de Google Cloud recursos. Aunque las cuentas de facturación pueden estar fuera de una organización, lo más habitual es que estén asociadas a una. Google Cloud
Cuando las cuentas de facturación se asocian a una organización, se consideran un subrecurso de la organización y están sujetas a las políticas de gestión de identidades y accesos definidas en la organización. Lo más importante es que puedes usar los roles de gestión de identidades y accesos de facturación para definir qué usuarios o grupos pueden administrar o usar una cuenta.
Un usuario al que se le haya concedido el rol Billing Account User puede vincular un proyecto a una cuenta de facturación, lo que hará que los recursos se facturen a esta cuenta.
Puedes vincular un proyecto a una cuenta de facturación dentro de la misma organización, pero también entre organizaciones.
Si utilizas varias organizaciones, puedes aprovechar que las cuentas de facturación se pueden usar en varias organizaciones. De esta forma, puedes decidir cuántas cuentas de facturación necesitas, independientemente del número de organizaciones.
El número adecuado de cuentas de facturación depende exclusivamente de tus requisitos comerciales o contractuales, como la moneda, el perfil de pagos y el número de facturas independientes que necesites. Al igual que con las cuentas y las organizaciones, para minimizar la complejidad, debes usar el menor número de cuentas de facturación que cumpla tus requisitos.
Para desglosar los costes acumulados en varias organizaciones, configure su cuenta de facturación para exportar los datos de facturación a BigQuery.
Cada registro exportado a BigQuery no solo contiene el nombre y el ID del proyecto, sino también el ID de la organización a la que está asociado el proyecto (en el campo project.ancestry_numbers).
Siguientes pasos
- Crear una cuenta de Cloud Identity
- Consulta cómo Google Cloud te permite autenticar a los usuarios corporativos en un entorno híbrido y patrones comunes.
- Consulta las prácticas recomendadas para federar Google Cloud con un proveedor de identidades externo.
- Consulta cómo federar Google Cloud con Active Directory o Microsoft Entra ID.