Padrões de segurança em arquiteturas de microservices

1. Fundamentos de segurança distribuída

1.1. Diferenças críticas entre segurança monolítica e em microservices

Em uma arquitetura monolítica, a segurança é tipicamente implementada como uma camada única — um firewall de borda, uma autenticação centralizada e uma única base de dados para sessões. Em microservices, cada serviço opera de forma independente, com seus próprios processos de comunicação, armazenamento e exposição. Isso elimina o "perímetro seguro" tradicional e exige que cada serviço seja capaz de se defender sozinho.

A principal diferença está na granularidade: em um monólito, uma única vulnerabilidade pode comprometer todo o sistema; em microservices, o impacto pode ser contido, mas a superfície de ataque é drasticamente ampliada.

1.2. Ameaças comuns: aumento da superfície de ataque e comunicação entre serviços

A comunicação entre serviços introduz novas ameaças:

  • Interceptação de tráfego: se a comunicação não for criptografada, um invasor pode capturar tokens, dados sensíveis ou até mesmo injetar comandos.
  • Ataques de replay: mensagens legítimas podem ser reenviadas para causar efeitos indesejados.
  • Injeção de payloads: serviços que confiam cegamente em dados recebidos de outros serviços podem ser explorados via SQL injection, command injection ou XML external entities (XXE).

1.3. Princípios de Zero Trust aplicados a malhas de serviços

Zero Trust parte da premissa "nunca confie, sempre verifique". Em microservices, isso significa:

  • Nenhum serviço é confiável por padrão: mesmo serviços internos devem ser autenticados e autorizados a cada requisição.
  • Acesso baseado em identidade: não em endereço IP ou rede.
  • Segmentação de rede: cada serviço deve ter seu próprio espaço de comunicação isolado.

Exemplo de política Zero Trust em uma malha de serviços:

Política de acesso:
- Serviço A (payment) só aceita chamadas de serviço B (order)
- Serviço B (order) só aceita chamadas de serviço C (auth)
- Comunicação entre A e B exige mTLS + token JWT válido
- Log de toda requisição negada é enviado ao SIEM central

2. Autenticação e autorização descentralizadas

2.1. Padrão API Gateway como gatekeeper central

O API Gateway atua como ponto único de entrada, validando tokens, aplicando rate limiting e verificando permissões básicas antes de encaminhar requisições aos serviços internos. Isso reduz a carga de autenticação em cada serviço.

Exemplo de fluxo:

1. Cliente envia requisição com token JWT ao API Gateway
2. Gateway valida assinatura do token com a chave pública do OAuth Provider
3. Gateway extrai claims (user_id, roles) e repassa ao serviço de destino
4. Serviço interno utiliza os claims para autorização local

2.2. Implementação de tokens JWT e OAuth 2.0 entre serviços

OAuth 2.0 com fluxo Client Credentials é o padrão para comunicação serviço-a-serviço. Cada serviço possui seu próprio client_id e client_secret, obtendo um token JWT com escopos específicos.

Exemplo de geração de token entre serviços:

POST /oauth/token
{
  "grant_type": "client_credentials",
  "client_id": "service-payment",
  "client_secret": "s3cr3t-payment-2024",
  "scope": "read:orders write:payments"
}

Resposta:
{
  "access_token": "eyJhbGciOiJSUzI1NiIs...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "scope": "read:orders write:payments"
}

2.3. Autorização por claims e políticas baseadas em escopos

Os claims do JWT (como role, department, scope) são usados para decisões de autorização. Políticas podem ser definidas centralmente em um serviço de autorização (como OPA — Open Policy Agent).

Exemplo de política OPA:

package authz

default allow = false

allow {
    input.method == "GET"
    input.path == "/orders"
    input.token.scope == "read:orders"
}

allow {
    input.method == "POST"
    input.path == "/payments"
    input.token.scope == "write:payments"
    input.token.role == "finance_admin"
}

3. Segurança na comunicação entre serviços

3.1. TLS mútuo (mTLS) para identidade e criptografia

mTLS garante que ambos os lados da comunicação apresentem certificados válidos, estabelecendo identidade e criptografia simultaneamente. Cada serviço possui seu próprio certificado emitido por uma CA interna.

Exemplo de configuração de mTLS com Envoy:

tls_context:
  common_tls_context:
    tls_certificates:
      - certificate_chain:
          filename: /etc/certs/service-cert.pem
        private_key:
          filename: /etc/certs/service-key.pem
    validation_context:
      trusted_ca:
        filename: /etc/certs/ca-cert.pem
      match_subject_alt_names:
        - exact: "service-order.internal.svc.cluster.local"

3.2. Service Mesh e proxies sidecar (exemplo: Istio, Linkerd)

Service Mesh como Istio automatiza mTLS entre todos os serviços, sem exigir alterações no código. Cada serviço tem um proxy sidecar (Envoy) que intercepta todo o tráfego de entrada e saída.

Exemplo de política de mTLS estrito no Istio:

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production
spec:
  mtls:
    mode: STRICT

3.3. Padrão de validação de payloads e prevenção de ataques de injeção

Nunca confie em payloads recebidos. A validação deve ser feita em duas camadas:

  • Camada de transporte: validar schema (JSON Schema, Protobuf validation)
  • Camada de aplicação: sanitizar entradas contra injeção

Exemplo de validação de schema:

{
  "type": "object",
  "properties": {
    "order_id": { "type": "string", "pattern": "^[a-f0-9]{24}$" },
    "amount": { "type": "number", "minimum": 0.01 },
    "currency": { "type": "string", "enum": ["USD", "EUR", "BRL"] }
  },
  "required": ["order_id", "amount", "currency"]
}

4. Gerenciamento de segredos e credenciais

4.1. Uso de vaults distribuídos (HashiCorp Vault, AWS Secrets Manager)

Segredos (senhas de banco, chaves de API, certificados) nunca devem ser armazenados em código ou variáveis de ambiente estáticas. Vaults distribuídos fornecem acesso temporário e auditado.

Exemplo de acesso ao Vault:

vault write auth/approle/login role_id="role-payment" secret_id="secret-payment-2024"

Resposta:
{
  "client_token": "s.abc123...",
  "lease_duration": 3600
}

vault read database/creds/payment-readonly
{
  "data": {
    "username": "v-abc123-payment",
    "password": "A1b2C3d4..."
  }
}

4.2. Rotação automática de chaves e certificados

Certificados mTLS e chaves de API devem ter expiração curta (ex.: 24h) e ser renovados automaticamente. Ferramentas como cert-manager no Kubernetes automatizam esse ciclo.

Exemplo de certificado com validade de 24 horas:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: service-payment-cert
spec:
  secretName: payment-tls
  duration: 24h
  renewBefore: 12h
  issuerRef:
    name: internal-ca
    kind: ClusterIssuer

4.3. Evitar hardcoding: injeção de segredos em tempo de execução

Segredos devem ser injetados via volumes montados ou variáveis de ambiente seguras (Kubernetes Secrets, AWS Parameter Store). Nunca colocar segredos em imagens Docker ou repositórios Git.

Exemplo de injeção segura:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-service
spec:
  template:
    spec:
      containers:
      - name: payment
        env:
        - name: DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: payment-db-secret
              key: password

5. Proteção de dados e privacidade

5.1. Criptografia em repouso e em trânsito por domínio de dado

Cada domínio de dado (financeiro, pessoal, logs) deve ter sua própria chave de criptografia. Dados em trânsito usam TLS/mTLS; dados em repouso usam criptografia em nível de coluna ou disco.

5.2. Tokenização e mascaramento de dados sensíveis em logs

Nunca logar dados sensíveis como números de cartão, CPF ou tokens. Use tokenização (substituir por um identificador não reversível) ou mascaramento (mostrar apenas os últimos 4 dígitos).

Exemplo de mascaramento em log:

Log original: "Payment processed for card 4111111111111111"
Log mascarado: "Payment processed for card **** **** **** 1111"

5.3. Controle de acesso baseado em contexto (CBAC) para dados compartilhados

CBAC considera fatores como localização geográfica, horário, dispositivo e nível de risco da requisição para decidir se um serviço pode acessar determinado dado.

6. Monitoramento, auditoria e resposta a incidentes

6.1. Logs centralizados e imutáveis para trilha de auditoria

Todos os logs de autenticação, autorização e acesso a dados devem ser enviados a um sistema central (ELK, Splunk) com política de imutabilidade (append-only). Logs imutáveis impedem que um invasor apague evidências.

6.2. Detecção de anomalias e padrões de ataque em tempo real

Use ferramentas de SIEM e machine learning para detectar padrões como:

  • Múltiplas tentativas de autenticação com tokens inválidos
  • Acesso a endpoints incomuns por um serviço específico
  • Picos de tráfego entre serviços que normalmente não se comunicam

Exemplo de regra de detecção:

Regra: Múltiplas falhas de mTLS
Condição: > 10 falhas de handshake TLS em 5 minutos
Ação: Bloquear IP do serviço de origem por 1 hora
Notificar: time de segurança via PagerDuty

6.3. Playbooks de resposta a incidentes em ambientes distribuídos

Playbooks devem ser específicos para microservices:

Playbook: Vazamento de token JWT
1. Revogar token via API de revogação
2. Rotacionar chave de assinatura do OAuth Provider
3. Invalidar sessões ativas do usuário afetado
4. Analisar logs para determinar escopo do vazamento
5. Notificar DPO se dados pessoais foram expostos

Referências