Crie microsserviços resilientes e seguros com microsegmentação

Este artigo foi publicado originalmente em A nova pilha.

Há cerca de 10 a 12 anos, o mundo do software passou por uma mudança nos aspectos arquitetônicos dos aplicativos corporativos. Arquitetos e desenvolvedores de software começaram a se afastar dos aplicativos monolíticos gigantes, fortemente acoplados e implantados nos data centers privados para uma arquitetura mais orientada a microsserviços hospedada na infraestrutura de nuvem pública. A natureza distribuída inerente dos microsserviços é um novo desafio de segurança na nuvem pública. Na última década, apesar da crescente adoção da arquitetura orientada a microsserviços para criar aplicativos corporativos escaláveis, autônomos e robustos, as organizações geralmente lutam para se proteger contra essa nova superfície de ataque na nuvem em comparação com os data centers tradicionais. Isso inclui preocupações com multilocação e falta de visibilidade e controle sobre a infraestrutura, bem como sobre o ambiente operacional. Essa mudança de arquitetura dificulta o cumprimento das metas de segurança, especialmente com a ênfase primordial em implantações mais rápidas baseadas em contêineres.

O objetivo deste artigo é entender o que é microssegmentação e como ela pode capacitar arquitetos de software, engenheiros de DevOps e arquitetos de segurança de TI a criar microsserviços seguros e resilientes. Especificamente, discutirei o segurança de rede desafios associados ao popular mecanismo de orquestração de contêineres Kubernetes, e ilustrarei o valor da microssegmentação para evitar movimentos laterais quando ocorre uma violação.

Desafios de segurança com implantações de microsserviços

A arquitetura orientada a microsserviços exige a divisão de aplicativos em serviços menores e fracamente acoplados. Devido à natureza distribuída desses serviços, eles geralmente acabam tendo seus próprios armazenamentos de dados. Cada um desses serviços é implantado de forma independente usando um contêiner, que oferece um mecanismo para um aplicativo empacotar tudo, desde código-objeto, bibliotecas de terceiros, sistemas operacionais, ferramentas e outras dependências. Depois que todas as necessidades são embaladas, os contêineres fornecem o ambiente de execução para executá-las sem problemas. Esses contêineres são gerenciados usando orquestradores como o Kubernetes.

De acordo com a noção popular, o ecossistema de contêineres foi projetado para reforçar a segurança por meio do isolamento. No entanto, o isolamento entre contêineres não necessariamente fornece os limites de segurança necessários. O Kubernetes oferece vários recursos de segurança, como autenticação, autorização, política de rede e padrão de segurança de pod, etc. Mas, infelizmente, nem os contêineres nem o Kubernetes oferecem segurança por padrão. As implantações do Kubernetes priorizam a funcionalidade em vez da segurança em sua configuração padrão. Portanto, um desenvolvedor ou engenheiro de confiabilidade responsável por criar, mover e destruir esses contêineres nem sempre sabe como garantir a segurança das implantações. Vamos examinar mais de perto alguns dos aspectos importantes do Kubernetes do ponto de vista da rede e da segurança:

1. Namespace: No Kubernetes, um namespace é uma forma lógica de dividir os recursos do cluster em espaço virtual entre vários usuários. Ao contrário do Linux, ele não impõe nenhuma segmentação de rede. Observe que um namespace não é um limite de segurança e, portanto, os serviços em um namespace podem acessar serviços em outro namespace.
2. Política de rede: A política de rede do Kubernetes é uma construção específica do aplicativo que permite a comunicação das camadas 3 e 4 entre namespaces, pods e blocos de endereços IP. Quando o Kubernetes é instalado, a política de rede não está disponível por padrão. É preciso instalar e configurar plug-ins de rede para aplicar políticas de rede antes que os pods sejam criados. Além disso, é importante observar que as políticas de rede não podem ser aplicadas no nível de serviço. Essa é uma lacuna significativa do ponto de vista da segurança, já que o controle de acesso não pode ser estendido aos serviços.
3. Padrão de segurança do pod: Em um cluster, os pods oferecem suporte a vários contêineres que compartilham a mesma máquina física ou virtual. Eles permitem o compartilhamento de dados e a comunicação entre os contêineres dentro do pod. Um padrão de segurança de pod permite que um administrador controle os recursos e suas permissões usando um modelo de autorização refinado. Esse controle de segurança exige um controlador de admissão, que não está ativado por padrão. Um pod privilegiado oferece acesso administrativo a todos os contêineres. Como resultado, o invasor que obtém acesso a contêineres privilegiados pode obter acesso administrativo aos recursos do host.
4. Armazenamento secreto: O Kubernetes armazena informações confidenciais e confidenciais, como senhas, tokens OAuth e chaves SSH, como segredos no formato codificado de base 64, considerado texto sem formatação. A política de autorização, usada para restringir o acesso aos segredos, não é configurada por padrão. Eles são compartilhados por meio de variáveis ambientais ou arquivos de manifesto, que também são considerados uma prática insegura para lidar com segredos. Na ausência de criptografia padrão de segredos em repouso e na falta de um gerenciamento robusto de segredos, os segredos se tornam um alvo atraente para movimentos laterais.

Movimento lateral e o insider malicioso

A natureza distribuída dos microsserviços torna a conectividade extremamente importante. Especificamente, contêineres e pods devem ser capazes de se comunicar entre si em namespaces. No entanto, as políticas de rede padrão na camada de cluster não necessariamente implementam a princípio do menor privilégio fora da caixa. Portanto, não importa como você proteja seu código, o acesso implícito não autorizado a recursos compartilhados não pode ser proibido. Como resultado, o aplicativo pode se tornar suscetível a movimentos laterais dentro do cluster. A microssegmentação permite implementar um controle de acesso granular, criando zonas seguras em torno de cada microsserviço no nível de contêiner, pod e cluster, reduzindo significativamente o raio de explosão e aumentando a resiliência para se recuperar de um ataque bem-sucedido.

A segunda ameaça proeminente que o modelo de segurança da estrutura Kubernetes existente apresenta em relação aos microsserviços é um insider malicioso. Do ponto de vista de um invasor, quando a segurança não está disponível por padrão, várias configurações incorretas são possíveis. Na ausência de políticas fortes de controle de acesso ou autorização, ataques como o Server-Side Request Forgery (SSRF) permitem que o invasor aproveite um acesso autenticado a um pod para obter acesso não autorizado a recursos em outro pod.

Conforme discutido acima, vimos que controles de segurança adequados não estão disponíveis para proteger segredos por padrão. Não criptografar e alternar segredos, bem como não restringir o acesso aos segredos, são de fato problemas não relacionados, mas na ausência de um controle de segurança (neste caso, falta de criptografia), o segundo controle de segurança (ou seja, restringir o acesso às lojas secretas) se torna crucial para evitar a exploração por um insider malicioso (por exemplo, um administrador insatisfeito).

Apresentando a resiliência cibernética com microssegmentação

No contexto da segurança, resiliência é a capacidade de se recuperar rapidamente de uma falha simples devido a ataques ou eventos catastróficos, como violações. A primeira etapa na criação de microsserviços resilientes é entender o que gostaríamos de proteger do invasor e, se o ativo ou recurso for comprometido, como podemos limitar o impacto. A microsegmentação nos ajuda a determinar os recursos que contêm dados essenciais ou sistemas críticos tolerantes a falhas e também fornece um mecanismo para bloquear o acesso com base no menor privilégio. Dessa forma, mesmo que um recurso crítico seja comprometido, os outros não serão afetados.

O ciclo de vida moderno de desenvolvimento de software de hoje dá ênfase especial ao fornecimento rápido de recursos. Esses recursos são implantados na produção por meio de contêineres de forma ainda mais rápida, principalmente pelos mesmos desenvolvedores ou DevOps. Se considerarmos todos os tipos de vulnerabilidades às quais o código de microsserviços, bibliotecas de terceiros e outras dependências, contêineres ou clusters são suscetíveis, como podemos identificar e evitar todos esses ataques? A resposta é bloquear o acesso a recursos essenciais e permitir apenas o uso da microssegmentação “com base na necessidade de conhecimento”.

Comece com a microssegmentação

Não existe uma estratégia única para começar com a microssegmentação, mas a seguir estão algumas das melhores práticas ao iniciar um projeto de microssegmentação para microsserviços:

1. Conhecendo os padrões de design de microsserviços e usando um modelo de microssegmentação

Conhecer os padrões de design facilita uma compreensão mais profunda dos componentes arquitetônicos, do fluxo de dados e dos ativos que contêm dados críticos. Com base nesses padrões de design usados com frequência, é possível criar modelos de microsegmentação correspondentes. Depois que esses modelos forem examinados pela equipe de segurança e rede, eles serão fáceis de reutilizar e escalar em um ritmo mais rápido.

Ao contrário dos aplicativos monolíticos gigantes e fortemente acoplados, os aplicativos baseados em arquitetura orientada a microsserviços seguem um ou mais determinados padrões de design. Esses padrões de design podem ser um dos seguintes:

• Os padrões de decomposição envolvem a divisão de aplicativos em subdomínios ou transações com base nos recursos de negócios.
• Os padrões de integração envolvem padrões de design de integração de serviços, como gateway de API, agregador, microsserviços em cadeia etc.
• Os padrões de banco de dados se concentram na posição dos bancos de dados na arquitetura geral dos aplicativos. Os exemplos incluem banco de dados por serviço, banco de dados compartilhado, fornecimento de eventos etc.
• Os padrões de observabilidade consistem em padrões de design que se concentram em auditoria, registro e monitoramento, como agregação de registros, rastreamento distribuído, verificação de integridade etc.
• Os padrões de preocupações transversais ajudam a gerenciar a funcionalidade em nível de aplicativo, como segurança, tolerância a falhas, comunicação de serviço a serviço e gerenciamento de configurações em um local centralizado. Os exemplos incluem disjuntor, descoberta de serviço etc.

(Para obter mais informações sobre vários padrões de design de microsserviços, consulte aqui.)

2. Selecionar a abordagem correta de microssegmentação

Atualmente, existem vários fornecedores de microssegmentação com diferentes abordagens de solução disponíveis no mercado. Em termos gerais, as técnicas de microssegmentação se enquadram em duas categorias:

1. As soluções de microssegmentação independentes de tecnologia são baseadas em agentes ou firewalls de próxima geração.
2. As soluções de microssegmentação dependentes da tecnologia são baseadas no hipervisor ou nas malhas de rede.

Os microsserviços usam uma pilha de tecnologia variada, e a implantação mais rápida exige a capacidade de escalar rapidamente. Portanto, uma solução de microssegmentação independente de tecnologia — mas especificamente adaptada para um ecossistema de contêineres capaz de segmentar clusters, pods, contêineres e serviços — seria a escolha ideal.

3. Visibilidade da rede

A capacidade de visualizar aplicativos segmentados e fluxo de tráfego é parte integrante das soluções de microssegmentação. O Visibility oferece uma visão única de toda a rede para o administrador, arquitetos de segurança e diretor de segurança (CSO).

4. Controle centralizado fácil de usar

Elaborar uma política para cada aplicativo pode ser uma tarefa assustadora no início. Isso requer uma série de conversas com os arquitetos de TI, rede e segurança. Ter um controle centralizado para facilitar a criação e a aplicação de políticas ajuda a acelerar o processo. Aproveitar os modelos de segmentação, que são personalizados de acordo com o padrão de design de microsserviços, também pode ajudar.

5. O desempenho não deve ser o gargalo

A aplicação de políticas de microssegmentação exige analisar o tráfego e implantar políticas de forma eficaz em tempo real. O atacante pode aproveitar os atrasos no desempenho para manifestar ainda mais o ataque. Portanto, é extremamente importante testar o desempenho, especialmente para microsserviços sensíveis à latência.

Conclusão

Nesta postagem do blog, discuti algumas das questões de segurança apresentadas pelos mecanismos de implantação baseados em contêineres e Kubernetes utilizados por microsserviços. A palavra “resiliência” começa a desaparecer quando implantamos continuamente os microsserviços em produção durante todo o ciclo de vida de CI/CD em um ritmo mais rápido, sem muita consideração em limitar o acesso a recursos essenciais. A microsegmentação oferece um forte mecanismo de controle de acesso que minimiza o impacto das violações. Ele também promove a resiliência nos aplicativos corporativos ao implementar microzonas seguras.

A microssegmentação, quando planejada e executada corretamente, certamente cria uma barreira robusta contra movimentos laterais no mundo dos microsserviços. É difícil proteger microsserviços com rapidez, mas é importante parar e pensar em implementar segurança e resiliência em grande escala e planejá-las proativamente com todas as partes interessadas.