TL;DR – Resumo executivo
"Continuidade do e-mail" tem significados diferentes para pessoas diferentes. Historicamente, não era algo que tirasse o sono à maioria das organizações. Se perguntasse a um administrador do Exchange ou do Microsoft 365 há alguns anos, ele dir-lhe-ia que as falhas no e-mail se resolviam por si mesmas, e não estaria errado. A infraestrutura da Microsoft é realmente boa, o SMTP coloca as mensagens em fila e a maioria das interrupções é de curta duração.
Isso já não reflete a realidade na sua totalidade. Mesmo que as falhas de energia não sejam prolongadas, a questão já não se resume apenas a:
“Será que o e-mail acabará por chegar?”
Em vez disso, passou a ser:
“A organização consegue continuar a funcionar sem e-mail?”
Qualquer interrupção no serviço do Microsoft 365 tem como consequência a perda de produtividade, atrasos na comunicação e oportunidades de negócio perdidas, e este efeito é especialmente visível em grandes organizações.
Além disso, os quadros de conformidade como NIS2, DORAe SOC 2 estão a reforçar esta mudança no sentido da continuidade das atividades. Essas estruturas fazem parte de uma tendência regulamentar mais ampla que leva as organizações a ir além do backup e da recuperação, orientando-as para a manutenção da capacidade operacional durante falhas, incidentes cibernéticos e interrupções de serviço.
Quer saber logo como o Google Workspace, quando utilizado em paralelo com o Microsoft 365, pode garantir a continuidade das atividades da empresa?
Explorare Google Workspace for Business Continuity pelo Connecting Software, a camada tecnológica que permite o funcionamento do SKU «Google Business Continuity Plus».
O backup protege os dados. A continuidade do serviço de e-mail contribui para a resiliência operacional.
Quando se pensa numa solução de cópia de segurança do Microsoft 365, normalmente a preocupação é a recuperação dos dados depois de um incidente.
Por outro lado, as soluções de continuidade do e-mail foram concebidas para manter a comunicação, os calendários e a colaboração em funcionamento durante o incidente.
Essa distinção é importante durante:
- Interrupções no serviço do Microsoft 365,
- expulso do imóvel,
- casos de ransomware,
- falhas de identidade,
- ou ciberataques.
A verdadeira questão é:
Como é que os utilizadores podem continuar a trabalhar enquanto o ambiente principal estiver indisponível?
É também aqui que se revelam úteis duas métricas que acabam por ser sempre abordadas em qualquer discussão sobre BCP/DR: RTO e RPO.
Numa discussão tradicional sobre cópias de segurança, o RTO é normalmente medido como o tempo necessário para restaurar o sistema ou os dados afetados, enquanto o RPO reflete a antiguidade do ponto de restauração (por outras palavras, a quantidade de dados recentes que podem estar em falta).
Numa discussão sobre continuidade por e-mail, as mesmas métricas são frequentemente aplicadas ao nível das funções empresariais: o RTO questiona quanto tempo a organização pode tolerar até que os utilizadores possam voltar a comunicar, e o RPO questiona até que ponto o ambiente de comunicação de reserva precisa de estar atualizado.
Essa distinção é importante no âmbito do NIS2, da DORA, do SOC 2 e de debates semelhantes sobre resiliência e conformidade, uma vez que a questão é saber se a função empresarial pode continuar a funcionar durante a perturbação.
Comparação das abordagens de continuidade do e-mail do Microsoft 365
Assim que o requisito passar a ser “manter as pessoas a comunicar durante a perturbação”,” as questões arquitetónicas relacionadas com as tecnologias da informação tornam-se muito mais interessantes.
Será que um serviço de caixa de correio de emergência leve é suficiente? Devemos ter em conta as diferentes regiões? Devemos utilizar a nossa própria infraestrutura local?
Existem várias abordagens e compromissos a ter em conta para alcançar o nível de continuidade de que a empresa realmente necessita. A tabela abaixo compara as principais abordagens, que iremos analisar mais detalhadamente a seguir.
| Abordagem | Ideia principal | Exemplos de ferramentas e fornecedores | Pontos fortes | Preocupações habituais |
|---|---|---|---|---|
| Serviços de continuidade baseados na nuvem | Plataforma de continuidade de serviços de emergência alojada por um terceiro | Mimecast, Retarus, Trend Micro | Implementação rápida Menores custos operacionais |
Continuidade limitada para além do serviço de correio eletrónico de emergência |
| Segundo inquilino do Microsoft 365 | Ambiente separado do Microsoft 365 preparado para failover | Microsoft 365 | Ecossistema familiar da Microsoft Arquitetura nativa da nuvem |
Dependência de um único fornecedor no ecossistema, risco de concentração |
| Servidor Exchange no local | Ambiente Exchange independente sincronizado com o Microsoft 365 | Microsoft, CB Exchange Server Sync | Independência operacional e controlo Ecossistema da Microsoft com o qual os utilizadores finais estão familiarizados |
Infraestruturas adicionais e manutenção |
| O Google Workspace como sistema de reserva ativa | Ambiente independente do Google Workspace sincronizado com o Microsoft 365 | Continuidade de Negócios do Google Workspace, CB Exchange Server Sync para o Google Workspace | Independência entre nuvens Pode ser alargado para SharePoint/ Google Drive |
Experiência do utilizador, identidade e mapeamento diferentes |
O modelo adequado depende do perfil de risco operacional da organização, das obrigações de conformidade e da tolerância ao tempo de inatividade. Vamos analisar cada opção com mais pormenor.
Opção 1: Serviços de continuidade de e-mail baseados na nuvem
Esta é uma das abordagens tradicionais. Fornecedores como a Mimecast, a Retarus e a Trend Micro disponibilizam plataformas de continuidade baseadas na nuvem que oferecem acesso de emergência à caixa de correio, encaminhamento de e-mails e serviços de comunicação temporários.
As vantagens são uma implementação rápida e custos operacionais mais baixos.
No entanto, as equipas empresariais questionam frequentemente até que ponto estas plataformas garantem uma verdadeira continuidade operacional, para além do acesso temporário ao webmail. Os utilizadores ainda conseguem coordenar agendas, trabalhar com caixas de correio partilhadas e regressar sem problemas ao Microsoft 365 após o incidente?
Opção 2: Locatário secundário do Microsoft 365
Algumas organizações utilizam um inquilino secundário do Microsoft 365 para fins de failover, por vezes numa região diferente, a fim de reduzir a exposição a interrupções regionais do serviço.
Isto pode melhorar a resiliência, especialmente se o inquilino secundário for concebido com administração, encaminhamento, políticas de acesso e procedimentos de recuperação separados. No entanto, a configuração inter-regional não elimina a dependência mais ampla do ecossistema da nuvem da Microsoft.
Há também uma questão mais subtil: se o inquilino secundário se autenticar através do mesmo fornecedor de identidade que o ambiente de produção (normalmente o mesmo inquilino do Entra ID), então um incidente ou uma interrupção de serviço relacionados com a identidade podem afetar ambos os ambientes ao mesmo tempo.
Opção 3: Servidor Exchange no local sincronizado com o Microsoft 365
Uma terceira abordagem consiste em manter um ambiente de servidor Exchange independente, sincronizado com o Microsoft 365.
Um exemplo é a utilização do servidor Exchange no local, sincronizado com o Microsoft 365.
Neste modelo:
- O Microsoft 365 continua a ser a principal plataforma operacional,
- O servidor Exchange é o ambiente de continuidade independente,
- A configuração de CB Exchange Server Sync para o BCP por Connecting Software garante a sincronização entre ambos.
A sincronização pode incluir:
- caixas de correio,
- calendários,
- contactos,
- pastas públicas,
- grupos de distribuição,
- e a sincronização do GAL.
Como este ambiente funciona no local com o seu próprio Active Directory, não precisa de partilhar um plano de identidade com o inquilino do Microsoft 365. Essa é uma distinção significativa em relação à opção 2: um ataque baseado na identidade contra o locatário na nuvem não se estende automaticamente ao ambiente Exchange local, o que tem impacto direto nos cenários de "falhas de identidade" e "bloqueio do locatário" acima referidos.
A implementação no local também significa que esta é a melhor opção se a sua organização precisar deste tipo de solução numa rede isolada (air-gapped). A versão no local pode ser utilizada em conjunto com díodos de dados para permitir esse cenário.
Por que razão algumas organizações preferem esta arquitetura
Para as organizações com requisitos mais exigentes em matéria de resiliência operacional, esta abordagem pode proporcionar:
- independência operacional em relação ao Microsoft 365,
- o já conhecido Outlook e a continuidade do calendário,
- maior controlo sobre as infraestruturas e a transição para o modo de emergência,
- suporte para ambientes regulamentados ou isolados,
- independência de identidade em relação ao inquilino de produção,
- e um risco reduzido de concentração de nuvens.
As organizações que também dependem do SharePoint e da colaboração em documentos podem, além disso, implementar estratégias de sincronização de documentos utilizando o Secure Sync for SharePoint da Connecting Software, para uma sincronização segura do SharePoint entre ambientes independentes ou isolados.
Opção 4: Google Workspace em modo de espera ativa
Uma quarta abordagem segue a mesma lógica da Opção 3, mas troca a plataforma de reserva: em vez do servidor Exchange no local, o ambiente independente é o Google Workspace, mantido continuamente sincronizado com o Microsoft 365 através de .
Isto proporciona às organizações uma opção de failover entre nuvens, sem qualquer dependência do ecossistema da Microsoft. Este aspeto pode ser relevante no que diz respeito a preocupações com o risco de concentração e é também muito apreciado por organizações que já executam parte das suas operações no Google Workspace. Mesmo no caso das que não o fazem, os utilizadores estão frequentemente familiarizados com o Google Workspace através da sua experiência pessoal, o que se revela útil durante o failover.
Iremos analisar esta arquitetura, o seu modelo de identidade e as suas vantagens e desvantagens específicas num artigo posterior.
Descubra como implementar um sistema de reserva ativa com o Google Workspace para a continuidade do negócio, por Connecting Software
Failover: Eliminar a janela de restauração
A abordagem tradicional de cópia de segurança e restauração implicava que, quando ocorria uma interrupção, era necessário que alguém executasse uma restauração antes de alguém poder voltar a trabalhar.
Isso apresenta dois problemas: a intervenção manual necessária e o tempo que a restauração demora, o qual é proporcional à quantidade de dados que é necessário restaurar. No caso de grandes inquilinos, não é invulgar que os RTO sejam medidos em dias.
Os serviços de continuidade de e-mail baseados na nuvem constituem uma solução alternativa para este problema, mas oferecem funcionalidades limitadas.
Um ambiente de standby sincronizado elimina essa etapa. Como se dispõe de uma cópia continuamente atualizada das caixas de correio, dos calendários e, eventualmente, dos documentos, basta indicar aos utilizadores que utilizem essa cópia para que possam continuar a trabalhar. Trata-se de uma transição para o modo de failover sem janela de restauração. Este ambiente está sempre ativo e atualizado, o que elimina a janela de restauração do cálculo do RTO.
Terá de ponderar esse custo em relação ao custo de os seus utilizadores não terem acesso ao e-mail, ao calendário e a outros conteúdos da caixa de correio, em termos de perda de produtividade, negócios não concretizados e custos de conformidade, quando aplicável.
Failback: Evitar a reconciliação manual
O failover é apenas metade da história. A certa altura, o ambiente principal volta a ficar operacional e os utilizadores têm de regressar a esse ambiente. Esta é a fase de failback, em que a verdadeira questão é saber o que acontece ao correio eletrónico enviado e recebido, às alterações no calendário e às edições de documentos efetuadas no ambiente de reserva, sem perder dados nem criar duplicados.
Será que os novos e-mails, as alterações no calendário e os documentos editados terão de ser reconciliados manualmente de volta ao ambiente de produção? Esta não é uma tarefa de que ninguém goste, porque é exatamente o tipo de passo manual que dá origem a erros, confusão entre versões e atrasos.
Com a sincronização bidirecional, essa reconciliação ocorre automaticamente: as alterações efetuadas durante a interrupção são transferidas de volta para o Microsoft 365 sem intervenção da equipa de TI, assim que o ambiente principal for restaurado. Os únicos dados em risco são aqueles que sofreram alterações durante o intervalo de sondagem de sincronização mais recente, ou seja, o intervalo entre uma passagem de sincronização e a seguinte. Se o intervalo for de cinco minutos, o RPO prático corresponde aproximadamente a cinco minutos de alterações, e não à duração total da interrupção. Pode programar a recuperação de falha de acordo com o seu intervalo de sondagem para reduzir o RPO a zero
Vale a pena referir que existe um compromisso no que diz respeito ao intervalo de sondagem: encurtá-lo diminui o RPO, mas; alongá-lo reduz a sobrecarga, mas alarga a janela potencial de perda de dados.
Não existe uma única arquitetura de e-mail “correta”.
A solução certa depende de:
- dependência operacional do Microsoft 365,
- tempo de inatividade aceitável,
- requisitos regulamentares,
- capacidades internas de TI,
- e os objetivos de resiliência operacional.
As organizações com necessidades moderadas podem ficar plenamente satisfeitas com serviços de continuidade baseados na nuvem.
As organizações que operam ao abrigo da NIS2, da DORA ou que têm requisitos rigorosos em matéria de resiliência podem necessitar de uma maior independência operacional e de capacidades de failover mais robustas.
Reflexões finais
O Microsoft 365 oferece uma excelente disponibilidade.
No entanto, a disponibilidade, por si só, não garante a resiliência operacional.
As organizações reconhecem cada vez mais que a continuidade do serviço de e-mail, o acesso ao calendário e a continuidade da colaboração são essenciais para manter as operações durante situações de perturbação.
Porque, durante uma falha de energia real, a questão mais importante não é:
“Podemos recuperar mais tarde?”
É:
"Podemos continuar a funcionar?"
Descubra como implementar um sistema de reserva ativa com o Google Workspace para a continuidade do negócio, por Connecting Software
Mais informações sobre Continuidade de Negócios e Recuperação em caso de catástrofe
O backup não é sinónimo de continuidade: recuperação «a quente» vs. «a frio» para Exchange, SharePoint e Microsoft 365
A armadilha da simplicidade: por que o e-mail na nuvem deve ser incluído em todas as conversas sobre BCP
A ascensão das nuvens soberanas: Questionar o controlo de dados na era da nuvem
Sobre o Autor
Por Ana Neto, consultor técnico em Connecting Software.
"Sou engenheiro de software desde 1997, com uma paixão mais recente pela escrita e por falar em público. Tem alguma pergunta ou comentário sobre este artigo? Gostaria muito de receber o seu feedback, deixe um comentário abaixo!"
