Listas de control de acceso (LCA)

Uso

En esta página se proporciona una descripción general de las listas de control de acceso (LCA). Para obtener información sobre otras formas de controlar el acceso a los depósitos y objetos, consulta Descripción general del control de acceso.

¿Debería usar listas de control de acceso?

En la mayoría de los casos, se recomienda usar la administración de identidades y accesos (IAM) para controlar el acceso a tus recursos:

• IAM proporciona control de acceso en las distintas plataformas de Google Cloud.
• IAM tiene un mayor control sobre las acciones que pueden realizar los usuarios.
• Los recursos secundarios, como buckets y objetos, heredan los permisos de IAM otorgados a recursos superiores, como los proyectos, lo que te permite administrar con mayor facilidad el acceso a los recursos.
• Los permisos de IAM se pueden aplicar a las carpetas administradas, mientras que las LCA no.
• Las LCA no se pueden usar de forma exclusiva para controlar el acceso a tus recursos, ya que las LCA no se pueden configurar en el proyecto general ni en otros recursos superiores.

El uso exclusivo de IAM y habilitar el acceso uniforme a nivel de bucket te permite usar otras funciones de seguridad de Google Cloud, como el uso compartido restringido del dominio y la federación identidad de trabajador y las condiciones de IAM.

Es muy probable que quieras usar las LCA en los siguientes casos:

• Necesitas personalizar el acceso a objetos individuales dentro de un bucket. Las LCA se pueden configurar para objetos individuales, mientras que los permisos de IAM solo se pueden otorgar a nivel de bucket o superior.
• Solo usas la API de XML o necesitas interoperabilidad con Amazon S3.

IAM y LCA funcionan en conjunto a fin de otorgar acceso a tus buckets y objetos, lo que significa que un usuario solo necesita el permiso relevante de cualquiera de estos sistemas para acceder a un bucket o a un objeto.

Nota: En general, los permisos que otorgan las políticas de IAM no aparecen en las LCA y viceversa. La única excepción son las LCA aplicadas directamente a un bucket y ciertas políticas de IAM a nivel del bucket, como se describe en la relación entre IAM y las LCA. Para reducir la sobrecarga de administración y seguimiento, debes inhabilitar el sistema de LCA y usar IAM de forma exclusiva.

¿Qué es una lista de control de acceso?

Una lista de control de acceso (LCA) es un mecanismo que puedes usar para definir quién tiene acceso a tus buckets y objetos, así como qué nivel de acceso tienen. En Cloud Storage, las LCA se aplican a buckets y objetos individuales. Cada LCA consta de una o más entradas. Una entrada da a un usuario específico (o un grupo) la capacidad de realizar acciones específicas. Cada entrada consta de la siguiente información que se muestra a continuación:

• Un permiso, que define qué acciones se pueden realizar (por ejemplo, leer o escribir)

• Un alcance (a veces llamado beneficiario), que define quién puede realizar las acciones especificadas (por ejemplo, un usuario específico o un grupo de usuarios).

Como ejemplo, supongamos que tienes un bucket y deseas que cualquiera pueda acceder a los objetos en él, pero también deseas que tu colaborador pueda agregar o quitar objetos del bucket. En este caso, tu LCA debería tener las siguientes dos entradas:

• En una entrada, otorgarías el permiso READER a un alcance de allUsers.

• En la otra entrada, le darías permiso WRITER al alcance de tu colaborador (hay muchas formas de especificar esta persona, por ejemplo, mediante su correo electrónico).

La cantidad máxima de entradas de LCA que se pueden crear para un bucket o un objeto es 100. Cuando el alcance de la entrada es un grupo o dominio, cuenta como una entrada LCA sin importar la cantidad de usuarios que haya en el grupo o dominio.

Cuando un usuario solicita acceso a un bucket o un objeto, el sistema de Cloud Storage lee la LCA del bucket o del objeto y determina si permitirá o rechazará la solicitud de acceso. Si la LCA otorga al usuario el permiso para la operación solicitada, se admite la solicitud. Si la LCA no otorga permiso al usuario para la operación solicitada, la solicitud falla y se muestra un error 403 Forbidden.

Ten en cuenta que las LCA se pueden usar para administrar la mayoría de las acciones que involucran depósitos y objetos, la capacidad de create un depósito proviene de tener un permiso de proyecto adecuado.

Permisos

Los permisos describen qué se le puede hacer a un objeto o depósito dados.

Cloud Storage te permite asignar los siguientes permisos concéntricos para tus depósitos y objetos, como se muestra en la tabla siguiente:

	Depósitos	Objetos
READER	Permite que los usuarios enumeren los contenidos de un depósito. Permite que un usuario lea metadatos del bucket, sin incluir las LCA.	Permite que un usuario descargue los datos de un objeto.
WRITER	Otorga a un usuario todo el acceso que otorga el permiso READER. Además, permite que un usuario cree, reemplace y borre objetos en un bucket, incluida la creación de objetos mediante cargas multiparte.	No corresponde. No puedes aplicar este permiso a los objetos.
OWNER	Otorga a un usuario todo el acceso que otorga el permiso WRITER. También permite que un usuario lea y escriba metadatos del bucket, incluso las LCA, y trabaje con etiquetas en el bucket.	Otorga a un usuario todo el acceso que otorga el permiso READER. También permite que un usuario lea y escriba metadatos de objeto, incluidas las LCA.
Predeterminado	Los buckets tienen la LCA predefinida project-private ya aplicada en el momento en que se crean. Los buckets siempre son propiedad del grupo project-owners.	Los objetos tienen la LCA predefinida project-private ya aplicada cuando se suben. Los objetos siempre tienen como propietario al solicitante original que subió el objeto.

Nota: No puedes otorgar permisos discretos para lectura o escritura de las LCA o de otros metadatos. Para permitir que alguien lea y escriba las LCA, debes otorgarles el permiso OWNER.

En esta página, por lo general, nos referimos a los permisos como READER, WRITER, y OWNER, que son las formas en que se los especifica en la API de JSON y en la consola de Google Cloud. Si usas la API de XML, los permisos equivalentes respectivos son READ, WRITE y FULL_CONTROL.

Permisos

Los alcances especifican quién tiene un permiso dado.

Una LCA consta de una o más entradas, en la que cada entrada otorga permisos a un alcance. Puedes especificar el alcance de una LCA por medio de cualquiera de las siguientes entidades:

Alcance (“beneficiario”)	Tipos de entidad	Ejemplo
Identificador especial para todas las entidades	Usuario	allUsers
Identificador especial para todas las cuentas válidas	Usuario	allAuthenticatedUsers
Dirección de correo electrónico de la cuenta de usuario	Usuario	[e-mail]
Dirección de correo electrónico del Grupo de Google	Grupo	[e-mail]
Valores de conveniencia para proyectos	Proyecto	owners-123456789012
Dominio de Google Workspace	Dominio	USERNAME@YOUR_DOMAIN.com
Dominio de Cloud Identity	Dominio	USERNAME@YOUR_DOMAIN.com
Identidad única en un grupo de identidad de personal	Principal	//iam.googleapis.com/locations/global/workforcePools/my-pool/subject/[e-mail]
Todas las identidades del personal de un grupo	PrincipalSet	//iam.googleapis.com/locations/global/workforcePools/my-pool/group/my-group

• Identificador especial para todas las entidades:

  El identificador de alcance especial allUsers representa cualquier entidad en Internet. Ten en cuenta que, si bien este identificador es un tipo de entidad de User, cuando se usa la consola de Google Cloud, se etiqueta como un tipo de entidad Public.

• Identificador especial para todas las cuentas válidas:

  El identificador de alcance especial allAuthenticatedUsers representa la mayoría de las cuentas autenticadas, incluidas las cuentas de servicio. Para obtener más información, consulta la Descripción general de IAM. Ten en cuenta que, si bien este identificador es un tipo de entidad de User, cuando se usa la consola de Google Cloud, se etiqueta como un tipo de entidad Public.

• Dirección de correo electrónico de la cuenta de usuario:

  Cada usuario que tiene una cuenta de usuario debe tener una dirección de correo electrónico única asociada a esa cuenta. Puedes especificar un alcance a través de cualquier dirección de correo electrónico asociada a una cuenta de usuario.

  Cloud Storage recuerda las direcciones de correo electrónico como se proporcionan en las LCA hasta que se quitan o se reemplazan las entradas. Si un usuario cambia las direcciones de correo electrónico, tienes que actualizar las entradas de LCA de modo que se reflejen esos cambios.

• Dirección de correo electrónico de Grupos de Google:

  Cada Grupo de Google tiene una dirección de correo electrónico única asociada al grupo. Por ejemplo, el grupo Anuncio de Cloud Storage tiene la siguiente dirección de correo electrónico: [e-mail]. Puedes buscar la dirección de correo electrónico asociada a un Grupo de Google si haces clic en Acerca de en la página de inicio de cada uno.

  Al igual que las direcciones de correo electrónico de las cuentas de usuario, Cloud Storage recuerda las direcciones de correo electrónico de grupos como se proporcionan en las LCA hasta que se quitan las entradas. No tienes que preocuparte por actualizar las direcciones de correo electrónico de los Grupos de Google, ya que esas direcciones son permanentes y no es probable que cambien.

• Valores de conveniencia para los proyectos:

  Los valores de conveniencia te permiten otorgar acceso masivo a los visualizadores, editores y propietarios del proyecto. Los valores de conveniencia combinan un rol de proyecto y un número de proyecto asociado. Por ejemplo, en el proyecto 867489160491, los editores se identifican como editors-867489160491. Puedes buscar el número del proyecto en la página principal de la consola de Google Cloud.

  Por lo general, debes evitar usar valores de conveniencia en entornos de producción, ya que requieren que se otorguen roles básicos, una práctica que no se recomienda en los entornos de producción.

• Google Workspace o Cloud Identity:

  Los clientes de Google Workspace y Cloud Identity pueden asociar sus cuentas de correo electrónico a un nombre de dominio de Internet. Cuando haces esto, cada cuenta de correo electrónico debe tener el formato USERNAME@YOUR_DOMAIN.com. Puedes especificar un alcance con cualquier nombre de dominio de Internet que esté asociado con Google Workspace o Cloud Identity.

• Identidades del personal:

  La federación de identidades de personal te permite usar un proveedor de identidad externo (IdP) para autenticar y autorizar a un grupo de usuarios a través de IAM, de modo que los usuarios puedan acceder a los servicios de Google Cloud.

Permisos concéntricos y alcances

Cuando especificas las LCA en Cloud Storage, no necesitas hacer listas de varios alcances para otorgar varios permisos. En Cloud Storage, se usan permisos concéntricos, por lo tanto, cuando otorgas un permiso WRITER, también otorgas el permiso READER, y si otorgas un permiso OWNER, también otorgas los permisos READER y WRITER.

Cuando se especifica una LCA, la mayoría de las herramientas te permiten especificar varios alcances para la misma entrada. El permiso con más autorización es el acceso otorgado al alcance. Por ejemplo, si proporcionas dos entradas para un usuario, una con el permiso READER y una con el permiso WRITER en un bucket, el usuario tendrá permiso WRITER en el bucket.

En la API de XML, no es posible proporcionar dos entradas de LCA con el mismo alcance. Por ejemplo, otorgar a un usuario el permiso READ y el permiso WRITE sobre un bucket generará un error. En su lugar, otorga al usuario el permiso WRITE, que también le otorga el permiso READ.

LCA predefinidas

Una LCA predefinida, también conocida como LCA estándar, es un alias para un conjunto de entradas de LCA específicas que puedes usar a fin de aplicar varias entradas de LCA con rapidez de una sola vez a un bucket o un objeto.

Precaución: Cuando se aplica una LCA predefinida a un objeto o depósito existente, se reemplaza por completo la LCA de objeto o depósito existente por la predefinida. En algunos casos, este cambio puede hacer que pierdas el acceso a la LCA de objeto o bucket. Por ejemplo, si estás en el grupo de propietarios del proyecto, pero no eres el propietario de un objeto con la LCA projectPrivate, luego de aplicar la LCA predefinida publicRead al objeto, pierdes el permiso OWNER y, por lo tanto, ya no puedes acceder a la LCA de objeto. Si esto sucede, puedes usar la función storage.objectAdmin de IAM para que tengas el permiso necesario a fin de actualizar la LCA del objeto y corregir el cambio.

En la siguiente tabla, se enumeran las LCA predefinidas y se muestra qué entradas de LCA se aplican para cada LCA predefinida. Cuando uses la siguiente tabla, ten en cuenta lo siguiente:

• El grupo de propietarios del proyecto tiene la propiedad de los depósitos del proyecto, y el usuario que crea un objeto tiene propiedad de ese objeto. Si un usuario anónimo creó un objeto, entonces el grupo de propietarios del proyecto tiene la propiedad del objeto.

• En la tabla, se usan las descripciones de permisos de la API de JSON OWNER, WRITER y READER. Los alcances equivalentes de la API de XML son FULL_CONTROL, WRITE y READ.

  JSON API/gcloud storage	API de XML	Descripción
  private	private	Otorga el permiso OWNER al propietario del objeto o depósito para un objeto o depósito.
  bucketOwnerRead	bucket-owner-read	Otorga el permiso OWNER al propietario del objeto y el permiso READER al propietario del depósito. Esto solo se usa con objetos.
  bucketOwnerFullControl	bucket-owner-full-control	Otorga el permiso OWNER a los propietarios de objetos y depósitos. Esto solo se usa con objetos.
  projectPrivate	project-private	Le da permiso al equipo del proyecto según sus funciones. Cualquiera que sea parte del equipo tiene el permiso READER. Los propietarios y editores del proyecto tienen el permiso OWNER. Esta es la LCA predeterminada para los nuevos depósitos creados. Esta también es la LCA predeterminada para los nuevos objetos creados, a menos que se haya cambiado la LCA predeterminada de objeto para ese bucket.
  authenticatedRead	authenticated-read	Otorga el permiso OWNER al propietario del objeto o bucket y otorga el permiso READER a todos los titulares de cuentas de usuario autenticados
  publicRead	public-read	Otorga el permiso OWNER al propietario del objeto o bucket y otorga el permiso READER a todos los usuarios, autenticados y anónimos. Cuando aplicas esto a un objeto, cualquiera en Internet puede leer el objeto sin necesidad de autenticarse. Cuando aplicas esto a un bucket, cualquiera en Internet puede enumerar objetos sin necesidad de autenticarse. * Consulta la nota al final de la tabla en relación con el almacenamiento en caché.
  publicReadWrite	public-read-write	Le da al propietario del bucket el permiso OWNER, y a todos los usuarios, tanto los autenticados como los anónimos, los permisos READER y WRITER. Esta LCA aplica solo a los depósitos. Cuando la aplicas a un bucket, cualquiera en Internet puede enumerar, crear, reemplazar y borrar objetos sin necesidad de autenticarse. Importante: Si configuras un depósito como publicReadWrite, cualquier persona en Internet podrá subir contenido a él. Serás el responsable de este contenido. * Consulta la nota al final de la tabla en relación con el almacenamiento en caché.

* De forma predeterminada, los objetos que se pueden leer de forma pública se entregan con un encabezado Cache-Control que permite almacenar en caché los objetos durante 3,600 segundos. Si necesitas asegurarte de que las actualizaciones se hagan visibles de inmediato, debes establecer los metadatos Cache-Control para los objetos como Cache-Control:private, max-age=0, no-transform.

LCA predeterminadas

Cuando se crean depósitos o se suben objetos, si no les asigna una LCA de forma explícita, se les asigna la LCA predeterminada. Puede cambiar la LCA predeterminada que se otorga a un objeto; el proceso para hacerlo se describe en el cambio de la LCA de objeto predeterminada. Ten en cuenta que, cuando cambias la LCA predeterminada, las LCA de los objetos que ya existen en los depósitos que se encuentran en el proyecto permanecen sin cambios.

LCA de bucket predeterminadas

Todos los depósitos son propiedad del grupo de propietarios del proyecto. Además, a los propietarios del proyecto se les otorga el permiso OWNER para cualquier bucket dentro de su proyecto que use una LCA predefinida.

Si creas un bucket con la LCA de bucket predeterminada, es decir, si no especificas una LCA predefinida, se aplica la LCA predefinida projectPrivate.

LCA de objetos predeterminadas

De forma predeterminada, cualquiera con el permiso OWNER o el permiso WRITER sobre un bucket puede subir objetos a ese bucket. Cuando subes un objeto, puedes proporcionar una LCA predefinida o no especificar ninguna. Si no especificas una LCA, Cloud Storage aplica la LCA de objeto predeterminada del bucket a ese objeto. Cada bucket tiene una LCA de objeto predeterminada que se aplica a todos los objetos subidos a ese bucket sin una LCA predefinida o una LCA especificada en la solicitud (solo para la API de JSON). El valor inicial para la LCA de objeto predeterminada de cada depósito es projectPrivate.

Según cómo se suben los objetos, las LCA de objeto se aplican acorde a lo siguiente:

• Cargas autenticadas

  Si realizas una solicitud autenticada para subir un objeto y no especificas ninguna LCA de objeto cuando lo subes, entonces figuras como el propietario del objeto y la LCA predefinida projectPrivate se aplica al objeto de forma predeterminada. Esto significa lo siguiente:

  • Tú (la persona que subió el objeto) estás en la lista como el propietario del objeto. La propiedad del objeto no se puede cambiar sin modificar las LCA. Solo puedes cambiar la propiedad del objeto si reemplazas un objeto.

  • Tú (el propietario del objeto) tienes otorgado permiso OWNER sobre el objeto. Si intentas dar al propietario un permiso menor que OWNER, Cloud Storage de forma automática escala el permiso a OWNER.

  • El grupo de propietarios y editores del proyecto tienen el permiso OWNER sobre el objeto.

  • El grupo de miembros del equipo del proyecto tienen el permiso READER sobre el objeto.

• Cargas anónimas

  Si un usuario no autenticado (anónimo) sube un objeto, lo cual es posible si un depósito concede al grupo allUsers el permiso WRITER o OWNER, las LCA de depósito predeterminadas se aplican al objeto como se describió antes.

  Los usuarios anónimos no pueden especificar una LCA predefinida mientras se sube un objeto.

Importante: Si cambias la LCA de objeto predeterminada de un depósito, es posible que el cambio demore en propagarse y que los objetos nuevos creados en el depósito obtengan la LCA de objeto predeterminada anterior durante un corto período (consulta la Coherencia). A fin de asegurarte de que los nuevos objetos creados en el depósito obtengan la LCA de objeto predeterminada actualizada, debes esperar al menos 30 segundos antes de crear objetos nuevos.

Comportamiento de la LCA

Cloud Storage te ayuda a satisfacer estas prácticas recomendadas por medio del cumplimiento de algunas reglas de modificación de LCA, las cuales evitan que configures LCA que hacen que los datos sean inaccesibles:

• No puedes aplicar una LCA que especifica un propietario de objeto o bucket diferente.

  La propiedad de bucket y objetos no se puede cambiar mediante la modificación de las LCA. Si aplicas una LCA nueva a un bucket o un objeto, asegúrate de que el propietario del bucket o del objeto se mantenga sin cambios en la LCA nueva.

• El propietario del depósito o del objeto siempre tiene el permiso OWNER del depósito o del objeto.

  El propietario de un bucket es el grupo de propietarios del proyecto y el propietario de un objeto es el usuario que subió el objeto o, si lo subió un usuario anónimo, el grupo de propietarios del proyecto.

  Cuando aplicas una LCA nueva a un bucket o a un objeto, Cloud Storage agrega respectivamente el permiso OWNER al bucket o propietario del objeto si omites otorgarlo. No otorga el permiso OWNER al grupo de propietarios del proyecto para un objeto (a menos que lo haya creado un usuario anónimo), por lo que debes incluirlo de forma explícita.

No puedes aplicar las LCA que cambian la propiedad de un depósito o un objeto (no confundir con el permiso OWNER). Una vez creados en Cloud Storage, los propietarios del bucket y del objeto son permanentes. Sin embargo, puedes cambiar la propiedad de los objetos con efectividad (pero no de los depósitos) si los reemplazas. Reemplazar es, de modo básico, una operación de borrado seguida de una operación de carga de forma inmediata. Durante una operación de carga, la persona que la realiza se convierte en el propietario del objeto. Recuerda que, para reemplazar un objeto, la persona que realiza el reemplazo (y que adquiere la propiedad del objeto en el proceso) debe tener el permiso OWNER o WRITER sobre el bucket en el que se sube el objeto.

Nota: Puedes inhabilitar todas las propiedades de propiedad de un bucket y los objetos dentro de él si habilitas la opción acceso uniforme a nivel de bucket. Así también se quita todo uso de LCA en el depósito, por lo que las políticas de IAM serán el único sistema de control de acceso que se usará.

¿Qué sigue?

• Obtén más información sobre cómo usar las LCA.
• Para aprender a simplificar el control de acceso, consulta Usa el acceso uniforme a nivel de bucket.
• Obtén más información sobre las prácticas recomendadas para usar las LCA.