Auditoría de Google Workspace vs Microsoft 365: qué cambia y qué se mantiene

Por Kike Gandia · Co-Fundador y CEO, OSCP

Google Workspace y Microsoft 365 resuelven el mismo problema —correo, identidad y colaboración en la nube— pero con arquitecturas distintas. Auditar uno u otro comparte principios, pero los vectores concretos y las herramientas cambian. Esta guía explica las diferencias para que sepas qué esperar de cada auditoría.

Lo que comparten ambas auditorías

En los dos casos, la auditoría se centra en la identidad (MFA, mínimo privilegio, administradores), el control de apps de terceros (OAuth), la compartición de archivos, la persistencia vía reglas de correo y la capacidad de detección. El enfoque ofensivo —pensar como un atacante y encadenar vectores— es idéntico, igual que el uso de los CIS Benchmarks como marco.

Identidad: Entra ID vs Google Identity

Microsoft 365 se apoya en Entra ID (Azure AD), con acceso condicional, PIM y app registrations/service principals. Google Workspace usa su propia identidad con Context-Aware Access y delegación de dominio. Los conceptos son análogos, pero los puntos de fallo y las herramientas de auditoría difieren.

Vectores específicos de cada plataforma

En Microsoft 365 destacan el phishing AiTM con robo de tokens, el consentimiento ilícito de apps y el abuso de Entra ID. En Google Workspace, el consent phishing OAuth y, sobre todo, la delegación de dominio (DeleFriend), que permite impersonar a cualquier usuario desde GCP. Cada plataforma tiene su vector estrella.

Cómo elegir y qué pedir

Si tu empresa usa solo una de las dos, audita esa. Si usáis ambas (algo cada vez más habitual), conviene auditar las dos y, sobre todo, sus puntos de integración. En cualquier caso, exige un informe ejecutivo y técnico, un mapa de apps y permisos, y un checklist de hardening basado en el CIS Benchmark de la plataforma correspondiente.

Qué se revisa en cada plataforma, área por área

Los principios son los mismos, pero los sitios donde se responde cada pregunta no lo son. Esta es la correspondencia práctica entre ambas auditorías.

Área	Google Workspace	Microsoft 365
Identidad	Google Identity, unidades organizativas, Context-Aware Access	Entra ID, acceso condicional, directivas por grupo
Segundo factor	2SV, llaves de seguridad, Programa de Protección Avanzada	MFA, niveles de seguridad de autenticación, passkeys
Privilegio administrativo	Súper admins y roles delegados, sin concesión temporal nativa	Roles de Entra con PIM y activación just-in-time
Apps de terceros	Control de acceso a las APIs, lista de permitidos, apps no verificadas	Consentimiento de usuario, aplicaciones registradas y entidades de servicio
Suplantación entre servicios	Delegación de dominio sobre cuentas de servicio de Google Cloud	Permisos de aplicación de Graph con consentimiento de administrador
Correo	Reglas y filtros de Gmail, direcciones verificadas, delegación de buzón	Reglas de bandeja, reenvío externo, permisos de buzón
Archivos	Enlaces públicos, unidades compartidas, DLP de Drive	Compartición externa y anónima en SharePoint y OneDrive
Registros	Registros de auditoría de administrador y herramienta de investigación	Registro unificado de auditoría y registros de Entra
Marco de referencia	CIS Google Workspace Benchmark	CIS Microsoft 365 Benchmark

La fila que más diferencias esconde es la de privilegio administrativo: Microsoft ofrece concesión temporal nativa y Google no, así que en Workspace ese control hay que sostenerlo con proceso y alertas.

El punto ciego: los entornos mixtos

Cada vez es más frecuente encontrar las dos plataformas conviviendo en la misma empresa: una adquisición que trajo Microsoft 365 mientras una división sigue en Workspace, o un Workspace de toda la vida junto a un directorio de Microsoft que sostiene los equipos Windows. Ahí aparecen los problemas que ninguna de las dos auditorías por separado detecta.

La misma persona tiene dos identidades y normalmente solo una está endurecida. El offboarding se hace en una plataforma y se olvida en la otra, así que la cuenta muerta sigue viva en algún sitio. Una aplicación federada contra el entorno más débil termina dando acceso a datos que viven en el más fuerte. Y, sobre todo, nadie es propietario de la frontera: cada equipo asume que la cubre el otro.

Por eso una auditoría en entorno mixto empieza siempre por el mismo ejercicio poco glamuroso: mapear qué identidad es la autoritativa para cada aplicación y cada dato, y comprobar que el ciclo de vida de las cuentas se ejecuta en las dos.

FAQ

¿Es más seguro Microsoft 365 o Google Workspace?

Ninguno es intrínsecamente más seguro: ambos tienen una base sólida y los incidentes vienen casi siempre de la configuración del cliente, no de la plataforma. Lo que marca la diferencia es cómo de bien está endurecido y auditado tu tenant.

¿Podéis auditar los dos entornos a la vez?

Sí. Aplicamos la misma metodología ofensiva a Google Workspace y a Microsoft 365, y prestamos especial atención a las integraciones entre ambos y con la nube (GCP/Azure) cuando coexisten.

Si solo puedo auditar una, ¿cuál elijo?

La que actúe como proveedor de identidad para el resto de aplicaciones, aunque no sea donde está el correo principal. Es la que tiene mayor radio de impacto: comprometerla propaga el acceso a todo lo federado, mientras que comprometer la otra suele quedarse en su propio perímetro.

¿Qué necesitáis de nosotros para empezar?

Un rol de solo lectura en cada entorno, la lista de dominios, el inventario de integraciones y aplicaciones federadas, y saber quién tiene privilegios administrativos hoy. Con eso se puede hacer toda la parte de revisión sin tocar vuestra configuración ni pedir credenciales privilegiadas.

¿Interrumpe el trabajo de los usuarios?

La revisión de configuración y de registros no se nota. Cualquier prueba activa —validar una política, demostrar un camino de escalada, una simulación de phishing— se acuerda por escrito, con alcance y ventana definidos, antes de ejecutarse.

¿Y si además usamos Google Cloud o Azure?

Entran en el alcance si comparten identidades con la plataforma de productividad, y normalmente las comparten. Es justo ahí donde aparecen los caminos de escalada que ninguna de las dos auditorías encuentra por separado: del correo a la infraestructura a través de cuentas de servicio, delegaciones y permisos de aplicación.