Gestión de identidades y accesos

Esta página ofrece una descripción general de la gestión de identidades y accesos (IAM) y su uso para controlar el acceso a segmentos y objetos en Cloud Storage. Para aprender a configurar y gestionar los permisos de IAM para los segmentos y proyectos de Cloud Storage, consulta el apartado sobre el uso de permisos de gestión de identidades y accesos. Para obtener más información sobre otras formas de controlar el acceso a segmentos y objetos, consulta la información general sobre el control de acceso.

Esta página se centra en aspectos de gestión de identidades y accesos que corresponden específicamente a Cloud Storage. Para obtener una descripción detallada de la gestión de identidades y accesos y sus características en general, consulta la guía para desarrolladores sobre gestión de identidades y accesos de Google Cloud. En concreto, consulta la sección sobre la administración de políticas de gestión de identidades y accesos.

Visión general

La gestión de identidades y accesos Google Cloud (IAM) te permite controlar quién tiene acceso a los recursos en tu proyecto de Google Cloud Platform. Entre los recursos se incluyen segmentos de Cloud Storage y objetos almacenados en segmentos, así como otras entidades de GCP, como instancias de Compute Engine.

El conjunto de reglas de acceso que se aplica a un recurso se denomina política de gestión de identidades y accesos. La política de gestión de identidades y accesos que se aplica a un proyecto define las acciones que los usuarios pueden realizar en todos los objetos o segmentos dentro de dicho proyecto. Una política de gestión de identidades y accesos aplicada a un solo segmento define las acciones que los usuarios pueden realizar en el segmento y en los objetos dentro de él.

Por ejemplo, puedes crear una política de gestión de identidades y accesos para uno de tus segmentos que otorgue a un usuario el control administrativo de dicho segmento. Mientras tanto, puedes agregar otro usuario a la política de gestión de identidades y accesos de todo el proyecto y que le dé a dicho usuario la capacidad de ver objetos en cualquier segmento.

Los miembros son el "quién" de la gestión de identidades y accesos. Pueden ser usuarios individuales, grupos, dominios o incluso el público en general. Se les asignan funciones, gracias a las cuales tienen la capacidad de realizar acciones en Cloud Storage y GCP en general. Cada función es una colección de uno o más permisos. Los permisos son las unidades básicas de la gestión de identidades y accesos: cada permiso te permite realizar una acción determinada.

Por ejemplo, el permiso storage.objects.create permite crear objetos. Se encuentra en funciones como roles/storage.objectCreator, donde es el único permiso, o roles/storage.objectAdmin, donde hay numerosos permisos agrupados. Si le asignas a un miembro la función roles/storage.objectCreator para un segmento específico, solo podrá crear objetos en ese segmento. Si asignas a otro miembro la función roles/storage.objectAdmin para el segmento, podrá realizar tareas adicionales, como eliminar objetos, pero solo dentro de ese segmento. Si a estos dos usuarios se les asignan estas funciones y no otras, no tendrán constancia de ningún otro segmento de tu proyecto. Si le asignas a un tercer miembro la función roles/storage.objectAdmin, pero para todo el proyecto y no para un solo segmento, tendrá acceso a cualquier objeto en cualquier segmento del proyecto.

El uso de la gestión de identidades y accesos de Cloud Storage facilita la limitación de permisos de un miembro sin tener que modificar cada segmento o permiso de objeto de forma individual.

Permisos

Los permisos sirven para que los miembros puedan realizar acciones específicas en segmentos u objetos en Cloud Storage. Por ejemplo, el permiso storage.buckets.list permite a los miembros agrupar los segmentos en el proyecto. A los miembros no les das permisos directamente; en su lugar, asignas funciones, que tienen uno o más permisos agrupados dentro de ellas.

Para obtener una lista de referencia de los permisos de gestión de identidades y accesos que se aplican a Cloud Storage, consulta el apartado sobre permisos de gestión de identidades y accesos de Cloud Storage.

Funciones

Las funciones son un paquete de uno o más permisos. Por ejemplo, roles/storage.objectViewer contiene los permisos storage.objects.get y storage.objects.list. Se asignan funciones a los miembros, lo que les permite realizar acciones en los segmentos y objetos en tu proyecto.

Para obtener una lista de referencia de las funciones de gestión de identidades y accesos que se aplican a Cloud Storage, consulta el apartado sobre las funciones de gestión de identidades y accesos de Cloud Storage.

Funciones de nivel de proyecto frente a funciones de nivel de segmento

La asignación de funciones de nivel de segmento no afecta a ninguna función existente que hayas concedido de nivel de proyecto, y viceversa. Por lo tanto, puedes usar estos dos niveles de granularidad para personalizar tus permisos. Por ejemplo, supongamos que deseas conceder permiso a un usuario para leer objetos en cualquier segmento, pero crear objetos solo en un segmento específico. Para ello, asigna al usuario la función roles/storage.objectViewer de nivel de proyecto, que le permitirá leer cualquier objeto almacenado en cualquier segmento, y asígnale la función roles/storage.objectCreator de nivel de segmento para un segmento específico, con lo que podrá crear objetos solo en ese segmento.

Algunas funciones se pueden usar tanto con nivel de proyecto como de segmento. Cuando se utilizan con nivel de proyecto, los permisos que contienen se aplican con todos los segmentos y objetos del proyecto. Cuando se usan con nivel de segmento, los permisos solo se aplican a un segmento específico y a los objetos que contiene. Ejemplos de dichas funciones son roles/storage.admin, roles/storage.objectViewer y roles/storage.objectCreator.

Algunas funciones solo se pueden aplicar en un nivel. Por ejemplo, solo puede aplicar la función de Viewer de nivel de proyecto, mientras que solo puede aplicar roles/storage.legacyObjectOwner de nivel de segmento.

Relación con las LCA

Las funciones de gestión de identidades y accesos de segmentos heredados funcionan junto con las LCA de segmento: cuando añades o quitas una función de segmento heredado, las LCA asociadas al segmento reflejan tus cambios. Del mismo modo, al cambiar una LCA específica del segmento, se actualiza la función correspondiente del segmento heredado.

Función de segmento heredado LCA equivalente
roles/storage.legacyBucketReader Lector de segmentos
roles/storage.legacyBucketWriter Escritor de segmentos
roles/storage.legacyBucketOwner Propietario del segmento

Todas las demás funciones de gestión de identidades y accesos de nivel de segmento, y de proyecto funcionan independientemente de las LCA. Por ejemplo, si asignas a un usuario la función de visor de objetos de almacenamiento, las LCA no se modificarán. Esto significa que puede usar funciones de gestión de identidades y accesos de nivel de segmento para otorgar un amplio acceso a todos los objetos dentro de un segmento y usar las LCA de objeto detalladas para personalizar el acceso a objetos específicos dentro del segmento.

Permiso de gestión de identidades y accesos para cambiar las LCA

Puede usar la gestión de identidades y accesos para otorgar a los miembros el permiso necesario para cambiar LCAs en objetos. Los siguientes permisos storage.buckets en conjunto permiten a los usuarios trabajar con LCAs de segmento y de objeto predeterminado: .get, .getIamPolicy, .setIamPolicy y .update.

De forma similar, los siguientes permisos storage.objects juntos permiten a los usuarios trabajar con LCAs de objetos: .get, .getIamPolicy, .setIamPolicy y .update.

Funciones personalizadas

Si bien la gestión de identidades y accesos tiene muchas funciones predefinidas que abarcan casos prácticos en común, es posible que desees definir tus propias funciones que contienen contengan paquetes de permisos que especifiques. Para hacer esto posible, la gestión de identidades y accesos ofrece funciones personalizadas.

Tipos de miembros

Hay varios tipos diferentes de miembros. Por ejemplo, las cuentas y grupos de Google representan dos tipos generales, mientras que allAuthenticatedUsers y allUsers son dos tipos especializados. Para ver una lista de tipos comunes de miembros en la gestión de identidades y accesos, consulta el apartado sobre conceptos relacionados con la identidad. Además de los tipos que se enumeran, la gestión de identidades y accesos admite los siguientes tipos de miembros, que se pueden aplicar específicamente a las políticas de IAM de tu segmento de Cloud Storage:

  • projectOwner:[PROJECT_ID]
  • projectEditor:[PROJECT_ID]
  • projectViewer:[PROJECT_ID]

Donde [PROJECT_ID] es el ID de un proyecto específico.

Cuando otorgas una función a uno de los tipos de miembros anteriores, todos los miembros con el permiso especificado para el proyecto especificado obtienen la función que hayas seleccionado. Por ejemplo, supongamos que quieres otorgar a todos los miembros que tengan la función de Viewer para el proyecto my-example-project la función roles/storage.objectCreator para uno de tus segmentos. Para ello, asigna al miembro projectViewer:my-example-project la función roles/storage.objectCreator para ese segmento.

Uso con herramientas de Cloud Storage

Aunque los permisos de gestión de identidades y accesos no se pueden establecer a través de la API XML, los usuarios a los que se les otorgaron estos permisos aún pueden usar la, así como cualquier otra herramienta para acceder a Cloud Storage.

Para ver las referencias de los permisos de gestión de identidades y accesos que permiten a los usuarios realizar acciones con diferentes herramientas de Cloud Storage, consulta los apartados sobre IAM con Cloud Console, IAM con gsutil, IAM con JSON e IAM con XML.

Prácticas recomendadas

La gestión de identidades y accesos, como cualquier otra configuración administrativa, requiere una gestión activa para ser efectiva. Antes de hacer un segmento u objeto accesible para otros usuarios, asegúrate de saber con quién deseas compartir el segmento u objeto y qué funciones deseas que tenga cada una de esas personas. Con el tiempo, los cambios en la gestión del proyecto, los patrones de uso y la propiedad de la organización pueden requerir que modifiques la configuración de IAM en segmentos y proyectos, especialmente si administras Cloud Storage en una organización grande o para un gran grupo de usuarios. Cuando evalúes y planifiques la configuración de control de acceso, ten en cuenta las siguientes prácticas recomendadas:

  • Usa el principio de privilegio mínimo al otorgar acceso.

    El principio de privilegio menor es una directiva de seguridad para conceder privilegios o derechos. Cuando se concede acceso basado en este principio, se concede el principio mínimo que sea necesario para que un usuario cumpla su tarea asignada. Por ejemplo, si quieres compartir un archivo con alguien, asígnale la función storage.objectReader y no la función storage.admin.

  • Procura no otorgar funciones con el permiso setIamPolicy a personas que no conoces.

    Conceder el permiso setIamPolicy permite a los usuarios cambiar los permisos y tomar el control de los datos. Debes usar funciones con el permiso setIamPolicy solo cuando desees delegar el control administrativo sobre objetos y segmentos.

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

    Los tipos de miembros allUsers y allAuthenticatedUsers solo deben utilizarse cuando es aceptable que cualquier persona en Internet lea y analice tus datos. Si bien estos permisos son útiles para algunas aplicaciones y casos, generalmente no es una buena idea conceder ciertos permisos a todos los usuarios, como setIamPolicy , update , create o delete.

  • Conoce las funciones del proyecto Viewer/Editor/Owner en Cloud Storage.

    Las funciones de nivel de proyecto de Viewer/Editor/Owner otorgan efectivamente el acceso que implican sus nombres dentro de Cloud Storage. Sin embargo, lo hacen de forma indirecta a través del acceso adicional que se proporciona en el segmento y los niveles de objeto, utilizando tipos de miembros exclusivos de Cloud Storage. Aunque el acceso se agrega de forma predeterminada, puedes revocarlo.

    Por ejemplo, la función de Viewer, por sí sola, solo otorga un permiso storage.buckets.list a los miembros, pero los nuevos segmentos, de forma predeterminada, otorgan la función roles/storage.legacyBucketReader a todos los miembros con la función de Viewer para el proyecto. Esta función de segmento es la que permite a un Viewer ver un segmento. Además, el segmento tiene una LCA de objeto predeterminado de projectPrivate, lo que significa que los objetos añadidos al segmento obtienen, de forma predeterminada, la LCA projectPrivate. Esta LCA es la que permite a un Viewer ver el objeto.

    Del mismo modo, las funciones Editor y Owner del proyecto tienen acceso limitado a Cloud Storage por sí solas, pero los miembros con estas funciones asignadas obtienen roles/storage.legacyBucketOwner para nuevos segmentos, así como la propiedad de los objetos a través de la LCA projectPrivate.

    Ten en cuenta que, debido a que el acceso a un segmento y a un objeto no es inherente a las funciones del proyecto de Viewer/Editor/Owner, es posible revocar el acceso que los miembros podrían esperar tener.

  • Evita definir LCAs que provoquen objetos inaccesibles.

    Un objeto inaccesible es un objeto que no se puede descargar (leer) y solo se puede eliminar. Este caso puede darse cuando el propietario de un objeto abandona un proyecto y no hay políticas de gestión de identidades y accesos de nivel de proyecto o de segmento que otorguen acceso a los objetos. Si esto ocurre, puedes recuperar el acceso al objeto asignando una función apropiada, como roles/storage.objectAdmin, a ti u otro miembro. Ten en cuenta que, al hacerlo, proporcionas acceso a todos los objetos del segmento o proyecto.

  • Asegúrate de que delegas el control administrativo de tus segmentos.

    De forma predeterminada, los miembros con la función de Owner de nivel de proyecto son las únicas entidad que tienen la función roles/legacyBucketOwner en un segmento recién creado. Debes tener al menos dos miembros con la función de Owner en un momento determinado, de modo que, si un miembro del equipo abandona el grupo, los otros miembros puedan seguir administrando los segmentos.

Siguientes pasos

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

Enviar comentarios sobre…

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