Prácticas recomendadas para usar Grupos de Google

En este documento, se describen algunas prácticas recomendadas para usar los grupos de Google y administrar el acceso a los recursos de Google Cloud con Identity and Access Management (IAM).

Tipos de grupos

Los tipos de grupos que se enumeran aquí son una forma de pensar, usar y administrar los Grupos de Google. Ningún atributo de Grupo de Google establece estos tipos de grupos. Sin embargo, usar estos tipos de grupos en tu enfoque general de la administración de grupos de Google puede ayudarte a evitar algunos errores de seguridad comunes.

En este documento, se usan los siguientes tipos de grupos:

  • Grupos organizativos

    Los grupos organizativos representan subconjuntos de la estructura de una organización y, por lo general, provienen de los datos de recursos humanos. Pueden basarse en el departamento, la estructura de informes, la ubicación geográfica o en otras agrupaciones organizativas.

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

    La estructura general de los grupos organizativos puede cambiar cuando la empresa se reorganiza. Una reorganización puede generar la creación de grupos nuevos o la baja de los existentes.

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

    Por lo general, los grupos organizativos se usan 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 desean collaborar en un proyecto o analizar un tema específico.

    La estructura de los grupos de colaboración no está vinculada a ninguna estructura organizacional. A menudo, se crean de forma ad hoc y de autoservicio.

    La membresía en los grupos de colaboración puede ser sin restricciones, lo que permite que cualquier persona de la organización se una. Como alternativa, un grupo de colaboración se puede autoadministrar, lo que significa que ciertos miembros pueden decidir a quién más incluir en el grupo.

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

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

  • Grupos de acceso

    Los grupos de acceso se usan con el único propósito de proporcionar acceso. Representan funciones laborales y se usan para simplificar la asignación de roles necesarios para realizarlas. En lugar de otorgar roles a principales individuales, otorgas roles al grupo y, luego, administras su membresía.

    La estructura de los grupos de acceso está influenciada por la estructura de los recursos o las cargas de trabajo de tu organización. La implementación de un nuevo recurso o una nueva carga de trabajo puede requerir la creación de grupos de acceso nuevos.

    Por lo general, la membresía en los grupos de acceso está controlada por uno o más propietarios del grupo, que invitan a los usuarios al grupo o aprueban sus solicitudes para unirse al grupo.

    Algunos ejemplos de grupos de acceso incluyen 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 aplicación

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

    Por lo general, la estructura de los grupos de aplicación está influenciada por una combinación de requisitos de cumplimiento y estructura organizativa.

    La membresía en un grupo de aplicación de políticas suele estar determinada por un conjunto de reglas predefinidas que analizan el nivel de autorización, la ubicación o el rol de un usuario en la organización.

    Algunos ejemplos de grupos de aplicación incluyen 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 para que reflejen su tipo

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

Convención de nombres

Este es un ejemplo de una convención de nombres para que el tipo de grupo sea visible:

  • Grupos de organizaciones: 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 aplicación: enforcement.GROUP_DESCRIPTION@example.com. Por ejemplo, enforcement.sso-users@example.com

Adopta la convención que funcione para tu organización y que sea compatible con tu software de administración de grupos. Si usas un prefijo, tus grupos se alfabetizan por función, pero algunos sistemas de administració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 nombres, puedes usar dominios secundarios para incorporar 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 ni es necesario que existan en DNS. Además, si no creas registros de intercambio de correo electrónico (MX) de DNS para los dominios secundarios, puedes bloquear los correos electrónicos entrantes para que no lleguen a los grupos que no están destinados a la comunicación.

Reglas de anidación

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

Reglas de anidación para grupos organizativos

Una práctica recomendada es anidar grupos organizativos para que reflejen tu organigrama. Este enfoque significa que cada empleado se incluye en un grupo y, luego, los grupos se incluyen entre sí. Por ejemplo, el grupo org.finance-all podría contener los grupos org.finance-us, org.finance-germany y org.finance-australia como miembros.

Puedes agregar grupos organizativos a cualquiera de los otros tipos de grupos como miembros. Esto puede ser mucho más fácil que tener que agregar a cada miembro de un grupo de la organización a otro grupo.

No agregues ningún otro tipo de grupo a un grupo organizativo como miembro. No uses grupos de acceso, aplicación forzosa ni colaboración como parte de una jerarquía organizativa.

Reglas de anidación para grupos de colaboración

Cada grupo de colaboración debe tener un conjunto bien definido de políticas que determinen cómo se agregan los miembros. Si dos grupos de colaboración siguen las mismas políticas de membresía, se pueden anidar. Sin embargo, anidar grupos de colaboración con diferentes políticas de membresía puede permitir que los miembros que no cumplen con las políticas de membresía de un grupo se conviertan en miembros. Revisa las políticas de membresía cuidadosamente antes de anidar grupos de colaboración.

Los grupos de colaboración pueden tener grupos organizativos como miembros.

Reglas de anidación para grupos de acceso

Por lo general, no debes anidar grupos de acceso. El anidamiento de grupos de acceso puede dificultar la determinación de quién tiene acceso a qué recursos. Además, el anidamiento de grupos de acceso con diferentes políticas de acceso podría permitir que las principales omitan las políticas estrictas de membresía de grupos de acceso.

Los grupos de acceso pueden tener grupos organizativos como miembros.

Reglas de anidación para grupos de aplicación

No anides grupos de aplicación forzosa. El anidamiento de grupos de aplicación puede dificultar determinar por qué se le niega el acceso a un principal. Además, anidar grupos de aplicación forzosa con diferentes políticas de membresía podría hacer que algunos directores se vean afectados por restricciones no deseadas.

Los grupos de aplicación de políticas pueden tener grupos organizativos como miembros.

Administra grupos organizativos

Usa las siguientes prácticas recomendadas para administrar tus grupos organizativos.

Aprovisiona desde una única fuente de información

Debido a que los grupos organizativos se basan en datos de recursos humanos, lo mejor es aprovisionarlos exclusivamente desde un sistema de información de recursos humanos o desde una fuente de verdad externa, por ejemplo, un proveedor de identidad externo (IdP) o un sistema de administración de identidades, como Sailpoint, Okta o Entra ID.

No permitir modificaciones en el grupo

No agregues ni quites usuarios de un grupo organizativo de forma manual ni permitas que los usuarios se quiten de un grupo organizativo.

Evita usar grupos organizativos para proporcionar acceso a los recursos

Raramente todos los usuarios de un grupo organizativo necesitan el mismo nivel de acceso a los recursos. Por este motivo, es probable que otorgar acceso a un grupo organizativo haga que algunos miembros del grupo tengan más acceso del que realmente necesitan.

Además, puede haber una demora entre el momento en que se realizan los cambios en un IdP externo y el momento en que se propagan a Cloud Identity, según la frecuencia de sincronización del IdP externo a Cloud Identity. Esta demora puede generar la proliferación de permisos excesivos. Por ejemplo, podría llevar a que los propietarios de recursos otorguen acceso a grupos existentes en lugar de crear uno nuevo, incluso si esos grupos existentes contienen personas que no necesitan acceder al recurso.

Si debes proporcionar acceso con un grupo organizativo, agrégalo como miembro a un grupo de acceso, en lugar de otorgar acceso directamente, y solo otorga roles con permisos limitados, como el Visualizador de la organización. De lo contrario, usa grupos de acceso para proporcionar acceso a los recursos.

No permitas cuentas de servicio ni usuarios externos en los grupos organizativos

No incluyas cuentas de servicio en los grupos de organizaciones, ya que no representan a personas.

Por lo general, los usuarios externos (usuarios de una cuenta de Google Workspace o Cloud Identity diferente) no forman parte de tu organización, por lo que no hay razón para que sean miembros de un grupo de organización. Si integras a tu personal externo a tu propia cuenta de Google Workspace o Cloud Identity, se considerarán usuarios internos y se podrán incluir en tus grupos organizativos.

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

Administra grupos de colaboración

Usa las siguientes prácticas recomendadas para administrar tus grupos de colaboración.

Usa Grupos para empresas para administrar grupos de colaboración

Si usas Google Workspace, puedes usar Grupos para empresas para administrar grupos de colaboración. Esto permite que los usuarios usen Grupos de Google para crear, explorar y unirse a grupos. Debes configurar Grupos para empresas para permitir que los usuarios creen nuevos grupos de colaboración.

Inhabilita Grupos para empresas si no lo usas

Si usas Cloud Identity, pero no Google Workspace, entonces no hay razón para tener grupos de colaboración en Cloud Identity, por lo que es mejor que inhabilitas Grupos para empresas para evitar que los usuarios creen grupos en Cloud Identity.

Cómo forzar un sufijo para los grupos de colaboración

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

La aplicación forzosa de un sufijo evita que los usuarios creen un grupo con un nombre que entre en conflicto de forma intencional con un grupo de acceso o un grupo organizativo que se aprovisionará desde una fuente externa. Esta situación podría permitir que el creador del grupo de colaboración con nombre falso derive sus privilegios.

No uses grupos de colaboración para el control de acceso

Los grupos de colaboración deben tener un control de acceso flexible y, por lo general, no siguen un ciclo de vida bien definido. Eso los hace buenos para la colaboración, pero malos para el control de acceso.

Si seguiste estrictamente una convención de nombres para tus grupos de colaboración, puedes crear una restricción de política de la organización personalizada para evitar que se les otorguen roles de IAM a los grupos de colaboración.

Del mismo modo, si aprovisionas y administras tus grupos de colaboración de forma externa, no los aprovisiones a Cloud Identity, ya que se podrían usar de forma inadecuada para el control de acceso.

Administra los grupos de acceso

Usa las siguientes prácticas recomendadas para administrar tus grupos de acceso.

Selecciona la herramienta adecuada para administrar tus grupos de acceso

Debido a que los propietarios de cargas de trabajo administran los grupos de acceso, usa una herramienta adecuada para el autoservicio. Tu herramienta debe permitir que los usuarios encuentren grupos de acceso existentes y aplicar controles de seguridad que apliquen los siguientes controles:

  • Quiénes (miembros de qué grupo organizativo) pueden unirse a un grupo de acceso

  • Qué requisitos deben cumplirse para que un usuario se una a un grupo

    Por ejemplo, ¿los usuarios deben proporcionar una justificación?

  • Duración máxima de la membresía del grupo

  • Si se debe aprobar la membresía y quién lo hace

  • Compatibilidad con el registro de auditoría

Una herramienta que se ajusta a estos requisitos son los grupos JIT.

Usa grupos de acceso para modelar funciones laborales y otorgar acceso a los recursos

Crea un grupo de acceso para cada puesto de trabajo y bríndale acceso a todos los recursos que los usuarios de ese puesto de trabajo necesitan. Luego, puedes agregar al grupo a los usuarios que tengan esa función para darles el acceso que necesitan en lugar de otorgar los mismos roles a cada usuario individual.

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 otorgues. Si algunos usuarios no necesitan el acceso adicional, crea un grupo de acceso nuevo y, en su lugar, bríndale ese acceso adicional.

Usa tus grupos de acceso para una carga de trabajo específica

La reutilización de grupos de acceso para varias cargas de trabajo genera una complejidad excesiva de permisos y administración.

Quita las barreras para crear grupos de acceso para los propietarios de cargas de trabajo

Para reducir la tentación de volver a usar un grupo de acceso existente, haz que los grupos de acceso sean fáciles de crear y mantener. Los propietarios de cargas de trabajo deben poder crear grupos de acceso de forma autónoma, con compatibilidad para nombres adecuados.

Permite que los usuarios encuentren grupos de acceso y se unan a ellos

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

Permite que las membresías venzan automáticamente de forma predeterminada

Solicita a los usuarios que vuelvan a unirse a un grupo de acceso o que extiendan su membresía después de un período determinado. Esta práctica agrega intencionalmente fricciones para seguir siendo miembro de un grupo de acceso y crea un incentivo para que venza la membresía que no se necesita. Esta práctica recomendada es fundamental para lograr 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 quitarlas de un grupo de acceso puede provocar interrupciones del servicio.

Asignar propietarios designados a cada grupo

Cada grupo de acceso debe tener uno o más propietarios designados. Esto fomenta un sentido de responsabilidad por la membresía del grupo. Los propietarios pueden ser la misma persona o el mismo equipo que posee la carga de trabajo asociada con el grupo.

Limita la visibilidad de los grupos de acceso

No hagas que los grupos de acceso sean visibles en el directorio de grupos. (Deben ser detectables en tu herramienta de administración de grupos de acceso). Además, solo los miembros del grupo podrán ver quiénes más son miembros. Estas prácticas evitan que las personas que actúan de mala fe obtengan información valiosa.

Limita los miembros externos

Debido a que las restricciones de la política de uso compartido restringido de dominios (DRS) se aplican a los grupos, pero no a los miembros, los grupos de acceso que permiten miembros externos pueden crear un vacío legal que socave el DRS.

Usa los grupos de seguridad de Cloud Identity y las restricciones de grupos para permitir o denegar miembros externos en los grupos de acceso. Además, considera usar una convención de nombres especial, como external.access.GROUP_NAME@example.com, para los grupos de acceso que permiten miembros externos.

Administra los grupos de aplicación de políticas

Usa las siguientes prácticas recomendadas para administrar tus grupos de aplicación.

Selecciona la herramienta adecuada para administrar tus grupos de aplicación de políticas

Debido a que la membresía en los grupos de aplicación se basa en reglas de la organización y se usa para aplicar restricciones de seguridad, no permitas que los miembros inhabiliten la función ni se quiten de un grupo de aplicación.

El uso de grupos dinámicos te permite automatizar el aprovisionamiento de grupos de aplicación forzosa. Si usas un IdP externo, usa los grupos dinámicos que proporciona el IdP y, luego, aprovisionalos a Cloud Identity. Ten en cuenta que usar un IdP externo puede generar una demora en las actualizaciones de políticas.

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

Usa grupos de aplicación forzosa 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 una serie de servicios y herramientas, incluidos los siguientes:

Los grupos de aplicación forzosa también se usan para aplicar controles de autenticación, como la asignación de perfiles de SAML o la verificación en 2 pasos (2SV).

Debido a que todos estos controles restringen funciones o quitan el acceso, los grupos de aplicación forzosa son la opción correcta.

No permitir que los usuarios salgan de un grupo de aplicación forzosa

Permitir que los usuarios salgan de un grupo de aplicación de políticas va en contra de los principios del control de acceso obligatorio. Para impedir que los usuarios salgan del grupo, usa la API de Groups Settings para establecer la propiedad whoCanLeaveGroup en NONE_CAN_LEAVE.

Prácticas recomendadas para las IdP externas

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

Evita usar una fuente externa para los grupos de acceso

Es posible administrar grupos de acceso en el IdP externo y aprovisionarlos a Cloud Identity, pero este enfoque tiene varias desventajas:

  • Retrasos en el aprovisionamiento

    Los cambios realizados en la IdP externa pueden tardar hasta varias horas en reflejarse en el grupo de acceso.

  • Riesgo de divergencia

    Algunas IdP no toman el control de autoridad de los grupos. Por ejemplo, es posible que no borren un grupo en Cloud Identity después de que se borre de forma externa, o que borren de forma activa a los miembros del grupo que existen en Cloud Identity, pero no en el IdP.

    La divergencia puede hacer que los usuarios retengan el acceso que no necesitan y les proporciona información incorrecta sobre quién tiene acceso. También puede generar inconvenientes a la hora de crear grupos de acceso.

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

Usa un dominio secundario si asignas grupos por nombre

Cloud Identity identifica los grupos por dirección de correo electrónico, pero es posible que los grupos de tu IdP externo no tengan una dirección de correo electrónico.

Muchas IdPs te permiten evitar este problema, ya que te permiten derivar una dirección de correo electrónico ficticia del nombre del grupo, como usar my-group@example.com. Esto funciona, pero puede generar colisiones cuando un grupo o usuario diferente ya usa esta dirección de correo electrónico. En el peor de los casos, un atacante podría aprovechar esta colisión de nombres para crear grupos de seguridad que se hagan pasar por otro tipo de grupo menos examinado.

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

Evita otorgar el rol de administrador de grupos a las canalizaciones de implementación

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

Para restringir el acceso otorgado a una canalización, crea una cuenta de servicio con un solo permiso (la capacidad de crear un grupo) y, luego, haz que la canalización sea el propietario de cualquier grupo que cree. Eso permite que esa canalización administre cualquier grupo que cree y cree más grupos, sin autorizarla a administrar cualquier grupo que no haya creado.

En los siguientes pasos, se describe este enfoque:

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

    Asigna un nombre descriptivo a este rol, como Creador del grupo.

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

  3. Usa la cuenta de servicio de tu canalización y pasa la marca WITH_INITIAL_OWNER en el momento de la creación del grupo.

Usa Cloud Logging para auditar y supervisar tus grupos.

Registro te permite recopilar, supervisar y analizar la actividad del grupo.

Cómo auditar los cambios en las membresías

Agregar o quitar un miembro de un grupo organizativo, de acceso o de aplicación de políticas puede afectar a los recursos a los que tiene acceso, por lo que es importante mantener un registro de auditoría que haga un seguimiento de estos cambios.

Solicita justificaciones para unirse a grupos de acceso

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

Estos metadatos adicionales pueden ayudarte más adelante a analizar por qué se agregó a alguien a un grupo y, por extensión, por qué se le otorgó acceso a ciertos recursos.

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

Configura Cloud Identity para enrutar registros a Cloud Logging de modo que puedas controlar estos registros de auditoría de la misma manera que otros registros de Google Cloud, lo que incluye configurar alertas o usar un sistema externo de administración de información y eventos de seguridad (SIEM).