agencia-exemplo.gal · análisis de solo lectura de Google Workspace. Esta página se lee en un minuto; el detalle técnico viene después.
Si no se toca nada: 7 de estos problemas están clasificados como críticos, y todos ellos comparten la misma consecuencia — que una sola contraseña robada baste para controlar el correo de la organización. No hace falta un ataque sofisticado; basta con que una persona pique una vez. Los 16 ajustes de configuración pendientes son, además, los que deciden lo lejos que llega quien entre.
Ordenado por hallazgos cerrados por minuto de trabajo, no por severidad. Hacer estas tres cosas, en este orden, elimina la mayor exposición con el menor esfuerzo.
| Cambio | # | Hallazgos |
|---|---|---|
| Nuevos | 2 | Cuentas que Google ha marcado como comprometidas, Política DMARC en 2 dominio(s) |
| Empeorados | 0 | — |
| Resueltos | 1 | Acceso externo a los Grupos de Google |
Configuración del tenant: lo decide un administrador en la Consola de Administración y afecta a todo el mundo por igual. No es un fallo de ninguna persona en concreto.
Comprobado contra el DNS público en cada dominio configurado. Peor resultado: Fallo.
Cómo se arregla: Publica un TXT en «_dmarc» empezando por «v=DMARC1; p=none; rua=mailto:…» para recoger informes y después endurece a p=quarantine y finalmente p=reject.
2 aplicaciones de terceros tienen permisos que dan acceso amplio al contenido de Gmail, a todo Drive, a las APIs de administración o a recursos de Cloud. Una brecha en cualquiera de esos proveedores se convierte en una brecha de tus datos. (La ventana de autorizaciones leída se indica en el alcance del hallazgo; se han visto 4 aplicaciones.)
Cómo se arregla: Revisa cada aplicación en Seguridad > Controles de API > Control de acceso de aplicaciones. Bloquea las que no reconozcas y pon el acceso de aplicaciones en «restringido» para que las nuevas autorizaciones de alto riesgo necesiten aprobación del administrador.
El SMS y la llamada de voz no son un segundo factor de verdad: se interceptan con un cambio de SIM, con un desvío en la operadora o con una página de phishing que pide el código y lo reenvía en el momento. Contra un ataque dirigido, una cuenta con 2FA por SMS está casi tan expuesta como una sin 2FA, con el agravante de que todo el mundo la considera protegida. Solo las passkeys y las llaves de seguridad resisten el phishing, porque la credencial está atada al dominio real.
Cómo se arregla: Consola de Administración > Seguridad > Autenticación > Verificación en dos pasos, apartado «Métodos»: quita el SMS y la llamada de voz. Empieza por las unidades de administradores y reparte llaves o passkeys antes de endurecerlo para todos.
Quien compromete un buzón suele añadir una regla de reenvío silenciosa para seguir leyendo el correo después de que se cambie la contraseña. Desactivar el reenvío automático cierra esa vía.
Cómo se arregla: Consola de Administración > Aplicaciones > Google Workspace > Gmail > Acceso de usuario final: desactiva el «Reenvío automático», al menos en las unidades organizativas sensibles.
Los archivos compartidos fuera de la organización son la vía más habitual por la que los datos salen de un tenant. «Permitido» significa que cualquier usuario puede compartir cualquier cosa con cualquiera.
Cómo se arregla: Consola de Administración > Aplicaciones > Google Workspace > Drive y Documentos > Configuración de uso compartido: pon el uso compartido fuera de la organización en DESACTIVADO o solo dominios permitidos, y el uso compartido por enlace por defecto en «Restringido».
Comprobado contra el DNS público en cada dominio configurado. Peor resultado: Fallo.
Cómo se arregla: Publica un registro TXT del tipo «v=spf1 include:_spf.google.com ~all» en cada dominio que envíe correo, mantén un único registro y termínalo en ~all o -all. Vigila también el límite de 10 consultas DNS del RFC 7208.
Las contraseñas cortas o reutilizables hacen que el relleno de credenciales sea barato. Apunta a 12+ caracteres, sin reutilización y sin rotación periódica forzada.
Cómo se arregla: Consola de Administración > Seguridad > Autenticación > Gestión de contraseñas: mínimo 12 caracteres, prohibir la reutilización y quitar la caducidad forzada.
Una lista de permitidas significa que los usuarios solo pueden instalar aplicaciones de Marketplace que tú hayas validado, en lugar de dar acceso a sus datos a cualquier cosa que encuentren.
Cómo se arregla: Consola de Administración > Aplicaciones > Aplicaciones de Google Workspace Marketplace > Configuración: permite solo las aplicaciones de la lista y revisa lo que ya está instalado.
La delegación en todo el dominio permite que una cuenta de servicio suplante a CUALQUIER usuario para los permisos concedidos: es la concesión más poderosa de Workspace. Se han observado 1 evento(s) de concesión en la ventana de auditoría.
Cómo se arregla: Revisa Seguridad > Controles de API > Delegación en todo el dominio. Elimina los clientes que no reconozcas y reduce los permisos al mínimo.
Se han registrado 2 cambio(s) en 2 categoría(s) de riesgo. El registro de auditoría recoge cambios, no el estado actual por defecto, así que revisa cada uno y confirma que fue intencionado.
Cómo se arregla: Para cada cambio, confirma quién lo hizo y por qué. Añade reglas de alerta para estos tipos de evento en el Centro de alertas.
1 aplicaciones han sido autorizadas por 10 o más usuarios. Que una aplicación sin validar se use de forma masiva multiplica el alcance del daño si se ve comprometida.
Cómo se arregla: Valida las aplicaciones de uso extendido (proveedor, tratamiento de datos, necesidad real) y marca la decisión como de confianza o bloqueada en el Control de acceso de aplicaciones.
Los calendarios secundarios —el de la sala de reuniones, el del equipo, el de guardias— salen por defecto con TODOS los detalles visibles desde fuera de la organización, no solo el libre/ocupado. Y son justo los que nadie revisa, porque nadie los siente suyos. El título de una reunión suele ser el secreto entero: «Due diligence Acme», «Rescisión de Juan», «Consejo extraordinario». Quien pueda leerlos desde fuera sabe qué va a hacer la empresa antes de que lo sepa la plantilla.
Cómo se arregla: Consola de Administración > Aplicaciones > Google Workspace > Calendar > Opciones de uso compartido: para los calendarios secundarios, deja «Solo información de libre/ocupado» como máximo permitido hacia fuera.
Comprobado contra el DNS público en cada dominio configurado. Peor resultado: Aviso.
Cómo se arregla: Genera una clave DKIM en la Consola de Administración (Aplicaciones > Google Workspace > Gmail > Autenticar el correo electrónico), publica el registro DNS y pulsa «Iniciar autenticación». Solo se comprueba el selector «google», que es el que usa Workspace: si firmas con un selector propio, escríbeme a diego@diegofarina.com y lo verificamos a mano.
Comprobado contra el DNS público en cada dominio configurado. Peor resultado: Aviso.
Cómo se arregla: Publica una política MTA-STS: un registro TXT en «_mta-sts» más un fichero de política en https://mta-sts.<dominio>/.well-known/mta-sts.txt con tus servidores MX. Empieza en modo «testing» y pasa después a «enforce».
Comprobado contra el DNS público en cada dominio configurado. Peor resultado: Aviso.
Cómo se arregla: Activa DNSSEC en tu proveedor de DNS (en Cloudflare es un solo interruptor) y añade el registro DS en tu registrador. Sin DNSSEC, tus propios registros SPF, DKIM y DMARC se pueden falsificar.
Comprobado contra el DNS público en cada dominio configurado. Peor resultado: Aviso.
Cómo se arregla: Publica un registro TXT en «_smtp._tls»: «v=TLSRPTv1; rua=mailto:tls@<dominio>» para enterarte cuando falle la entrega con TLS hacia tu dominio.
Mientras la verificación en dos pasos no sea obligatoria, inscribirse es voluntario: quien no lo haga entra solo con contraseña, y quien ya la tenga puede quitársela cuando quiera. La obligatoriedad se configura por unidad organizativa, así que lo que importa no es si está activada, sino a quién alcanza.
Cómo se arregla: Consola de Administración > Seguridad > Autenticación > Verificación en dos pasos > Obligatoriedad: actívala para toda la organización, no solo para una unidad.
IMAP permite entrar al buzón con usuario y contraseña desde cualquier cliente de correo, sin pasar por el desafío de la verificación en dos pasos. Es la puerta lateral clásica: quien tenga la contraseña lee todo el correo sin tocar la pantalla de acceso de Google y sin dejar el rastro de un inicio de sesión web.
Cómo se arregla: Consola de Administración > Aplicaciones > Google Workspace > Gmail > Acceso de usuario final: desactiva IMAP o limítalo a los clientes que hayas aprobado.
POP tiene el mismo problema que IMAP y uno peor: descarga los mensajes a la máquina del cliente, así que una vez copiados quedan fuera de tu control, de tu retención y de cualquier borrado que hagas después.
Cómo se arregla: Consola de Administración > Aplicaciones > Google Workspace > Gmail > Acceso de usuario final: desactiva POP. Casi nunca hace falta.
No se ha podido leer ninguna regla de alerta, así que no se puede decir si alguien está vigilando.
Cómo se arregla: Consola de Administración > Reglas > Reglas definidas por el sistema. Activa al menos las de cambios de configuración, cuentas comprometidas, acceso sospechoso y dispositivos, y ponles un destinatario real: una lista de correo que alguien lea.
Una cookie de sesión robada sigue siendo válida hasta que la sesión caduca. Las sesiones con límite acotan cuánto tiempo sirve un token robado, sobre todo en administradores.
Cómo se arregla: Consola de Administración > Seguridad > Control de acceso y datos > Control de sesión de Google: establece una duración máxima de sesión web (12-24 h en unidades privilegiadas).
Las aplicaciones menos seguras acceden con usuario y contraseña, sin OAuth y sin el desafío de la verificación en dos pasos. Este ajuste importa MÁS, no menos, cuando ya tienes la 2FA obligatoria: es precisamente la vía que la deja sin efecto. Y como la conexión no es interactiva, tampoco genera el aviso de inicio de sesión sospechoso.
Cómo mantenerlo: Consola de Administración > Seguridad > Acceso y control de datos > Aplicaciones menos seguras: desactívalo. Lo que lo necesite debe migrar a OAuth.
El periodo de gracia es el tiempo que una cuenta nueva puede seguir entrando solo con contraseña. Durante esos días la obligatoriedad está anunciada pero no aplicada: es exactamente la ventana que busca quien roba credenciales, porque la cuenta ya existe y ya tiene permisos.
Cómo mantenerlo: Consola de Administración > Seguridad > Autenticación > Verificación en dos pasos: baja el periodo de gracia a una semana o menos.
Es el valor que lleva cada archivo que alguien crea. Si por defecto es «cualquiera con el enlace», la fuga no necesita un error humano: ocurre sola cada vez que se comparte un documento sin mirar.
Cómo mantenerlo: Consola de Administración > Aplicaciones > Google Workspace > Drive y Documentos > Configuración de uso compartido > Acceso general por defecto: ponlo en «Restringido».
Lo que un tercero puede ver del calendario de cada persona. Con libre/ocupado basta para coordinar una reunión; con los detalles se filtra con quién se reúne cada uno, cuándo y sobre qué.
Cómo mantenerlo: Consola de Administración > Aplicaciones > Google Workspace > Calendar > Opciones de uso compartido: limita el máximo externo a «Solo libre/ocupado».
Los grupos accesibles públicamente pueden exponer conversaciones internas y permitir que gente de fuera publique en listas de correo internas.
Cómo mantenerlo: Consola de Administración > Aplicaciones > Google Workspace > Grupos para empresas > Configuración de uso compartido: pon el acceso desde fuera de la organización en Privado.
El registro de auditoría de administración es accesible. Abajo se listan los cambios recientes en la Consola de Administración: revisa cualquiera que no reconozcas.
Cómo mantenerlo: Configura reglas de alerta para los eventos de administración sensibles (Seguridad > Centro de alertas, Informes > Auditoría e investigación).
Cosas que son ciertas de personas concretas: sin segundo factor, nunca han iniciado sesión, privilegios de administrador, recuperación mal puesta, acceso desde un país nuevo.
1 cuenta(s) cumplen a la vez: es superadministrador + no tiene verificación en dos pasos + tiene la recuperación de la cuenta mal puesta. Por qué esto es peor que los hallazgos por separado: los dos hechos por separado ya son graves; juntos cierran el círculo. Sin segundo factor, una contraseña robada por phishing entra directamente. Y con la recuperación mal puesta, esa entrada se vuelve permanente: si el atacante llega primero al buzón personal de recuperación, se queda con la cuenta y tú no tienes vía de vuelta, porque sin teléfono de recuperación la única salida es el soporte de Google, que tarda días. Es la diferencia entre un incidente y perder el tenant.
Cómo se arregla: Trata estas cuentas como una emergencia: inscríbelas hoy en la verificación en dos pasos con llave de seguridad, pon un teléfono de recuperación corporativo y quita cualquier correo de recuperación que esté en un dominio personal. Asegúrate de que queda al menos otro superadministrador con 2FA para no quedarte fuera.
1 cuenta(s) cumplen a la vez: es superadministrador + no tiene verificación en dos pasos + nunca ha iniciado sesión. Por qué esto es peor que los hallazgos por separado: cada uno de los tres hechos es manejable aparte. Juntos son una puerta trasera permanente: la cuenta tiene control total del tenant, basta con robar su contraseña para usarla y, como nunca ha iniciado sesión, no existe una línea base de actividad normal con la que comparar, así que nadie notaría que otra persona empieza a usarla. Suelen ser restos de la instalación inicial o de migraciones, sin ningún responsable que las vigile.
Cómo se arregla: Suspende estas cuentas hoy. Si alguna es realmente necesaria, inscríbela en la verificación en dos pasos con una llave de seguridad antes de reactivarla y asígnale un responsable con nombre y apellidos.
1 cuenta(s) cumplen a la vez: es superadministrador + no tiene verificación en dos pasos. Por qué esto es peor que los hallazgos por separado: un superadministrador puede leer, cambiar o exportar cualquier cosa del tenant, y puede dejar fuera al resto de administradores. Sin segundo factor, una sola contraseña robada por phishing equivale al compromiso total del dominio: no hay segunda línea de defensa.
Cómo se arregla: Inscribe ya a estos administradores en la verificación en dos pasos, preferiblemente con llave de seguridad física o passkey, y después actívala de forma obligatoria para la unidad organizativa de administradores.
Los administradores delegados pueden gestionar usuarios, restablecer contraseñas o cambiar ajustes de servicios: sin segundo factor, una sola contraseña robada por phishing basta para usar esos privilegios. Los superadministradores se evalúan aparte, en sus propios hallazgos.
Cómo se arregla: Inscribe ya a estos administradores en 2FA (Seguridad > Verificación en dos pasos) y después hazla obligatoria para su unidad organizativa. Para administradores, usa preferiblemente llaves de seguridad o passkeys.
La propia detección de Google ha desactivado o señalado estas cuentas por contraseña filtrada, secuestro o ataque patrocinado por un estado. Trátalas como comprometidas hasta demostrar lo contrario.
Cómo se arregla: Restablece la contraseña, revoca las sesiones y los tokens de aplicaciones, y vuelve a verificar la 2FA de cada cuenta. Consulta el Centro de alertas para el contexto completo.
1 de 2 superadministradores tienen la recuperación mal puesta. Sin teléfono de recuperación, perder el segundo factor o sufrir un secuestro deja la cuenta fuera de alcance: no hay vía de vuelta que no pase por el soporte de Google, y eso son días. Y un correo de recuperación en un dominio personal es peor todavía: mueve la seguridad de todo el tenant a un buzón que tu organización no controla, no puede auditar y no puede revocar. Quien tenga ese buzón puede restablecer al superadministrador, y sigue pudiendo el día después de que la persona deje la empresa.
Cómo se arregla: Abre Directorio > Usuarios, entra en cada superadministrador y revisa «Información de seguridad»: todos deben tener un teléfono de recuperación corporativo y ningún correo de recuperación en un dominio personal; sustituye los que lo estén por una dirección del propio dominio. Si la cuenta es de emergencia y no tiene a nadie detrás, guarda sus códigos de respaldo en el gestor de secretos en lugar de apuntar un buzón particular.
1 cuenta(s) cumplen a la vez: es superadministrador + no ha iniciado sesión recientemente. Por qué esto es peor que los hallazgos por separado: una cuenta de administrador sin uso conserva el privilegio máximo mientras nadie la vigila. Su uso indebido no llamaría la atención, porque no hay actividad reciente con la que contrastarlo.
Cómo se arregla: Confirma si la cuenta sigue siendo necesaria. Si no lo es, quítale el rol de administrador y suspéndela; si lo es, mantenla con 2FA y revísala cada trimestre.
1 cuenta(s) cumplen a la vez: no tiene verificación en dos pasos + nunca ha iniciado sesión. Por qué esto es peor que los hallazgos por separado: estas cuentas siguen con la contraseña inicial que les puso informática, no tienen segundo factor y no hay nadie que entre a diario y note algo raro. Son la vía de entrada más silenciosa a un tenant.
Cómo se arregla: Suspéndelas hasta que alguien necesite la cuenta de verdad. Cuando se entregue, exige la inscripción en 2FA en el primer inicio de sesión.
1 cuenta(s) cumplen a la vez: no tiene verificación en dos pasos + parece una cuenta compartida o funcional. Por qué esto es peor que los hallazgos por separado: los buzones compartidos (admin@, info@, integraciones@…) suelen tener contraseñas conocidas por varias personas, guardadas en scripts o documentos, y que casi nunca se rotan. Sin segundo factor, cualquier filtración de esa contraseña es suficiente; y como la cuenta es de todos, nadie asume la tarea de vigilarla.
Cómo se arregla: Inscribe la cuenta en la verificación en dos pasos, o sustitúyela por un grupo o por acceso delegado para que no exista ninguna contraseña compartida.
4 de 11 usuarios activos no se han inscrito en la verificación en dos pasos. Las cuentas que solo dependen de una contraseña son la vía de entrada más habitual para el robo de cuentas.
Cómo se arregla: Lanza una campaña de inscripción y después activa la 2FA obligatoria para toda la organización con un periodo de gracia (Seguridad > Verificación en dos pasos > Obligatoriedad).
1 superadministrador(es) han entrado en los últimos 14 días desde un país en el que no constaba ningún acceso suyo antes, en 74 días de registro. No es que el país sea peligroso: lo que llama la atención es el cambio. Una cuenta con meses de historial en un sitio que de pronto entra desde otro es el indicio más barato que existe de que alguien más la está usando, y en un superadministrador eso es el tenant entero. Antes de alarmarte: un viaje, una VPN nueva o un móvil en itinerancia dan exactamente la misma señal. Se confirma con una llamada, no con el informe.
Cómo se arregla: Pregunta a esa persona si el acceso es suyo. Si no lo reconoce: cierra sus sesiones (Directorio > Usuarios > la cuenta > Seguridad > Cerrar sesión), restablece la contraseña, revisa las aplicaciones con acceso a su cuenta y mira el registro de administración por si tocó algún ajuste.
1 cuentas activas no han iniciado sesión en más de 90 días. Las cuentas dormidas son un objetivo preferente: nadie se da cuenta cuando se ven comprometidas, y además suelen seguir consumiendo licencia.
Cómo se arregla: Confírmalo con la persona o su responsable y después suspende la cuenta. Transfiere los datos y libera la licencia antes de eliminarla.
Google ha marcado como sospechosos los inicios de sesión de 1 cuenta(s) (ubicación, dispositivo o patrón inusual).
Cómo se arregla: Confirma la actividad con cada persona. Si no la reconoce, restablece las credenciales y exige 2FA. Valora usar el Acceso Contextual para limitar desde dónde se puede iniciar sesión.
Mientras la 2FA no sea obligatoria, inscribirse es voluntario. 8 usuarios activos no están cubiertos por una política de obligatoriedad, así que podrían quitarse el segundo factor en cualquier momento.
Cómo se arregla: Activa la obligatoriedad de la 2FA en todas las unidades organizativas (Seguridad > Verificación en dos pasos > Obligatoriedad > Activada).
1 cuenta(s) acumulan 10 o más inicios de sesión fallidos en la ventana de auditoría, lo que puede indicar que alguien está probando contraseñas.
Cómo se arregla: Exige la 2FA (así acertar la contraseña deja de ser suficiente) y valora requisitos de contraseña más estrictos o el Acceso Contextual.
2 cuentas activas (creadas hace más de 14 días) nunca han iniciado sesión. Normalmente conservan la contraseña inicial que les puso informática y no tienen 2FA: objetivos fáciles que nadie vigila.
Cómo se arregla: Suspéndelas hasta que la persona necesite la cuenta de verdad.
Quedan 1 cuentas suspendidas en el directorio. Se pueden reactivar sin hacer ruido y puede que sigan ocupando licencia, perteneciendo a grupos y compartiendo datos.
Cómo se arregla: Para quien ya no está en la empresa: transfiere los datos y elimina la cuenta. La suspensión debe ser solo un paso temporal de la salida.
Ninguna cuenta suspendida tiene autorizaciones de terceros pendientes de revocar en el registro.
Cómo mantenerlo: Seguridad > Controles de API > Gestionar el acceso de aplicaciones de terceros: busca cada aplicación y retira el acceso de esas cuentas. Añádelo a tu proceso de baja, junto a la suspensión y al cierre de sesiones: son tres acciones distintas y solo una la hace el botón de suspender.
0 cuenta(s) están en esta situación. Es la combinación que no debería poder existir, y por eso merece una mirada aparte: la obligatoriedad de la verificación en dos pasos les alcanza, el periodo de gracia ya ha pasado, la persona ha iniciado sesión — y sigue sin segundo factor. Un informe que enseña «obligatoriedad: correcta» junto a «N usuarios sin 2FA» deja al lector pensando que una de las dos cosas está mal medida. No lo está: las dos son ciertas, y lo que hay entre ellas es una excepción real. Las causas habituales son una unidad organizativa excluida, una exención por usuario, o un acceso que no pasa por la pantalla de Google (IMAP, POP o una contraseña de aplicación), que es justamente el camino que la obligatoriedad no cubre.
Cómo mantenerlo: Mira cada cuenta en Directorio > Usuarios > Seguridad: comprueba si tiene una exención de la verificación en dos pasos y si su unidad organizativa está dentro del ámbito de la obligatoriedad. Revisa también si entra por IMAP, POP o con una contraseña de aplicación, porque esas vías no pasan por el segundo factor. Si es una cuenta de servicio, conviértela en cuenta de servicio de verdad en lugar de dejarla como usuario con contraseña.
2 cuentas de superadministrador: dentro del rango recomendado (2-3).
Cómo mantenerlo: Mantén entre 2 y 4 superadministradores. Pasa la administración del día a día a roles delegados con el mínimo privilegio necesario (Cuenta > Roles de administrador).
No consta ninguna generación de códigos de respaldo en el registro de administración. Es la respuesta que se quiere: los códigos son un segundo factor de papel que no caduca y que sí se puede phishear.
Cómo mantenerlo: Directorio > Usuarios > la cuenta > Seguridad > Códigos de verificación de respaldo: revoca los que sigan vivos en las cuentas con privilegios. Si hacen falta como vía de emergencia, genéralos en el momento y revócalos después.
2 de 2 superadministradores tienen accesos en el registro, sobre una ventana de 74 día(s). Es un inventario, no un fallo: sirve para que reconozcas de un vistazo desde dónde se entra normalmente a las cuentas que controlan todo el tenant. El país sale de una base de datos local; ninguna dirección IP sale de este servidor.
Cómo mantenerlo: Repasa la lista con quien corresponda: lo que importa no es el país en sí, sino que cuadre con dónde trabaja de verdad esa persona.
1 cuentas de administrador delegado. Es informativo: revisa que cada rol siga siendo necesario y esté ajustado al mínimo privilegio.
Cómo mantenerlo: Revisa la asignación de roles en Cuenta > Roles de administrador.
Ordenadas por severidad combinada. 7 de ellas acumulan más de un problema a la vez: son las cuentas que un atacante solo tiene que acertar una vez.
| Peor | Cuenta | Problemas | Aparece en |
|---|---|---|---|
| crítico | uxia.ferreiro@agencia-exemplo.gal | 10 | Superadministrador sin 2FA y con la recuperación mal puesta · Superadministrador sin 2FA que nunca ha iniciado sesión · Superadministrador sin verificación en dos pasos · Superadministrador sin actividad en 90+ días · Cuenta sin 2FA que nunca ha iniciado sesión · Usuarios sin la verificación en dos pasos configurada · Cuentas fuera del alcance de la obligatoriedad de 2FA · Accesos de superadministrador desde un país nuevo · Recuperación de las cuentas de superadministrador · Cuentas activas que nunca han iniciado sesión |
| crítico | anton.carballo@agencia-exemplo.gal | 3 | Administrador delegado sin verificación en dos pasos · Usuarios sin la verificación en dos pasos configurada · Cuentas fuera del alcance de la obligatoriedad de 2FA |
| crítico | nerea.figueroa@agencia-exemplo.gal | 2 | Cuentas fuera del alcance de la obligatoriedad de 2FA · Cuentas que Google ha marcado como comprometidas |
| alto | integraciones@agencia-exemplo.gal | 4 | Cuenta compartida o funcional sin 2FA · Usuarios sin la verificación en dos pasos configurada · Cuentas fuera del alcance de la obligatoriedad de 2FA · Posible adivinación de contraseñas (ráfagas de intentos fallidos) |
| alto | iago.mendez@agencia-exemplo.gal | 3 | Usuarios sin la verificación en dos pasos configurada · Cuentas fuera del alcance de la obligatoriedad de 2FA · Actividad de inicio de sesión sospechosa |
| medio | noa.lourido@agencia-exemplo.gal | 2 | Cuentas fuera del alcance de la obligatoriedad de 2FA · Cuentas activas sin iniciar sesión en 90+ días |
| medio | xurxo.vilar@agencia-exemplo.gal | 2 | Cuentas fuera del alcance de la obligatoriedad de 2FA · Cuentas activas que nunca han iniciado sesión |
| medio | roi.pardo@agencia-exemplo.gal | 1 | Cuentas fuera del alcance de la obligatoriedad de 2FA |
| bajo | becaria.2025@agencia-exemplo.gal | 1 | Cuentas suspendidas que siguen existiendo |
| Comprobación | Estado | Detalle |
|---|---|---|
| SPF | FALLO | El SPF supera el límite de 10 consultas (12): los receptores devuelven permerror, así que el SPF no se evalúa en absoluto. v=spf1 include:_spf.google.com include:sendgrid.net include:spf.mailjet.com include:_spf.crm-exemplo.com ~all mecanismo final: ~allConsultas DNS: 12 del límite de 10 del RFC 7208 — por encima del límite: los receptores devuelven permerror y dejan de evaluar el SPF |
| DKIM | AVISO | Clave DKIM encontrada en el selector «google», pero es de solo 1024 bits; el mínimo actual es 2048. selector google: v=DKIM1; k=rsa; p=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA tamaño de clave: 1024 bits — débil, rota a 2048 o más |
| DMARC | FALLO | La política DMARC es p=none: solo monitoriza, el correo suplantado se sigue entregando. v=DMARC1; p=none; rua=mailto:informes@axencia-marketing-exemplo.com; adkim=r; aspf=r política: p=none · alineación: DKIM relajada, SPF relajadalos informes van a: solo a un tercero: nunca ves tu propia telemetría |
| DNSSEC | CORRECTO | DNSSEC está activado: las respuestas DNS de este dominio van firmadas. |
| Comprobación | Estado | Detalle |
|---|---|---|
| SPF | FALLO | No se ha encontrado ningún registro SPF. Cualquiera puede suplantar el correo de este dominio.mecanismo final: ?all |
| DKIM | NO VERIFICADO | DKIM no verificado: no se ha encontrado ninguna clave en los 29 selectores probados (google, default, mail, dkim, smtp, dkim1, …). Un dominio que firme con un selector propio no lo encuentra esta comprobación, así que esto no significa que no firmes; se verifica a mano escribiendo a diego@diegofarina.com. No verificado. Se ha probado google, default, mail, dkim, smtp, dkim1, que es el selector que usa Workspace. Un dominio que firme con un selector propio no lo encuentra esta comprobación; no significa que no firmes. Escríbeme y lo verificamos a mano. |
| DMARC | FALLO | No hay registro DMARC. El correo suplantado de este dominio no se controla.política: p=sin definir · alineación: DKIM relajada, SPF relajada los informes van a: desconocido |
| DNSSEC | AVISO | DNSSEC no está activado. Un atacante a nivel de resolutor puede falsificar las respuestas DNS, incluidos tus registros SPF, DKIM y DMARC. |
Vigía no ha podido leer estos ajustes automáticamente, así que verifícalos a mano. Desaparecen de esta lista en cuanto una comprobación automática pueda confirmarlos.
El Policy API no expone las reglas de enrutamiento, así que esto no se puede comprobar automáticamente ni pidiendo más permisos. Vale el minuto que cuesta: una regla de enrutamiento maliciosa es exfiltración que sobrevive a un cambio de contraseña, a un cierre de sesiones y a activar la verificación en dos pasos. Sigue copiando el correo hasta que alguien mire esta pantalla, y nadie la mira nunca.
Vigía sí pide y tiene el permiso para leer este ajuste, y el identificador es el que documenta Google (gmail.imap_access y gmail.pop_access). Lo que pasa es otra cosa: tu organización nunca ha fijado una política explícita para ellos, y Google —a diferencia de casi todos los demás ajustes— no publica cuál es el valor por defecto ni lo devuelve por API. No hay nada que leer, así que decir «permitido» o «bloqueado» sería inventárselo. Se mira a mano en un minuto.
La política de reenvío de toda la organización se lee automáticamente en cuanto se concede el permiso de políticas. Las reglas de reenvío de cada usuario necesitarían un permiso restringido de Gmail, así que esas hay que auditarlas con la Búsqueda en el registro de correo.
Pesos por severidad: critical 10, high 6, medium 3, low 1. Crédito: correcto 100%, aviso 50%, fallo 0%. La puntuación se reparte en dos bloques que se leen distinto:
Los hallazgos informativos, manuales o no verificados quedan excluidos por completo: la incertidumbre nunca suma ni resta.
| Elemento | Severidad | Estado | Peso | Obtenido | De |
|---|---|---|---|---|---|
| anton.carballo@agencia-exemplo.gal | crítico | fallo | 10 | 0.0 | 2sv-delegated-admins (+2 más) |
| becaria.2025@agencia-exemplo.gal | bajo | aviso | 1 | 0.5 | suspended-accounts |
| iago.mendez@agencia-exemplo.gal | alto | fallo | 6 | 0.0 | 2sv-users (+2 más) |
| integraciones@agencia-exemplo.gal | alto | fallo | 6 | 0.0 | composite-service-account-no-2sv (+3 más) |
| nerea.figueroa@agencia-exemplo.gal | crítico | fallo | 10 | 0.0 | login-compromised (+1 más) |
| noa.lourido@agencia-exemplo.gal | medio | fallo | 3 | 0.0 | dormant-accounts (+1 más) |
| roi.pardo@agencia-exemplo.gal | medio | aviso | 3 | 1.5 | 2sv-enforcement |
| uxia.ferreiro@agencia-exemplo.gal | crítico | fallo | 10 | 0.0 | composite-superadmin-no-2sv-no-recovery (+9 más) |
| xurxo.vilar@agencia-exemplo.gal | medio | aviso | 3 | 1.5 | 2sv-enforcement (+1 más) |
| La 2FA es obligatoria para esta cuenta y aun así entra sin ella | alto | correcto | 6 | 6.0 | composite-enforced-but-not-enrolled |
| Número de cuentas de superadministrador | alto | correcto | 6 | 6.0 | super-admin-count |
| Códigos de respaldo de la verificación en dos pasos | alto | correcto | 6 | 6.0 | 2sv-backup-codes |
| Aplicaciones de terceros con permisos de alto riesgo | alto | fallo | 6 | 0.0 | oauth-high-risk |
| Aplicaciones autorizadas por muchos usuarios | medio | aviso | 3 | 1.5 | oauth-widely-granted |
| Concesiones de delegación en todo el dominio | alto | aviso | 6 | 3.0 | oauth-dwd |
| Aplicaciones conectadas por cuentas suspendidas | crítico | correcto | 10 | 10.0 | suspended-with-tokens |
| Métodos de segundo factor permitidos | alto | fallo | 6 | 0.0 | policy-2sv-methods |
| Periodo de gracia de la verificación en dos pasos | medio | correcto | 3 | 3.0 | policy-2sv-grace |
| Aplicaciones menos seguras (acceso solo con contraseña) | alto | correcto | 6 | 6.0 | policy-less-secure-apps |
| Reenvío automático de Gmail | alto | fallo | 6 | 0.0 | policy-gmail-forwarding |
| Uso compartido externo de Drive | alto | fallo | 6 | 0.0 | policy-drive-sharing |
| Acceso por defecto de los archivos nuevos de Drive | medio | correcto | 3 | 3.0 | policy-drive-link-default |
| Política de contraseñas | medio | fallo | 3 | 0.0 | policy-password |
| Lista de aplicaciones de Marketplace permitidas | medio | fallo | 3 | 0.0 | policy-marketplace |
| Calendarios secundarios visibles desde fuera | medio | aviso | 3 | 1.5 | policy-calendar-secondary |
| Calendarios personales visibles desde fuera | medio | correcto | 3 | 3.0 | policy-calendar-primary |
| Acceso externo a los Grupos de Google | medio | correcto | 3 | 3.0 | policy-groups-sharing |
| Cambios de administración de riesgo en la ventana de auditoría | alto | aviso | 6 | 3.0 | audit-risky-changes |
| Registros SPF en 2 dominio(s) | alto | fallo | 6 | 0.0 | email-spf |
| Firma DKIM en 2 dominio(s) | medio | aviso | 3 | 1.5 | email-dkim |
| Política DMARC en 2 dominio(s) | crítico | fallo | 10 | 0.0 | email-dmarc |
| MTA-STS (TLS obligatorio en el correo entrante) en 2 dominio(s) | medio | aviso | 3 | 1.5 | mail-mta-sts |
| TLS-RPT (informes de fallos de TLS) en 2 dominio(s) | bajo | aviso | 1 | 0.5 | mail-tls-rpt |
| DNSSEC (DNS firmado) en 2 dominio(s) | medio | aviso | 3 | 1.5 | dns-dnssec |
| Total | 172 | 63.5 | puntuación 37/100 | ||
| admin-login-countries | informativo | correcto | solo informativo | ||
| delegated-admins | informativo | correcto | solo informativo | ||
| policy-2sv-enforcement | crítico | no verificado | no se ha podido determinar | ||
| policy-imap | alto | no verificado | no se ha podido determinar | ||
| policy-pop | alto | no verificado | no se ha podido determinar | ||
| policy-session | bajo | no verificado | no se ha podido determinar | ||
| alert-rules | medio | no verificado | no se ha podido determinar | ||
| audit-admin-log | informativo | correcto | solo informativo | ||
Este informe dice qué está mal y dónde se toca. Si prefieres que lo haga alguien que ya ha hecho esto antes, lo hago yo contigo:
Y si quieres, repetimos la revisión cada cierto tiempo: es lo que impide volver al punto de partida en seis meses.
Escríbeme y te contesto yo. El precio depende de lo que haya que hacer, así que lo hablamos por correo con el informe delante.