Proteger los servicios: el caso de BICI_MAD

En los últimos días ha sido interesante ver como en la ciudad donde vivo se ha puesto en marcha una interesante iniciativa para el alquiler de bicicletas, BICI_MAD.

Independientemente de los muchos comentarios que ha habido, me ha llamado poderosamente la atención el hecho de que un servicio expuesto a potencialmente una gran cantidad de usuarios no haya estado operativo durante días solamente porque ha muerto de éxito.

¿Qué podríamos haber hecho diferente?
El hecho de que una cierta campaña pueda convertirse en viral no debería afectar a la infraestructura tecnológica hasta dejarla fuera de combate. Y es aquí donde entiendo que el consumo de los servicios web expuestos debe contenerse de forma que no se rompan aquellos límites que hayamos establecido en las pruebas de carga.
Si hemos establecido un número máximo de peticiones por unidad de tiempo (segundos, minutos, horas incluso), debemos reforzar la capacidad de la infraestructura existente controlando estas peticiones y añadiendo los controles necesarios para que no se superen. Es lo que en la lengua de Shakespeare se denomina “Throttling control”.
Dentro de API Gateway (http://www.axway.com/products-solutions/api-management/api-gateway) podemos establecer el mecanismo oportuno para el “Throttling control” de forma que no se superen los límites de la infraestructura, se bloqueen aquellas peticiones en exceso, y se permita que los usuarios que puedan acceder al sistema puedan cumplimentar sus peticiones adecuadamente, y así progresivamente dar servicio a todo el conjunto de usuarios que están pretendiendo realizar una acción.
Como se puede ver en la captura de pantalla de este componente, sólo es necesario configurar unas pocas propiedades para poder disfrutar de las capacidades comentadas.
throttling
De esta forma protegemos los servicios expuestos ante un fenómeno viral.
¿Qué ocurre cuando un atacante intenta efectuar un ataque del tipo DOS (Denegación de servicio) o DDOS (Denegación de servicio distribuida)?

Principalmente lo mismo, intenta realizar tantas llamadas como sean posibles contra el servicio expuesto y de esta forma saturar el sistema hasta que caiga y permanezca fuera de servicio por el mayor tiempo posible. En este caso, vamos a utilizar un mecanismo de protección similar utilizando el “Throttling control” para gestionar el uso del servicio.

Advertisements

Integración con la nube – Google, Microsoft y Salesforce

Recientemente escribía acerca de la integración con la nube, que no integración en la nube, acerca de los retos u objetivos que podemos encontrar al realizar dicha integración a nivel de los diferentes formatos y las capacidades para la gestión de identidades.

Desde que hablo de integración los grandes facilitadores de cualquier integración han sido siempre los conectores específicos para los distintos sistemas. Ántes dichos conectores específicos se diseñaban para los diferentes sistemas on-premise, como CRM, ERP, Billing, etcétera y con la proliferación de aplicaciones en la nube, son los conectores específicos para las aplicaciones en la nube los que marcan la diferencia.

Hoy quería hablar de dos de esos casos en los que el interés crece por momentos, son las integraciones con aplicaciones en la nube provistas por Google, Microsoft Windows Live Connect y por Salesforce. En estos casos hay diversas formas de autenticación, como por ejemplo SAML, y últimamente OAuth 2.0 es la que está tomando más fuerza.

Como quiera que cada gestor de identidades hace una implementación OAuth a su medida, lo mejor es pode utilizar un conector específico para cada uno de estos proveedores: Google, Microsoft Windows Live Connect y Salesforce.

En la última versión de API Gateway están disponibles los conectores OAuth específicos para las mencionadas plataformas.

OAuth2_client_credentials

La gran ventaja de los conectores específicos, es en este caso que con un simple drag’n drop se puede configurar una política de conexión con nuestra aplicación favorita en la nube en minutos, sin necesidad de pasar horas y horas de desarrollo, pruebas, y malos ratos.

 

 

API Workshop en Madrid – 10 de Julio

Después de participar en varios API Workshops en la región europea, nosotros los estamos llamando Tech Labs, el próximo 10 de Julio tendrá lugar el API Workshop en Madrid.

¿Pero que es un API Workshop? Es un evento diseñado desde el punto de vista más práctico, y con la intención más clara de que los participantes puedan configurar ellos mismos su solución a un problema. Por eso también lo denominamos tech lab, o laboratorio de tecnología.

Durante una mañana, centramos el tema principal del API Workshop entorno a la economía de las APIs, la realidad del B2B respecto a las APIs y servicios web, la gestión de comunidades de desarrolladores (B2D – Business to Developer).

Después de las presentaciones lo más importante va a ser el utilizar los puestos disponibles para la configuración de los distintos casos de uso que proponemos durante la sesión:

  • Gestión de APIs, la exposición de un API existente, con el gobierno de su uso desde el punto de visto de monitorización de explotación, identificación de aplicaciones usuarias, y control del ciclo de vida.
  • Securización de WebServices, encontramos muchos casos de mezcla de lógica de negocio y seguridad, en este caso de uso establecemos una capa de seguridad sobre servicios web existentes de forma que establecemos un PEP (Policy Enforcement Point).
  • Conexión con la nube, integrar tus aplicaciones en el datacenter con aquellas soluciones existentes en la nube puede ser un caso de uso encima de tu mesa hoy. Nuestros participantes configurarán un escenario de acceso a Salesforce.com.
  • Si gestionar los servicios (APIs o SOAP / WOA o SOA) existentes es un problema para ti, podrás aprender a utilizar la tecnología de API Gateway para gobernar tus servicios existentes y establecer un sistema de cuotas sobre ellos.

 Y como puedes leer, todo desde un punto de vista meramente práctico, con ejemplos de la vida real, y una exposición sobre casos de usos reales de hoy en día.

Si quieres participar en un evento de estas características puedes Registrarte gratis para el API Workshop.

 

 

 

Integración con la nube

Es uno de esos temas que durante los últimos años me han tenido bastante humm digamos atareado, la integración de aplicaciones.

La integración de aplicaciones está siempre en el centro de lo que hago, y a ciencia cierta que con el advenimiento de la nube plantea nuevos retos y no menos quebraderos de cabeza a un arquitecto empresarial.

 

Los formatos

Uno de estos retos es la utilización de aquellos formatos de mensaje que sean compatibles en ambos lados de las aplicaciones a integrar, en nuestro caso particular nos encontraremos con aplicaciones en la nube que nativamente exponen un interfaz en formato JSON, que nos facilita sobretodo la integración. Si nos detenemos a hacer un cálculo en base al número de transacciones por segundo, contra el tamaño medio de ellas, podemos darnos cuenta de la gran ventaja contra el otro formato habitual en la nube, XML.

Dentro de las aplicaciones que tendremos dentro de las instalaciones de la empresa, en algunos afortunados casos tendremos una capa normalizada en formato JSON, que nos permita hacer una integración sencilla con la nube. En otros casos el interfaz será XML, y con una pequeña transformación de formato podremos tener la integración entre ambos mundos finalizada de una forma rápida.

Hay un tercer caso, si nos ceñimos puramente al formato de los datos, en el que el formato de los datos es texto plano, bases de datos, o cualquier combinación de todos los anteriores. A veces esta complicada arquitectura de datos nos hace ver el firewall como una barrera para enfrentarnos al exterior, más que aquella barrera que nos protege de los intrusos.

Nada más lejos de la realidad, es entonces cuando la figura de una capa de mediación que siendo capaz de trabajar nativamente en el formato JSON, nos permita exponer aquellos servicios web SOAP, servicios REST, servicios EJB, servicios expuestos como procedimientos de bases de datos, o incluso servicios del Mainframe. Entender todos aquellos formatos, y exponerlos como una única capa normalizada nos facilita enormemente la integración de datos entre ambos lados del firewall.

 

¿Quién es Quién?

El segundo reto, de otros muchos que seguiré comentando, es la gestión de las identidades entre ambas aplicaciones a integrar. Dependiendo del caso de uso, tendremos una serie de usuarios de una aplicación en la nube, que no necesariamente tienen que corresponder con los mismos en las aplicaciones internas. En este caso, ser capaz de entender ambos sistemas de gestión de identidad, y poder realizar la mediación entre ambos para poder realizar una más que necesaria federación de identidades.

 

¿Cuál es la ventaja principal para un usuario?

Más allá de la conveniencia para un arquitecto empresarial, o para la gestión de TI, el propósito principal es tener una única visión para los usuarios finales, independientemente de dónde se encuentre la aplicación, e incluso de si la aplicación final es una conjunción de dos aplicaciones como es el caso. Y sobre todo para un usuario, sin tener que recordar diferentes contraseñas y para el que al final la gran ventaja es que las aplicaciones sobre las que trabaja le presentan un único interfaz, utilizando aquellos servicios que los arquitectos empresariales han designado a tal efecto.

 

IoT ya no es el futuro, el futuro está aquí

Leyendo sobre Internet Of Things (IoT), internet de las cosas, me viene a la memoria todo aquello que ya dijimos sobre el futuro hace no tanto. Como que en el año 2000 todos iríamos en coches voladores, usaríamos trajes brillantes, o similares.

Y la cuestión es si, ¿estamos esta vez en la misma tesitura con los 25 billones (americanos imagino) de dispositivos conectados en 2015 que Cisco prevé? . Ejem, y para 2020 Gartner prevé 26, mientras Cisco ya va por los 50 billones.

Si que parece que millón arriba, millón abajo, la idea cuaja y que cada vez una proporción mayor de los dispositivos están conectados a la red de redes, construyendo así una red de cosas, incluso algún avezado hacker ya añadió a su red de dispositivos (BotNet) un frigorífico para hacer algún tipo de ataque DDoS.

Leo en Forbes, y me gusta, acerca de distintas aplicaciones médicas para un internet de las cosas, una red en la que los elementos cotidianos que tenemos nos envían mensajes de distintos tipos.

  • Inyector de insulina que me avise cuando me toca la próxima inyección, o que lleve la cuenta de las que me he ido poniendo.
  • Monitores de bebés, tener una cosa en internet que me avise de que mi peque está teniendo dificultad para respirar, o que tiene fiebre me parece algo tan necesario, y sobre todo, que me avise a mi móvil en vez de a este dispositivo que nunca sé donde enchufar.
  • Gestor de pastillas, un gadget que se me antoja necesario para una población cada vez más necesitada de medicamentos, y cada vez más enganchada a internet. Aunque el invento en sí es una pastilla que ella sola informa de su ingestión, el hecho de que mi gestor de pastillas me avise que hace unas horas que no lo abro, cuando debería haber tomado mi dosis de antibiótico me parece muy útil también.

Y seguro que muchos más gadgets y aplicaciones para asistencia, pero sobretodo un eficaz sistema de Web APIs con el que poder controlar y gestionar los datos privados de estas herramientas tan personales, así como controlar los accesos a estos nuevos gadgets, y la información que proporcionan.

Otra de las cuestiones importantes, es de si es posible generar las APIs que deben ser consumidas por las aplicaciones finales, que normalmente se van a encontrar en la palma de la mano del usuario final [móvil, tablet, phablet, …], y que deben proveer el necesario control y gobierno, así como la protección frente a los ataques más rabiosos.

Disponer de una adecuada estrategia de gestión de APIs, con la necesaria seguridad, es posible y controlar las apps que están consumiendo las APIs expuestas, así como los procesos empresariales subyacentes, es hoy en día una realidad más allá de los sueños más futuristas que tuviéramos en los 80.

API Management y OpenData

Son tantos los entornos, los usos, que se han hecho de la célebre frase “ … connect the dots …” que me parece abusar. Es cierto que el contexto me parece perfecto en mi caso, en el que tuve una pequeña exposición a open-data, smartcities, hace algún tiempo y es ahora que mi interés está más cercano al API Management, que una chispa, un comentario en una reunión,  me acercó a conjuntar ambos elementos.

Es más, leo un post muy interesante de Mark Boyd (@mgboydcom), http://blog.programmableweb.com/2013/10/24/government-open-data-how-to-get-involved/,  en el que ciertamente termino por cerrar el círculo de la importancia de unir ambos conceptos.

{"topic":"OpenData"}

Para poder exponer aquellos datos que las diferentes agencias gubernamentales publican, de forma que podamos consumirlos desde cualquier página o app, es importante tener ciertos aspectos en cuenta:

  • Formato de la información: habitualmente csv, excel, html, pero también json, txt, kml, xml, georss, rdf, entre tantos otros.
  • Adquisición de la información: atendiendo a los criterios de actualización de las fuentes, unas serán cuasi automáticas y otras contienen datos históricos sin mucha frecuencia de actualización.
  • Uso de la información: quizá el aspecto más complejo, y sobre el que quería centrarme ya que esta información puede ser expuesta no solo en distintos formatos, sino también relacionada con otras informaciones, o enriquecida por los ciudadanos.

El uso de la información opendata, una vez queremos exponerla con nuestro propio “toque”, nos permite publicar apps y exponer servicios en los que podemos aportar valores añadidos:

  • Enriquecimiento de la información con otras APIs, o servicios, tanto públicos como privados que permitan no solo contextualizar la información en un área geográfica, sino relacionarla con otra información como la previsión del tiempo o la concentración de agentes microscópicos (polen, partículas, gases).
  • Información personalizada por usuario, o localización del usuario, de forma que acercar la información pública a la palma de la mano del ciudadano le reporte un beneficio tangible en el día a día.
  • Abrir la posibilidad a un usuario de enriquecer la información provista, es muy común el caso en entornos de smart-cities de la notificación de los ciudadanos sobre elementos del mobiliario estropeados o incluso información sobre el tráfico, atascos y obras la lista se me antoja infinita.

Ante lo que es también importante disponer de ciertas capacidades:

  • Mediación, disponer de las capacidades necesarias para poder expresar la información abierta u open-data, en cualquiera de los formatos en los que se encuentre, de forma que sea comprensible por los dispositivos donde vaya a ser consumida, principalmente JSON utilizando el paradigma REST.
  • La nube, ser capaz de acceder a la información pública en distintos formatos, mediante protocolos como http/s no es un hándicap hoy en día. Si es cierto que es necesario disponer de las capacidades de exponer servicios o web APIs sobre este open-data, en la nube con los requisitos de crecimiento elástico necesarios para crecer si se produce un efecto viral, o simplemente porque nuestro servicio es un servicio de éxito.
  • Gestión de identidad, donde no solamente es importante la gestión de la autenticación de usuarios sino la posibilidad de utilizar identidades federadas en terceros y autenticar utilizando protocolos y tecnologías como OpenID entre otras.
  • Frontal de seguridad, merece quizá una serie de capítulos completos en los que evaluar las distintas posibilidades de securización, control de amenazas, gestión de ataques (ddos, code inyection,…) .
  • Monitorización y control, los elementos que suelen darse por supuestos y que marcan la diferencia en un entorno productivo en el que es imprescindible tener claro cuáles de los servicios expuestos están siendo consumidos y cómo lo están siendo, emitiendo las alertas pertinentes en el caso de que alguno de los SLA definidos hayan sido sobrepasados.

En definitiva, las Web APIs permiten la aproximación del ciudadano a los datos abiertos, opendata, en los dispositivos que éste tiene en la palma de la mano.

Así mismo es posible un enfoque desde el punto de vista profesional del consumo de datos, protección de infraestructuras, mash-up de servicios y oferta de servicios tanto en formatos free APIs como freemium. Lo que indudablemente añadirá más competición a la explotación de datos, que no olvidemos son de todos porque todos los pagamos, y la obtención de valor de estos bienes comunes.