Segurança de rede

Segurança na comunicação entre serviços: TLS, mTLS, service mesh, políticas de rede e segmentação em arquiteturas distribuídas.

Por que a rede é um vetor de ataque

Em uma arquitetura monolítica, a comunicação entre componentes ocorre dentro do mesmo processo — não há rede envolvida. Em microsserviços, cada chamada entre serviços trafega pela rede, o que introduz novos vetores de ataque:

Interceptação: um atacante pode capturar o tráfego entre serviços
Falsificação de identidade: um serviço malicioso pode se passar por outro
Man-in-the-middle: um atacante pode modificar os dados em trânsito
Movimento lateral: se um serviço é comprometido, o atacante pode acessar outros serviços na mesma rede

A segurança de rede em microsserviços não é opcional — é fundamental.

TLS (Transport Layer Security)

O TLS cifra a comunicação entre dois pontos, garantindo confidencialidade e integridade.

Como funciona o TLS

sequenceDiagram
    participant C as Cliente
    participant S as Servidor

    C->>S: ClientHello (versões TLS, cipher suites)
    S->>C: ServerHello (versão escolhida, cipher suite)
    S->>C: Certificado do servidor
    C->>C: Verificar certificado contra CA
    C->>S: Chave pre-master cifrada com a chave pública do servidor
    Note over C,S: Ambos derivam a chave de sessão
    C->>S: Dados cifrados com a chave de sessão
    S->>C: Dados cifrados com a chave de sessão

Configuração recomendada

# Configuração TLS moderna
tls:
  min_version: TLSv1.2    # Mínimo TLS 1.2, preferir 1.3
  cipher_suites:
    - TLS_AES_256_GCM_SHA384
    - TLS_CHACHA20_POLY1305_SHA256
    - TLS_AES_128_GCM_SHA256
  certificate: /etc/certs/server.crt
  private_key: /etc/certs/server.key
  ca_certificate: /etc/certs/ca.crt

TLS na prática

Terminação TLS no Gateway: o tráfego externo chega cifrado ao API Gateway, que encerra o TLS e roteia internamente
TLS end-to-end: o tráfego permanece cifrado do cliente até o serviço final
Recifragem: o Gateway encerra o TLS externo e estabelece uma nova conexão TLS interna

mTLS (Mutual TLS)

No TLS padrão, apenas o servidor apresenta um certificado. No mTLS, ambas as partes se autenticam mutuamente.

Por que usar mTLS em microsserviços

Em uma rede interna com dezenas de serviços, você precisa garantir que:

O serviço que chama é quem diz ser
O serviço que responde é quem diz ser
Ninguém pode interceptar ou modificar a comunicação

sequenceDiagram
    participant A as Serviço A
    participant B as Serviço B

    A->>B: ClientHello
    B->>A: ServerHello + Certificado de B
    A->>A: Verificar certificado de B
    B->>A: Solicitar certificado de A
    A->>B: Certificado de A
    B->>B: Verificar certificado de A
    Note over A,B: Ambos verificados, comunicação cifrada
    A->>B: Request cifrado
    B->>A: Response cifrado

Gestão de certificados

O maior desafio do mTLS é a gestão de certificados em escala:

Cada serviço precisa do seu próprio certificado
Os certificados devem ser renovados antes de expirar
É necessária uma Certificate Authority (CA) interna
A revogação de certificados deve ser rápida

# Exemplo: certificado por serviço
service: orders-service
certificate:
  common_name: orders-service.internal
  san:
    - orders-service.default.svc.cluster.local
    - orders-service.production.svc.cluster.local
  validity: 24h          # Certificados de curta duração
  auto_renewal: true      # Renovação automática
  issuer: internal-ca

Ferramentas para mTLS

cert-manager (Kubernetes): automatiza a emissão e renovação de certificados
Vault (HashiCorp): PKI como serviço, gera certificados sob demanda
SPIFFE/SPIRE: framework de identidade para workloads, gera SVIDs (identidades verificáveis)

Service Mesh

Um service mesh é uma camada de infraestrutura dedicada a gerenciar a comunicação entre serviços. Implementa mTLS, observabilidade e políticas de tráfego de forma transparente.

Como funciona

Cada serviço tem um sidecar proxy que intercepta todo o tráfego de rede:

[Serviço A] ←→ [Proxy A] ←→ [Rede] ←→ [Proxy B] ←→ [Serviço B]
                  (Envoy)                  (Envoy)

O serviço não precisa implementar TLS, retry, circuit breaking nem métricas — o proxy faz isso por ele.

Benefícios de segurança

mTLS automático: o mesh gerencia certificados e cifra todo o tráfego entre serviços
Políticas de acesso: define quais serviços podem se comunicar entre si
Observabilidade: visibilidade completa do tráfego entre serviços
Cifragem transparente: os serviços não precisam de código de segurança adicional

Exemplo: política de acesso no Istio

# Somente o BFF pode chamar o serviço de pedidos
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: orders-service-policy
  namespace: production
spec:
  selector:
    matchLabels:
      app: orders-service
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/production/sa/bff-service"]
      to:
        - operation:
            methods: ["GET", "POST"]
            paths: ["/api/orders/*"]

Service meshes populares

Mesh	Características
Istio	O mais completo, baseado em Envoy, ampla comunidade
Linkerd	Mais leve, focado em simplicidade e desempenho
Consul Connect	Integrado com o HashiCorp Consul, bom para ambientes híbridos

Políticas de rede (Network Policies)

No Kubernetes, as Network Policies controlam quais pods podem se comunicar entre si em nível de rede.

Por padrão: tudo aberto

Sem Network Policies, qualquer pod pode se comunicar com qualquer outro pod no cluster. Isso é perigoso: se um pod é comprometido, o atacante tem acesso a toda a rede interna.

Exemplo: restringir acesso ao serviço de banco de dados

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-access-policy
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: orders-service
        - podSelector:
            matchLabels:
              app: users-service
      ports:
        - protocol: TCP
          port: 5432

Esta política diz: somente os pods orders-service e users-service podem se conectar ao pod postgres na porta 5432. Todo o restante está bloqueado.

Estratégia de segmentação

Zona pública:     [API Gateway]
                       ↓
Zona de aplicação: [BFF] [Auth Service]
                       ↓
Zona de serviços:  [Orders] [Users] [Payments]
                       ↓
Zona de dados:      [PostgreSQL] [Redis] [Kafka]

Cada zona tem políticas que restringem o acesso:

A zona pública só pode falar com a zona de aplicação
A zona de aplicação pode falar com a zona de serviços
Somente a zona de serviços pode falar com a zona de dados
A zona de dados não inicia conexões para fora

DNS e descoberta segura de serviços

Em microsserviços, os serviços são descobertos dinamicamente. Esse mecanismo também precisa ser seguro:

DNS interno: usar DNS privado dentro do cluster, sem expor nomes de serviços internos
Service discovery cifrado: as consultas de descoberta devem ser autenticadas
Validação de endpoints: verificar que o serviço descoberto é legítimo antes de enviar dados

# Kubernetes: os serviços são resolvidos por DNS interno
# orders-service.production.svc.cluster.local
# Este DNS não é acessível de fora do cluster

Boas práticas de segurança de rede

Cifre todo o tráfego: use TLS ou mTLS para toda comunicação, mesmo a interna
Aplique o princípio do mínimo acesso: cada serviço só pode se comunicar com os serviços que precisa
Segmente a rede: separe serviços em zonas com diferentes níveis de confiança
Monitore o tráfego: detecte padrões anômalos que possam indicar um ataque
Rotacione certificados com frequência: certificados de curta duração (horas, não anos)
Use um service mesh: simplifica a implementação de segurança de rede em escala
Bloqueie por padrão: as Network Policies devem negar tudo e permitir explicitamente

Resumo

A segurança de rede em arquiteturas distribuídas exige cifrar toda a comunicação (TLS/mTLS), autenticar cada serviço, segmentar a rede em zonas de confiança e monitorar o tráfego. Um service mesh simplifica enormemente essa tarefa ao gerenciar mTLS, políticas de acesso e observabilidade de forma transparente. As Network Policies do Kubernetes complementam o mesh controlando o acesso em nível de rede. A regra fundamental é: nunca confie na rede, mesmo que ela seja “interna”.