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 quieres 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 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 quieras usar las LCA si tienes que personalizar el acceso para 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, aplicas las LCA a depósitos y objetos individuales. Cada LCA se conforma de una o más entradas. Una entrada le 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 se lo llama 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 todos puedan acceder a sus objetos, pero también quieres que tu colaborador sea capaz de agregar o quitar objetos desde tu depósito. En este caso, tu LCA debería tener las dos entradas siguientes:

  • En una entrada, le darías 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, como con su correo electrónico).

El número máximo de estradas 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 LCA sin importar la cantidad de usuarios que haya en el grupo o dominio.

Cuando un usuario solicita acceso a un depósito o a un objeto, el sistema de Cloud Storage lee la LCA del depósito o del objeto y determina si permite o rechaza la solicitud de acceso. Si la LCA otorga permiso al usuario para la operación solicitada, se permite la solicitud. Si la LCA no otorga permiso al usuario para la operación solicitada, la solicitud falla y 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 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 depósito, sin incluir las LCA. Permite que un usuario descargue los datos de un objeto.
WRITER Permite que los usuarios realicen una lista, 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 del depósito, incluso las LCA. Otorga a un usuario permiso READER. También le permite a un usuario leer y escribir metadatos del objeto, incluidas las LCA.
Default Los depósitos tienen la LCA predefinida project-private ya aplicada en el momento en que se crean. Los depósitos siempre tienen como propietario al 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 especifican en la API de JSON y en Google Cloud Platform Console. Si usas la API de XML, los permisos equivalentes son READ, WRITE y FULL_CONTROL, respectivamente. Y cuando usas la autenticación de OAuth 2.0 con el fin de autenticar herramientas y aplicaciones (otorgarles permiso) para que accedan a la API de Google Cloud Storage en tu nombre, el acceso se restringe por OAuth scope 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 puedes encontrar con frecuencia:

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 encontrar la dirección de correo electrónico asociada a un Grupo de Google con un clic en Sobre en la página principal de cada Grupo de Google. Para obtener más información sobre los Grupos de Google, consulta la página principal de Grupos de Google.

    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 lectores 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 toma la forma [USERNAME]@[YOUR_DOMAIN].com. Puedes especificar un alcance con un nombre de dominio de Internet asociado a G Suite o Cloud Identity.

  • Identificador especial para todos los titulares de Cuenta 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 Cuenta 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. Cloud Storage usa 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 Platform 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 el permiso READ y el permiso 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 por situaciones comunes, como revocar todos los permisos de acceso excepto los permisos de 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 de más abajo:

  • 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 un objeto o depósito 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. Este 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. Este 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 permiso READER. Los propietarios del proyecto y editores del proyecto tienen el permiso OWNER. Esta es la LCA predeterminada para los depósitos creados nuevos. Esta también es la LCA predeterminada para los objetos creados nuevos, a menos que se haya cambiado la LCA predeterminada del 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, tanto los autenticados como los 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, tanto los autenticados como los anónimos, los permisos READER y WRITER. Esta LCA aplica solo a los depósitos. Cuando lo 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é.

* Según la configuración predeterminada, los objetos legibles de forma pública se entregan con un encabezado Cache-Control que permite a los objetos almacenarse en caché durante 3,600 segundos. Si necesitas garantizar que las actualizaciones se vuelvan visibles de inmediato, debes establecer los metadatos de Cache-Control para los objetos en Cache-Control:private, max-age=0, no-transform.

LCA predeterminadas

Cuando se crean depósitos o se suben objetos, si no les asignas una LCA de forma explícita, se les otorga la LCA predeterminada. Puedes cambiar la LCA predeterminada de un objeto; el proceso se describe en Cambia las LCA predeterminadas de un objeto. Ten en cuenta que cuando cambias la LCA predeterminada, las LCA de objetos que ya existen en el depósito o depósitos que existen 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, no especificas una LCA predefinida cuando creas el depósito, tu depósito tiene la LCA predefinida projectPrivate aplicada. 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 les proporciona a los lectores 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 a 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 otorga a los propietarios del proyecto los permisos OWNER. Los propietarios del proyecto también pueden realizar todas las mismas tareas que los editores del proyecto, además de las tareas administrativas como agregar o quitar miembros del equipo, o cambiar información de la facturación.

Los lectores del proyecto, editores del proyecto y propietarios del proyecto se identifican por 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 encontrar el número del proyecto en la página principal de Google Cloud Platform Console.

LCA de objetos predeterminadas

De forma predeterminada, cualquiera con el permiso OWNER o el permiso WRITER sobre un depósito puede subir objetos a ese depósito. Cuando subes un objeto, puedes proporcionar una LCA predefinida o no especificar una ACL. 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 y esa LCA se aplica a todos los objetos subidos a ese depósito sin una LCA predefinida o una LCA especificada en la solicitud (solo 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 objetos se aplican acorde a lo siguiente:

  • Cargas autenticadas

    Si haces una solicitud autenticada para subir un objeto y no especificas ninguna LCA de objeto cuando los subes, entonces estás en la lista 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ú (el propietario del objeto) tienes otorgado permiso OWNER sobre el objeto. Si intentas dar al propietario permiso menor que OWNER, Cloud Storage de forma automática escala el permiso a OWNER.

    • El grupo de propietarios del proyecto y el grupo de editores del proyecto tienen 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 otorga el permiso OWNER o WRITER al grupo allUsers, entonces las LCA de depósito predeterminadas se aplican al objeto como se describe arriba.

    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 opciones de configuración de 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 siguientes recomendaciones:

  • 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órgales el permiso READER y no el permiso 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. Deberías usar el permiso OWNER solo cuando quieras delegar el control administrativo sobre los objetos y depósitos.

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

    Los alcances de allUsers y allAuthenticatedUsers solo deberían usarse cuando es aceptable que cualquiera en Internet lea y analice tus datos. Si bien 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. A fin de evitar este problema, puedes usar las LCA bucket-owner-read o bucket-owner-full- control predefinidas cuando tú o alguien más sube 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 el 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 deja el grupo, otros propietarios del proyecto aún pueden 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 cumplir con estas recomendaciones 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 el grupo de propietarios del proyecto si un usuario anónimo subió el objeto.

    Cuando aplicas una LCA nueva a un depósito o a un objeto, Cloud Storage agrega respectivamente el permiso 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 un usuario anónimo haya creado el objeto), por lo que debes incluirlos de forma explícita.

No puedes aplicar las LCA que cambian la propiedad de un depósito o un objeto (que no debería confundirse 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 realiza la carga se convierte en el propietario del objeto. Recuerda que, para reemplazar un objeto, la persona que realiza el reemplazo (y que, al hacerlo, adquiere la propiedad del objeto) debe tener permiso OWNER o WRITER sobre el depósito en el que se sube el objeto.

¿Te sirvió esta página? Envíanos tu opinión:

Enviar comentarios sobre…

¿Necesitas ayuda? Visita nuestra página de asistencia.