Listas de control de acceso (LCA)

En esta página, se proporciona una descripción general de las listas de control de acceso (LCA). Si deseas obtener información sobre cómo configurar y administrar las LCA, lee Crea y administra listas de control de acceso. Para obtener información sobre otras formas de controlar el acceso a los depósitos y objetos, consulta la Descripción general del control de acceso.

¿Debería usar listas de control de acceso?

En la mayoría de los casos, Cloud Identity and Access Management (Cloud IAM) es el método recomendado para controlar el acceso a tus recursos. Cloud IAM y las LCA trabajan juntas a fin de otorgar acceso a tus depósitos y objetos: un usuario solo necesita permiso desde Cloud IAM o una LCA para acceder a un depósito o a un objeto.

Es muy probable que desees usar las LCA si tienes que personalizar el acceso a objetos individuales dentro de un depósito, ya que los permisos de Cloud IAM aplican a todos los objetos dentro de un depósito. Sin embargo, aún debes usar Cloud IAM para cualquier acceso que sea común a todos los objetos en un depósito, porque esto reduce la cantidad de microadministración que tienes que realizar.

¿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 depósitos y objetos, así como qué nivel de acceso tienen. En Cloud Storage, las LCA se aplican a depósitos 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 dos datos, que se muestran 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 depósito y deseas que cualquiera pueda acceder a los objetos en él, pero también deseas que tu colaborador pueda agregar o quitar objetos del depósito. En este caso, tu LCA debería tener las dos entradas siguientes:

  • 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, con su correo electrónico).

El número máximo de entradas de LCA que puedes crear para un depósito o un objeto es 100. Cuando el alcance de la entrada es un grupo o dominio, cuenta como una entrada de LCA sin importar la cantidad de usuarios que haya en el grupo o dominio.

Cuando un usuario solicita acceso a un depósito o un objeto, el sistema de Cloud Storage lee la LCA del contenedor 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 crear 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 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 depósito, sin incluir las LCA. Permite que un usuario descargue los datos de un objeto.
WRITER Permite que los usuarios enumeren, creen, reemplacen y borren objetos en un depósito 1. No corresponde. No puedes aplicar este permiso a los objetos.
OWNER Otorga a un usuario permisos READER y WRITER sobre el depósito. También permite que un usuario lea y escriba metadatos de depósito, incluidas las LCA. Otorga permiso READER a un usuario. También permite que un usuario lea y escriba metadatos de objeto, incluidas las LCA.
Predeterminada Los depósitos tienen la LCA predefinida project-private ya aplicada en el momento en que se crean. Los depósitos 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.

1 Las siguientes propiedades de metadatos del depósito no se pueden cambiar: acl, cors, defaultObjectAcl, lifecycle, logging, versioning y website.

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 Google Cloud Console. Si usas la API de XML, los permisos equivalentes respectivos son READ, WRITE y FULL_CONTROL. Cuando usas la autenticación de OAuth 2.0 a fin de autenticar herramientas y aplicaciones (concederles permisos) para acceder a la API de Google Cloud Storage en tu nombre, el acceso se restringe por los alcances de OAuth devstorage.read_only, devstorage.read_write y devstorage.full_control. En la tabla a continuación, se resume la terminología de los permisos que se suelen encontrar:

API de JSON API de XML Alcance de OAuth2
READER READ https://www.googleapis.com/auth/devstorage.read_only
WRITER WRITE https://www.googleapis.com/auth/devstorage.read_write
OWNER FULL_CONTROL https://www.googleapis.com/auth/devstorage.full_control

Alcances

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
Dirección de correo electrónico de la Cuenta de Google 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 G Suite Dominio [USERNAME]@[YOUR_DOMAIN].com
Dominio de Cloud Identity Dominio [USERNAME]@[YOUR_DOMAIN].com
Identificador especial para todos los titulares de Cuentas de Google Usuario allAuthenticatedUsers
Identificador especial para todos los usuarios Usuario allUsers
  • Dirección de correo electrónico de la Cuenta de Google:

    Cada usuario que tiene una Cuenta de Google debe tener una dirección de correo electrónico única asociada a esa cuenta. Puedes especificar un alcance mediante cualquier dirección de correo electrónico asociada a una Cuenta de Google, como una dirección gmail.com.

    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. Para obtener más información sobre los Grupos de Google, consulta su página principal.

    Al igual que las direcciones de correo electrónico de las Cuentas de Google, Cloud Storage recuerda las direcciones de correo electrónico de grupos como se proporcionan en las LCA hasta que se quitan o se reemplazan 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 owners-<project-number>, editors-<project-number> y viewers-<project-number> representan las listas de propietarios, editores y visualizadores del proyecto cuyo número de proyecto es <project-number>.

  • G Suite o Cloud Identity:

    Los clientes de G Suite 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 G Suite o Cloud Identity.

  • Identificador especial para todos los titulares de Cuentas de Google:

    Este identificador de alcance especial representa a cualquiera que se autentica con una Cuenta de Google. El identificador de alcance especial para todos los titulares de Cuentas de Google es allAuthenticatedUsers.

  • Identificador especial para todos los usuarios:

    Este identificador de alcance especial representa a cualquiera que esté en Internet, con una Cuenta de Google o sin ella. El identificador de alcance especial para todos los usuarios es allUsers.

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 permiso READER, y si otorgas un permiso OWNER, también otorgas permisos READER y WRITER.

Cuando especificas una LCA con Google Cloud Console, la API de JSON o gsutil, puedes 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 depósito, el usuario tendrá permiso WRITER en el depósito.

En la API de XML, no es posible proporcionar dos entradas de LCA con el mismo alcance. Por ejemplo, otorgar a un usuario los permisos READ y WRITE sobre un depósito 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 o “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 depósito o un objeto. Las LCA predefinidas se definen para situaciones comunes, como revocar todos los permisos de acceso, excepto el permiso del propietario (LCA predefinida private) o hacer que un objeto sea legible de forma pública (LCA predefinida publicRead).

En la tabla a continuación se enumeran las LCA predefinidas que puedes usar y se muestra qué entradas de LCA se aplican por cada LCA predefinida. Ten en cuenta lo siguiente cuando uses la tabla a continuación:

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

    API de JSON gsutil/API de XML Descripción
    private private Le da al propietario del objeto o depósito el permiso OWNER para este y quita todos los otros permisos de acceso.
    bucketOwnerRead bucket-owner-read Otorga el permiso OWNER al propietario del objeto y el permiso READER al propietario del depósito. Se quitan todos los otros permisos. Esto solo se usa con objetos.
    bucketOwnerFullControl bucket-owner-full-control Les da a los propietarios de objetos y depósitos el permiso OWNER. Se quitan todos los otros permisos. 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 depósito.
    authenticatedRead authenticated-read Otorga al propietario del objeto o depósito el permiso OWNER y les otorga a todos los titulares de Cuentas de Google autenticados el permiso READER. Se quitan todos los otros permisos.
    publicRead public-read Le da al propietario del depósito o del objeto el permiso OWNER y a todos los usuarios, autenticados y anónimos, el permiso READER. Cuando aplicas esto a un objeto, cualquiera en Internet puede leer el objeto sin necesidad de autenticarse. Cuando aplicas esto a un depósito, 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 depósito el permiso OWNER, y a todos los usuarios, autenticados y anónimos, los permisos READER y WRITER. Esta LCA aplica solo a los depósitos. Cuando la aplicas a un depósito, 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 depósito predeterminadas

Todos los depósitos son propiedad del grupo de propietarios del proyecto. A los propietarios del proyecto se les otorga permiso OWNER de forma automática a todos los depósitos dentro de su proyecto. Cuando creas un proyecto, se te agrega como propietario del proyecto de forma automática.

Si creas un depósito con la LCA de depósito predeterminada, es decir, si no especificas una LCA predefinida, se aplica la LCA predefinida projectPrivate. La LCA projectPrivate otorga permisos adicionales a los miembros del equipo del proyecto según sus funciones. Estos permisos adicionales se definen de la siguiente manera:

  • Lectores del proyecto

    La LCA projectPrivate proporciona a los visualizadores del proyecto el acceso READER a los depósitos de un proyecto. Todos los miembros del equipo del proyecto pueden enumerar objetos dentro de los depósitos. Todos los miembros del equipo del proyecto pueden también enumerar depósitos dentro de un proyecto, sin importar las LCA del depósito.

  • Editores del proyecto

    La LCA projectPrivate proporciona a los editores del proyecto los permisos OWNER para los depósitos de un proyecto. Los editores del proyecto pueden enumerar los contenidos del depósito y crear, reemplazar o borrar objetos en un depósito. Los editores del proyecto también pueden enumerar, crear o borrar depósitos, sin importar las LCA del proyecto.

  • Propietarios del proyecto

    La LCA projectPrivate proporciona a los propietarios de un proyecto los permisos OWNER. Los propietarios del proyecto también pueden realizar todas las mismas tareas que los editores del proyecto, además de tareas administrativas, como agregar o quitar miembros del equipo, o cambiar los datos de facturación.

Los visualizadores, editores y propietarios del proyecto se identifican mediante la combinación de sus funciones con el número del proyecto asociado. Por ejemplo, en el proyecto 867489160491, los editores se identifican como project-editors-867489160491. Puedes buscar el número del proyecto en la página principal de Google Cloud Console.

LCA de objetos predeterminadas

De forma predeterminada, cualquier persona con los permisos OWNER o WRITER sobre un depósito puede subir objetos a este. Cuando subes un objeto, puedes proporcionar una LCA predefinida o no especificar ninguna. Si no especificas una LCA, Cloud Storage aplica la LCA de objetos predeterminada del depósito a ese objeto. Cada depósito tiene una LCA de objeto predeterminada que se aplica a todos los objetos subidos a ese depósito 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 mediante el reemplazo de un objeto.

    • Tú (como propietario del objeto) tienes otorgado el 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.

Recomendaciones

Las LCA, como cualquier otra configuración administrativa, necesitan una administración activa para que sean efectivas. Antes de hacer un objeto o depósito accesible a todos los usuarios, asegúrate de saber con quién deseas compartir el depósito o el objeto y qué funciones quieres que tengan cada una de esas personas. Con el paso del tiempo, los cambios en la administración del proyecto, los patrones de uso y la propiedad de la organización podrían necesitar que modifiques las opciones de configuración de la LCA sobre depósitos y objetos, en particular, si administras depósitos y objetos en una organización grande o para un grupo grande de usuarios. A medida que evalúes y planifiques tu configuración de control de acceso, ten en cuenta las prácticas recomendadas siguientes:

  • Usa el principio de privilegios mínimos cuando otorgues acceso a tus depósitos y objetos.

    El principio de privilegios mínimos es una guía de seguridad para otorgar privilegios o derechos. Cuando otorgas acceso según este principio, otorgas los privilegios mínimos necesarios para que un usuario realice su tarea asignada. Por ejemplo, si quieres compartir un archivo con alguien, otórgale el permiso READER, no el OWNER.

  • Evita otorgar el permiso OWNER a personas que no conoces.

    Otorgar el permiso OWNER permite que los usuarios cambien las LCA y controlen los datos. Debes usar el permiso OWNER solo cuando quieras delegar el control administrativo sobre objetos y depósitos.

  • Ten cuidado con la forma en la que otorgas permisos para usuarios anónimos.

    Los alcances allUsers y allAuthenticatedUsers solo deben usarse cuando es aceptable que alguien en Internet lea y analice tus datos. Aunque estos alcances son útiles para algunas aplicaciones y situaciones, por lo general, no es una buena idea otorgar el permiso OWNER a todos los usuarios.

  • Evita configurar las LCA que dan como resultado objetos inaccesibles.

    Un objeto inaccesible es un objeto que no se puede descargar (lectura) y solo se puede borrar. Esto puede suceder cuando el propietario de un objeto lo abandona sin otorgar a nadie más el permiso OWNER o READER sobre el objeto. Para evitar este problema, puedes usar las LCA predefinidas bucket-owner-read o bucket-owner-full- control cuando alguien suba objetos a tus depósitos.

  • Asegúrate de delegar el control administrativo de tus depósitos.

    De forma predeterminada, el grupo de propietarios del proyecto es la única entidad que tiene permiso OWNER sobre un depósito cuando se crea. Debe haber al menos dos miembros en el grupo de propietarios del proyecto en cualquier momento dado, de forma tal que, si un miembro abandona el grupo, otros propietarios del proyecto aún puedan administrar tus depósitos.

  • Presta atención al comportamiento interoperable de Cloud Storage.

    Cuando usas la API de XML para acceso interoperable con otros servicios de almacenamiento, como Amazon S3, el identificador de la firma determina la sintaxis de LCA. Por ejemplo, si la herramienta o biblioteca que usas realiza una solicitud a Cloud Storage para recuperar las LCA y la solicitud usa el identificador de firma de otro proveedor de almacenamiento, entonces Cloud Storage muestra un documento XML con la sintaxis de LCA del proveedor de almacenamiento correspondiente. Si la herramienta o biblioteca que usas realiza una solicitud a Cloud Storage para que aplique las LCA y la solicitud usa el identificador de firma de otro proveedor de almacenamiento, entonces Cloud Storage espera recibir un documento XML con la sintaxis de LCA del proveedor de almacenamiento correspondiente.

    Si quieres obtener información sobre el uso de la API de XML para acceso interoperable con Amazon S3, consulta Migra desde Amazon S3 a Google Cloud Storage.

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 depósito diferente.

    La propiedad de depósito y objetos no se puede cambiar mediante la modificación de las LCA. Si aplicas una LCA nueva a un depósito o un objeto, asegúrate de que el propietario del depósito 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 depósito 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 depósito o a un objeto, Cloud Storage agrega el permiso respectivo OWNER al depósito 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 depósito 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 depósito en el que se sube el objeto.

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...

Si necesitas ayuda, visita nuestra página de asistencia.