Aproveitando a linguagem natural para definir e simplificar as políticas de microssegmentação

Dos três recursos básicos em qualquer data center ou nuvem — computação, armazenamento, rede — a rede foi a que mais demorou a evoluir para o mundo moderno da virtualização e abstração de recursos. Isso ocorre principalmente por design. Pode-se argumentar que a malha de rede é o recurso mais crítico em qualquer arquitetura de data center ou nuvem. Sem uma rede, a computação e o armazenamento são ilhas inacessíveis. A rede permite o acesso e a comunicação entre todos os recursos de computação e armazenamento, entre eles mesmos e os usuários finais desses recursos. Sem a rede subjacente a qualquer arquitetura, todas as conversas na nuvem não têm sentido. Não importa até que ponto você abstraia as conversas na nuvem em torno de recursos de computação, do bare-metal ao sem servidor, se houver um pacote IP em qualquer lugar da imagem, a rede é fundamental.

A segurança da rede agora é definida usando linguagem natural, não linguagem de rede.

Isso é senso comum, e a rede tem suas próprias formas de virtualização de recursos destinadas a resolver problemas específicos de rede. Ainda assim, é mencionado aqui pelo simples fato de que a segurança em data centers ou implantações em nuvem tem sido tradicionalmente implementada na rede. Para bloquear ou ativar o tráfego de rede em trânsito entre os recursos da nuvem, um firewall é implantado em algum lugar na estrutura da rede. O software de endpoint pode ser implantado em recursos de computação, que geralmente são ferramentas baseadas em assinaturas que procuram malware conhecido ou mau comportamento, mas geralmente inspecionam o tráfego, não o bloqueiam ou permitem. A maioria das cargas de trabalho tem algum tipo de recurso de firewall embutido, como o iptables no Linux, mas orquestrar essas ferramentas em grande escala geralmente é difícil de gerenciar e, portanto, não é usado. Então, segurança de rede e a fiscalização do tráfego é tradicionalmente feita com firewalls de rede.

A segurança geralmente é definida em um idioma diferente

Como os firewalls geralmente são gerenciados por equipes de rede, a política de segurança geralmente é definida usando termos familiares às equipes de rede. Os firewalls existem há décadas e a forma como eles são configurados mudou minimamente ao longo dos anos. As regras de política são tradicionalmente escritas usando endereços IP, portas TCP/UDP, VLANs e zonas. Os firewalls geralmente não são projetados para examinar mais profundamente a carga útil de dados dos pacotes para inspecionar quais conteúdos ou aplicativos estão contidos, pois eles querem evitar que se tornem um gargalo de tráfego de rede.

Existem os chamados firewalls de próxima geração (NGFW) que têm a capacidade de inspecionar pacotes com muito mais profundidade na velocidade do fio e podem definir políticas em relação ao que realmente está contido na carga útil de dados de um pacote, e não apenas em seus cabeçalhos de rede. Mas, como os velhos hábitos são difíceis de eliminar, a realidade é que, muitas vezes, esses firewalls são configurados da maneira antiga, com as opções da próxima geração deixadas sem uso. O resultado é um dispositivo que usa terminologia de rede para definir segurança de rede, que não é como os usuários de recursos hospedados em um data center ou em uma nuvem percebem esses recursos. Os usuários geralmente não sabem ou não se importam com o segmento de rede em que um recurso está hospedado. Eles estão preocupados com o recurso em si.

A política de rede deve refletir como os usuários percebem os recursos que estão sendo protegidos

Quando um usuário ou desenvolvedor relata um problema, como não conseguir acessar um recurso hospedado em um data center ou nuvem, ele geralmente se refere à carga de trabalho ou aplicativo específico que está inacessível. Eles geralmente não relatam que um endereço IP específico não pode ser acessado por uma porta específica. No entanto, a rede ou operações de segurança as equipes solicitarão essas informações. E é aqui que surge o problema: O problema relatado está em um idioma diferente dos dispositivos que estão aplicando a política de rede. A linguagem do aplicativo geralmente não é igual à linguagem da rede.

Um detalhe importante na busca de automatizar o maior número possível de recursos em arquiteturas de nuvem é a capacidade de definir a política de rede usando os mesmos termos que os usuários percebem que os recursos que estão sendo protegidos. Se um firewall estiver aplicando uma política entre os aplicativos X, Y e Z, ele deverá ser capaz de definir uma política específica para esses aplicativos, e não específica para o recurso de rede em que está hospedado.

Isso é especialmente relevante em infraestruturas modernas hospedadas em nuvem pública, como microsserviços, nas quais os endereços IP são efêmeros. As cargas de trabalho e os aplicativos geralmente são migrados dinamicamente em diferentes segmentos de rede, portanto, um endereço IP não é mais uma forma confiável de identificar qualquer carga de trabalho específica para o ciclo de vida desse recurso. Se você precisar modificar um firewall toda vez que um endereço IP for alterado, isso não é escalável.

O resultado é que, muitas vezes, os firewalls simplesmente não são implantados em arquiteturas de nuvem modernas. Em vez disso, eles são relegados a ficar no perímetro de uma estrutura de nuvem, impondo apenas o tráfego norte-sul, cegos para a maioria do tráfego leste-oeste.

Defina a segurança usando metadados, não IPs

A maioria dos controladores SDN modernos pode criar o que equivale a um banco de dados local de IPs e metadados de carga de trabalho que é aplicado a cada carga de trabalho. Por exemplo, se cinco cargas de trabalho de produção forem servidores SQL e outras cinco cargas de trabalho forem servidores SQL de desenvolvimento, o controlador criará um registro local que lista esses servidores em duas categorias, com os primeiros cinco IPs de carga de trabalho atribuídos a uma tag de metadados “SQL-Prod” e os segundos cinco IPs de carga de trabalho atribuídos a uma tag de metadados “SQL-dev”. O controlador monitorará essas cargas de trabalho e, se alguma carga de trabalho mudar seu IP por qualquer motivo, ou se for desativada, a controladora atualizará seus registros locais de mapeamentos de metadados para IP.

Dessa forma, o controlador pode rastrear todo o ciclo de vida da carga de trabalho com base nos metadados atribuídos a ela, independentemente do endereço IP atribuído a ela. O encaminhamento de pacotes de e para as cargas de trabalho ainda é realizado usando pesquisas de IP, usando o endereço IP atualmente atribuído. Mas a identidade dessa carga de trabalho é mantida pelos metadados atribuídos, independentemente do segmento de rede ao qual ela está atribuída.

Identificar uma carga de trabalho usando metadados permite que a identidade dessa carga de trabalho seja totalmente abstraída de qualquer detalhe da rede — é assim que a segurança moderna precisa ser definida. Definir uma política que diz algo como “Nenhum servidor SQL em desenvolvimento pode iniciar contato com servidores SQL em produção” está muito mais perto de como os usuários percebem esses recursos do que algo como definir uma política como “permissão 192.168.10.0/24 TCP 1024-2000 10.10.0.0/16". Os termos de metadados são muito mais legíveis por humanos do que os termos de rede.

O uso de metadados para identificar recursos geralmente é chamado de “tags” ou “rótulos”. E esse conceito é usado por outros controladores além do SDN. Com Iluminação ASP, você pode atribuir um rótulo a cada carga de trabalho, e cada rótulo tem quatro “dimensões”: função, aplicativo, ambiente e localização. Cada carga de trabalho pode receber um rótulo que a identifique em uma ou todas essas dimensões, e a política pode então ser definida usando esses rótulos. Portanto, um conjunto de regras do Illumio não se refere a portas ou IPs; ele se refere a rótulos.

O valor dos rótulos Illumio

O conceito de rótulos pode parecer um pequeno detalhe, mas vale a pena enfatizar. Usando rótulos, você pode definir políticas usando os mesmos termos de como os usuários percebem os recursos que estão sendo protegidos. Essa é uma mudança significativa em relação à forma como a segurança de rede é tradicionalmente definida. Durante décadas, a segurança de rede foi definida em torno de construções de rede: IPs, VLANs e portas. Os firewalls veem a segurança através das lentes dessas construções de rede e, se alguma dessas construções mudar, a configuração do firewall precisará ser modificada.

Mas se a política for definida usando rótulos e esses rótulos resultarem na configuração dos recursos de firewall integrados da carga de trabalho para impor essa definição em segundo plano, a política agora corresponde à forma como os recursos são realmente usados. A segurança da rede agora é definida usando linguagem natural, não linguagem de rede. E essa política de linguagem natural é definida uma vez, permanecendo silenciosa mesmo quando as cargas de trabalho migram entre estruturas de rede, são reduzidas ou aumentadas ou ampliadas para grandes implantações.

A segurança não deve ser um obstáculo aos requisitos de escalabilidade da carga de trabalho. O uso de linguagem natural para definir políticas — usando rótulos — permite a evolução da carga de trabalho sem que a segurança atrase o processo de DevOps.

Então, estou usando rótulos: e agora?

Mesmo que as equipes de rede se acostumem a definir políticas usando rótulos de linguagem natural, a fim de criar uma linguagem mais legível por humanos, a mentalidade por trás da definição da política ainda costuma ser centrada na rede. Embora os rótulos se refiram a cargas de trabalho e aplicativos, as equipes de rede ainda consideram os limites de confiança como limites de rede. Mas, à medida que mais e mais empresas adotam um Confiança zero mentalidade, uma característica importante exige que as organizações afastem os limites de confiança da rede e diretamente para os recursos aos quais os rótulos se referem. Se você tiver cinco cargas de trabalho SQL, cada uma dessas cargas de trabalho é seu próprio limite de confiança. O limite de confiança não é um segmento de rede comum que todos possam estar compartilhando.

A Illumio implanta agentes, conhecidos como FORNOs, em cada carga de trabalho monitorada, e esses agentes traduzem a política baseada em rótulos em regras no firewall embutido em cada carga de trabalho. Então, o primeiro passo na vida de um pacote, em seu nascimento, é a política. Outra forma de pensar sobre o Zero Trust é: “nenhum pacote deve alcançar o plano de encaminhamento de rede até que seja inspecionado”. Com o Illumio, quando um pacote chega ao plano de encaminhamento de rede, a segurança já foi aplicada.

Isso é especialmente importante ao tentar resolver o problema de movimento lateral, que permite que agentes mal-intencionados ou malwares atravessem uma rede sem serem detectados. Ao discutir diretrizes de segurança com usuários remotos, por exemplo, a necessidade de segurança geralmente é reconhecida, mas uma resposta comum é “Não tenho nada a esconder”, que é usada como justificativa para não se preocupar em proteger uma carga de trabalho. Embora esse usuário possa não ter nada a esconder, outra pessoa pode. O malware geralmente viola uma carga de trabalho com o propósito específico de passar dessa carga de trabalho para outras cargas de trabalho, sendo o destino um recurso mais valioso. Isso é movimento lateral, usando uma carga de trabalho como plataforma de lançamento para outra carga de trabalho.

Se um limite de confiança for um segmento de rede e o malware violar uma das várias cargas de trabalho nesse segmento de rede, ele poderá se mover lateralmente entre cargas de trabalho que compartilham um segmento sem que o firewall da rede perceba nada. O movimento lateral precisa ser evitado em cada carga de trabalho, não na estrutura da rede.

Os rótulos são úteis para tornar a política mais fácil de entender e manter o objetivo final em foco: levar a solução de segurança ao que você está tentando proteger. Não confie em uma camada de uma arquitetura de nuvem para proteger uma camada diferente. Seus limites de confiança estão onde quer que suas cargas de trabalho estejam. Zero Trust significa que cada carga de trabalho é um segmento e, se você proteger cada carga de trabalho, reduzirá drasticamente o risco de movimento lateral.

Para saber mais sobre o Illumio ASP e como pensamos sobre rotulagem, confira:

• Novo vídeo sobre o poder dos rótulos
• O Guia de design do Illumio ASP