Zero Trust em Nutanix: Guia de Microsegmentação e Flow

Introdução à Segurança Zero Trust em Ambientes Hyperconverged

A migração para infraestruturas hyperconverged, como a plataforma Nutanix, traz benefícios significativos em termos de escalabilidade, facilidade de gerenciamento e desempenho. No entanto, a consolidação de cargas de trabalho aumenta a superfície de ataque lógica. O modelo de segurança tradicional baseado em perímetro ("castelo e fosso") torna-se insuficiente em ambientes virtualizados dinâmicos, onde máquinas virtuais (VMs) se movem constantemente entre nós físicos.

A abordagem Zero Trust (Confiança Zero) baseiaa-se no princípio de "nunca confie, sempre verifique". Em um ambiente Nutanix, isso é alcançado através da microsegmentação, que permite definir políticas de segurança granulares no nível do hypervisor, independentemente da topologia de rede física. Este tutorial demonstra como implementar princípios Zero Trust utilizando o recurso Flow do Nutanix, garantindo que apenas tráfego autorizado flua entre as VMs.

Pré-requisitos e Arquitetura do Ambiente

Antes de configurar as políticas de segurança, é essencial entender a arquitetura básica. O Nutanix Flow opera no nível do switch virtual (vSwitch) dentro do hypervisor (AHV, ESXi ou Hyper-V), inspecionando cada pacote de dados que entra e sai da interface de rede da VM.

Para este tutorial, assumiremos o seguinte cenário:

• Hypervisor: Nutanix AHV (Acropolis Hypervisor).
• Plataforma de Gerenciamento: Prism Element ou Prism Central.
• Rede Lógica: Redes VLANs separadas para Frontend (Web) e Backend (Database).

Topologia do Ambiente:

• VM-Web: Servidor Web na rede 10.0.1.0/24 (VLAN 10).
• VM-DB: Servidor Banco de Dados na rede 10.0.2.0/24 (VLAN 20).
• Objetivo: Permitir que VM-Web acesse o VM-DB apenas na porta TCP 3306 (MySQL) e bloquear todo o resto.

Etapa 1: Verificação da Infraestrutura Existente

O primeiro passo é garantir que as VMs estejam provisionadas e conectadas às redes lógicas corretas. Utilize a linha de comando do Acropolis (acli) ou a interface gráfica do Prism para validar o estado das máquinas.

Acesse o shell do control virtual machine (CVM) ou utilize o terminal integrado no Prism Shell se habilitado. Execute o seguinte comando para listar as VMs e seus endereços IP:

acli vm.list

Verifique se a VM-Web e a VM-DB estão com status up. Em seguida, confirme as interfaces de rede associadas:

acli vm.get_vm_by_name VM-Web | grep network
acli vm.get_vm_by_name VM-DB | grep network

Se as VMs não estiverem nas redes corretas ou se o hypervisor AHV não tiver o recurso Flow habilitado globalmente, você precisará ativar o Nutanix Flow no cluster. Isso é feito via Prism Element: vá em Cluster > Settings e certifique-se de que a opção Enable Flow está marcada.

Etapa 2: Definição dos Grupos de Segurança (Security Groups)

No modelo Zero Trust, não aplicamos regras diretamente ao IP da VM, pois IPs podem mudar. Aplicamos regras a Grupos de Segurança, que são coleções dinâmicas de entidades (VMs, tags, subnets). O Nutanix utiliza Security Groups para definir quem pode falar com quem.

Crie dois grupos distintos para segmentar as cargas de trabalho:

1. Grupo Web-Servers: Contém a VM-Web.
2. Grupo DB-Servers: Contém a VM-DB.

Via CLI, crie os grupos de segurança usando o comando acls.create_sg:

acli sg.create Web-Servers
acli sg.create DB-Servers

Agora, adicione as VMs aos respectivos grupos. Supondo que você utilize tags para identificar as máquinas (recomendado para automação), ou use os nomes diretos:

acli sg.add_member Web-Servers VM-Web
acli sg.add_member DB-Servers VM-DB

Se preferir usar a interface gráfica do Prism, navegue até Flow > Security Groups, clique em Create Security Group, nomeie-o e arraste as VMs para o grupo correspondente.

Etapa 3: Configuração das Regras de Fluxo (Flow Rules)

Agora vem o cerne da implementação Zero Trust: definir as regras que permitem ou negam o tráfego. Por padrão, se nenhuma regra aplicar-se, o comportamento depende da configuração do cluster, mas a melhor prática é ser explícito.

Vamos criar uma regra de fluxo que permite apenas o tráfego MySQL entre os grupos.

Passo 3.1: Criar a Regra Permitida

Crie uma regra que permita o grupo Web-Servers se comunicar com o grupo DB-Servers na porta 3306:

acli flow.create_rule --name Allow-MySQL \
--src-group Web-Servers \
--dst-group DB-Servers \
--protocol tcp \
--dst-port 3306 \
--action ALLOW

Explicação dos parâmetros:

• --name Allow-MySQL: Nome legível da regra.
• --src-group Web-Servers: Origem da conexão.
• --dst-group DB-Servers: Destino da conexão.
• --protocol tcp: Protocolo de transporte.
• --dst-port 3306: Porta de destino (MySQL).
• --action ALLOW: Ação a ser tomada se o tráfego corresponder.

Passo 3.2: Criar Regras de Bloqueio Implícito ou Explícito

O Nutanix Flow opera com uma lógica de "primeiro match wins" (o primeiro que bate ganha) dentro da hierarquia de prioridade, mas é crucial entender a ordem de avaliação. Se você não criar regras explícitas para bloquear, o tráfego não correspondente às regras ALLOW pode ser descartado dependendo da configuração padrão do Egress.

No entanto, para fins didáticos e auditoria clara, podemos criar uma regra explícita de negação ou confiar na política padrão. A política padrão do Flow geralmente permite o tráfego se houver uma regra correspondente e nega o resto. Para garantir a segurança máxima, verifique se não há regras globais ALLOW ALL que possam sobrescrever suas restrições.

Se desejar bloquear explicitamente todo o restante do tráfego entre esses grupos (boa prática para documentação), crie uma regra de baixa prioridade:

acli flow.create_rule --name Deny-All-Between-SGs \
--src-group Web-Servers \
--dst-group DB-Servers \
--action DENY

Atenção à Ordem de Prioridade: O Nutanix avalia as regras em ordem de prioridade (número menor = maior prioridade). A regra Allow-MySQL deve ter prioridade maior (número menor) que a regra Deny-All. Por padrão, ao criar via CLI sem especificar prioridade, o sistema atribui valores sequenciais. Verifique sempre a ordem.

Etapa 4: Validação e Testes de Conectividade

Com as regras aplicadas, é hora de validar se a microsegmentação está funcionando conforme esperado. Não basta confiar na configuração; é necessário testar a conectividade real.

Teste 1: Conexão Permitida (MySQL)

Acesse a VM-Web via SSH ou console. Tente conectar ao banco de dados:

mysql -h [IP-DA-VM-DB] -u root -p

Se a configuração estiver correta, a conexão será estabelecida com sucesso. O pacote foi permitido pela regra Allow-MySQL.

Teste 2: Conexão Negada (HTTP/HTTPS)

Agora, tente acessar serviços não autorizados na VM de banco de dados, como uma página web ou serviço SSH que não deveria estar exposto à rede Web:

curl http://[IP-DA-VM-DB]:80
ssh [IP-DA-VM-DB]

A conexão deve falhar (timeout ou connection refused). Isso demonstra que, embora as VMs estejam na mesma infraestrutura hyperconverged e possivelmente na mesma VLAN física, a separação lógica no nível do hypervisor está bloqueando o tráfego indesejado.

Teste 3: Monitoramento via Prism

O Nutanix Prism oferece uma visualização poderosa das regras de fluxo. Navegue até Flow > Rules. Você verá o status das suas regras e, mais importante, métricas de tráfego.

Clique em Analytics ou Dashboard no menu Flow para ver:

• Quais VMs estão gerando tráfego.
• Se há tentativas de conexão bloqueadas (packets dropped).

Se você vir picos de pacotes "Denied" na interface, isso indica tentativas de violação da política Zero Trust sendo detectadas e bloqueadas em tempo real.

Etapa 5: Manutenção e Escalabilidade com Automação

Em ambientes dinâmicos, adicionar novas VMs manualmente é propenso a erros. Para manter a segurança Zero Trust escalável, utilize Tags e automação.

Melhor Prática: Em vez de adicionar VMs individuais aos Security Groups, adicione regras baseadas em tags.

1. Aplique a tag env:production e role:web às suas VMs Web.
2. Aplique a tag env:production e role:db às suas VMs DB.

Atualize o Security Group para incluir entidades por tag:

acli sg.add_member_by_tag Web-Servers "role:web"
acli sg.add_member_by_tag DB-Servers "role:db"

Agora, qualquer nova VM provisionada com essas tags será automaticamente incluída nas políticas de segurança. Se você desligar ou mover a VM, a política a acompanha, mantendo o modelo Zero Trust consistente.

Considerações Finais sobre Segurança em Nutanix

A implementação da microsegmentação via Nutanix Flow é um passo crítico para uma estratégia de segurança moderna. Ela elimina a necessidade de complexas ACLs de rede física e firewalls perimetrais para tráfego lateral (East-West traffic), que é onde a maioria dos ataques modernos se propaga.

Lembre-se dos seguintes pontos críticos:

• Teste sempre em modo de relatório: Antes de aplicar regras DENY em produção, use o modo "Report" do Flow para ver quais conexões seriam bloqueadas sem interromper o serviço.
• Audite regularmente: Políticas de segurança podem se tornar "dead code" (regras não utilizadas) com o tempo. Remova regras antigas para simplificar a gestão.
• Integre com SIEM: Exporte os logs de fluxo do Nutanix para seu sistema de gerenciamento de informações e eventos de segurança para análise forense.

A segurança Zero Trust não é um produto, é uma arquitetura. O Nutanix fornece as ferramentas fundamentais — virtualização leve, hipervisor unificado e microsegmentação nativa — para que você construa essa defesa em profundidade, protegendo seus dados onde eles realmente residem: nas VMs.