¿Cómo de privada debe ser mi API?

Tal y como entiendo, los datos públicos (opendata) deberían ser expuestos mediante APIs públicas de forma que estén disponibles para los ciudadanos, y todo aquel que quiera utilizarlos.

En el caso de las empresas, dependerá de su modelo de negocio, de hecho exponer servicios con acceso directo a los objetos de negocio debería hacerse en distintos niveles, que tal y como yo veo podrían ser los siguientes:

  • Por ejemplo, en un cierto nivel sólo aquella información que quiera suministrarse de forma pública, API pública, estaría disponible para la comunidad global de forma que pueda se expanda el conocimiento de productos y servicios de la compañía, u otras informaciones que la compañía deba exponer por algún marco regulatorio. Este API sería de acceso público con libre acceso y registro a la comunidad, o con acceso restringido a una gran comunidad de clientes.
  • Avanzando en cuanto a privacidad, habrá otros modelos del datos de la compañía que estarán restringidos para intercambio con otras empresas (lo que se denomina business to business – b2b ). De esta forma las aplicaciones de terceros que consuman las APIs privadas formarán parte de una o más comunidades privadas a las que deberíamos ofrecer distintas APIs dependiendo del escenario, por ejemplo intercambio de información de pagos y cobros, de pedidos y facturas, movimientos de almacén, etc. Estas son las comúnmente llamadas APIs privadas.
  • Y en el último nivel de restricción, habrá APIs de uso interno, lo cual no quiere decir que sean APIs que se puedan consumir internamente a discreción, si no que su existencia implica también un gobierno sobre su ciclo de vida, notificación a los consumidores de nuevas versiones o cambios, y control del consumo del API y de las condiciones del servicio por parte de los distintos consumidores. Estos consumidores internos pueden perfectamente ser otros sistemas, lo que tradicionalmente se llama integración application to application – A2A. Yo llamo a estas APIs internas, aunque muchas veces son APIs propietarias de los componentes software que la compañía utilice, SCM, CRP, CRM, HR, ERP.

Esta gestión de los diferentes niveles de privacidad de la información, y por tanto de las diferentes APIs que se utilizan, implica todo un proceso de gobierno del ciclo de vida de las distintas APIs, control de los cambios, y adicionalmente la gestión de la Autenticación de los consumidores, el control de la Autorización de uso del recurso que se pretende acceder y por su puesto la Auditoría de las operaciones realizadas lo cual no es muy diferente de los requisitos que pedimos a un API pública.

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.