En los albores de la transformación digital, los encargados de la seguridad en las empresas empezaron a darse cuenta del reto que era proteger las APIs: muchas soluciones Open Source, muchos conceptos nuevos ahora en su cancha, un perímetro de red en el camino de la desaparición, una conversación casi nula con las áreas de aplicaciones. En fin, mucho que digerir.
El reto entonces se tradujo en una superficie de ataque extendida y tan distribuida como las aplicaciones de donde viene. Los ambientes donde hoy en día corren las APIs, tienen muchas variantes que hacen complicado y, de paso, innecesario englobar toda la seguridad en una única solución. Esto genera mucha inquietud en quien se encarga de protegerlas quienes deben considerar el estilo de arquitectura, el lugar y formato de ejecución, así como los roles y equipos de trabajo involucrados.
ESTILO DE ARQUITECTURA
Los tipos de datos que se buscan extraer, el orígen del llamado: ¿es un móvil con buenas capacidades de cómputo o es un sensor? ¿De qué fuentes y en qué formatos se busca mover la información? ¿Son factores determinantes sobre el estilo de Arquitectura a utilizar?
Sea REST API, GraphQL, gRPC, cada una de estas opciones representa una decisión del lado de Desarrollo, que ahora el team de Seguridad debe entender y asegurar. No se debe asumir que con las soluciones ya existentes se cubren las nuevas amenazas. Por ejemplo, una consulta recursiva con fines de abuso sobre GraphQL, no es identificada con éxito por un WAF tradicional, aunque conozca muy bien el protocolo HTTP, sino por aquel que entiende la semántica propia de este estilo de arquitectura.
Por otro lado, si las APIs son para intercambio de datos entre microservicios, por lo tanto, ¿con qué soluciones protegemos estas interacciones? y ¿de quién es la responsabilidad? Hoy en día los microservicios corren en ambientes como kubernetes y la comunicación entre containers también puede representar peligro.
Solo con estos cuestionamientos ya se pueden dar una idea de lo que representó a sus expertos de seguridad proteger esa nueva app que lanzaron durante la pandemia, o aquel e-commerce que estaba en el tintero.
LUGAR Y FORMATO DE EJECUCIÓN
Datos de la Cloud Native Computing Foundation (CNCF) nos confirman que la adopción de kubernetes para correr cargas productivas ha ido en incremento en los últimos años, teniendo Latinoamérica una buena adopción del 50 por ciento.
Las APIs están en todos lados. Al momento de leer este artículo calculamos hay más de 200 millones de APIs publicadas. Para 2030 la cifra estará cerca del billón.
Containers en la nube, containers on-prem, containers al final. La seguridad de las APIs en estos ambientes suele estar regida por logos que vienen del mundo open-source —abrazado por nuestros amigos de desarrollo— que dan buena funcionalidad, pero en temas de soporte no sostienen la criticidad de lo que deja dinero a su negocio.
Es muy común encontrar excelentes soluciones de seguridad, que para proteger APIs en estos ambientes contenerizados solo pueden hacerlo en formato SaaS o más cercano al API, como máquina virtual: hablamos de WAF/WAAP. ¿Será suficiente proteger solo el tráfico norte-sur? ¿Qué pasa con el tráfico este-oeste?
Normalmente los creadores de la aplicación refuerzan este último intercambio con una capa de autenticación y autorización muy integrada, entiéndase en el mismo container. ¿Qué tanto el team de seguridad participa en este esquema? ¿Decidirá el algoritmo a usar por los tokens o la versión del protocolo TLS?
A veces las preguntas dicen más que las respuestas.
ROLES Y EQUIPOS DE TRABAJO INVOLUCRADOS
Hace unos 14 años miraba en la presentación de producto de cierto vendedor una diapositiva con un ring de box muy peculiar: de un lado estaba una figura representando al púgil del Network Team, del otro al del Development team. El argumento era que siempre ambos equipos, al darse una falla, se echaban culpa sin mayor remordimiento.
Ahora que los proyectos que estaban en hold antes de la pandemia, salieron a la luz a marchas forzadas, estas diferencias entre los equipos de seguridad y desarrollo se hicieron más visibles. Se descubrió, por ejemplo, que muchas veces en los pipelines de aplicación hay WAFs corriendo —open source— que ni siquiera pasan por la decisión del team de seguridad. En muchas otras ni se enteran qué existe un WAF ahí. Claramente esta oscuridad reduce la eficacia de la estrategia de seguridad y al contrario de lo que se buscó al inicio, puede aumentar la superficie de ataque de la aplicación.
Actualmente, las soluciones de seguridad de APIs deben empujar la colaboración, ya que la seguridad es un ejercicio donde todos participamos.
Así las cosas, las APIs han representado una serie de retos para las empresas y su team de seguridad, que necesitan ser tomados en cuenta y tener un seguimiento puntual. Recuerde que las APIs son el gateway hacia sus datos, o los de sus clientes.
POR DÓNDE EMPEZAR
Para que no se vaya solo con preguntas en la cabeza le dejo algunos tips de por dónde empezar. Hoy en día hay referencias como el
OWASP API Security Project que le pueden ayudar a fincar las bases de su estrategia de Seguridad de APIs. Al revisarlo notará que un WAF/WAAP no es suficiente para proteger las APIs aunque sí nos ayuda con al menos dos vectores de 10. No olvide que la parte de autenticación y autorización es una parte medular en el aseguramiento de las APIs, así como lo es su buena documentación y administración.
Insisto, las APIs están en todos lados. Al momento de leer este artículo, calculamos hay más de 200 millones de APIs publicadas. Para 2030 la cifra estará cerca del billón. Si su compañía aún no entra en esta arena, eventualmente lo hará. Y si ya se encuentra ahí ¿cómo va con su seguridad de sus APIs?
