1. Demasiados administradores globales
El rol de administrador global puede todo: leer cualquier buzón, cambiar cualquier política, eliminar cualquier cuenta. Lo habitual es encontrarlo repartido entre el responsable de TI, el proveedor que hizo la migración, un consultor que ya no trabaja con la empresa y el director general, "por si acaso".
Cada una de esas cuentas es una llave maestra, y normalmente es también el buzón de uso diario de esa persona, el mismo que recibe phishing. La corrección es doble: reducir el rol global al mínimo indispensable y usar roles específicos —administrador de Exchange, de usuarios, de seguridad— para el trabajo cotidiano. Las cuentas que conserven el rol global deberían ser cuentas dedicadas, sin correo de uso diario y con el método de autenticación más fuerte disponible.
2. Dejar la autenticación heredada habilitada
Los protocolos antiguos —POP, IMAP, SMTP básico— no saben pedir un segundo factor. Aceptan usuario y contraseña y conceden acceso. Mientras estén activos, la autenticación multifactor del tenant se puede rodear por completo, y es exactamente lo que buscan los ataques automatizados de prueba de contraseñas.
El error aquí casi nunca es ignorancia: es miedo a romper algo. Suele haber un escáner multifuncional que envía por SMTP, un sistema de facturación que manda correos o un cliente de correo viejo en una computadora de planta. El orden correcto es inventariar qué usa esos protocolos a partir de los registros de inicio de sesión, migrar cada caso a autenticación moderna y después bloquear la autenticación heredada con una política de acceso condicional.
3. No revisar la auditoría de buzones ni las alertas
La auditoría unificada registra quién entró, qué leyó, qué borró y qué reglas creó. Sin ella, un incidente es irreconstruible: no hay forma de decirle a dirección qué información quedó expuesta.
Conviene verificar que la auditoría esté activa en el tenant y en los buzones, y conocer el periodo de conservación del plan contratado, porque un incidente que se descubre tarde puede caer fuera de la ventana. Pero el problema más frecuente no es que falten registros: es que nadie los mira. Las alertas de inicio de sesión imposible, de reenvío automático recién creado o de descarga masiva de archivos ya se generan; si no hay un responsable que las revise, se acumulan en un portal que nadie abre.
4. Compartición externa sin criterio
SharePoint y OneDrive permiten generar enlaces de tipo "cualquier persona con el enlace", que funcionan sin iniciar sesión, se reenvían solos y suelen no caducar. Es la fuga más silenciosa que existe: nadie fue atacado, simplemente el enlace de una cotización sigue vivo dos años después.
No se trata de prohibir la compartición, que es útil y necesaria. Se trata de configurarla: enlaces que requieran iniciar sesión como opción por defecto, caducidad obligatoria para los enlaces anónimos donde se permitan, permisos de solo lectura en lugar de edición cuando basta, y una revisión periódica de qué sitios están compartidos hacia afuera.
5. Licencias y cuentas que nadie reconcilia
Una reconciliación trimestral entre el directorio de Entra ID y la lista real de personal resuelve casi todo esto, y suele liberar licencias.
- Cuentas de personal que ya salió, activas y con licencia. Son credenciales válidas sin dueño que las vigile.
- Licencias asignadas y sin usar, que se siguen pagando mes a mes porque nunca se revisó el inventario contra la nómina.
- Usuarios con un plan superior al que necesitan y, peor, usuarios con información sensible en un plan que no permite imponer acceso condicional.
- Buzones personales usados como direcciones de área, en lugar de buzones compartidos, lo que obliga a compartir contraseñas y deja la información dentro de la cuenta de un empleado.
- Cuentas de servicio sin MFA, excluidas "temporalmente" de las políticas hace años.
6. Confundir retención con respaldo
Es el malentendido más caro. La papelera, el historial de versiones y las políticas de retención de Purview resuelven errores recientes y obligaciones de cumplimiento, dentro del mismo sistema donde viven los datos y con plazos que caducan. Un respaldo es una copia independiente, con histórico propio y restauración granular, que sirve aunque el tenant esté comprometido.
Esto se enmarca en el modelo de responsabilidad compartida: Microsoft responde por la disponibilidad de la plataforma; el cliente responde por sus datos y sus configuraciones. Dar por hecho que la nube ya respalda es la suposición que se descubre el día en que hay que recuperar algo de hace seis meses.
7. No tener un responsable
Detrás de los seis puntos anteriores casi siempre está el mismo vacío: nadie es dueño del tenant. El proveedor que hizo la migración entregó y se fue, el área de TI atiende lo urgente y Microsoft, mientras tanto, cambia valores por defecto, renombra servicios y publica capacidades nuevas que nadie activa.
La alternativa no es un proyecto: es una rutina. Revisar roles con privilegios, reconciliar licencias, mirar las alertas de seguridad, comprobar que el respaldo corre y probar una restauración. igeckoo hace exactamente eso como servicio administrado, con costo fijo mensual y soporte en español desde Querétaro; el punto de partida habitual es una revisión del tenant que devuelve una lista corta de correcciones ordenadas por riesgo.