TL;DR – Sintesi
"Il concetto di "continuità della posta elettronica" assume significati diversi a seconda delle persone. Storicamente, non era una questione che teneva svegli la notte la maggior parte delle organizzazioni. Se anni fa aveste chiesto a un amministratore di Exchange o Microsoft 365, vi avrebbe risposto che i disservizi della posta elettronica si risolvevano da soli, e non avrebbe avuto torto. L’infrastruttura di Microsoft è davvero valida, l’SMTP mette in coda i messaggi e la maggior parte delle interruzioni è di breve durata.
Questo non è più il quadro completo. Anche se le interruzioni non durano a lungo, la questione non è più solo:
“L'e-mail arriverà prima o poi?”
Invece, è diventato:
“L’organizzazione può continuare a funzionare anche senza posta elettronica?”
Qualsiasi interruzione del servizio Microsoft 365 comporta una perdita di produttività, ritardi nelle comunicazioni e la perdita di opportunità commerciali, e tale impatto è particolarmente evidente nelle grandi organizzazioni.
Inoltre, i quadri normativi come NIS2, DORAe SOC 2 stanno rafforzando questa transizione verso la continuità operativa. Tali quadri normativi fanno parte di una tendenza più ampia che spinge le organizzazioni ad andare oltre il semplice backup e il ripristino, orientandole invece a mantenere la capacità operativa durante le interruzioni di servizio, gli incidenti informatici e i disservizi.
Vuoi passare direttamente a scoprire come Google Workspace, utilizzato in parallelo con Microsoft 365, possa garantire la continuità operativa?
Esplorae Google Workspace for Business Continuity a cura di Connecting Software, il livello tecnologico che rende possibile il funzionamento dello SKU Google Business Continuity Plus.
Il backup protegge i dati. La continuità della posta elettronica garantisce la resilienza operativa.
Quando si pensa a una soluzione di backup per Microsoft 365, di solito ci si preoccupa del recupero dei dati dopo un incidente.
Le soluzioni per la continuità del servizio di posta elettronica, invece, sono progettate per garantire il funzionamento delle comunicazioni, dei calendari e della collaborazione durante l'incidente.
Questa distinzione è importante nei seguenti casi:
- Interruzioni del servizio Microsoft 365,
- chiusura fuori casa degli inquilini,
- episodi di ransomware,
- errori di identità,
- o attacchi informatici.
La vera domanda è:
Come possono gli utenti continuare a lavorare quando l'ambiente principale non è disponibile?
È proprio qui che tornano utili due indicatori su cui, prima o poi, verte qualsiasi discussione sul BCP/DR: RTO e RPO.
In un contesto tradizionale di backup, l’RTO viene solitamente misurato come il tempo necessario per ripristinare il sistema o i dati interessati, mentre l’RPO riflette l’età del punto di ripristino (in altre parole, la quantità di dati recenti che potrebbero andare persi).
In una discussione sulla continuità operativa via e-mail, spesso vengono applicati gli stessi parametri a livello di funzione aziendale: l’RTO indica per quanto tempo l’organizzazione può tollerare l’interruzione prima che gli utenti possano tornare a comunicare, mentre l’RPO indica quanto deve essere aggiornato l’ambiente di comunicazione di riserva.
Tale distinzione è rilevante ai fini di NIS2, DORA, SOC 2 e di altre discussioni simili in materia di resilienza e conformità, poiché la questione è se la funzione aziendale possa continuare a operare durante l’interruzione.
Confronto tra gli approcci alla continuità della posta elettronica in Microsoft 365
Una volta che il requisito cambia in “mantenere viva la comunicazione tra le persone durante il periodo di interruzione”,” le questioni architettoniche relative all'IT diventano molto più interessanti.
È sufficiente un servizio di casella postale di emergenza leggero? Dobbiamo tenere conto delle diverse regioni? Dovremmo utilizzare la nostra infrastruttura in loco?
Esistono diversi approcci e compromessi da considerare per raggiungere il livello di continuità di cui l'azienda ha effettivamente bisogno. La tabella che segue mette a confronto i principali approcci, che esamineremo più nel dettaglio di seguito.
| Approccio | Idea principale | Esempi di strumenti e fornitori | Punti di forza | Preoccupazioni tipiche |
|---|---|---|---|---|
| Servizi di continuità operativa basati sul cloud | Piattaforma di continuità operativa in caso di emergenza ospitata da una terza parte | Mimecast, Retarus, Trend Micro | Rapido dispiegamento Riduzione dei costi operativi generali |
Continuità limitata al di là del servizio di webmail di emergenza |
| Secondo tenant di Microsoft 365 | Ambiente Microsoft 365 separato predisposto per il failover | Microsoft 365 | L'ecosistema Microsoft che tutti conosciamo Architettura cloud-native |
Dipendenza dall'ecosistema di un unico fornitore, rischio di concentrazione |
| Server Exchange in locale | Ambiente Exchange indipendente sincronizzato con Microsoft 365 | Microsoft, CB Exchange Server Sync | Indipendenza operativa e controllo Un ecosistema Microsoft familiare per gli utenti finali |
Infrastrutture aggiuntive e manutenzione |
| Google Workspace in modalità hot standby | Ambiente Google Workspace indipendente sincronizzato con Microsoft 365 | Continuità operativa di Google Workspace, CB Exchange Server Sync per Google Workspace | Indipendenza tra i vari cloud Può essere esteso a SharePoint/ Google Drive |
Esperienza utente, identità e mappatura diverse |
La scelta del modello più adatto dipende dal profilo di rischio operativo dell'organizzazione, dagli obblighi di conformità e dalla tolleranza ai tempi di inattività. Esaminiamo ciascuna opzione più nel dettaglio.
Opzione 1: Servizi di continuità della posta elettronica basati sul cloud
Questo è uno degli approcci tradizionali. Fornitori come Mimecast, Retarus e Trend Micro mettono a disposizione piattaforme di continuità operativa basate sul cloud che offrono accesso di emergenza alle caselle di posta, instradamento della posta e servizi di comunicazione temporanei.
I vantaggi sono una rapida implementazione e minori costi operativi.
Tuttavia, i team aziendali si chiedono spesso quale sia il reale livello di continuità operativa garantito da queste piattaforme, al di là dell’accesso temporaneo alla webmail. Gli utenti possono ancora coordinare i calendari, lavorare con le caselle di posta condivise e tornare senza problemi a Microsoft 365 dopo l’incidente?
Opzione 2: Tenant secondario di Microsoft 365
Alcune organizzazioni utilizzano un tenant Microsoft 365 secondario per il failover, talvolta in una regione diversa, al fine di ridurre l'esposizione alle interruzioni del servizio a livello regionale.
Ciò può migliorare la resilienza, soprattutto se il tenant secondario è progettato con amministrazione, instradamento, criteri di accesso e procedure di ripristino separati. Tuttavia, la configurazione interregionale non elimina la dipendenza più ampia dall'ecosistema cloud di Microsoft.
C'è anche un aspetto più sottile: se il tenant secondario effettua l'autenticazione tramite lo stesso provider di identità dell'ambiente di produzione (di solito lo stesso tenant Entra ID), allora un incidente o un'interruzione legati all'identità possono influire contemporaneamente su entrambi gli ambienti.
Opzione 3: Server Exchange in locale sincronizzato con Microsoft 365
Un terzo approccio consiste nel mantenere un ambiente server Exchange indipendente e sincronizzato con Microsoft 365.
Un esempio è l'utilizzo di un server Exchange in locale sincronizzato con Microsoft 365.
In questo modello:
- Microsoft 365 rimane la piattaforma operativa principale,
- Il server Exchange è l'ambiente di continuità operativo indipendente,
- Il passaggio da CB Exchange Server Sync a Connecting Software per BCP garantisce la sincronizzazione tra i due.
La sincronizzazione può comprendere:
- caselle di posta,
- calendari,
- contatti,
- cartelle pubbliche,
- gruppi di distribuzione,
- e la sincronizzazione GAL.
Poiché questo ambiente è gestito in locale con un proprio Active Directory, non è necessario che condivida un piano di identità con il tenant di Microsoft 365. Si tratta di una differenza significativa rispetto all’opzione 2: un attacco basato sull’identità contro il tenant cloud non si estende automaticamente all’ambiente Exchange on-premise, il che ha un impatto diretto sugli scenari di "errori di identità" e "blocco del tenant" elencati sopra.
L'implementazione on-premises rende questa soluzione la scelta più indicata se la vostra organizzazione necessita di questo tipo di soluzione in una rete air-gapped. La versione on-premises può essere utilizzata in combinazione con i diodi di dati per rendere possibile tale scenario.
Perché alcune organizzazioni preferiscono questa architettura
Per le organizzazioni con requisiti di resilienza operativa più elevati, questo approccio può offrire:
- indipendenza operativa da Microsoft 365,
- il ben noto Outlook e la continuità del calendario,
- un maggiore controllo sulle infrastrutture e sul failover,
- supporto per ambienti regolamentati o isolati,
- indipendenza identitaria rispetto al tenant di produzione,
- e un minor rischio di concentrazione delle nuvole.
Le organizzazioni che fanno affidamento anche su SharePoint e sulla collaborazione sui documenti possono inoltre implementare strategie di sincronizzazione dei documenti utilizzando Secure Sync for SharePoint by Connecting Software, al fine di garantire una sincronizzazione sicura di SharePoint tra ambienti indipendenti o isolati.
Opzione 4: Google Workspace in modalità hot standby
Un quarto approccio segue la stessa logica dell'Opzione 3, ma cambia la piattaforma di riserva: invece del server Exchange on-premises, l'ambiente indipendente è Google Workspace, mantenuto costantemente sincronizzato con Microsoft 365 tramite .
Ciò offre alle organizzazioni un’opzione di failover cross-cloud che non dipende in alcun modo dall’ecosistema Microsoft. Questo aspetto può essere rilevante in caso di preoccupazioni relative al rischio di concentrazione ed è particolarmente apprezzato dalle organizzazioni che già gestiscono parte delle proprie operazioni su Google Workspace. Anche per chi non lo utilizza, gli utenti hanno spesso familiarità con Google Workspace grazie all’esperienza personale, il che risulta utile durante il failover.
Analizzeremo questa architettura, il suo modello di identità e i relativi compromessi in un articolo successivo.
Scopri come implementare uno "hot standby" con Google Workspace per la continuità operativa, a cura di Connecting Software
Failover: eliminazione della finestra di ripristino
Con il tradizionale approccio basato su backup e ripristino, quando si verificava un’interruzione, era comunque necessario che qualcuno eseguisse un ripristino prima che chiunque potesse tornare a lavorare.
Ciò comporta due problemi: l’intervento manuale richiesto e il tempo necessario per il ripristino, che è proporzionale alla quantità di dati da ripristinare. Per i tenant di grandi dimensioni, non è raro che gli RTO siano misurati in giorni.
I servizi di continuità della posta elettronica basati sul cloud rappresentano una soluzione alternativa a questo problema, ma offrono funzionalità limitate.
Un ambiente di standby sincronizzato elimina questa fase. Poiché si dispone di una copia costantemente aggiornata delle caselle di posta, dei calendari e, eventualmente, dei documenti, è sufficiente indirizzare gli utenti verso tale ambiente affinché possano continuare a lavorare. Si tratta di un failover senza finestra di ripristino, sempre attivo e aggiornato, il che elimina la finestra di ripristino dal calcolo dell’RTO.
Dovrete valutare tale costo rispetto a quello derivante dal fatto che i vostri utenti non abbiano a disposizione la posta elettronica, il calendario e altri contenuti della casella di posta, in termini di perdita di produttività, affari non conclusi e costi di conformità, ove applicabili.
Failback: come evitare la riconciliazione manuale
Il failover è solo metà del processo. A un certo punto, l’ambiente primario torna operativo e gli utenti devono tornare a utilizzarlo. Questa è la fase di failback, in cui la vera domanda è: cosa succede alla posta inviata e ricevuta, alle modifiche al calendario e alle modifiche ai documenti effettuate nell’ambiente di standby, senza perdere dati né creare duplicati?.
Le nuove e-mail, le modifiche al calendario e i documenti modificati dovranno essere riconciliati manualmente con l'ambiente di produzione? Non è certo un compito gradito a nessuno, perché è proprio il tipo di operazione manuale che causa errori, confusione tra le versioni e ritardi.
Con la sincronizzazione bidirezionale, tale riconciliazione avviene automaticamente: le modifiche apportate durante l’interruzione vengono riportate in Microsoft 365 senza alcun intervento dell’IT una volta ripristinato l’ambiente primario. Gli unici dati a rischio sono quelli modificati nell’ultimo intervallo di polling di sincronizzazione, ovvero il lasso di tempo che intercorre tra un ciclo di sincronizzazione e quello successivo. Se l’intervallo è di cinque minuti, l’RPO effettivo corrisponde all’incirca a cinque minuti di modifiche, non all’intera durata dell’interruzione. È possibile programmare il failback in base all’intervallo di polling per ridurre l’RPO a zero
Vale la pena notare che l'intervallo di polling comporta un compromesso: accorciarlo riduce l'RPO, ma allungarlo riduce il sovraccarico, ampliando però la finestra di potenziale perdita di dati.
Non esiste un'unica architettura “corretta” per la posta elettronica.
La soluzione giusta dipende da:
- dipendenza operativa da Microsoft 365,
- tempo di inattività accettabile,
- requisiti normativi,
- competenze IT interne,
- e gli obiettivi di resilienza operativa.
Le organizzazioni con esigenze moderate potrebbero trovare piena soddisfazione nei servizi di continuità operativa basati sul cloud.
Le organizzazioni che operano in conformità con la direttiva NIS2, la direttiva DORA o che devono soddisfare rigorosi requisiti di resilienza potrebbero necessitare di una maggiore indipendenza operativa e di capacità di failover più avanzate.
Pensieri finali
Microsoft 365 garantisce un'eccellente disponibilità.
Ma la disponibilità da sola non garantisce la resilienza operativa.
Le organizzazioni riconoscono sempre più che la continuità del servizio di posta elettronica, l'accesso al calendario e la continuità della collaborazione sono essenziali per garantire il regolare svolgimento delle attività durante le interruzioni.
Perché durante un'interruzione di corrente vera e propria, la domanda più importante non è:
“Possiamo rimetterci in pari più tardi?”
È:
"Possiamo continuare a operare?"
Scopri come implementare uno "hot standby" con Google Workspace per la continuità operativa, a cura di Connecting Software
Maggiori informazioni sulla continuità operativa e sul ripristino di emergenza
Il backup non equivale alla continuità operativa: ripristino “a caldo” e “a freddo” per Exchange, SharePoint e Microsoft 365
La trappola della semplicità: perché l'e-mail nel cloud deve essere presente in ogni conversazione sul BCP
Nuvole sovrane in aumento: Mettere in discussione il controllo dei dati nell'era del cloud
Sull'autore
Da Ana Neto, consulente tecnico a Connecting Software.
"Sono un ingegnere informatico dal 1997, con un amore più recente per la scrittura e il public speaking". Avete domande o commenti su questo articolo? Mi piacerebbe avere il vostro feedback, lasciate un commento qui sotto!"
