Prácticas recomendadas para usar Grupos de Google

En este documento se describen algunas prácticas recomendadas para usar grupos de Google con el fin de gestionar el acceso a los recursos con Gestión de Identidades y Accesos (IAM). Google Cloud

Tipos de grupos

Los tipos de grupos que se indican en este artículo son una forma de pensar, usar y gestionar los grupos de Google. Estos tipos de grupos no se definen mediante ningún atributo de grupo de Google. Sin embargo, usar estos tipos de grupos en tu estrategia general de gestión de grupos de Google puede ayudarte a evitar algunos errores de seguridad habituales.

En este documento se utilizan los siguientes tipos de grupos:

  • Grupos de la organización

    Los grupos de la organización representan subconjuntos de la estructura de una organización y suelen proceder de datos de recursos humanos. Pueden basarse en el departamento, la estructura de informes, la ubicación geográfica u otras agrupaciones de la organización.

    Los miembros de un grupo de la organización cambian cuando un empleado se une a la organización, se traslada a otro departamento o deja la organización.

    La estructura general de los grupos de organización puede cambiar cuando la empresa se reorganiza. Una reorganización puede llevar a la creación de nuevos grupos o a la retirada de grupos ya existentes.

    Algunos ejemplos de grupos organizativos son org.marketing-fte, org.finance-all, org.msmith-reports, org.apac-all y org.summer-interns.

    Los grupos de organización se suelen usar para la comunicación por correo electrónico.

  • Grupos de colaboración

    Los grupos de colaboración representan grupos de trabajo, miembros de proyectos o usuarios que quieren colaborar en un proyecto o debatir sobre un tema específico.

    La estructura de los grupos de colaboración no está vinculada a ninguna estructura organizativa. A menudo se crean de forma puntual y de autoservicio.

    La pertenencia a grupos de colaboración puede ser ilimitada, lo que permite que cualquier persona de la organización se una. También puede ser autogestionado, lo que significa que determinados miembros pueden decidir quién más se incluye en el grupo.

    Algunos ejemplos de grupos de colaboración son collab.security-discuss y collab.website-relaunch.

    Los grupos de colaboración se suelen usar para la comunicación por correo electrónico.

  • Grupos de acceso

    Los grupos de acceso se usan únicamente para proporcionar acceso. Representan funciones laborales y se usan para simplificar la asignación de los roles necesarios para llevar a cabo estas funciones. En lugar de conceder roles a principales individuales, se conceden roles al grupo y, a continuación, se gestiona la pertenencia al grupo.

    La estructura de los grupos de acceso se ve influenciada por la estructura de los recursos o las cargas de trabajo de tu organización. Para implementar un nuevo recurso o una nueva carga de trabajo, puede que sea necesario crear nuevos grupos de acceso.

    Por lo general, la pertenencia a los grupos de acceso la controlan uno o varios propietarios del grupo, que invitan a los usuarios a unirse al grupo o aprueban sus solicitudes para hacerlo.

    Algunos ejemplos de grupos de acceso son access.prod-firewall-admins, access.finance-datamart-viewers y access.billing-dashboard-users.

    Los grupos de acceso solo se usan para proporcionar acceso. No se usan con fines de comunicación.

  • Grupos de medidas por incumplimiento de políticas

    Los grupos de cumplimiento son similares a los grupos de acceso, pero se usan para aplicar políticas de restricción de acceso en lugar de para proporcionar acceso.

    La estructura de los grupos de medidas se suele ver influida por una combinación de requisitos de cumplimiento y estructura organizativa.

    La pertenencia a un grupo de cumplimiento se determina normalmente mediante un conjunto de reglas predefinidas que tienen en cuenta el nivel de autorización, la ubicación o el rol de un usuario en la organización.

    Algunos ejemplos de grupos de medidas son enforcement.users-in-restricted-locations, enforcement.fedramp-low y enforcement.sso-users.

    Los grupos de aplicación solo se usan para aplicar políticas de restricción de acceso. No se usan con fines de comunicación.

Asigna nombres a tus grupos que reflejen su tipo

Para seguir las prácticas recomendadas que se indican en el resto de este documento, usa nombres de grupo que te permitan determinar el tipo de grupo a partir de su nombre. Puedes usar una convención de nomenclatura o dominios secundarios.

Convención de nomenclatura

Aquí tienes un ejemplo de convención de nomenclatura para que el tipo de grupo sea visible:

  • Grupos organizativos: org.GROUP_NAME@example.com. Por ejemplo, org.finance-all@example.com.

  • Grupos de colaboración: collab.TEAM_NAME@example.com. Por ejemplo, collab.msmiths-team@example.com.

  • Grupos de acceso: access.JOB_FUNCTION@example.com. Por ejemplo, access.billing-dashboard-users@example.com.

  • Grupos de medidas: enforcement.GROUP_DESCRIPTION@example.com. Por ejemplo, enforcement.sso-users@example.com.

Adopta la convención que mejor se adapte a tu organización y que sea compatible con el software de gestión de grupos. Si usas un prefijo, tus grupos se ordenarán alfabéticamente por función, pero algunos sistemas de gestión de grupos, como Grupos para empresas, solo admiten sufijos. Si no puedes usar prefijos, puedes usar sufijos o dominios secundarios.

Dominios secundarios

Como alternativa a las convenciones de nomenclatura, puedes usar dominios secundarios para insertar el tipo de grupo en el nombre. Por ejemplo, access.example.com. Los dominios secundarios que son subdominios de un dominio verificado no requieren verificación y no tienen que existir en el DNS. Además, si no creas registros de intercambio de correo (MX) de DNS para los dominios secundarios, puedes bloquear los correos entrantes que se dirijan a grupos que no estén pensados para la comunicación.

Reglas de anidación

Los distintos tipos de grupos tienen reglas diferentes sobre si se permite anidar (aceptar un grupo como miembro).

Reglas de anidación de grupos de organización

Es recomendable anidar grupos de organización para reflejar tu organigrama. Con este enfoque, todos los empleados se incluyen en un grupo y, a su vez, los grupos se incluyen entre sí. Por ejemplo, el grupo org.finance-all puede contener los grupos org.finance-us, org.finance-germany y org.finance-australia como miembros.

Puedes añadir grupos de organización a cualquier otro tipo de grupo como miembros. Esto puede ser mucho más fácil que tener que añadir a todos los miembros de un grupo de la organización a otro grupo.

No añadas ningún otro tipo de grupo a un grupo de organización como miembro. No utilices grupos de acceso, de cumplimiento o de colaboración como parte de una jerarquía organizativa.

Reglas de anidación de grupos de colaboración

Todos los grupos de colaboración deben tener un conjunto de políticas bien definido que determine cómo se añaden los miembros. Si dos grupos de colaboración siguen las mismas políticas de pertenencia, se pueden anidar. Sin embargo, si anidas grupos de colaboración con políticas de miembros diferentes, los miembros que no cumplan las políticas de miembros de un grupo podrán convertirse en miembros. Lee atentamente las políticas de membresía antes de anidar grupos de colaboración.

Los grupos de colaboración pueden tener grupos de la organización como miembros.

Reglas de anidación de grupos de acceso

Por lo general, no deberías anidar grupos de acceso. Anidar grupos de acceso puede dificultar la determinación de quién tiene acceso a qué recursos. Además, si se anidan grupos de acceso con políticas de acceso diferentes, es posible que las entidades salten las políticas de pertenencia a grupos de acceso estrictas.

Los grupos de acceso pueden tener grupos de la organización como miembros.

Reglas de anidación de grupos de cumplimiento

No anides grupos de medidas. Si se anidan grupos de comprobación, puede resultar difícil determinar por qué se deniega el acceso a un principal. Además, anidar grupos de aplicación con políticas de pertenencia diferentes puede provocar que algunos principales se vean afectados por restricciones no deseadas.

Los grupos de cumplimiento pueden tener grupos de la organización como miembros.

Gestionar grupos de la organización

Sigue estas prácticas recomendadas para gestionar tus grupos de organización.

Aprovisionar desde una única fuente de información veraz

Como los grupos organizativos se basan en datos de recursos humanos, lo más recomendable es aprovisionarlos exclusivamente desde un sistema de información de recursos humanos o desde una fuente externa fiable, como un proveedor de identidades (IdP) externo o un sistema de gestión de identidades como Sailpoint, Okta o Entra ID.

No permitir modificaciones de grupos

No añadas ni quites usuarios de un grupo organizativo manualmente, y no permitas que los usuarios se quiten a sí mismos de un grupo organizativo.

No utilices grupos de organización para proporcionar acceso a los recursos

No es habitual que todos los usuarios de un grupo de organización necesiten el mismo nivel de acceso a los recursos. Por este motivo, si se concede acceso a un grupo de una organización, es probable que algunos miembros del grupo tengan más acceso del que realmente necesitan.

Además, puede haber un retraso entre el momento en que se realizan los cambios en un IdP externo y el momento en que se propagan a Cloud Identity, en función de la frecuencia de sincronización del IdP externo con Cloud Identity. Este retraso puede provocar la proliferación de permisos excesivos. Por ejemplo, puede llevar a los propietarios de recursos a conceder acceso a grupos ya creados en lugar de crear un grupo nuevo, aunque esos grupos incluyan a personas que no necesiten acceder al recurso.

Si debes proporcionar acceso mediante un grupo organizativo, añade el grupo organizativo como miembro a un grupo de acceso en lugar de conceder acceso directamente y solo asigna roles con permisos limitados, como el de lector de la organización. De lo contrario, usa grupos de acceso para proporcionar acceso a los recursos.

No permitir cuentas de servicio ni usuarios externos en grupos de la organización

No incluyas cuentas de servicio en grupos de una organización, ya que no representan a personas.

Los usuarios externos (usuarios de otra cuenta de Google Workspace o Cloud Identity) no suelen formar parte de tu organización, por lo que no hay ningún motivo para que sean miembros de un grupo de la organización. Si incorporas a tu plantilla externa a tu cuenta de Google Workspace o Cloud Identity, se considerarán usuarios internos y podrás incluirlos en los grupos de tu organización.

Usa grupos de seguridad de Cloud Identity y restricciones de grupo para aplicar estas reglas.

Gestionar grupos de colaboración

Sigue estas prácticas recomendadas para gestionar tus grupos de colaboración.

Usar Grupos para empresas para gestionar grupos de colaboración

Si usas Google Workspace, puedes usar Grupos para empresas para gestionar grupos de colaboración. Esto permite a los usuarios usar Grupos de Google para crear grupos, buscar en ellos y unirse a ellos. Debes configurar Grupos para empresas para permitir que los usuarios creen grupos de colaboración.

Inhabilitar Grupos para empresas si no lo usas

Si usas Cloud Identity, pero no Google Workspace, no hay ningún motivo para tener grupos de colaboración en Cloud Identity, por lo que es mejor inhabilitar Grupos para empresas para evitar que tus usuarios creen grupos en Cloud Identity.

Forzar un sufijo para los grupos de colaboración

Si usas Grupos para empresas, configúralo para aplicar un sufijo. Esto es especialmente importante si permites que todos los usuarios creen grupos de Grupos para empresas.

Al aplicar un sufijo, se impide que los usuarios creen un grupo con un nombre que coincida intencionadamente con un grupo de acceso o un grupo organizativo que se vaya a aprovisionar desde una fuente externa. Este caso podría permitir que el creador del grupo de colaboración con nombre falso aumente sus privilegios.

No uses grupos de colaboración para controlar el acceso

Los grupos de colaboración están diseñados para tener un control de acceso flexible y, por lo general, no siguen un ciclo de vida bien definido. Esto las hace adecuadas para la colaboración, pero no para el control de acceso.

Si has seguido estrictamente una convención de nomenclatura para tus grupos de colaboración, puedes crear una restricción de política de organización personalizada para evitar que se asignen roles de gestión de identidades y accesos a los grupos de colaboración.

Del mismo modo, si aprovisionas y gestionas tus grupos de colaboración de forma externa, no los aprovisiones en Cloud Identity, ya que podrían usarse de forma inadecuada para controlar el acceso.

Gestionar grupos de acceso

Sigue las prácticas recomendadas que se indican a continuación para gestionar tus grupos de acceso.

Seleccionar la herramienta adecuada para gestionar tus grupos de acceso

Como los propietarios de las cargas de trabajo gestionan los grupos de acceso, utiliza una herramienta adecuada para el autoservicio. Tu herramienta debe permitir que los usuarios encuentren grupos de acceso y aplicar medidas de seguridad que incluyan los siguientes controles:

  • Quién (miembros de qué grupo de la organización) puede unirse a un grupo de acceso

  • Requisitos que debe cumplir un usuario para unirse a un grupo

    Por ejemplo, ¿los usuarios deben justificar su solicitud?

  • Tiempo de vida máximo de la pertenencia a un grupo

  • Si la pertenencia debe aprobarse y quién debe hacerlo

  • Compatibilidad con el registro de auditoría

Una herramienta que cumple estos requisitos es JIT Groups.

Usar grupos de acceso para modelar funciones laborales y conceder acceso a recursos

Crea un grupo de acceso para cada función y concédele acceso a todos los recursos que necesiten los usuarios que desempeñen esa función. Después, puede añadir a los usuarios que desempeñen ese puesto al grupo para darles el acceso que necesiten en lugar de asignar los mismos roles a cada usuario.

Puedes usar un solo grupo de acceso para proporcionar acceso a varios recursos o incluso a varios proyectos. Sin embargo, asegúrate de que cada miembro del grupo necesite el acceso que le concedas. Si algunos usuarios no necesitan el acceso adicional, crea un nuevo grupo de acceso y concédele ese acceso en su lugar.

Usar grupos de acceso para una carga de trabajo específica

Reutilizar grupos de acceso para varias cargas de trabajo conlleva un exceso de permisos y una complejidad administrativa.

Eliminar las barreras que impiden crear grupos de acceso para los propietarios de cargas de trabajo

Para reducir la tentación de reutilizar un grupo de acceso, haz que los grupos de acceso sean fáciles de crear y mantener. Los propietarios de cargas de trabajo deberían poder crear grupos de acceso de forma autónoma, con nombres adecuados.

Permitir que los usuarios busquen grupos de acceso y se unan a ellos

Si los usuarios pueden descubrir grupos de acceso y unirse a los que necesiten, será menos probable que acumulen privilegios innecesarios. Si es necesario, puedes usar un proceso de invitación o aprobación para controlar quién puede unirse al grupo.

Dejar que las suscripciones caduquen automáticamente de forma predeterminada

Solicitar a los usuarios que vuelvan a unirse a un grupo de acceso o que amplíen su membresía después de un periodo determinado. Esta práctica añade fricción intencionadamente para seguir siendo miembro de un grupo de acceso y crea un incentivo para dejar que caduquen las membresías innecesarias. Esta práctica recomendada es fundamental para alcanzar el objetivo de privilegios permanentes cero (ZSP) y es especialmente importante para los usuarios externos.

Sin embargo, no apliques esta regla a las cuentas de servicio, ya que si quitas cuentas de servicio de un grupo de acceso, se pueden producir interrupciones en el servicio.

Asigna propietarios a cada grupo

Cada grupo de acceso debe tener uno o varios propietarios designados. De esta forma, se fomenta la responsabilidad de pertenecer al grupo. Los propietarios pueden ser la misma persona o el mismo equipo que posee la carga de trabajo asociada al grupo.

Limitar la visibilidad de los grupos de acceso

No hagas que los grupos de acceso se muestren en el directorio de Grupos. Deberían aparecer en tu herramienta de gestión de grupos de acceso. Además, permite que solo los miembros del grupo puedan ver quién más forma parte de él. Estas prácticas evitan que los agentes perniciosos obtengan información valiosa.

Limitar miembros externos

Como las restricciones de la política de uso compartido restringido por dominio (DRS) se aplican a los grupos, pero no a los miembros de los grupos, los grupos de acceso que permiten miembros externos pueden crear una brecha que socave la DRS.

Usa grupos de seguridad de Cloud Identity y restricciones de grupo para permitir o denegar el acceso a grupos a miembros externos. Además, te recomendamos que utilices una convención de nomenclatura especial, como external.access.GROUP_NAME@example.com, para los grupos de acceso que permitan miembros externos.

Gestionar grupos de medidas por incumplimiento de políticas

Sigue estas prácticas recomendadas para gestionar tus grupos de medidas.

Seleccionar la herramienta adecuada para gestionar tus grupos de medidas

Dado que la pertenencia a grupos de cumplimiento se basa en reglas de la organización y se usa para aplicar restricciones de seguridad, no permitas que los miembros se excluyan o se eliminen de un grupo de cumplimiento.

Con los grupos dinámicos, puedes automatizar el aprovisionamiento de grupos de cumplimiento. Si utilizas un IdP externo, usa los grupos dinámicos que proporciona el IdP y, a continuación, aprovisiona los grupos en Cloud Identity. Ten en cuenta que, si usas un proveedor de identidades externo, las actualizaciones de las políticas pueden tardar más.

Si no puedes usar grupos dinámicos, considera la posibilidad de usar Terraform u otra herramienta de infraestructura como código (IaC) para aprovisionar tus grupos de medidas. Si usas IaC para crear grupos de aplicación, asegúrate de no dar un acceso demasiado amplio a la canalización.

Usar grupos de aplicación para el control de acceso obligatorio y los controles de autenticación

Usa grupos de acceso para aplicar el control de acceso obligatorio. Google Cloud admite el control de acceso obligatorio con varios servicios y herramientas, entre los que se incluyen los siguientes:

Los grupos de implementación también se usan para aplicar controles de autenticación, como la asignación de perfiles SAML o la verificación en dos pasos.

Como todos estos controles restringen funciones o eliminan el acceso, los grupos de cumplimiento son la opción adecuada.

No permitir que los usuarios abandonen un grupo de medidas

Permitir que los usuarios abandonen un grupo de aplicación va en contra de los principios del control de acceso obligatorio. Para impedir que los usuarios abandonen el grupo, usa la API Groups Settings para asignar el valor NONE_CAN_LEAVE a la propiedad whoCanLeaveGroup.

Prácticas recomendadas para proveedores de identidades externos

Si usas un IdP externo para la autenticación, puede ser útil usarlo también para aprovisionar grupos de la organización y grupos de aplicación.

No uses una fuente externa para los grupos de acceso

Es posible gestionar grupos de acceso en el IdP externo y aprovisionarlos en Cloud Identity, pero este enfoque tiene varios inconvenientes:

  • Retrasos en el aprovisionamiento

    Los cambios realizados en el IdP externo pueden tardar varias horas en reflejarse en el grupo de acceso.

  • Riesgo de divergencia

    Algunos IdPs no toman el control autorizado de los grupos. Por ejemplo, es posible que no eliminen un grupo en Cloud Identity después de que se haya eliminado externamente o que eliminen activamente a los miembros de un grupo que estén en Cloud Identity, pero no en el proveedor de identidades.

    Si hay divergencias, los usuarios pueden conservar el acceso que no necesitan y recibir información incorrecta sobre quién tiene acceso. También puede dificultar la creación de grupos de acceso.

Para evitar estos problemas, usa IdPs externos para aprovisionar solo grupos de la organización y de cumplimiento, y usa una herramienta como JIT Groups para gestionar los grupos de acceso directamente en Cloud Identity.

Usar un dominio secundario si vas a mapear grupos por nombre

Cloud Identity identifica los grupos por su dirección de correo, pero es posible que los grupos de tu proveedor de identidades externo no tengan una dirección de correo.

Muchos proveedores de identidades te permiten solucionar este problema derivando una dirección de correo seudónima del nombre del grupo, como my-group@example.com. Esto funciona, pero puede provocar colisiones si esta dirección de correo ya la usa otro grupo u otro usuario. En el peor de los casos, un agente malintencionado podría aprovechar esta colisión de nombres para crear grupos de seguridad que se hagan pasar por otro tipo de grupo menos vigilado.

Para evitar el riesgo de colisiones, usa un dominio secundario específico para los grupos que aprovisiones desde la fuente externa, como groups.example.com.

No concedas el rol Administrador de grupos a las canalizaciones de implementación

Si usas IaC para gestionar grupos (por ejemplo, Terraform), tu canalización de implementación debe tener los permisos necesarios para llevar a cabo su tarea. El rol Administrador de grupos autoriza la creación de grupos, pero también permite que cualquier principal con ese rol gestione todos los grupos de la cuenta de Cloud Identity.

Para restringir el acceso a una canalización, puedes crear una cuenta de servicio con un solo permiso (la capacidad de crear un grupo) y, a continuación, hacer que la canalización sea la propietaria de cualquier grupo que cree. De esta forma, la canalización puede gestionar cualquier grupo que cree y crear más grupos sin autorización para gestionar ningún grupo que no haya creado.

A continuación, se describen los pasos que debes seguir:

  1. Crea un rol de administrador personalizado que solo incluya el permiso de creación de grupos de la API Admin.

    Asigna un nombre descriptivo a este rol, como Creador de grupos.

  2. Crea una cuenta de servicio y asígnale el rol Creador de grupos.

  3. Usa la cuenta de servicio de tu canal y pasa la marca WITH_INITIAL_OWNER al crear el grupo.

Usa Cloud Logging para auditar y monitorizar tus grupos.

Registros te permite recoger, monitorizar y analizar la actividad de los grupos.

Auditar los cambios de miembros

Añadir o quitar un miembro de un grupo de la organización, un grupo de acceso o un grupo de cumplimiento puede afectar a los recursos a los que tiene acceso el miembro, por lo que es importante mantener un registro de auditoría que haga un seguimiento de estos cambios.

Requerir justificaciones para unirse a grupos de acceso

Para que los datos de monitorización sean más útiles, pide a los usuarios que proporcionen una justificación cuando se unan a un grupo o soliciten unirse a él, y registra la justificación. Si hay un proceso de aprobación, registra los detalles sobre quién ha aprobado la solicitud.

Estos metadatos adicionales pueden ayudarte más adelante a analizar por qué se ha añadido a un usuario a un grupo y, por tanto, por qué se le ha dado acceso a determinados recursos.

Habilitar el uso compartido de registros de auditoría de Cloud Identity

Configura Cloud Identity para enrutar registros a Cloud Logging de forma que puedas gestionar estos registros de auditoría de la misma forma que otros registros de Google Cloud , como configurar alertas o usar un sistema externo de gestión de eventos e información de seguridad (SIEM).