Cómo aplicar la MFA en toda su organización de Google Workspace

La autenticación multifactor es el control de seguridad de mayor retorno que la mayoría de las organizaciones pueden implementar, y en Google Workspace se denomina Verificación en 2 pasos (2SV). El problema está en la palabra *aplicar*. Habilitar la MFA es fácil y en gran medida inútil: las cuentas con más probabilidades de ser atacadas son las que menos probablemente se inscriban por voluntad propia. La protección real proviene de la aplicación obligatoria: exigirla en toda la organización, con los factores adecuados y una implementación que no deje a nadie bloqueado. Este artículo es ese plan de implementación.

Por qué "disponible" no es lo mismo que "obligatorio"

Si la 2SV es opcional, la adopción sigue el camino de menor resistencia: el personal técnico y con conciencia de seguridad se inscribe; los ejecutivos ocupados y las cuentas relacionadas con servicios no lo hacen. Los atacantes lo saben. Los ataques de phishing de credenciales y reutilización de contraseñas apuntan exactamente a las cuentas que se saltaron la inscripción. Un control opcional protege a quienes menos lo necesitaban.

La aplicación obligatoria invierte esa situación. Cuando la 2SV es obligatoria, una contraseña robada ya no basta para tomar el control de una cuenta, lo cual neutraliza de un solo movimiento la vía más común de compromiso de cuentas.

Elija sus factores de forma deliberada

No todos los segundos factores son iguales. De más fuerte a más débil:

• Passkeys y llaves de seguridad de hardware (FIDO2). Resistentes al phishing: se vinculan criptográficamente al sitio legítimo, por lo que una página de phishing no puede retransmitirlos. El estándar de referencia, y muy recomendado para administradores y otras cuentas de alto valor.
• Google prompt / aplicación autenticadora (TOTP). Una mejora sólida respecto a las contraseñas, pero un kit de phishing en tiempo real y determinado puede retransmitir un código de un solo uso. Adecuado para la población general.
• Códigos SMS. Mejor que nada, pero vulnerable al SIM-swapping y a la interceptación. Aceptable como respaldo, no como factor principal.

Una política sólida: exigir factores fuertes y resistentes al phishing para administradores y grupos sensibles, permitir códigos basados en aplicaciones para el resto, y minimizar el uso de SMS.

Una implementación por etapas que evita bloqueos

El temor que frena la aplicación de la MFA es dejar a las personas bloqueadas fuera de sus cuentas. Escalone la implementación para eliminar ese riesgo:

1. Comunique primero. Informe a la organización qué va a cambiar, por qué y para cuándo. Proporcione instrucciones de inscripción. Una aplicación sorpresiva genera tickets de soporte técnico y descontento.
2. Abra una ventana de inscripción. Active la 2SV como opción disponible y fije una fecha límite. Haga seguimiento del progreso de inscripción para saber quién todavía no se ha inscrito.
3. Dé un empujón a los rezagados. A medida que se acerca la fecha límite, recuerde a las cuentas que aún no se han inscrito. Aquí es donde se inscribe la mayor parte del grupo restante.
4. Aplíquela con un período de gracia para usuarios nuevos. Active la aplicación obligatoria, pero configure un período de gracia para las cuentas recién creadas, de modo que la incorporación no quede bloqueada en el primer inicio de sesión.
5. Distribuya opciones de respaldo. Asegúrese de que los usuarios tengan códigos de respaldo o un segundo factor registrado, de modo que un teléfono perdido sea un inconveniente menor y no un bloqueo total.
6. Gestione las excepciones de forma acotada. Algunas cuentas de servicio o compartidas pueden efectivamente tener dificultades con una 2SV interactiva. Traslade esas cuentas a un modelo de autenticación más apropiado (claves de cuenta de servicio, tratamiento dedicado) en lugar de introducir exenciones amplias en su política de usuarios.

La consola de administración permite aplicar la obligatoriedad a nivel de unidad organizativa, por lo que puede hacer una prueba piloto con TI, luego con un departamento y después con toda la organización, reduciendo aún más el riesgo de la implementación.

Errores comunes

• Eximir a los ejecutivos "por comodidad". Las cuentas de mayor valor son las peores candidatas para una excepción. Si acaso, deberían estar sujetas a los factores *más fuertes*.
• Permitir solo SMS. Cumple con el requisito formal, pero deja abierta la puerta al SIM-swapping. Impulse el uso de factores basados en aplicaciones o en hardware.
• Olvidar las cuentas de servicio y compartidas. Con frecuencia tienen acceso significativo y evitan la autenticación interactiva. Gestiónelas de forma deliberada: véase cómo detectar agentes de IA y cuentas de servicio de riesgo.
• Tratarlo como algo que se hace una sola vez. Las cuentas nuevas, las nuevas excepciones y la deriva de las políticas hacen que la aplicación obligatoria requiera verificación periódica, no un simple interruptor que se activa una vez.

Verifique la aplicación obligatoria — no la dé por hecha

Activar la política y confirmar que *realmente se aplica a todas las cuentas* son dos cosas distintas. Las cuentas creadas antes de la política, las que están en una unidad organizativa exenta o las que quedan atrapadas en un período de gracia pueden quedar silenciosamente fuera del alcance de la aplicación obligatoria. Parte de una postura saludable de seguridad en Google Workspace —y un control que los auditores de SOC 2 examinan específicamente bajo CC6.1— consiste en comprobar que la aplicación de la MFA se mantiene en toda la organización, y no solo que el interruptor está activado.

Este es exactamente el tipo de configuración que se va desviando con el tiempo, y el tipo que los auditores le piden documentar como evidencia. Una herramienta de evaluación de postura que revise la configuración a nivel de toda la organización señalará dónde no se está aplicando la 2SV (cuando se dispone de la visibilidad administrativa correspondiente), de modo que "aplicamos la MFA" sea un hecho verificado y no una suposición.

Cómo manejar los casos difíciles

La mayoría de las cuentas se inscriben sin contratiempos. Algunas categorías requieren un tratamiento deliberado, y la forma en que se las gestione a menudo determina si la aplicación obligatoria realmente se mantiene:

• Ejecutivos y personas VIP. Son los objetivos principales del phishing y quienes con más probabilidad solicitarán una excepción. Exíjales los factores más fuertes en lugar de eximirlos. Una cuenta ejecutiva comprometida es uno de los peores resultados posibles; la comodidad no vale ese riesgo.
• Buzones compartidos y cuentas de rol. La 2SV interactiva encaja con una persona, no con un buzón que usan cinco personas. Vuelva a modelar estas cuentas como acceso delegado hacia cuentas protegidas individualmente, de modo que la protección siga a personas reales.
• Cuentas de servicio y automatización. Estas no deberían realizar inicios de sesión interactivos en absoluto. Autentíquelas con credenciales de cuenta de servicio gestionadas por separado, y gobiérnelas como las identidades no humanas que son.
• Personal de campo y trabajadores de primera línea. Las personas sin un smartphone o con conectividad limitada necesitan un factor viable —llaves de hardware o códigos de respaldo— planificado antes del día de la aplicación obligatoria, no improvisado en la mesa de ayuda.

El principio en todos los casos es el mismo: no introduzca exenciones amplias en su política de usuarios para acomodar unos pocos casos particulares. Resuelva cada caso con el mecanismo adecuado para que la línea base se mantenga intacta.

Después de la implementación: manténgala aplicada

La aplicación obligatoria no es una meta final. Las cuentas nuevas, las unidades organizativas recién creadas y las excepciones puntuales crean, todas ellas, vías por las que la cobertura puede debilitarse. Incorpore una verificación recurrente a su rutina: confirme que la 2SV se sigue aplicando en todas las unidades organizativas, que ninguna exención se ha convertido silenciosamente en permanente, y que los factores fuertes siguen siendo obligatorios donde usted los exigió. El control más sólido del mundo se degrada si nadie confirma que sigue activo, y "aplicamos la MFA" debería ser una afirmación que pueda demostrar, no una que espera que siga siendo cierta.

8200.dev audita la configuración administrativa de su Google Workspace —incluida la aplicación de la Verificación en 2 pasos, los controles de uso compartido y la autenticación de correo electrónico— y señala las desviaciones con enlaces directos a la configuración correspondiente. Vea cómo funciona.

¿Quiere confirmar que la MFA realmente se aplica en todas partes? Inicie su auditoría de seguridad gratuita y obtenga una evaluación de la postura de identidad y configuración de su Google Workspace.