A migração para o SaaS trouxe agilidade operacional, mas também criou uma das lacunas de segurança mais frequentes (e subestimadas) nos projetos de nuvem: a crença de que “se está na nuvem, está salvo”.
Nesta série técnica de quatro artigos, analisaremos o Veeam Data Cloud (VDC) M365 sob a ótica da arquitetura e operação. O objetivo é detalhar como o modelo de Backup as a Service (BaaS) transfere a responsabilidade pelo provisionamento de storage e manutenção de servidores para o provedor, permitindo que a equipe de TI substitua a gestão de patches e hardware pela governança da retenção e integridade do dado.
Mas, antes de nos aprofundarmos nas features ou na arquitetura da solução, precisamos alinhar os fundamentos do modelo de nuvem. Neste primeiro capítulo, vamos analisar o Modelo de Responsabilidade Compartilhada, clarificando os limites de atuação do provedor e do cliente. O objetivo é entender, sem ruídos, onde terminam os deveres da Microsoft e onde começam as suas obrigações de proteção para garantir a continuidade do negócio.
Disponibilidade vs. Proteção de Dados
No ecossistema corporativo atual, existe uma confusão perigosa entre a Disponibilidade do Serviço e a Proteção de Dados. Muitos gestores e até profissionais técnicos assumem, erroneamente, que migrar para o Microsoft 365 significa terceirizar a responsabilidade pela integridade dos dados.
A realidade contratual, no entanto, é bem diferente. A Microsoft garante a infraestrutura, o acesso ao SharePoint, Exchange Online, OneDrive e Teams, mas a responsabilidade pelos dados que trafegam nessa infraestrutura permanece 100% do cliente.
Esse conceito é formalizado no Modelo de Responsabilidade Compartilhada. Ao analisar o SLA do Microsoft 365, fica claro que o foco é a redundância geográfica e a disponibilidade do serviço, protegendo contra falhas de hardware ou desastres naturais que afetem seus Data Centers. O que o SLA não cobre, e a Microsoft deixa explícito, é a corrupção de dados causada por erro humano, exclusão maliciosa (insider threats) e ataques de ransomware.
A falsa sensação de segurança muitas vezes vem de ferramentas nativas como a Lixeira ou o Histórico de Versão do OneDrive. Embora úteis para correções rápidas de curto prazo, essas funcionalidades não constituem uma estratégia de Proteção de Dados. Elas não possuem isolamento real (Air Gap), não oferecem imutabilidade garantida contra criptografia e, crucialmente, são réplicas síncronas.
Se um arquivo é corrompido logicamente, essa corrupção é replicada instantaneamente para todas as cópias geográficas que a Microsoft mantém. Sem um backup externo desconectado, a redundância da nuvem apenas garante que você tenha cópias corrompidas altamente disponíveis.
Para tangibilizar esse risco, pense no cenário comum de um seguro automotivo. A maioria contrata a proteção contra roubo, colisão e danos aos vidros, criando uma sensação imediata de segurança. Porém, muitos “esquecem” ou ignoram as coberturas para desastres naturais (enchentes/granizo) e, principalmente, o carro reserva.
Quando o imprevisto acontece, o segurado descobre da pior forma que, embora tenha uma proteção parcial, ela não resolve seu problema imediato: ele ficou a pé. O Microsoft 365 atua de forma similar. O SLA da Microsoft é a cobertura básica que protege a infraestrutura (o “carro”), mas se você sofrer um sinistro de dados (Ransomware) ou precisar de agilidade para continuar operando (Continuidade de Negócios), descobrirá que esses itens não constam na cobertura.
A Ilusão das “Gambiarras” Administrativas
Aprofundando nas limitações nativas, encontramos duas “manobras” operacionais que mascaram o risco real: o Litigation Hold e a conversão de contas para Caixas Compartilhadas.
Embora o Litigation Hold possa reter dados indefinidamente, ele foi desenhado estritamente para eDiscovery (evidência legal), e não para recuperação de desastres (DR). Tentar utilizá-lo como ferramenta de restauração operacional é um erro de arquitetura. Se você precisar recuperar a caixa de um usuário deletada há seis meses, receberá um dump massivo de e-mails na pasta Discovery Search, sem a estrutura original de pastas e subpastas. O dado bruto existe, mas a inteligência da informação foi destruída, inviabilizando o RTO em um cenário de produção.
Ainda mais crítica é a prática de converter contas em Caixas Compartilhadas. Tecnicamente, a Caixa Compartilhada continua sendo um objeto de produção “vivo” dentro do mesmo fault domain do tenant. Ela não possui imutabilidade e está exposta ao risco de deleção acidental ou intencional. Quando um usuário com permissão de acesso deleta acidentalmente uma pasta crítica ou um e-mail, esse item frequentemente é movido para a Lixeira do próprio usuário (Delegate Wastebasket), e não para a da caixa compartilhada. Sem um backup externo indexado, rastrear e recuperar esses dados torna-se trabalhoso e demorado.
Confiar nessa estratégia significa assumir que nenhum acesso privilegiado, seja legítimo ou comprometido, jamais executará um Hard Delete ou uma modificação destrutiva que será replicada instantaneamente.
O Vetor de Ataque Moderno: Propagação e Roubo de Token
Muitas organizações acreditam estar protegidas simplesmente porque seus arquivos estão no SharePoint ou OneDrive. Essa visão ignora a mecânica fundamental da nuvem: a propagação síncrona. O agente de sincronização do OneDrive, instalado nos endpoints, age como uma ponte direta entre o ambiente local e a nuvem. Se um payload de ransomware é executado na máquina de um usuário, ele criptografa os arquivos locais e o agente do OneDrive, cumprindo sua função, sincroniza imediatamente para o tenant da Microsoft.
Um dos argumentos comuns de defesa é: “Basta reverter para a versão anterior”. Embora o versionamento seja útil para erros pontuais, ele não é imutável. Em ataques sofisticados modernos, os atacantes não focam apenas no arquivo, eles comprometem a identidade.
Através de ataques de Illicit Consent Grant (onde o usuário concede permissão a um App malicioso via OAuth) ou roubo de Tokens de Sessão, o atacante ganha acesso aos dados sem precisar de credenciais ou MFA. Com esse acesso via API, scripts automatizados podem exfiltrar dados, criptografar bibliotecas inteiras do SharePoint e, crucialmente, excluir o histórico de versões ou alterar as políticas de retenção antes do ataque, inutilizando a rede de segurança nativa da Microsoft.
Cenário Prático
Vamos simular um cenário real de Insider Threat, onde uma conta de serviço comprometida executa um Hard Delete em uma biblioteca crítica do SharePoint Financeiro (200 GB) e na caixa postal do CFO (50 GB).
Ao depender exclusivamente das ferramentas nativas, o administrador se vê forçado a abrir um chamado de suporte crítico (Sev-A) na Microsoft para solicitar um Site Collection Rollback. O problema é que essa operação é uma “medida de força bruta”. Além do tempo de espera pelo suporte (SLA de resposta, não de resolução), o rollback é destrutivo: ele reverte o site inteiro para um ponto no tempo, eliminando todos os dados legítimos criados ou modificados por outros departamentos entre o momento do ataque e a execução da restauração.
Simultaneamente, para recuperar o e-mail do CFO, a equipe de TI precisa recorrer ao eDiscovery. O que deveria ser uma restauração simples torna-se uma maratona. A exportação de 50 GB sofre com o Throttling nativo de saída, gerando arquivos PST que precisam ser baixados e, subsequentemente, reimportados. Nesse fluxo, o RTO (Recovery Time Objective) que deveria ser de minutos estende-se para dias.
Ao utilizar o Veeam Data Cloud, o fluxo de recuperação torna-se independente do suporte do provedor. O administrador executa restores granulares diretamente via console. Como a solução roda dentro do próprio Azure, o tráfego de dados é interno, eliminando gargalos de internet pública durante o restore, e a operação é não-destrutiva, preservando a produção corrente enquanto os dados afetados são reintroduzidos.
Conclusão
No fim das contas, o Modelo de Responsabilidade Compartilhada não é apenas uma cláusula jurídica para isentar a Microsoft de culpa; é um aviso técnico explícito. A Microsoft garante a disponibilidade da plataforma (SLA de Infraestrutura), mas a disponibilidade, integridade e conformidade dos dados (SLA de Negócio) são responsabilidade exclusiva do cliente.
Continuar operando sem uma solução de Proteção de Dados dedicada para o Microsoft 365 não é uma estratégia de “nuvem moderna”, é uma aposta de risco. Você está apostando que erros humanos, bugs de sincronização e ataques de ransomware nunca acontecerão no seu tenant. E, pensando em Proteção de Dados, a esperança não é uma tática de recuperação de desastres válida.
No próximo artigo desta série, vamos explorar como o conceito de Backup as a Service (BaaS) resolve essa equação, entregando proteção total com infraestrutura zero, eliminando a necessidade de manter, atualizar e proteger um servidor de backup dedicado, para que você foque apenas na gestão da disponibilidade.
Reflexão
Antes de assumir que o “check” verde no painel do Microsoft 365 significa segurança, faça as seguintes reflexões para o seu ambiente atual:
– Se o RH ou o Jurídico baterem na sua mesa hoje pedindo o histórico de e-mails de um gerente que foi desligado há 6 meses (cujo usuário já foi deletado do AD), você consegue restaurar esses dados? Ou eles desapareceram silenciosamente assim que o prazo padrão de 30/90 dias da Lixeira expirou?
– Seu telefone toca, sexta-feira no final do expediente. É a assistente do Diretor Financeiro. Ela avisa que pastas críticas do Balanço de 2024 “sumiram” do SharePoint e ela precisa disso para a reunião de segunda-feira cedo. Ela é categórica: “Não temos tempo para refazer pelo ERP”. Nesse momento de pressão, qual é a sua reação? A tranquilidade de responder “Já estou restaurando, me dê 10 minutos” ou o suor frio de ter que explicar o “Veja bem, a Microsoft só garante a lixeira por 93 dias…”?
Cuca Fresca IT 
Leave a comment