Cloudflare cuenta con una gran base de clientes de software como servicio (SaaS) que gestionan miles o millones de dominios de clientes que utilizan su servicio SaaS. Hemos ayudado a esos proveedores de SaaS a crecer, ampliando nuestra infraestructura y nuestros servicios a los dominios de sus clientes con un producto llamado Cloudflare para SaaS. Estamos encantados hoy de ofrecer a nuestros proveedores de SaaS una nueva herramienta que ayudará a sus clientes a añadir una capa adicional de seguridad. Ahora pueden activar la autenticación de TLS mutuo en los dominios de sus clientes a través de nuestro producto Access.
Manual sobre el TLS mutuo
Cuando te conectas a un sitio web, deberías ver un icono de candado en la barra de direcciones. Se trata de tu navegador indicándote que te estás conectando a un sitio web a través de una conexión segura, y que el sitio web tiene un certificado TLS público válido. Los certificados TLS mantienen encriptado el tráfico de Internet mediante el uso de un par de claves públicas/privadas para encriptar y desencriptar el tráfico. También proporcionan autenticación, lo cual muestra a los clientes que se están conectando al servidor correcto.
Para establecer una conexión segura, debe llevarse a cabo un protocolo de enlace TLS. Durante el mismo, el cliente y el servidor intercambian claves criptográficas, el cliente autentifica la identidad del servidor, y tanto el cliente como el servidor generan claves de sesión que luego se utilizan para encriptar el tráfico.
Un protocolo de enlace TLS se parece a esto:
En un protocolo de enlace TLS, el cliente valida siempre el certificado que proporciona el servidor, para asegurarse de que está enviando las solicitudes al destino correcto. De igual forma que el cliente necesita autenticar la identidad del servidor, a veces el servidor necesita autenticar al cliente, para asegurarse de que solo los clientes autorizados envíen solicitudes al servidor.
Digamos que estás gestionando unos cuantos servicios: el servicio A introduce información en una base de datos. Esta base de datos es fundamental y solo debe tener entradas que haya enviado el servicio A. Ahora bien, ¿qué sucede si tienes un error en tu sistema y el servicio B realiza por accidente una llamada de escritura a la base de datos?
Necesitas algo que compruebe si un servicio está autorizado a realizar llamadas a tu base de datos, como un "portero de discoteca". Un portero de discoteca tiene una lista VIP, y puede comprobar los DNI de las personas con la lista para ver si tienen permiso para entrar en el local. Los servidores pueden usar un modelo similar, que utiliza los certificados TLS como forma de identificación.
Igual que un portero de discoteca tiene una lista VIP, un servidor puede tener un certificado de CA raíz desde la que emite certificados. Los certificados emitidos por la CA raíz se entregan entonces a los clientes. Estos certificados de cliente se pueden usar para identificar y autorizar al cliente. Siempre que un cliente presente un certificado válido, que el servidor pueda validar con la CA raíz, podrá realizar solicitudes. Si un cliente no presenta un certificado de cliente (es decir, no está en la lista VIP) o presenta un certificado de cliente no autorizado, el servidor puede optar por rechazar la solicitud. Este proceso de validación de los certificados de cliente y de servidor se conoce como autenticación de TLS mutuo (mTLS), y se produce durante el protocolo de enlace TLS.
Cuando no se utiliza mTLS, solo el servidor es responsable de presentar un certificado, que el cliente verifica. Con mTLS, tanto el cliente como el servidor presentan y validan los certificados del otro, como se muestra en la siguiente imagen.
mTLS + Access = Zero Trust
Hace unos años, añadimos la compatibilidad con mTLS a nuestro producto Access, lo cual permite que los clientes habiliten una política de Zero Trust en sus aplicaciones. Los clientes de Access pueden implementar una política que dicte que todos los clientes deben presentar un certificado válido al realizar una solicitud. Esto significa que las solicitudes realizadas sin un certificado válido, normalmente de clientes no autorizados, serán bloqueadas, y se añadirá una capa adicional de protección. Cloudflare ha permitido que los clientes configuren mTLS en sus dominios de Cloudflare estableciendo políticas de Access. El único pero es que, para utilizar esta función, tenías que ser el propietario del dominio. Ahora bien, ¿qué sucede si no eres el propietario de un dominio, pero sí gestionas el origen de ese dominio? Este es el caso de muchos de nuestros clientes, los proveedores de SaaS que amplían sus servicios a los dominios de sus clientes que no son de su propiedad.
Ampliar las ventajas de Cloudflare con los proveedores de SaaS
Cloudflare para SaaS permite que los proveedores de SaaS amplíen las ventajas de la red de Cloudflare a los dominios de sus clientes. Estos dominios no son propiedad del proveedor de SaaS, pero usan el servicio del proveedor de SaaS, enrutado el tráfico de vuelta al origen del proveedor de SaaS.
Al hacer esto, los proveedores de SaaS asumen la responsabilidad de proporcionar a sus clientes el mayor tiempo de actividad, un rendimiento extremadamente rápido y una seguridad inigualable. Algo que pueden ampliar con facilidad a sus clientes a través de Cloudflare.
Cloudflare para SaaS empezó como SSL para SaaS. Desarrollamos SSL para SaaS para que los proveedores de SaaS pudieran emitir certificados TLS para sus clientes, manteniendo a los clientes del proveedor de SaaS seguros y protegidos.
Desde entonces, nuestros clientes de SaaS nos han pedido ampliar la compatibilidad de mTLS que creamos para nuestros clientes directos, pero a sus clientes.
¿Por qué querrían los proveedores de SaaS usar mTLS?
Como proveedor de SaaS, hay una amplia gama de servicios que puedes ofrecer. Algunos de estos servicios requieren mayores controles de seguridad que otros.
Digamos que la solución de SaaS que estás desarrollando es un procesador de pagos. Cada cliente tiene su propio punto final de la API al que sus usuarios envían solicitudes, p. ej., pay.<business_name>.com. Como procesador de pagos, no quieres que cualquier cliente o dispositivo pueda realizar solicitudes a tu servicio, solo quieres que lo hagan los dispositivos autorizados. Eso es exactamente lo que hace mTLS.
Como proveedor de SaaS, puedes configurar una CA raíz para cada uno de los puntos finales de la API de tus clientes. Luego, haz que cada CA raíz emita certificados de cliente que tendrán que instalarse en los dispositivos autorizados. Una vez instalados los certificados de los clientes, solo hay que aplicar una comprobación de certificados válidos.
Para resumir, de esta manera, como proveedor de SaaS, tus clientes pueden asegurarse ahora de que las solicitudes destinadas a su punto final de la API de procesamiento de pagos provengan solo de dispositivos válidos. Además, al implementar certificados CA raíz individuales para cada cliente, también evitas que los clientes que están autorizados para realizar solicitudes al punto final de la API de un cliente las realicen al punto final de la API de otro cliente, cuando no tienen autorización para ello.
¿Cómo lo configuras con Cloudflare?
Como proveedor de SaaS, configura Cloudflare para SaaS y añade los dominios de tus clientes como nombres de host personalizados. A continuación, en el panel de control de Cloudflare for Teams, añade la autenticación mTLS con solo unos clics.
Esta función se encuentra actualmente en fase beta y está disponible para los clientes Enterprise. Si tienes algún comentario, coméntaselo a tu equipo de cuenta.