Información general de las Listas de control de acceso (ACL) - Amazon Simple Storage Service

Información general de las Listas de control de acceso (ACL)

Las listas de control de acceso (ACL) de Amazon S3 le permiten administrar el acceso a buckets y objetos. Cada bucket y objeto incluye una ACL como un subrecurso. La ACL define qué Cuentas de AWS o grupos cuentan con acceso y el tipo de acceso que tienen. Cuando se recibe una solicitud en relación con un recurso, Amazon S3 verifica la ACL correspondiente para asegurarse de que el solicitante tenga los permisos de acceso necesarios.

Cuando crea un bucket o un objeto, Amazon S3 crea una ACL predeterminada que concede al propietario del recurso control total sobre el recurso. Esto se muestra en el siguiente ACL de bucket de muestra (el ACL del objeto predeterminado tiene la misma estructura):

<?xml version="1.0" encoding="UTF-8"?> <AccessControlPolicy xmlns="http://s3.amazonaws.com/doc/2006-03-01/"> <Owner> <ID>*** Owner-Canonical-User-ID ***</ID> <DisplayName>owner-display-name</DisplayName> </Owner> <AccessControlList> <Grant> <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="Canonical User"> <ID>*** Owner-Canonical-User-ID ***</ID> <DisplayName>display-name</DisplayName> </Grantee> <Permission>FULL_CONTROL</Permission> </Grant> </AccessControlList> </AccessControlPolicy>

La ACL de muestra incluye un elemento Owner que identifica al propietario a través del ID de usuario canónico de la Cuenta de AWS . Para obtener instrucciones acerca de cómo buscar su identificador de usuario canónico, consulte Búsqueda del ID de usuario canónico de una Cuenta de AWS . El elemento Grant identifica al beneficiario (ya sea una Cuenta de AWS o un grupo predefinido) y el permiso otorgado. Esta ACL predeterminada tiene un elemento Grant para el propietario. Usted otorga permisos al añadir elementos Grant, con cada concesión identifica al beneficiario y al permiso.

nota

Una ACL puede tener hasta 100 concesiones.

¿Quién es un beneficiario?

El beneficiario puede ser una Cuenta de AWS o uno de los grupos predefinidos de Amazon S3. Puede otorgar permiso a una Cuenta de AWS con la dirección de email o el ID de usuario canónico. Sin embargo, si proporciona una dirección de correo electrónico en su solicitud de concesión, Amazon S3 detecta el ID de usuario canónico para esa cuenta y lo añade a la ACL. Las ACL resultantes siempre incluyen el ID de usuario canónico de la Cuenta de AWS , no la dirección de email de la Cuenta de AWS .

Cuando conceda derechos de acceso, especifique cada beneficiario como par tipo=valor, donde el tipo sea uno de los siguientes:

  • id: si el valor especificado es el ID de usuario canónico de una Cuenta de AWS .

  • uri: si está otorgando permisos a un grupo predefinido.

  • emailAddress: si el valor especificado es la dirección de email de una Cuenta de AWS .

importante

Solo las siguientes regiones de AWS permiten utilizar direcciones de email para especificar el beneficiario:

  • EE.UU. Este (Norte de Virginia)

  • EE.UU. Oeste (Norte de California)

  • EE.UU. Oeste (Oregón)

  • Asia Pacífico (Singapur)

  • Asia Pacífico (Sídney)

  • Asia Pacífico (Tokio)

  • Europa (Irlanda)

  • América del Sur (São Paulo)

Para ver una lista de todas las regiones y los puntos de enlace que admiten Amazon S3, consulte Regiones y puntos de enlace en la Referencia general de Amazon Web Services.

ejemplo Ejemplo: dirección de correo electrónico

Por ejemplo, el encabezado x-amz-grant-read siguiente otorga a las Cuentas de AWS identificadas por direcciones de email permisos para leer los datos y los metadatos de los objetos:

x-amz-grant-read: emailAddress="xyz@amazon.com", emailAddress="abc@amazon.com"
aviso

Cuando otorgue a otras Cuentas de AWS acceso a sus recursos, tenga en cuenta que las Cuentas de AWS pueden delegar sus permisos a los usuarios de sus cuentas. Esto se conoce como acceso entre cuentas. Para obtener información acerca del uso del acceso entre cuentas, consulte Creación de un rol para delegar permisos a un usuario de IAM en la guía del usuario de IAM.

Búsqueda del ID de usuario canónico de una Cuenta de AWS

El ID de usuario canónico está asociado a su Cuenta de AWS . Este ID es una cadena larga de caracteres, como 79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be. Para obtener información acerca de cómo encontrar el ID de usuario canónico de su cuenta, consulte Búsqueda del ID de usuario canónico de su Cuenta de AWS .

También puede buscar el ID de usuario canónico de una Cuenta de AWS si lee la ACL de un bucket o un objeto para el cual la Cuenta de AWS tiene permisos de acceso. Cuando una solicitud de concesión otorga permisos a una Cuenta de AWS individual, se agrega una entrada de concesión a la ACL con el ID de usuario canónico de la cuenta.

nota

Si hace su bucket público (no se recomienda) cualquier usuario sin autenticar puede cargar objetos al bucket. Estos usuarios anónimos no tienen una Cuenta de AWS . Cuando un usuario anónimo carga un objeto en su bucket Amazon S3 agrega un ID de usuario canónico especial (65a011a29cdf8ec533ec3d1ccaae921c) como propietario del objeto en la ACL. Para obtener más información, consulte Propiedad de los buckets y objetos de Amazon S3.

Grupos predefinidos de Amazon S3

Amazon S3 tiene un conjunto de grupos predefinidos. Cuando le otorga acceso a la cuenta a un grupo, usted especifica uno de nuestros Uniform Resource Identifiers (URI, Identificadores de recursos uniformes) en lugar de un ID de usuario canónico. Proporcionamos los siguientes grupos predefinidos:

  • Grupo Usuarios autenticados: representado por http://acs.amazonaws.com/groups/global/AuthenticatedUsers.

    Este grupo representa a todas las Cuentas de AWS . El permiso de acceso a este grupo permite que cualquier Cuenta de AWS acceda al recurso. Sin embargo, todas las solicitudes deben estar firmadas (autenticadas).

    aviso

    Cuando otorga acceso al Grupo de usuarios autenticados, cualquier usuario autenticado de AWS en el mundo puede acceder a su recurso.

  • Grupo Todos los usuarios: representado por http://acs.amazonaws.com/groups/global/AllUsers.

    El permiso de acceso a este grupo permite que cualquier persona en el mundo tenga acceso al recurso. Las solicitudes pueden estar firmadas (autenticadas) o pueden no incluir una firma (anónimas). Las solicitudes sin firmar omiten el encabezado de autenticación en la solicitud.

    aviso

    Recomendamos encarecidamente que no conceda nunca los permisos WRITE, WRITE_ACP o FULL_CONTROL al grupo Todos los usuarios. Por ejemplo, aunque los permisos de WRITE no permiten que los no propietarios sobrescriban o eliminen objetos existentes, los permisos de WRITE siguen permitiendo a cualquier persona almacenar objetos en el bucket, que se facturan. Para obtener más información sobre estos permisos, consulte la sección siguiente ¿Qué permisos puedo conceder?.

  • Grupo Envío de archivos de registro: representado por http://acs.amazonaws.com/groups/s3/LogDelivery.

    El permiso de escritura (WRITE) en un bucket le permite a este grupo escribir registros de acceso al servidor (consulte Registro de solicitudes mediante el registro de acceso al servidor) en el bucket.

nota

Cuando utiliza ACL, el beneficiario puede ser una Cuenta de AWS o uno de los grupos predefinidos de Amazon S3. Sin embargo, el beneficiario no puede ser un usuario de IAM. Para obtener más información acerca de los permisos y los usuarios de AWS en IAM, consulte Uso de AWS Identity and Access Management.

¿Qué permisos puedo conceder?

En la siguiente tabla se muestra el conjunto de permisos que Amazon S3 admite en una ACL. El conjunto de permisos de ACL es el mismo para una ACL de objetos y una ACL de buckets. Sin embargo, según el contexto (ACL de bucket o ACL de objeto) estos permisos de ACL conceden permisos para operaciones de buckets o de objeto específicas. La tabla muestra los permisos y describe qué significan en el contexto de objetos y buckets.

Para obtener más información acerca de los permisos de ACL en la consola de Amazon S3, consulte Configuración de la ACL.

Permisos de ACL
Permiso Cuando se concede en un bucket Cuando se concede en un objeto
READ Le permite al beneficiario crear una lista de objetos en el bucket Le permite al beneficiario leer los datos del objeto y sus metadatos
WRITE Permite al beneficiario crear nuevos objetos en el bucket. Para los propietarios de bucket y objetos de objetos existentes, también permite eliminar y sobreescribir esos objetos. No aplicable
READ_ACP Le permite al beneficiario leer la ACL de bucket Le permite al beneficiario leer la ACL de objeto
WRITE_ACP Le permite al beneficiario escribir la ACL para el bucket correspondiente Le permite al beneficiario escribir la ACL para el objeto correspondiente
FULL_CONTROL Le concede al beneficiario los permisos READ, WRITE, READ_ACP y WRITE_ACP en el bucket Le concede al beneficiario permisos READ, READ_ACP y WRITE_ACP en el objeto
aviso

Extreme las precauciones a la hora de conceder permisos de acceso a sus objetos y buckets de S3. Por ejemplo, la concesión de acceso WRITE a un bucket permite al beneficiario crear objetos en el bucket. Se recomienda encarecidamente que lea toda esta sección Información general de las Listas de control de acceso (ACL) antes de conceder permisos.

Mapeo de permisos de ACL y permisos de política de acceso

Como se muestra en la tabla anterior, una ACL permite solo un conjunto limitado de permisos, en comparación con el número de permisos que puede configurar en una política de acceso (consulte Acciones de Amazon S3). Cada uno de estos permisos permite una o más operaciones de Amazon S3.

La siguiente tabla muestra cómo cada permiso de ACL se asigna a los permisos de política de acceso correspondientes. Como puede ver, la política de acceso permite más permisos que ACL. ACL se utiliza principalmente para conceder permisos básicos de lectura/escritura, similar a los permisos del sistema de archivos. Para obtener más información acerca de cuándo utilizar la ACL, consulte Directrices de política de acceso.

Para obtener más información acerca de los permisos de ACL en la consola de Amazon S3, consulte Configuración de la ACL.

Permiso de ACL Permisos de política de acceso correspondientes cuando se concede un permiso de ACL en un bucket Permisos de política de acceso correspondientes cuando se concede un permiso de ACL en un objeto
READ s3:ListBucket, s3:ListBucketVersions, y s3:ListBucketMultipartUploads s3:GetObject y s3:GetObjectVersion
WRITE

s3:PutObject

El propietario del bucket puede crear, sobrescribir y eliminar cualquier objeto del bucket, y el propietario del objeto tiene FULL_CONTROL sobre su objeto.

Además, cuando el beneficiario es el propietario del bucket, conceder permisos WRITE en una ACL de bucket permite que la acción s3:DeleteObjectVersion se realice en cualquier versión en ese bucket.

No aplicable
READ_ACP s3:GetBucketAcl s3:GetObjectAcl y s3:GetObjectVersionAcl
WRITE_ACP s3:PutBucketAcl s3:PutObjectAcl y s3:PutObjectVersionAcl
FULL_CONTROL Equivalente a otorgar permisos de ACL READ, WRITE, READ_ACP y WRITE_ACP. Por consiguiente, este permiso de ACL se asigna a una combinación de permisos de política de acceso correspondientes. Equivalente a otorgar permisos de ACL READ, READ_ACP y WRITE_ACP. Por consiguiente, este permiso de ACL se asigna a una combinación de permisos de política de acceso correspondientes.

Claves de condición

Cuando concede permisos de directiva de acceso, puede utilizar claves de condición para restringir el valor de la ACL en un objeto mediante una directiva de bucket. Las claves de contexto siguientes corresponden a las ACL. Puede utilizar estas claves de contexto para ordenar el uso de una ACL específica en una solicitud:

  • s3:x-amz-grant-read: requerir acceso de lectura.

  • s3:x-amz-grant-write: requerir acceso de escritura.

  • s3:x-amz-grant-read-acp: requerir acceso de lectura a la ACL del bucket.

  • s3:x-amz-grant-write-acp: requerir acceso de escritura a la ACL del bucket.

  • s3:x-amz-grant-full-control: requerir control total.

  • s3:x-amz-acl ‐ requerir un ACL predefinidas.

Por ejemplo, para las políticas que implican encabezados específicos de ACL, consulte Ejemplo 1: Concesión de permisos s3:PutObject con una condición que solicita que el propietario del bucket tenga control total. Para obtener una lista completa de claves de condición específicas de Amazon S3, consulte Acciones, recursos y claves de condición de Amazon S3.

ACL de muestra

La siguiente ACL de muestra en un bucket identifica al propietario del recurso y un conjunto de concesiones. El formato es la representación XML de una ACL en la API de REST de Amazon S3. El propietario del bucket tiene FULL_CONTROL del recurso. Además, la ACL muestra cómo se otorgan los permisos para un recurso a dos Cuentas de AWS identificadas por el ID de usuario canónico, y a dos de los grupos predefinidos de Amazon S3, analizados en la sección anterior.

<?xml version="1.0" encoding="UTF-8"?> <AccessControlPolicy xmlns="http://s3.amazonaws.com/doc/2006-03-01/"> <Owner> <ID>Owner-canonical-user-ID</ID> <DisplayName>display-name</DisplayName> </Owner> <AccessControlList> <Grant> <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser"> <ID>Owner-canonical-user-ID</ID> <DisplayName>display-name</DisplayName> </Grantee> <Permission>FULL_CONTROL</Permission> </Grant> <Grant> <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser"> <ID>user1-canonical-user-ID</ID> <DisplayName>display-name</DisplayName> </Grantee> <Permission>WRITE</Permission> </Grant> <Grant> <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser"> <ID>user2-canonical-user-ID</ID> <DisplayName>display-name</DisplayName> </Grantee> <Permission>READ</Permission> </Grant> <Grant> <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="Group"> <URI>http://acs.amazonaws.com/groups/global/AllUsers</URI> </Grantee> <Permission>READ</Permission> </Grant> <Grant> <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="Group"> <URI>http://acs.amazonaws.com/groups/s3/LogDelivery</URI> </Grantee> <Permission>WRITE</Permission> </Grant> </AccessControlList> </AccessControlPolicy>

ACL predefinidas

Amazon S3 admite un conjunto de concesiones predefinidas, conocidas como ACL predefinidas. Cada ACL predefinida tiene un conjunto predefinido de beneficiarios y permisos. En la siguiente tabla se muestra el conjunto de ACL predefinidas y las concesiones predefinidas asociadas.

ACL predefinidas Se aplica a Permisos añadidos a la ACL
private Bucket y objeto El propietario tiene FULL_CONTROL. Nadie más tiene derechos de acceso (opción predeterminada).
public-read Bucket y objeto El propietario tiene FULL_CONTROL. El grupo AllUsers (consulte ¿Quién es un beneficiario?) obtiene acceso READ.
public-read-write Bucket y objeto El propietario tiene FULL_CONTROL. El grupo AllUsers obtiene acceso READ y WRITE. Por lo general, no se recomienda conceder esto en un bucket.
aws-exec-read Bucket y objeto El propietario tiene FULL_CONTROL. Amazon EC2 obtiene acceso READ a GET para obtener un paquete de Amazon Machine Image (AMI) de Amazon S3.
authenticated-read Bucket y objeto El propietario tiene FULL_CONTROL. El grupo AuthenticatedUsers obtiene acceso de READ.
bucket-owner-read Objeto El propietario del objeto tiene FULL_CONTROL. El propietario del bucket obtiene acceso READ. Si especifica esta ACL predefinida cuando crea un bucket, Amazon S3 la ignora.
bucket-owner-full-control Objeto Tanto el propietario del objeto como el propietario del bucket tienen FULL_CONTROL del objeto. Si especifica esta ACL predefinida cuando crea un bucket, Amazon S3 la ignora.
log-delivery-write Bucket El grupo LogDelivery obtiene permisos de WRITE y READ_ACP en el bucket. Para obtener más información acerca de los logs, consulte (Registro de solicitudes mediante el registro de acceso al servidor).
nota

Puede especificar solo una de estas ACL predefinidas en su solicitud.

Para especificar una ACL predefinida en su solicitud, debe utilizar el encabezado de solicitud x-amz-acl. Cuando Amazon S3 recibe una solicitud con una ACL predefinida en la solicitud, añade las concesiones predefinidas a la ACL del recurso.