Jerarquía de recursos y herencia de permisos

La jerarquía de recursos tiene tres niveles de agrupación. La organización es la raíz y representa a la empresa. Las carpetas agrupan proyectos por área, por entorno o por equipo, y pueden anidarse. El proyecto contiene los recursos concretos: máquinas, almacenes de archivos, conjuntos de datos, funciones.

Los permisos se conceden en una política de cada nodo: una lista de vínculos «este principal tiene este rol aquí». Lo concedido en un nodo se hereda: vale también para todo lo que cuelga de él. La herencia baja y no sube: un rol dado en un proyecto no alcanza a la carpeta ni a los proyectos vecinos.

Abre la carpeta y mira cómo está organizada la empresa.

ls jerarquia
cat jerarquia/arbol-de-recursos.txt

Para saber qué puede hacer alguien sobre un recurso hay que reunir los vínculos de todos los ancestros: el proyecto, la carpeta que lo contiene y la organización. La política de un proyecto, por sí sola, no muestra lo que el proyecto recibe de arriba, y es el error de lectura más común: «no veo a esta persona en el proyecto, entonces no tiene acceso».

Lee las políticas de cada nivel. Ana Paz administra almacenamiento en la planta; sigue el rol hasta donde está escrito.

cat jerarquia/politicas-por-nivel.txt
grep ana.paz jerarquia/politicas-por-nivel.txt

Un vínculo en una carpeta se multiplica por cada proyecto que cuelga de ella. Un grupo de mantenimiento externo con un rol de edición en la carpeta no tiene «un permiso»: tiene ese permiso en cada proyecto de la carpeta, incluso los que se creen mañana.

Cuenta los proyectos que el grupo mantenimiento-externo alcanza con su rol de Editor. Mira en qué carpeta está el vínculo y cuántos proyectos tiene esa carpeta en el árbol.

grep mantenimiento jerarquia/politicas-por-nivel.txt
cat jerarquia/arbol-de-recursos.txt

Un vínculo en la organización llega a todos los proyectos de la empresa, presentes y futuros. Por eso los roles de administración no se conceden allí salvo que el trabajo lo exija en toda la empresa. Cuando lo concedido en la raíz es de escritura o de administración, la revisión pregunta: ¿esta persona o este grupo de verdad necesita ese rol en todos los proyectos?

Lee los vínculos de la organización y busca el que concede administración de cómputo.

Un acceso que llega por herencia no se quita donde se ve el efecto, sino donde está escrito. Si Ana Paz no debe administrar almacenamiento en un proyecto concreto y su vínculo está en la carpeta, borrar «algo» en la política del proyecto no cambia nada, porque ahí no hay nada que borrar. Hay tres salidas: quitar el vínculo en la carpeta, sustituirlo por vínculos en los proyectos donde sí hace falta, o mover el proyecto a otra carpeta. Cada una cambia lo que ven los demás proyectos de esa carpeta, así que se decide con el dueño del área.