Listas de control de acceso (LCA)

Uso

En esta página se ofrece una descripción general de las listas de control de acceso (LCA), que le permiten controlar el acceso a segmentos u objetos concretos. Para obtener información sobre otras formas de controlar el acceso a los segmentos y objetos, consulta el artículo Descripción general del control de acceso.

¿Deberías usar listas de control de acceso?

En la mayoría de los casos, no deberías usar las LCA y deberías habilitar el acceso uniforme a nivel de segmento en tus segmentos, lo que impide el uso de las LCA:

  • Las listas de control de acceso no se pueden usar exclusivamente para controlar el acceso a tus recursos de Google Cloud porque no se pueden definir en el proyecto en general ni en los recursos que no estén en Cloud Storage.
  • Si habilitas el acceso uniforme a nivel de segmento, se crea una superficie de control de acceso más sencilla y puedes usar Google Cloud funciones adicionales. Para obtener más información, consulta si debes usar el acceso uniforme a nivel de segmento.
  • La política de organización Uso compartido restringido al dominio y las políticas de organización personalizadas no impiden el acceso concedido por las listas de control de acceso, lo que puede provocar que se acceda a los recursos de forma no intencionada.
  • Pueden producirse comportamientos inesperados y problemas de acceso al usar listas de control de acceso en proyectos que tengan condiciones de gestión de identidades y accesos definidas a nivel de proyecto o superior.

Lo más probable es que quieras usar ACLs en los siguientes casos:

  • Necesitas personalizar el acceso a objetos concretos de un segmento, por ejemplo, si quieres que el usuario que sube un objeto tenga control total sobre él, pero menos acceso a otros objetos del segmento.
  • Solo usas la API XML o necesitas interoperabilidad con Amazon S3.

¿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 segmentos y objetos, así como el nivel de acceso que tiene. En Cloud Storage, las LCA se aplican a objetos y segmentos concretos. Cada ACL consta de una o varias entradas. Una entrada otorga a un usuario (o grupo) específico la capacidad de realizar acciones concretas. Cada entrada consta de dos elementos de información:

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

  • Un ámbito (a veces denominado beneficiario), que define quién puede realizar las acciones especificadas (por ejemplo, un usuario concreto o un grupo de usuarios).

Por ejemplo, supongamos que tienes un contenedor al que quieres que pueda acceder cualquier persona, pero también quieres que tu colaborador pueda añadir o eliminar objetos del contenedor. En este caso, la LCA constaría de dos entradas:

  • En una entrada, darías permiso READER a un ámbito de allUsers.

  • En la otra entrada, darías permiso de WRITER al ámbito de tu colaborador (hay varias formas de especificar a esta persona, como por su correo electrónico).

El número máximo de entradas de ACL que puede crear para un cubo o un objeto es 100. Cuando el ámbito de la entrada es un grupo o un dominio, se cuenta como una entrada de LCA, independientemente del número de usuarios que haya en el grupo o el dominio.

Cuando un usuario solicita acceso a un segmento o a un objeto, el sistema de Cloud Storage lee la LCA del segmento o del objeto y determina si permite o rechaza la solicitud de acceso. Si la LCA concede al usuario permiso para la operación solicitada, se permite la solicitud. Si la ACL no concede al usuario permiso para la operación solicitada, la solicitud falla y se devuelve un error 403 Forbidden.

Ten en cuenta que, aunque las LCAs se pueden usar para gestionar la mayoría de las acciones relacionadas con los segmentos y los objetos, la capacidad de crear un segmento se obtiene al tener el permiso de proyecto adecuado.

Permisos

Los permisos describen qué se puede hacer con un objeto o un segmento concretos.

Cloud Storage le permite asignar los siguientes permisos concéntricos a sus segmentos y objetos, tal como se muestra en la siguiente tabla:

Segmentos Objetos
READER Permite que un usuario consulte el contenido de un contenedor. También permite a un usuario leer los metadatos de un segmento, excluidas las listas de control de acceso. Permite que un usuario descargue los datos de un objeto.
WRITER Otorga a un usuario todo el acceso que se concede con el permiso READER. Además, permite a un usuario crear, sustituir y eliminar objetos de un segmento, así como crear objetos mediante subidas multiparte. N/A. Este permiso no se puede aplicar a objetos.
OWNER Otorga a un usuario todo el acceso que se concede con el permiso WRITER. También permite a un usuario leer y escribir metadatos de un segmento, incluidos los ACLs, y trabajar con etiquetas en el segmento. Otorga a un usuario todo el acceso que se concede con el permiso READER. También permite a un usuario leer y escribir metadatos de objetos, incluidas las listas de control de acceso.
Predeterminado Los segmentos tienen aplicada la ACL project-private predefinida cuando se crean. Los contenedores siempre son propiedad del grupo project-owners. Los objetos tienen aplicada la LCA project-private predefinida cuando se suben. Los objetos siempre son propiedad del solicitante original que los subió.

En esta página, nos referimos a los permisos como READER, WRITER y OWNER, que son los nombres que se especifican en la API JSON y en la consolaGoogle Cloud . Si usa la API XML, los permisos equivalentes son READ, WRITE y FULL_CONTROL, respectivamente.

Ámbitos

Los ámbitos especifican quién tiene un permiso determinado.

Una lista de control de acceso consta de una o varias entradas, y cada una de ellas concede permisos a un ámbito. Puede especificar un ámbito de LCA con cualquiera de las siguientes entidades:

Ámbito ("beneficiario") Tipos de entidad Ejemplo
Identificador especial de todas las entidades Usuario allUsers
Identificador especial de todas las cuentas válidas Usuario allAuthenticatedUsers
Dirección de correo de la cuenta de usuario Usuario jeffersonloveshiking@gmail.com
Dirección de correo de la cuenta de servicio Usuario my-service-account@my-project.iam.gserviceaccount.com
Dirección de correo de grupo de Google Grupo work-group@googlegroups.com
Valores de conveniencia de los proyectos Proyecto owners-123456789012
Dominio de Google Workspace Dominio dana@example.com
Dominio de Cloud Identity Dominio dana@example.com

  • Identificador especial de todas las entidades:

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

  • Identificador especial para todas las cuentas válidas:

    El identificador de ámbito especial allAuthenticatedUsers representa la mayoría de las cuentas autenticadas, incluidas las cuentas de servicio. Para obtener más información, consulta Principales de gestión de identidades y accesos. Ten en cuenta que, aunque este identificador es un tipo de entidad User, en la consola se etiqueta como un tipo de entidad Public. Google Cloud

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

    Todos los usuarios que tengan una cuenta de usuario deben tener una dirección de correo electrónico única asociada a esa cuenta. Puedes especificar un ámbito usando cualquier dirección de correo asociada a una cuenta de usuario.

    Cloud Storage recuerda las direcciones de correo electrónico tal como se proporcionan en las ACLs hasta que se eliminan o se sustituyen las entradas. Si un usuario cambia de dirección de correo, debe actualizar las entradas de la lista de control de acceso para reflejar estos cambios.

  • Dirección de correo de la cuenta de servicio:

    Cada cuenta de servicio tiene una dirección de correo única asociada. Puedes especificar un ámbito mediante la dirección de correo asociada a la cuenta de servicio.

  • Dirección de correo del grupo de Google:

    Cada grupo de Google tiene una dirección de correo única asociada al grupo. Por ejemplo, el grupo Cloud Storage Announce tiene la siguiente dirección de correo: gs-announce@googlegroups.com. Para encontrar la dirección de correo asociada a un grupo de Google, haz clic en Información en la página principal del grupo.

    Al igual que las direcciones de correo de las cuentas de usuario, Cloud Storage recuerda las direcciones de correo de los grupos tal como se proporcionan en las listas de control de acceso hasta que se eliminan las entradas. No tienes que preocuparte por actualizar las direcciones de correo de Grupos de Google, ya que son permanentes y es poco probable que cambien.

  • Valores de conveniencia para proyectos:

    Los valores de conveniencia te permiten conceder acceso masivo a los lectores, editores y propietarios de tu 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 encontrar el número de tu proyecto en la página principal de Google Cloud console.

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

  • Google Workspace o Cloud Identity:

    Los clientes de Google Workspace y Cloud Identity pueden asociar sus cuentas de correo a un nombre de dominio de Internet. Cuando lo hagas, cada cuenta de correo tendrá el formato USERNAME@YOUR_DOMAIN.com. Puedes especificar un ámbito usando cualquier nombre de dominio de Internet asociado a Google Workspace o Cloud Identity.

Permisos y ámbitos concéntricos

Cuando especifiques las ACLs en Cloud Storage, no tendrás que enumerar varios ámbitos para conceder varios permisos. Cloud Storage usa permisos concéntricos, por lo que, si concede el permiso WRITER, también concede el permiso READER. Del mismo modo, si concede el permiso OWNER, también concede los permisos READER y WRITER.

Al especificar una lista de control de acceso, la mayoría de las herramientas te permiten especificar varios ámbitos para la misma entrada. El permiso más permisivo es el acceso concedido al ámbito. Por ejemplo, si proporciona dos entradas para un usuario, una con permiso READER y otra con permiso WRITER en un bucket, el usuario tendrá permiso WRITER en el bucket.

En la API XML, no se pueden proporcionar dos entradas de LCA con el mismo ámbito. Por ejemplo, si se concede a un usuario el permiso READ y el permiso WRITE en un cubo, se produce un error. En su lugar, concede al usuario el permiso WRITE, que también le concede el permiso READ.

LCAs y gestión de identidades y accesos

Gestión de Identidades y Accesos (IAM) y las listas de control de acceso (LCAs) funcionan conjuntamente para conceder acceso a tus segmentos y objetos, lo que significa que un usuario solo necesita el permiso pertinente de cualquiera de estos sistemas para acceder a un segmento u objeto. Por lo general, los permisos concedidos por las políticas de gestión de identidades y accesos no aparecen en las listas de control de acceso, y los permisos concedidos por las listas de control de acceso no aparecen en las políticas de gestión de identidades y accesos. Para obtener más información, consulta la sección Relación entre la gestión de identidades y accesos y las LCA.

Comportamiento con la función de denegación de gestión de identidades y accesos

Una política de denegación de gestión de identidades y accesos anula cualquier acceso aplicable que, de lo contrario, se concedería mediante una LCA que hayas configurado, cuando la política de denegación y la LCA tengan como objetivo el mismo permiso.

Por ejemplo, si un segmento tiene una política de denegación que impide que un usuario tenga el permiso storage.objects.get y creas una LCA que le concede el rol READER en un objeto del segmento, el usuario no podrá ver el objeto en el segmento. Sin embargo, si la política de denegación especifica el permiso storage.buckets.get y la lista de control de acceso concede el rol WRITER en el segmento, el usuario no podrá recuperar los metadatos del segmento, pero sí podrá enumerar, crear y eliminar objetos en el segmento.

LCAs predefinidas

Una LCA predefinida, también conocida como LCA predeterminada, es un alias de un conjunto de entradas de LCA específicas que puedes usar para aplicar muchas entradas de LCA a la vez a un segmento o un objeto.

En la siguiente tabla se enumeran las LCAs predefinidas y se muestran las entradas de LCA que se aplican a cada una de ellas. Cuando uses la tabla que se muestra a continuación, ten en cuenta lo siguiente:

  • El grupo de propietarios del proyecto tiene la propiedad de los contenedores del proyecto, y el usuario que crea un objeto tiene la propiedad de ese objeto. Si un objeto lo ha creado un usuario anónimo, el grupo de propietarios del proyecto será el propietario del objeto.

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

    API JSON/gcloud storage API XML Descripción
    private private Da al propietario del segmento o del objeto el permiso OWNER para un segmento o un objeto.
    bucketOwnerRead bucket-owner-read Otorga al propietario del objeto el permiso OWNER y al propietario del segmento el permiso READER. Se usa solo con objetos.
    bucketOwnerFullControl bucket-owner-full-control Otorga el permiso OWNER a los propietarios del objeto y del segmento. Solo se usa con objetos.
    projectPrivate project-private Da permiso al equipo de proyecto según sus funciones. Cualquier miembro del equipo tiene permiso READER. Los propietarios y editores de proyectos tienen el permiso OWNER. Esta es la LCA predeterminada de los segmentos recién creados. Esta es también la LCA predeterminada de los objetos recién creados, a menos que se haya cambiado la LCA de objeto predeterminada de ese segmento.
    authenticatedRead authenticated-read Concede el permiso OWNER al propietario del objeto o del contenedor y el permiso READER a todos los titulares de cuentas de usuario autenticados.
    publicRead public-read Da permiso OWNER al propietario del objeto o del contenedor y permiso READER a todos los usuarios, tanto autenticados como anónimos. Si aplicas este permiso a un objeto, cualquier usuario de Internet podrá leerlo sin autenticarse. Si aplicas este permiso a un segmento, cualquier usuario de Internet podrá enumerar objetos sin autenticarse.

    * Consulta la nota al final de la tabla sobre el almacenamiento en caché.
    publicReadWrite public-read-write Da al propietario del contenedor el permiso OWNER y a todos los usuarios, tanto autenticados como anónimos, los permisos READER y WRITER. Esta LCA solo atañe a los depósitos. Si aplicas este permiso a un segmento, cualquier usuario de Internet podrá enumerar, crear, sustituir y eliminar objetos sin autenticarse.

    * Consulta la nota al final de la tabla sobre el almacenamiento en caché.

* De forma predeterminada, los objetos legibles públicamente se sirven con un encabezado Cache-Control que permite que los objetos se almacenen en caché durante 3600 segundos. Si necesitas que las actualizaciones se hagan visibles inmediatamente, debes definir los metadatos Cache-Control de los objetos como Cache-Control:private, max-age=0, no-transform.

LCAs predeterminadas

Cuando se crean contenedores o se suben objetos, si no les asignas una LCA de forma explícita, se les asigna la LCA predeterminada. Puede cambiar la LCA predeterminada asignada a un objeto. El proceso para hacerlo se describe en la sección Cambiar las LCA de objeto predeterminadas. Ten en cuenta que, cuando cambias la LCA predeterminada, las LCA de los objetos que ya existen en el segmento o los segmentos que ya existen en el proyecto no cambian.

LCAs de segmento predeterminadas

Todos los depósitos son propiedad del grupo de propietarios de proyecto. Además, los propietarios de proyectos tienen el permiso OWNER para cualquier segmento de su proyecto que use una LCA predefinida.

Si creas un segmento con la LCA predeterminada, es decir, si no especificas una LCA predeterminada al crear el segmento, este tendrá aplicada la LCA predeterminada projectPrivate.

LCAs de objeto predeterminadas

De forma predeterminada, cualquier persona que tenga el permiso OWNER o WRITER en un segmento puede subir objetos a ese segmento. Cuando subes un objeto, puedes proporcionar una LCA predefinida o no especificar ninguna. Si no especifica una LCA, Cloud Storage aplica al objeto la LCA de objeto predeterminada del segmento. Todos los segmentos tienen una LCA de objeto predeterminada, que se aplica a todos los objetos que se suben a ese segmento sin una LCA predefinida o una LCA especificada en la solicitud (solo en la API JSON). El valor inicial de la lista de control de acceso de objeto predeterminada de cada contenedor es projectPrivate.

En función de cómo se suban los objetos, las LCA de objeto se aplican de forma acorde:

  • Subidas autenticadas

    Si haces una solicitud autenticada para subir un objeto y no especificas ninguna LCA de objeto al subirlo, se te asignará como propietario del objeto y se aplicará al objeto la LCA predefinida projectPrivate de forma predeterminada. Esto significa que:

    • Se te designa (como persona que ha subido el objeto) propietario del objeto. La propiedad del objeto no se puede cambiar modificando las LCA, Solo puedes cambiar la propiedad de un objeto sustituyéndolo.

    • Se te concede (como propietario del objeto) el permiso OWNER en el objeto. Si intentas dar al propietario un permiso inferior a OWNER, Cloud Storage lo aumentará automáticamente a OWNER.

    • El grupo de propietarios y editores del proyecto tiene permiso OWNER en el objeto.

    • El grupo de miembros del equipo del proyecto tiene el permiso READER en el objeto.

  • Subidas anónimas

    Si un usuario no autenticado (anónimo) sube un objeto, lo que es posible si un contenedor concede al grupo allUsers el permiso WRITER o OWNER, se aplicarán al objeto las LCAs predeterminadas del contenedor, tal como se ha descrito anteriormente.

    Los usuarios anónimos no pueden especificar una LCA predefinida al subir objetos.

Comportamiento de las LCAs

Cloud Storage te ayuda a cumplir las prácticas recomendadas aplicando algunas reglas de modificación de las listas de control de acceso (LCAs), que te impiden definir LCAs que hagan que los datos sean inaccesibles:

  • No puedes aplicar una LCA que especifique un propietario de objeto o de contenedor diferente.

    La propiedad del objeto o del depósito no se puede cambiar modificando las LCA, Si aplicas una nueva LCA a un segmento o un objeto, asegúrate de que el propietario del segmento o del objeto no cambie en la nueva LCA.

  • El propietario del segmento o del objeto siempre tiene permiso OWNER del segmento o del objeto.

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

    Cuando aplicas una nueva LCA a un segmento o a un objeto, Cloud Storage añade el permiso OWNER al propietario del segmento o del objeto, respectivamente, si omites las concesiones. No concede al grupo de propietarios del proyecto OWNERpermiso para un objeto (a menos que el objeto lo haya creado un usuario anónimo), por lo que debes incluirlo explícitamente.

No puede aplicar LCAs que cambien la propiedad de un segmento o un objeto (que no debe confundirse con el permiso OWNER). Una vez creados en Cloud Storage, la propiedad de los segmentos y los objetos es permanente. Sin embargo, puedes cambiar la propiedad de los objetos (pero no de los contenedores) sustituyéndolos. La sustitución es básicamente una operación de eliminación seguida inmediatamente de una operación de subida. Durante una operación de subida, la persona que la realiza se convierte en el propietario del objeto. Ten en cuenta que, para sustituir un objeto, la persona que realice la sustitución (y que, por lo tanto, obtendrá la propiedad del objeto) debe tener el permiso WRITER o OWNER en el segmento en el que se suba el objeto.

Siguientes pasos