Ejemplos de políticas para delegar el acceso

En los siguientes ejemplos se muestra cómo puede permitir o conceder acceso a una Cuenta de AWS a los recursos de otra Cuenta de AWS. Para obtener información sobre cómo crear una política de IAM mediante estos documentos de políticas JSON de ejemplo, consulte Creación de políticas mediante el editor JSON.

Uso de roles para delegar el acceso a otros recursos de la Cuenta de AWS

Para ver un tutorial que muestra cómo utilizar los roles de IAM para conceder a los usuarios de una cuenta acceso a los recursos de AWS que se encuentran en otra cuenta, consulte Tutorial de IAM: delegación del acceso entre cuentas de AWS mediante roles de IAM.

importante

Puede incluir el ARN de un rol o usuario específico en el elemento Principal de una política de confianza de rol. Al guardar la política, AWS transforma el ARN a un ID exclusivo de entidad principal. Esto ayuda a mitigar el riesgo de que alguien aumente sus privilegios eliminando o volviendo a crear el rol o usuario. Normalmente este ID no se muestra en la consola, ya que también existe una transformación inversa al ARN cuando se muestra la política de confianza. Sin embargo, si elimina el rol o el usuario, la relación se desvincula. La política ya no se aplica, incluso si vuelva a crear el usuario o rol, ya que no coincide con el ID principal almacenado en la política de confianza. Cuando esto sucede, el ID principal se muestra en la consola, ya que AWS no puede volver a asignarlo a un ARN. El resultado es que si elimina y vuelve a crear un usuario o rol al que se hace referencia en un elemento Principal de la política de confianza, debe editar el rol para sustituir el ARN. Se transforma en el nuevo ID de entidad principal al guardar la política.

Uso de una política para delegar el acceso a los servicios

En el siguiente ejemplo se muestra una política que puede asociarse a un rol. La política permite que dos servicios, Amazon EMR y AWS Data Pipeline asuman el rol. Los servicios pueden realizar las tareas concedidas por la política de permisos asignada al rol (no se muestra). Para especificar varios elementos principales del servicio, no debe especificar dos elementos Service; solo puede tener uno. En cambio, utilice una gama de varios elementos principales del servicio como el valor de un único elemento Service.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": [
          "elasticmapreduce.amazonaws.com",
          "datapipeline.amazonaws.com"
        ]
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Uso de una política basada en recursos para delegar el acceso a un bucket de Amazon S3 de otra cuenta

En este ejemplo, la cuenta A utiliza una política basada en recursos (una política de bucket de Amazon S3) para conceder a la cuenta B acceso completo al bucket de S3 de la cuenta A. A continuación, la cuenta B crea una política de usuario de IAM para delegar el acceso del bucket de la cuenta A a uno de los usuarios de la cuenta B.

La política de bucket de S3 de la cuenta A podría ser como la siguiente política. En este ejemplo, el bucket de S3 de la cuenta A se llama amzn-s3-demo-bucket, mientras que el número de cuenta de la cuenta B es 111122223333. No se especifica los usuarios individuales ni grupos de la cuenta B, solo la cuenta.

{
  "Version": "2012-10-17",
  "Statement": {
    "Sid": "AccountBAccess1",
    "Effect": "Allow",
    "Principal": {"AWS": "111122223333"},
    "Action": "s3:*",
    "Resource": [
      "arn:aws:s3:::amzn-s3-demo-bucket",
      "arn:aws:s3:::amzn-s3-demo-bucket/*"
    ]
  }
}

De forma alternativa, la cuenta A puede utilizar las Listas de control de acceso (ACL) de Amazon S3 para conceder a la cuenta B acceso a un bucket de S3 o a un único objeto de un bucket. En tal caso, lo único que cambia es cómo la cuenta A concede acceso a la cuenta B. La cuenta B todavía utiliza una política para delegar el acceso a un grupo de IAM de la cuenta B, tal y como se describe en la próxima sección de este ejemplo. Para obtener más información sobre el control del acceso a los buckets y objetos de S3, vaya a Control de acceso en la Guía del usuario de Amazon Simple Storage Service.

El administrador de la cuenta B puede crear la siguiente muestra de política. La política permite el acceso de lectura a un grupo o usuario de la cuenta B. La política anterior concede acceso a la cuenta B. Sin embargo, los grupos y usuarios individuales de la cuenta B no pueden obtener acceso al recurso hasta que una política de grupo o usuario conceda de forma explícita los permisos al recurso. Los permisos de esta política solo pueden ser un subconjunto de los de la anterior política entre cuentas. La cuenta B no puede conceder más permisos a sus grupos y usuarios que los que la cuenta A concedió a la cuenta B en la primera política. En esta política, el elemento Action se define de forma explícita para permitir únicamente acciones List y el elemento Resource de esta política coincide con Resource para la política de bucket implementada por la cuenta A.

Para aplicar esta política, la cuenta B utiliza IAM para asociarla al usuario adecuado (o grupo) de la cuenta B.

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "s3:List*",
    "Resource": [
      "arn:aws:s3:::amzn-s3-demo-bucket",
      "arn:aws:s3:::amzn-s3-demo-bucket/*"
    ]
  }
}

Uso de una política basada en recursos para delegar el acceso a una cola de Amazon SQS de otra cuenta

En el siguiente ejemplo, la cuenta A tiene una cola de Amazon SQS que utiliza una política basada en recursos asociados a la cola para conceder acceso a la cola a la cuenta B. A continuación, la cuenta B utiliza una política de grupo de IAM para delegar el acceso a un grupo de la cuenta B.

En el siguiente ejemplo una política de cola concede permiso a la cuenta B para realizar las acciones SendMessage y ReceiveMessage en la cola de la cuenta A denominada queue1, pero solo entre las 12:00 h y las 15:00 h del 30 de noviembre de 2014. El número de la cuenta B es 1111-2222-3333. La cuenta A utiliza Amazon SQS para implementar esta política.

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Principal": {"AWS": "111122223333"},
    "Action": [
      "sqs:SendMessage",
      "sqs:ReceiveMessage"
    ],
    "Resource": ["arn:aws:sqs:*:123456789012:queue1"],
    "Condition": {
      "DateGreaterThan": {"aws:CurrentTime": "2014-11-30T12:00Z"},
      "DateLessThan": {"aws:CurrentTime": "2014-11-30T15:00Z"}
    }
  }
}

La política de la cuenta B para delegar el acceso a un grupo de la cuenta B podría ser como el siguiente ejemplo. La cuenta B utiliza IAM para asociar esta política a un grupo (o usuario).

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "sqs:*",
    "Resource": "arn:aws:sqs:*:123456789012:queue1"
  }
}

En el ejemplo anterior de la política de usuario de IAM, la cuenta B utiliza un carácter comodín para conceder acceso a su usuario a todas las acciones de Amazon SQS en la cola de la cuenta A. Sin embargo, la cuenta B puede delegar el acceso únicamente en la medida en que se haya concedido acceso a dicha cuenta. El grupo de la cuenta B que tenga la segunda política solo puede obtener acceso a la cola entre las 12:00 y las 3:00 el 30 de noviembre de 2014. El usuario solo puede realizar las acciones SendMessage y ReceiveMessage, según se define en la política de cola de Amazon SQS de la cuenta A.

No se puede delegar el acceso cuando la cuenta tiene el acceso denegado

Una Cuenta de AWS no puede delegar el acceso a los recursos de otra cuenta si la otra cuenta ha denegado de forma explícita el acceso a la cuenta principal del usuario. La denegación se propaga a los usuarios de dicha cuenta independientemente de que tengan políticas que les conceda acceso.

Por ejemplo, la cuenta A escribe una política de bucket en el bucket de S3 de la cuenta A que deniega de forma explícita el acceso de la cuenta B al bucket de la cuenta A. Pero la cuenta B escribe una política de usuario de IAM que concede a un usuario de la cuenta B acceso a un bucket de la cuenta A. La denegación explícita aplicada al bucket de S3 de la cuenta A se propaga a los usuarios de la cuenta B. Anula la política de usuario de IAM que concede acceso al usuario de la cuenta B (para obtener más información sobre se evalúan cómo los permisos, consulte Lógica de evaluación de políticas.)

La política de bucket de la cuenta A podría ser como la siguiente política. En este ejemplo, el bucket de S3 de la cuenta A se llama amzn-s3-demo-bucket, mientras que el número de cuenta de la cuenta B es 1111-2222-3333. La cuenta A utiliza Amazon S3 para implementar esta política.

{
  "Version": "2012-10-17",
  "Statement": {
    "Sid": "AccountBDeny",
    "Effect": "Deny",
    "Principal": {"AWS": "111122223333"},
    "Action": "s3:*",
    "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*"
  }
}

Esta denegación explícita anula cualquier políticas de la cuenta B que proporcione permiso para obtener acceso al bucket de S3 en la cuenta A.