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

Los recursos de Cloud Platform están organizados de forma 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 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 en 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 recomendaciones que debes tener en cuenta a la hora de crear recursos durante la implementación de IAM.

Requisitos previos

Contexto

En el diagrama siguiente, se muestra un ejemplo de jerarquía de recursos de Cloud Platform:

Jerarquía de recursos

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.

  • 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.

  • 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 en 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: Cloud Pub/Sub

En Cloud 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@gmail.com y estableces una política en topic_a que otorga la función de publicador a alice@gmail.com, lo que haces es otorgar la función de editor a bob@gmail.com y la función de publicador a alice@gmail.com para topic_a.

En el siguiente diagrama, se ilustra el ejemplo anterior:

Ejemplo de Pub/Sub

Las funciones de propietario, editor y lector son concéntricas. La función de propietario incluye los permisos en la función de editor y esta última incluye los permisos en la función de lector. Si otorgas la función más amplia y la más limitada (como editor y lector) 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@gmail.com a nivel de proyecto y la función de lector a bob@gmail.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 Cloud 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 Administrador de objeto de almacenamiento al experto en procesamiento de datos (en este caso, 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 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 Administrador de red de Compute a nivel de la organización y a alice@example.com la función Administrador de instancias de Compute 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 a su proyecto. Solo Bob puede realizar cambios en los recursos de red de la organización y en cualquier proyecto de ella.

Ejemplo de Cloud Storage

Recomendaciones

  • Refleja tu estructura de jerarquías de políticas de Cloud IAM a la estructura de tu organización. La jerarquía de políticas de Cloud IAM debe reflejar cómo se organiza tu empresa, ya sea una startup, una PYME o una gran corporación. Una startup puede comenzar con una jerarquía de políticas 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 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 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 manera automática.

  • Usa el principio de seguridad de privilegios mínimos para otorgar funciones de Cloud IAM, es decir, otorga la menor cantidad de acceso posible a tus recursos.

  • Otorga funciones a un Grupo de Google en lugar de a usuarios individuales cuando sea posible. Es más fácil administrar miembros en un Grupo de Google que actualizar una política de Cloud IAM.

  • Controla la propiedad del Grupo de Google que se usa en las políticas de Cloud IAM.

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

  • Recuerda que un conjunto de políticas en un recurso secundario no puede restringir el acceso otorgado en su superior. Verifica la política otorgada en cada recurso y trata de interpretar la herencia jerárquica.

  • Si necesitas otorgar una función a un usuario o grupo que se extiende a través de múltiples proyectos, establece esa función a nivel de la organización en lugar de establecerla a nivel de 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 Creador de proyectos a un grupo que administres.

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

Enviar comentarios sobre…

Documentación de Cloud Identity and Access Management