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, debes evitar usar LCA y debes habilitar el acceso uniforme a nivel de bucket para tus buckets, lo que evita el uso de LCA:

  • Las LCA no se pueden usar de forma exclusiva para controlar el acceso a tus recursos de Google Cloud, ya que las LCA no se pueden configurar en el proyecto general ni en recursos fuera de Cloud Storage.
  • Si habilitas el acceso uniforme a nivel de bucket, se crea una plataforma de control de acceso más simple y te permite usar funciones adicionales de Google Cloud. Para obtener más información, consulta ¿deberías usar el acceso uniforme a nivel de bucket?
  • La política de la organización de uso compartido restringido del dominio y las políticas de la organización personalizadas no impiden el acceso otorgado por las LCA, lo que podría generar accesos no deseados.
  • Pueden ocurrir comportamientos y accesos inesperados cuando se usan LCA en proyectos que tienen condiciones de IAM configuradas a nivel del proyecto o superior.

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

  • Debes personalizar el acceso a objetos individuales dentro de un bucket, por ejemplo, si quieres que quien sube un objeto tenga control total sobre ese objeto, pero menos acceso a otros objetos en tu bucket.
  • Solo usas la API de XML o necesitas interoperabilidad con Amazon S3.

La administración de identidades y accesos (IAM) y las LCA funcionan en conjunto para 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. En general, los permisos que otorgan las políticas de IAM no aparecen en las LCA y viceversa. Consulta la relación de la IAM con las LCA para obtener más información.

¿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.

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 collaborator@gmail.com
Dirección de correo electrónico del Grupo de Google Grupo work-group@googlegroups.com
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/my-user@example.com
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: gs-announce@googlegroups.com. 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.

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.

    * 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.

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.

¿Qué sigue?