Permisos efectivos frente a permisos escritos

En AWS la decisión de una solicitud sale de combinar varias capas: las políticas de identidad, los límites de permisos, las políticas de control de servicios (SCP) de la organización y las de recursos. La regla que ordena todo es simple: todo está denegado por defecto, un permiso explícito lo habilita y una denegación explícita en cualquiera de las capas gana siempre a cualquier permiso.

Por eso una política de identidad que dice «permitir» no es una garantía: puede existir, más arriba, una denegación que la anule.

Una simulación de políticas devuelve, por cada acción, la decisión y la capa que la causó. Esa columna del motivo es lo más útil para el auditor: dice dónde actuar si la decisión es incorrecta. Una SCP se escribe con sentencias identificadas por un Sid.

La usuaria m.rincon tiene escrito el permiso de borrar objetos, pero la simulación lo muestra denegado. Cruza simulacion-m.rincon.txt con scp-organizacion.json.

La política de m.rincon escribe doce acciones, todas con «permitir». La simulación dice cuáles terminan permitidas después de aplicar la SCP y el límite de permisos. La diferencia entre lo escrito y lo efectivo es el hallazgo: quien lea solo la política creerá que la usuaria puede hacer doce cosas.

Cuenta en simulacion-m.rincon.txt cuántas de las doce acciones quedan realmente permitidas.

En Azure las asignaciones se heredan hacia abajo: lo que se asigna a un grupo de administración rige sobre sus suscripciones, y lo de una suscripción sobre sus grupos de recursos. Mirar solo las asignaciones hechas sobre un grupo de recursos deja fuera lo que llega de arriba. La persona a.suarez figura con lectura en el grupo de recursos de curtido, pero eso no es todo.

Usa jerarquia.txt para saber qué cuelga de qué y asignaciones-a.suarez.txt para ver qué tiene asignado. Busca el alcance que le da escritura sobre ese grupo de recursos.

En Google Cloud los permisos concedidos (allow) también se heredan de la organización a las carpetas, de las carpetas a los proyectos y de los proyectos a los recursos, y se suman: una concesión más abajo no quita la de arriba. Para que algo deje de aplicar hay que quitar la concesión donde se hizo, o usar una política de denegación.

En herencia.txt el grupo de contratistas tiene Editor en producción, pero el proyecto no muestra esa vinculación.