Imagina una empresa de logística de 14 personas que contrata a alguien externo para construir una sola app interna en Google Cloud. Esa persona entra al proyecto en marzo, termina el trabajo y deja de facturar en junio. En octubre el dueño nos pide revisar la factura, y la primera línea de la lista de accesos del proyecto es una dirección personal de Gmail con el rol Editor sobre todo. La persona externa nunca estuvo en el Workspace de la empresa: se le otorgó un rol directo sobre el proyecto, con una cuenta que la empresa nunca pudo controlar.
De eso se trata este artículo. Workspace y Google Cloud se ven como dos productos con dos consolas, así que el acceso se otorga dos veces, y solo uno de los dos permisos se limpia cuando alguien se va.
Una cuenta, dos consolas
Google Cloud no tiene su propio directorio de usuarios. Las identidades que usa son las cuentas de Google que ya administra tu dominio de Google Workspace o de Cloud Identity, y la documentación de Google trata a los dos productos como equivalentes para administrar usuarios, grupos y autenticación.
La consecuencia práctica es que el buzón que creaste en la consola de administración ya es una entidad principal válida de Google Cloud. No lo invitas a Cloud ni le creas una segunda cuenta. Le otorgas un rol a la dirección de correo, y el inicio de sesión, la política de contraseñas, la recuperación y la verificación en dos pasos se quedan donde tus administradores ya los manejan. También desaparece el motivo por el que los equipos terminan compartiendo un solo acceso a Cloud.
Hay dos detalles que sorprenden a mucha gente. Primero, los alias: si le otorgas un rol a un alias de correo, el permiso cae en la dirección principal, que es la que aparece después en la política. Si tu equipo reparte ventas@ como alias de una persona, no lo uses en IAM. Segundo, la dirección de un grupo funciona como entidad principal exactamente igual, y eso es lo que hace que valga la pena todo lo que sigue.
El superadministrador ya es tu entidad principal más poderosa
El superadministrador que crea la organización de Google Cloud recibe el rol de Administrador de la organización de forma automática, y la recomendación de Google es delegar ese rol a otro usuario o a un grupo para separar funciones. Vale entender qué no te compra esa delegación: un superadministrador de Workspace puede modificar de forma implícita la política de permisos de IAM en el nodo de la organización, y su acceso alcanza para eliminar la cuenta y la organización con ella. Separar funciones aquí te da un registro de auditoría y una costumbre, no un candado. Esa es la verdadera razón por la que nadie debería trabajar a diario en una cuenta de superadministrador.
Los grupos son la unidad de acceso, y no todo grupo sirve
La guía de IAM de Google es clara: crea un grupo de acceso por cada función de trabajo, otórgale a ese grupo los roles que la función necesita y después administra a las personas agregando y quitando miembros. Otorgar roles a individuos uno por uno es lo que vuelve imposible una revisión de accesos, porque la única manera de describir quién llega a producción pasa a ser una lista de nombres sin un motivo atado a ninguno.
Donde se equivocan los equipos pequeños es en reutilizar los grupos que ya tienen. Las listas de distribución de uso diario, todos@, finanzas@, la que lee la bodega, son grupos de colaboración, y la página de buenas prácticas de Google dice sin rodeos que los grupos de colaboración no deben usarse para control de acceso. La membresía de una lista de correo cambia por razones que no tienen nada que ver con quién debería poder borrar una base de datos. Cuando de verdad hace falta que un grupo organizacional aparezca en el control de acceso, el patrón documentado es anidarlo dentro de un grupo de acceso y otorgar ahí solo roles limitados, como Lector de la organización.
Así, una empresa de 14 personas termina con un conjunto corto y aburrido de grupos de acceso: uno para quienes despliegan, uno para quienes leen logs y tableros, uno para quien ve la facturación y uno de emergencia. Cada uno recibe su rol en el alcance más pequeño que funcione. Mantén la edición de esos grupos en pocas manos, pero nunca en una sola, o el grupo queda sin administrar la primera vez que esa persona se va de vacaciones.
Qué revisamos primero en el proyecto de un cliente
Antes de cambiar nada queremos la respuesta de hoy a una sola pregunta: qué identidades humanas pueden llegar a qué. Cloud Asset Inventory la responde para toda la organización. La cuenta que ejecuta esto necesita cloudasset.assets.searchAllIamPolicies en el alcance que le pases.
gcloud asset search-all-iam-policies \
--scope=organizations/ORG_ID \
--query="policy:ana@example.com" \
--flatten="policy.bindings[]" \
--format="table(resource, policy.bindings.role)"Por proyecto, la política de permisos se lee más rápido directamente:
gcloud projects get-iam-policy PROJECT_ID \
--flatten="bindings[]" \
--filter="bindings.members:user:ana@example.com" \
--format="table(bindings.role)"Una advertencia sobre el segundo comando, y es la que esconde problemas: devuelve los roles otorgados en ese proyecto, no los que se heredan de una carpeta o de la organización. Un proyecto que parece limpio puede estar abierto un nivel más arriba, y por eso empezamos en el alcance de la organización.
Después contamos. Cuántas entidades principales de la política empiezan con user: y cuántas con group:. En un proyecto que nunca se ha revisado la proporción suele estar al revés, y cada entrada user: es una pregunta: ¿esta persona sigue aquí, es una cuenta que nosotros administramos, y alguien se daría cuenta si eso cambiara?
Las entradas que empiezan con deleted:
Cuando se elimina una cuenta de Google, Google Cloud no borra sus roles. La entidad principal se reescribe en la política como deleted:user:alguien@example.com?uid=... y el permiso se queda donde estaba. Si restauras la cuenta, la entrada vuelve a user: con el rol intacto. Una cuenta nueva con la misma dirección no hereda nada. Así que esas entradas no le dan acceso a nadie y sirven como historia: personas que alguna vez tuvieron un rol que nadie quitó. Límpialas con remove-iam-policy-binding, pasando la cadena deleted: completa, y ten clara la contrapartida: si quitas el permiso y después restauras la cuenta, el rol no vuelve.
Una baja que de verdad cierra la puerta
El acceso a un proyecto de Google Cloud no vive en un solo lugar, y por eso "ya lo quitamos de Workspace" y "todavía tiene acceso" pueden ser ciertos a la vez. Estos son los lugares donde hay que mirar, en el orden en que los recorremos.
| Dónde vive el acceso | Cómo lo ves | Qué lo quita de verdad |
|---|---|---|
| La cuenta de Workspace o de Cloud Identity | El usuario en la consola de administración | Suspender primero, eliminar después, ya con los datos transferidos |
| La membresía en un grupo de acceso | La lista de miembros del grupo | Quitar al miembro, o una fecha de vencimiento de membresía |
| Un rol otorgado a la persona directamente | Su dirección en la política del proyecto | Quitar ese permiso en cada recurso que lo tenga |
| Un rol otorgado a través de un alias | La dirección principal en la política | Quitar el permiso de la dirección principal |
| Una cuenta de servicio que esa persona creó | Una cuenta de servicio en el proyecto | Darle un responsable actual y desactivarla si nada la usa |
| Una cuenta que tú no administras | Una dirección personal en la política | Quitar el permiso; no controlas nada más |
El orden es a propósito. Suspender bloquea el inicio de sesión y deja los datos en su lugar, que es lo que quieres el día que alguien se va. Una cuenta suspendida se factura igual que una activa, así que si el buzón hay que conservarlo por retención, pásalo a una licencia de Usuario archivado en lugar de dejar una licencia completa estacionada. Eliminar es el paso irreversible: la consola de administración te deja restaurar un usuario eliminado hasta 20 días después (verificado el 30 de octubre de 2026), y pasado ese plazo los datos no transferidos ya no están. Transfiere la propiedad de los archivos de Drive antes de eliminar, y toma en cuenta que transferir archivos cambia al propietario sin cambiar quién más puede verlos.
La última fila es la persona externa del inicio. Una cuenta personal de Google con un rol en tu proyecto es acceso que no puedes revocar en la capa de identidad, porque la identidad no es tuya. La única palanca es el permiso. Ese es el argumento para darle a cada contratista una cuenta administrada en tu propio dominio, dentro de un grupo de acceso, por el tiempo que dure el trabajo, y asumir el costo de la licencia como el precio de cerrarlo en un solo paso.
Verificación en dos pasos, y por qué hay que revisarla dos veces
La verificación en dos pasos que despliegas desde la consola de administración es reconocida por Google Cloud, así que una cuenta a la que ya le exigiste 2SV inicia sesión en la consola de Cloud con el mismo requisito. Google Cloud además tiene su propio requisito de 2SV para la consola de Cloud y la de Firebase, con fechas de inicio que dependen del tipo de cuenta, y la documentación de Google dice de forma explícita que el requisito de Workspace es uno aparte. Las cuentas que inician sesión a través de un proveedor de identidad externo se manejan de otra forma, y las organizaciones con Cloud Identity sin SSO pueden desactivar esa exigencia a nivel de organización, algo que Google no recomienda. Lee la página del requisito para tu propio tipo de cuenta en vez de suponer que la consola de administración ya lo cubrió.
Qué dejamos puesto para que siga siendo cierto en seis meses
Un modelo de acceso bien armado una vez y nunca revisado después se convierte en una lista de gente que ya no trabaja ahí. Dos mecanismos hacen casi todo el trabajo.
Los vencimientos de membresía le ponen fecha de término a la pertenencia a un grupo, para que el acceso caduque solo. La función requiere Google Workspace Enterprise o Cloud Identity Premium (verificado el 30 de octubre de 2026) y aplica únicamente al rol de miembro: propietarios y administradores no pueden llevar vencimiento. Los propietarios del grupo reciben un correo 72 horas antes de que ocurra. La guía de buenas prácticas de Google recomienda que las membresías de los grupos de acceso venzan por defecto, con una excepción que nombra con claridad: no lo apliques a cuentas de servicio, porque sacar una cuenta de servicio de un grupo puede interrumpir lo que estaba ejecutando.
Y después, una revisión en una fecha con dueño. Lee la política en el alcance de la organización, no en el del proyecto. Busca roles otorgados durante un incidente y nunca devueltos. Busca entradas deleted: nuevas desde la última vez, porque cada una es una persona que se fue con un rol encima, y eso te dice que al proceso de baja le falta un paso.
Cómo ayuda Guanacos Tech
Lo hacemos como un trabajo cerrado: inventariar cada entidad principal humana en el alcance de la organización, armar los grupos de acceso alrededor de las funciones que la empresa de verdad tiene, mover los permisos directos a esos grupos y conectar el proceso de baja de Workspace con el lado de Cloud, para que suspender una cuenta sea lo único que alguien tenga que recordar. El resultado es una lista de accesos que el dueño del negocio puede leer sin nosotros en la sala, más el camino de emergencia escrito.
Si las personas que pueden llegar a tus proyectos de Google Cloud deberían ser las personas que hoy trabajan en tu empresa, eso es consultoría de Google Cloud. Agenda una llamada de 30 minutos y te decimos qué permisos directos y qué cuentas no administradas moveríamos primero, y en qué orden.
Fuentes
- Google Cloud: administración de identidades para Google Cloud
- IAM de Google Cloud: buenas prácticas para usar grupos de Google
- IAM de Google Cloud: cómo entender las políticas de permisos
- Google Cloud: buenas prácticas para la cuenta de superadministrador
- Cloud Asset Inventory: buscar políticas de permisos de IAM en recursos
- Cloud Identity: administrar vencimientos de membresía
- Ayuda de Google Workspace: eliminar o quitar un usuario de tu organización
- Google Cloud: requisito de verificación en dos pasos para Google Cloud