Segurança em Containers: “big 5” tópicos

Nos últimos anos tem se tornado normativo o uso de arquitetura de microsserviços e parte viabilizadora desse modelo é o uso de containers e orquestradores (Kubernetes, Mesos, Openshift …) dos mesmos.

Assim tendo o pensamento de Security Firth, vamos falar sobre como a AWS lida com segurança e também as boas praticas de segurança em containers.

Se você ja leu algum post sobre serviços AWS, certamente já conhece sobre o modelo mais famoso da grande redes de computadores mundial: o Modelo de responsabilidade compartilhada da AWS.

  • A responsabilidade pela segurança e conformidade é compartilhada, veja no sistematizado abaixo.
    segurança de containers

Então notemos que é de responsabilidade da AWS toda parte de Fundação, ou seja, segurança de seus Data centers, atualização dos drives de sistema operacional(S.O) e outros como pode ser visto na parte laranja na figura. Já nos como cliente e usuários, temos uma parcela de responsabilidades, sendo elas criptografia, proteção do tráfego de rede, configuração de firewall, S.O, gerenciamento de chaves de segurança (Identity Access Manager), aplicativos e dados do cliente.

Os clientes são responsáveis por sua segurança e conformidade NA nuvem e a AWS é responsável pela segurança DA nuvem.

Quais são os desafios com soluções em containers ?

Essa imagem ilustra bem os desafios, e exemplifica os riscos do “novo mundo”.

segurança de containers

Os desafios são diversos e listar alguns deles:

  • Processos em execução em um host compartilhado
  • Isolamento implementado por namespaces cgroups (control groups) do Linux
  • Containers são imutáveis e possuem TTL mais curtos (cargas de trabalho efêmeras)
  • O software de segurança tradicional/legado raramente reconhece containers [Firewalls, Sistema de detecção de intrusão (IDS) /Sistema de prevenção de intrusões (IPS)]
  • Detectar e restringir fontes e conteúdos de imagens de container
  • Impedir que artefatos maliciosos entrem em imagens de container

Vamos falar sobre Principios:

– Defesa em profundidade

Defesa em profundidade é uma estratégia de adoção de diversas medidas de segurança para proteger a integridade de uma informação. Ela é usada para cobrir todos os ângulos de segurança de uma empresa, sendo redundante quando necessário.

  • Mecanismos de defesa estão em camadas
  • A abordagem em várias camadas aumenta a segurança do sistema
  • Redundâncias intencionais
  • Projetado para lidar com diferentes vetores de ataque
  • Projetado para ajudar a gerenciar riscos

– Menor Privilégio.

  • Conceda apenas os privilégios essenciais necessários para realizar o trabalho pretendido
  • Anexar permissão ao serviço de computação por meio de uma role de execução
    Prefira uma função exclusiva por aplicativo
    • Impor limites de permissão
  • Seja específico: identifique um conjunto limitado de recursos e ações permitidos
    Examinar o uso de “*”
[Fontes]
https://docs.aws.amazon.com/pt_br/wellarchitected/latest/framework/sec_permissions_least_privileges.html

https://docs.aws.amazon.com/pt_br/IAM/latest/UserGuide/access-analyzer-findings.html

https://docs.aws.amazon.com/pt_br/IAM/latest/UserGuide/access-analyzer-policy-validation.html

Falamos sobre desafios, responsabilidade e princípios, vamos falar sobre os modelos de responsabilidades dos serviços gerenciados sendo eles o AWS Elastic Container Service (ECS) e Elastic Kubernetes Service (EKS).

Vamos ver a matriz de responsabilidade(Sabendo nossos deveres construímos, engajamos preocupação e esforço no ponto exato).

Modelos de responsabilidade compartilhada do ECS

A Amazon Elastic Container Service (Amazon ECS) é um serviço de gerenciamento de contêineres altamente escalável e rápido que facilita a execução, a interrupção e o gerenciamento de contêineres em um cluster. Este guia aborda muitas das práticas recomendadas operacionais mais importantes e, ao mesmo tempo, explica os principais tópicos subjacentes ao funcionamento dos aplicativos baseados no Amazon ECS. O objetivo é fornecer uma abordagem concreta e acionável para operar e solucionar problemas de aplicativos baseados no Amazon ECS. [link]

O Amazon ECS pode ser executado instâncias autogerenciadas ou AWS Fargate, para não se estender ou deixar um outro post sobre esse tema e diferença entre eles. [link]

No que diz respeito à segurança da infraestrutura, AWS assume mais responsabilidade por AWS Fargate do que para outras instâncias autogerenciadas (AWS EC2). Com Fargate, a AWS gerencia a segurança da instância subjacente na nuvem e o tempo de execução usado para executar suas tarefas. A Fargate também dimensiona automaticamente sua infraestrutura em seu nome.

Referência
https://docs.aws.amazon.com/pt_br/AmazonECS/latest/bestpracticesguide/security-shared.html

Modelos de responsabilidade compartilhada do EKS

O Amazon Elastic Kubernetes Service (Amazon EKS) é um serviço gerenciado que você pode usar para executar o Kubernetes na AWS, sem necessidade de instalar e manter seus próprios nós ou ambiente de gerenciamento do Kubernetes. Kubernetes é um sistema de código aberto para automatizar a implantação, o dimensionamento e o gerenciamento de aplicações em contêineres.

Assim como no ECS, existe a possibilidade de ter grupos de nós auto gerenciados, Gerenciados e em Farget. Nesse ponto você já esta craque em ler o modelo de responsabilidade, veja as imagens: 

Enfim, vamos para parte mais pratica e interessante do assunto.

The Big 5 — Melhores praticas de segurança em containers

Essa serie de posts teve como base experiências vivenciadas e diversos artigos e palestras. Assim, temos em todo ponto algum link de referencia, peço que se debruce sob cada um e extraia o máximo que puder, lembre Segurança é Prioridade 0.