Por qué el mTLS no es opcional en nuestra arquitectura
La confianza entre servicios nunca debería darse por supuesta. Por qué cada llamada interna de nuestros despliegues se autentica en ambos sentidos, y lo que cuesta hacerlo bien.
Muchas de las arquitecturas que heredamos siguen dando por suficiente la seguridad perimetral. Un balanceador de carga termina el TLS, todo lo que hay detrás se comunica en texto plano o con certificados en un solo sentido, y cualquier petición que haya superado el perímetro se considera de confianza. Nosotros no construimos así, y cuando nos hacemos cargo de un proyecto construido así, lo cambiamos.
La suposición que no hacemos
El TLS en un solo sentido demuestra que el servidor es quien dice ser, pero no dice nada del cliente. En una arquitectura de microservicios, eso significa que cualquier carga de trabajo dentro del perímetro de red puede llamar a cualquier servicio interno y pasar por tráfico legítimo: un sidecar comprometido, un pod de depuración mal configurado, una dependencia con un problema en la cadena de suministro. La segmentación lo frena, pero no lo impide.
El mTLS cierra ese hueco. Cada servicio demuestra su identidad ante todos los demás, en cada llamada, con certificados de vida corta emitidos por una CA interna. Sin certificado no hay conexión. No hay excepciones para el tráfico interno, porque es justo ahí donde la suposición falla.
Lo que cuesta
Activar mTLS por defecto tiene un coste real:
- La emisión y la rotación de certificados tienen que estar automatizadas desde el primer día. A mano deja de funcionar en cuanto hay más de un puñado de servicios.
- El desarrollo local necesita su propia cadena de confianza. Si no la tiene, los ingenieros empiezan a desactivar la verificación «solo para probar», y tarde o temprano esa opción acaba en producción.
- Depurar un fallo en el handshake de mTLS no es lo mismo que depurar un HTTP 500. El equipo tiene que saber hacerlo antes de salir a producción.
Dónde ponemos el límite
Tratamos el mTLS como parte de la plataforma. Ningún equipo puede desactivarlo para cumplir un plazo. El mismo pipeline que aprovisiona un servicio aprovisiona sus certificados y los rota automáticamente, y un servicio sin mTLS hace fallar el build, igual que un test que falta o un control SAST que no se supera.
El mTLS no sustituye a la segmentación de red, al mínimo privilegio ni a la monitorización. Cierra un hueco concreto y habitual: suponer que todo lo que está dentro del perímetro es de confianza por defecto. Nosotros nunca lo suponemos.