TL;DR – Resumen ejecutivo
"El término "continuidad del correo electrónico» tiene diferentes significados para cada persona. Históricamente, no era algo que quitara el sueño a la mayoría de las organizaciones. Si hace años le hubieras preguntado a un administrador de Exchange o de Microsoft 365, te habría dicho que las interrupciones en el correo electrónico se resolvían por sí solas, y no se habría equivocado. La infraestructura de Microsoft es realmente buena, el SMTP pone el correo en cola y la mayoría de las interrupciones son de corta duración.
Eso ya no refleja toda la realidad. Aunque las interrupciones no sean prolongadas, la cuestión ya no es solo:
“¿Llegará el correo electrónico algún día?”
En cambio, ahora es:
“¿Puede la organización seguir funcionando si no hay correo electrónico?”
Cualquier interrupción del servicio de Microsoft 365 tiene como consecuencia una pérdida de productividad, retrasos en la comunicación y la pérdida de oportunidades de negocio, y este efecto es especialmente notable en las grandes organizaciones.
Además, los marcos de cumplimiento como NIS2, DORA...y... SOC 2 están reforzando este cambio hacia la continuidad del negocio. Estos marcos forman parte de una tendencia normativa más amplia que impulsa a las organizaciones a ir más allá de las copias de seguridad y la recuperación, y a centrarse en mantener la capacidad operativa durante las interrupciones, los incidentes cibernéticos y las interrupciones del servicio.
¿Quieres pasar directamente a ver cómo Google Workspace, al funcionar en paralelo con Microsoft 365, puede garantizar la continuidad del negocio?
Explorare Google Workspace for Business Continuity por Connecting Software, la capa tecnológica que permite el funcionamiento de la referencia «Google Business Continuity Plus».
Las copias de seguridad protegen los datos. La continuidad del correo electrónico favorece la resiliencia operativa.
Cuando piensas en una solución de copia de seguridad para Microsoft 365, lo normal es que te preocupe la recuperación de los datos después de un incidente.
Las soluciones de continuidad del correo electrónico, por su parte, están diseñadas para mantener operativas las comunicaciones, los calendarios y la colaboración durante el incidente.
Esa distinción es importante en los siguientes casos:
- Interrupciones del servicio de Microsoft 365,
- exclusiones de inquilinos,
- casos de ransomware,
- fallos de identidad,
- o ciberataques.
La verdadera pregunta es:
¿Cómo pueden los usuarios seguir trabajando mientras el entorno principal no está disponible?
Es aquí también donde cobran utilidad dos indicadores en los que acaba centrándose cualquier debate sobre planes de continuidad del negocio (BCP) y recuperación ante desastres (DR): RTO y RPO.
En un debate tradicional sobre copias de seguridad, el RTO suele medirse como el tiempo necesario para restaurar el sistema o los datos afectados, mientras que el RPO refleja la antigüedad del punto de restauración (en otras palabras, la cantidad de datos recientes que pueden faltar).
En un debate sobre la continuidad del servicio por correo electrónico, a menudo se aplican los mismos parámetros a nivel de función empresarial: el RTO se refiere al tiempo que la organización puede tolerar antes de que los usuarios puedan volver a comunicarse, y el RPO se refiere al grado de actualización que debe tener el entorno de comunicación de reserva.
Esa distinción es importante para NIS2, DORA, SOC 2 y otros debates similares sobre resiliencia y cumplimiento normativo, ya que la cuestión es si la función empresarial puede continuar durante la interrupción.
Comparación de los enfoques de continuidad del correo electrónico de Microsoft 365
Una vez que el requisito cambie a “mantener la comunicación entre las personas durante la interrupción”,” Las cuestiones arquitectónicas relacionadas con las tecnologías de la información se vuelven mucho más interesantes.
¿Es suficiente con un servicio de buzón de correo de emergencia ligero? ¿Debemos tener en cuenta las diferentes regiones? ¿Deberíamos utilizar nuestra propia infraestructura local?
Hay múltiples enfoques y compensaciones que hay que tener en cuenta para alcanzar el nivel de continuidad que la empresa realmente necesita. En la tabla siguiente se comparan los principales enfoques, que analizaremos con más detalle a continuación.
| Enfoque | Idea principal | Ejemplos de herramientas y proveedores | Puntos fuertes | Preocupaciones habituales |
|---|---|---|---|---|
| Servicios de continuidad basados en la nube | Plataforma de continuidad en caso de emergencia alojada por un tercero | Mimecast, Retarus, Trend Micro | Despliegue rápido Menores gastos generales de explotación |
Continuidad limitada más allá del correo web de emergencia |
| Segundo inquilino de Microsoft 365 | Entorno independiente de Microsoft 365 preparado para la conmutación por error | Microsoft 365 | El conocido ecosistema de Microsoft Arquitectura nativa de la nube |
Dependencia del ecosistema de un único proveedor, riesgo de concentración |
| Servidor Exchange en las propias instalaciones | Entorno independiente Exchange sincronizado con Microsoft 365 | Microsoft, CB Exchange Server Sync | Independencia operativa y control Un ecosistema de Microsoft con el que los usuarios finales están familiarizados |
Infraestructura adicional y mantenimiento |
| Google Workspace como sistema de reserva activa | Entorno independiente de Google Workspace sincronizado con Microsoft 365 | Continuidad del negocio de Google Workspace, CB Exchange Server Sync para Google Workspace | Independencia entre nubes Se puede ampliar a SharePoint/Google Drive |
Experiencia de usuario, identidad y mapeo diferentes |
El modelo adecuado depende del perfil de riesgo operativo de la organización, de sus obligaciones de cumplimiento normativo y de su tolerancia al tiempo de inactividad. Analicemos cada opción con más detalle.
Opción 1: Servicios de continuidad del correo electrónico basados en la nube
Este es uno de los enfoques tradicionales. Proveedores como Mimecast, Retarus y Trend Micro ofrecen plataformas de continuidad basadas en la nube que proporcionan acceso de emergencia al buzón de correo, enrutamiento del correo y servicios de comunicación temporales.
Las ventajas son una rápida puesta en marcha y unos menores costes operativos.
Sin embargo, los equipos de las empresas suelen preguntarse qué grado de continuidad operativa real ofrecen estas plataformas más allá del acceso temporal al correo web. ¿Podrán los usuarios seguir coordinando sus calendarios, trabajar con buzones compartidos y volver sin problemas a Microsoft 365 tras el incidente?
Opción 2: Entidad secundaria de Microsoft 365
Algunas organizaciones utilizan un inquilino secundario de Microsoft 365 para la conmutación por error, a veces en una región diferente, con el fin de reducir la vulnerabilidad ante las interrupciones del servicio en una región concreta.
Esto puede mejorar la resiliencia, sobre todo si el inquilino secundario se diseña con una administración, un enrutamiento, unas políticas de acceso y unos procedimientos de recuperación independientes. Sin embargo, la configuración interregional no elimina la dependencia general del ecosistema de la nube de Microsoft.
Hay también una cuestión más sutil: si el inquilino secundario se autentica a través del mismo proveedor de identidad que el entorno de producción (normalmente, el mismo inquilino de Entra ID), cualquier incidente o interrupción del servicio relacionado con la identidad puede afectar a ambos entornos a la vez.
Opción 3: Servidor Exchange local sincronizado con Microsoft 365
Una tercera opción consiste en mantener un entorno de servidor Exchange independiente y sincronizado con Microsoft 365.
Un ejemplo es el uso de un servidor Exchange local sincronizado con Microsoft 365.
En este modelo:
- Microsoft 365 sigue siendo la principal plataforma operativa,
- El servidor Exchange es el entorno de continuidad independiente,
- El uso de CB Exchange Server Sync para BCP y Connecting Software garantiza la sincronización entre ambos.
La sincronización puede incluir:
- buzones,
- calendarios,
- contactos,
- carpetas públicas,
- grupos de distribución,
- y la sincronización GAL.
Dado que este entorno se ejecuta de forma local con su propio Active Directory, no tiene por qué compartir un plano de identidad con el inquilino de Microsoft 365. Esa es una diferencia significativa con respecto a la opción 2: un ataque basado en la identidad contra el inquilino de la nube no se extiende automáticamente al entorno local Exchange, lo cual tiene una repercusión directa en los escenarios de "fallos de identidad" y "bloqueo del inquilino" mencionados anteriormente.
El hecho de que se ejecute en las propias instalaciones también significa que es la mejor opción si tu organización necesita este tipo de solución en una red aislada físicamente. La versión local se puede utilizar junto con diodos de datos para hacer posible ese escenario.
Por qué algunas organizaciones prefieren esta arquitectura
Para las organizaciones con requisitos de resiliencia operativa más exigentes, este enfoque puede ofrecer:
- independencia operativa respecto a Microsoft 365,
- la conocida Outlook y la continuidad del calendario,
- un mayor control sobre la infraestructura y la conmutación por error,
- compatibilidad con entornos regulados o aislados,
- independencia de identidad respecto al inquilino de producción,
- y un menor riesgo de concentración de nubes.
Las organizaciones que también dependen de SharePoint y de la colaboración en documentos pueden, además, implementar estrategias de sincronización de documentos mediante Secure Sync for SharePoint de Connecting Software, con el fin de garantizar una sincronización segura de SharePoint entre entornos independientes o aislados.
Opción 4: Google Workspace en modo de espera activa
Un cuarto enfoque sigue la misma lógica que la opción 3, pero cambia la plataforma de reserva: en lugar del servidor Exchange en las instalaciones, el entorno independiente es Google Workspace, que se mantiene sincronizado continuamente con Microsoft 365 a través de .
Esto ofrece a las organizaciones una opción de conmutación por error entre nubes sin depender en absoluto del ecosistema de Microsoft. Esto puede ser importante para mitigar el riesgo de concentración y también resulta muy popular entre las organizaciones que ya gestionan parte de sus operaciones en Google Workspace. Incluso en el caso de quienes no lo hacen, los usuarios suelen estar familiarizados con Google Workspace por su experiencia personal, lo que resulta útil durante la conmutación por error.
Analizaremos esta arquitectura, su modelo de identidad y sus ventajas e inconvenientes específicos en un artículo posterior.
Descubre cómo implementar un sistema de espera activa con Google Workspace para la continuidad del negocio, por Connecting Software
Conmutación por error: eliminación de la ventana de restauración
El método tradicional de copia de seguridad y restauración implicaba que, cuando se producía una interrupción, alguien tenía que realizar una restauración antes de que nadie pudiera volver a trabajar.
Esto plantea dos problemas: la intervención manual necesaria y el tiempo que lleva la restauración, que es proporcional a la cantidad de datos que hay que restaurar. En el caso de los grandes clientes, no es raro que los RTO se midan en días.
Los servicios de continuidad del correo electrónico basados en la nube son una solución alternativa para este problema, pero ofrecen funciones limitadas.
Un entorno de espera sincronizado elimina ese paso. Al disponer de una copia actualizada continuamente de los buzones de correo, los calendarios y, en su caso, los documentos, basta con indicar a los usuarios que utilicen ese entorno para que puedan seguir trabajando. Se trata de una conmutación por error sin ventana de restauración, que está activa y al día, lo que elimina la ventana de restauración del cálculo del RTO.
Tendrás que sopesar ese coste frente al coste que supone que tus usuarios no dispongan de correo electrónico, calendario y demás contenidos del buzón, en términos de pérdida de productividad, operaciones no cerradas y costes de cumplimiento normativo, cuando proceda.
Recuperación tras un fallo: cómo evitar la conciliación manual
La conmutación por error es solo la mitad de la historia. En algún momento, el entorno principal vuelve a estar operativo y los usuarios deben volver a él. Esta es la fase de conmutación de retorno, en la que la verdadera cuestión es qué ocurre con los correos enviados y recibidos, los cambios en el calendario y las modificaciones de documentos realizadas en el entorno de reserva, sin perder datos ni crear duplicados.
¿Habrá que volver a incorporar manualmente los nuevos correos electrónicos, los cambios en el calendario y los documentos editados al entorno de producción? A nadie le gusta hacer esto, porque es precisamente el tipo de tarea manual que da lugar a errores, confusión entre versiones y retrasos.
Con la sincronización bidireccional, esa conciliación se produce automáticamente: los cambios realizados durante la interrupción se transfieren a Microsoft 365 sin intervención del departamento de TI una vez que se restablece el entorno principal. Los únicos datos en riesgo son aquellos que hayan cambiado durante el intervalo de sincronización más reciente, es decir, el tiempo transcurrido entre una sincronización y la siguiente. Si el intervalo es de cinco minutos, el RPO práctico equivale aproximadamente a cinco minutos de cambios, y no a la duración total de la interrupción. Puede programar la recuperación automática en función de su intervalo de sincronización para reducir el RPO a cero.
Cabe señalar que el intervalo de sondeo implica una disyuntiva: acortarlo reduce el RPO, pero; alargarlo reduce la sobrecarga, pero amplía la ventana de posible pérdida de datos.
No existe una única arquitectura de correo electrónico “correcta”.
La solución adecuada depende de:
- dependencia operativa de Microsoft 365,
- tiempo de inactividad aceptable,
- requisitos normativos,
- capacidades internas de TI,
- y los objetivos de resiliencia operativa.
Las organizaciones con necesidades moderadas pueden quedar plenamente satisfechas con los servicios de continuidad basados en la nube.
Las organizaciones que operan bajo el marco de NIS2, DORA o que deben cumplir requisitos estrictos de resiliencia pueden necesitar una mayor independencia operativa y mejores capacidades de conmutación por error.
Reflexiones finales
Microsoft 365 ofrece una disponibilidad excelente.
Pero la disponibilidad por sí sola no garantiza la resiliencia operativa.
Las organizaciones reconocen cada vez más que la continuidad del correo electrónico, el acceso al calendario y la continuidad de la colaboración son esenciales para mantener las operaciones durante una interrupción.
Porque, durante un corte de suministro real, la pregunta más importante no es:
“¿Podemos ponernos al día más tarde?”
Es:
"¿Podemos seguir trabajando?"
Descubre cómo implementar un sistema de espera activa con Google Workspace para la continuidad del negocio, por Connecting Software
Más información sobre la continuidad del negocio y la recuperación ante desastres
La copia de seguridad no es sinónimo de continuidad: recuperación «en caliente» frente a «en frío» para Exchange, SharePoint y Microsoft 365
La trampa de la simplicidad: por qué el correo electrónico en la nube debe estar presente en todas las conversaciones sobre el PBC
Sovereign Clouds Rising: Cuestionando el control de los datos en la era de la nube
Sobre el autor
Por Ana Neto, asesor técnico en Connecting Software.
"Soy ingeniero informático desde 1997, con una afición más reciente por escribir y hablar en público. ¿Tiene alguna pregunta o comentario sobre este artículo? Me encantaría conocer tu opinión, ¡deja un comentario a continuación!"
