Operacionalizando o Zero Trust — Etapa 5: Projetar a política

Esta série de blogs expande as ideias apresentadas em minha postagem de março,”Zero Trust não é difícil... Se você é pragmático.”

Nesse post, descrevi seis etapas para alcançar o Zero Trust e, aqui, gostaria de expandir uma dessas etapas, a saber, a elaboração da política. Mostrarei como essa etapa pode apoiar a implementação de uma estrutura sólida que pode ser usada por qualquer profissional de microssegmentação para tornar seus projetos mais bem-sucedidos, independentemente do tamanho da organização.

Antes de começar, aqui está uma atualização sobre as seis etapas:

Etapa 5: Projetar a política

Na última postagem nesta série, examinei “prescrever quais dados são necessários”. Neste artigo, fiz a seguinte observação:

“Um dos aspectos mais importantes do Zero Trust — e ele não recebe tanta cobertura quanto deveria — é que a implementação efetiva do Zero Trust depende do acesso a informações contextuais, ou metadados, para ajudar a formular políticas. Portanto, ao falar sobre microssegmentação no contexto da proteção de cargas de trabalho, os metadados mínimos fora de um relatório de tráfego padrão de que você precisa descrevem as cargas de trabalho no contexto de seus aplicativos e ambientes de data center.”

Com base nessa afirmação, os três principais dados de que precisamos são:

1. Eventos de trânsito em tempo real para as cargas de trabalho que queremos proteger.
2. Dados de contexto para cada carga de trabalho e conexão — isso inclui metadados associados à carga de trabalho que viriam de um sistema de registro, como um CMDB, e também informações como detalhes do processo de comunicação provenientes diretamente da carga de trabalho. '
3. Um mapa de dependência de aplicativos (derivado dos itens 1 e 2) que permite que um proprietário de aplicativo ou profissional de segmentação visualize rapidamente as dependências upstream e downstream de um aplicativo específico.

Juntando tudo

Agora você está quase pronto para criar essa política, mas deixe-me lembrá-lo dos objetivos:

• Você quer criar uma política de microssegmentação para proteger suas cargas de trabalho.
• Você quer que essa política siga os princípios do Zero Trust.
• Portanto, as regras que você cria devem permitir somente o acesso às cargas de trabalho necessárias para realizar suas funções comerciais.

Seguindo os dados que eu disse serem “necessários”, abaixo você verá exemplos de algumas entradas do registro de tráfego que podem ser usadas para criar uma política:

Conexão de registro de tráfego 1:

• Fonte: 10.0.0.1, 10.0.0.2
• Contexto de origem: servidor Web, aplicativo de pagamentos, produção, Reino Unido
• Destino: 192.168.0.1
• Destino: contexto: respondente de DNS, infraestrutura de DNS, produção, Reino Unido ou Processo de destino: nomeado
• Porta: 53
• Protocolo: UDP
• Ação: Permitir

Conexão de registro de tráfego 2:

• Fonte: 10.0.0.1,10.0.0.2
• Contexto de origem: servidor Web, aplicativo de pagamentos, produção, Reino Unido
• Destino: 10.0.1.5,10.0.1.6, 10.0.1.7
• Contexto de destino: servidor de aplicativos, aplicativo de pagamentos, produção, Reino Unido
• Processo de destino: tomcat
• Porta: 8080
• Protocolo: TCP
• Ação: Permitir

Conexão de registro de tráfego 3:

• Fonte: 10.0.1.5, 10.0.1.6,10.0.1.7
• Contexto de origem: servidor de aplicativos, aplicativo de pagamentos, produção, Reino Unido
• Destino: 192.168.0.1
• Destino: Contexto: Respondente de DNS, Infraestrutura de DNS, Produção, Reino Unido
• Processo de destino: nomeado
• Porta: 53
• Protocolo: UDP
• Ação: Permitir

Conexão de registro de tráfego 4:

• Fonte: 10.1.0.1,10.1.0.2
• Contexto de origem: servidor Web, aplicativo de pagamentos, produção, Alemanha
• Destino: 10.0.1.5,10.0.1.6, 10.0.1.7
• Contexto de destino: servidor de aplicativos, aplicativo de pagamentos, produção, Reino Unido
• Processo de destino: httpd
• Porta: 80
• Protocolo: TCP
• Ação: Permitir

Conexão de registro de tráfego 5:

• Fonte: 10.1.2.1,10.1.2.2
• Contexto de origem: servidor de banco de dados, aplicativo de pagamentos, produção, Alemanha
• Destino: 10.0.1.5,10.0.1.6, 10.0.1.7
• Contexto de destino: servidor de aplicativos, aplicativo de pagamentos, produção, Reino Unido
• Processo de destino: httpd
• Porta: 80
• Protocolo: TCP
• Ação: Permitir

Usando isso, você pode derivar rapidamente o mapa de dependências do aplicativo.

‍

Até agora, tudo bem.

Agora, você pode examinar o mapa de dependências do seu aplicativo para determinar quais fluxos você realmente deseja permitir. Com base no conhecimento do seu aplicativo, você sabe que os seguintes fluxos são necessários, por exemplo:

1. Servidor Web, pagamentos, produção, Reino Unido -> Respondente DNS, infraestrutura de DNS, produção, Reino Unido em 53/udp
2. Servidor de aplicativos, pagamentos, produção, Reino Unido -> Respondente de DNS, infraestrutura de DNS, produção, Reino Unido em 53/udp
3. Servidor Web, pagamentos, produção, Reino Unido -> Servidor de aplicativos, pagamentos, produção, Reino Unido em 8080/tcp

Você também sabe que os dois fluxos a seguir não parecem corretos e, portanto, não devem ser incluídos em suas regras iniciais:

1. Servidor Web, pagamentos, produção, Alemanha -> Servidor de aplicativos, pagamentos, produção, Reino Unido em 80/tcp
2. Servidor de banco de dados, pagamentos, produção, Alemanha -> Servidor de aplicativos, pagamentos, produção, Reino Unido em 80/tcp

O mapa de dependências do aplicativo que você usará para criar regras ficará assim:

‍

‍

Agora, como você realmente expressa essas regras? Com os firewalls tradicionais, você seria forçado a defini-los usando endereços IP de origem e destino. Mas fazer isso dessa forma remove completamente todas as informações contextuais ricas das quais você se beneficiou ao descobrir esses fluxos e, pior ainda, significa que esse contexto deve ser reinserido quando a regra for analisada. Além disso, o que acontece quando você adiciona um Respondente DNS adicional ou um novo servidor de aplicativos ou servidor Web para o aplicativo de pagamentos?

Lembre-se de que você está tentando criar uma política que siga os princípios do Zero Trust, ou seja, garantir que seja sempre o menor privilégio. Uma abordagem baseada em contexto, com um mecanismo de segurança adaptável fazendo sua mágica em segundo plano, facilita exatamente isso. Portanto, assim como sua política se expande para incorporar um novo servidor ao contexto existente, você também desejará que sua política seja reduzida ao desativar um servidor. Se você aposentar um dos seus respondentes de DNS, por exemplo, desejará que todas as regras que anteriormente permitiam o acesso de/a partir dele sejam atualizadas para que esse acesso não seja mais possível. Isso é exatamente o que é Illumio Policy Compute Engine O objetivo do (PCE) é: a política de microssegmentação é definida usando metadados, e o PCE determina quais cargas de trabalho correspondem aos metadados naquele momento específico para então computar as regras reais que precisam ser aplicadas em cada carga de trabalho para manter sua postura de segurança Zero Trust. Sempre que há uma mudança no contexto, o PCE adapta a política e notifica as cargas de trabalho sobre atualizações.

Com isso em mente, sua política de Zero Trust se resume às seguintes regras:

Regra 1:

• Fonte: Servidor Web, Pagamentos, Produção, Reino Unido
• Destino: Respondente de DNS, Infraestrutura de DNS, Produção, Reino Unido
• Serviço de destino: 53/udp
• Processo de destino: nomeado

Regra 2:

• Fonte: App Server, Pagamentos, Produção, Reino Unido
• Destino: Respondente de DNS, Infraestrutura de DNS, Produção, Reino Unido
• Serviço de destino: 53/udp
• Processo de destino: nomeado

Regra 3:

• Fonte: Servidor Web, Pagamentos, Produção, Reino Unido
• Destino: servidor de aplicativos, pagamentos, produção, Reino Unido
• Serviço de destino: 8080/tcp
• Processo de destino: tomcat

E é isso.

Pronto para dar o próximo passo em sua jornada com o Zero Trust? Visita nossa página sobre como operacionalizar sua estratégia Zero Trust com microssegmentação para obter informações privilegiadas.