O modelo de responsabilidade compartilhada na nuvem é um dos conceitos mais importantes em segurança na nuvem e um dos mais frequentemente mal interpretados. Esse equívoco segue um padrão específico: as organizações presumem que a migração para a nuvem transfere mais responsabilidade de segurança para o provedor do que realmente acontece. Essa suposição gera brechas de segurança que os invasores exploram ativamente.
A Gartner estima que, até 2026, 99% das falhas de segurança na nuvem serão de responsabilidade do cliente, principalmente devido a configurações incorretas. Esse número não é uma crítica à segurança na nuvem. É uma constatação sobre onde se situa o limite da responsabilidade. A infraestrutura do provedor de nuvem é, em geral, bem protegida. As configurações incorretas, os buckets de armazenamento expostos, as funções de IAM com permissões excessivas e as VMs sem patches estão quase todas do lado do cliente.
Este guia esclarece exatamente quais são as responsabilidades dos provedores de nuvem, quais são as responsabilidades dos clientes e de seus MSPs, e como os limites variam entre os diferentes modelos de serviços em nuvem. A plataforma da Kaseya abrange o lado do cliente no modelo de responsabilidade compartilhada para mais de 50.000 MSPs e equipes de TI em todo o mundo.
O princípio fundamental
Todos os principais provedores de nuvem — AWS, Microsoft Azure e Google Cloud — publicam um modelo de responsabilidade compartilhada que define a divisão de tarefas em matéria de segurança. O princípio é o mesmo para todos eles: o provedor é responsável pela segurança da nuvem; o cliente é responsável pela segurança do que está na nuvem.
As responsabilidades do provedor abrangem a infraestrutura física (centros de dados, servidores, hardware de rede), a camada de hipervisor, a malha de rede e a disponibilidade e confiabilidade dos managed services oferece. Tudo o que um cliente implanta no ambiente de nuvem — sistemas operacionais, aplicativos, dados, configuração de identidade e controles de acesso à rede — é de responsabilidade do cliente ou de seu MSP.
A implicação prática: um ambiente em nuvem não é seguro por padrão. Ele é seguro na medida em que o cliente o configura corretamente. Uma instância EC2 com um sistema operacional sem patches é problema do cliente. Um bucket S3 com acesso público habilitado é problema do cliente. Uma função IAM com permissões de administrador atribuída a um serviço que precisa apenas de acesso somente leitura é problema do cliente. O provedor de nuvem não identificará nem corrigirá nenhuma dessas situações.
Como a responsabilidade varia de acordo com o modelo de serviço
Os limites exatos variam de acordo com o modelo de serviço em nuvem utilizado. Quanto mais alto na pilha o serviço estiver, mais responsabilidades o provedor assume e menos o cliente precisa gerenciar no nível da infraestrutura. No entanto, os dados, a identidade e o controle de acesso continuam sendo de responsabilidade do cliente em todos os modelos.
Infraestrutura como Serviço (IaaS)
O provedor gerencia a infraestrutura física e a camada de virtualização. O cliente gerencia tudo o que está acima: sistema operacional, middleware, ambiente de execução, aplicativos, dados e configuração de rede. Esse é o modelo utilizado para máquinas virtuais hospedadas na nuvem, como AWS EC2, Azure VMs e Google Compute Engine.
O modelo IaaS é aquele em que o cliente assume a maior responsabilidade entre todos os modelos de serviço. Um MSP que gerencia o ambiente IaaS de um cliente é responsável por toda a pilha de segurança acima do hipervisor. Isso inclui a aplicação de patches no sistema operacional e nas aplicações, regras de firewall e configuração de grupos de segurança, criptografia em repouso e em trânsito, configuração de IAM e registro de logs. Nada disso é tratado pelo provedor.
Plataforma como Serviço (PaaS)
O provedor também gerencia o sistema operacional, o middleware e o ambiente de execução. O cliente é responsável pelas aplicações e pelos dados. Os serviços de banco de dados gerenciados, como o Azure SQL Database e o AWS RDS, bem como as plataformas de hospedagem de aplicações, operam segundo esse modelo.
O PaaS reduz significativamente a carga de trabalho de gerenciamento. Os clientes não precisam aplicar patches no sistema operacional subjacente nem gerenciar o mecanismo de banco de dados. No entanto, eles continuam sendo responsáveis pela segurança dos dados, pelo controle de acesso, pela configuração no nível da aplicação e pela segurança do código da aplicação.
Software como Serviço (SaaS)
O provedor gerencia toda a pilha, desde a infraestrutura até a aplicação. O cliente é responsável pelos dados, pelo gerenciamento de acesso e pela configuração dos controles de segurança da aplicação.
O Microsoft 365, o Google Workspace e o Salesforce são todos serviços SaaS. O equívoco mais comum aqui é o seguinte: como o provedor gerencia o aplicativo, os clientes presumem que ele também protege os dados. Mas não é assim. A Microsoft é responsável pela disponibilidade e confiabilidade da plataforma do Microsoft 365. Os dados dentro de cada locatário, bem como sua recuperabilidade, são de responsabilidade do cliente.
Uma organização que perca dados do Microsoft 365 devido a uma exclusão em massa acidental, a um administrador mal-intencionado ou a um ransomware que criptografe arquivos sincronizados no OneDrive não pode contar com as ferramentas de retenção da Microsoft para recuperá-los. Essas ferramentas são voltadas para a conformidade, com períodos de retenção curtos, e não foram projetadas para a recuperação operacional em um momento específico.
As lacunas mais comuns na responsabilidade compartilhada
Compreender o princípio é uma coisa. As lacunas que surgem em ambientes reais são específicas e previsíveis. Essas cinco lacunas aparecem em quase todos os ambientes de nuvem que não foram formalmente avaliados.
Backup de SaaS. O equívoco mais comum em todos os modelos de serviço. A Microsoft e o Google não realizam backup dos dados do Microsoft 365 ou do Google Workspace de forma a garantir a recuperação operacional em caso de exclusão acidental, ransomware ou comprometimento da conta. SaaS Protection Datto SaaS Protection essa questão diretamente, realizando backup dos dados do Microsoft 365 e do Google Workspace três vezes ao dia em um repositório independente e imutável na Datto Cloud, com retenção ilimitada e restauração granular.
Configuração do IAM. A gestão de identidades e acessos — ou seja, quem possui quais permissões nos ambientes de nuvem — é sempre de responsabilidade do cliente, independentemente do modelo de serviço. A configuração incorreta do IAM é a principal causa de violações de dados na nuvem. Um pequeno MSP que assuma o ambiente AWS de um novo cliente normalmente encontrará funções do IAM com permissões muito mais amplas do que os serviços que elas abrangem. Corrigir isso é um trabalho pouco glamoroso e demorado, mas necessário em quase todos os ambientes.
Aplicação de patches no sistema operacional e nos aplicativos para cargas de trabalho de IaaS. As máquinas virtuais na nuvem não se atualizam automaticamente. Uma instância do AWS EC2 ou uma máquina virtual do Azure que execute um sistema operacional sem patches está tão vulnerável quanto um servidor local na mesma situação. O VSA e o Datto RMM estendem o gerenciamento automatizado de patches aos terminais hospedados na nuvem, utilizando a mesma implantação baseada em agente e a automação orientada por políticas empregadas para servidores locais.
Configuração de segurança de rede. Grupos de segurança, listas de controle de acesso à rede e configuração de VPC/VNet são de responsabilidade do cliente em ambientes IaaS. Grupos de segurança que permitem acesso de entrada irrestrito nas portas 22 ou 3389 são frequentemente encontrados em avaliações de ambientes em nuvem e estão sempre presentes porque foram deixados abertos para fins de solução de problemas e nunca foram fechados. Essas falhas são fáceis de corrigir e devem ser tratadas com alta prioridade.
Registro e monitoramento. Os provedores de nuvem disponibilizam registros de auditoria, como o AWS CloudTrail, os Registros de Atividade do Azure Monitor e os Registros de Auditoria do Google Cloud; no entanto, ativar o registro, armazená-lo corretamente e monitorá-lo em busca de eventos de segurança é de responsabilidade do cliente. Um ambiente de nuvem sem registro ativado é um beco sem saída para a investigação de incidentes. O Kaseya SIEM integra os registros da plataforma de nuvem com a telemetria de terminais e e-mails, normalizando os eventos de segurança de todos os provedores em uma única camada de detecção.
O que isso significa para a concepção de serviços MSP
O modelo de responsabilidade compartilhada não é apenas um conceito de segurança. É uma estrutura de concepção de serviços. Os MSPs que desenvolvem ofertas de serviços explicitamente em torno das categorias de responsabilidade que abrangem conseguem transmitir o valor aos clientes com precisão. Os MSPs que não compreendem o modelo provavelmente terão lacunas não documentadas em sua cobertura e enfrentarão conversas difíceis quando um incidente as vier a revelar.
Uma lista de verificação prática para a integração de qualquer novo ambiente de nuvem de um cliente, estruturada com base no modelo de responsabilidade compartilhada:
Para cargas de trabalho de IaaS:
- Implemente o VSA ou o agente Datto RMM em todas as VMs na nuvem e inclua-as nas políticas de gerenciamento de patches existentes
- Auditar funções de IAM e contas de serviço; documentar e corrigir permissões excessivas
- Verifique as configurações dos grupos de segurança e das ACLs de rede; bloqueie qualquer acesso não restrito às portas de gerenciamento
- Confirme se o registro de auditoria está ativado em todas as regiões e se os registros são encaminhados para um destino independente e monitorado
- Verifique se o backup está configurado independentemente da conta na nuvem e teste uma recuperação
Para ambientes SaaS:
- Implemente o Datto SaaS Protection o Microsoft 365 e o Google Workspace
- Verifique as permissões da conta de administrador e implemente a autenticação de dois fatores (MFA) em todas as contas com privilégios por meio do Kaseya 365
- Documente quais dados estão armazenados em cada plataforma SaaS e qual é o procedimento de recuperação para cada uma delas
Para todos os ambientes em nuvem:
- Definir e documentar quais responsabilidades o MSP assume no contrato de prestação de serviços
- Confirmar os requisitos de conformidade (HIPAA, PCI DSS, CMMC, CCPA) aplicáveis aos dados hospedados na nuvem e mapeá-los para os controles existentes
- Adicionar a arquitetura do ambiente em nuvem e a estrutura de IAM ao IT Glue o cliente
A etapa de documentação tem importância que vai além do valor operacional. Quando um cliente enfrenta um pedido de indenização de seguro cibernético ou uma auditoria de conformidade, a capacidade do MSP de apresentar provas sobre quais controles de segurança estavam em vigor e em que momento costuma ser o fator determinante para o resultado.
Como Kaseya 365 às necessidades do cliente
Kaseya 365 oferece ferramentas que atendem a cada nível de responsabilidade do cliente em IaaS, PaaS e SaaS.
O VSA e o Datto RMM automatizam o gerenciamento de patches do sistema operacional e de aplicativos para máquinas virtuais hospedadas na nuvem, bem como para terminais locais, cobrindo a responsabilidade pela aplicação de patches em IaaS a partir de um único console.
O Datto SaaS Protection assume a responsabilidade pela proteção de dados SaaS do Microsoft 365 e do Google Workspace, com backup três vezes ao dia, retenção ilimitada e armazenamento imutável independente.
Kaseya 365 cuida da gestão de identidades e acessos no Microsoft 365 e em ambientes de nuvem conectados, incluindo a aplicação da autenticação multifatorial (MFA) e o monitoramento Dark Web ID .
O Kaseya SIEM assume a responsabilidade pelo registro e monitoramento, integrando registros de auditoria da plataforma em nuvem, juntamente com dados de telemetria de terminais e e-mails, em uma camada unificada de detecção de segurança.
IT Glue cumpre a responsabilidade de documentação, armazenando a arquitetura do ambiente de nuvem, a estrutura de IAM e os manuais de recuperação com isolamento por cliente e acesso controlado.
Kaseya Intelligence aplica reconhecimento de padrões e resposta automatizados em ambientes de nuvem gerenciados, detectando desvios de configuração no lado do cliente da fronteira de responsabilidade compartilhada e executando correções sem esperar por uma revisão manual.
