Modelo de diagrama de arquitetura de rede zero trust

Muitos diagramas com o rótulo “zero trust” são diagramas de perímetro com um título novo: um firewall na borda, uma DMZ e um interior confiável. Um diagrama de arquitetura zero trust útil responde a três perguntas num relance: onde cada decisão de acesso é tomada, quais sinais alimentam essa decisão e onde ela é aplicada? Se a imagem não responde a isso, ela descreve localização na rede, não confiança.

A seguir: o modelo lógico do NIST SP 800-207, regras de desenho que um revisor consegue verificar, erros comuns e um modelo gratuito que você pode copiar para o Archboard.

O modelo do NIST SP 800-207

O NIST SP 800-207 define a arquitetura zero trust (ZTA) em torno de uma ideia: nenhuma confiança implícita baseada na localização de rede ou na propriedade de um ativo. O acesso a cada recurso é concedido por sessão, decidido por política dinâmica e aplicado antes de o sujeito chegar ao recurso.

Os três componentes lógicos

Juntos, PE e PA formam o Policy Decision Point (PDP). Em sistemas reais, o PE pode ficar dentro de um proxy ciente de identidade ou do plano de controle de um service mesh, e os PEPs são gateways, sidecars, agentes ou proxies. Mesmo assim, o diagrama deve deixar cada papel visível, ainda que um único produto cumpra dois deles.

As fontes de dados por trás da decisão

O SP 800-207 lista as entradas que um PE pode usar. As que devem aparecer em quase todo diagrama:

• Provedor de identidade / gestão de identidades: usuários, identidades de serviço, grupos, força da autenticação.
• Postura do dispositivo (CDM): dados de diagnóstico e mitigação contínuos: o dispositivo é conhecido, gerenciado, atualizado?
• Threat intelligence: feeds sobre novos ataques, contas comprometidas e vulnerabilidades.
• Logs de atividade e SIEM: atividade de rede e de sistemas coletada e analisada; é aqui que começa o ciclo de feedback.
• PKI corporativa: certificados para usuários, dispositivos e workloads.

O padrão também cita políticas de acesso a dados e requisitos de conformidade; desenhe-os se eles influenciam decisões reais.

Como desenhar um diagrama de arquitetura zero trust

1. Coloque um PEP em todo caminho de acesso

Siga cada seta de um sujeito (usuário, dispositivo, serviço) até um recurso. Cada uma precisa passar primeiro por um ponto de aplicação. Se uma seta pula o PEP, ou o diagrama está errado ou a arquitetura tem uma brecha. Inclua os caminhos de administração, de CI/CD e de acesso emergencial (break-glass), não só o do usuário.

2. Mostre os sinais de identidade e de dispositivo alimentando a decisão

Desenhe o provedor de identidade, a postura do dispositivo, a threat intel e o SIEM como nós ligados ao Policy Engine. Rotule as conexões com o que trafega: “usuário + grupos (OIDC)”, “conformidade do dispositivo”, “sinais de risco”.

3. Deixe explícitas a authN e a authZ por sessão

O NIST descreve o acesso como concedido por sessão; muitas implementações reavaliam a cada requisição. Em qualquer caso, mostre a sequência: o sujeito pede acesso, o PEP consulta o PDP, o PE avalia, o PA configura o PEP e o PEP permite ou bloqueia a sessão. Rótulos numerados nas conexões bastam; adicione um pequeno diagrama de sequência se precisar de mais detalhe.

4. Separe o plano de controle do plano de dados

Coloque PE, PA e fontes de dados em uma região, e sujeitos, PEPs e recursos em outra. Entre as duas só passam o canal de controle do PA para o PEP, os fluxos de sinais e o fluxo de logs.

5. Mostre a microssegmentação e o tráfego leste-oeste

Zero trust não se resume a usuários acessando aplicações. Para o tráfego entre serviços, desenhe:

• a identidade do workload (por exemplo, certificados vinculados a uma service account),
• mTLS entre serviços e a CA ou PKI que emite esses certificados,
• a política de segmentação entre workloads, como uma NetworkPolicy do Kubernetes.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: orders-allow-from-checkout
  namespace: orders
spec:
  podSelector:
    matchLabels:
      app: orders
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: checkout
          podSelector:
            matchLabels:
              app: checkout
      ports:
        - protocol: TCP
          port: 8443

Uma NetworkPolicy atua nas camadas 3 e 4 e só tem efeito se o seu plugin CNI a aplicar. Ela é segmentação, não autenticação, então combine-a no diagrama com mTLS e autorização em um PEP.

6. Desenhe secrets e certificados como peças de primeira classe

Mostre o vault (gerenciador de secrets) e a PKI como nós separados. Desenhe quais workloads buscam quais secrets e com qual identidade. No modelo do NIST, as credenciais específicas de sessão vêm do PA, então conecte-as ao fluxo de decisão.

7. Mantenha o WAF e os firewalls, no lugar certo

Zero trust não elimina o WAF nem os firewalls. Eles continuam filtrando na borda e entre segmentos, mas não tomam a decisão de confiança. Desenhe-os como filtros no caminho, não como o muro em volta de uma zona confiável.

8. Feche o ciclo com logging

Todo PEP e todo firewall deve enviar logs para o SIEM, e a análise deve voltar para o Policy Engine. Sem essa conexão, falta na imagem o “contínuo” da verificação contínua.

Erros comuns

• Castelo e fosso, com outro rótulo. Um firewall externo grosso, uma “rede interna confiável” e nenhum controle entre serviços internos.
• Sem fluxo de decisão. O IdP e um gateway estão no canvas, mas nada mostra onde a decisão é tomada nem o que ela consome.
• Sem ciclo de feedback. Os logs não vão a lugar nenhum, ou o SIEM é um beco sem saída, sem conexão de volta para a política.
• Só norte-sul. O acesso de usuários a aplicações está coberto; os caminhos entre serviços e de administração para a infraestrutura, não.
• Zonas desenhadas como confiança. Usar Frames para segmentos é ótimo, mas chame-os de segmentos ou domínios de aplicação, não de “confiáveis”.

Monte no Archboard

Os packs integrados cobrem todas as peças. O pack Security tem nós para provedor de identidade, WAF, firewall, gateway zero trust, vault e certificados. O pack Network traz Internet, DNS, load balancer, e VPC e subnet como frames. O pack Kubernetes acrescenta Namespace (desenhado como frame), Service, Pod e NetworkPolicy. Os nós têm portas, então cada conexão se prende a um lado específico do nó em vez de flutuar sobre uma forma.

1. Organize os planos com Frames. Adicione dois Frames do pack Core, “Control plane” e “Data plane”. Dentro do plano de dados, adicione um Frame por segmento, por exemplo “Edge”, “App segment” e “Data segment”. Para workloads Kubernetes, use o nó Namespace.
2. Adicione os sujeitos e a borda. Coloque um nó Internet do pack Network para os usuários, depois um nó WAF do pack Security e o nó de gateway zero trust como PEP do acesso de usuários.
3. Adicione a decisão e suas entradas. No frame do plano de controle, coloque o nó de provedor de identidade e nós Box do pack Core rotulados “Policy Engine”, “Policy Administrator”, “Device posture (CDM)”, “Threat intel” e “SIEM”.
4. Ligue o fluxo de decisão. Conecte as fontes de sinais ao Policy Engine, o Policy Engine ao Policy Administrator e o Policy Administrator a cada PEP. Rotule as conexões.
5. Adicione os caminhos leste-oeste. Dentro de cada Namespace, adicione nós Service e Pod e um nó NetworkPolicy. Adicione um nó de certificado para o emissor mTLS e um nó vault para os secrets, ligados aos workloads que os usam.
6. Coloque firewalls entre segmentos. Use o nó firewall do pack Security onde o tráfego cruza frames de segmento.
7. Feche o ciclo. Desenhe conexões de cada PEP e firewall para o SIEM, e do SIEM de volta para o Policy Engine.
8. Escreva as premissas no canvas. Use um bloco Markdown para as regras de política e a duração das sessões, com um bloco de código YAML delimitado dentro dele para a NetworkPolicy.

Um diagrama completo assim pode passar do limite de 15 nós de diagrama por diagrama do plano Free; notas e textos contam à parte, até 150. No Free, divida-o em uma visão geral e um diagrama de detalhe do Kubernetes; o Pro remove o limite de nós. Você pode exportar SVG ou PNG (com marca d'água no Free), compartilhar um link público e exportar o JSON estruturado para guardar junto ao seu código de infraestrutura.

O modelo gratuito

O exemplo Zero Trust Perimeter mostra usuários entrando por um WAF na borda, um nó IdP / SSO conectado via OIDC, um gateway zero trust, um firewall de segmento, um vault de secrets e uma PKI mTLS em volta de uma aplicação privada. Abra e copie para o seu espaço de trabalho com Usar este exemplo. Depois, amplie com o frame do plano de controle, as fontes de sinais e o ciclo de logging deste artigo. Para a rede por baixo, veja o exemplo de rede de data center e o caso de uso de diagramas de rede.

Checklist e perguntas frequentes

Antes de compartilhar o diagrama, confira se:

• todo caminho de sujeito a recurso passa por um PEP,
• sinais de identidade, dispositivo, ameaças e logs alimentam o Policy Engine,
• plano de controle e plano de dados estão visivelmente separados,
• o tráfego leste-oeste mostra mTLS e segmentação,
• secrets e PKI mostram quem busca o quê,
• logs de PEPs e firewalls vão para o SIEM e voltam para a política.

Um diagrama de arquitetura zero trust é só um diagrama de rede? Não. Um diagrama de rede mostra para onde os pacotes vão. Um diagrama ZTA acrescenta onde o acesso é decidido, com quais sinais e onde é aplicado.

Ainda preciso de firewalls em um projeto zero trust? Sim. Firewalls e WAFs continuam reduzindo a exposição; eles só deixam de ser o motivo pelo qual algo é considerado confiável.

Uma NetworkPolicy do Kubernetes me dá zero trust? Não sozinha. Ela oferece segmentação L3/L4. Você ainda precisa de identidade de workload, mTLS, autorização em um PEP e logging.

Comece grátis — um assento, sem cartão de crédito.