Leer una política de control de servicio

Una política de control de servicio no da permisos a nadie. Fija el máximo de lo que los usuarios y roles de una cuenta miembro pueden llegar a hacer. Para que una acción ocurra tienen que cumplirse dos cosas a la vez: que la política de identidad del rol la permita, y que ninguna política de control de servicio del camino la bloquee. El resultado es la intersección de las dos.

Además, una denegación explícita en cualquier nivel —raíz, unidad o cuenta— gana a todo lo demás. Y para que algo se permita tiene que haber un permiso explícito en cada nivel del camino: por eso AWS adjunta por defecto una política que permite todo, y por eso retirarla sin sustituirla deja a las cuentas sin poder hacer nada.

Abre BRG-solo-regiones-autorizadas.json en la carpeta de políticas. Dice: deniega todo, salvo unos servicios globales que deja fuera con NotAction, cuando la región pedida no sea una de las dos de la lista. Se lee así: dentro de las regiones autorizadas no cambia nada; fuera de ellas, se deniega.

Esa política está adjunta a una unidad concreta. Lee el árbol para saber a cuál, y luego recorre las acciones de prueba buscando la que pide una región fuera de la lista en una cuenta de esa unidad.

BRG-proteger-registro.json impide apagar y borrar el registro de auditoría. Es de las barandillas más valiosas, porque quien abusa de una cuenta empieza por apagar la cámara. Pero una política escrita no es una política aplicada: el árbol dice en qué unidad está adjunta, y solo protege a las cuentas que cuelgan de ahí.

Cruza el árbol con las acciones de prueba. Busca la acción que apaga el registro en una cuenta que esa política no alcanza.

Una acción puede fallar sin que la política de control de servicio tenga nada que ver. La última acción de la lista pide crear un usuario de identidad desde un rol de lectura, y el rol no tiene ese permiso en su política de identidad. Fallará, pero por la política del rol, no por la barandilla. Confundir las dos causas lleva a arreglar lo que no está roto: quien ve que la acción falla y concluye «la barandilla funciona» acaba dando por protegida una cuenta que no lo está.

Lee la columna del permiso en identidad de la acción AC-09 y la política adjunta a su unidad.

Hay dos estrategias para escribir barandillas. La de lista de denegados deja todo permitido y va prohibiendo lo concreto. La de lista de permitidos retira la política por defecto y nombra solo lo que se puede usar; todo lo demás queda denegado sin decirlo. La segunda es más estricta y se rompe con facilidad cuando aparece un servicio nuevo que nadie había listado.

En una unidad de Brasero se hizo así. Lee el árbol y busca cuál es esa unidad y qué política sustituye a la de por defecto.