estratégias para proteger cloud workloads com modelos de

Estratégias para proteger Cloud Workloads com Modelos de Responsabilidade Compartilhada

Estratégias para proteger Cloud Workloads com Modelos de Responsabilidade Compartilhada | 2

Visão Geral

A mudança para a nuvem oferece muitas vantagens para a TI corporativa em relação à infraestrutura tradicional local. Mas também apresenta novos desafios de segurança.A nuvem é muito diferente dos ambientes de computação tradicionais, exigindo novos métodos para proteger a infraestrutura virtualizada e dinâmica. Além disso, quando um cliente coloca sua TI nas mãos de terceiros, eles renunciam algumas de suas responsabilidades de segurança ao seu provedor de nuvem.Mas, sem políticas claras, isso pode levar a concepções errôneas sobre o papel que os usuários da nuvem pública desempenham na proteção de seus aplicativos. Consequentemente, os fornecedores de nuvem usam um modelo de responsabilidade compartilhada para esclarecer as obrigações de segurança de cada parte.Atualmente não existe um modelo padrão do setor de responsabilidade compartilhada. Como resultado, as obrigações de segurança de um cliente variam de provedor para provedor, bem como a natureza dos serviços que eles usam.Ao mesmo tempo, para ajudar o cliente a cumprir essas obrigações, os fornecedores de nuvem oferecem um rico conjunto de recursos e configurações para aplicativos de proteção.Este documento compara os modelos de segurança compartilhada dos principais provedores de nuvem e fornece conselhos sobre as medidas adicionais de segurança que as empresas devem adotar para proteger seus workloads na nuvem.

“Quando a TI era totalmente local, as organizações operavam com delineamentos claros entre operações de rede, desenvolvimento de software e segurança da informação. As pessoas desenvolveram habilidades relacionadas aos seus papéis e sabiam quando solicitar a ajuda de outras pessoas.

Nas implantações na nuvem, particularmente no IaaS, as distinções não são claras. Quem se torna responsável pelas decisões de segurança, como configurar grupos de segurança, gerenciar chaves de criptografia ou manter as instâncias de computação corrigidas? Quando a resposta não é clara, as equipes de segurança de TI podem se sentir menos influentes.

Para IaaS e PaaS, ferramentas de terceiros podem aliviar os desenvolvedores desses encargos adicionais e restaurar um senso de propósito às equipes de segurança de TI.”

– Gartner, “Staying Secure in the Cloud Is a Shared Responsibility,” Abril, 2016 (atualizado em Maio, 2017)


O que é o Modelo de Responsabilidade de Segurança Compartilhada?

Os provedores de nuvem fazem o possível para garantir o fornecimento de uma plataforma segura para os clientes desenvolverem e hospedarem seus aplicativos. Eles têm uma riqueza de tecnologia de segurança e conhecimento à sua disposição. Eles também revisam regularmente suas medidas de segurança para se proteger contra falhas em seus sistemas.

Mas eles só podem ajudar até um certo ponto para proteger os ativos de seus clientes.

Isso ocorre porque não há dois clientes na nuvem iguais. Cada ambiente de nuvem é individual para o cliente. Cada um deles será baseado em um design de rede diferente, usará recursos de infraestrutura diferentes e hospedará aplicativos diferentes. Isso deixa elementos de segurança cibernética que estão fora do controle do provedor. Em outras palavras, os clientes ainda têm o dever de proteger suas próprias implantações na plataforma escolhida.

Um modelo de responsabilidade de segurança compartilhada é um framework usado pelos fornecedores de nuvem para ajudar os clientes a entender suas obrigações ao usar seus serviços. Garante a responsabilidade do usuário e que ambas as partes trabalhem juntas para garantir a cobertura total da segurança.

Alguns controles são de inteira responsabilidade do fornecedor da nuvem, como a segurança física de seus data centers, hardware e sistema operacional (SO). Algumas são de total responsabilidade do cliente, como o SO convidado, proteção de tráfego de rede e código do aplicativo.

No entanto, a responsabilidade por muitos outros controles depende da classe de serviço em nuvem (IaaS, PaaS ou SaaS) que um cliente usa. Os clientes de IaaS têm mais controle sobre seu ambiente de nuvem e, portanto, têm um conjunto muito mais amplo de responsabilidades de segurança. No outro extremo da escala, a segurança das ofertas de SaaS, abstraídas da infraestrutura subjacente, recai principalmente sobre o fornecedor.

A maioria dos principais fornecedores de nuvem segue modelos de responsabilidade compartilhada muito semelhantes. Portanto, em termos de responsabilidades do cliente, o que distingue um fornecedor de outro tem mais a ver com a forma como eles estruturam suas ofertas, onde as funções e os controles de segurança aplicados dependem dos serviços específicos utilizados.

Não obstante o fato de que a maioria dos modelos de responsabilidade compartilhada funcione com os mesmos princípios fundamentais, os principais fornecedores usam abordagens diferentes para documentar as responsabilidades de cada parte.

“Se eu tivesse que mencionar duas diferenças principais entre a nuvem pública e a segurança local, diria que seria o isolamento e a responsabilidade compartilhada.”– Thomas Shinder, Gerente de Programa Engenharia de Segurança Azure, Microsoft

Cuidado com Pontos Cegos

Os modelos de responsabilidade compartilhada são um excelente ponto de referência para proteger implantações na nuvem. Mas os clientes devem estar cientes de que eles podem não cobrir todos os aspectos de segurança.

Por exemplo, alguns provedores fornecem pouca orientação para papéis e responsabilidades em relação à resposta a incidentes.

Por esse motivo, os usuários da nuvem devem ir além do que é coberto no modelo de responsabilidade compartilhada de seus fornecedores, para garantir que eles tenham medidas para todas as eventualidades.


Amazon Web Services (AWS)A AWS explica seu conceito de responsabilidade compartilhada em termos muito simples, dividindo-o em duas categorias claramente definidas:

• Segurança da nuvem: responsabilidades da Amazon, que incluem o sistema operacional host, a camada de virtualização, a segurança física de suas instalações e as ferramentas de segurança que ele fornece aos clientes.

• Segurança na nuvem: as responsabilidades do cliente, como sistema operacional convidado, configuração e manutenção do sistema e configuração dos serviços de segurança.

Como mostra o diagrama a seguir, o modelo se concentra apenas nas ofertas de IaaS e PaaS disponíveis em sua plataforma:

ClienteResponsabilidade

pela segurança "na" nuvem

Criptografia de Dados do Lado do Cliente e Autenticação de

Integridade de Dados

Regiões

Proteção de Tráfego de Rede (Criptografia, Integridade,

Identidade)

Edge Locations

Criptografia no Servidor (Sistema de Arquivos e / ou Dados)

Zonas de disponibilidadeAWSResponsabilidade pela segurança "da" nuvem

Infraestrutura Global do Hardware/AWS

Software

Fonte: AWS

● Plataforma, Aplicativos, Identidade e Gerenciamento de Acesso

Dados do Cliente

● Configuração do Sistema Operacional, Rede e Firewall

Modelo de Responsabilidade Compartilhada da AWS

Calcular RedeBanco de DadosArmazenamento


Microsoft AzureO modelo do Microsoft Azure descreve as responsabilidades por seus produtos IaaS, PaaS e SaaS e ilustra as principais diferenças de responsabilidade entre as diferentes classes de serviço. Ele é organizado em sete áreas de responsabilidade: Segurança da nuvem: as responsabilidades da Microsoft, que incluem o sistema operacional host, a camada de virtualização, a segurança física de suas instalações e as ferramentas de segurança fornecidas aos clientes.

• Classificação de dados e prestação de contas: Classificação dos dados do cliente por nível de confidencialidade - para definir as medidas de segurança necessárias para protegê-lo.

• Proteção de cliente e endpoint: gerenciamento e controle de dispositivos e locais que acessam a nuvem de um cliente, fornecendo o equilíbrio correto entre a produtividade do usuário e a proteção de seus dados.

• Gerenciamento de identidade e acesso: gerenciamento de usuários que acessam a nuvem de um cliente e controlam quais aplicativos, conjuntos de dados ou serviços podem usar.

• Controle em nível de aplicativo: medidas para proteger pilhas de aplicativos, incluindo o código que é executado dentro deles.

• Controle de rede: controles necessários para garantir que os serviços se comuniquem e inter-operem com segurança, abrangendo elementos de rede, como rede virtual, balanceamento de carga, DNS e gateways.

• Infraestrutura do host: configuração e gerenciamento de computação, armazenamento e serviços relacionados, como dimensionamento automático e redes de distribuição de conteúdo (CDNs).

• Segurança física: proteção de edifícios, servidores e dispositivos de rede da Microsoft contra acesso físico não autorizado.

Responsabilidade On-Prem IaaS PaaS Saas

Classificação e Responsabilidade de Dados

Proteção de Cliente e Endpoint

Gerenciamento de Identidade e Acesso

Controles de Nível de Aplicativo

Controles de Rede

Infraestrutura do Host

Segurança Física

Cliente da Nuvem Provedor da Nuvem

Fonte: Microsoft Azure

Modelo de Responsabilidade Compartilhada da Microsoft Azure


O diagrama na página anterior demonstra como algumas áreas de responsabilidade são compartilhadas, dependendo da classe de serviço em nuvem. Por exemplo, os clientes de IaaS compartilham a responsabilidade pelos controles de rede com o fornecedor, enquanto a Microsoft assume total responsabilidade pelos controles de rede em suas ofertas de SaaS e PaaS.

Google Cloud PlatformAo contrário da AWS e do Azure, o Google Cloud Platform não fornece um documento ou página da web oficial dedicada à responsabilidade compartilhada, embora tenha criado uma matriz de responsabilidade do cliente especificamente para clientes que usam a plataforma para fornecer produtos e serviços compatíveis com PCI.

Em vez disso, ele cobre a responsabilidade compartilhada como parte de um Modelo de segurança do Google mais geral, oferecendo conselhos sobre como manter seus projetos seguros nas seguintes áreas principais:

• Sistema operacional convidado e aplicação de patches• Gerenciamento de usuário e credencial• Manutenção de regra de firewall de rede• Teste de penetração• Gerenciamento de dados confidenciais• Registro e monitoramento


Considerações para Proteger Cloud Workloads em Modelos de Segurança CompartilhadaDe acordo com o Gartner, “Server workloads em data centers híbridos, abrangendo nuvens públicas e privadas, exigem uma estratégia de proteção diferente dos dispositivos voltados para o usuário final”. Isso se deve à natureza elástica dos aplicativos no estilo da nuvem e à incompatibilidade de agentes em execução projetados para servidores locais.

Segurança compartilhada significa dividir e conquistar os riscos de segurança na nuvem. Todos os principais provedores de nuvem lidam com as etapas de atenuação e mitigação de segurança para hardware de infraestrutura, com filtragem de tráfego no perímetro, e oferecem serviços como por exemplo o Amazon Shield. Eles fornecem segurança em seus datacenters, descartam hardware que pode conter dados confidenciais, além de fornecer orientações de segurança em níveis de suporte mais altos pagos.

O que está claro é que os principais controles de proteção de cargas de trabalho na nuvem recomendados pelo Gartner não são fornecidos em modelos de segurança compartilhados da AWS, Azure ou Google Cloud Platform. O design real da aplicação dos controles principais de proteção de carga de trabalho é responsabilidade da empresa.

Tabela de Comparação

Estratégias de Segurança para Preencher as Lacunas

Isolamento de RecursosA segurança é otimizada quando projetada em profundidade. A separação de recursos em seções individualmente testáveis e protegidas ajuda a reduzir vetores e vulnerabilidades de ataque.

Isolamento de Rede e AplicativosA segmentação de aplicativos na camada de rede é uma excelente prática de segurança por dois motivos. Primeiro, a utilização de NACL (Network Access Control Lists) permite controle granular entre ativos externos, como balanceadores de carga ou gerenciadores de ameaças, e os recursos internos, como camadas de aplicativos, armazenamento em cache, subserviço e banco de dados. Isso, associado aos Grupos de Segurança (SG) para restringir ainda mais a comunicação apenas entre os serviços necessários, reduz o seu ponto de vetor para defesa.

1. Neil MacDonald, “Market Guide for Cloud Workload Protection Platforms”, Gartner Inc. marzo de 2018.

Controles de Proteção Core Cloud Workload Amazon Web Services Azure Google Cloud

Platform

Firewall / Segmentação e Visibilidade de Rede

100% de Responsabilidade

do Cliente


do Cliente em Ambientes de IaaS

e PaaS


do Cliente

Controle de Aplicativo / Lista de Permissões

Monitoramento / Gerenciamento da Integridade do Sistema

Proteção, Configuração e Gerenciamento de Vulnerabilidades


Em segundo lugar, solidificar suas regras NACL reduz a carga de tráfego antes de atingir seu SG e aplicações. Isso pode aliviar a carga desnecessária nos serviços do tráfego indesejado e remover o tráfego que pode ser eliminado do log de seu aplicativo.

No entanto, os fluxos de dados entre componentes sempre devem ser registrados e analisados em busca de atividades suspeitas, incluindo conexões não autorizadas entre aplicativos, como ataques MITM (Man-In-The-Middle) ou anomalias de rede (DDOS, vírus, exploração de vulnerabilidades) que podem ser indicadores de uma violação.

Segurança de ContêineresOs contêineres fornecem virtualização e isolamento em nível de serviço. Eles reduzem ainda mais os vetores de ataque, expondo apenas o serviço necessário. Além disso, os contêineres, por design, são extremamente leves.

Um contêiner pode ser executado em hosts individuais no Docker ou rkt, mas as empresas se beneficiariam mais com a arquitetura sofisticada de agendamento e implantação, como Kubernetes, Mesos ou Docker Swarm. Esses conjuntos de ferramentas fornecem os meios para isolar ainda mais as cargas de trabalho por meio de permissões, habilitar a alta disponibilidade por meio do agendamento e distribuir efetivamente a carga pelos mestres. Além disso, eles permitem um controle mais preciso dos tipos de carga de trabalho entre os serviços de contêiner. Existem ofertas nativas da nuvem que correspondem aos Kubernetes de código aberto, como Amazon Elastic Container Service (ECS), Amazon EKS, Azure Container Service (AKS) ou o Google Kubernetes Engine.

As ofertas nativas da nuvem aproveitam o mesmo modelo de código aberto do Kubernetes, mas abstraem algumas (ECS, EKS, AKS) para quase todas (AWS Fargate, Azure Container Instances) do gerenciamento de infraestrutura. Escolher esses modelos requer algum tipo de dependência do fornecedor de nuvem, mas, em contrapartida, reduz a sobrecarga de gerenciamento e possíveis erros de configuração. Fazer isso também reduz o potencial de exposição à segurança.

MicrossegmentaçãoAs aplicações podem ser segmentadas em componentes individuais distribuídos. Reduzir o acoplamento de aplicações para funções únicas por microservico fornece benefícios adicionais.

Com a microssegmentação, cada aplicativo se torna um componente interdependente. Significando que a falha é isolada. Os componentes que dependem de um componente com falha ainda podem falhar (se arquitetados dessa maneira), mas cada componente deve ser projetado para sobreviver como uma cadeia de funções. Este é um desvio do grande projeto monolítico “fortemente acoplado” utilizado na geração anterior da computação.

As aplicações em microservicos se encaixam perfeitamente em redes e contêineres segmentados. A utilização de ambos recursos garante que o modelo possa ser flexível com a carga e a mudança de ambiente, como durante um surto ou desastre.

Por fim, a microssegmentação reduz a exposição. Se um único serviço for comprometido, um invasor terá vetores muito limitados para invadir ainda mais a arquitetura total. Isso também permite uma resolução mais rápida, pois os recursos são impactados apenas de maneiras limitadas por ataques a outros recursos.

“A microssegmentação é um método de criação de zonas seguras em datacenters e implementações de nuvem que permite que as empresas isolem as cargas de trabalho umas das outras e protejam-nas individualmente. Seu objetivo é tornar a segurança de rede mais granular.”

Ann Bednarz, Editor Assistente, Network World


Criptografia de DadosCriptografia Server-Side e Client-Side

Criptografia server-side e client-side são suportadas pelos três principais fornecedores de nuvem.

• Criptografia Server-side: O fornecedor criptografa os dados de um cliente em nome deles depois de recebê-los.

• Criptografia Client-side: O cliente criptografa os dados antes de transferi-los para o serviço em nuvem.

A criptografia server-side limita as responsabilidades do cliente, transferindo o gerenciamento de chaves de criptografia para o seu fornecedor de nuvem. Também oferece operações de menor latência, pois as chaves são armazenadas mais perto do ponto de criptografia.

A criptografia client-side atenderá aos clientes que desejam o controle interno das chaves usadas para criptografar dados. No entanto, as chaves de criptografia do lado do servidor são gerenciadas pelo provedor. Os clientes devem sempre revisar o que está disponível por serviço. Por exemplo, a AWS limita os serviços disponíveis para criptografia no lado do cliente.

Criptografando Dados em Repouso e em TrânsitoO construtor de aplicativos pode aproveitar esses métodos de criptografia como parte de uma solução. Eles não são fornecidos automaticamente pelo fornecedor da nuvem. A utilização de ambos significa criptografar dados em cada ponto da transação ou “atividade”, bem como quando atinge seus pontos com informações de estado.

• Criptografia em repouso: arquivos ou dados são criptografados quando não estão sendo utilizados, como no disco ou no banco de dados.

• Criptografia em trânsito: os dados são criptografados durante o uso entre serviços, como entre o balanceador de carga e os servidores da Web, ou entre um aplicativo e um servidor de banco de dados.

O Azure, o GCP e o AWS fornecem a capacidade de criptografar volumes de dados em servidores. A utilização da criptografia de volume permite a criptografia em repouso e é uma etapa fácil de mitigação de riscos. Cada um deles fornece utilitários de gerenciamento de chaves para teclas de volume que oferecem a opção de gerenciar as chaves de criptografia ou permitir que o fornecedor de nuvem gerencie as chaves (que são automaticamente executadas por trás da cena).

O uso da criptografia em trânsito requer o design da integração de certificados em serviços usando protocolos seguros, como TLS ou SSL. Para verdadeira criptografia em trânsito, os dados devem ser criptografados do ponto de extremidade mais externo até o ponto de dados. Ou seja, cada destino ao longo de balanceadores de carga ou entre microsserviços deve ser criptografado pelo aplicativo ou intermediado por proxy por meio de um serviço da Web que possa manipular a criptografia, como Nginx ou HAProxy. A manutenção da criptografia completa reduz o sniffing, o alcance, o MITM e o roubo de dados, em geral. É obrigatório usar sempre cifras acima de 256 bits e garantir que o SSL / TLS atual não seja corrigido e explorado.

Outro fator importante a considerar é como executar a descriptografia. Alguns serviços de terminação TLS, como os incluídos no AWS Classic Load Balancer (CLB) e no Application Load Balancer (ALB), não apenas reduzem a carga de trabalho nos servidores de back-end, mas também a sobrecarga de gerenciamento de segurança.

Níveis Granulados de CriptografiaAlguns serviços de fornecedores em nuvem oferecem níveis de criptografia altamente direcionados. Por exemplo, o Banco de Dados SQL do Azure oferece criptografia em nível de célula ou em coluna, onde é possível criptografar colunas ou células específicas de dados com diferentes chaves de criptografia.


Alguns, em particular, fornecem administração centralizada de certificados SSL / TLS e gerenciamento simplificado de patches. Conseqüentemente, se um cliente precisar corrigir vulnerabilidades em sua pilha SSL / TLS, precisará aplicá-las apenas ao servidor front-end.

Atualizações e Correções regualrmenteComo usuário de IaaS, o cliente assume total responsabilidade por manter cada SO convidado atualizado. No entanto, eles podem reduzir sua carga de segurança usando um ou mais dos serviços totalmente gerenciados de seus provedores de nuvem.

Por exemplo, eles poderiam usar opções de banco de dados como serviço (DBaaS), como o RDS (Serviço de banco de dados relacional), o banco de dados SQL do Azure e o Google Cloud SQL, para hospedar seus bancos de dados relacionais. Essas soluções executam correções e atualizações do servidor e possuem recursos de resiliência de dados, como replicação automática e backups.

As empresas que utilizam hosts de servidores devem aproveitar o AWS Patch Management sempre que possível. Caso contrário, projete uma estratégia para instalar regularmente todas as atualizações de segurança em aplicativos, sistemas operacionais, kernels e pacotes. O Microsoft SCCM, o Redhat YUM, o Ubuntu Apt e o SLES Zypper, bem como as atualizações autônomas do Linux, fornecem os meios para corrigir os itens mencionados acima. Sempre faça o patch em um ambiente de teste antes de implantar na produção.

Os clientes podem reduzir o requisito de gerenciamento de patches de servidor implantando seu código em ofertas sem servidor orientadas a eventos, como AWS Lambda, Azure Functions ou Google Cloud Functions. Esses serviços executam código em resposta a eventos, como chamada de API ou upload de arquivo, abstraindo a infraestrutura necessária para executar aplicativos.

Além disso, pode-se aproveitar os recursos de segurança aprimorados das ofertas de API sem servidor, como o AWS API Gateway e o Azure API Management. Esses produtos não apenas fornecem uma porta de entrada segura para acessar dados e serviços de back-end, mas também uma variedade de controles de segurança para validar e autorizar chamadas de API.

Ferramentas DevOpsOs orquestradores de infraestrutura como código (IAC) de código aberto, como Terraform, ou gerentes de estado desejados, como Chef, Ansible, Salt e Puppet, podem ser usados para servir como um sistema centralizado para garantir uma arquitetura de mudança consistente e orientada por código para a infraestrutura .

Os principais fornecedores de nuvem oferecem seus próprios serviços internos, como AWS CloudFormation, Modelos do Azure ARM e Google Cloud Deployment Manager. Se os aplicativos estiverem hospedados em um ambiente híbrido, é importante procurar soluções de código aberto e de terceiros que funcionem na nuvem pública e na infraestrutura local. Além disso, o uso de qualquer uma dessas três ferramentas provavelmente significa a dependência do fornecedor da nuvem. Eles não são propícios ao gerenciamento de várias nuvens ou, se necessário, à migração.

As ferramentas mencionadas acima permitem que os codificadores de infraestrutura gerenciem serviços de segurança como NACLS, controles de ameaças e peering. Manter a infraestrutura em código significa que as alterações podem ser rastreadas com mais eficácia, testadas quanto à derivações e impor a conformidade da configuração. A execução de ferramentas do IAC que gerenciam itens e serviços de infraestrutura específicos também pode ser implantada por meio de pipelines de integração contínua (CI) e entrega contínua (CD) para controlar ainda mais as alterações. Posteriormente, o uso de ferramentas como Puppet ou Ansible

Linguagens de Programação Sem Servidor

ada uma das três principais ofertas sem servidor suporta seu próprio conjunto individual de linguagens de programação e estruturas de tempo de execução. Estes são atualmente:AWS Lambda: JavaScript (Node.js), Java, C# e PythonAzure Functions: JavaScript, C#, Java, Python, PHP, Bash, Batch e PowerShellGoogle Cloud Functions: JavaScript (Node.js)

Cuidado:

Embora as ferramentas do IAC tenham um papel essencial no cumprimento das responsabilidades de segurança na nuvem, é importante estar ciente dos perigos do código do IAC com defeito.

A configuração incorreta pode causar interrupções, abrir vulnerabilidades ou remover alterações manualmente configuradas. Adaptação e uso adequados são essenciais ao gerenciar a infraestrutura da nuvem como código.


para configurar aplicativos, servidores, contêineres ou serviços para atingir o estado desejado permite não apenas provisionar (e fortalecer) automaticamente os recursos, mas também passar de um ambiente mutável para imutável. Ambientes imutáveis contêm serviços que são totalmente sem estado e abstraídos para o componente consumido, como um serviço da web. A configuração de recursos para uma implantação imutável fornece segurança previsível e repetível, sem mencionar resiliência e flexibilidade.

Monitoramento do WorkloadUma variedade de ferramentas de monitoramento diferentes estão disponíveis para o cliente, à medida que assumem seu papel em um modelo de responsabilidade compartilhada.

Primeiro, as soluções de monitoramento e gerenciamento de inventário fornecem visibilidade total de todos os ativos da nuvem, ajudando a evitar a expansão da nuvem e mantendo as superfícies de ataque no mínimo.

Em segundo lugar, os serviços de monitoramento de aplicativos e de monitoramento de custos podem alertar os clientes sobre um pico repentino no consumo de recursos, o que poderia ser o primeiro sinal de um possível ataque.

Por fim, as plataformas de proteção de cloud workload (CWPPs) podem fornecer insights de segurança mais diretos ao ambiente de TI do cliente, monitorando o tráfego que flui entre os diferentes processos de aplicativos em execução na nuvem, analisando conexões incomuns ou não autorizadas para comportamento mal-intencionado.

Defesas TradicionaisEmbora as ferramentas de segurança tradicionais por si só não sejam suficientes para proteger os sistemas baseados na nuvem, elas ainda servem a um propósito útil no cumprimento das responsabilidades de segurança.

No entanto, lembre-se de que os métodos convencionais de segurança focados no perímetro, como firewalls e anti-malware, foram projetados para proteger ambientes estáticos. Por outro lado, a nuvem é um ambiente dinâmico, onde novas instâncias estão sendo criadas e destruídas a todos os momentos, e os endereços IP estão mudando continuamente.

Portanto, ferramentas tradicionais de segurança podem precisar ser implementadas de uma maneira nova e diferente. Isso pode exigir scripts ou automação para manter a visibilidade total sobre uma matriz complexa de partes móveis.

“As cloud workloads têm requisitos de segurança diferentes dos pontos de extremidade voltados para o usuário final, e a adoção de modelos híbridos de computação em nuvem pública / privada compõe as diferenças. Os CISOs devem implantar produtos projetados especificamente para a proteção de cargas de trabalho na nuvem híbrida.”

Gartner, “Guia do mercado para Plataformas de Proteção de Cloud Workload,” Março, 2017

ConclusãoO novo cenário de nuvem de microsserviços distribuídos e infraestrutura dinâmica mudou a ênfase da prevenção de intrusões do perímetro externo para cargas de trabalho individuais.Isso exige novas ferramentas de segurança capazes de monitorar ambientes segmentados e o tráfego de rede entre eles.Ao mesmo tempo, as cargas de trabalho de TI estão se tornando cada vez mais portáteis, permitindo a escolha de onde hospedar aplicativos com base nos requisitos de desempenho, custo e conformidade. Como resultado, são necessárias ferramentas com recursos híbridos e de várias nuvens para garantir visibilidade total nos ambientes.Mas, para usar as ferramentas de segurança de maneira eficaz, os clientes também precisam entender suas responsabilidades compartilhadas na nuvem, pois esse conhecimento pode fazer a diferença importante entre um ambiente de computação seguro e as conseqüências potencialmente devastadoras de um ataque mal-intencionado.

Sobre a GuardicoreA Guardicore é uma empresa inovadora em segurança de data center e nuvem que protege os principais ativos da sua organização usando controles de microssegmentação flexíveis, implantados rapidamente e fáceis de entender. Nossas soluções fornecem uma maneira mais simples e rápida de garantir segurança persistente e consistente - para qualquer aplicativo, em qualquer ambiente de TI.

www.guardicore.comCopyright 2019

estratégias para proteger cloud workloads com modelos de

Documents