SSL mutuo para clientes del servicio en la nube SaaS

0

Mi empresa está lanzando un servicio SaaS basado en la nube. Habrá clientes de diferentes inquilinos que se conectarán a nuestros servicios a través de SSL mutuo.

Los clientes usarían una biblioteca proporcionada por nosotros para conectarnos con el servicio. Esta biblioteca basada en Java realizaría SSL mutuo utilizando almacenes de claves y almacenes de confianza. Así que tanto el servidor como los clientes están bajo nuestro control. Para enfatizar, no hay navegadores involucrados en toda la comunicación.

Para realizar con éxito la autenticación SSL mutua, deben confiar en un certificado proporcionado por nuestro servicio en la nube. Este certificado podría ser:

  1. Un certificado de CA público (como Comodo, Verisign, etc.). Sin embargo, pedir a los clientes que confíen en una CA pública permitiría la posibilidad de ataques en el medio, ya que otra persona puede usar un certificado diferente firmado por la misma CA para engañar a los clientes.
  2. CA raíz privada de nuestro propio. Esto implicaría crear nuestro propio servicio PKI y asegurar la clave privada et al. ¿Justifica nuestra situación optar por esta ruta?
  3. Certificado autofirmado utilizado por el servidor y los clientes. Un problema que veo con esta solución es que cuando caduque el certificado, todos los clientes de los inquilinos tendrán que volver a configurar el nuevo certificado al mismo tiempo . Eso sería inaceptable.

Otra opción que he encontrado es usar algún tipo de anclaje SSL (certificado o clave pública) que anulará la cadena de confianza. Esta no es una solución fácil de implementar.

¿Cuál es la solución recomendada?

    
pregunta xsreality 11.12.2018 - 11:39
fuente

1 respuesta

0

Dado que tanto el cliente como el servidor están totalmente bajo su control, considero que es la mejor cosa (y quizás también la más fácil) confiar solo en certificados autoemitidos, de modo que no tenga que confiar en alguna CA externa que esté fuera de tu control.

Si solo tiene unos pocos compañeros de comunicación, puede ser fácil utilizar certificados autofirmados e intercambiarlos cuando sea necesario. Tenga en cuenta que, en este caso, simplemente podría incluir el certificado o la clave pública específica e ignorar cualquier caducidad, revocación, etc., ya que de todos modos todo está bajo su control directo.

Con más pares de comunicación, probablemente es mejor crear su propia estructura PKI, es decir, tener su propia CA raíz que emite certificados para clientes y servidores y que también puede renovar y revocar certificados. Una vez que se configura esta PKI, la gestión de los interlocutores de la comunicación se simplifica, ya que solo tienen que confiar en esta CA específica (y solo en esta CA). Ya se puede crear una estructura PKI simple con openssl pero también hay productos comerciales que pueden proporcionar una mejor usabilidad y también escalar mejor.

Dado que tiene control total sobre los clientes y el servidor, en realidad es posible comenzar de manera simple y barata (certificados autofirmados), crecer lentamente pero seguir siendo barato (CA basada en openssl) y luego pasar a una (no tan barata) Empresa CA cuando hay muchos clientes involucrados.

    
respondido por el Steffen Ullrich 11.12.2018 - 13:08
fuente