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

LosGoogle Cloud recursos se organizan de forma jerárquica, donde el nodo de organización es el nodo raíz de la jerarquía, los proyectos son los elementos secundarios de la organización y los demás recursos son descendientes de los proyectos. Puedes definir políticas de permiso en diferentes niveles de la jerarquía de recursos. Los recursos heredan las políticas de permiso del recurso superior. La política de permiso efectiva de un recurso es la unión de la política de permiso definida en ese recurso y la política de permiso heredada de su elemento superior.

En esta página se describen algunos ejemplos de cómo funciona la herencia de políticas de permiso y se explican las prácticas recomendadas que debes tener en cuenta al crear recursos durante la implementación de Gestión de Identidades y Accesos (IAM).

Requisitos previos

Fondo

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

De arriba abajo, la jerarquía incluye organizaciones, carpetas, proyectos y recursos específicos de servicios.

IAM te permite definir políticas de permiso 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 de la organización heredan los roles de gestión de identidades y accesos que se conceden en este nivel. Para obtener más información, consulta Control de acceso para organizaciones con la gestión de identidades y accesos.

  • Nivel de carpeta. Las carpetas pueden contener proyectos, otras carpetas o una combinación de ambos. Los roles concedidos en el nivel de carpeta más alto se heredarán en los proyectos u otras carpetas que estén incluidos en esa carpeta principal. Para obtener más información, consulta Control de acceso a carpetas con gestión de identidades y accesos.

  • A nivel de proyecto. Los proyectos representan un límite de confianza dentro de tu empresa. Los servicios de un mismo proyecto tienen un nivel de confianza predeterminado. Los roles de gestión de identidades y accesos concedidos a nivel de proyecto se heredan en los recursos de ese proyecto. Para obtener más información, consulta Control de acceso a proyectos con la gestión de identidades y accesos.

  • Nivel de recurso. Además de los sistemas de listas de control de acceso de Cloud Storage y BigQuery, otros recursos, como los temas de Pub/Sub y las instancias de Compute Engine, admiten roles de nivel inferior para que puedas conceder permiso a determinados usuarios para acceder a un solo recurso de un proyecto.

Las políticas de permiso son jerárquicas y se propagan por la estructura. La política de permiso efectiva de un recurso es la unión de la política de permiso definida en ese recurso y la política de permiso heredada de su elemento superior.

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

Ejemplo: Pub/Sub

En Pub/Sub, los temas y las suscripciones son recursos que se encuentran en un proyecto. Supongamos que project_1 tiene un tema topic_a. Si define una política de permiso en project_1 que concede el rol Editor a Kalani y una política de permiso en topic_a que concede el rol Editor a Nur, efectivamente concede el rol Editor a Kalani y el rol Editor a Nur en topic_a.

En el siguiente diagrama se muestra el ejemplo anterior.

Ejemplo de Pub/Sub.

Si un rol heredado ya otorga a una entidad principal todos los permisos que necesita, no es necesario que le concedas roles adicionales en el propio recurso. Conceder otro rol que contenga los mismos permisos o menos es redundante y no tiene ningún efecto.

Por ejemplo, considera los roles básicos Propietario, Editor y Lector. Estos roles son concéntricos, es decir, el rol Propietario incluye los permisos del rol Editor, y el rol Editor incluye los permisos del rol Lector. Por lo tanto, si le asignas a Kalani el rol Editor a nivel de proyecto, no es necesario que le asignes el rol Lector en topic_a. Esto se debe a que Kalani ya tiene todos los permisos del rol Lector a través del rol Editor, que se hereda de la política de permisos del proyecto.

En el siguiente diagrama se muestra el ejemplo anterior.

Ejemplo de Pub/Sub.

Ejemplo: Cloud Storage

En Cloud Storage, los segmentos y los objetos son recursos, y los objetos se encuentran en segmentos. Un ejemplo de uso de la gestión de identidades y accesos con Cloud Storage es permitir el acceso de lectura a los archivos que se suben.

Supongamos que muchos usuarios suben archivos a un mismo contenedor, pero no deberían poder leer ni eliminar ninguno de los archivos subidos por otros usuarios. Tu experto en tratamiento de datos debería poder leer y eliminar los archivos subidos, pero no debería poder eliminar los contenedores, ya que otros usuarios utilizan la ubicación del contenedor para subir sus archivos. En este caso, definirías las políticas de permiso en el proyecto de la siguiente manera:

  • Otorga el rol Administrador de objetos de Storage (roles/storage.objectAdmin) a tu experto en tratamiento de datos, Nur. Este rol permite a Nur leer, añadir y eliminar cualquier objeto de cualquier segmento del proyecto.
  • Concede el rol Creador de objetos de Storage (roles/storage.objectCreator) al grupo data-uploaders. Este rol permite a los miembros del grupo subir archivos al contenedor, pero no leer ni eliminar los archivos que suban otros usuarios.

En el siguiente diagrama se muestra el ejemplo anterior.

Ejemplo de Cloud Storage.

Ejemplo: Compute Engine

En las empresas más grandes, la gestión de los recursos de red y seguridad, como los cortafuegos, suele estar a cargo de un equipo específico, que es diferente del equipo de desarrollo. Es posible que los equipos de desarrollo quieran tener la flexibilidad de lanzar instancias y llevar a cabo otras acciones relacionadas con las instancias de sus proyectos.

En una situación como esta, podrías configurar tus políticas de permiso de la siguiente manera:

  • Concede el rol Administrador de red de Compute (roles/compute.networkAdmin) a tu administrador de red y seguridad, Kalani, a nivel de organización. Este rol permite a Kalani hacer cambios en los recursos de red de la organización y en cualquier proyecto de esa organización.
  • Concede el rol Administrador de instancias de Compute (roles/compute.instanceAdmin) a Nur, responsable de un equipo de desarrollo, en su proyecto project_2. Este rol permite a Nur llevar a cabo cualquier acción en sus instancias, pero le impide hacer cambios en los recursos de red asociados a su proyecto. Sin embargo, no les permite hacer cambios en los recursos de red de otros proyectos.

Ejemplo de Compute Engine.

Permisos para ver las políticas heredadas

Para ver las políticas de gestión de identidades y accesos que se heredan de un recurso superior, debes tener permiso para ver la política de gestión de identidades y accesos del recurso superior. Por ejemplo, para ver todas las políticas de gestión de identidades y accesos heredadas de un proyecto, debes tener permiso para ver la política de gestión de identidades y accesos de la organización superior del proyecto y las políticas de gestión de identidades y accesos de las carpetas superiores.

Para obtener los permisos que necesitas para ver las políticas de gestión de identidades y accesos que se heredan de los recursos principales, pide a tu administrador que te conceda los siguientes roles de gestión de identidades y accesos:

Para obtener más información sobre cómo conceder roles, consulta el artículo Gestionar el acceso a proyectos, carpetas y organizaciones.

Estos roles predefinidos contienen los permisos necesarios para ver las políticas de gestión de identidades y accesos que se heredan de los recursos principales. Para ver los permisos exactos que se necesitan, despliega la sección Permisos necesarios:

Permisos obligatorios

Se necesitan los siguientes permisos para ver las políticas de gestión de identidades y accesos que se heredan de los recursos principales:

  • Ver una política de gestión de identidades y accesos heredada de una organización: resourcemanager.organizations.getIamPolicy en la organización
  • Ver una política de gestión de identidades y accesos heredada de una carpeta: resourcemanager.folders.getIamPolicy en la carpeta
  • Para ver una política de gestión de identidades y accesos que se ha heredado de un proyecto, haz lo siguiente: resourcemanager.projects.getIamPolicy en el proyecto

También puedes obtener estos permisos con roles personalizados u otros roles predefinidos.

Prácticas recomendadas

  • Refleja la estructura de tu jerarquía de recursos en la estructura de tu organización. Google Cloud La jerarquía de recursos Google Cloud debe reflejar la estructura de tu empresa, ya sea una startup, una pyme o una gran corporación. Una startup puede empezar con una jerarquía de recursos plana sin ningún recurso de organización. Cuando más personas empiecen a colaborar en proyectos y aumente el número de proyectos, puede que sea conveniente obtener un recurso de organización. Los recursos de organización se recomiendan para empresas más grandes con varios departamentos y equipos, donde 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 del mismo producto o microservicio pueden pertenecer al mismo proyecto.

  • Siempre que sea posible, concede roles a un grupo en vez de a usuarios individuales. Es más fácil gestionar los miembros de un grupo que actualizar una política de permiso. Asegúrate de controlar la propiedad del grupo que se usa en las políticas de permiso.

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

  • Puedes adoptar el principio de seguridad de mínimos accesos a la hora de conceder roles de IAM, que se basa en proporcionar la cantidad mínima de acceso necesaria a tus recursos.

    Para encontrar el rol predefinido adecuado, consulta la referencia de roles predefinidos. Si no hay roles predefinidos adecuados, también puedes crear tus propios roles personalizados.

  • Concede roles con el menor permiso necesario. Por ejemplo, si un usuario solo necesita acceso para publicar mensajes en un tema de Pub/Sub, concédele el rol Publisher (Editor) a ese usuario en ese tema.

  • Recuerda que las políticas de permiso de los recursos secundarios se heredan de las políticas de permiso de sus recursos superiores. Por ejemplo, si la política de permiso de un proyecto concede a un usuario la capacidad de administrar instancias de máquinas virtuales (VMs) de Compute Engine, el usuario podrá administrar cualquier VM de Compute Engine de ese proyecto, independientemente de la política de permiso que definas en cada VM.

  • En cada proyecto, asegúrate de que al menos dos entidades principales tengan el rol Propietario (roles/owner). También puedes asignar el rol Propietario a un grupo que contenga al menos dos entidades principales.

    De esta forma, si uno de los principales deja tu empresa, podrás seguir gestionando el proyecto.

  • Si necesitas asignar un rol a un usuario o grupo que abarque varios proyectos, define ese rol a nivel de carpeta en lugar de hacerlo a nivel de proyecto.

  • Utiliza etiquetas para anotar, agrupar y filtrar recursos.

  • Audita tus políticas de permiso para asegurarte de que las cumples. Los registros de auditoría contienen todas las llamadas setIamPolicy(), por lo que puedes hacer un seguimiento de cuándo se ha creado o modificado una política de permiso.

  • Audita la propiedad y la pertenencia de los grupos utilizados en las políticas de permiso.

  • Si quieres limitar la creación de proyectos en tu organización, cambia la política de acceso de la organización para conceder el rol de creador de proyectos a un grupo que gestiones.