Políticas basadas en identidad frente a políticas basadas en recursos

Los permisos en AWS proceden de políticas asociadas en dos lugares: a una identidad (usuario, grupo o rol) o a un recurso (como un bucket de S3 o una clave de KMS). Saber qué tipo se aplica y cómo se combinan es esencial para el examen, ya que el acceso entre cuentas depende completamente de esta distinción.

Una política basada en identidad está asociada a un principal de IAM y define lo que dicho principal puede hacer. No tiene ningún elemento Principal porque el principal es aquel al que está asociada. Estas políticas pueden ser administradas por AWS, administradas por el cliente o insertadas en línea, y son la forma más habitual de conceder permisos.

Una política basada en recursos está asociada directamente a un recurso e incluye un elemento Principal que indica quién tiene permitido el acceso. Algunos ejemplos son las políticas de bucket de S3, las políticas de claves de KMS, las políticas de colas de SQS y las políticas de funciones de Lambda. Especifican quién (Principal) puede hacer qué (Action) en ese recurso concreto.

Esta política de bucket de S3 concede acceso de lectura a otra cuenta. Principal identifica la cuenta de confianza, algo que solo puede hacer una política basada en recursos.

Dentro de una misma cuenta, las políticas basadas en identidad y las basadas en recursos se combinan como una unión: una solicitud se permite si cualquiera de las dos la concede (y nada la deniega). Por tanto, se puede acceder a un objeto de S3 si la política del usuario lo permite o si lo permite la política del bucket. Basta con que uno de los dos lados conceda el acceso.

Para el acceso entre cuentas, la regla es más estricta: ambos lados deben permitirlo. El principal necesita una política basada en identidad que permita la acción y la política basada en recursos de la otra cuenta debe conceder acceso a ese principal. Si falta cualquiera de las dos partes, la solicitud se deniega. Esta distinción aparece con mucha frecuencia en el examen.

Las políticas de confianza de los roles son técnicamente un tipo de política basada en recursos, por lo que la asunción de un rol entre cuentas requiere tanto la política de confianza como el permiso de identidad del solicitante para sts:AssumeRole. Reconocer la política de confianza como una política basada en recursos ayuda a unificar su modelo mental sobre cómo se concede el acceso.

No todos los servicios admiten políticas basadas en recursos. Entre los principales que sí las admiten se encuentran S3, KMS, SQS, SNS, Lambda, Secrets Manager y ECR. Cuando un servicio no admite políticas de recursos, el acceso entre cuentas debe concederse mediante la asunción de un rol. El examen puede comprobar si un enfoque determinado es siquiera posible para un servicio concreto.

Utilice políticas basadas en identidad para permisos generales del tipo «este equipo puede hacer estas cosas». Utilice políticas basadas en recursos cuando deba conceder acceso a un principal externo específico, habilitar el uso compartido entre cuentas en un servicio compatible o establecer permisos que acompañen al propio recurso.

Dado que el acceso puede proceder de cualquiera de los dos lados, la auditoría requiere comprobar ambos. IAM Access Analyzer inspecciona las políticas basadas en recursos para encontrar recursos compartidos externamente o de forma pública. La simulación de políticas y los datos de último acceso ayudan a revisar el lado de la identidad. Una revisión completa nunca analiza un solo tipo.

El acceso dentro de una misma cuenta es una unión (cualquiera de las políticas puede permitirlo), mientras que el acceso entre cuentas requiere que tanto la política de identidad como la política de recursos lo permitan. Las políticas de identidad no tienen Principal; las políticas de recursos sí. Adapte el tipo de política al escenario y recuerde qué servicios admiten políticas basadas en recursos.

Ponga a prueba su razonamiento sobre los tipos de políticas.

Las políticas basadas en identidad se asocian a principales y no tienen ningún elemento Principal; las políticas basadas en recursos se asocian a recursos e indican un Principal. El acceso dentro de una misma cuenta es una unión de ambas; el acceso entre cuentas requiere que las dos lo permitan. Solo algunos servicios (S3, KMS, SQS, SNS, Lambda, Secrets Manager y ECR) admiten políticas de recursos; de lo contrario, utilice la asunción de roles.