O modelo de responsabilidade compartilhada na nuvem é um dos conceitos mais importantes em segurança na nuvem e um dos que mais frequentemente são 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 pela segurança para o provedor do que realmente ocorre. 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 afirmação sobre onde se situa o limite da responsabilidade. A infraestrutura do provedor de nuvem geralmente é 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 essa divisão de responsabilidades varia 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 do hipervisor, a malha de rede e a disponibilidade e confiabilidade do serviço de gerenciamento de nuvem ( managed services ) que oferecem. 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 configurar 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 acima na pilha o serviço estiver, mais responsabilidades o provedor assume e menos o cliente gerencia 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 o AWS EC2, as VMs do Azure e o Google Compute Engine.

O IaaS é o modelo de serviço que atribui maior responsabilidade ao cliente. 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, as regras de firewall e a configuração de grupos de segurança, a criptografia em repouso e em trânsito, a configuração de IAM e o 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 gerenciados de banco de dados, como o Azure SQL Database, o AWS RDS e as plataformas de hospedagem de aplicações, operam nesse modelo.

O PaaS reduz significativamente a carga 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 do aplicativo e pela segurança do código do aplicativo.

Software como Serviço (SaaS)

O provedor gerencia toda a pilha, desde a infraestrutura até o aplicativo. O cliente é responsável pelos dados, pelo gerenciamento de acesso e pela configuração dos controles de segurança do aplicativo.

O Microsoft 365, o Google Workspace e o Salesforce são todos serviços SaaS. O equívoco mais comum nesse contexto é o seguinte: como o provedor gerencia o aplicativo, os clientes presumem que ele também protege os dados. Mas isso não é verdade. A Microsoft é responsável pela disponibilidade e confiabilidade da plataforma do Microsoft 365. Os dados contidos em 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 principais lacunas na responsabilidade compartilhada

Entender 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 passaram por uma avaliação formal.

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, ataque de ransomware ou comprometimento da conta. O Datto SaaS Protection resolve 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. O gerenciamento de identidade e acesso — 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 assume o ambiente AWS de um novo cliente normalmente se depara com funções do IAM cujas permissões são 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 aplicam patches 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 configurados como 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 —, mas 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 SIEM da Kaseya integra os registros da plataforma de nuvem juntamente 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 de 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 com base nas categorias de responsabilidade que abrangem conseguem demonstrar 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 expor.

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 inscreva-as nas políticas existentes de gerenciamento de patches
Auditar funções de IAM e contas de serviço; documentar e corrigir permissões excessivas
Revisar as configurações dos grupos de segurança e das ACLs de rede; bloquear qualquer acesso irrestrito às portas de gerenciamento
Confirme se o registro de auditoria está habilitado 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 para o Microsoft 365 e o Google Workspace
Revise as permissões da conta de administrador e implemente a autenticação multifatorial (MFA) em todas as contas com privilégios por meio do usuário “ Kaseya 365 ”
Documente quais dados estão armazenados em cada plataforma SaaS e qual é o caminho 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 aos controles em vigor
Adicionar a arquitetura do ambiente em nuvem e a estrutura de IAM ao IT Glue para o cliente

A etapa de documentação tem importância que vai além do valor operacional. Quando um cliente se depara com um pedido de indenização de seguro cibernético ou uma auditoria de conformidade, a capacidade do MSP de apresentar evidências sobre quais controles de segurança estavam em vigor e em que momento costuma ser o fator determinante para o resultado.

Como o “ Kaseya 365 ” aborda a perspectiva do cliente

A plataforma Kaseya 365 oferece ferramentas que atendem a cada nível de responsabilidade do cliente nas camadas IaaS, PaaS e SaaS.

O VSA e o Datto RMM automatizam o gerenciamento de patches do sistema operacional e dos 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 cobre a responsabilidade pela proteção de dados em modelo SaaS para o Microsoft 365 e o Google Workspace, com backup três vezes ao dia, retenção ilimitada e armazenamento imutável independente.

Kaseya 365 O usuário lida com a responsabilidade pela gestão de identidade e acesso no Microsoft 365 e nos ambientes de nuvem conectados, incluindo a aplicação da autenticação multifatorial (MFA) e o monitoramento de credenciais do Dark Web ID .

O Kaseya SIEM assume a responsabilidade pelo registro e monitoramento, incorporando logs 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 abrange a responsabilidade pela documentação, o armazenamento da arquitetura do ambiente em nuvem, a estrutura de IAM e os manuais de recuperação, com isolamento por cliente e acesso controlado.

Kaseya Intelligence aplica reconhecimento automatizado de padrões e respostas 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.

Conheça o Kaseya 365 para ambientes em nuvem e híbridos