Con el ritmo acelerado de la transformación digital tras los albores de la pandemia de COVID-19, muchas organizaciones y directivos se están haciendo esta pregunta: «¿Debemos lanzar una API pública?».
Imagina la reacción de tus interesados cuando se enteren de que tus socios y competidores ya están utilizando tus APIs para potenciar sus ofertas sin ningún mecanismo para cobrar o incluso hacer un seguimiento de este uso.
Lo que muchas empresas no se dan cuenta es que ya tienen una API pública que está siendo utilizado por posibles socios e incluso competidores porque los patrones actuales de desarrollo de aplicaciones en los grupos de TI se basan en las API públicas para impulsar sus aplicaciones web y móviles. Si tienes una aplicación móvil orientada al consumidor, tienes una API. Si tienes un sitio web, tienes una API. Puede que no se rastree ni se consuma fácilmente, pero eso no significa que no esté ahí fuera y se utilice, porque cuando se trata de desarrolladores, donde hay voluntad, hay un camino. En lugar de esperar las consecuencias del uso de la API sin control, es hora de salir de la negación de la API pública y crear un canal intencional.
Aunque cada empresa tiene un contexto de negocio diferente y una visión única de cómo generar valor para el cliente y la empresa, una cosa es igual en todos los casos: ya tienen una API pública de la que no eran conscientes y que se puede consumir de forma no rastreada.
El canal no tan invisible
¿Cómo es posible que las grandes empresas tengan una API pública que no conocen? Resulta que hay una puerta trasera no tan invisible incrustada en los sitios web públicos y en las aplicaciones móviles. Esta puerta trasera no sólo está ahí para cualquier desarrollador lo suficientemente motivado como para buscarla, sino que es una práctica ampliamente aceptada y respaldada por los profesionales de la tecnología y las empresas en este momento. El problema no es que las empresas utilicen las API para impulsar sus aplicaciones web y móviles. Ni siquiera se trata de que las direcciones URL sean fácilmente accesibles para terceros. El problema es que un amplio abanico de líderes empresariales y tecnológicos no han conectado lo suficiente como para entender que han convertido sus APIs en una infraestructura disponible públicamente que puede ser utilizada por cualquiera de forma gratuita.
La aparición del programa de API públicas de bajo perfil comenzó hace 20 años, cuando AJAX (JavaScript asíncrono y XML) estuvo disponible por primera vez y dio el pistoletazo de salida a lo que entonces se conocía como «web 2.0». Las tecnologías se han ido perfeccionando y cambiando de nombre, pero los fundamentos del patrón se han convertido en el estándar de facto para crear aplicaciones web con gran capacidad de respuesta y se han aplicado para convertirse también en la base de las comunicaciones de las aplicaciones móviles.
Ya sea una página web, una aplicación móvil o una página web encapsulada dentro de una aplicación móvil nativa, los detalles de los puntos finales de la API y las credenciales del cliente suelen estar disponibles en pocos minutos para un desarrollador medianamente motivado. Por una serie de razones, las técnicas avanzadas de ofuscación y los programas estratégicos de defensa contra el scraper rara vez superan la línea de trabajo de los equipos para llevar sus ofertas al mercado. El resultado final es que muchas organizaciones tienen una oferta de APIs en la sombra que esencialmente no está gestionada ni supervisada. Si te preguntas si esto se aplica a ti y cómo, aquí tienes un sencillo diagrama de flujo que te ayudará a orientarte:
Incluso tu mejor amigo necesita buenos límites
Una vez que una organización comienza a desarrollar experiencias móviles ricas en datos o un programa omnicanal que ofrece experiencias coherentes en todos los puntos de contacto con el público, surge la necesidad de una estrategia de API compuesta. Las empresas de todo el mundo están descubriendo esta necesidad a medida que el impulso de la transformación digital se hace más frecuente en todos los contextos industriales. Ya sea de forma intencionada o por casualidad, el deseo de conservar los ciclos de desarrollo y operaciones ha impulsado el patrón arquitectónico Back-end for Front-end (BFF), popularizado por Sam Newman y Phil Calçado, para convertirse en la norma en un conjunto cada vez más amplio de empresas y startups.
Si bien los BFF (y las API que los impulsan) se han convertido en un patrón popular entre las organizaciones de desarrollo, la presencia de los BFF no siempre viene acompañada de un enfoque para gestionar la inevitable fuga de datos que se produce en las experiencias digitales. El raspado sistemático del contenido de Parler de principios de 2021 ha demostrado lo mal que puede ir cuando tus capacidades de gestión de API no están a la altura del desafío de proteger razonablemente los datos que mantienen a tu organización competitiva en el mercado. Debido a un enfoque poco cuidadoso de la seguridad de los datos, el 100% de todos los datos de los usuarios y las publicaciones, incluidas las eliminadas, se han extraído, descargado y compartido con las fuerzas de seguridad estadounidenses.
Esta vulnerabilidad no es nueva para todos. Muchos medios de comunicación tienen estrategias de defensa contra el rastreador que no descartan a los BFF. Un patrón frecuente es hacer que las páginas accedan a los datos a través de llamadas al servidor en lugar de llamadas al cliente, lo que permite a las empresas establecer «listas de permitidos» al tiempo que abren portales de API gobernados. Una distinción importante en esta estrategia es que nadie detiene con éxito a los raspadores. La jugada más inteligente y manejable es canalizarlos, supervisarlos y gobernarlos a través de una oferta de monetización de datos estructurada.
Los lujos de ayer son las necesidades de hoy
Con demasiada frecuencia, los equipos de tecnología adoptan las narrativas de los equipos empresariales que no tienen en cuenta las realidades del mundo moderno. Los equipos empresariales reclaman el dominio del «qué» y presumen de tener el mejor juicio sobre qué capacidades son necesarias y cuáles son «agradables de tener». Este modelo de toma de decisiones que hace hincapié en las ganancias a corto plazo a expensas de las preocupaciones a largo plazo está más desequilibrado que en tiempos pasados porque:
- La velocidad del reloj de la tecnología y los negocios se ha acelerado y sigue acelerándose, lo que significa que «las preocupaciones a largo plazo se manifiestan en ciclos de tiempo del calendario cada vez más cortos.»
- La tendencia de los «elementos de fase 2 que nunca llegan a serlo» es el statu quo cotidiano en muchas empresas de todo el mundo.
Teniendo en cuenta este nuevo contexto, algunas capacidades que antes se consideraban lujos, deberían elevarse al ámbito de la necesidad. Para ser claros, esto no significa que todas las necesidades sean dignas de MVP o V1. Más aún, esto significa que las medidas de seguridad de los datos para mitigar el riesgo de la minería de las APIs (por ejemplo, la gestión de las APIs, la limitación de la tasa, la habilitación de políticas de seguridad por diseño, la supervisión del tráfico específico de las APIs, las prácticas de seguridad de «defensa en profundidad» integradas en la red y/o la infraestructura, etc.) deben pasar a la zona de «alcance inaplazable», donde es necesario articular compromisos firmes de hoja de ruta y «tener dientes» suficientes para mantener a raya a las fuerzas de «los ingresos por encima de todo».
En el contexto de la priorización de las capacidades empresariales, puede ser difícil tener la persistencia necesaria para cambiar la postura de los equipos distribuidos sobre el equilibrio entre las capacidades arquitectónicas y la generación de ingresos. Al mismo tiempo, la necesidad de elevar el tema de la seguridad de los datos se hace más evidente cada día a medida que las brechas de datos se hacen más frecuentes. Incluso en el contexto de las API «internas», los pequeños errores y pasos en falso pueden hacer que su empresa sea vulnerable a la filtración de datos valiosos o sensibles. Si bien es cierto que ninguna persona puede resolver este problema para una empresa, también es cierto que esto no nos exime de la responsabilidad de hacer lo que podamos, desde nuestro lugar en la empresa. Tanto si diriges un equipo, una plataforma o incluso los productos que consumen y distribuyen los datos, tienes un papel que desempeñar.
Si trabajas en una empresa que cree que «no tenemos APIs de cara al público», haz estas tres cosas:
- Piénsalo de nuevo y valida exactamente cómo las APIs potencian las experiencias de tus clientes.
- Ponte en contacto con el equipo de MuleSoft en Disid para saber cómo tu organización puede aprovechar el despliegue más amplio y profundo de la infraestructura de API «segura por diseño» en la mayor base de clientes del mundo.
- Comienza a desarrollar el apetito empresarial para inventariar, controlar y gobernar tus activos de datos accesibles mediante API. Porque en este caso, lo que no sabes puede perjudicarte.
Esto es una adaptación al castellano del interesante post publicado por Mulesoft en su blog en inglés: «Securing the public APIs you didn’t know you had«
