Jerarquía y herencia de permisos

Una política de acceso se puede fijar en la organización, en una carpeta, en un proyecto o en un recurso concreto. La política efectiva de un recurso es la suma de la suya y de todas las de sus ancestros: los permisos se acumulan hacia abajo.

La consecuencia en un incidente es práctica: si el rol se concedió en la carpeta, quitarlo en el proyecto no tiene efecto sobre ese vínculo, y solo se corta cambiando la carpeta (o con una política de denegación que lo anule, si la organización las usa). Antes de dar por cerrado un acceso hay que revisar todos los niveles por encima.

Para saber qué se hereda hay que subir por el árbol desde el proyecto hasta la organización. La tabla de jerarquía da, para cada recurso, su padre. El nombre de una carpeta aparece con el prefijo folders/.

Con la carpeta identificada, se miran los vínculos de esa carpeta. Un vínculo une un rol con un miembro (una persona, un grupo o una cuenta de servicio). Un rol básico como roles/editor incluye permisos para crear y modificar recursos en casi todos los servicios, y por eso se usa en pocos sitios.

Un vínculo en una carpeta alcanza a todos sus descendientes, incluidas las subcarpetas y los proyectos que cuelgan de ellas. Delimitar el alcance del acceso es parte de la contención: no basta con el proyecto del aviso.

Cuenta los proyectos que están dentro de esa carpeta, directamente o dentro de una subcarpeta. Los proyectos de otras ramas no cuentan.

Los cambios de política quedan en Admin Activity con el método SetIamPolicy, el recurso al que se aplicó y el cambio. Esa fila responde a quién lo concedió y cuándo, y también al nivel: no es lo mismo una concesión en el proyecto que en la carpeta. Saber quién lo concedió no es acusar: es el primer dato para preguntarle por qué.