0
0
Maioria dos incidentes se deve a erro do cliente e não do fornecedor. Modelo mostra onde as responsabilidades do provedor terminam e as suas começam
Chris Hughes, CSO
A adoção da nuvem acelerou no ano passado, à medida que as organizações se esforçavam para oferecer suporte a uma força de trabalho remota. Apesar dessa rápida adoção e crescimento, as empresas costumam interpretar mal um conceito-chave de nuvem: o modelo de responsabilidade compartilhada (SRM).
Muitos líderes empresariais ainda perguntam: “A nuvem é segura”? Esta é a pergunta errada. Uma pergunta mais apropriada seria: “Estamos, como equipe e organização de segurança, protegendo nossa parcela da nuvem?” A esmagadora maioria das violações/vazamentos de dados na nuvem se deve ao cliente, com o Gartner prevendo que até 2025, 99% das falhas de segurança na nuvem serão culpa do cliente. Por esse motivo, é fundamental que todos os profissionais de segurança entendam suas responsabilidades.
Qual é o modelo de responsabilidade compartilhada?
O modelo de responsabilidade compartilhada delineia pelo que você, o cliente da nuvem, é responsável e pelo que seu provedor de serviços de nuvem (CSP) é responsável. O CSP é responsável pela segurança “da” nuvem – pense em instalações físicas, utilitários, cabos, hardware, etc. O cliente é responsável pela segurança “na” nuvem – ou seja, controles de rede, gerenciamento de identidade e acesso, configurações de aplicativos e dados.
Dito isso, essa divisão de responsabilidades pode mudar dependendo do modelo de serviço que você usa. Em um nível básico, a definição NIST de computação em nuvem define três modelos de serviço em nuvem primários:CIO2503
- Infraestrutura como serviço (IaaS): No modelo IaaS, o CSP é responsável pelo data center físico, rede física e servidores/hospedagem físicos.
- Plataforma como serviço (Paas): em um modelo PaaS, o CSP assume mais responsabilidade por coisas como patching (que os clientes são historicamente terríveis e serve como principal caminho para incidentes de segurança) e manutenção de sistemas operacionais.
- Software como serviço (SaaS): no SaaS, o cliente só pode fazer alterações nas configurações de um aplicativo, com o controle de todo o resto sendo deixado para o CSP (pense no Gmail como um exemplo básico).
Cada um vem com uma compensação, com o cliente abrindo mão do controle em troca de uma experiência turnkey/gerenciada com o CSP lidando com mais das atividades operacionais e permitindo que o cliente se concentre em suas competências essenciais.
Cada CSP tem várias versões do SRM. Abaixo está um exemplo do SRM do Microsoft Azure:
Como os profissionais de segurança podem se preparar para o SRM
Embora o SRM envolva questões não relacionadas à segurança, como contratos e implicações financeiras, ele também inclui várias considerações de segurança. Os profissionais de segurança devem entender pelo que são responsáveis no SRM com base nos serviços que estão consumindo e nas implementações e arquiteturas de suas organizações. Lembra-se de como quase todos os incidentes de dados em nuvem ocorrem no lado do cliente do SRM? Este é um dos principais motivos para entender o SRM e garantir que você está fazendo sua parte no modelo.
Suas responsabilidades dependem de qual das duas perspectivas principais de função de segurança você tem: o profissional técnico de segurança ou o executivo de segurança. Os profissionais de segurança técnica, como engenheiros de segurança em nuvem ou arquitetos de segurança em nuvem, precisam entender quais serviços em nuvem sua organização está usando, como arquitetar essas soluções com segurança e quais configurações, definições e controles estão sob sua alçada que você pode influenciar e liderar para uma postura de segurança mais robusta.
Os profissionais de segurança técnica devem estar intimamente familiarizados com as plataformas e serviços que sua organização está usando e compreender como implementá-los com segurança. Os engenheiros/arquitetos de segurança em nuvem costumam trabalhar com equipes de engenharia e desenvolvimento. Se você não for capaz de orientá-los para uma solução segura ou identificar configurações arriscadas (lembre-se de como elas são responsáveis pela maioria dos incidentes de dados em nuvem), você pode estar expondo sua organização a um risco tremendo.
Consulte seu CSP para recursos de segurança. Amazon Web Services (AWS), por exemplo, oferece um banco de dados incrível de documentação de segurança, dividido por categorias (por exemplo, computação, armazenamento, segurança, identidade e conformidade), onde você pode encontrar especificações associadas a cada um dos serviços que sua organização está usando. Isso inclui inúmeras informações sobre como configurar os serviços com segurança, quais configurações você pode manipular e orientações para solução de problemas.
As principais considerações para executivos de segurança incluem o uso de serviço de inventário (você deve saber o que está sendo usado em sua organização ou não pode protegê-la), garantindo que os serviços que você usa sejam compatíveis com suas estruturas regulatórias aplicáveis e compreendendo os aspectos contratuais/legais, como serviço CSP acordos de nível (SLAs), especialmente quando se trata de coisas como planejamento de resposta a incidentes.
Muitas organizações firmam parceria com o CSP e compartilham responsabilidades. Isso inclui garantir que os serviços que você está usando atendam às estruturas regulatórias às quais você deve cumprir. Os CSPs em hiperescala tornam essas informações fáceis de encontrar, com AWS e Microsoft Azure fornecendo páginas de “serviços no escopo”, onde você pode determinar quais serviços estão em conformidade com quais estruturas e quais ainda estão em processos de aprovação. Isso ajuda a garantir que a sua equipe não apenas construa arquiteturas e cargas de trabalho robustas e seguras na nuvem, mas também use serviços que são compatíveis com suas estruturas aplicáveis para evitar problemas de conformidade ou regulamentares.
Os profissionais de segurança de todos os níveis devem se esforçar para implementar padrões de segurança e práticas recomendadas em seus ambientes de nuvem. Isso pode significar implementar práticas recomendadas de segurança de seus respectivos CSPs ou implementar algo como o benchmark Center for Internet Security (CIS) para seus respectivos ambientes de nuvem.
A matriz de responsabilidade do cliente
Um artefato fundamental ao lidar com o SRM é a matriz de responsabilidade do cliente (CRM, sigla em inglês para Customer Responsibility Matrix), que estabelece quais controles estão sendo fornecidos pelo CSP e quais responsabilidades são deixadas para o consumidor da nuvem.
Um CRM é uma ferramenta crítica para uso de profissionais de segurança. No SRM, os controles de segurança são fornecidos inteiramente pelo CSP, um controle híbrido (com a responsabilidade recaindo sobre o CSP e o cliente da nuvem), ou inteiramente deixados para o cliente. Os profissionais de segurança podem aproveitar os CRMs para obter uma compreensão clara desse delineamento de controle de segurança.
Consumir serviços em nuvem pode transferir a responsabilidade de alguns controles e atividades de segurança para o CSP e permitir que as organizações se concentrem em suas competências essenciais. Dito isso, ele cria uma relação de responsabilidades que os profissionais de segurança devem entender e tratar de maneira adequada. Lembre-se de que a maioria das violações de dados na nuvem ocorrerá no lado do cliente do SRM e, no final do dia, você é totalmente responsável pela reputação de sua organização.
FONTE: CIO