En este documento, se presentan las prácticas recomendadas para decidir cuántas cuentas de facturación, organizaciones de Google Cloud y cuentas de Cloud Identity o Google Workspace necesitarás. En el documento, se proporciona orientación sobre cómo identificar un diseño que satisfaga los requisitos de seguridad y organización.
En Google Cloud, la administració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 clave para autenticar a los usuarios corporativos y administrar el acceso a los recursos de Google Cloud. Una cuenta de Cloud Identity o de Google Workspace indica un directorio de usuarios, no una cuenta de usuario individual. Las cuentas de usuario individuales se denominan usuarios o cuentas de usuario.
Las organizaciones son contenedores para proyectos y recursos dentro de Google Cloud. Las organizaciones permiten estructurar los recursos de forma jerárquica y son clave para administrar los recursos de manera centralizada y eficiente.
Este documento está destinado principalmente a los clientes que configuran los entornos empresariales.
Cuentas de Cloud Identity y Google Workspace
Google Workspace es un conjunto integrado de apps de productividad y colaboración nativas de la nube. Incluye herramientas que te permiten administrar usuarios, grupos y la autenticación.
Cloud Identity proporciona un subconjunto de las características de Google Workspace. Al igual que Google Workspace, Cloud Identity te permite administrar 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 API y herramientas administrativas. Los productos comparten el concepto de una cuenta como contenedor para usuarios y grupos. Este contenedor se identifica con un nombre de dominio, como example.com. En lo que respecta a la administración de usuarios, grupos y la autenticación, los dos productos se pueden considerar equivalentes.
Combina Cloud Identity y Google Workspace en una sola cuenta.
Debido a que 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 permitir que más usuarios usen Google Cloud, es posible que no quieras asignar a todos los usuarios una licencia de Google Workspace. En este caso, agrega Cloud Identity Free a la cuenta existente. Luego, puedes incorporar más usuarios sin cargo adicional y decidir qué usuarios deben tener acceso a Google Workspace mediante la asignación de una licencia de Google Workspace.
Del mismo modo, si ya administras una cuenta gratuita o Premium de Cloud Identity, puede que desees otorgar a ciertos usuarios el derecho de usar Google Workspace. En lugar de crear cuentas de Google Workspace independientes para esos usuarios, puedes agregar Google Workspace a una cuenta de Cloud Identity existente. Después de asignar la licencia de Google Workspace a esos usuarios seleccionados, pueden usar las apps de productividad y colaboración.
Usa la menor cantidad de cuentas posible, pero tantas como sea necesario
Para permitir que tus usuarios colaboren con Google Workspace y minimizar las sobrecargas administrativas, es mejor administrar a todos los usuarios a través de una sola cuenta de Cloud Identity o una cuenta de Google Workspace y proporcionar una cuenta de usuario única a cada persona. Este enfoque ayuda a garantizar que la configuración, como las políticas de contraseñas, el inicio de sesión único y la verificación en dos pasos se apliquen de manera coherente a todos los usuarios.
A pesar de estos beneficios de usar una sola cuenta de Cloud Identity o de Google Workspace, puedes obtener flexibilidad y automatización administrativa mediante varias cuentas. Cuando decidas cuántas cuentas de Cloud Identity o Google Workspace usar, ten en cuenta todos los requisitos que sugieren el uso de varias cuentas. Luego, usa la menor cantidad de cuentas de Cloud Identity o Google Workspace para satisfacer tus requisitos.
Usa cuentas separadas para la etapa de pruebas y la producción
Para la mayoría de las opciones de configuración que puedes configurar en Cloud Identity y Google Workspace, puedes elegir el alcance en el que se debe aplicar cada configuración. Por ejemplo, puedes especificar la ubicación geográfica para tus datos por usuario, por grupo o por unidad organizativa. Cuando planeas aplicar una configuración nueva, puedes elegir un permiso pequeño al principio (por ejemplo, por usuario) y verificar si la configuración cumple con tus expectativas. Una vez que lo hayas verificado, podrás aplicar la misma configuración a un conjunto más grande de grupos o unidades organizacionales.
A diferencia de la mayoría de las configuraciones, la integración de una cuenta de Cloud Identity o G Suite en un proveedor de identidad externo (IdP) tiene un impacto global:
- Habilitar el inicio de sesión único es una configuración global que se aplica a todos los usuarios que no sean administradores avanzados.
- Según el IdP 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 hacer que los usuarios se modifiquen, se suspendan o, incluso, se borren por accidente.
Para mitigar estos riesgos, ten cuentas separadas de etapa de pruebas y producción de Cloud Identity o Google Workspace:
- Usa la cuenta de etapa de pruebas para verificar cualquier cambio riesgoso de la configuración antes de aplicar el mismo cambio a la cuenta de producción.
- Crea algunos usuarios de prueba en las cuentas de etapa de pruebas que tú y otros administradores puedan usar para verificar los cambios de la configuración. Pero no le otorgues a los usuarios acceso a la cuenta de etapa de pruebas.
Si tienes instancias de etapa de pruebas y de producción independientes del IdP externo, sigue estos pasos:
- Integra tu cuenta de etapa de pruebas de Cloud Identity o Google Workspace con tu instancia de IdP de etapa de pruebas.
- Integra tu cuenta de producción de Cloud Identity o Google Workspace con tu instancia del IdP de producción.
Por ejemplo, supongamos que planeas configurar la federación con Active Directory y tener un bosque de Active Directory distinto para fines de prueba. En este caso, integrarás tu cuenta de etapa de pruebas de Cloud Identity o Google Workspace, en el bosque de pruebas, y la cuenta de producción de Cloud Identity o Google Workspace con tu bosque principal. Aplica el mismo enfoque de asignación para dominios DNS, usuarios y grupos a ambos pares de bosque y cuenta, como se muestra en el siguiente diagrama:
Los bosques y dominios de Active Directory de producción y etapa de pruebas pueden usar dominios DNS que no te permiten aplicar el mismo enfoque de asignación de dominios para la etapa de pruebas y de producción. En este caso, considera registrar más dominios de sufijo de nombre principal de usuario (UPN) en el bosque de etapa de pruebas.
Del mismo modo, si planeas configurar la federación con Azure Active Directory, es mejor adoptar el siguiente enfoque:
- Integra la cuenta de etapa de pruebas de Cloud Identity o Google Workspace con un usuario de etapa de pruebas de Azure Active Directory.
- Integra la cuenta de producción de Cloud Identity o Google Workspace con tu usuario de Azure Active Directory.
Aplica el mismo enfoque de asignación para dominios DNS, usuarios y grupos a ambos pares de cuenta y usuario:
Los usuarios de producción y etapa de pruebas de Azure Active Directory pueden usar dominios DNS que no te permiten aplicar el mismo enfoque de asignación de dominios para la etapa de pruebas y de producción. En este caso, considera agregar un dominio adicional al usuario de etapa de pruebas.
Usa dominios DNS separados entre las cuentras de Cloud Identity y Google Workspace.
Cuando agregas un dominio, como example.com, a tu cuenta de Cloud Identity o Google Workspace, debes verificar que eres el propietario del dominio.
Después de agregar y verificar un dominio, puedes agregar subdominios como marketing.example.com y finance.example.com sin necesidad de verificar cada subdominio de forma individual.
Sin embargo, si agregas subdominios sin verificar cada uno, los conflictos pueden resultar si tienes otra cuenta de Cloud Identity o de Google Workspace que ya usa este subdominio. A fin de evitar estos conflictos, es preferible usar dominios inconexos para cada cuenta. Por ejemplo, si necesitas dos cuentas de Cloud Identity o de Google Workspace, intenta evitar usar dos dominios en los que un dominio 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 separa Google Workspace de Google Cloud
Si ya usas Google Workspace, a algunos usuarios de tu cuenta de Google Workspace se les podrían otorgar privilegios de administrador avanzado para que puedan realizar tareas administrativas.
Los usuarios con privilegios de administrador avanzado tienen permiso implícito para modificar la política de administración de identidades y accesos (IAM) del nodo de la organización. Este permiso permite que los administradores avanzados se asignen la función de administrador de la organización o cualquier otra función en la organización de Google Cloud. El acceso de administrador avanzado a una cuenta de Cloud Identity o de Google Workspace también permite a un usuario borrar la cuenta, su organización de Google Cloud asociada y todos sus recursos. Por lo tanto, debes suponer que los administradores avanzados tienen acceso completo a todos los recursos dentro de una organización.
Es posible que los administradores avanzados también sean administradores de la seguridad si tus administradores de Google Workspace existentes son un conjunto diferente de usuarios de los usuarios que se encargarán de administrar tu organización de Google Cloud. En este caso, es posible que decidas crear una cuenta de Cloud Identity separada dedicada a Google Cloud para limitar el acceso de los administradores avanzados de Google Workspace a los recursos de Google Cloud. Separar Google Workspace y Google Cloud puede tener varias consecuencias no deseadas.
Por ejemplo, puedes intentar crear usuarios independientes en la cuenta de Cloud Identity y, luego, restringir el acceso de los usuarios de la organización de Google Cloud a la cuenta de Cloud Identity. Esto garantizaría que la implementación de Google Cloud y Google Workspace estén aislados por completo. Sin embargo, la duplicación de usuarios afecta de manera negativa la experiencia del usuario y la sobrecarga administrativa. Además, no podrás recibir correos electrónicos de notificación que envíe Google Cloud porque el dominio que usa Cloud Identity debe ser diferente del que se usa para Google Workspace y, por lo tanto, no es adecuado a fin de enrutar correos electrónicos.
Si, en cambio, haces referencia a los usuarios de la cuenta de Google Workspace en tu organización de Google Cloud, debes socavar el aislamiento entre Google Workspace y Google Cloud:
Los administradores avanzados de Google Workspace tienen la capacidad de usar la delegación de todo el dominio para robar la identidad de cualquier usuario en la misma cuenta de Google Workspace. Un administrador avanzado fraudulento podría usar sus privilegios elevados para recuperar el acceso a Google Cloud.
Un enfoque más eficaz que el uso de cuentas separadas es segregar las responsabilidades entre Google Workspace y los administradores de Google Cloud para reducir la cantidad de administradores avanzados:
La mayoría de las tareas administrativas en Google Workspace no requieren privilegios de administrador avanzado. Usa funciones administrativas compiladas previamente o funciones de administrador personalizadas en lugar de privilegios de administrador avanzado para otorgar a los administradores de Google Workspace los permisos necesarios para cumplir con sus obligaciones.
Retén solo una cantidad mínima de usuarios administradores avanzados y desalienta el uso diario.
Aprovecha las auditorías para detectar las actividades sospechosas entre los usuarios administrativos.
Asegura el IdP externo cuando uses el inicio de sesión único
Cloud Identity y Google Workspace te permiten configurar el inicio de sesión único con tu IdP externo, como Active Directory, Azure Active Directory o Okta (para nombrar algunas). Si el inicio de sesión único está habilitado, Cloud Identity y Google Workspace confían en el IdP externo para autenticar a los usuarios en el nombre de Google.
Habilitar el inicio de sesión único tiene varias ventajas:
- Los usuarios pueden usar las credenciales existentes para acceder a los servicios de Google.
- No es necesario que los usuarios vuelvan a ingresar su contraseña si ya tienen una sesión iniciada.
- Puedes aplicar políticas de autenticación de varios factores coherentes en todas las aplicaciones y los servicios de Google.
Sin embargo, habilitar el inicio de sesión único también te expone a riesgos. Cuando el inicio de sesión único está habilitado y se debe autenticar un usuario, Cloud Identity o Google Workspace redirecciona al usuario a tu IdP externo. Después de autenticar al usuario, el IdP le muestra a Google una aserción de SAML que indica la identidad del usuario. La aserción de SAML está firmada. Por lo tanto, Google puede verificar la autenticidad de la aserción de SAML y verificar que se usó el proveedor de identidad correcto. Sin embargo, no hay forma de que Cloud Identity o Google Workspace pueda verificar que el IdP tomó la decisión de autenticación correcta y haya indicado con exactitud la identidad del usuario.
Si el inicio de sesión único está habilitado, la seguridad y la integridad general de la implementación de Google dependen de la seguridad y la integridad del IdP. Tu cuenta de Cloud Identity o Google Workspace, y todos los recursos que dependen de los usuarios administrados por ella estarán en riesgo si alguno de los siguientes elementos se configura de forma insegura:
- El IdP en sí
- Las máquinas en las que se ejecuta el proveedor
- La base de datos de usuarios de la que el proveedor obtiene información del usuario
- Cualquier otro sistema del que dependa el proveedor
Para evitar que el inicio de sesión único se convierta en un vínculo débil en tu posición de seguridad, asegúrate de que el IdP y todos los sistemas de los que depende estén configurados de forma segura:
- Limita la cantidad de usuarios con acceso de administrador al IdP o a cualquiera de los sistemas de los que depende el proveedor.
- No otorgues acceso de administrador a estos sistemas a ningún usuario al que no le darías privilegios de administrador avanzado en Cloud Identity o G Suite.
- No uses el inicio de sesión único si no estás seguro de los controles de seguridad que se implementaron para el IdP externo.
Protege el acceso a tus zonas de DNS
Las cuentas de Cloud Identity y Google Workspace, se identifican mediante un nombre de dominio DNS principal. Cuando crees una cuenta nueva de Cloud Identity o Google Workspace, deberás verificar la propiedad del dominio DNS mediante la creación de un registro DNS especial en la zona DNS correspondiente.
La importancia del DNS y el impacto en la seguridad general de la implementación de Google se extiende más allá del proceso de registro:
Google Workspace se basa en los registros MX de DNS para enrutar correos electrónicos. Mediante la modificación de estos registros MX, un atacante podría enrutar los correos electrónicos a un servidor diferente y obtener acceso a información sensible.
Si un atacante puede agregar registros a la zona DNS, es posible que pueda restablecer la contraseña de un usuario administrador avanzado y obtener acceso a la cuenta.
Para evitar que el DNS se convierta en un vínculo débil en tu posición de seguridad, asegúrate de que el servidor DNS esté configurado de forma segura:
Limita la cantidad de usuarios que tienen acceso de administrador al servidor DNS que administra el dominio principal usado para Cloud Identity o Google Workspace.
No otorgues acceso de administrador al servidor DNS a ningún usuario al que no le darías privilegios de administrador avanzado en Cloud Identity o G Suite.
Si planeas implementar una carga de trabajo en Google Cloud que tenga requisitos de seguridad que la infraestructura de DNS existente no cumple, considera registrar un dominio DNS nuevo que use servidores DNS distintos o un servicio DNS administrado para esa carga de trabajo.
Exporta registros de auditoría a BigQuery
Cloud Identity y Google Workspace mantienen varios registros de auditoría para realizar un seguimiento de los cambios de configuración y otras actividades que podrían ser relevantes para la seguridad de tu cuenta de Cloud Identity o de Google Workspace. En la siguiente tabla, se resumen estos registros de auditoría.
| Registro | Actividades capturadas |
|---|---|
| Administrador | Acciones que se realizaron en la Consola del administrador de Google |
| Acceso | Intentos exitosos, fallidos y sospechosos de acceso al dominio |
| Token | Instancias en las que se autoriza o revoca el acceso a aplicaciones web o para dispositivos móviles de terceros |
| Grupos | Cambios en los grupos y en las membresías grupales |
Puedes acceder a estos registros de auditoría a través de la Consola del administrador o la API de informes. En la mayoría de los registros de auditoría, los datos se conservan durante 6 meses.
Si operas en un sector regulado, es posible que no sea suficiente conservar los datos de auditoría durante 6 meses. A fin de conservar los datos durante un período más largo, configura los registros de auditoría para que se exporten a BigQuery.
A fin de limitar el riesgo de acceso no autorizado a los registros de auditoría exportados, usa un proyecto de Google Cloud dedicado para el conjunto de datos de BigQuery. Para proteger los datos de auditoría de la manipulación o la eliminación, otorga acceso al proyecto y al conjunto de datos con menos privilegios.
Los registros de auditoría de Cloud Identity y Google Workspace son complementarios a los registros de Cloud Audit Logging. Si también usas BigQuery para recopilar registros de auditoría de Cloud y otros registros de auditoría específicos de la aplicación, puedes correlacionar los eventos de acceso con las actividades que realizó un usuario en Google Cloud o las aplicaciones. Ser capaz de correlacionar datos de auditoría en varias fuentes puede ayudarte a detectar y analizar la actividad sospechosa.
Configura la exportación de BigQuery requiere una licencia de Google Workspace Enterprise. Después de configurar los principales registros de auditoría, se exportan para todos los usuarios, incluidos aquellos que no tienen una licencia de Google Workspace. Algunos registros, como los registros de auditoría de Drive y de dispositivos móviles, se exportan para los usuarios que tienen al menos una licencia empresarial de Google Workspace.
Si usas Cloud Identity Free para la mayoría de tus usuarios, aún puedes exportar a BigQuery con solo agregar Google Workspace Enterprise a tu cuenta de Cloud Identity y comprar licencias de Google Workspace para un conjunto seleccionado de administradores.
Organizaciones
Las organizaciones te permiten organizar los recursos en una jerarquía de proyectos y carpetas, con el nodo de la organización como raíz. Las organizaciones están asociadas con una cuenta de Cloud Identity o de Google Workspace, y derivan su nombre 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 de Google Workspace crea un primer proyecto.
Cada cuenta de Cloud Identity o Google Workspace solo puede tener una sola organización. De hecho, no es posible crear una organización sin una cuenta correspondiente. A pesar de esta dependencia, puedes otorgar a los usuarios de varias cuentas distintas acceso a recursos en una sola organización:
La flexibilidad para hacer referencia a los usuarios de diferentes cuentas de Cloud Identity o Google Workspace te permite separar la forma de tratar las cuentas y las organizaciones. Puedes separar la decisión de cuántas cuentas de Cloud Identity o de Google Workspace necesitas para administrar a tus usuarios de la decisión de cuántas organizaciones necesitas para administrar tus recursos.
La cantidad de organizaciones que creas y sus fines pueden tener un impacto profundo en la posición de seguridad, la autonomía de los equipos y departamentos, y la coherencia y la eficiencia de la administración.
En las siguientes secciones, se describen las prácticas recomendadas para decidir cuántas organizaciones usar.
Usa la menor cantidad de organizaciones posible, pero tantas como sea necesario
La jerarquía de recursos de una organización te permite reducir el esfuerzo de administrar políticas de IAM mediante el aprovechamiento de la herencia. Cuando configuras políticas a nivel de carpeta o de organización, te aseguras de que las políticas se apliquen de manera coherente en una subjerarquía de recursos y evitas el trabajo de configuración repetitivo. Para minimizar la sobrecarga administrativa, es mejor usar la menor cantidad de organizaciones posible.
Por el contrario, puedes obtener flexibilidad y autonomía administrativa adicional si usas varias organizaciones. En las siguientes secciones, se describe cuándo es posible que necesites mayor flexibilidad o autonomía.
En cualquier caso, cuando decidas cuántas organizaciones usar, ten en cuenta todos los requisitos que sugieren usar varias organizaciones. Luego, usa la menor cantidad de organizaciones que satisfaga tus requisitos.
Usa organizaciones para definir la autoridad administrativa
Dentro de una jerarquía de recursos, puedes otorgar permisos a nivel de recurso, proyecto o carpeta. El último nivel en el que puedes otorgar permisos del usuario es la organización.
Un usuario al que se le asignó la función de administrador de la organización a nivel de la organización tiene control total sobre la organización, los recursos y las políticas de IAM. Un administrador de la organización puede tomar el control de cualquier recurso dentro de la organización y es libre de 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, lo que la convierte en el máximo permiso de la autoridad administrativa:
- Un administrador de la organización no puede acceder a ningún recurso en otras organizaciones, a menos que se le otorgue permiso de forma explícita.
- Ningún usuario ajeno a la organización puede quitarle el control a un administrador de esa organización.
La cantidad correcta de organizaciones que se deben usar depende de la cantidad de grupos de usuarios administrativos independientes de la empresa:
- Si la empresa está organizada por función, es posible que tengas un solo departamento a cargo de supervisar todas las implementaciones de Google Cloud.
- Si la empresa está organizada por división o posee varias filiales administradas de manera autónoma, es posible que no haya un solo departamento a cargo.
Si un solo departamento está a cargo de supervisar las implementaciones de Google Cloud, es mejor usar un solo nodo de la organización de Google Cloud. Dentro de la organización, usa carpetas para estructurar los recursos y otorgar diferentes niveles de acceso a otros equipos y departamentos.
Si trabajas con varios departamentos independientes, intentar centralizar la administración con una sola organización puede causar inconvenientes:
- Si designas un solo departamento para que administre la organización, es posible que te enfrentes con otros departamentos.
- Si permites que varios equipos o departamentos sean copropietarios de una sola organización, puede ser difícil mantener una jerarquía de recursos coherente y garantizar que las políticas de IAM y de la organización se usen de manera coherente en todos los recursos.
Para evitar este tipo de inconvenientes, usa varias organizaciones y crea estructuras de carpetas diferentes en cada organización. Mediante el uso de organizaciones distintas, estableces límites entre grupos de usuarios administrativos diferentes, lo que define su autoridad administrativa.
Usa una organización de etapa de pruebas diferente
Para ayudar a garantizar la coherencia y evitar el trabajo de configuración repetitivo, organiza los proyectos en una jerarquía de carpetas y aplica políticas de IAM y de la organización a nivel de la carpeta o la organización.
Hay una desventaja en tener políticas que se apliquen a muchos proyectos y recursos. Cualquier cambio en la política en sí o en la jerarquía de recursos a la que se aplica la política podría tener consecuencias no deseadas y de gran alcance. Para mitigar este riesgo, lo mejor es probar los cambios en las políticas antes de aplicarlos a la organización principal.
Te recomendamos crear una organización de etapa de pruebas independiente. Esta organización te ayuda a probar los cambios en la jerarquía de recursos, las políticas de IAM, las políticas de la organización y otras configuraciones que tienen un impacto potencial en toda la organización, como los niveles de acceso y las políticas.
A fin de asegurarte de que los resultados de las pruebas o los experimentos realizados en la organización de etapa de pruebas también se apliquen a la organización de producción, configura la organización de etapa de pruebas para que use la misma estructura de carpetas de la organización principal, pero con solo una pequeña cantidad de proyectos. En cualquier momento, las políticas de IAM y de la organización en la organización de etapa de pruebas deben coincidir con las políticas de la organización de producción o reflejar la próxima versión de las políticas que deseas aplicar a la organización de producción.
Como se muestra en el siguiente diagrama, se usa tu cuenta de etapa de pruebas de Cloud Identity o Google Workspace como base para la organización de la etapa de pruebas. Usa la cuenta de etapa de pruebas (o el IdP externo con el que se integra tu cuenta de etapa de pruebas) para crear usuarios de prueba dedicados y una estructura de grupo que duplica los grupos que usas en tu cuenta de producción de Cloud Identity o Google Workspace. Luego, puedes usar estos grupos y usuarios de prueba dedicados para probar las políticas de IAM sin afectar a los usuarios existentes.
Evita usar una organización de prueba independiente
Para cada carga de trabajo de producción que planeas implementar en Google Cloud, es probable que necesites uno o más entornos de prueba, que los equipos de desarrollo y DevOps pueden usar para validar las versiones nuevas.
Desde una perspectiva de seguridad, para evitar que las versiones sin probar afecten de forma accidental las cargas de trabajo de producción, debes separar con claridad los entornos de prueba de los entornos de producción. Del mismo modo, los dos tipos de entornos tienen requisitos diferentes para las políticas de IAM. Por ejemplo, a fin de otorgar a los desarrolladores y verificadores la flexibilidad que necesitan, los requisitos de seguridad para los entornos de prueba pueden ser mucho más flexibles que los de los entornos de producción.
Como se muestra en el siguiente diagrama, desde una perspectiva de configuración, debes mantener los entornos de prueba lo más similares posible a los entornos de producción. Cualquier diferencia aumenta el riesgo de que una implementación que funcionó de manera correcta en un entorno de prueba falle cuando se implementa en un entorno de producción.
A fin de lograr un equilibrio entre mantener los entornos aislados y coherentes, usa carpetas dentro de la misma organización para administrar los entornos de prueba y de producción:
- Aplica cualquier política de IAM o de la organización que sea común en todos los entornos a nivel de la organización (o mediante el uso de una carpeta principal común).
- Usa las carpetas individuales para administrar las políticas de IAM y de la organización que difieren entre los distintos tipos de entornos.
No uses la organización de etapa de pruebas para administrar entornos de prueba. Los entornos de prueba son fundamentales para la productividad de los equipos de desarrollo y DevOps. Administrar estos entornos en el entorno de etapa de pruebas restringiría la capacidad de usar la organización de etapa de pruebas para experimentar y probar los cambios en las políticas. Cualquier cambio de este tipo podría interrumpir el trabajo de estos equipos. En resumen, si usas una organización de etapa de pruebas para administrar los entornos de prueba, comprometerás el fin de la organización de etapa de pruebas.
Usa una organización distinta para experimentar
Para aprovechar Google Cloud al máximo, permite que los equipos de desarrollo, DevOps y operaciones se familiaricen con la plataforma y expandan su experiencia mediante la ejecución de instructivos. Aliéntalos a experimentar con funciones y servicios nuevos.
Usa una organización distinta como el entorno de la zona de pruebas para admitir estos tipos de actividades experimentales. Si usas una organización distinta, puedes mantener los experimentos libres de cualquier política, configuración o automatización que uses en la organización de producción.
Evita usar la organización de etapa de pruebas para experimentar. El entorno de etapa de pruebas debe usar políticas de IAM y de la organización similares a las de la organización de producción. Por lo tanto, es probable que el entorno de etapa de pruebas esté sujeto a las mismas limitaciones que el entorno de producción. Al mismo tiempo, relajar las políticas para permitir experimentos comprometería el fin de la organización de etapa de pruebas.
Para evitar que la organización experimental se desorganice, genere un costo excesivo o se convierta en un riesgo de seguridad, establece lineamientos que definan cómo los equipos pueden usar la organización y quién asume la responsabilidad de mantenerla. Además, considera configurar la automatización para borrar de forma automática los recursos, o incluso proyectos completos, después de una cierta cantidad de días.
Como se muestra en el siguiente diagrama, cuando creas una organización para experimentar, primero debes crear una cuenta de Cloud Identity dedicada. A continuación, usa los usuarios existentes de tu cuenta principal de Cloud Identity o de Google Workspace para otorgar acceso a los usuarios a la organización experimental.
Para administrar la cuenta adicional de Cloud Identity, necesitas al menos una cuenta de usuario de administrador avanzado en la cuenta de Cloud Identity. Para obtener información sobre cómo proteger estas cuentas de usuario de administrador avanzado, consulta las Prácticas recomendadas para cuentas de administrador avanzado.
Emplea el uso compartido restringido al dominio para aplicar relaciones de confianza
Las políticas de IAM te permiten agregar cualquier identidad válida de Google como miembro. Esto significa que cuando editas la política de IAM de un recurso, un proyecto, una carpeta o una organización, puedes agregar miembros de diferentes fuentes, incluidas las siguientes:
- Los usuarios de la cuenta de Cloud Identity o Google Workspace con la que se asocia la organización y las 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 usuario, incluidas las cuentas de usuarios de
gmail.comy las personales que usan una dirección de correo electrónico corporativa
Ser capaz de hacer referencia a usuarios de fuentes diferentes es útil para situaciones y proyectos en los que necesitas colaborar con afiliados u otras empresas. En la mayoría de los casos, es mejor restringir las políticas de IAM para permitir solo miembros de fuentes de confianza.
Usa el uso compartido con restricciones de dominio para definir un conjunto de cuentas de Cloud Identity o Google Workspace confiables de los que deseas permitir que se agreguen miembros a las políticas de IAM. Define esta política organizativa a nivel de la organización (para que se aplique a todos los proyectos) o en una carpeta cerca de la parte superior de la jerarquía de recursos (a fin de permitir que ciertos proyectos estén exentos).
Si usas cuentas y organizaciones de Cloud Identity o Google Workspace independientes para separar los entornos de etapa de pruebas, producción y experimentación, usa políticas de uso compartido restringido al dominio a fin de aplicar la segregación como se muestra en la tabla siguiente:
| Organización | Cuenta de Cloud Identity o Google Workspace de confianza |
|---|---|
| Etapa de pruebas | Etapa de pruebas |
| Producción | Producción |
| Experimentos | Producción |
Usa nombres de dominio neutrales para las organizaciones
Las organizaciones se identifican con 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 utiliza en toda tu empresa, usa ese dominio como el dominio principal en tu cuenta de producción de Cloud Identity o de Google Workspace. Si usas el nombre de DNS canónico, te aseguras de que los empleados puedan reconocer con facilidad el nombre del nodo de la organización.
Si la empresa tiene varias filiales o es propietaria de una variedad de marcas diferentes, es posible que no haya un nombre de dominio canónico. En lugar de elegir de forma arbitraria uno de los dominios existentes, considera registrar un dominio DNS nuevo que sea neutral y dedicado para que lo use Google Cloud. Cuando usas un nombre de DNS neutral, evitas expresar una preferencia por una marca, una filial o un departamento específico dentro de la empresa, lo que podría afectar de manera negativa la adopción de la nube. Agrega los otros dominios específicos de la marca como dominios secundarios a fin de que puedan usarse en los ID de usuario y para el inicio de sesión único.
Usa cuentas de facturación en todas las organizaciones de Google Cloud
Las cuentas de facturación definen quién paga por un conjunto determinado de recursos de Google Cloud. Aunque las cuentas de facturación pueden existir fuera de una organización de Google Cloud, suelen estar asociadas a una organización.
Cuando las cuentas de facturación están asociadas a una organización, se consideran un subrecurso de la misma y están sujetas a las políticas de IAM que se definen dentro de ella. Sobre todo, esto significa que puedes usar las funciones de IAM de facturación para definir qué usuarios o grupos pueden administrar o usar una cuenta.
Un usuario al que se le otorgó la función Billing Account User puede vincular un proyecto a una cuenta de facturación, lo que hace que los recursos se facturen a esta cuenta.
La vinculación de un proyecto a una cuenta de facturación funciona dentro de la misma organización, pero también entre organizaciones.
Si usas varias organizaciones, puedes aprovechar el hecho de que las cuentas de facturación se pueden usarse entre ellas. Esto te permite decidir cuántas cuentas de facturación necesitas, sin importar la cantidad de organizaciones que necesites.
La cantidad correcta de cuentas de facturación depende solo de los requisitos comerciales o contractuales, como la moneda, el perfil de pagos y la cantidad de facturas distintas que necesites. Al igual que con las cuentas y las organizaciones, para minimizar la complejidad, debes usar la menor cantidad posible de cuentas de facturación que satisfaga tus requisitos.
A fin de desglosar los costos acumulados en varias organizaciones, configura la cuenta de facturación para exportar los datos de facturación a BigQuery.
Cada registro exportado a BigQuery contiene el nombre y el ID del proyecto, y el ID de la organización a la que está asociado el proyecto (en el campo project.ancestry_numbers).
¿Qué sigue?
- Crea una cuenta nueva de Cloud Identity
- Obtén más información sobre cómo Google Cloud te permite autenticar usuarios corporativos en un entorno híbrido y patrones comunes.
- Revisa las prácticas recomendadas para federar Google Cloud con un proveedor de identidad externo.
- Descubre cómo federar Google Cloud con Active Directory o Azure Active Directory.
- Revisa las prácticas recomendadas para administrar la identidad y el acceso.