¿Es seguro otorgar el rol Editor si nadie tiene Owner?

No del todo. Editor es uno de los tres roles básicos, y Google dice que los roles básicos incluyen miles de permisos en todos los servicios y que conviene evitarlos en producción salvo que no exista otra opción. Quitar Owner y dejar Editor mueve el problema muy poco. Otorga el rol predefinido más limitado que cubra el trabajo, y usa las recomendaciones de roles para saber cuál es.

¿Hay que borrar todas las llaves de cuentas de servicio?

No, pero cada llave que conserves debería ser una decisión que puedas explicar. El código que corre dentro de Google Cloud debe usar la cuenta de servicio asociada a su recurso, el que corre fuera debe usar Workload Identity Federation, y las personas deben suplantar la cuenta de servicio en lugar de guardar su llave. Si una herramienta vieja de verdad necesita una llave, dale un responsable, una fecha de rotación y un gestor de secretos, y a la cuenta de servicio detrás, el rol más angosto que funcione.

Somos solo 10 personas. ¿Vale la pena una revisión de accesos?

El tamaño del equipo no define el alcance de un incidente; los permisos sí. Diez personas con Owner sobre un proyecto que guarda datos de clientes exponen más que cincuenta con roles angostos. Además el trabajo es más pequeño hoy que nunca, y los grupos y políticas que dejes ahora siguen aplicando a medida que contratas.

IAM de Google Cloud para pymes: los roles que sí otorgamos

Imagina una agencia de marketing de 10 personas con un solo proyecto en Google Cloud. Lo montaron dos personas, una se fue en marzo, y todo el que tuvo que desplegar con prisa terminó agregado como Owner, porque el sitio estaba caído y esa era la casilla más rápida de marcar. Hay cuatro cuentas de servicio, tres con un archivo JSON de llave en alguna parte, y uno de esos archivos está en un hilo de chat del año pasado.

Nada de eso es descuido. Es lo que pasa cuando un equipo crece y nadie tiene los accesos como responsabilidad propia. El riesgo no es la mala fe, es que una laptop prestada, un archivo de llave filtrado o la cuenta de un contratista que nadie cerró alcanzan para llegar a todo, porque todo se otorgó de un golpe. Abajo está la auditoría que hacemos en un entorno chico de Google Cloud y los roles que sí otorgamos al terminar. Cada afirmación viene de la documentación de IAM de Google, revisada el 13 de octubre de 2026.

Por qué los roles básicos son el problema de fondo

Google Cloud tiene tres roles básicos: Owner (roles/owner), Editor (roles/editor) y Viewer (roles/viewer). Son anteriores a IAM y son gruesos a propósito. La guía de Google sobre usar IAM de forma segura dice que los roles básicos incluyen miles de permisos en todos los servicios, y que los entornos de producción deberían evitarlos salvo que no exista otra opción. El reemplazo recomendado es el rol predefinido más limitado que cubra la necesidad, o un rol personalizado cuando ningún predefinido calza.

Editor es el que se cuela, repartido como "no es Owner, así que está bien". Pertenece a la misma familia que Google pide dejar fuera de producción, y en una empresa de 10 personas suele significar que cualquier ingeniero puede cambiar cualquier recurso del proyecto.

Vamos primero a los roles predefinidos y después a los personalizados. La razón está en la nota de Google sobre cómo elegir el tipo de rol: los personalizados no los mantiene Google, así que no adoptan permisos nuevos de forma automática cuando un servicio agrega una función. Uno que escribiste en 2024 puede dejar de cubrir en silencio aquello para lo que se escribió.

La auditoría que hacemos primero

Antes de cambiar nada, dejamos por escrito lo que de verdad está otorgado. Seis preguntas, en este orden:

Quién tiene un rol básico y en qué nivel. Un permiso otorgado a nivel de organización o de carpeta se hereda en todo lo que está debajo, así que un Owner arriba es Owner en cada proyecto, incluidos los que se creen el año que viene.
Cuáles de esos principales son cuentas de servicio. Una cuenta de servicio con Editor tiene el mismo alcance que una persona con Editor, pero sin nadie que note que está mal.
Qué cuentas de servicio tienen llaves administradas por el usuario y de qué fecha. Cada llave es una credencial que vive fuera de Google Cloud y nunca caduca sola.
Quién no usa lo que tiene. El recomendador de roles de Google compara la cantidad total de permisos de un principal con los permisos que ese principal usó de verdad en los últimos 90 días, y sugiere quitar o reemplazar el excedente.
Si un proyecto puede alcanzar a otro. Algunas recomendaciones traen información de movimiento lateral, que identifica roles que permiten a una cuenta de servicio de un proyecto suplantar a otra de un proyecto distinto. En un entorno chico, así es como staging terminó tocando producción.
Si el acceso va a grupos o a direcciones individuales. Si son direcciones, la baja de personal es manual, o sea parcial.

Las recomendaciones se leen desde la consola o desde la línea de comandos:

gcloud recommender recommendations list

Cuatro Owners y tres archivos de llave es un resultado normal en un entorno chico, no uno raro.

Reemplazar Owner por roles del tamaño del trabajo

Nunca empezamos quitando un permiso. Agrega el rol de reemplazo, confirma que la persona sigue pudiendo trabajar y después quita el rol básico. Quitarle Owner a la única persona que sabe revertir un despliegue, un viernes a las 4 de la tarde, le enseña al equipo que el mínimo privilegio es algo que les hacen.

La guía de seguridad de Google apunta a dos herramientas que vuelven esto seguro. Las recomendaciones de roles proponen el rol más angosto que reemplaza al ancho. Policy Simulator muestra si un cambio propuesto afectaría el acceso que ya tiene un principal, antes de aplicarlo. Usamos las dos y después otorgamos por función, no por persona: quien despliega recibe permisos sobre ese servicio, quien lee el almacén recibe lectura sobre esos conjuntos, y no son un mismo permiso aunque sean el mismo ser humano.

Dejamos exactamente una identidad de emergencia con Owner. Es del negocio, no de un contratista ni nuestra, sus credenciales viven en el gestor de contraseñas del dueño, y el equipo sabe que existe y cuándo se usa. Una ruta de emergencia escrita evita que la próxima caída vuelva a dejar cuatro Owners.

Las llaves de cuentas de servicio y qué usamos en su lugar

Aquí está la mayor parte del riesgo real en una empresa chica. Las buenas prácticas de Google para administrar llaves de cuentas de servicio lo dicen sin rodeos: para un atacante, una llave puede valer incluso más que una contraseña filtrada. La guía de seguridad pide evitarlas si existe otra opción, y aclara que si te autenticas con una, la seguridad de la llave privada queda en tus manos.

Para casi todo lo que corre una empresa de 10 personas, esa otra opción existe:

Código que corre dentro de Google Cloud usa la cuenta de servicio asociada a su recurso. Un servicio de Cloud Run, una VM de Compute Engine o una Cloud Function se autentican con su propia identidad, sin archivo de llave. Para una app interna eso es el valor por omisión que quieres, no una mejora: los ajustes alrededor están en nuestra nota sobre una app interna en Cloud Run para un equipo pequeño.
Código que corre fuera de Google Cloud usa Workload Identity Federation. Las credenciales de tu proveedor de identidad externo se intercambian por tokens de corta duración que permiten a la carga de trabajo suplantar una cuenta de servicio, y eso es lo que elimina la necesidad de una llave. Un pipeline de CI en otro proveedor es el caso típico.
Las personas que necesitan el acceso de una cuenta de servicio la suplantan. La documentación de Google describe las credenciales de corta duración como credenciales que viven unas pocas horas o menos, que no se renuevan automáticamente, y que implican menos riesgo que las credenciales de larga duración como las llaves. El rol que permite emitirlas es Service Account Token Creator, otorgado sobre la cuenta de servicio destino, y es también el que exige la bandera de suplantación de gcloud.

roles/iam.serviceAccountTokenCreator    otorgado sobre la cuenta de servicio DESTINO
gcloud ... --impersonate-service-account=CUENTA_DESTINO

Fíjate dónde va ese rol: sobre la cuenta de servicio que se suplanta, no sobre el proyecto. El token que regresa no trae renovación, así que al expirar quien llama repite la suplantación. Esa expiración es la ventaja. Un archivo de llave no tiene ninguna, y por eso le sigue funcionando a quien lo encontró.

Unas pocas herramientas viejas sí necesitan una llave. Entonces recibe un responsable con nombre, una fecha de rotación, un lugar en un gestor de secretos y el rol más angosto que encontremos sobre la cuenta detrás. Una excepción documentada es una decisión; tres archivos de llave sin documentar son un problema con fecha pendiente.

Conectar los grupos de Workspace con el acceso en Cloud

Si ya usas Google Workspace, la lista de grupos de tu consola de administración es el control de acceso más limpio que tienes, y casi ningún equipo chico la conecta con Google Cloud. Las buenas prácticas de Google para usar Grupos de Google describen justo eso: grupos que administran el acceso a recursos de Google Cloud con IAM, con tipos distintos para estructura, colaboración, acceso y aplicación de políticas, y una convención de nombres para que el propósito se vea en el nombre. Los grupos de acceso toman la forma access.FUNCION.

access.cloudrun-deployers@ejemplo.com
access.bigquery-readers@ejemplo.com
access.billing-viewers@ejemplo.com

Los roles se otorgan a esos grupos y a nada más. Desde ahí, los cambios de acceso son cambios de membresía: alguien que entra se suma a dos grupos su primer día y los pierde el último, sin tocar ninguna política de IAM. También vuelve legible la lista para quien no es ingeniero, que importa cuando quien aprueba es la dueña del negocio. Nuestra nota sobre permisos y control de acceso en Grupos de Google cubre cómo configurar los grupos.

Una advertencia honesta de la misma página de Google: cuando los grupos se sincronizan desde un proveedor de identidad externo, puede haber un retraso entre el cambio en ese proveedor y su llegada a Cloud Identity. Así que quitar a alguien de un grupo no es, por sí solo, un plan de baja. Suspende también la cuenta, que es el primer paso de nuestra lista de baja de personal en Google Workspace.

Qué activamos para que no se desarme otra vez

Apretar los accesos una vez es limpieza. Mantenerlos apretados es política. Dos restricciones de política de organización hacen casi todo ese trabajo:

iam.managed.disableServiceAccountKeyCreation
iam.managed.disableServiceAccountKeyUpload

La primera desactiva la creación de llaves externas nuevas para todas las cuentas de servicio bajo un proyecto, una carpeta o una organización. La segunda bloquea la carga de llaves públicas externas a cuentas de servicio. Google lista ambas entre las restricciones de línea base de seguridad que se aplican de forma automática cuando se crea un recurso de organización nuevo, así que si tu organización es reciente, revisa antes de asumir que hay que agregarlas.

El orden también importa. La guía de Google es ofrecer alternativas antes de restringir las llaves, y permitir excepciones solo a los proyectos que demuestren que no pueden usar un método más seguro. Si aplicas la restricción a un equipo que no tiene a dónde ir, recibes una solicitud de excepción que nunca se cierra, o una llave creada en un proyecto personal.

Qué vigilar en los primeros 90 días

Espera un periodo callado. La ventana de observación del recomendador llega a un máximo de 90 días, y por omisión espera 90 días antes de producir recomendaciones, aunque a nivel de proyecto se puede configurar en 30 o 60 días. Un proyecto que apretaste la semana pasada todavía no tiene mucho que decir, así que pon una fecha en el calendario en lugar de esperar un recordatorio.

Revisa tres cosas en esa fecha. Si volvió algún rol básico y a raíz de qué. Si apareció alguna llave nueva. Si las recomendaciones se callaron, que es la señal de que lo otorgado y lo usado por fin coinciden. Si alguien volvió a dar Owner para salir de un incidente, al rol angosto le faltaba un permiso: búscalo y agrega ese.

Cómo ayuda Guanacos Tech

Hacemos esto como un trabajo cerrado: inventariar permisos, cuentas de servicio y llaves, proponer los roles de reemplazo función por función, conectar tus grupos de Workspace con el acceso en Cloud y entregarte una lista que la dueña del negocio puede leer sin traductor. La ruta de emergencia también queda escrita, porque una revisión que solo entendemos nosotros no mejoró nada.

Si quieres que los accesos de tus proyectos en Google Cloud coincidan con quién trabaja de verdad en tu empresa, eso es consultoría de Google Cloud. Agenda una llamada de 30 minutos y te decimos qué roles básicos y qué archivos de llave quitaríamos primero, y en qué orden.

IAM de mínimo privilegio para una empresa de 10 personas en Google Cloud: los roles que sí otorgamos