O modelo de responsabilidade compartilhada na nuvem para IaaS, PaaS e SaaS

Como funcionam os modelos de responsabilidade compartilhada na nuvem?

Os modelos de responsabilidade compartilhada na nuvem definem quais aspectos de um ambiente de nuvem um CSP gerencia e quais o cliente gerencia.

Todos os principais CSPs, incluindo AWS, Microsoft Azure e Google Cloud, publicam modelos de responsabilidade compartilhada. Embora variem um pouco nos detalhes, a maioria dos modelos de responsabilidade compartilhada afirma que o CSP assume a liderança na gestão do seguinte:

• Manter o software que alimenta a infraestrutura de nuvem subjacente atualizado e protegido contra riscos de segurança.
• Gerenciar a camada de virtualização que permite aos clientes criar máquinas virtuais (VMs) e outros recursos em servidores físicos na nuvem.
• Responder a incidentes que afetam a segurança ou a eficácia operacional de servidores físicos em nuvem e outras infraestruturas.
• Proteger servidores e infraestrutura de rede dentro da plataforma de nuvem contra riscos de segurança física.

Enquanto isso, os clientes da nuvem geralmente são responsáveis ​​pelo seguinte:

• Implementar configurações de segurança eficazes para aplicativos e dados hospedados em seus ambientes.
• Definir políticas seguras de gerenciamento de identidade e acesso para controlar o acesso a aplicativos e dados baseados em nuvem em seus ambientes.
• Monitoramento de ambientes de nuvem em busca de sinais de violações.
• Atualizar aplicativos implantados pelo cliente conforme necessário para mitigar vulnerabilidades de segurança.

Entender quem faz o quê no contexto de segurança e gerenciamento da nuvem é importante porque a nuvem é diferente da computação local. Com data centers locais tradicionais, a equipe de TI da organização gerencia tudo — a infraestrutura física, a camada de virtualização (se houver) e quaisquer dados e aplicativos que residam no data center. Essas barreiras claramente definidas tornam todo o processo de segurança relativamente simples.

Mas, ao migrar para a nuvem, as equipes de TI precisam lidar com a infraestrutura e os serviços gerenciados pelos provedores de serviços de nuvem, o que pode complicar a estratégia geral de segurança de uma organização. Uma vez envolvido, o provedor de nuvem assume parte da responsabilidade de proteger o ambiente do cliente — mas não necessariamente os dados contidos nele. No entanto, se administradores e desenvolvedores não protegerem suas atividades, a organização pode se tornar vulnerável a violações.

A chave para uma estratégia de segurança na nuvem bem-sucedida é entender o modelo de responsabilidade compartilhada da nuvem em toda a sua extensão.

Quais são as diferenças entre os modelos de responsabilidade compartilhada para IaaS, PaaS e SaaS?

Em um nível mais alto, entender o modelo de responsabilidade compartilhada é bastante simples: os clientes da nuvem são responsáveis ​​por gerenciar os recursos que controlam, e o CSP faz o resto.

No entanto, essa abordagem pode variar dependendo da categoria de serviço de nuvem —IaaS, PaaS ou SaaS— envolvida.

IaaS

Em um modelo IaaS, os CSPs fornecem apenas a infraestrutura. Por exemplo, eles podem fornecer aos clientes um serviço de armazenamento de objetos onde podem armazenar dados ou um serviço de servidor em nuvem onde podem iniciar VMs.

A responsabilidade compartilhada costuma ser clara no IaaS, pois o modelo distingue a infraestrutura em nuvem das cargas de trabalho e dos dados nelas residentes. O CSP gerencia a infraestrutura física e a camada de virtualização, enquanto o cliente gerencia todo o resto.

PaaS

Em um modelo PaaS, o CSP fornece a infraestrutura e as ferramentas para desenvolver e implantar aplicativos.

Nesse modelo, o CSP gerencia tanto a infraestrutura quanto as ferramentas de desenvolvimento e implantação de software. Os clientes gerenciam quaisquer aplicativos que criem usando o PaaS.

Além disso, os clientes geralmente são responsáveis ​​por proteger os ambientes de desenvolvimento de PaaS. Por exemplo, imagine que um cliente escolheu uma senha ruim para sua conta de PaaS e um agente malicioso se conectou à PaaS, injetou código malicioso no aplicativo do cliente e, em seguida, implantou o aplicativo comprometido. Nesse caso, o cliente seria responsável por permitir a violação. Embora o CSP gerencie a plataforma de PaaS, ele não é responsável por problemas que surjam devido à forma como os clientes utilizam a plataforma.

PaaS é o meio-termo no modelo de responsabilidade compartilhada da nuvem, pois atribui mais responsabilidade ao provedor de nuvem. Nesse cenário, as equipes de TI ainda implantam e gerenciam seus aplicativos e dados relacionados, mas o provedor protege a operação da infraestrutura subjacente e dos sistemas operacionais em geral.

SaaS

No modelo SaaS, os clientes têm controle e responsabilidade mínimos. Isso ocorre porque as ofertas de SaaS incluem infraestrutura em nuvem e o software executado sobre essa infraestrutura, tudo gerenciado pelo fornecedor de SaaS.

Isso não significa que o SaaS isenta os clientes de toda responsabilidade. Os usuários de aplicativos SaaS ainda devem garantir que não escolham opções de configuração que possam levar a problemas de segurança, como conceder acesso público a um arquivo de processador de texto criado usando um aplicativo SaaS.

Além disso, embora os fornecedores de SaaS normalmente ofereçam serviços de backup e recuperação de dados para proteção contra incidentes de perda de dados que podem resultar de falhas em sua infraestrutura, eles geralmente não recuperam dados que os clientes excluem acidentalmente. Por esse motivo, os clientes de SaaS devem considerar fazer backup de seus dados.

Desfocando as linhas

Às vezes, as linhas que separam IaaS, PaaS e SaaS não são claras, assim como o modelo de responsabilidade compartilhada da nuvem.

Por exemplo, o Amazon Elastic Kubernetes Service gerencia clusters do Kubernetes. Em alguns aspectos, o EKS se assemelha ao IaaS, pois permite que os clientes implantem aplicativos em servidores em nuvem. A Amazon gerencia os servidores subjacentes, mas os clientes gerenciam os aplicativos que implantam usando o EKS.

A Amazon fornece o software principal dentro do EKS, o plano de controle do Kubernetes, como um serviço gerenciado para implantar, configurar e proteger o serviço pelos clientes. Este componente do Amazon EKS se assemelha mais a uma forma de SaaS.

Gerenciar responsabilidades de forma eficaz no contexto de um serviço de nuvem complexo como o Amazon EKS é possível. No entanto, é necessário um entendimento detalhado de como o serviço é arquitetado e quais são suas implicações para a responsabilidade compartilhada.

Desafios do modelo de responsabilidade compartilhada

O modelo de responsabilidade compartilhada é simples em princípio, mas segui-lo pode ser desafiador na prática pelos seguintes motivos:

• Não há garantia definitiva contra falhas. Terceirizar algumas responsabilidades de gerenciamento para provedores de nuvem é atraente, mas os CSPs podem cometer erros que afetam os clientes. Por exemplo, se o data center de um provedor de nuvem cair, os serviços da sua empresa também podem ficar inativos até que o CSP volte a operar. Normalmente, os acordos de nível de serviço em nuvem (SLAs) permitem um certo nível de falha e o CSP não oferece compensação por esses tipos de eventos.
• Limitações das ferramentas de nuvem. Os provedores de nuvem oferecem uma variedade de ferramentas para ajudar seus clientes a configurar e monitorar ambientes de nuvem. Mas só porque os CSPs fornecem essas ferramentas não significa que elas assumam automaticamente as responsabilidades dos clientes por elas. Os clientes devem aprender a usar as ferramentas de forma eficaz e saber quando recorrer a ofertas de terceiros para preencher lacunas nas ferramentas oferecidas pelo CSP.
• Dados limitados. Embora os dados que ajudam as organizações a gerenciar a segurança e outros riscos estejam disponíveis em um ambiente local, eles nem sempre estão disponíveis na nuvem. Por exemplo, muitos serviços de nuvem fornecem acesso apenas a determinados tipos de métricas e, como os clientes não controlam a infraestrutura subjacente, não podem criar métricas personalizadas. Isso deixa os clientes com um conjunto de dados limitado para monitorar seus ambientes.
• Implantações complexas. Alguns tipos de serviços e ambientes de nuvem combinam elementos de IaaS, PaaS e/ou SaaS. Entender como a responsabilidade compartilhada funciona nesse contexto requer uma avaliação detalhada de quem controla o quê.

Dicas para revisar SLAs com provedores de nuvem

Se não tiver certeza do que um acordo de responsabilidade compartilhada significa para sua organização, peça ao seu provedor de nuvem para explicar os detalhes do SLA. Em particular, você deve entender o seguinte:

• O que o SLA garante. Normalmente, os SLAs prometem um determinado tempo de atividade para serviços em nuvem. Eles também podem especificar latência ou taxas de resposta.
• Como as métricas de SLA são calculadas. Pergunte como o CSP determina se está cumprindo o SLA. Por exemplo, um serviço precisa ficar indisponível por um período mínimo de tempo antes de acionar um evento de inatividade que conta para o SLA? Ou o CSP soma cada milissegundo de inatividade e usa esse cálculo para determinar se cumpre seu compromisso de tempo de atividade?
• O que acontece se o SLA for violado? Os CSPs podem fornecer créditos ou reembolsos caso não cumpram o SLA. Mas também é possível que o acordo de SLA não inclua nenhuma compensação por descumprimento das garantias do SLA.
• O histórico de conformidade do CSP com o SLA. Com que frequência o provedor de nuvem não cumpriu suas garantias de SLA no passado? Quando ocorreram violações de SLA, quão graves foram? Os clientes foram compensados?
• Políticas de alteração de SLA. O CSP pode alterar os termos do SLA, por exemplo, modificando as garantias de disponibilidade por vontade própria? Ou o CSP está vinculado aos seus compromissos por meio de garantias de SLA inalteráveis?

Sobre os autores:

Chris Tozzi é um escritor freelancer, consultor de pesquisa e professor de TI e sociedade que já trabalhou como jornalista e administrador de sistemas Linux.

Sara Grier é ex-editora assistente do grupo de mídia Cloud/DevOps da Informa TechTarget.