Posted: 03 Mar. 2021 15 Tiempo de lectura

Seguridad en el entorno Mulesoft

En el entorno Mulesoft es muy importante analizar todos aquellos puntos donde nuestra plataforma puede ser vulnerable y/o estar expuesta a riesgos, y al mismo tiempo intentar mitigar los riesgos hasta un punto que sea aceptable, o incluso eliminarlos. Riesgos siempre van a existir, sobre todo porque una gran parte de nuestro trabajo se basa en las acciones humanas. Y ojo, que las automatizaciones tampoco están libres de riesgos.

Dentro de la arquitectura de seguridad en el mundo Mulesoft, voy a distinguir seis grandes bloques que incluyen aquellas áreas que están expuestas a riesgos:

1.       Seguridad de infraestructura

2.       Seguridad de la plataforma, haciendo referencia a la plataforma de Mulesoft.

3.       Seguridad del canal

4.       Seguridad del usuario

5.       Seguridad del mensaje

6.       Seguridad de código

1.       Seguridad de infraestructura

Cuando hablamos de seguridad de infraestructura en el mundo Mulesoft es la seguridad de los componentes de hardware y software sobre los que se instala y ejecuta el producto de Mulesoft.

El Runtime de Mulesoft es un Runtime ligero basado en Java que únicamente necesita de una JVM para poder ser ejecutado, lo que hace que pueda ser instalado en prácticamente cualquier plataforma, lo que hace que la seguridad de la infraestructura sobre la que se instala difiera mucho y sea dependiente del tipo de instalación.

Aunque la seguridad pueda diferir en función de la instalación, los riesgos que nos encontramos son prácticamente comunes a todas ellas:

1.       Accesos no autorizados: Siempre existe el riesgo de que un hacker, una persona ajena, la organización o incluso personas dentro de la organización puedan acceder a la infraestructura, y este puede ser un punto de entrada a nuestras APIs y mucho mas allá.

2.       Caída del sistema: Los accesos no autorizados pueden directa o indirectamente provocar caídas, bloqueos o incluso secuestro de los sistemas. También se pueden sufrir ataques (DDOS por ejemplo) que pongan en riesgo la infraestructura.

3.       Robo de información: Los acceso nos autorizados maliciosos generalmente tienen un objetivo: el robo de información de los clientes. Ya sean cuentas bancarias, datos personales, direcciones, etc.

Todos estos riesgos tienen consecuencias: pérdida de clientes, el daño reputacional (la reputación cuesta muchísimo ganarla pero solo falta un pequeño detalle para perderla) y algo mas grave aún para las compañías, puede conllevar multas o sanciones importantes por parte de las entidades reguladoras. Hay procesos que se consideran críticos dentro de las empresas y que son monitorizados por los entes reguladores.

En el caso de la infraestructura, las soluciones de seguridad difieren mucho en cada tipo de instalación. Podemos englobar tres grandes grupos:

1.       Cloudhub. Cloudhub es la solución IPaaS (Integration Platform as a Service) de Mulesoft, donde se brinda a los clientes una plataforma libre de mantenimiento de hardware y software base, el mantenimiento de todo ello es realizado directamente por Mulesoft quien garantiza un SLA de servicio.

Cloudhub se basa en AWS, y el usuario de Cloudhub no interactúa en ningún momento con la infraestructura base, siendo Mulesoft responsable de la seguridad. En caso de existir cualquier riesgo Mulesoft siempre informa a los clientes, y se publican en la pagina de status.mulesoft.com. Por ejemplo, hace pocos días por un problema de seguridad se resetearon todos los accesos a Anypoint y se solicitó a todos los clientes que restauraran su contraseña.

Otro punto muy a favor de Cloudhub es que además de disponer de todas las versiones de Runtime disponibles, estas son actualizadas periódicamente sin intervención del usuario.

2.       El segundo tipo de instalación común es trabajar sobre un proveedor cloud. Ya sea AWS, Azure, GCP, Alibabá, etc. Para instalaciones mas específicas como Runtime Fabric solo es configurable de momento en AWS y Azure.

En este tipo de instalaciones la seguridad recae en el proveedor de cloud, pero el usuario privilegiado de la plataforma Cloud es quien administra y configura la seguridad de los distintos componentes y servidores. También es responsable del parcheo de los componentes. Sólo en aquellos servicios de tipo gestionado esta responsabilidad recae en el proveedor de Cloud.

3.       Por último el tipo tradicional, instalación en los servidores on-premise del cliente. Muy similar al proveedor cloud, pero aquí es el cliente el responsable del hardware.

2.       Seguridad de la plataforma

Definimos la seguridad de plataforma en Mulesoft como la seguridad en el acceso a la plataforma Anypoint y a sus distintos subcomponentes (API Manager, Runtime Manager, etc.).

Los riesgos a los que nos exponemos aquí son los mismos a los que nos exponíamos en infraestructura:

1.       Accesos no autorizados a la plataforma:

2.       Caída del sistema: Un acceso no autorizado puede conllevar acciones sobre el Runtime que provoquen indisponibilidades o caídas que pueden ser realmente difíciles de diagnosticar.

3.       Robo de información: Igualmente, el acceso no autorizado puede llevar a ver logs, analíticas y datos sensibles de clientes.

¿Qué nos ofrece la plataforma para hacer frente a este tipo de situaciones? Primero, hay que dejar claro que esta situación es difícil de detectar.

Anypoint tiene un acceso por usuario y password, y aunque un usuario nuevo no tiene ningún permiso a no ser que un usuario administrador se lo conceda, es muy importante solo dar acceso a la plataforma a las personas que realmente lo deban tener. Cada persona con acceso es un punto de riesgo en la plataforma.

Como punto positivo, la plataforma tiene un sistema de permisos y roles muy avanzado que permite granular los permisos de una manera muy óptima. Los roles por defecto son muy útiles aunque recomiendo siempre revisar los permisos que debe tener cada persona.

Para poder tener opciones avanzadas de seguridad, la plataforma nos permite integrar su login con proveedores IDP que sean compatibles con SAML o OpenId Connect. Esto nos permite, por ejemplo, integrar Anypoint con el LDAP empresarial.

La plataforma también proveé en su modulo de Access Management un sistema de auditoría donde se puede visualizar las acciones realizadas por un usuario. Este log puede ser integrado con herramientas externas via el API que expone Mulesoft para detectar accesos indebidos y/o acciones indebidas.

Hay que recalcar, por último, lo importante que es tener una buena gestión de credenciales y permisos.

3.       Seguridad del canal

En una plataforma API donde por definición utilizamos sockets y protocolos HTTP, SMTP, FTP, etc. es importante que el canal, que es por donde viaja la información, sea seguro. No es lo mismo viajar por una autopista perfectamente señalizada y con los sentidos separados y las entradas y salidas preparadas, que por una carretera regional con un carril por sentido, llena de camiones, con curvas, animales y entradas casi sin señalizar.

Los riesgos a los que nos enfrentamos en el canal son:

1.       Captura de tráfico, que puede conllevar un robo de credenciales o robo de información sensible.

2.       Accesos no autorizados. Si una API no tiene ningún sistema de autenticación cualquiera la puede consumir. ¿Dejarías la puerta de tu casa abierta de par en par?

3.       Ataques contra la infraestructura: un canal no seguro puede ser sensible a ataques de denegación de servicio u otro tipo.

¿Qué podemos hacer para defendernos contra esto? En Mulesoft, por definición, creamos APIs REST. En una plataforma de API Management como Mule lo que prima son las APIs REST. Y las APIs REST se basan en comunicación HTTP.

Como primera recomendación nunca tenemos que utilizar protocolo HTTP plano. El protocolo HTTP plano hace que el tráfico sea fácilmente capturable. Ya habréis visto que los principales navegadores avisan sobre los sitios que usan HTTP Plano, ya que la información que se recibe no puede ser validada. Como punto importante, en la arquitectura de tres capas de Mulesoft hay veces que las APIs de proceso y APIs de sistema no están expuestas a Internet o a los consumidores, y se pueden poner como HTTP. No lo recomiendo, en el caso improbable de que alguien acceda a nuestra infra podría capturar este tráfico. En resumen, siempre utilizar protocolos seguros: HTTPS nunca HTTP, FTPS/SFTP nunca FTP, etc.

Para securizar el canal podemos utilizar filtrados por IP, ya sea por Whitelist (deniego todo y solo permito el acceso a ciertas IPs) o Blacklist (permito todo y bloqueo ciertas IPs). Importante comentar que aunque es un sistema de seguridad válido, el filtrado por IP se basa en la información que llega del llamante, y un atacante malicioso con los conocimientos necesarios podría hacer pasar su IP por otra saltándose este bloqueo. Por ello, este tipo de seguridad nunca ha de ser usada como único sistema, sino que debe ser usada en conjunción con un sistema de autenticación. Importante recalcar que utilizando el API Manager de Mulesoft se puede configurar una política de Whitelis/Blacklist en unos pocos clicks.

Por último, siempre existe la opción de crear un canal seguro utilizando autenticación mutua SSL/TLS con certificados. En el caso de Cloudhub es preciso contratar como mínimo un Dedicated Load Balancer para poder disponer de esta opción, que tiene coste pero que también facilita la configuración y mantenimiento a unos pocos clicks. En otros tipos de instalación ya depende del desarrollo de las APIs. Esta opción es importante cuando la información que viaja por el canal se considere como sensible, aunque introduce un desarrollo técnico complejo en la parte cliente por lo que normalmente no se utiliza en caso de APIs públicas.

4.       Seguridad de usuario

Definimos seguridad de usuario en dos partes, primero la autorización que es la necesidad de que el usuario de permiso explícito al acceso a su información, y de autenticación, cuando el usuario da permiso solo a usuarios reconocidos.

Los riesgos a los que nos enfrentamos en esta parte son los que ya hemos hablado:

1.       Robo de información

2.       Accesos no autorizados

3.       Ataques contra la infraestructura

¿Qué podemos hacer para solucionar esto a nivel usuario y poder garantizar que solo los usuarios conocidos y con los permisos necesarios acceden a la información?

Tenemos tipos de autenticación ampliamente utilizados en el mercado:

-         Uno de los más comunes es Oauth (o su evolución OpenId Connect). Aquí se desacopla la autenticación de la autorización. Se basa en que un usuario dispone de su información en un recurso (servidor de recursos). Para poder acceder a la información del recurso, ha de solicitar acceso a través de un servidor de autenticación (servidor OAuth), al que el peticionario envía su identidad y el recurso al que quiere acceder. Si el peticionario es detectado como un usuario conocido y con los permisos necesarios se le facilita un código de autorización temporal (como si fuera una llave) para poder llamar al servidor de recursos. Esta llave siempre es temporal, y el acceso al recurso puede ser restringido por el propietario de este en cualquier momento. La implementación de esto generalmente es que disponemos de un endpoint de autenticación, generalmente protegido con una autenticación básica que permite autenticar al llamante, donde el usuario envía su credencial y el recurso que es lo que solemos llamar un scope. Si la llamada es correcta y el peticionario tiene acceso al recurso (scope) se devolverá un access_token que es la “llave” con la que puede llamar al endpoint del API. Al llamar al API con este access_token, la misma valida de nuevo contra el endpoint de autenticación que la llave es válida para el recurso solicitado y en caso correcto devuelve la información solicitada. Este sistema es muy versátil ya que puedes tener scopes para cada recurso o incluso diferentes scopes para un mismo recurso pero con diferente nivel de detalle. Este es el sistema más ampliamente utilizado en el mundo API.

-         Como segundo punto, tenemos la autenticación de tipo básica. Generalmente es simplemente una concatenación de un usuario y contraseña separados por dos puntos y codificado en Base64. Luego el API valida estas credenciales ya sea contra unas credenciales fijas, unas credenciales de tipo cliente (client credentials) o incluso contra un servidor LDAP. En este sistema la autenticación y la autorización están unificadas.

-         Como tercera opción tenemos los tokens JWT. Existen dos tipos de estos tokens; los firmados con una clave “fija” (HMAC) o los firmados mediante certificado RSA. Este tipo de tokens son ampliamente utilizados para autenticación (sobre todo los RSA) que identifican al usuario o sistema.

-         Por último, tenemos un sistema por Client Credentials. Mulesoft por defecto facilita este tipo de gestión de credenciales, típico de APIs. Además, con este tipo de autenticación se identifica fácilmente al consumidor de la API, lo que nos puede permitir monetizar las APIs si así lo deseamos, o incluir políticas de SLAs o Rate Limiting.

Para las cuatro opciones comentadas Mulesoft dispone de políticas a través del API Manager que facilitan su gestión con pocos clicks. Además, estos tipos de autenticación son ampliamente utilizados en conjunción unos con otros. Por ejemplo, es típico en Oauth que endpoint de autorización esté securizado con una autenticación basic. O el JWT se puede utilizar también en conjunción con Oauth haciendo más potente aún la autenticación. Incluso además de añadir un tipo de autenticación cliente como puede ser Oauth, se puede añadir una política por Client Credentials que también garantiza la identidad del consumidor del API.

Recalcar lo importante que es tener siempre securizados los endpoint, sobre todo si tratan cualquier tipo de información sensible. Y también lo importante que es tener una correcta gestión de credenciales. Es habitual encontrar correos electrónicos con credenciales de sistema o APIs, y eso es sin duda una mala práctica porque nunca sabes dónde van a acabar dichas credenciales.

5.       Seguridad del mensaje

Definimos la seguridad de mensaje como la seguridad de la información que se intercambia. Es muy normal que la información que se envía o se recibe a través de un API esté en lo que denominamos “en claro”, es decir, que es simplemente un JSON o un XML que fácilmente podrían ser interpretados en caso de que el tráfico sea capturado.

¿Qué riesgos tenemos en el tratamiento del mensaje? Primero el robo de información. Si el tráfico es capturado o redirigido a un sitio malicioso, es fácilmente legible e interpretable. El segundo, el tratamiento de información sensible. Si nuestros mensajes contienen información sensible de clientes como puede ser su nombre, su identificación, si dirección, teléfono, email, etc. En resumen, cualquier información que permita identificar al cliente debe ser tratada como confidencial y su información debe estar protegida.

Luego tenemos interfaces, generalmente de envío de información, donde hay que garantizar que desde que la información sale del emisor hasta que llega al receptor no ha sido modificada en el tránsito, lo que equivale a una firma. De esta manera se evitan fraudes y problemas.

El resultado final de un problema de seguridad en cualquiera de estos puntos son los mismos que hemos analizado a lo largo del artículo.

¿Qué acciones podemos tomar para salvaguardar la información de los clientes?

Pues la primera opción sería una payload cifrada. Se puede descifrar fácilmente pero debes saber cómo ha sido cifrada.

Una mejora de esto son los JWT firmados, donde la información viaja cifrada y además dentro de un JWT firmado. Esto se suele utilizar en transacciones económicas e interfaces de envío de información oficial, donde es necesario que dicha información sea validada y el emisor sea reconocido.

También tenemos los HASH que nos permiten asegurar que la información que se recibe es exactamente la que ha sido generada desde el emisor. Una buena práctica es incluir este HASH dentro de un JWT firmado, de tal manera que no pueda ser modificado, y que valide la información enviada en la payload.

Por último, la ofuscación de datos. Mulesoft en Runtime Fabric tiene un servicio de tokenización y detokenización que permite enmascarar los datos enviados en la payload. También la ofuscación de la información es importante. Si es posible enviar los datos del cliente ofuscados al receptor ya que no necesita el dato exacto es mucho más seguro.

6.       Seguridad de código

Se trata de la seguridad del código de las APIs y de sus librerías y componentes asociados.

Esto está muy ligado al desarrollo. Al final en Mule la mayoría del desarrollo se hace "moviendo cajitas" y configurándolas (lo que hace el desarrollo en Mule tan ágil) aunque siempre tenemos la opción de introducir código, tanto en Dataweave como en Java.

¿Qué riesgos tenemos aquí? El primero, modificaciones maliciosas de código. Ejemplos: si alguien accede a nuestra plataforma y se descarga el código de nuestras APIs (lo que es posible aunque no hayamos añadido las fuentes) puede modificar dicho código y por ejemplo añadir una llamada a un API externa donde se envíen todos los datos que enviamos a un front. Esto nos lleva al segundo riesgo, que es el robo de información. También es posible que alguien acceda a nuestro repositorio de código y modifique el código de manera maliciosa sin que lo sepamos, y que al subir una nueva versión o se lance un job de integración continua, se despliegue.

Y luego están las vulnerabilidades. Con esto me refiero al propio Runtime de Mule, que al final es un Runtime de Java y aquellas librerías añadidas manualmente por el usuario en caso de añadir clases customizadas.

¿Qué podemos hacer para mejorar la seguridad de código?

1.       Añadir un sistema de integración continuo y/o despliegue continuo. Esto reduce sensiblemente la posibilidad de que un tercero modifique el código de nuestra aplicación.

2.       Para una correcta gestión, unido a lo comentado de seguridad de plataforma, solo deben tener permisos de despliegue los usuarios realmente necesarios, e incluso mejor si se reduce al usuario de integración continua.

3.       Seguridad de los repositorios. Es importante que solo tengan opción de ver y modificar los repositorios de código aquellas personas realmente autorizadas. Es buena práctica que los merge en las ramas principales como develop o master solo lo realicen usuarios controlados.

Un punto importante son los ficheros de configuración y las properties de Runtime Manager. Es típico almacenar en estos ficheros usuarios y contraseñas de acceso a otros sistemas que en caso de acceder al código del API serían fácilmente identificables. Para ello, Mule nos permite configurar las credenciales de manera encriptada que hace que solo sean interpretables por el Runtime de Mule. Las properties que se incluyen en Runtime Manager se pueden marcar como seguras para que aparezcan asteriscadas y no se pueda leer su contenido completo.

Por último, es muy importante mantener actualizados tanto la versión del Runtime como de las librerías custom que podamos añadir en los proyectos. Mulesoft publica mensualmente actualizaciones de todas sus versiones de Runtime, y en caso de detectar alguna vulnerabilidad siempre saca actualizaciones urgentes.

7.       Resumen

La seguridad en Mulesoft no es simplemente la autenticación de las APIs, debemos de verlo como un todo y tenemos vulnerabilidades en muchos puntos que requieren de nuestra atención.

Los principales riesgos a los que nos enfrentamos son:

-         Modificaciones maliciosas de código.

-         Robo de información, ya sea capturando el trafico o en los logs.

-         Vulnerabilidades, es muy importante mantener los Runtime y los componentes siempre correctamente actualizados.

-         Prevenir accesos no autorizados mediante una correcta gestión de credenciales y añadiendo si es posible una autenticación multifactor en la plataforma.

-         Prevenir ataques protegiendo todos los puntos de la infra, de la plataforma y de las APIs.

Al final un problema de seguridad puede causar consecuencias tan graves como la perdida de clientes, daño reputacional o incluso multas o sanciones por parte de los reguladores.

Como acciones mitigadoras importantes (hay muchas más) tenemos:

-         Utilizar sistemas de integración y despliegue continuo, que garanticen que el software que se despliega ni ha sido modificado por terceros y ha pasado los test necesarios de calidad.

-         Securizar siempre el canal y cuando sea necesario también el mensaje. Sobre todo cuando la información que se trata es confidencial.

-         Mantener el Runtime de Mule, el software base de los servidores donde se ejecuta Mule y los componentes custom siempre actualizados, sobre todo si se detecta alguna vulnerabilidad importante.

-         Tener una correcta gestión de credenciales y de permisos en la plataforma.

-         Añadir siempre políticas de autenticación que garanticen la identidad de los consumidores y políticas de protección que protejan las APIs y la infraestructura.

Vuelvo a recalcar, ver la seguridad en Mulesoft como un end to end y algo global debe ser, sin duda, una de nuestras principales preocupaciones.

 

Autor del artículo

Pablo Pardo, specialist lead de Consultoría Tecnológica de Deloitte