Integración de Google Workspace con Wazuh mediante Wodle sin Docker

1. Objetivo

El objetivo de esta integración es recolectar eventos de auditoría y alertas de seguridad desde Google Workspace e incorporarlos en Wazuh para análisis, correlación, generación de alertas y visualización desde el módulo de Threat Hunting. La integración se realiza mediante un wodle personalizado llamado gworkspace, ejecutado directamente por el Wazuh Manager mediante el módulo command. Este wodle consulta las APIs de Google Workspace, transforma los eventos en formato JSON y entrega la salida a Wazuh para que sea procesada por el motor de análisis y las reglas personalizadas.

2. Arquitectura de la integración

Flujo general:

Google Workspace
    |
    | Admin SDK API
    | Google Workspace Alert Center API
    |
GCP Service Account
    |
    | Domain-wide delegation
    |
Usuario de servicio de Google Workspace
    |
    | Impersonación controlada
    |
Wazuh Manager
    |
    | /var/ossec/wodles/gworkspace/gworkspace
    |
Wazuh Command Wodle
    |
    | Eventos JSON
    |
Wazuh Analysis Engine
    |
    | Reglas 64600 - 65499
    |
Wazuh Indexer / Dashboard

3. Componentes utilizados

Google Cloud Platform

Se utiliza un proyecto en Google Cloud para crear una Service Account con una llave JSON. Esta Service Account será autorizada mediante Domain-wide Delegation para consultar eventos de Google Workspace.

Google Workspace Admin Console

Desde Google Workspace se autoriza la Service Account de GCP para que pueda actuar en nombre de un usuario de servicio del dominio.

Usuario de servicio en Google Workspace

Se crea un usuario de Google Workspace, por ejemplo:

svc-wazuh-monitoring@dominio.com

Este usuario no requiere licencia de pago. Su función es servir como identidad delegada para que el wodle pueda consultar eventos y alertas.

Wazuh Manager

El Wazuh Manager ejecuta periódicamente el wodle:

/var/ossec/wodles/gworkspace/gworkspace

La salida del wodle es procesada por Wazuh como eventos JSON.

4. APIs requeridas en Google Cloud

En el proyecto de Google Cloud llamado, por ejemplo, Wazuh, se deben habilitar las siguientes APIs:

Admin SDK API
Google Workspace Alert Center API

La Admin SDK API permite consultar eventos de auditoría de aplicaciones como:

Admin
Login
Drive
Gmail
Token
Groups
User Accounts
SAML
Mobile
Vault
GCP

La Google Workspace Alert Center API permite consultar alertas generadas por Google Workspace, como eventos de seguridad, actividad sospechosa, posibles compromisos de cuenta o alertas administrativas.

5. Creación de Service Account en GCP

En Google Cloud Console:

IAM & Admin → Service Accounts → Create Service Account

Nombre sugerido:

Wazuh Monitoring

Luego se debe crear una llave JSON:

Service Account → Keys → Add Key → Create new key → JSON

El archivo JSON descargado debe almacenarse de forma segura, ya que contiene la clave privada que será usada por el wodle. Importante:

Si la llave JSON fue expuesta en pantalla, repositorios, capturas o chats, debe considerarse comprometida.
En ese caso se debe eliminar la key en Google Cloud y generar una nueva.

6. Domain-wide Delegation en Google Workspace

Una vez creada la Service Account en GCP, se debe copiar su Client ID. Este valor suele encontrarse en el JSON como:

"client_id": "xxxxxxxxxxxxxxxxxxxxx"

Luego, en Google Admin Console:

Security → Access and data control → API controls → Domain-wide delegation

Se debe agregar una nueva delegación con el Client ID de la Service Account y los siguientes scopes:

https://www.googleapis.com/auth/admin.reports.audit.readonly
https://www.googleapis.com/auth/apps.alerts

El primer scope permite leer eventos de auditoría de Google Workspace. El segundo scope permite leer alertas desde Google Workspace Alert Center.

7. Usuario de servicio en Google Workspace

Se recomienda crear una unidad organizativa llamada:

Service accounts

Dentro de esa OU se crea el usuario:

svc-wazuh-monitoring@dominio.com

Este usuario debe cumplir con lo siguiente:

No tener licencia de pago asignada.
No tener acceso innecesario a aplicaciones.
Tener permisos mínimos para Reports y Alert Center.
Ser utilizado únicamente como identidad delegada.

Permisos recomendados:

Reports
Alert Center → View access

Para validación inicial, puede asignarse temporalmente un rol más alto, incluso Super Admin, solo para confirmar que el problema no sea de permisos. Una vez validada la integración, se debe reducir el permiso al mínimo necesario.

8. Instalación del wodle en Wazuh sin Docker

En el Wazuh Manager se crea la ruta del wodle:

mkdir -p /var/ossec/wodles/gworkspace
cd /var/ossec/wodles/gworkspace

Luego se copia o clona el contenido del wodle gworkspace dentro de esa ruta. Ejemplo:

git clone https://github.com/avanwouwe/wazuh-gworkspace.git /tmp/wazuh-gworkspace
cp -r /tmp/wazuh-gworkspace/wodle/* /var/ossec/wodles/gworkspace/

Asignar permisos:

chown -R root:wazuh /var/ossec/wodles/gworkspace
chmod -R 750 /var/ossec/wodles/gworkspace
chmod +x /var/ossec/wodles/gworkspace/gworkspace

9. Instalación de dependencias Python

El wodle requiere librerías de Google que normalmente no vienen incluidas por defecto en Wazuh. Validar Python interno de Wazuh:

/var/ossec/framework/python/bin/python3 --version

Instalar dependencias:

/var/ossec/framework/python/bin/python3 -m pip install google-api-python-client google-auth

Si pip no está disponible:

/var/ossec/framework/python/bin/python3 -m ensurepip
/var/ossec/framework/python/bin/python3 -m pip install --upgrade pip
/var/ossec/framework/python/bin/python3 -m pip install google-api-python-client google-auth

10. Archivo de credenciales

Copiar la llave JSON de la Service Account en:

/var/ossec/wodles/gworkspace/service_account_key.json

Ejemplo:

nano /var/ossec/wodles/gworkspace/service_account_key.json

Pegar el contenido del JSON generado desde Google Cloud. Asignar permisos:

chown root:wazuh /var/ossec/wodles/gworkspace/service_account_key.json
chmod 640 /var/ossec/wodles/gworkspace/service_account_key.json

11. Archivo de configuración del wodle

Crear el archivo:

nano /var/ossec/wodles/gworkspace/config.json

Contenido esperado:

{
  "service_account": "svc-wazuh-monitoring@dominio.com"
}

Punto importante:

El valor service_account debe ser el usuario de Google Workspace que será impersonado.
No debe ser el correo de la Service Account de GCP tipo iam.gserviceaccount.com.

Ejemplo incorrecto:

{
  "service_account": "wazuh-monitoring@proyecto.iam.gserviceaccount.com"
}

Ejemplo correcto:

{
  "service_account": "svc-wazuh-monitoring@dominio.com"
}

Asignar permisos:

chown root:wazuh /var/ossec/wodles/gworkspace/config.json
chmod 640 /var/ossec/wodles/gworkspace/config.json

12. Prueba manual del wodle

Desde el Wazuh Manager:

cd /var/ossec/wodles/gworkspace
./gworkspace -a admin --unread

También se pueden probar aplicaciones específicas:

./gworkspace -a login --unread
./gworkspace -a drive --unread
./gworkspace -a gmail --unread
./gworkspace -a token --unread
./gworkspace -a all --unread

Si la integración funciona correctamente, el comando debe devolver eventos JSON. Ejemplo esperado:

{
  "id": 123456789,
  "gworkspace": {
    "application": "login",
    "eventtype": "login",
    "eventname": "login success",
    "parameters": {}
  },
  "user": "usuario@dominio.com"
}

13. Error común: Access denied

Si aparece un error similar a:

Access denied. You are not authorized to read activity records.

Significa que el wodle logra comunicarse con Google, pero Google rechaza la lectura de eventos por permisos insuficientes. Causas comunes:

El Client ID autorizado en Domain-wide delegation no es correcto.
Falta el scope admin.reports.audit.readonly.
El usuario delegado no tiene permisos de Reports.
El config.json está usando el correo iam.gserviceaccount.com en vez del usuario Workspace.
La Admin SDK API no está habilitada.
La delegación aún no ha propagado.

Validación recomendada:

1. Confirmar que Admin SDK API esté habilitada.
2. Confirmar que Alert Center API esté habilitada.
3. Confirmar que el Client ID autorizado sea el correcto.
4. Confirmar que los scopes estén bien escritos.
5. Confirmar que config.json use el usuario Workspace.
6. Probar temporalmente con un Super Admin.
7. Si funciona con Super Admin, ajustar permisos del usuario svc-wazuh-monitoring.

14. Configuración del wodle en ossec.conf

Editar el archivo de configuración de Wazuh:

nano /var/ossec/etc/ossec.conf

Agregar dentro de <ossec_config>:

<wodle name="command">
  <disabled>no</disabled>
  <tag>gworkspace</tag>
  <command>/var/ossec/wodles/gworkspace/gworkspace -a all -o 2</command>
  <interval>10m</interval>
  <ignore_output>no</ignore_output>
  <run_on_start>yes</run_on_start>
  <timeout>0</timeout>
</wodle>

Descripción de parámetros: Parámetro Descripción disabled Habilita o deshabilita el wodle. tag Etiqueta usada para identificar la ejecución. command Comando que ejecutará Wazuh. -a all Consulta todas las aplicaciones soportadas por el wodle. -o 2 Define el offset máximo de búsqueda hacia atrás, en horas. interval Frecuencia de ejecución. ignore_output Debe estar en no para que Wazuh procese la salida. run_on_start Ejecuta el wodle al iniciar el manager. timeout Tiempo máximo de ejecución. Con 0 no se fuerza timeout. El intervalo recomendado inicial es:

10 minutos

Un intervalo más bajo puede generar más consumo de API. Un intervalo más alto puede aumentar el retraso de visualización de eventos.

15. Validación de configuración de Wazuh

Antes de reiniciar:

/var/ossec/bin/wazuh-analysisd -t

Si la validación es correcta:

systemctl restart wazuh-manager

Validar logs del manager:

tail -f /var/ossec/logs/ossec.log

Buscar errores relacionados:

grep -i gworkspace /var/ossec/logs/ossec.log
grep -i wodle /var/ossec/logs/ossec.log
grep -i command /var/ossec/logs/ossec.log

16. Reglas personalizadas

Se utiliza un archivo de reglas personalizado:

/var/ossec/etc/rules/0685-gworkspace_rules.xml

El rango reservado para esta integración es:

64600 - 65499

La regla base es:

<rule id="64600" level="3">
  <decoded_as>json</decoded_as>
  <field name="gworkspace.application">\.+</field>
  <description>Google $(gworkspace.application) : $(gworkspace.eventname)</description>
</rule>

Esta regla identifica cualquier evento JSON que contenga el campo:

gworkspace.application

A partir de esta regla base se generan reglas específicas para:

Errores del extractor
Warnings del extractor
Login
SAML
Token
Admin
Groups
User Accounts
Security Settings
Gmail / Email Settings
Vault
Drive
Alert Center
Actividad intensiva
Descargas masivas
Fallos múltiples de autenticación

17. Principales reglas implementadas

Rule ID Nivel Caso de uso 64600 3 Evento base de Google Workspace 64601 14 Error crítico del extractor 64602 12 Warning del extractor 64610 5 Eventos de login, token o SAML 64612 6 Eventos administrativos, grupos, GCP y accesos 64614 7 Rules y User Accounts 64616 10 Cambios globales en configuración de seguridad 64618 9 Acciones sobre cuarentena de correo 64620 9 Búsqueda de logs de correo 64622 10 Actividad de Vault / posible recuperación masiva 64624 12 Actividad sensible de administrador delegado 64626 12 Access Transparency 64628 10 Login sospechoso 64630 10 Actividad sospechosa en dispositivos móviles 64632 10 Warnings de cuenta, ataque o forwarding 64650 10 Descarga intensiva de archivos en Drive 64651 12 Descarga intensiva por cuenta externa 64652 10 Actividad intensiva general 64653 10 Actividad intensiva en Drive 64654 12 Muchos login failures 64655 0 Ignorar auto-delete de Drive 64700 10 Alertas de Google Workspace Alert Center

18. Validación de reglas

Validar sintaxis:

/var/ossec/bin/wazuh-analysisd -t

Reiniciar Wazuh:

systemctl restart wazuh-manager

Probar con wazuh-logtest:

/var/ossec/bin/wazuh-logtest

Evento de prueba para login failure:

{"id":123456,"gworkspace":{"application":"login","eventtype":"login","eventname":"login failure","parameters":{"login_type":"google_password"}},"user":"usuario@dominio.com"}

Resultado esperado:

Debe hacer match con la regla base 64600.
Debe clasificar el evento como actividad de login.
La regla de correlación 64654 se activará solo si se cumple la frecuencia definida.

Evento de prueba para Drive:

{"id":123457,"gworkspace":{"application":"drive","eventtype":"access","eventname":"download","parameters":{"primary_event":"true"}},"user":"usuario@dominio.com"}

Resultado esperado:

Debe hacer match con la regla base 64600.
Las reglas de actividad intensiva se activarán solo si se alcanza el umbral de frecuencia.

19. Visualización en Wazuh Dashboard

Una vez reiniciado el manager y ejecutado el wodle, los eventos deberían visualizarse desde:

Threat Hunting
Discover
Security Events

Filtro recomendado:

data.gworkspace.application: *

Filtros útiles:

data.gworkspace.application: login
data.gworkspace.application: admin
data.gworkspace.application: drive
data.gworkspace.application: gmail
data.gworkspace.application: token
data.gworkspace.application: "alert center"

Por usuario:

data.user: usuario@dominio.com

Por evento:

data.gworkspace.eventname: "login failure"
data.gworkspace.eventname: "login success"
data.gworkspace.eventname: download

Por tipo de evento:

data.gworkspace.eventtype: "security settings"
data.gworkspace.eventtype: "delegated admin"

20. Casos de uso cubiertos

Autenticación

Login exitoso
Login fallido
Login sospechoso
Múltiples fallos de autenticación
Eventos SAML
Eventos token/OAuth

Administración

Cambios administrativos
Cambios de seguridad global
Cambios de usuario
Cambios de grupos
Actividad de administrador delegado

Gmail / Correo

Eventos administrativos relacionados con correo
Búsqueda de logs de correo
Acciones sobre cuarentena
Cambios relacionados con forwarding
Eventos de seguridad asociados a Gmail

Google Drive

Descarga de archivos
Actividad intensiva
Descargas masivas
Actividad de usuarios externos
Eventos de DLP operativos

Alert Center

Alertas de seguridad generadas por Google Workspace
Alertas de comportamiento sospechoso
Alertas administrativas
Posibles compromisos de cuenta

21. Consideraciones sobre timestamp

El wodle conserva el timestamp real del evento dentro de los campos del evento, pero Wazuh puede asignar @timestamp según el momento en que el evento ingresa al motor de análisis. Esto significa que:

El evento conserva su hora real.
La visualización en Wazuh puede aparecer con algunos minutos de retraso.
El retraso dependerá del intervalo configurado en el wodle.

Con el intervalo actual:

10 minutos

El desfase esperado es aceptable para monitoreo operativo y análisis de seguridad.

22. Consideraciones de seguridad

Se deben aplicar las siguientes medidas:

Proteger el archivo service_account_key.json.
Asignar permisos restrictivos en el filesystem.
Evitar exponer la llave JSON en capturas, chats o repositorios.
Rotar la llave si fue expuesta.
Usar un usuario de servicio sin licencia.
Asignar permisos mínimos en Google Workspace.
No usar cuentas personales para la integración.
Validar periódicamente que la integración siga recolectando eventos.

Permisos recomendados en el servidor:

chown root:wazuh /var/ossec/wodles/gworkspace/service_account_key.json
chmod 640 /var/ossec/wodles/gworkspace/service_account_key.json

chown root:wazuh /var/ossec/wodles/gworkspace/config.json
chmod 640 /var/ossec/wodles/gworkspace/config.json

23. Troubleshooting

Error: Access denied

Mensaje típico:

Access denied. You are not authorized to read activity records.

Acciones:

Validar Domain-wide Delegation.
Validar Client ID.
Validar scopes.
Validar permisos del usuario delegado.
Validar que config.json use el usuario Workspace.
Probar temporalmente con un Super Admin.

No aparecen eventos en Wazuh

Acciones:

cd /var/ossec/wodles/gworkspace
./gworkspace -a admin --unread

Luego:

tail -f /var/ossec/logs/ossec.log

Validar que el wodle esté configurado:

grep -i gworkspace /var/ossec/etc/ossec.conf

Las reglas no generan alertas

Validar sintaxis:

/var/ossec/bin/wazuh-analysisd -t

Validar con logtest:

/var/ossec/bin/wazuh-logtest

Confirmar que los campos reales sean:

gworkspace.application
gworkspace.eventname
gworkspace.eventtype
gworkspace.parameters.*
user

El wodle genera extraction error

Esto indica que el wodle se está ejecutando, pero falló la extracción desde Google. Se debe revisar:

Credenciales.
Permisos.
Delegación.
Scopes.
Conectividad.
APIs habilitadas.

24. Validación final de funcionamiento

Checklist final:

1. Admin SDK API habilitada.
2. Alert Center API habilitada.
3. Service Account creada en GCP.
4. Llave JSON copiada en /var/ossec/wodles/gworkspace.
5. Domain-wide delegation configurado con Client ID correcto.
6. Scopes configurados correctamente.
7. Usuario svc-wazuh-monitoring creado en Google Workspace.
8. Usuario sin licencia de pago.
9. Usuario con permisos de Reports y Alert Center.
10. config.json apuntando al usuario Workspace correcto.
11. Dependencias Python instaladas.
12. Wodle probado manualmente.
13. ossec.conf configurado con command wodle.
14. Reglas 0685-gworkspace_rules.xml cargadas.
15. wazuh-analysisd -t ejecutado sin errores.
16. Wazuh Manager reiniciado.
17. Eventos visibles en Threat Hunting.
18. Filtro data.gworkspace.application:* devuelve resultados.

25. Conclusión

La integración implementada permite centralizar eventos de Google Workspace en Wazuh sin necesidad de Docker, usando el mecanismo nativo de Wazuh command wodle. El flujo permite recolectar eventos de autenticación, administración, Gmail, Drive, tokens/OAuth, grupos, usuarios, Vault y Alert Center. Estos eventos son normalizados en formato JSON y procesados por reglas personalizadas en el rango 64600 - 65499. Con esta integración, Wazuh puede generar alertas sobre actividad sospechosa en Google Workspace, como múltiples fallos de login, cambios administrativos sensibles, actividad intensiva en Drive, acciones sobre correo, eventos de usuario, eventos OAuth y alertas provenientes de Google Workspace Alert Center. La siguiente etapa recomendada es validar durante 24 a 48 horas los eventos reales recibidos, identificar los eventname más relevantes del tenant y ajustar reglas específicas según el comportamiento normal del cliente.