Lógica de evaluación de políticas IAM explicada - Cómo la denegación implícita pierde ante la autorización explícita
Una explicación paso a paso de cómo IAM evalúa las solicitudes para permitirlas o denegarlas, cubriendo la prioridad de denegación implícita, autorización explícita y denegación explícita, así como la lógica de intersección para SCPs, límites de permisos y políticas de sesión.
La evaluación IAM produce solo tres resultados
La evaluación de políticas IAM puede parecer compleja, pero el resultado final es siempre uno de tres: denegación explícita, autorización explícita o denegación implícita. La prioridad es siempre: denegación explícita > autorización explícita > denegación implícita. La denegación implícita es el estado predeterminado: si ninguna política otorga explícitamente un permiso, la solicitud se deniega. Una autorización explícita (Effect: Allow) anula la denegación implícita. Una denegación explícita (Effect: Deny) anula cualquier autorización explícita. Esta jerarquía simple es la base de toda la evaluación de políticas IAM.
Flujo de evaluación dentro de una sola cuenta
La evaluación de políticas dentro de una sola cuenta es un proceso de múltiples etapas que evalúa varios tipos de políticas en secuencia. Primero, se evalúan las SCPs (Service Control Policies) de Organizations. Las SCPs actúan como un "techo" de permisos para toda la cuenta: incluso si una política de identidad otorga un permiso, si la SCP no lo permite, la solicitud se deniega. Luego se evalúan los límites de permisos (permission boundaries), que establecen el máximo de permisos para un usuario o rol IAM específico. Finalmente, se evalúan las políticas basadas en identidad (gestionadas y en línea) y las políticas basadas en recursos. El permiso efectivo es la intersección de todas estas capas. Para una comprensión más profunda de la evaluación de políticas IAM, consulta libros relacionados en Amazon.
Lógica de intersección de SCPs y límites de permisos
Tanto las SCPs como los límites de permisos establecen un "límite superior" de permisos, pero se aplican a diferentes niveles. Las SCPs se aplican a nivel de cuenta de Organizations, mientras que los límites de permisos se aplican a nivel de usuario/rol IAM individual. El permiso efectivo es la intersección de ambos: un permiso debe estar permitido tanto por la SCP como por el límite de permisos para ser efectivo. Si la SCP permite las acciones A, B, C y el límite de permisos permite B, C, D, el permiso efectivo es solo B y C. Las políticas de sesión (pasadas al asumir un rol con AssumeRole) agregan otra capa de intersección, restringiendo aún más los permisos de la sesión.
Evaluación de claves de condición - Errores comúnmente pasados por alto
El bloque Condition en las políticas IAM es una función poderosa que controla el acceso basándose en atributos de la solicitud (IP de origen, hora de solicitud, valores de etiquetas, etc.), pero hay trampas en la lógica de evaluación. Cuando una clave de condición no está presente en la solicitud, el comportamiento depende del operador: StringEquals falla (deniega), StringNotEquals tiene éxito (permite), y Null puede verificar explícitamente la presencia/ausencia de una clave. Las condiciones con múltiples valores usan lógica AND entre diferentes claves y lógica OR entre múltiples valores de la misma clave. El operador ForAllValues requiere que todos los valores de la solicitud coincidan, mientras que ForAnyValue requiere que al menos uno coincida.
Reglas de evaluación de acceso entre cuentas
Las reglas de evaluación de acceso entre cuentas difieren de las de una sola cuenta. Cuando un principal en la Cuenta A accede a un recurso en la Cuenta B, tanto la política basada en identidad en la Cuenta A como la política basada en recursos en la Cuenta B deben permitir explícitamente el acceso. Esto es diferente del acceso dentro de la misma cuenta, donde una política basada en recursos puede otorgar acceso independientemente de la política de identidad. La excepción es cuando la política basada en recursos especifica el principal exacto (no una cuenta completa): en ese caso, la política basada en recursos sola es suficiente. Las SCPs de ambas cuentas también deben permitir la acción para que el acceso entre cuentas tenga éxito.