La trampa de la simplicidad: por qué el correo electrónico en la nube debe estar presente en todas las conversaciones sobre el PBC

Se suponía que la nube lo simplificaría todo. Y para la mayoría de las cargas de trabajo, lo hizo. Para quienes trabajan en un entorno Microsoft, Microsoft 365 prometía, y en gran medida cumplió, un mundo en el que el correo electrónico, los calendarios y la colaboración simplemente funcionaban, y no había necesidad de pensar en los servidores que lo soportaban.

Pero el mundo está cambiando. Las tensiones comerciales y las disputas por la soberanía de los datos son prueba de ello. Y los cortes de suministro ya no son casos extremos.

En enero de 2026, Microsoft 365 se cayó a nivel mundial. El correo electrónico se detuvo. Outlook no se cargaba. El acceso al calendario desapareció. El radio de explosión no fue una empresa. Eran todos los inquilinos de la plataforma, todos a la vez.

Para cada organización que se quedaba sin una solución de emergencia, la continuidad de su actividad se veía amenazada. Y para las organizaciones que operan bajo normativas como DORA o NIS2, eso ya no es sólo un problema operativo. Es un fallo de cumplimiento de la normativa, que conlleva el riesgo de multas, informes obligatorios y una posible intervención supervisora.

En múltiples jurisdicciones e industrias, los reguladores están subiendo el listón de lo que realmente significa la continuidad de la actividad empresarial:

• DORA (entrada en vigor total en enero de 2025): Las organizaciones del sector financiero deben mantener y probar periódicamente planes documentados de continuidad de las TIC, garantizar que los sistemas permanezcan operativos durante las interrupciones y mitigar activamente los riesgos de los proveedores de nube de terceros. Disponer de un acuerdo de nivel de servicio no se considera una mitigación adecuada.

Las autoridades supervisoras tienen potestad para imponer planes de corrección, realizar auditorías adicionales, restringir determinadas actividades empresariales o aumentar la supervisión si se descubre que las organizaciones incumplen las normas.

• NIS2: extiende obligaciones casi idénticas a la energía, la sanidad, el transporte, la administración pública y la infraestructura digital. Los sistemas de correo electrónico entran explícitamente en el ámbito de aplicación. Las sanciones alcanzan 2% de facturación anual global. La carga de la prueba recae en la organización, no en el regulador.

Los reguladores pueden imponer medidas correctivas, exigir pruebas detalladas del cumplimiento y, en casos graves, restringir o prohibir las operaciones comerciales relacionadas con servicios esenciales o importantes hasta que se restablezca el cumplimiento.

• GDPR y soberanía de datos: Los datos de correo electrónico mantenidos exclusivamente con proveedores de servicios en la nube con sede en EE.UU. están sujetos a la divulgación obligatoria de la Ley CLOUD de EE.UU., independientemente de la ubicación física de los servidores. Para las organizaciones europeas de sectores regulados como la sanidad, los servicios jurídicos y la investigación clínica, esto representa un riesgo de cumplimiento real y continuo.

Los reguladores esperan que las organizaciones demuestren el control sobre la residencia de los datos y la jurisdicción legal, una garantía que ningún hiperescalador puede ofrecer plenamente en nombre de su organización.

Estas no son las únicas normativas que exigen la continuidad de la actividad. Dependiendo de su sector y geografía, muchos otros marcos conllevan obligaciones similares:

El hilo conductor de todos estos marcos es el mismo: la organización es responsable de la continuidad, no el proveedor. La afirmación "nuestro proveedor de la nube no funciona" no satisface a ningún auditor en ninguna de estas jurisdicciones.

La respuesta no es abandonar la M365. Es ampliarlo. Adoptando una arquitectura de espera activa, puede lograr la resistencia y la continuidad del negocio sin interrumpir a sus usuarios finales.

En una arquitectura de este tipo, un entorno gestiona 100% de tráfico vivo en estado normal. Un segundo entorno mantiene la paridad continua y asume el tráfico cuando falla el primario. Naturalmente, el flujo de conmutación por error debe planificarse y probarse de antemano, para que sea auditable y accionable cuando sea necesario.

Hay tres aspectos clave que actúan como base de una arquitectura activo-standby, como se ve en el siguiente diagrama:

1 - Una herramienta de sincronización automática...como... CB Exchange Server Sync, para mantener la paridad bidireccional del correo y los calendarios en todas las plataformas, a la vez que se mantiene el control total de la ubicación de los datos.

2 - A pasarela de correo, como Postfix, para proporcionar un búfer controlado que permita redirigir el correo electrónico a puntos finales secundarios durante una interrupción.

3 - Perfiles de clientes de correo electrónico precreados, para cambiar rápidamente a los usuarios a esos terminales secundarios. Todos los usuarios finales deben tener perfiles preconfigurados para ambos sistemas a fin de evitar retrasos en la configuración de la "primera ejecución". Recomendamos utilizar el Outlook clásico como cliente de correo electrónico o asegurarse de que todos los usuarios están capacitados para utilizar OWA como alternativa de “configuración cero”.

Para el entorno alternativo que tiene en espera, puede considerar las dos opciones siguientes, en función de las preferencias de infraestructura y los requisitos de soberanía de su organización.

Lo mejor para: organizaciones con requisitos de soberanía de datos, sectores regulados, operaciones basadas en la UE o infraestructura local existente.

Cómo funciona:

• On-premises Exchange se utiliza como entorno alternativo de reserva y se aloja en el propio centro de datos de la organización.
• CB Exchange Server Sync mantiene una sincronización bidireccional continua de correo, contactos y calendarios entre Microsoft 365 y Exchange on-prem. Todos los datos son idénticos en ambos sistemas.
• En el estado normal, Microsoft 365 gestiona todo el tráfico en directo.
• En caso de conmutación por error, el correo se encamina automáticamente a través del Exchange local.

Cómo es el flujo de conmutación por error para el usuario final:

• Outlook escritorio, móvil y OWA se conectan a cualquier entorno disponible.
• La interfaz es idéntica (no hay que aprender ningún sistema nuevo ni seguir ningún procedimiento de emergencia).
• Cualquier correo creado durante la interrupción se sincroniza automáticamente con Microsoft 365 al recuperarse.

Ventajas de la soberanía de datos:

• Los datos de correo electrónico en reposo viven en el propio centro de datos de la organización, bajo su propia jurisdicción, en el hardware que controlan.
• Cadena de custodia completa y auditabilidad
• Respuesta directa y demostrable a las disposiciones sobre riesgo de terceros del DORA

Lo que ven los auditores: Un entorno de espera vivo, en funcionamiento y comprobable. No un documento normativo. No una referencia SLA. Una prueba de continuidad.

Lo mejor para: organizaciones que prefieren la redundancia total en la nube, las que ya están evaluando la diversificación de proveedores o las que carecen de infraestructura local (o de un equipo para plantearse tenerla).

Cómo funciona:

• Google Workspace se utiliza como entorno alternativo de reserva. Se trata de una infraestructura de proveedor independiente, una huella de centro de datos diferente y una superficie de fallo diferente.
• Una pasarela de correo, como Postfix, centraliza la entrada y gestiona el enrutamiento, controlando el flujo de conmutación por error independientemente de la propagación MX.
• CB Exchange Server Sync mantiene una paridad bidireccional continua de correo y calendario con Google Workspace silenciosamente en segundo plano. Tendrás los mismos datos en ambos sistemas.
• En estado normal, Microsoft 365 gestiona 100% de tráfico en directo.
• En caso de conmutación por error, un cambio de ruta semiautomático en la pasarela redirige el tráfico a Google Workspace.
• De este modo se evita la división de cerebros MX (el conflicto de enrutamiento dividido que se produce cuando los cambios en los registros MX se propagan de forma incoherente a través de los resolvers DNS durante una transición en directo).

Cómo es el flujo de conmutación por error para el usuario final:

• Los usuarios familiarizados con Outlook pueden utilizarlo a través de conectores de correo durante el periodo de conmutación por error o pueden cambiar a las interfaces Gmail Web o Gmail Mobile.

Nota sobre soberanía de datos:

Esta opción es conveniente porque evita la necesidad de poseer o mantener la infraestructura, pero no proporciona la misma garantía de propiedad local que la Opción 1. La soberanía de los datos depende de la configuración de implementación de Google Workspace y de los ajustes de región. Para las organizaciones con requisitos de jurisdicción estrictos, la Opción 1 es una opción más sólida.

Independientemente del modelo de implantación que se adapte a la organización, la arquitectura subyacente ofrece las mismas garantías:

• Redundancia que sea invisible para los usuarios finales y visible para los auditores
• Arquitectura activa y en espera con sincronización continua. Sin espera en frío, sin restauración de copias de seguridad, sin recuperación manual de datos.
• A flujo de conmutación por error que se planifica y se prueba antes de que sea necesario

• Preparación para auditorías por defectoCuando un examinador de DORA o NIS2 pregunte cómo garantiza la organización la continuidad del correo electrónico, la respuesta será un sistema activo y en funcionamiento, no un documento de política que haga referencia a un acuerdo de nivel de servicio de un proveedor.
• La soberanía como diferenciador comercial: En la UE, muchos contratos del sector público y de infraestructuras críticas exigen el tratamiento de datos en el país o únicamente en la UE. En Australia, la APRA CPS 230 extiende esa responsabilidad directamente a terceros proveedores. En Estados Unidos, marcos como FBI CJIS y NYDFS exigen a las organizaciones -no a sus proveedores- que mantengan un estricto control sobre los datos sensibles. En los tres casos, las organizaciones que pueden demostrar la soberanía de los datos están ganando mandatos que los competidores que sólo operan en la nube no pueden ofrecer.
• Cero confianza, operacionalizada para el correo electrónicola postura más resistente del PCB asume que cualquier sistema puede fallar y se diseña en consecuencia. La arquitectura activa y en espera con sincronización continua presentada anteriormente es lo que parece esa suposición cuando se aplica a la carga de trabajo que las organizaciones menos pueden permitirse perder.
• Inversión que se mantiene a la vanguardiaLas organizaciones que invierten hoy en la capacidad de recuperación del correo electrónico híbrido adoptan una postura proactiva, adelantándose a las exigencias normativas, operativas y del mercado en lugar de reaccionar a posteriori.

Se suponía que la nube iba a simplificarlo todo. Para la mayoría de las cargas de trabajo, lo consiguió. Pero la simplicidad sin resiliencia no es más que fragilidad con mejor nombre.

Cuando los organismos reguladores acuden a su llamada, o cuando una avería importante paraliza las operaciones, ¿piensa que “confiamos en el SLA de nuestro proveedor”¿será una respuesta aceptada?

La era de la fe ciega en el tiempo de actividad de un único proveedor en la nube ha terminado, especialmente para sistemas empresariales críticos como el correo electrónico. El correo electrónico es el único canal de comunicación que funciona independientemente de la plataforma que utilice su contraparte. Probablemente por eso está en el centro de casi todas las interacciones críticas para la empresa. Es crucial para todas las relaciones con los clientes, todas las obligaciones normativas, todos los acuerdos en marcha. Cuando falla, todo lo demás falla con él.

Para las organizaciones que antes dependían únicamente de Microsoft 365, la creación de una arquitectura de doble entorno, que se pueda probar, no es solo prudencia técnica. Ahora es de sentido común normativo. Tanto si esto significa añadir un Exchange de reserva local para una soberanía total, como si se trata de una conmutación por error de nube a nube con Google Workspace para la diversidad de proveedores, la cuestión es la misma.

La resistencia debe diseñarse desde el principio, para que cuando falle la simplicidad, no lo haga la continuidad.

¿Quiere saber más sobre este tipo de Arquitectura Activa-Stanby y cómo CB Exchange Server Sync ¿podría funcionar en su caso? Asegúrese una sesión de consulta gratuita con nuestros expertos técnicos: