Sin embargo, la realidad es que entre la aplicaci\u00f3n y el servidor pueden haber muchas paradas. En una implementaci\u00f3n m\u00e1s moderna es muy probable que el tr\u00e1fico en realidad se vea as\u00ed:<\/p>\n\n\n\n Para nuestra sorpresa, vemos que el tr\u00e1fico entre el Balanceador de Carga y el Manejador de APIs dice Cifrado\/Recifrado\/No cifrado, \u00bfqu\u00e9 significa esto? Pues, que es muy probable que cuando publiques tu API, el administrador de tu red te pida el certificado para asegurar la informaci\u00f3n. En muchas topolog\u00edas, se pone el certificado en el Balanceador de Carga para terminar el cifrado entre la aplicaci\u00f3n y la infraestructura de la compa\u00f1\u00eda en la puerta de entrada, y entre el Balanceador de Carga y el Manejador de APIs se puede crear una nueva sesi\u00f3n de TLS, o simplemente dejarlo sin cifrar. \u00bfEs seguro esto? En realidad, todo depende de c\u00f3mo ha sido dise\u00f1ada la infraestructura. Por ejemplo, si el Balanceador y el Manejador son un mismo producto, o corren en el mismo hardware, o en un ambiente herm\u00e9tico, es posible que esto suceda sin mayor peligro.<\/p>\n\n\n\n Algo a\u00fan m\u00e1s sorprendente es en el pr\u00f3ximo tramo, entre el Manejador de APIs y el servidor del API, no solamente el tr\u00e1fico no est\u00e1 cifrado, sino que adem\u00e1s, est\u00e1 pre-autenticado y pre-autorizado, en otras palabras, el servidor del API aceptar\u00e1 la palabra del Manejador de APIs Y NO VOLVER\u00c1 a verificar la autenticaci\u00f3n y autorizaci\u00f3n del pedido, sino que lo servir\u00e1 sin mayor precauci\u00f3n.<\/p>\n\n\n\n A simple vista, esto parece ser un problema serio, pero en realidad no lo es, es una ventaja muy grande. Si cada servidor de APIs tuviera que volver a implementar c\u00f3digo de autorizaci\u00f3n y autenticaci\u00f3n, nos encontrar\u00edamos con un dolor de cabeza en asegurarnos que cada API use exactamente el mismo nivel de seguridad en ambas funciones. APIs que fueron escritos hace dos a\u00f1os, tendr\u00edan que volverse a escribir para soportar las nuevas implementaciones o versiones de los algoritmos de seguridad. Las compa\u00f1\u00edas, para evitar la deuda t\u00e9cnica tendr\u00edan que usar un solo lenguaje de programaci\u00f3n y una librer\u00eda de autenticaci\u00f3n y autorizaci\u00f3n que sea actualizada constantemente y enlazada con el c\u00f3digo de los API. Eso es exactamente lo que el Manejador de APIs prov\u00e9e, un lugar com\u00fan donde estas funciones se ejecutan, dejando al mismo tiempo libertad de que cada API sea escrito en la tecnolog\u00eda m\u00e1s adecuada para ese API, teniendo la seguridad de que, si el pedido logra pasar por el Manejador de APIs, ha sido debidamente autenticado y autorizado.<\/p>\n\n\n\n Pero, eso todav\u00eda nos deja dos peque\u00f1as dudas, \u00bfpor qu\u00e9 no est\u00e1 cifrada la informaci\u00f3n entre el Manejador de APIs y el Servidor del API? y \u00bfC\u00f3mo sabe el Servidor del API que el pedido realmente viene del Manejador de APIs y no de un tercero? Buenas preguntas.<\/p>\n\n\n\n En cuanto a la primera, \u00bfes el mismo riesgo de no cifrar entre el Balanceador y el Manejador? No, el riesgo de no cifrar entre el manejador y el servidor es normalmente mayor. \u00bfPor qu\u00e9? Porque el Balanceador y el Manejador son normalmente piezas de infraestructura, dentro de un ambiente de redes f\u00edsico o virtual herm\u00e9tico, y esto no es necesariamente cierto entre el Manejador y tu servidor de APIs. Si tu infraestructura te puede asegurar una conexi\u00f3n de punto a punto entre el Manejador y tu Servidor que no pueda ser interceptada o inyectada por terceros, entonces no hay problema en que el tr\u00e1fico entre el Manejador y el Servidor sea sin cifrar, y preautorizada y preautenticada. Sin embargo, no siempre este es el caso, en muchas ocasiones tu vas a querer que tu servidor est\u00e9 cercano a tus datos, o en la nube, o por distintos otros motivos, lejos del Manejador. Entonces, \u00bfcu\u00e1l es la alternativa? mTLS.<\/p>\n\n\n\n mTLS significa autenticaci\u00f3n m\u00fatua, y en este caso es una tecnolog\u00eda usada para asegurarnos que, independientemente de cu\u00e1nta lejan\u00eda exista entre dos servidores, ambos puedan confiar que est\u00e1n hablando con el servidor correcto, y la informaci\u00f3n no puede ser descifrada por los diferentes puntos por los cu\u00e1les pase el tr\u00e1fico. Esto nos permite tener infraestructura en las nubes que sirva recursos on-prem, o infrastructura on-prem sirviendo recursos en las nubes, o cualquier combinaci\u00f3n anterior, es decir, nos libera de que las funciones est\u00e9n situadas en el lugar correcto sin tener que preocuparnos sobre la seguridad de la informaci\u00f3n en tr\u00e1nsito. <\/p>\n\n\n\n