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, existen riesgos de seguridad comunes tanto a las aplicaciones como a las API que deben tenerse en cuenta al implementar soluciones de seguridad. Por ejemplo, el Top 10 de seguridad de API de 2023 , actualizado recientemente, muestra claramente un subconjunto de riesgos que se comparten con las aplicações:
- 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 velocidad con la que uno puede reaccionar a las amenazas emergentes es un factor importante para la adopción de la seguridad como servicio según nuestra investigación anual . Cada solución que requiere un parche, una actualización o la implementación de una nueva política para mitigar una amenaza emergente agrega tiempo y aumenta la posibilidad de una mala configuración o un error. Por lo tanto, el tiempo para mitigar una amenaza aumenta con la complejidad, especialmente si una organización opera en múltiples entornos (TI híbrida) y aprovecha soluciones de seguridad para cada entorno. No estoy haciendo los cálculos para determinar si se trata de un aumento lineal o exponencial porque, honestamente, cualquier cosa que aumente el tiempo para responder a una amenaza inminente no es algo bueno.
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.