Protegendo os 4 Cs dos Sistemas Nativos da Nuvem: Cloud, Cluster, Contêiner e Código

A segurança nativa em nuvem adota a abordagem de defesa em profundidade e divide as estratégias de segurança utilizadas nos sistemas cloud em quatro camadas diferentes, que podem ser vistas em “Os 4Cs da segurança nativa em nuvem”.

A computação nativa em nuvem é uma abordagem de desenvolvimento de software para criar e executar aplicações escaláveis na nuvem – seja em ambientes de nuvem pública, privada, local ou híbrida. A computação nativa em nuvem aproveita o software open-source e non-open-source para implantar aplicações como microsserviços que são empacotados em contêineres individuais. Um contêiner, tal como o do Docker, é usado para empacotar todo o software e aplicações necessárias em processos executáveis isolados. Como as organizações geralmente executam vários contêineres em vários hosts, elas usam sistemas de orquestração, como o Kubernetes, que são gerenciados e implantados por meio de ferramentas de CI / CD, utilizando as metodologias do DevOps. Por fim, as tecnologias nativas em nuvem permitem que as empresas aproveitem ao máximo seus recursos na nuvem com menos sobrecarga, tempos de resposta mais rápidos e gerenciamento mais fácil.

Como qualquer tecnologia que usa várias ferramentas e plataformas interconectadas, a segurança desempenha um papel vital na computação nativa em nuvem. Se há algo que os especialistas em segurança concordam inequivocamente, é o fato de não existirem sistemas modernos de software complexos que sejam totalmente “não-hackeáveis” – não há sistema, dispositivo ou ambiente 100% impenetrável. Isso levou à aplicação da defesa em profundidade, um conceito adotado pelas forças armadas, no campo da segurança cibernética.

A defesa em profundidade utiliza múltiplas camadas de controle e estabelece barreiras de segurança através de diferentes áreas de uma organização para fornecer proteção em várias camadas, caso um de seus controles falhe ou sofra exploração. A segurança nativa em nuvem adota essa abordagem e divide as estratégias de segurança utilizadas nos sistemas nativos em nuvem em quatro camadas diferentes, como pode ser visto no diagrama abaixo chamado “Os 4Cs da segurança nativa em nuvem”.

Figura 1. Os 4 Cs de segurança nativa em nuvem

É muito importante aplicar controles de segurança a cada camada; caso contrário, poderia deixar as aplicações vulneráveis a ataques, porque cada camada fornece sua própria superfície de ataque e pode não ser protegida pelas outras camadas. Por exemplo: uma aplicação Web insegura que é atacada com uma injeção de SQL não receberá proteção das camadas externas, como visto na figura 1, sem o uso de algum software especializado de terceiros. Os defensores da cibersegurança precisam cobrir todos os cenários possíveis e proteger os sistemas de todas as maneiras possíveis. E, por mais difícil que pareça às vezes os invasores precisam encontrar apenas um problema para comprometer todo o sistema.    

Segurança em nuvem

Nesta estrutura, a camada de nuvem refere-se à infraestrutura que executa servidores. Existem muitos serviços diferentes envolvidos na configuração de um servidor no seu Cloud Service Provider  (CSP) preferido. E embora a maior parte da responsabilidade de proteger esses serviços (por exemplo, sistema operacional, gerenciamento de plataforma e configuração de rede) seja dos CSPs, o cliente ainda é responsável por verificar e configurar esses serviços, além de supervisionar e proteger seus dados. Esse modelo de responsabilidade compartilhada é essencial para entender e aproveitar ao decidir mover recursos e serviços organizacionais para a nuvem.

Estes são os problemas mais comuns encontrados nos sistemas em nuvem de hoje:

As organizações podem evitar esses problemas, seguindo as recomendações de seus provedores de nuvem e realizando auditorias regulares para garantir que tudo esteja configurado corretamente antes de serem implantados na produção e expostos à Internet.

A adoção de práticas de infrastructure as code (IaC) é uma medida eficaz que garante que os sistemas sejam criados corretamente e que suas configurações permaneçam conforme o planejado. A IaC usa código para automatizar o provisionamento adequado das arquiteturas de TI, o que permite a eliminação do provisionamento manual pelos engenheiros do DevOps, minimizando a supervisão e os erros humanos, desde que sejam seguidas as práticas recomendadas. Ferramentas como Terraform, Ansible e CloudFormation são ótimas maneiras de definir as configurações da linha de base da sua infraestrutura, incluindo as configurações de segurança. Também ajuda a garantir que essas configurações permaneçam inalteradas, a menos que alguém aprove e implante o código necessário para alterá-las.

O uso de práticas de IaC é o novo normal quando se trata de criar e construir ambientes em nuvem, e permite que as organizações aproveitem ao máximo os diferentes níveis de automação e suas velocidades de implantação. Atualmente, não há necessidade de ativar e configurar servidores manualmente – a automação é fundamental para proteger arquiteturas em nuvem.

Além disso, siga as recomendações de segurança do seu Cloud Security Provider. Aqui estão algumas das melhores práticas de segurança dos CSPs mais populares:

Amazon Web Services – https://aws.amazon.com/security/ 

Google Cloud Platform – https://cloud.google.com/security/ 

Microsoft Azure – https://docs.microsoft.com/en-us/azure/security/azure-security

As soluções que fornecem visibilidade das arquiteturas de nuvem e automatizam as verificações de segurança e compliance, como o Trend Micro™ Cloud One – Conformity auxiliam a simplificar e aperfeiçoar a segurança nessa camada.

Segurança de cluster

Ao falar sobre segurança de cluster, focaremos principalmente no Kubernetes, já que atualmente é a ferramenta de orquestração de contêiner mais utilizada, entretanto, os princípios de segurança discutidos também podem ser aplicados a outras soluções.

Existem três elementos principais de cluster com os quais as organizações precisam se preocupar:

  • Componentes de cluster. Isso está relacionado à proteção dos componentes que formam seu cluster, ou o node principal, no caso do Kubernetes. Coisas como controlar o acesso ao servidor da API e restringir o acesso direto ao etcd, que é o armazenamento de dados principal do Kubernetes, devem ser lembradas quando se trata de segurança de cluster. O Kubernetes possui um documento abrangente que discute como proteger os clusters contra acesso acidental ou malicioso. Em um artigo recente, discutimos como observamos 3.000 hosts em que o etcd foi exposto publicamente. Para evitar isso, recomendamos que os administradores da nuvem neguem o acesso por padrão e permitam tráfego apenas explicitamente. A menos que você tenha uma equipe grande e / ou quaisquer requisitos estritos de compliance, é recomendável usar serviços gerenciados por cluster, como o Azure Kubernetes Service (AKS), Elastic Kubernetes Service (EKS) ou Google Kubernetes Engine (GKE).
  • Serviços de cluster. Isso se aplica à configuração e controle de acesso adequado para os serviços em execução no cluster. Para proteger esses serviços, o Kubernetes recomenda o emprego de certas medidas de proteção, como gerenciamento de recursos e execução de serviços com o menor privilégio. Defina a autenticação e autorização adequadas para seus clusters, criptografe o tráfego usando o Transport Layer Security (TLS) e proteja as informações confidenciais usando segredos. Também recomendamos que você dê uma olhada no Center for Internet (CIS) Kubernetes Benchmark para obter mais detalhes técnicos sobre a segurança dos serviços de cluster.
  • Networking de cluster. Isso está relacionado à alocação adequada de portas para facilitar a comunicação entre contêineres, pods e serviços. É importante garantir que o modelo de rede Kubernetes seja implementado com segurança usando um Container Network Interface (CNI) que permitirá que os usuários restrinjam o tráfego de pod.

Fornecemos recomendações mais detalhadas para proteger a orquestração de contêineres em nosso guia sobre modelagem de ameaças Kubernetes.

Segurança de contêiner

Os Container Runtime Engines (CREs) são necessários para executar os contêineres no cluster. Embora o Docker seja um dos CREs mais populares, o Kubernetes também suporta outros, como o containered e o CRI-O. Há três coisas principais que as organizações precisam se preocupar com essa camada:

  • Quão seguras são suas imagens? Isso se resume a garantir que seus contêineres estejam atualizados e livres de qualquer grande vulnerabilidade que possa ser explorada por um agente de ameaça. As organizações devem proteger não apenas a imagem base, mas também garantir que as aplicações em execução em seus contêineres tenham sido varridas e verificadas. Embora existam algumas ferramentas de código aberto disponíveis para esse fim, nem todas elas podem detectar vulnerabilidades além dos pacotes do SO. Para isso, as organizações podem usar uma solução que cubra também as vulnerabilidades de aplicações, como a Deep Security ™ Smart Check.
  • Eles podem ser confiáveis? Os contêineres em execução no seu sistema são construídos a partir das imagens em seus registros? Como você pode garantir isso? Usando ferramentas de assinatura de imagem como TUF ou Notary, você pode assinar suas imagens e manter um sistema de confiança para o conteúdo de seus contêineres.
  • Eles estão executando com privilégios adequados? O princípio do menor privilégio se aplica aqui. Você só deve executar contêineres com usuários que possuam os privilégios mínimos do SO necessários para executar suas tarefas. Anteriormente, explicamos porque é uma má ideia executar contêineres privilegiados no Docker ou contêineres com todos os recursos raiz de uma máquina host.

Criamos um guia abrangente sobre como os contêineres podem ser mais bem protegidos por meio de um exame das ameaças em potencial em cada estágio do pipeline de desenvolvimento.

Segurança de código

Isso também pode ser chamado de segurança de aplicação e é a camada que as organizações têm mais controle. O código de suas aplicações é o coração dos seus sistemas, juntamente com seus respectivos bancos de dados, e geralmente são expostos à Internet – portanto, os invasores se concentrarão nisso se todos os outros componentes estiverem protegidos adequadamente. Então, como as organizações podem garantir que suas aplicações sejam codificadas de maneira adequada e segura quando eles têm dezenas, centenas ou talvez milhares de desenvolvedores escrevendo e implantando código todos os dias em seu ambiente de produção?

Primeiro, as organizações devem garantir que todas as comunicações sejam feitas usando TLS Encryption, mesmo entre serviços internos, tais como balanceadores de carga, servidores de aplicações e databases. Ao usar uma ferramenta de orquestração como o Kubernetes, serviços como o Istio ou o Linkerd podem ser aproveitados.

As organizações podem reduzir bastante a superfície de ataque de seus sistemas limitando e monitorando serviços, portas e endpoints de API expostos. Aqui, é importante pensar também nas imagens base do contêiner e nos sistemas nos quais seus clusters estão em execução.

Existem várias verificações de segurança de código que você pode adicionar ao pipeline para garantir que seu código esteja protegido. Aqui estão alguns deles:

  • Análise de segurança de aplicações estáticas. Também chamada de “revisão de código de segurança” ou “auditoria de código”, essa ainda é uma das melhores e mais rápidas maneiras de detectar problemas de segurança em seu código. Independentemente do idioma que você está usando, você deve ter pelo menos uma ferramenta de análise estática incorporada ao seu pipeline que verifique práticas de codificação inseguras toda vez que seus desenvolvedores confirmarem um novo código. A Fundação Open Web Application Security Project (OWASP) possui uma lista de ferramentas comerciais e de open-source projetadas para analisar o código-fonte e / ou código compilado para detectar falhas de segurança.
  • Análise de segurança de aplicações dinâmicas. Embora a análise dinâmica só possa ser feita quando você tiver uma aplicação em execução para testar, também é uma boa ideia executar varreduras e verificações automatizadas para testar ataques de aplicações comuns, como injeção de SQL, cross-site scripting (XSS), e cross-site request forgery (CSRF). Essas ferramentas também testam a resiliência de sua aplicação, contêiner e cluster quando confrontadas com uma série de carga inesperada e solicitações mal formadas. O OWASP possui uma ferramenta de análise dinâmica que também pode ser automatizada e incorporada ao seu pipeline chamada OWASP Zed Attack Proxy (ZAP).
  • Análise de composição de software. Entre 70% e 90% de todas as aplicações nativas em nuvem são feitas de bibliotecas ou dependências de terceiros. Esses são pedaços de código – código provavelmente escrito por alguém de fora da sua organização – que são incorporados e executados nos seus sistemas de produção. Esses códigos geralmente não são verificados durante a fase de análise estática. Ferramentas como a dependency-check do OWASP podem ser usadas para verificar bibliotecas desatualizadas ou vulneráveis no seu código.  Snyk também oferece verificação gratuita de terceiros para projetos de open source.

As quatro camadas de sistemas nativos em nuvem são vitais para manter as aplicações seguras – e deixar apenas uma delas exposta aos invasores lhes dará o impulso necessário para comprometer todo o sistema. Garantir que seu sistema nativo em nuvem seja resiliente é essencial para manter sua organização produtiva, dinâmica e, em fim, no topo.

Soluções de segurança em nuvem da Trend Micro

Soluções de segurança específicas para nuvem, como o Trend Micro ™ Hybrid Cloud Security, podem ajudar a proteger os sistemas nativos em nuvem e suas várias camadas. Ele é desenvolvido pela Trend Micro Cloud One ™, uma plataforma de serviços de segurança para criadores de nuvens que fornece proteção automatizada para o pipeline e aplicações de CI / CD. Também ajuda a identificar e resolver problemas de segurança mais rapidamente e melhorar o tempo de entrega para as equipes de DevOps. Inclui:

Category: Cibersegurança
Tags: , ,
Magno Logan

Categorias

Veja outras publicações

Menu