El caso de las estrategias de seguridad integradas para aplicaciones y API
Es evidente que la seguridad de las aplicaciones y de las API es cada vez más especializada. Las API ya no son meros puntos de entrada a una aplicación basados en URI, sino que han crecido y se han convertido en una entidad independiente con sus propias necesidades de seguridad.
La mayor parte de estas necesidades están relacionadas con la naturaleza de las interacciones de las API. En concreto, las API deben autorizarse por transacción, lo que difiere notablemente de las aplicaciones, que suelen aplicar la autorización por sesión.
La tasa de interacción también es mayor en el caso de las API, al igual que otras características que plantean desafíos especiales a la hora de protegerlas.
| Aplicación | API | |
|---|---|---|
| Fluidez del formato de los mensajes | HTML, JSON, XML | ProtoBuf, JSON, GraphQL, binario, XML, formatos de datos |
| Interacciones | Estáticas, cambios poco frecuentes | Dinámicas, cambios frecuentes |
| Datos | Estructurados, transaccionales | No estructurados, streaming y transaccionales |
| Usuario | Humano | Software, humano |
| Agente de usuario | Navegadores, aplicaciones | Software, dispositivos, scripts, aplicaciones, navegadores |
| Autenticación | Basada en sesiones | Basada en transacciones (más parecido a ZT) |
| Fluidez del protocolo | HTTP/S, QUIC | gRPC, WebSockets, HTTP/S, QUIC |
Una comparación entre las aplicaciones y las API ilustra las diferencias que han provocado la divergencia en las necesidades de seguridad.
Dicho esto, hay riesgos de seguridad comunes tanto a las aplicaciones como a las API que deben tenerse en cuenta a la hora de implantar soluciones de seguridad. Por ejemplo, en la clasificación API Security Top 10 de 2023, actualizada recientemente, se muestra de forma clara un subconjunto de riesgos que se comparten con las aplicaciones:
- Controles de autorización o autenticación débiles
- Configuración errónea
- Abuso de la lógica de negocio (credential stuffing, apropiación de cuentas)
- Server-Side Request Forgery (SSRF)
Además de estos riesgos, sigue habiendo un número considerable de ataques dirigidos a la disponibilidad. Se trata de ataques DDoS que son comunes tanto a las aplicaciones como a las API, ya que normalmente comparten las mismas dependencias en TCP y HTTP, ambos sujetos a una variedad de ataques diseñados para interrumpir el acceso y la disponibilidad.
Una forma de abordar los desafíos que plantea la protección de las aplicaciones, las API y la infraestructura que las respalda consiste en desplegar múltiples soluciones: defensa contra bots y fraudes, protección contra DDoS, seguridad de las aplicaciones y de las API. Si bien es cierto que así se afrontan los desafíos de seguridad, al mismo tiempo se introducen dificultades operativas y se complican muchas de las tareas relacionadas con la seguridad, como la gestión de cambios en las políticas y la reacción ante amenazas que afectan tanto a las aplicaciones como a las API. La complejidad no es solo enemiga de la seguridad, sino también de la velocidad.
La rapidez de reacción ante las amenazas emergentes es uno de los principales impulsores para adoptar la seguridad como servicio, según nuestra investigación anual. Cada una de las soluciones que requiere un parche, una actualización o la implementación de una nueva política para mitigar una amenaza emergente suma tiempo y aumenta la posibilidad de configuraciones incorrectas o errores. Por tanto, el tiempo necesario para mitigar una amenaza aumenta con la complejidad, especialmente si una organización opera en varios entornos (TI híbrida) y utiliza soluciones de seguridad por entorno. No vamos a entrar en si se trata de un aumento lineal o exponencial, porque lo cierto es que cualquier cosa que aumente el tiempo de respuesta ante una amenaza inminente es algo negativo.
Por esta razón, el mejor enfoque es el de combinar soluciones y compartir así la gestión operativa y de seguridad de las funciones diseñadas para combatir las amenazas y, al mismo tiempo, permitir que haya políticas de seguridad específicas para abordar los protocolos y las cargas útiles exclusivas de las aplicaciones y las API.
Esto conduce a una estrategia de seguridad integrada para aplicaciones y API, en la que las funciones comunes se comparten con una granularidad y especificidad crecientes aplicadas más cerca de la aplicación o API. Después de todo, los bots son bots y su impacto en la calidad de los datos, el coste de la entrega y el perfil de riesgo para las aplicaciones y las API son una preocupación compartida. DDoS es DDoS. Operar el doble de servicios para abordar el mismo problema es una medida ineficaz desde todas las perspectivas.
Una estrategia de seguridad integrada para aplicaciones y API tiene mucho más sentido desde el punto de vista operativo, financiero y arquitectónico.