O Google Workspace como opção de continuidade de negócios em caso de interrupções do Microsoft 365

Quando o Microsoft 365 fica indisponível, a primeira questão que se coloca é como fazer com que as pessoas voltem a trabalhar. Trata-se de um problema prático de continuidade de negócios, e o Google Workspace pode ser uma resposta prática.

Para a maioria das empresas, o Microsoft 365 é a infraestrutura que mantém a comunicação, a coordenação e o próprio negócio a funcionar. Quando ocorre uma falha no Microsoft 365, começam a surgir inúmeras perguntas:

As pessoas podem enviar e receber e-mails?

Eles conseguem ver os seus calendários?

A direção continua a ter acesso ao e-mail e à agenda para gerir a resposta a situações de crise?

As equipas que lidam diretamente com os clientes ainda podem comunicar com o exterior?

Os membros da equipa podem aceder aos ficheiros? Ou têm de esperar que a cópia de segurança seja restaurada primeiro?

Estas questões são mais importantes do que nunca, agora que a regulamentação está a tornar mais exigentes os requisitos em matéria de resiliência operacional e continuidade das operações.

Quer estejas a trabalhar para SOC 2 controlos de disponibilidade, navegação NIS2 requisitos de resiliência operacional ou o alinhamento com quadros como NIST CSF 2.0 e ISO 22301, a dependência do Microsoft 365 deve ser avaliada de forma explícita. Basear-se exclusivamente no tempo de disponibilidade da Microsoft é cada vez menos justificável como estratégia de continuidade de negócios.

Isto levou as equipas técnicas a considerarem cada vez mais as opções de «hot standby», em particular o Google Workspace. Não como substituto do Microsoft 365, nem como uma ferramenta de cópia de segurança tradicional, mas sim como um segundo ambiente na nuvem, independente, capaz de manter o e-mail, os calendários, os ficheiros e as comunicações críticas disponíveis durante uma interrupção do Microsoft 365.

Esta é uma abordagem totalmente diferente da utilização de uma plataforma de cópia de segurança do Microsoft 365, como a Veeam, a Druva ou outra solução de recuperação, que pode ajudar a recuperar caixas de correio, ficheiros e outros dados após um incidente. Por muito boas que essas plataformas possam ser, se milhares de utilizadores precisarem de ter acesso a uma caixa de entrada e a um calendário funcionais nas próximas duas horas, o backup por si só não será suficiente.

Google Workspace can indeed support business continuity during a Microsoft 365 outage, especially for email, calendar, appointments, and crisis communication. Microsoft 365 remains the primary platform, while Google Workspace provides an independent continuity environment. But this kind of cross-cloud business continuity model requires the right architecture and planning: identity, mail routing, synchronization, security, user access, and failback all need to be designed and tested before the outage happens, not during it.

Regulamentos e quadros normativos como a NIS2, a DORA e o Quadro de Cibersegurança do NIST elevam os padrões em matéria de prevenção e gestão de perturbações nos serviços essenciais e nas funções críticas ou importantes, embora o seu âmbito de aplicação, terminologia e efeito jurídico sejam diferentes.

DORA define uma “função crítica ou importante” com base no impacto significativo que a sua interrupção poderia ter no desempenho financeiro, na continuidade do serviço ou nas obrigações regulamentares, enquanto NIS2 exige a adoção de medidas de continuidade de atividade e de gestão de crises no âmbito da gestão de riscos de cibersegurança. Por outro lado, quadros como NIST CSF abordar os resultados associados através das suas funções de «Governar», «Responder» e «Recuperar», incluindo a resposta a incidentes, a restauração e a comunicação.

Mesmo que os termos utilizados não sejam consistentes, a questão prática mantém-se:

Que serviços e dependências são essenciais na vossa organização?

Uma forma prática de traduzir os requisitos regulamentares de alto nível em planos de continuidade é realizar um avaliação das funções críticas contra as principais dependências da nuvem. A questão fundamental é simples:

Se este serviço na nuvem ficar indisponível durante X horas, estaremos a ultrapassar algum limite legal, operacional, de atendimento ao cliente, de segurança ou financeiro?

No caso do Microsoft 365, essa avaliação deve incluir:

• RTO e RPO: how quickly services need to resume, and how much data loss is acceptable
• Raio de explosão: quais as funções, equipas, clientes ou processos que são afetados
• Risco de concentração: isso depende do prestador de serviços, do inquilino, da região ou da camada de identidade
• Interdependências: identidade, gestão de chaves, acesso à rede, integrações e vias de comunicação externas

Se analisarmos o Microsoft 365 sob essa perspetiva, o resultado raramente é tranquilizador. O e-mail, a identidade, os calendários e o acesso a ficheiros revelam-se frequentemente dependências operacionais que exigem um planeamento explícito de continuidade, e não apenas cópias de segurança e restauração.

Os regulamentos e as normas não impõem uma arquitetura de continuidade específica nem fornecedores concretos. No entanto, os seus requisitos podem influenciar diretamente a sua conceção:

• ISO 22301 requer objetivos de recuperação definidos, procedimentos de continuidade documentados e testes regulares. Nos casos em que o potencial impacto nos negócios o justifique, poderá ser adequado recorrer a um sistema de reserva ativa para o Microsoft 365.
• Se a sua organização for uma entidade financeira, DORA requires you to assess information and communication technology (ICT) concentration risk and provider substitutability. It also requires documented exit strategies for ICT services that support critical or important functions. Depending on the risk assessment, this may support an alternative-provider or multi-vendor design, but DORA does not mandate one specific architecture.
• NIS2 aplica a mesma lógica a um conjunto mais alargado de entidades essenciais e importantes e inclui explicitamente a continuidade das atividades, a recuperação em caso de catástrofe, a gestão de crises e a segurança da cadeia de abastecimento nas suas medidas de gestão de riscos de cibersegurança. Isto torna as principais dependências em relação à nuvem e aos prestadores de serviços relevantes para a avaliação de riscos da organização.
• Nos EUA, as funções «Governar», «Responder» e «Recuperar» de NIST CSF 2.0 exigem planos de recuperação comprovados e uma gestão de riscos na cadeia de abastecimento, o que suscita a mesma questão: será que as funções críticas podem continuar a funcionar caso um fornecedor essencial deixe de estar disponível?

A questão arquitetónica consiste em saber como garantir a continuidade das funções críticas quando o fornecedor principal não estiver disponível. Se uma falha do Microsoft 365 puder interromper essas funções, a organização poderá necessitar de um ambiente alternativo que já esteja provisionado, acessível e testado. Esse risco é frequentemente maior do que parece à primeira vista, uma vez que o Microsoft 365 não constitui uma única dependência, mas sim várias dependências interligadas.

O Microsoft 365 reúne quatro aspetos que, individualmente, justificariam, cada um por si só, um plano de continuidade:

• Comunicação (Exchange / Teams). Na prática, a interrupção do encaminhamento de e-mails ou do chat deixa a empresa fora de serviço, mesmo que, tecnicamente, todos os ficheiros estejam seguros.
• Calendário (Exchange / Teams). A gestão de horários e o acesso às reuniões funcionam da mesma forma que o correio eletrónico, o que resulta numa falta de coordenação interna e na perda de reuniões externas, mesmo que, tecnicamente, nada se tenha "perdido"."
• Documentos (SharePoint / OneDrive). Os ficheiros têm de permanecer acessíveis, não apenas recuperáveis.
• Identidade (Entra ID / Azure AD). Se a camada de autenticação deixar de funcionar, não importa o que mais esteja a funcionar: ninguém consegue iniciar sessão em nada, incluindo aplicações de terceiros que dependem do mesmo fornecedor de identidade.

A conclusão preocupante nesta fase é, normalmente, que o software de cópia de segurança padrão apenas protege o terceiro elemento, e só após um período de restauração que pode demorar entre 24 e 48 horas. Entretanto, não existe nenhum local alternativo onde as pessoas possam realmente trabalhar.

A solução que vem imediatamente à mente para esta situação poderá ser um tenant secundário da Microsoft. Infelizmente, esta solução não se sustenta quando analisada com mais detalhe, uma vez que uma falha poderá afetar ambos os tenants em simultâneo, mesmo que estejam provisionados em regiões diferentes do Microsoft 365 ou do Azure. A hospedagem regional não implica domínios de falha independentes, uma vez que o Entra ID e os serviços principais do Microsoft 365 continuam a partilhar a mesma infraestrutura global subjacente.

Um segundo inquilino satisfaz, no papel, o requisito de "termos um inquilino de reserva", mas não garante independência suficiente.

É isso que leva a procurar um hiperescalador distinto. Não porque o Google Workspace seja, por si só, mais fiável, mas porque proporciona uma infraestrutura e uma pilha de identidades operacionalmente separadas. Essa separação pode ajudar a dar resposta às preocupações relativas ao risco de concentração nas TIC e à continuidade das atividades, refletidas na DORA e na NIS2.