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

Nota: Ahora puedes usar políticas de denegación para evitar que las principales utilicen ciertos permisos. El uso de políticas de denegación puede hacer que las características descritas en esta página funcionen de manera diferente.

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 configurar políticas de permisos en distintos niveles de la jerarquía de recursos. Los recursos heredan las políticas de permisos del recurso superior. La política de permisos efectiva para un recurso es la unión del conjunto de políticas de permisos de ese recurso y la política de permisos heredada de su superior.

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

Requisitos previos

• Comprender los conceptos básicos de IAM, en particular la jerarquía de recursos de Google Cloud

Información general

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

IAM te permite establecer políticas de permisos 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 permisos son jerárquicas y se propagan hacia abajo por la estructura. La política de permisos efectiva para un recurso es la unión del conjunto de políticas de permisos de ese recurso y la política de permisos heredada de su 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 dentro de un proyecto. Supongamos que project_1 tiene un tema topic_a dentro de él. Si configuras una política de permisos en project_1 que otorga el rol Editor a [e-mail] y estableces una política de permisos en topic_a que otorga el rol Publisher a [e-mail], lo que haces es otorgar el rol Editor a [e-mail] y el rol Publisher a [e-mail] para topic_a.

En el siguiente diagrama, se ilustra el ejemplo anterior.

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 [e-mail] a nivel de proyecto y otorgas la función de visualizador a [e-mail] para topic_a, Bob obtiene la función de editor para topic_a. Esto se debe a que ya se le otorgó a Bob el rol Editor para topic_a, que se hereda de la política de permisos establecida en project_a.

En el siguiente diagrama, se ilustra el ejemplo anterior.

Ejemplo: Cloud Storage

En Cloud Storage, los buckets y los objetos son recursos, y los objetos se encuentran en los buckets. 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 bucket, 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 bucket s porque otros usan la ubicación del bucket para subir sus archivos. En esta situación, deberás establecer las políticas de permisos 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 [e-mail].
  • Alice tiene derechos de administrador de objetos a nivel de proyecto y puede leer, agregar y borrar cualquier objeto en cualquier bucket del proyecto.
• Otorga la función de creador de objetos de almacenamiento a un grupo de usuarios, [e-mail].
  • Esta política de permisos significa que cualquier persona que sea miembro del grupo [e-mail] puede subir archivos al bucket.
  • 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: 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 [e-mail] la función de administrador de red de Compute a nivel de la organización y a [e-mail] la función de 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 con su proyecto. Solo Bob puede realizar cambios en los recursos de red de la organización y en cualquier proyecto de ella.

Permisos para ver las políticas heredadas

Si deseas ver las políticas de IAM que se heredaron de un recurso superior, necesitas permiso para ver la política de IAM del recurso superior. Por ejemplo, a fin de ver todas las políticas de IAM heredadas de un proyecto, necesitas permiso para ver la política de IAM de la organización superior del proyecto y ver las políticas de IAM de cualquier carpeta superior.

A fin de obtener los permisos que necesitas para ver las políticas de IAM heredadas de recursos superiores, pídele a tu administrador que te otorgue los siguientes roles de IAM:

• Ver una política de IAM que se hereda de una organización: Administrador de la organización (roles/resourcemanager.organizationAdmin) en la organización
• Ver una política de IAM que se hereda de una carpeta: Administrador de carpetas (roles/resourcemanager.folderAdmin) en la carpeta
• Ver una política de IAM que se hereda de un proyecto: Administrador de IAM de proyectos (roles/resourcemanager.projectIamAdmin) en el proyecto

Si quieres obtener más información para otorgar roles, consulta Administra el acceso.

Estos roles predefinidos contienen los permisos necesarios para ver las políticas de IAM que se heredan de los recursos superiores. Para ver los permisos exactos que son necesarios, expande la sección Permisos requeridos:

Permisos necesarios

Se requieren los siguientes permisos para ver las políticas de IAM heredadas de los recursos superiores:

• Ver una política de IAM que se hereda de una organización: resourcemanager.organizations.getIamPolicy en la organización
• Visualiza una política de IAM que se hereda de una carpeta: resourcemanager.folders.getIamPolicy en la carpeta
• Visualizar una política de IAM que se hereda de un proyecto: resourcemanager.projects.getIamPolicy en el proyecto

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

Nota: En la consola de Google Cloud, la página de IAM de un recurso solo muestra los roles heredados si son otorgables en el recurso.

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.

• 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 permisos. 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 permisos para recursos secundarios se heredan de las políticas de permisos en sus recursos superiores. Por ejemplo, si la política de permisos 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 de permisos que configures en cada VM.

• En cada proyecto, asegúrate de que al menos dos principales tengan la función de propietario (roles/owner). Como alternativa, otorga la función de propietario a un grupo de Google que contenga al menos dos principales.

  Esta práctica ayuda a garantizar que si uno de los principales abandona tu empresa, aún tengas una forma de administrar el proyecto.

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

• Usa etiquetas para anotar, agrupar y filtrar recursos.

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

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

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