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.

S3 Object Ownership es una configuración de bucket de Amazon S3 que puede usar para controlar la propiedad de los objetos que se cargan en el bucket y para activar o desactivar las ACL. De forma predeterminada, la propiedad de objetos se establece en la configuración impuesta por el propietario del bucket. Además, todas las ACL están deshabilitadas. Cuando las ACL están deshabilitadas, el propietario del bucket posee todos los objetos del bucket y administra su acceso de forma exclusiva mediante políticas de administración de acceso.

La mayoría de los casos de uso modernos de Amazon S3 ya no requieren el uso de ACL. Le recomendamos desactivar las ACL, excepto en circunstancias inusuales en las que necesite controlar el acceso a cada objeto de manera individual. Si las ACL están desactivadas, puede usar políticas para controlar el acceso a todos los objetos del bucket, independientemente de quién haya subido los objetos al bucket. Para obtener más información, consulte Control de la propiedad de los objetos y desactivación de las ACL del bucket.

importante

Si el bucket utiliza la configuración de propietario del bucket obligatorio de S3 Object Ownership, debe utilizar políticas para conceder acceso al bucket y a los objetos que contiene. Si la configuración impuesta por el propietario del bucket está activada, las solicitudes de configuración o actualización de las listas de control de acceso (ACL) fallan y devuelven el código de error AccessControlListNotSupported. Las solicitudes de lectura de ACL siguen siendo compatibles.

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 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 correo electrónico 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 correo electrónico de la Cuenta de AWS.

Cuando conceda derechos de acceso, especifique cada beneficiario como par type="value", donde type 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 correo electrónico 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)

  • Oeste de EE. UU. (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 puntos de conexión admitidos por Amazon S3, consulte Regiones y puntos de conexión 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 correo electrónico permisos para leer los datos y los metadatos de los objetos:

x-amz-grant-read: emailAddress="xyz@example.com", emailAddress="abc@example.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 la 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. Al conceder acceso a la cuenta a un grupo, especifique uno de los URI de Amazon S3 en lugar de un ID de usuario canónico. Amazon S3 proporciona 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 WRITE en un bucket le permite a este grupo escribir registros de acceso al servidor (consulte Registro de solicitudes con 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 buckets y objetos existentes, también permite eliminar y sobrescribir dichos 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 Permite conceder los permisos READWRITEREAD_ACP y WRITE_ACP en el bucket Permite conceder los permisos READREAD_ACP y WRITE_ACP en el bucket
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 que lea toda la 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 políticas 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 siguientes claves de contexto 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 más información sobre claves de condición específicas de Amazon S3, consulte Actions, resources, and condition keys for Amazon S3 en la Referencia de autorización de servicios.

Valores de aclRequired para solicitudes comunes de Amazon S3

Para identificar las solicitudes de Amazon S3 que requerían ACL para la autorización, puede utilizar el valor aclRequired de los registros de acceso al servidor de Amazon S3 o AWS CloudTrail. El valor aclRequired que aparece en CloudTrail o en los registros de acceso al servidor de Amazon S3 depende de las operaciones a las que se haya llamado y de cierta información sobre el solicitante, el propietario del objeto y el propietario del bucket. Si no se requerían ACL, si está estableciendo la ACL predefinida bucket-owner-full-control o si las solicitudes están permitidas por su política de buckets, la cadena de valor de aclRequired es “-”en los registros de acceso al servidor de Amazon S3 y falta en CloudTrail.

Las siguientes tablas muestran los valores aclRequired esperados en los registros de acceso al servidor de CloudTrail o Amazon S3 para las distintas operaciones de la API de Amazon S3. Puede utilizar esta información para saber qué operaciones de Amazon S3 dependen de las ACL para su autorización. En las tablas siguientes, A, B y C representan las diferentes cuentas asociadas al solicitante, al propietario del objeto y al propietario del bucket. Las entradas con un asterisco (*) indican cualquiera de las cuentas A, B o C.

nota

Las operaciones PutObject de la tabla siguiente, a menos que se especifique lo contrario, indican solicitudes que no establecen una ACL, a menos que se trate de una ACL bucket-owner-full-control. Un valor nulo para aclRequired indica que aclRequired falta en los registros de AWS CloudTrail.

Valores de aclRequired para CloudTrail
Nombre de operación Solicitante Propietario del objeto Propietario del bucket La política de buckets concede acceso Valor de aclRequired Motivo
GetObject A A A Yes o No null Acceso en la misma cuenta
A B A Yes o No null Acceso a la misma cuenta con el propietario del bucket aplicado
A A B null Acceso entre cuentas a través de la política de buckets
A A B No El acceso entre cuentas se basa en la ACL
A A B null Acceso entre cuentas a través de la política de buckets
A B B No El acceso entre cuentas se basa en la ACL
A B C null Acceso entre cuentas a través de la política de buckets
A B C No El acceso entre cuentas se basa en la ACL
PutObject A No aplicable A Yes o No null Acceso en la misma cuenta
A No aplicable B null Acceso entre cuentas a través de la política de buckets
A No aplicable B No El acceso entre cuentas se basa en la ACL
PutObject con una ACL (excepto para bucket-owner-full-control) * No aplicable * Yes o No La solicitud concede ACL
ListObjects A No aplicable A Yes o No null Acceso en la misma cuenta
A No aplicable B null Acceso entre cuentas a través de la política de buckets
A No aplicable B No El acceso entre cuentas se basa en la ACL
DeleteObject A No aplicable A Yes o No null Acceso en la misma cuenta
A No aplicable B null Acceso entre cuentas a través de la política de buckets
A No aplicable B No El acceso entre cuentas se basa en la ACL
PutObjectAcl * * * Yes o No La solicitud concede ACL
PutBucketAcl * No aplicable * Yes o No La solicitud concede ACL

nota

Las operaciones REST.PUT.OBJECT de la tabla siguiente, a menos que se especifique lo contrario, indican solicitudes que no establecen una ACL, a menos que se trate de una ACL bucket-owner-full-control. Una cadena de valores aclRequired de “-” indica un valor nulo en los registros de acceso al servidor de Amazon S3.

Valores aclRequired para los registros de acceso al servidor de Amazon S3
Nombre de operación Solicitante Propietario del objeto Propietario del bucket La política de buckets concede acceso Valor de aclRequired Motivo
REST.GET.OBJECT A A A Yes o No - Acceso en la misma cuenta
A B A Yes o No - Acceso a la misma cuenta con el propietario del bucket aplicado
A A B - Acceso entre cuentas a través de la política de buckets
A A B No El acceso entre cuentas se basa en la ACL
A B B - Acceso entre cuentas a través de la política de buckets
A B B No El acceso entre cuentas se basa en la ACL
A B C - Acceso entre cuentas a través de la política de buckets
A B C No El acceso entre cuentas se basa en la ACL
REST.PUT.OBJECT A No aplicable A Yes o No - Acceso en la misma cuenta
A No aplicable B - Acceso entre cuentas a través de la política de buckets
A No aplicable B No El acceso entre cuentas se basa en la ACL
REST.PUT.OBJECT con una ACL (excepto para bucket-owner-full-control) * No aplicable * Yes o No La solicitud concede ACL
REST.GET.BUCKET A No aplicable A Yes o No - Acceso en la misma cuenta
A No aplicable B - Acceso entre cuentas a través de la política de buckets
A No aplicable B No El acceso entre cuentas se basa en la ACL
REST.DELETE.OBJECT A No aplicable A Yes o No - Acceso en la misma cuenta
A No aplicable B - Acceso entre cuentas a través de la política de buckets
A No aplicable B No El acceso entre cuentas se basa en la ACL
REST.PUT.ACL * * * Yes o No La solicitud concede ACL

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 con registro de acceso al servidor).
nota

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

Puede especificar una ACL enlatada en su solicitud mediante 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.