Cloud Identity and Access Management

En esta página, se proporciona una descripción general de Cloud Identity and Access Management (Cloud IAM) y su uso para controlar el acceso a los depósitos y objetos en Cloud Storage. Si deseas obtener más información sobre cómo configurar y administrar los permisos de Cloud IAM para los depósitos y proyectos de Cloud Storage, consulta Usa los permisos de Cloud IAM. A fin de obtener más información sobre otras maneras de controlar el acceso a los depósitos y objetos, consulta Descripción general del control de acceso.

En esta página, se describen aspectos de Cloud IAM relevantes para Cloud Storage en específico. A fin de ver un análisis más detallado de Cloud IAM y sus características en general, consulta la guía para desarrolladores de Cloud Identity and Access Management. En particular, consulta la sección sobre cómo administrar las políticas de Cloud IAM.

Descripción general

Con Cloud Identity and Access Management (Cloud IAM) puedes controlar quién tiene acceso a los recursos en tu proyecto de Google Cloud. En los recursos, se incluyen los objetos y depósitos de Cloud Storage almacenados en los depósitos, además de otras entidades de Google Cloud, como las instancias de Compute Engine.

La configuración de las reglas de acceso que aplicas a un recurso se denomina política de Cloud IAM. En una política de Cloud IAM que se aplica a tu proyecto, se definen las acciones que los usuarios pueden realizar en todos los objetos o depósitos dentro del proyecto. En una política de Cloud IAM que se aplica a un depósito único, se definen las acciones que los usuarios pueden realizar en ese depósito específico y los objetos que contiene.

Por ejemplo, puedes crear una política de Cloud IAM para uno de tus depósitos con la que se le otorgue a un usuario el control administrativo de ese depósito. Mientras tanto, puedes agregar otro usuario a la política de Cloud IAM de todo el proyecto que le otorgue la capacidad de ver objetos en cualquier depósito de tu proyecto.

Los miembros son “quienes” están en Cloud IAM. Los miembros pueden ser usuarios individuales, grupos, dominios o incluso el público en general. A los miembros se les asignan funciones, que les otorgan la capacidad de realizar acciones en Cloud Storage y en Google Cloud de manera más general. Cada función es un grupo de uno o más permisos. Los permisos son las unidades básicas de Cloud IAM. Cada uno te permite realizar una acción determinada.

Por ejemplo, el permiso storage.objects.create te permite crear objetos. Este permiso se encuentra en funciones como roles/storage.objectCreator, en las que es el único permiso, y roles/storage.objectAdmin, en las que se agrupan varios permisos. Si asignas la función roles/storage.objectCreator a un miembro para un depósito específico, solo puede crear objetos en ese depósito. Si asignas la función roles/storage.objectAdmin a otro miembro para el depósito, puede realizar tareas adicionales, como borrar objetos, pero solo dentro de ese depósito. Si asignas estas funciones a estos dos usuarios y no a otros, no tendrán conocimiento de ningún otro depósito en tu proyecto. Si otorgas la función roles/storage.objectAdmin a un tercer miembro, pero lo haces para que la use en tu proyecto y no en un solo depósito, tendrá acceso a cualquier objeto en cualquier depósito de tu proyecto.

El uso de Cloud IAM con Cloud Storage facilita la limitación de los permisos de un miembro sin modificar el permiso de cada objeto o depósito de manera individual.

Permisos

Con los permisos, los miembros pueden realizar acciones específicas en objetos o depósitos en Cloud Storage. Por ejemplo, con el permiso storage.buckets.list, un miembro puede enumerar los depósitos de tu proyecto. No se otorgan permisos a los miembros de forma directa. En su lugar, se les asignan funciones, que incluyen uno o más permisos.

Para ver una lista de referencia de los permisos de Cloud IAM que se aplican a Cloud Storage, consulta Permisos de Cloud IAM para Cloud Storage.

Funciones

Las funciones son un conjunto de uno o más permisos. Por ejemplo, roles/storage.objectViewer contiene los permisos storage.objects.get y storage.objects.list. Debes asignar funciones a los miembros, lo que les permite realizar acciones en los depósitos y objetos de tu proyecto.

Para ver una lista de referencia de las funciones de Cloud IAM que se aplican a Cloud Storage, consulta Funciones de Cloud IAM para Cloud Storage.

Funciones a nivel de proyecto frente a funciones a nivel de depósito

La asignación de funciones a nivel de depósito no afecta a las funciones existentes que otorgaste a nivel de proyecto y viceversa. Por lo tanto, puedes usar estos dos niveles de detalle para personalizar tus permisos. Por ejemplo, supongamos que deseas otorgar a un usuario permiso para leer objetos en cualquier depósito, pero crearlos solo en un depósito específico. A fin de lograrlo, asigna al usuario la función roles/storage.objectViewer a nivel de proyecto, lo que le permite leer cualquier objeto almacenado en cualquier depósito del proyecto. Además, asígnale una función roles/storage.objectCreator a nivel de depósito para un depósito específico, de modo que pueda crear objetos solo en ese depósito.

Algunas funciones se pueden usar a nivel de proyecto y de depósito. Cuando se usan a nivel de proyecto, los permisos que contienen se aplican a todos los depósitos y objetos en el proyecto. Cuando se usan a nivel de depósito, los permisos solo se aplican a un depósito específico y los objetos que contenga. Algunos ejemplos de estas funciones son roles/storage.admin, roles/storage.objectViewer y roles/storage.objectCreator.

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

Relación con las LCA

Las funciones de Cloud IAM del depósito heredado funcionan en conjunto con las LCA del depósito. Cuando agregas o quitas una función del depósito heredado, tus cambios se reflejan en las LCA asociadas con el depósito. De manera similar, cambiar una LCA específica del depósito hace que se actualice la función del depósito heredado correspondiente para el depósito.

Función del depósito heredado LCA equivalente
roles/storage.legacyBucketReader Lector del depósito
roles/storage.legacyBucketWriter Escritor del depósito
roles/storage.legacyBucketOwner Propietario del depósito

Las demás funciones de Cloud IAM a nivel de depósito y todas las funciones de Cloud IAM a nivel de proyecto funcionan de manera independiente desde las LCA. Por ejemplo, si le asignas a un usuario la función de visualizador de objetos de almacenamiento, las LCA no se modificarán. Esto significa que puedes usar las funciones de Cloud IAM a nivel de depósito a fin de otorgar acceso total a todos los objetos de un depósito y usar las LCA de objetos detalladas para personalizar el acceso a objetos específicos del depósito.

Permiso de Cloud IAM para cambiar las LCA

Puedes usar Cloud IAM a fin de otorgar a los miembros el permiso necesario para cambiar las LCA en los objetos. En conjunto, los siguientes permisos storage.buckets permiten a los usuarios trabajar con las LCA del depósito y las LCA de los objetos predeterminados: .get, .getIamPolicy, .setIamPolicy y .update.

De forma similar, los siguientes permisos storage.objects en conjunto autorizan a los usuarios a trabajar con las LCA de los objetos: .get, .getIamPolicy, .setIamPolicy y .update.

Funciones personalizadas

Si bien Cloud IAM tiene varias funciones predefinidas que abarcan casos prácticos comunes, es posible que desees definir tus propias funciones que contengan los paquetes de permisos que especifiques. Para ello, Cloud IAM ofrece funciones personalizadas.

Tipos de miembros

Hay varios tipos de miembros. Por ejemplo, las Cuentas de Google y los Grupos de Google representan dos tipos generales, mientras que allAuthenticatedUsers y allUsers son dos tipos especializados. Para ver una lista de los tipos de miembros comunes en Cloud IAM, consulta la sección sobre conceptos relacionados con la identidad. Además de los tipos que se enumeran allí, Cloud IAM admite los siguientes tipos de miembros, que se pueden aplicar de manera específica a las políticas de Cloud IAM de tu depósito de Cloud Storage:

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

en los que [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 reciben la función que selecciones. Por ejemplo, supongamos que deseas otorgar a la función roles/storage.objectCreator de uno de tus depósitos a todos los miembros que tengan la función Viewer del proyecto my-example-project. Para hacerlo, asigna la función roles/storage.objectCreator de ese depósito al miembro projectViewer:my-example-project.

Uso con las herramientas de Cloud Storage

Aunque los permisos de Cloud IAM no se pueden configurar a través de la API de XML, los usuarios que tengan permisos de Cloud IAM pueden usar esta API, así como cualquier otra herramienta para acceder a Cloud Storage.

Para obtener referencias sobre cuáles permisos de Cloud IAM permiten que los usuarios realicen acciones con herramientas diferentes de Cloud Storage, consulta Cloud IAM con Cloud Console, Cloud IAM con gsutil, Cloud IAM con JSON y Cloud IAM con XML.

Prácticas recomendadas

Como toda configuración administrativa, Cloud IAM requiere que la administración activa sea eficaz. Antes de permitir a otros usuarios el acceso a un objeto o depósito, asegúrate de saber con quién deseas compartirlos y qué funciones deseas que desempeñe cada uno de ellos. Con el tiempo, es posible que los cambios en la administración del proyecto, los patrones de uso y la propiedad de la organización requieran que modifiques la configuración de Cloud IAM en depósitos y proyectos, en especial si administras Cloud Storage 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 prácticas recomendadas:

  • Usa el principio de privilegios mínimos cuando otorgues acceso.

    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 deseas compartir un archivo con alguien, otórgale la función storage.objectReader y no la función storage.admin.

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

    Si se otorga el permiso setIamPolicy a un usuario, este puede 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 los objetos y los depósitos.

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

    Los tipos de miembro allUsers y allAuthenticatedUsers solo se deben usar cuando sea aceptable que cualquier persona en Internet lea y analice tus datos. Si bien estos alcances son útiles para algunas aplicaciones y situaciones, en general, no es una buena idea otorgar a todos los usuarios ciertos permisos como setIamPolicy, update, create o delete.

  • Comprende las funciones Viewer, Editor y Owner de proyectos en Cloud Storage

    Las funciones a nivel de proyecto Viewer, Editor y Owner otorgan el acceso que sus nombres implican dentro de Cloud Storage. Sin embargo, lo hacen de forma indirecta a través del acceso adicional que se proporciona a nivel de depósito y objeto, mediante tipos de miembros exclusivos de Cloud Storage. Puedes revocar el acceso mientras este se agrega según la configuración predeterminada.

    Por ejemplo, la función Viewer por sí misma solo otorga el permiso storage.buckets.list a un miembro, pero los depósitos nuevos otorgan la función roles/storage.legacyBucketReader a todos los miembros que tengan la función para el proyecto de forma predeterminada. Esta función del depósito es la que permite que un Viewer vea un depósito. Además, el depósito cuenta con una LCA de objetos predeterminada de projectPrivate, lo que significa que los objetos agregados al depósito adquieren la LCA de projectPrivate de forma predeterminada. Esta LCA es lo que permite que un Viewer vea el objeto.

    Del mismo modo, las funciones de proyecto Editor y Owner tienen acceso limitado a Cloud Storage por sí mismas, pero los miembros que tienen asignadas estas funciones obtienen roles/storage.legacyBucketOwner para los depósitos nuevos y la propiedad de los objetos a través de la LCA de projectPrivate.

    Ten en cuenta que, como el acceso a algunos depósitos y objetos no es inherente a las funciones de proyecto Viewer, Editor y Owner, es posible revocar el acceso que los miembros podrían esperar.

  • Evita configurar permisos que den como resultado depósitos y objetos inaccesibles.

    Un depósito o un objeto se vuelven inaccesibles cuando nadie cuenta con permiso para leerlos. Esto puede suceder con un depósito cuando todos los permisos de Cloud IAM del depósito se quitan. Esto puede suceder con un objeto cuando el propietario del objeto abandona un proyecto y no hay políticas de Cloud IAM a nivel de depósito o proyecto que otorguen acceso a los objetos. En ambos casos, puedes recuperar el acceso mediante la asignación de una función apropiada, como roles/storage.admin, para ti mismo o para otro miembro a nivel de proyecto. Ten en cuenta que hacer esto otorga acceso a todos los depósitos y objetos del proyecto, por lo que es posible que desees revocar la función una vez que hayas restablecido el acceso al objeto o depósito afectado.

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

    De forma predeterminada, los miembros con la función Owner a nivel de proyecto son las únicas entidades que tienen la función roles/legacyBucketOwner en un depósito recién creado. Debes tener al menos dos miembros con la función Owner en un momento determinado para que, si un miembro del equipo abandona el grupo, los otros miembros puedan continuar con la administración de tus depósitos.

Próximos pasos

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

Enviar comentarios sobre…

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