Seguridad de red

Seguridad en la comunicación entre servicios: TLS, mTLS, service mesh, políticas de red y segmentación en arquitecturas distribuidas.

Por qué la red es un vector de ataque

En una arquitectura monolítica, la comunicación entre componentes ocurre dentro del mismo proceso — no hay red de por medio. En microservicios, cada llamada entre servicios viaja por la red, lo que introduce nuevos vectores de ataque:

Interceptación: un atacante puede capturar el tráfico entre servicios
Suplantación: un servicio malicioso puede hacerse pasar por otro
Man-in-the-middle: un atacante puede modificar los datos en tránsito
Movimiento lateral: si un servicio es comprometido, el atacante puede acceder a otros servicios en la misma red

La seguridad de red en microservicios no es opcional — es fundamental.

TLS (Transport Layer Security)

TLS cifra la comunicación entre dos puntos, garantizando confidencialidad e integridad.

Cómo funciona TLS

sequenceDiagram
    participant C as Cliente
    participant S as Servidor

    C->>S: ClientHello (versiones TLS, cipher suites)
    S->>C: ServerHello (versión elegida, cipher suite)
    S->>C: Certificado del servidor
    C->>C: Verificar certificado contra CA
    C->>S: Clave pre-master cifrada con clave pública del servidor
    Note over C,S: Ambos derivan la clave de sesión
    C->>S: Datos cifrados con clave de sesión
    S->>C: Datos cifrados con clave de sesión

Configuración recomendada

# Configuración 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 en la práctica

Terminación TLS en el Gateway: el tráfico externo llega cifrado al API Gateway, que termina TLS y enruta internamente
TLS end-to-end: el tráfico se mantiene cifrado desde el cliente hasta el servicio final
Re-cifrado: el Gateway termina TLS externo y establece una nueva conexión TLS interna

mTLS (Mutual TLS)

En TLS estándar, solo el servidor presenta un certificado. En mTLS, ambas partes se autentican mutuamente.

Por qué mTLS en microservicios

En una red interna con decenas de servicios, necesitas garantizar que:

El servicio que llama es quien dice ser
El servicio que responde es quien dice ser
Nadie puede interceptar o modificar la comunicación

sequenceDiagram
    participant A as Servicio A
    participant B as Servicio 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, comunicación cifrada
    A->>B: Request cifrado
    B->>A: Response cifrado

Gestión de certificados

El mayor desafío de mTLS es la gestión de certificados a escala:

Cada servicio necesita su propio certificado
Los certificados deben renovarse antes de expirar
Se necesita una Certificate Authority (CA) interna
La revocación de certificados debe ser rápida

# Ejemplo: certificado por servicio
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 corta duración
  auto_renewal: true      # Renovación automática
  issuer: internal-ca

Herramientas para mTLS

cert-manager (Kubernetes): automatiza la emisión y renovación de certificados
Vault (HashiCorp): PKI como servicio, genera certificados bajo demanda
SPIFFE/SPIRE: framework de identidad para workloads, genera SVIDs (identidades verificables)

Service Mesh

Un service mesh es una capa de infraestructura dedicada a manejar la comunicación entre servicios. Implementa mTLS, observabilidad y políticas de tráfico de forma transparente.

Cómo funciona

Cada servicio tiene un sidecar proxy que intercepta todo el tráfico de red:

[Servicio A] ←→ [Proxy A] ←→ [Red] ←→ [Proxy B] ←→ [Servicio B]
                  (Envoy)                  (Envoy)

El servicio no necesita implementar TLS, retry, circuit breaking ni métricas — el proxy lo hace por él.

Beneficios de seguridad

mTLS automático: el mesh gestiona certificados y cifra todo el tráfico entre servicios
Políticas de acceso: define qué servicios pueden comunicarse entre sí
Observabilidad: visibilidad completa del tráfico entre servicios
Cifrado transparente: los servicios no necesitan código de seguridad adicional

Ejemplo: política de acceso en Istio

# Solo el BFF puede llamar al servicio de órdenes
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	El más completo, basado en Envoy, amplia comunidad
Linkerd	Más ligero, enfocado en simplicidad y rendimiento
Consul Connect	Integrado con HashiCorp Consul, bueno para entornos híbridos

Políticas de red (Network Policies)

En Kubernetes, las Network Policies controlan qué pods pueden comunicarse entre sí a nivel de red.

Por defecto: todo abierto

Sin Network Policies, cualquier pod puede comunicarse con cualquier otro pod en el cluster. Esto es peligroso: si un pod es comprometido, el atacante tiene acceso a toda la red interna.

Ejemplo: restringir acceso al servicio de base de datos

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 dice: solo los pods orders-service y users-service pueden conectarse al pod postgres en el puerto 5432. Todo lo demás está bloqueado.

Estrategia de segmentación

Zona pública:     [API Gateway]
                       ↓
Zona de aplicación: [BFF] [Auth Service]
                       ↓
Zona de servicios:  [Orders] [Users] [Payments]
                       ↓
Zona de datos:      [PostgreSQL] [Redis] [Kafka]

Cada zona tiene políticas que restringen el acceso:

La zona pública solo puede hablar con la zona de aplicación
La zona de aplicación puede hablar con la zona de servicios
Solo la zona de servicios puede hablar con la zona de datos
La zona de datos no inicia conexiones hacia afuera

DNS y descubrimiento seguro de servicios

En microservicios, los servicios se descubren dinámicamente. Este mecanismo también debe ser seguro:

DNS interno: usar DNS privado dentro del cluster, no exponer nombres de servicios internos
Service discovery cifrado: las consultas de descubrimiento deben estar autenticadas
Validación de endpoints: verificar que el servicio descubierto es legítimo antes de enviar datos

# Kubernetes: los servicios se resuelven por DNS interno
# orders-service.production.svc.cluster.local
# Este DNS no es accesible desde fuera del cluster

Buenas prácticas de seguridad de red

Cifra todo el tráfico: usa TLS o mTLS para toda comunicación, incluso interna
Aplica el principio de mínimo acceso: cada servicio solo puede comunicarse con los servicios que necesita
Segmenta la red: separa servicios en zonas con diferentes niveles de confianza
Monitorea el tráfico: detecta patrones anómalos que puedan indicar un ataque
Rota certificados frecuentemente: certificados de corta duración (horas, no años)
Usa un service mesh: simplifica la implementación de seguridad de red a escala
Bloquea por defecto: las Network Policies deben denegar todo y permitir explícitamente

Resumen

La seguridad de red en arquitecturas distribuidas requiere cifrar toda la comunicación (TLS/mTLS), autenticar cada servicio, segmentar la red en zonas de confianza y monitorear el tráfico. Un service mesh simplifica enormemente esta tarea al manejar mTLS, políticas de acceso y observabilidad de forma transparente. Las Network Policies de Kubernetes complementan el mesh controlando el acceso a nivel de red. La regla fundamental es: nunca confíes en la red, incluso si es “interna”.