Cloud Identity and Access Management

Ir a ejemplos

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. Para 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 particular. Para obtener un análisis detallado de Cloud IAM y sus características generales, consulta Cloud Identity and Access Management. En particular, lee 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 depósitos de Cloud Storage y los objetos almacenados en ellos, 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, así como en Google Cloud, de manera más general. Cada función es una colección 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 creador de objetos de almacenamiento, en la que es el único permiso, y en administrador de objetos de almacenamiento, en la que se agrupan muchos permisos. Si le asignas a un miembro la función creador de objetos de almacenamiento para un depósito específico, el miembro solo podrá crear objetos en ese depósito. Si le asignas a otro miembro la función administrador de objetos de almacenamiento para el depósito, este miembro podrá 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 le asignas a un tercer miembro la función administrador de objetos de almacenamiento, pero lo haces para tu proyecto y no solo un depósito, el miembro 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 tener que modificar el permiso de cada objeto o depósito de forma 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 paquete de uno o más permisos. Por ejemplo, la función visualizador de objetos de almacenamiento 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. Para lograrlo, otorga al usuario la función visualizador de objetos de almacenamiento a nivel de proyecto, lo que le permitirá leer cualquier objeto almacenado en cualquier depósito de tu proyecto, y la función creador de objetos de almacenamiento a nivel de depósito para un depósito específico, lo que le permitirá 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 del proyecto. Cuando se usan a nivel de depósito, los permisos solo se aplican a un depósito específico y a los objetos que contenga. Algunos ejemplos de estas funciones son administrador de almacenamiento, visualizador de objetos de almacenamiento y creador de objetos de almacenamiento.

Algunas funciones solo se pueden aplicar a un nivel. Por ejemplo, solo puedes aplicar la función visualizador a nivel de proyecto, mientras que solo puedes aplicar la función propietario de objetos heredados de almacenamiento 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
Lector de depósitos heredados de almacenamiento Lector de depósitos
Escritor de depósitos heredados de almacenamiento Escritor de depósitos
Propietario de depósitos heredados de almacenamiento Propietario de depósitos

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 Conceptos relacionados con la identidad. Además de los tipos que se enumeran allí, en Cloud IAM, se admiten los siguientes tipos de miembros, que pueden aplicarse 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 el ejemplo, [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 determinado para el proyecto especificado reciben la función que selecciones. Por ejemplo, supongamos que deseas otorgar a todos los miembros que tienen la función visualizador del proyecto my-example-project la función creador de objetos de almacenamiento para uno de tus depósitos. Para ello, asigna al miembro projectViewer:my-example-project la función creador de objetos de almacenamiento en ese depósito.

Condiciones

Con las Condiciones de Cloud IAM, puedes configurar expresiones que controlan cómo se otorgan los permisos a los miembros. En Cloud Storage, se admiten los siguientes tipos de atributos de condición:

  • resource.name: Otorga acceso a los depósitos y objetos que tienen el prefijo especificado. También puedes usar resource.type para otorgar acceso a objetos o depósitos, pero esta acción es casi siempre redundante si usas resource.name.
    resource.name.startsWith('projects/_/buckets/[BUCKET_NAME]/objects/[OBJECT_PREFIX]')
  • Fecha/hora: Configura una fecha de vencimiento para el permiso.
    request.time < timestamp('2019-01-01T00:00:00Z')

Estas expresiones condicionales son declaraciones lógicas que usan un subconjunto de Common Expression Language (CEL). Debes especificar condiciones en las vinculaciones de funciones de la política de Cloud IAM de un depósito.

Ten en cuenta las siguientes restricciones:

  • Debes habilitar el acceso uniforme a nivel de depósito en un depósito antes de agregar condiciones a este nivel. Aunque las condiciones se permiten a nivel de proyecto, debes migrar todos los depósitos del proyecto a un acceso uniforme a nivel de depósito para evitar que las LCA de Cloud Storage anulen las condiciones de Cloud IAM a nivel de proyecto. Puedes aplicar una restricción de acceso uniforme a nivel de depósito para habilitar el acceso uniforme a este nivel en todos los depósitos nuevos de tu proyecto.
  • El comando gsutil iam ch no funciona con las políticas que contienen condiciones. Si deseas modificar una política que tiene condiciones, usa gsutil iam get a fin de recuperar la política para el depósito relevante y editarla localmente y, luego, usa gsutil iam set de modo que vuelvas a aplicarla al depósito.
  • Para poder usar las condiciones, gsutil debe estar actualizado a la versión 4.38 o a una versión superior.
  • Cuando usas la API de JSON para llamar a getIamPolicy y setIamPolicy en depósitos con condiciones, debes configurar la versión de la política de Cloud IAM como 3.
  • Las condiciones vencidas permanecen en tu política de Cloud IAM hasta que las quitas.

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 con permisos de Cloud IAM pueden usar esta API y 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 en toda configuración administrativa, para que Cloud IAM sea eficaz, se requiere una administración activa. Antes de otorgar a otros usuarios acceso a un objeto o depósito, asegúrate de saber con quién deseas compartir el objeto o depósito y qué funciones quieres que tengan cada una de esas personas. A lo largo del tiempo, es posible que, con los cambios en la administración del proyecto, los patrones de uso y la propiedad de la organización, debas modificar la configuración de Cloud IAM en depósitos y proyectos, especialmente si administras Cloud Storage en una organización grande o para un grupo de muchos 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 menor privilegio cuando otorgues acceso.

    El principio de menor privilegio es un lineamiento de seguridad para otorgar acceso a tus recursos. Cuando otorgas acceso basado en el principio de menor privilegio, le das a un usuario solo el acceso que necesita para realizar la tarea asignada. Por ejemplo, si deseas compartir archivos con alguien, debes otorgarle 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 básicas de visualizador, editor y propietario en Cloud Storage

    Con las funciones básicas visualizador, editor y propietario se otorga efectivamente el acceso que implican sus nombres en Cloud Storage; sin embargo, esto se hace 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. Aunque el acceso se agrega de forma predeterminada, puedes revocarlo.

    Por ejemplo, la función visualizador permite a los miembros enumerar depósitos, pero no ver depósitos ni objetos. Sin embargo, debes tener en cuenta lo siguiente:

    • Los miembros con la función visualizador suelen obtener la función lector de depósitos heredados de almacenamiento y sus permisos para cada depósito del proyecto. Esto se debe a que cuando creas un depósito nuevo, de forma predeterminada, en Cloud Storage, se otorga la función lector de depósitos heredados de almacenamiento para el depósito nuevo a la función básica visualizador. En consecuencia, todos los miembros que tienen la función básica visualizador para el proyecto también tienen la función lector de depósitos heredados de almacenamiento en el depósito nuevo. Este comportamiento permite que los miembros con la función visualizador vean los depósitos.

    • Los depósitos tienen una LCA de objeto predeterminada projectPrivate, lo que significa que los objetos agregados al depósito obtienen, de forma predeterminada, la LCA projectPrivate. Mediante esta LCA, los miembros con la función visualizador pueden ver los objetos.

    De manera similar, con las funciones básicas editor y propietario, se otorga acceso limitado a Cloud Storage, pero los miembros que tienen estas funciones obtienen la función propietario de depósitos heredados de almacenamiento para los depósitos nuevos y la propiedad de los objetos a través de la LCA projectPrivate.

    Ten en cuenta que, como el acceso a algunos depósitos y objetos no es inherente a las funciones básicas visualizador, editor y propietario, 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 administrador de almacenamiento, a ti mismo o a 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 propietario a nivel de proyecto son las únicas entidades que tienen la función propietario de depósitos heredados de almacenamiento en un depósito creado recientemente. Debes tener al menos dos miembros con la función propietario en un momento determinado para que, si un miembro del equipo abandona el grupo, otros miembros puedan seguir administrando tus depósitos.

Próximos pasos