mTLS y Zero Trust entre servicios en España

Servicios DevOps · España

mTLS y arquitectura Zero Trust entre servicios en España para equipos que ya no dan por confiable el tráfico solo porque viene de dentro de la misma red. Montamos una autoridad certificadora interna con cert-manager o step-ca, certificados de corta duración renovados automáticamente para cada servicio, y, si el tamaño del proyecto lo justifica, un service mesh como Linkerd o Istio para aplicar la política de forma centralizada.

  • Ninguna confianza implícita dentro de la red interna
  • Certificados de corta duración, rotados automáticamente
  • Identidad propia por cada servicio, no por dirección IP
Habla con un ingenieroVer abonamientos
  • VPS 1–8 h/mes; dedicados 5-10 h/mes según el plan; GPU 10 h/mes
    Horas incluidas
  • Frankfurt, en la UE
    Datacenters
  • baja latencia desde Fráncfort
    Latencia
  • en EUR, con IVA del 21 % desglosado en factura
    Facturación

Qué es mTLS y qué resuelve

TLS normal autentica al servidor frente al cliente; mTLS (TLS mutuo) exige que ambos lados presenten un certificado válido, de forma que un servicio solo acepta tráfico de otro servicio que puede demostrar su identidad, no de cualquiera que alcance la dirección IP correcta. Esto importa especialmente cuando varios servicios comparten red interna: sin mTLS, cualquier proceso que consiga entrar en esa red puede hablar con tu base de datos o tu API interna sin más comprobación.

  • Autenticación en ambos sentidos, no solo del servidor
  • Identidad por certificado, no por confiar en la dirección IP
  • Cada servicio solo acepta tráfico de servicios autorizados explícitamente

Buenas prácticas que aplicamos

Zero Trust no es un producto que se instala, es una forma de diseñar el acceso: nada se confía por defecto solo porque está dentro del perímetro. Lo aplicamos de forma consistente en cada capa del sistema, no solo en el borde de la red, y documentamos qué servicio confía en cuál para que cualquier ingeniero pueda leer la política sin descifrar la configuración del mesh.

  • Ninguna confianza implícita dentro de la red interna
  • Identidad propia por cada carga de trabajo (workload), no por IP
  • Acceso de mínimo privilegio entre servicios
  • Rotación automática de certificados de corta duración
  • Secretos cifrados en git (SOPS) o en Vault, nunca en texto plano

Service mesh o certificados directos

Un service mesh como Linkerd o Istio aplica mTLS automáticamente entre todos los servicios del clúster, con observabilidad y control de tráfico añadidos, a cambio de una capa extra de complejidad operativa. Para proyectos más pequeños, gestionar los certificados directamente con cert-manager o step-ca, sin sidecar, cubre la misma necesidad de identidad y cifrado con menos piezas que mantener. Te recomendamos el enfoque según el número de servicios y la madurez operativa de tu equipo, no por moda.

  • Service mesh: mTLS automático, observabilidad añadida, más complejidad
  • Certificados directos: identidad y cifrado, sin sidecar
  • Recomendación según el número de servicios y la madurez del equipo

Cómo usas las horas incluidas

Las horas DevOps forman parte del abonamiento: entre 1 y 8 horas al mes en VPS, entre 5 y 10 horas al mes en dedicados según el plan y 10 horas al mes en GPU. Se solicitan desde el panel de cliente, en Servicios DevOps. Las usamos para montar la autoridad certificadora interna, migrar servicios existentes a mTLS de forma gradual, o evaluar si un service mesh aporta valor real a tu arquitectura actual. Lo que supera la cuota mensual se acepta y se factura por separado.

Cada suscripción incluye horas mensuales de DevOps, CyberSecurity y Programación: 1 h desde el plan cPanel Advanced, 1–8 h en VPS, entre 5 y 10 h en servidores dedicados según el plan y 10 h en servidores GPU. Las horas se solicitan desde el panel de cliente, no se acumulan al mes siguiente, y lo que supera la cuota se acepta y se factura por separado.

Cómo trabajamos

  1. Solicitas el trabajo desde el panel

    Describes tu arquitectura de servicios actual y si el motivo es cumplimiento, un requisito de un cliente, o una decisión propia de seguridad.

  2. Acordamos alcance y plazo

    Decidimos entre certificados directos o service mesh, y estimamos las horas necesarias dentro de tu cuota mensual.

  3. Desplegamos por fases, sin cortar el tráfico

    Migramos servicio a servicio hacia mTLS, verificando en cada paso que la comunicación sigue funcionando antes de exigir el certificado de forma obligatoria.

  4. Entrega con documentación

    Recibes la arquitectura de identidad documentada, el procedimiento de rotación de certificados y las políticas de acceso definidas.

Casos de uso

Fintech con requisitos de auditoría

Una entidad financiera de Madrid que necesita demostrar a sus auditores que ningún servicio interno confía en otro sin verificación implementa mTLS entre todos sus microservicios, con identidad y rotación de certificados documentadas.

SaaS multi-tenant con datos sensibles

Una plataforma que gestiona datos de varios clientes en el mismo clúster aísla la comunicación entre servicios por tenant, de forma que un fallo de configuración en uno no exponga datos de otro.

Proveedor tecnológico de un cliente regulado

Un proveedor que da servicio a una empresa del sector asegurador recibe el requisito contractual de aplicar Zero Trust en su arquitectura interna, no solo en el perímetro público.

Tecnologías

  • cert-manager
  • step-ca
  • Linkerd
  • Istio
  • SPIFFE/SPIRE
  • Vault
  • SOPS

Preguntas frecuentes

  • ¿Qué es mTLS y para qué sirve?

    Es TLS mutuo: tanto el cliente como el servidor presentan un certificado válido para autenticarse el uno al otro, en lugar de que solo el servidor demuestre quién es. Sirve para que un servicio interno solo acepte tráfico de otros servicios que puede verificar explícitamente, en lugar de confiar en cualquiera que alcance su dirección IP dentro de la red.

  • ¿Qué es Zero Trust?

    Es un modelo de seguridad en el que ningún servicio o usuario se considera de confianza solo por estar dentro del perímetro de la red. Cada acceso se verifica de forma explícita, con identidad propia y privilegio mínimo, en lugar de asumir que todo lo que está «dentro» es seguro por defecto.

  • ¿Istio o Linkerd?

    Linkerd es más ligero y sencillo de operar, con menos superficie de configuración; Istio ofrece más funciones avanzadas de control de tráfico y políticas, a cambio de mayor complejidad operativa. Para equipos que empiezan con service mesh, solemos recomendar Linkerd; Istio tiene sentido cuando ya necesitas ese control adicional.

  • ¿Cómo autenticar microservicios entre sí?

    Con mTLS: cada servicio recibe un certificado propio, de corta duración y renovado automáticamente, emitido por una autoridad certificadora interna. Así cada servicio puede verificar la identidad del que le llama sin depender de contraseñas compartidas ni de confiar simplemente en la dirección IP de origen.

  • ¿Necesito un service mesh?

    No siempre. Si tienes pocos servicios, gestionar certificados directamente con cert-manager o step-ca cubre la misma necesidad de identidad y cifrado con menos complejidad operativa. Un service mesh aporta valor real cuando el número de servicios crece lo suficiente como para que la observabilidad y el control de tráfico centralizado compensen el coste de mantenerlo.

¿Tu red interna confía en todo por defecto?

Cuéntanos tu arquitectura de servicios: te decimos si necesitas mTLS directo o un service mesh, con las horas incluidas en tu abonamiento.

Habla con un ingenieroVer abonamientos

Guías para empresas en España