A segurança em arquiteturas de microsserviços difere significativamente da segurança em sistemas monolíticos. Em um monólito, as comunicações entre componentes ocorrem dentro de um mesmo processo, enquanto em microsserviços as chamadas cruzam a rede, expondo novos vetores de ataque. Esta aula explora quatro pilares essenciais para proteger microsserviços: segregação, autenticação entre serviços, observabilidade e o modelo zero trust.

Vamos entender como aplicar esses conceitos na prática, com exemplos de configuração e ferramentas.

Segregação

Segregação em microsserviços significa dividir o sistema em serviços independentes com responsabilidades bem definidas, limitando o impacto de uma eventual violação. Cada serviço deve ter seu próprio banco de dados e contexto de negócio, evitando que um invasor que comprometa um serviço tenha acesso fácil a dados de outros.

Além da segregação lógica, é importante implementar segregação de rede: serviços críticos devem ficar em sub-redes isoladas, com firewalls e políticas de tráfego restritivas. Por exemplo, um serviço de pagamento não deve se comunicar diretamente com a internet, apenas com outros serviços autorizados via API gateway.

Exemplo de política de rede no Kubernetes (NetworkPolicy):
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: pagamento-isolamento
spec:
  podSelector:
    matchLabels:
      app: pagamento
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: api-gateway
    ports:
    - protocol: TCP
      port: 8080
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: banco-pagamento
    ports:
    - protocol: TCP
      port: 5432

Nesse exemplo, apenas o API gateway pode chamar o serviço de pagamento, e este só pode acessar seu banco de dados específico.

Service-to-service auth

A autenticação entre serviços (service-to-service auth) garante que apenas serviços legítimos possam se comunicar entre si. Diferentemente da autenticação de usuário, aqui estamos autenticando máquinas ou processos. As abordagens comuns incluem tokens JWT com claims de serviço, certificados TLS mútuo (mTLS) e chaves de API.

O mTLS é uma prática recomendada: cada serviço possui um certificado assinado por uma autoridade certificadora interna, e as conexões TLS exigem que ambas as partes apresentem seus certificados. Isso impede ataques man-in-the-middle e garante a identidade do serviço chamador.

Exemplo de configuração de mTLS no Istio (malha de serviço):
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: default
spec:
  mtls:
    mode: STRICT  # Exige mTLS para todas as comunicações

Com essa configuração, todo tráfego entre serviços na malha deve usar mTLS. Tokens JWT também podem ser usados: um serviço emite um token assinado com sua identidade, e o serviço receptor valida a assinatura e as permissões.

Observabilidade

Observabilidade é a capacidade de entender o estado interno de um sistema a partir de seus dados externos (logs, métricas, traces). Em microsserviços, a observabilidade é crucial para detectar anomalias de segurança, como acessos não autorizados ou padrões suspeitos.

Três pilares da observabilidade: logging centralizado (ex: ELK Stack), métricas (ex: Prometheus) e tracing distribuído (ex: Jaeger). Para segurança, é importante registrar eventos como tentativas de autenticação, mudanças de permissão e erros de autorização. Métricas como taxa de erros 403 (Forbidden) podem indicar tentativas de ataque.

Exemplo de log estruturado em JSON (serviço Node.js):
{
  "timestamp": "2025-03-21T10:00:00Z",
  "level": "warn",
  "service": "pedidos",
  "message": "Token JWT inválido",
  "clientIP": "10.0.0.5",
  "path": "/api/pedidos",
  "userId": null
}

Com logs centralizados, é possível correlacionar eventos entre serviços e identificar ataques em cadeia.

Zero trust

O modelo zero trust parte do princípio de que nenhuma entidade (interna ou externa) é confiável por padrão. Toda requisição deve ser autenticada, autorizada e criptografada, independentemente da origem. Em microsserviços, isso significa que mesmo dentro da rede interna, cada chamada deve ser verificada.

Implementações comuns incluem malhas de serviço (service mesh) como Istio ou Linkerd, que aplicam políticas de segurança no nível da rede, e gateways de API que validam tokens e aplicam rate limiting. Políticas de acesso baseadas em atributos (ABAC) ou em funções (RBAC) são aplicadas a cada requisição.

Exemplo de política zero trust com OPA (Open Policy Agent):
package authz

allow {
  input.method == "GET"
  input.path == "/api/dados"
  input.jwt.role == "admin"
}

Nesse exemplo, apenas requisições GET com role admin são permitidas. O OPA pode ser integrado a um API gateway para avaliar cada requisição.

Boas práticas e observações finais

Sempre use HTTPS para todas as comunicações. Evite compartilhar segredos (senhas, tokens) entre serviços; utilize um cofre de segredos (como HashiCorp Vault). Mantenha as dependências atualizadas e realize varreduras de vulnerabilidades regularmente. Considere usar uma malha de serviço para gerenciar políticas de segurança de forma centralizada.

Lembre-se: segurança em microsserviços é uma responsabilidade compartilhada entre desenvolvimento, operações e segurança. Invista em automação e testes de penetração contínuos.

Referências

Exercícios

  1. Explique por que a segregação de banco de dados é importante em microsserviços.

    ✓ Resposta: A segregação de banco de dados impede que um invasor que comprometa um serviço tenha acesso a dados de outros serviços. Cada serviço gerencia seu próprio banco, limitando o impacto de uma violação e facilitando a aplicação de controles de acesso específicos.

  2. Qual a diferença entre autenticação de usuário e autenticação service-to-service? Dê um exemplo de tecnologia usada para esta última.

    ✓ Resposta: Autenticação de usuário verifica a identidade de uma pessoa (ex: login/senha). Autenticação service-to-service verifica a identidade de um serviço (ex: certificado digital). Um exemplo é o mTLS (mutual TLS), onde ambos os lados apresentam certificados.

  3. Cite dois dos três pilares da observabilidade e explique como cada um ajuda na segurança.

    ✓ Resposta: Logs: registram eventos como tentativas de acesso, permitindo auditoria e detecção de anomalias. Métricas: indicam picos de erros 403/401, que podem sinalizar ataques. Tracing: ajuda a rastrear requisições suspeitas através de múltiplos serviços.

  4. No modelo zero trust, por que uma requisição vinda de dentro da rede interna não é automaticamente confiável?

    ✓ Resposta: Porque a rede interna pode conter serviços comprometidos ou dispositivos infectados. O zero trust assume que a rede é hostil, exigindo autenticação e autorização para cada requisição, independentemente da origem.

  5. Escreva um exemplo de política de rede (NetworkPolicy) no Kubernetes que permita apenas tráfego do serviço A para o serviço B na porta 8080.

    ✓ Resposta:
    apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: permitir-a-para-b
spec:
  podSelector:
    matchLabels:
      app: servico-b
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: servico-a
    ports:
    - protocol: TCP
      port: 8080