Incidente ConnectWise Cloud Backup: o que MSPs devem aprender sobre permissões e risco em cadeia

Quando uma integração de backup se transforma em risco de identidade

Provedores de serviços gerenciados (MSPs) dependem de integrações para oferecer backup, segurança e administração de maneira padronizada a diversos clientes. Essas integrações economizam tempo, mas trazem uma responsabilidade: entender exatamente a quais recursos cada aplicação de fornecedor pode acessar e o que acontece quando sua identidade é comprometida.

O incidente envolvendo o ConnectWise Cloud Backup, anteriormente SkyKick, é um exemplo atual. Em 21 de outubro, a ConnectWise informou ter identificado acesso não autorizado a credenciais de aplicações associadas ao serviço e anunciou o início da restauração dos serviços em fases controladas, depois de medidas de contenção e validação de segurança. A empresa declarou que os arquivos de backup armazenados permaneciam criptografados, isolados e preservados, sem indícios de comprometimento desses arquivos. Essa declaração não determina se ambientes Microsoft 365 ativos de clientes individuais foram afetados.

A diferença é essencial. Integridade dos arquivos de backup, segurança do tenant Microsoft 365 e capacidade de executar uma restauração são três questões distintas. Uma solução pode preservar suas cópias enquanto o acesso ao serviço está temporariamente interrompido e cada tenant ainda exige investigação.

O que os pesquisadores observaram

Em 15 de outubro, investigadores das empresas Huntress e Todyl identificaram autenticações não autorizadas no Microsoft 365 utilizando a identidade legítima do aplicativo ConnectWise Cloud Backup. A aplicação já possuía permissões previamente consentidas nos ambientes dos clientes; o invasor não precisava autenticar-se como um funcionário comum para utilizar esse acesso em nível de aplicativo.

A Huntress havia confirmado autenticações não autorizadas em 162 tenants até 16 de outubro, às 19h UTC. Esse era um número observado naquele momento, não uma contagem definitiva de clientes afetados. A Huntress também documentou alterações posteriores ao acesso envolvendo outra identidade do ConnectWise Cloud Management em um pequeno número de ambientes, inclusive a adição de credenciais em outras aplicações. Já a Todyl informou não ter encontrado essas alterações de diretório nos tenants por ela analisados. São amostras diferentes e seus resultados não devem ser generalizados.

A principal lição não está em um número específico de tenants. Quando um aplicativo multitenant com permissões elevadas é confiável para muitos clientes, um problema com a credencial do fornecedor pode criar exposição em várias organizações.

Por que as permissões importam mais do que a reputação do fornecedor

Ferramentas de backup frequentemente precisam de acesso abrangente a caixas de correio, OneDrive, SharePoint e outras cargas de trabalho para proteger os dados. No Microsoft Entra ID, um service principal representa essa integração no tenant do cliente. Permissões de aplicativo podem autorizar o acesso sem que exista uma sessão interativa de usuário.

Por isso, orientações tradicionais como “redefina as senhas dos usuários” ou “habilite MFA para todos os funcionários” continuam importantes, mas não são suficientes em incidentes envolvendo identidades de aplicações. Uma carga de trabalho pode autenticar-se com suas próprias credenciais, e o alcance desse acesso depende das permissões concedidas anteriormente pelos administradores.

Para MSPs, uma revisão deve responder:

• Quais aplicações de terceiros e aplicações internas existem em cada tenant?
• Quem é o responsável por cada integração e a quais recursos ela realmente precisa acessar?
• Quais permissões de aplicativo e delegadas foram concedidas, e por quem?
• Funções privilegiadas, segredos, certificados, proprietários e consentimentos são revisados?
• Como detectar autenticações incomuns de service principals ou mudanças de credenciais?
• O que acontece com a proteção dos clientes se uma integração do fornecedor precisar ser desativada?

O problema do risco em cadeia para MSPs e MSSPs

Um MSP pode administrar dezenas ou centenas de tenants independentes, mas seu modelo operacional ainda pode depender de poucas plataformas comuns, aplicações de fornecedores ou identidades administrativas. Isso representa concentração de risco operacional e de segurança.

Se um invasor conseguir acesso por meio de uma integração compartilhada, o raio de impacto potencial poderá ultrapassar um único cliente. Uma organização também pode ser afetada por uma interrupção preventiva adotada pelo fornecedor, mesmo quando não há evidências de comprometimento de seu próprio tenant.

É importante diferenciar isolamento entre tenants de dependência de um plano de controle compartilhado. A separação dos clientes cria barreiras importantes, mas não elimina os riscos de uma identidade de fornecedor comum, de contas administrativas com privilégios excessivos ou de um serviço central indisponível.

Para MSSPs, o episódio também reforça a necessidade de monitorar service principals, mudanças de permissões e identidades de aplicações na nuvem — não apenas endpoints e logins humanos.

Checklist prático de resposta para provedores de serviços gerenciados

MSPs que utilizam serviços ConnectWise ou integrações legadas SkyKick abrangidas pelo incidente devem seguir o guia técnico oficial e atualizado do fornecedor, coordenar as ações com os administradores autorizados dos clientes e a equipe de resposta a incidentes, e preservar evidências antes de alterações amplas sempre que isso não atrasar a contenção urgente. Este checklist editorial não substitui as instruções específicas do incidente.

1. Inventarie todos os tenants. Inclua o ambiente Microsoft 365 do próprio MSP, cada cliente gerenciado e integrações legadas inativas. Identifique as aplicações pelo Application ID, não apenas pelo nome exibido.
2. Confirme a contenção. Verifique se as aplicações empresariais afetadas estão desativadas conforme a orientação oficial, registre o estado local e não as reative até que a ConnectWise publique instruções formais de reconexão.
3. Preserve as evidências. Exporte os logs disponíveis de autenticação e auditoria do Entra, a auditoria do Microsoft 365 e os alertas relevantes. Registre horários de coleta e lacunas de retenção.
4. Investigue identidades de aplicações. Revise autenticações de service principals, segredos, certificados, novas permissões, proprietários, funções privilegiadas e mudanças de consentimento. Desativar a aplicação original não remove automaticamente acessos criados em outras identidades.
5. Verifique atividades posteriores. Investigue encaminhamentos de e-mail, regras de caixa de entrada, delegações e atividades pertinentes em SharePoint, OneDrive e Teams, conforme os registros disponíveis.
6. Meça a lacuna de proteção. Identifique o último backup concluído e quais restaurações estão disponíveis. Documente o impacto e discuta alternativas autorizadas com o cliente.
7. Comunique por tenant. Separe achados confirmados, indicadores que exigem investigação e pontos sem registros suficientes. Designe um responsável para cada cliente e acompanhe as pendências.

O guia oficial da ConnectWise identifica a aplicação Cloud Backup pelo ID 506e08f9-6e9a-4da4-942b-a099a03644ae e relaciona outros IDs do Cloud Management e procedimentos de investigação. Uma autenticação suspeita ou correspondência com IP divulgado merece análise, mas não comprova, isoladamente, que houve vazamento de dados ou comprometimento do tenant.

A disponibilidade do backup também é uma questão de continuidade

Durante a contenção, a ConnectWise suspendeu serviços afetados, interrompendo jobs agendados, acesso aos arquivos de backup e restaurações. Em 21 de outubro, o fornecedor anunciou um processo de retomada por fases, sem afirmar que todas as funcionalidades já estivessem disponíveis.

Para os clientes de MSPs, isso levanta questões que vão além da segurança: qual a data do ponto de recuperação mais recente? Quais são os RTOs e RPOs contratados? Existe um caminho de recuperação alternativo e aprovado caso o plano de controle principal fique indisponível? Quem comunica as limitações ao cliente?

Não é realista pressupor que toda empresa precise contratar dois fornecedores completos de backup. No entanto, cada MSP deve documentar dependências críticas e avaliar redundância, opções de recuperação e impacto operacional de acordo com o risco do cliente e os compromissos contratuais.

Sete medidas preventivas que merecem revisão agora

• Menor privilégio: conceder somente as permissões necessárias e revisá-las conforme as integrações mudam.
• Governança de aplicações: manter inventário de enterprise applications, service principals, proprietários, credenciais e consentimentos.
• Segmentação de clientes: limitar privilégios entre tenants e evitar acessos administrativos compartilhados desnecessários.
• Monitoramento e detecção: coletar autenticações de aplicações e alertas sobre origens, credenciais, consentimentos e privilégios incomuns.
• Logs preparados para incidentes: conhecer os prazos de retenção e preservar rapidamente as evidências críticas.
• Validação de recuperação: testar restaurações e documentar o que permanece possível se a plataforma de gerenciamento em nuvem ficar indisponível.
• Gestão de risco de fornecedores: revisar acessos de terceiros, canais de aviso de incidentes, procedimentos de retomada e responsabilidades contratuais.

Esses controles não eliminam o risco da cadeia de fornecedores. Eles ajudam a identificá-lo mais cedo, reduzir o raio de impacto e responder com evidências, em vez de suposições.

O que isso significa para o modelo de negócios do MSP

O incidente reforça que backup gerenciado não é apenas armazenamento. Os clientes dependem do MSP para saber se os jobs são concluídos, se o acesso está devidamente protegido, se a recuperação permanece possível e como incidentes serão tratados.

Para MSPs e MSSPs, uma oferta mais robusta combina operações de backup, governança de identidades, monitoramento, procedimentos de recuperação testados, SLAs claros e comunicação transparente. Um painel que aparece como “verde” não substitui a comprovação de recuperação.

Na perspectiva da SafetyOnCloud, uma estratégia de backup deve ser avaliada pela sua capacidade de apoiar a recuperação — e não somente pela existência das cópias armazenadas. Cada provedor precisa verificar suas configurações, dependências tecnológicas e exigências dos clientes antes de prometer controles ou tempos específicos.

Conclusão: confie na integração, mas verifique seus limites

O incidente ConnectWise Cloud Backup não demonstra que todos os fornecedores de backup ou todos os tenants de clientes foram comprometidos. Ele evidencia que identidades de aplicações, permissões de terceiros e dependências de serviços compartilhados merecem tanta atenção quanto endpoints, senhas e políticas de retenção.

Para qualquer MSP, o próximo passo útil é uma revisão tenant por tenant: inventariar integrações, conferir permissões, preservar os logs corretos, confirmar pontos de restauração e ensaiar a resposta à indisponibilidade de um fornecedor.

Para um MSP, a segurança do backup não consiste apenas em proteger os dados do cliente. Consiste também em controlar quem consegue acessá-los — e demonstrar como recuperá-los.