Usa la jerarquía de recursos para el control de acceso

Los recursos de Google Cloud están organizados de manera jerárquica: el nodo de organización es el nodo raíz en la jerarquía, los proyectos son los secundarios de la organización y los otros recursos son descendientes de los proyectos. Puedes establecer políticas de administración de identidades y accesos (IAM) en diferentes niveles de la jerarquía de recursos. Los recursos heredan las políticas del recurso superior. La política vigente para un recurso es la unión del conjunto de políticas de ese recurso y la política heredada de su superior.

En esta página, se describen algunos ejemplos de cómo funciona la herencia de políticas de IAM y se explican las prácticas recomendadas que debes tener en cuenta a la hora de crear recursos durante la implementación de IAM.

Requisitos

Información general

En el siguiente diagrama, se muestra un ejemplo de una jerarquía de recursos de Google Cloud.

En orden descendente, la jerarquía incluye organizaciones, carpetas, proyectos y recursos específicos de servicios.

IAM te permite establecer políticas en los siguientes niveles de la jerarquía de recursos:

  • Nivel de organización. El recurso de organización representa a tu empresa. Todos los recursos en la organización heredan las funciones de IAM otorgadas en este nivel. A fin de obtener más información, consulta Control de acceso para organizaciones mediante IAM.

  • Nivel de carpeta. Las carpetas pueden contener proyectos, otras carpetas o una combinación de ambos. Los proyectos heredarán las funciones otorgadas en el nivel de carpeta más alto, así como lo harán otras carpetas que se encuentren en esa carpeta superior. A fin de obtener más información, consulta Control de acceso para carpetas mediante IAM.

  • Nivel de proyecto. Los proyectos representan un límite de confianza dentro de tu empresa. Los servicios dentro del mismo proyecto tienen un nivel de confianza predeterminado. Por ejemplo, las instancias de App Engine pueden acceder a los depósitos de Cloud Storage dentro del mismo proyecto. Los recursos dentro del proyecto heredan las funciones de IAM otorgadas en el nivel de proyecto. A fin de obtener más información, consulta Control de acceso para proyectos mediante IAM.

  • Nivel de recursos. Además de los sistemas existentes de Cloud Storage y LCA de BigQuery, los recursos adicionales, como los conjuntos de datos de Genomics, los temas de Pub/Sub y las instancias de Compute Engine, admiten funciones de nivel inferior para que puedas otorgar permisos a ciertos usuarios a un solo recurso dentro de un proyecto.

Las políticas de IAM son jerárquicas y se propagan por la estructura. La política vigente para un recurso es la unión del conjunto de políticas de ese recurso y la política heredada de su superior.

En los siguientes ejemplos, se explica cómo funciona la herencia de políticas en la práctica.

Ejemplo: Pub/Sub

En Pub/Sub, los temas y las suscripciones son recursos dentro de un proyecto. Supongamos que project_a tiene un tema topic_a dentro de él. Si configuras una política en project_a que otorga la función de Editor a bob@example.com y estableces una política en topic_a que otorga la función de Publicador a alice@example.com, lo que haces es otorgar la función de Editor a bob@example.com y la función de Publicador a alice@example.com para topic_a.

En el siguiente diagrama, se ilustra el ejemplo anterior.

Ejemplo de Pub/Sub

Las funciones de propietario, editor y visualizador son concéntricas. La función de propietario incluye los permisos de la función de editor y, esta última, incluye los permisos de la función de visualizador. Si otorgas la función más amplia y la más limitada (como editor y visualizador) a la misma persona, solo se le otorga la función más amplia. Por ejemplo, si otorgas la función de editor a bob@example.com a nivel de proyecto y otorgas la función de visualizador a bob@example.com para topic_a, Bob obtiene la función de editor para topic_a. Esto se debe a que ya se le otorgó a Bob la función de editor para topic_a, que se hereda de la política establecida en project_a.

En el siguiente diagrama, se ilustra el ejemplo anterior.

Ejemplo de Pub/Sub

Ejemplo: Cloud Storage

En Cloud Storage, los depósitos y los objetos son recursos: los depósitos son los contenedores que contienen los objetos. Un ejemplo del uso de IAM con Cloud Storage es permitir el acceso de lectura a los archivos que se suben.

Considera una situación en la que muchos usuarios suben archivos a un depósito, pero no deberían poder leer ni borrar ninguno de los archivos subidos por otros usuarios. El experto en procesamiento de datos debería poder leer y borrar los archivos subidos, pero no debería poder borrar los depósitos porque otros usan la ubicación del depósito para subir sus archivos. En esta situación, deberás establecer las políticas en el proyecto de la siguiente manera:

  • Otorga la función de administrador de objetos de almacenamiento a tu experta en procesamiento de datos, Alice, en alice@example.com.
    • Alice tiene derechos de administrador de objetos a nivel de proyecto y puede leer, agregar y borrar cualquier objeto en cualquier depósito del proyecto.
  • Otorga la función de creador de objetos de almacenamiento a un grupo de usuarios, data_uploaders@example.com.
    • Esta política significa que cualquier persona que sea miembro de data_uploaders@example.com puede subir archivos al depósito.
    • Un miembro del grupo es propietario de los archivos que sube, pero no puede leer ni borrar ningún archivo que otros usuarios suban.

En el siguiente diagrama, se ilustra el ejemplo anterior.

Ejemplo de Cloud Storage

Ejemplo: Compute Engine

En las empresas más grandes, un equipo dedicado, distinto del equipo de desarrollo, suele encargarse de la administración de los recursos de red y seguridad, como los firewalls. Puede que los equipos de desarrollo quieran la flexibilidad para iniciar instancias y realizar otras acciones relacionadas con las instancias en sus proyectos. Si le otorgas a bob@example.com la función de administrador de red de Compute a nivel de la organización y a alice@example.com la función de administrador de instancias de procesamiento en su proyecto project_2, Alice puede llevar a cabo cualquier acción en las instancias, pero no puede realizar cambios en los recursos de la red asociados con su proyecto. Solo Bob puede realizar cambios en los recursos de red de la organización y en cualquiera de sus proyectos.

Ejemplo de Cloud Storage

Prácticas recomendadas

  • Duplica la estructura de jerarquía de recursos de Google Cloud en la estructura de tu organización. La jerarquía de recursos de Google Cloud debe reflejar cómo está organizada tu empresa, ya sea una startup, una PYME o una gran corporación. Una startup puede comenzar con una jerarquía de recursos plana sin recursos de organización. A medida que más personas comienzan a colaborar en proyectos y la cantidad de estos aumenta, obtener un recurso de organización empieza a cobrar sentido. Se recomienda un recurso de organización para empresas más grandes con varios departamentos y equipos en la que cada equipo es responsable de su propio conjunto de aplicaciones y servicios.

  • Usa proyectos para agrupar recursos que compartan el mismo límite de confianza. Por ejemplo, los recursos para el mismo producto o microservicio pueden pertenecer al mismo proyecto.

  • Establece políticas a nivel de organización y a nivel de proyecto en lugar de establecerlas a nivel de recursos. A medida que se agreguen recursos nuevos, es posible que desees que hereden las políticas de su recurso superior de forma automática. Por ejemplo, a medida que se agreguen nuevas máquinas virtuales al proyecto a través del ajuste de escala automático, estas heredarán la política en el proyecto de forma automática.

    Para obtener más información sobre cómo configurar políticas, consulta Otorga, cambia y revoca el acceso.

  • Otorga funciones a un Grupo de Google en lugar de a usuarios individuales cuando sea posible. Es más fácil administrar miembros de un Grupo de Google que actualizar una política de IAM. Asegúrate de controlar la propiedad del Grupo de Google que se usa en las políticas de IAM.

    Para obtener más información sobre cómo administrar grupos de Google, consulta la Ayuda de Grupos de Google.

  • Usa el principio de seguridad de privilegio mínimo para otorgar funciones de IAM, es decir, otorga la menor cantidad necesaria de acceso a tus recursos.

    Para encontrar la función predefinida adecuada, consulta la referencia de funciones predefinidas. Si no hay funciones predefinidas adecuadas, también puedes crear tus propias funciones personalizadas.

  • Otorga funciones en el menor alcance posible. Por ejemplo, si un usuario solo necesita acceso para publicar mensajes en un tema de Pub/Sub, asigna la función publicador al usuario en ese tema.

  • Recuerda que las políticas de los recursos secundarios heredan de las políticas de sus recursos superiores. Por ejemplo, si la política de un proyecto otorga a un usuario la capacidad de administrar instancias de máquina virtual (VM) de Compute Engine, el usuario puede administrar cualquier VM de Compute Engine en ese proyecto, sin importar la política que configures en cada VM.

  • Si necesitas otorgar una función a un usuario o grupo que abarca varios proyectos, establece esa función en el nivel de la carpeta, en lugar de configurarla a nivel del proyecto.

  • Usa etiquetas para anotar, agrupar y filtrar recursos.

  • Audita tus políticas para garantizar el cumplimiento. Los registros de auditoría contienen todas las llamadas a setIamPolicy(), por lo que puedes hacer un seguimiento cuando se crea o modifica una política.

  • Audita la propiedad y la membresía de los Grupos de Google que se usan en las políticas.

  • Si deseas limitar la creación de proyectos en tu organización, cambia la política de acceso de la organización para otorgar la función de creador de proyectos a un grupo que administres.