Desde hace varios meses se distinguen claramente cuatro pilares que están cambiando la arquitectura de las aplicaciones y la forma en que interactuamos con ellas: las redes sociales, movilidad, cómputo en la nube y big data. Se estima que el número de usuarios de redes sociales alcanzó una cifra cercana a los 1,500 millones en 2012, que actualmente 79% de las organizaciones en los Estados Unidos está usando SaaS, que para 2016 se habrán realizado 305 mil millones de descargas de aplicaciones móviles, y que para 2020 habrá 50 mil millones de dispositivos conectados a la red.

Hasta hace unos años, las aplicaciones solían ser monolíticas y multifuncionales, sin embargo, hoy en día tienen funciones concretas (muy granulares), de diseño específico y ligeras, las cuales se mezclan con otras, igualmente ligeras y delimitadas, para crear, desde la perspectiva del usuario final, una colección de interacciones (“mashed up”) para un propósito, contexto y dispositivo específico.

Las nuevas arquitecturas aplicativas deben considerar capacidades que permitan a las organizaciones conectarse entre sus sucursales y con sus socios de negocio proveyendo accesos seguros y desde cualquier dispositivo tanto a las aplicaciones corporativas como a los servicios en la nube que utilicen. Se pueden generalizar dos capas, la de servicios de infraestructura y la de entrega de servicios de negocio. La primera normalmente es estable, no cambia con frecuencia e incluye servicios, aplicaciones e interfaces que sirven de plataforma para los servicios de negocio. La segunda capa es la que posibilita tener agilidad para liberar servicios y realizar cambios continuos conforme la dinámica del mercado lo exija.

Un mecanismo clave para habilitar estas arquitecturas está en las API (application programming interface). Si bien el concepto no es nuevo, si lo es su uso intensivo para la integración de aplicaciones con tecnología Web. Es por eso que el número de API públicas ha crecido exponencialmente en los últimos meses, aumentando tan sólo en 5 meses lo mismo que en los 135 meses previos. Y no sólo hay más API, también se observa un uso muy intenso pues, por ejemplo, el número de llamadas por día en Twitter es de 13 mil millones, 5 mil millones para Google, Facebook 5 mil millones y Ebay mil millones.

¿Y qué es una API? Es una especificación (rutinas, estructuras de datos, clases de objetos, variables, etcétera) diseñada para servir como interfaz para que los componentes de software se comuniquen entre ellos. De manera general se distinguen dos tipos: 1) Para los consumidores, las cuales transmiten información para el consumo público o para iniciar transacciones que están abiertas al público en general, 2) Corporativas, las cuales transmiten información sensible o ejecutan transacciones que sólo están a disposición de las contrapartes aprobadas y autenticadas.

Las API son pequeñas ventanas que exponen al mundo exterior los sistemas e información de las organizaciones, lo que también las convierte en puntos de exposición a ataques, por lo que tener aplicaciones Web que manejen información sensible y no estén debidamente aseguradas puede derivar en pérdidas financieras, fraudes, afectación legal, incumplimiento de normativas o regulaciones. Estos nuevos ambientes están expuestos a los ataques tradicionales como escalación de privilegios, DoS, malware, sniffing o spoofing, pero además a los nuevos que surgen, los cuales se pueden agrupar en tres grandes categorías:

  • Ataques a los parámetros, que se enfocan a explotar la información enviada dentro de las API (pueden ser URL, parámetros de instrucciones SQL, encabezados HTTP, etcétera).
  • Ataques a la identidad, que explotan fallas en la autenticación y autorización así como en el seguimiento a las sesiones.
  • Ataques de tipo hombre en medio (man-in-the-middle), dirigidos a interceptar transacciones legítimas y explotar información sin firmar o sin cifrar. Pueden revelar información confidencial, alterar información de transacciones o reproducir transacciones legítimas.

Es importante aclarar que las soluciones tradicionales que protegen los servicios Web no son suficientes para enfrentar estos nuevos riesgos, por lo que a continuación listo una serie de recomendaciones generales para quienes están ya trabajando en este tipo de iniciativas o para quienes lo están evaluando.

  • Desplegar una plataforma de gestión de API, ya sea a través de un API Gateway, de servicios Cloud Proxy (SaaS) o de un software plugin, que inlcuya, al menos, las siguientes funciones generales:
    • Transformación. Permiten la interoperabilidad entre distintos API a través de hacer la mediación de protocolos, mensajes y tokens. Incluye la transformación bidireccional de mensajes y protocolos en caso de que haya alguna incompatibilidad (por ejemplo XML-JSON o SOAP-REST); la intermediación (brokering) que facilita el desarrollo de API internos que interactúen con los  externos, con una misma función pero de distinto proveedor; y la orquestación que facilita la creación de nuevos servicios al negocio a través de combinar, totalizar, englobar y manipular los datos y funciones provistos por los API (ya sean internos o externos).
    • Control y gobierno. Control en tiempo real de los API, que permite medir y cumplir con los niveles de servicio y la calidad de experiencia a través del establecimiento de reglas específicas.
    • Seguridad. Protección contra ataques a nivel mensaje (message level firewall), control de accesos, protección de la información sensible para prevenir fugas, cifrado y “tokenization” (proceso en el que se sustituyen datos sensibles por valores -tokens- aleatorios y sin sentido para quien o accede a ellos de forma no autorizada).
    • Monitoreo y reporte. Permite crear bitácoras de auditoría y cumplimiento, monitoreo y alertamiento, e información para análisis.
    • Control del ciclo de desarrollo. Gestionar un API  a lo largo de su ciclo de vida, desde desarrollo hasta operaciones, pasando por pruebas, distribución, etcétera.
  • Considerar soluciones de API que se puedan integrar con las soluciones existentes de IAM (identity and access management), para posibilitar una correcta autenticación y autorización.
  • Implementar mejores prácticas de seguridad en el desarrollo de las API.
    • Validación de parámetros, es decir, validar los datos de entrada contra una lista de los valores esperados («whitelisting«).
    • Validar el contenido contra amenazas conocidas («blacklisting«).
    • Uso de técnicas para escaneo de virus de archivos transferidos vía API.
    • Utilizar métodos robustos de autenticación y autorización que contemplen diversos aspectos como usuario, aplicación, dispositivo, horario, lugar, etcétera. Considerar el uso del estándar Oauth que, aunque es incipiente, puede ayudar a limitar el acceso a las aplicaciones y a los datos.
    • Utilizar SSL lo más que se pueda.

.

Conclusión

Las API están siendo un habilitador clave de nuevas formas de crear aplicaciones que permitan a los negocios ser más ágiles, tener más clientes, aumentar sus ingresos (API economy), pero tienen sus implicaciones en cuanto a seguridad, por lo que resulta de suma importancia preparar arquitecturas robustas que contemplen elementos específicos de protección. Asimismo, es indispensable que las organizaciones definan una estrategia clara y concreta de API Management (conjunto de procesos y tecnologías que ayudan a las organizaciones para enfrentar los retos tanto de gestión como de seguridad que surgen en este tipo de ambientes).

 [email protected]

 Fuentes:

  • Speedcast. Harnessing The Power of APIs to Enable Mobile & Developer Initiatives. CA Technologies.
  • White paper. Enterprise API Management. Vordel.
  • White paper. Next Generation API Delivery Platform. Vordel.
  • White paper. Protecting your APIs agianst attack and Hijack. Layer7.
  • White paper. 20 ways to better deliver, manager and secure APIs. Vordel.
  • White paper. A How-to Guide to Oauth and API Security. Layer 7.
  • Reporte. API Management for Security Pros. Forrester.