Una de las cosas interesantes —y más frustrantes— que he observado a lo largo de los años es la diferencia entre cómo ven las aplicaciones los ingenieros de redes y los desarrolladores de aplicaciones. Esto se refleja en la forma en que se representan las aplicaciones en los diagramas de red y, a la inversa, en cómo se muestran las redes en los diagramas de arquitectura de aplicaciones.
Ni que decir tiene que cada uno tiene una visión muy simplista del otro.
Lo mismo ocurre con la seguridad, cuyo papel a la hora de proteger no solo las redes y las aplicaciones, sino el propio negocio, ha adquirido una importancia primordial. Es importante que los equipos de seguridad vayan más allá de los recuadros de los diagramas de arquitectura habituales para comprender realmente las aplicaciones. Un porcentaje significativo de los ataques que tienen éxito se ejecuta en la capa de aplicación. Cuanto más tardemos en reconocer las características específicas de los distintos tipos de aplicaciones, más tiempo permanecerán vulnerables.
El debate de hoy se centrará en las SPA. Para quienes se pregunten qué significa esta sigla en concreto, corresponde a «aplicaciones de página única».
Introducción a las aplicaciones de página única (SPA)
Una aplicación de página única es precisamente eso: una única página web que sirve de marco para todas las tareas relacionadas con la aplicación. Esta arquitectura se remonta a la época de la Web 2.0 y a la aparición de AJAX como método para «actualizar» elementos individuales del DOM (modelo de objetos del documento) en lugar de recargar toda la página. Esta técnica mejoró considerablemente el rendimiento y fue la precursora de las aplicaciones modernas de página única.
Estas aplicaciones se asemejan más al funcionamiento de una aplicación móvil, en la que la interfaz de usuario del cliente se carga al abrirla por primera vez y la comunicación con el servidor se limita únicamente a los datos. Esto significa que cada llamada al servidor solo contiene datos y que cualquier cambio en la interfaz de usuario se realiza en el cliente. De este modo, se reduce drásticamente la cantidad de datos que se envían y reciben y, como cabe imaginar, se mejora el rendimiento. Este tipo de aplicaciones utiliza API para intercambiar datos.
Por lo general, hemos partido de la premisa de que la mayoría de esas API se implementan siguiendo los principios REST. Esto significa que cada objeto (que normalmente se considera vinculado a un único elemento de la interfaz de usuario) tiene su propia API, que se puede invocar para ejecutar operaciones CRUD (crear, leer, actualizar y eliminar). Desde el punto de vista de la seguridad, esto facilita un poco las cosas, ya que se pueden esperar datos en formatos específicos para una determinada llamada a la API (URI). Los datos enviados a "/update/product/123" corresponderán siempre al mismo objeto serializado, mientras que los enviados a "/delete/order/4433" corresponderán a otro objeto serializado distinto. Esto permite proteger esa API mediante prácticas tradicionales que asocian políticas específicas a URI concretos.
El patrón de URI única
Ahora bien, las SPA pueden seguir este patrón o no. Las prácticas emergentes en torno a las SPA pueden utilizar, y de hecho utilizan, la misma API para realizar transacciones, así como una asignación más tradicional de funciones a URI. En una SPA con un patrón de URI única, la URI no cambia, pero sí lo hacen los objetos serializados que se intercambian entre el servidor y el cliente.
Esto recuerda a las transacciones SOA/XML, en las que se utilizaba un único punto de conexión (URI) para invocar varias funciones. La función (punto de conexión) de destino se incluía en los datos XML serializados o, en ocasiones, se insertaba en una cabecera HTTP personalizada. Este modelo hizo necesarios los gateways SOA/XML, que se encargaban de recibir la solicitud y determinar qué función se estaba invocando antes de dirigirla al punto de conexión (servidor) adecuado.
Con las SPA, puede que tengas que gestionar muchas llamadas a la API o solo unas pocas. En cualquier caso, probablemente tendrás que proteger los datos en algún formato (quizá XML, aunque lo más probable es que sea JSON). Esto significa que debes ser consciente de que el contenido conlleva riesgos. Dado que algunos datos pueden utilizarse para generar dinámicamente elementos de la interfaz de usuario (o manipular de algún otro modo el DOM en el cliente), es importante detectar y eliminar cualquier código potencialmente malicioso en cada envío.
La desconexión en materia de seguridad
Por desgracia, si se utiliza un único URI para intercambiar datos destinados a distintas funciones, la práctica tradicional de asociar políticas a los URI no va a funcionar. De hecho, esto puede comprometer la seguridad, ya que dichas políticas suelen estar configuradas para esperar formatos de carga útil específicos. Las puertas de enlace de API también suelen vincular las políticas (enrutamiento, medición y acceso) a un URI concreto. Esto significa que la práctica de utilizar solo unos pocos URI (llamadas a la API) para gestionar muchas más funciones con distintos formatos de datos puede comprometer la seguridad existente.
Este es un ejemplo de por qué cada vez es más importante que los equipos de seguridad y desarrollo (no DevOps, sino los desarrolladores) colaboren más estrechamente desde la primera línea de código hasta el despliegue. Hay medidas que los desarrolladores pueden adoptar desde el principio para facilitar que el equipo de seguridad implemente las protecciones adecuadas, como insertar una cabecera HTTP con un indicador que permita aplicar la política correcta. Algo tan sencillo como "X-Code: 'order'" enriquecería las solicitudes de forma que las soluciones de seguridad pudieran identificar los datos y, posteriormente, analizarlos en busca de posibles vulnerabilidades.
Desde el punto de vista arquitectónico, esto puede requerir un proxy L7 inteligente capaz de extraer el código y reescribir el URI antes de dirigir la solicitud a la solución de seguridad adecuada (WAF, puerta de enlace de API, etc.). Este enfoque también funciona si el proxy L7 inteligente puede interpretar el lenguaje del formato de datos, como JSON, y los desarrolladores incluyen en cada intercambio algún código o nombre de endpoint que pueda utilizarse para reescribir la solicitud y dirigirla al destino correcto.
Lo ideal sería integrar la seguridad de la capa de aplicación en la propia aplicación para lograr el mejor equilibrio entre rendimiento y seguridad. Sin embargo, esto no siempre es posible y, en ocasiones, se requieren soluciones arquitectónicas creativas para alcanzar el objetivo de seguridad.
La seguridad es un trabajo en equipo
En términos generales, los cambios en la forma en que los desarrolladores distribuyen las distintas responsabilidades entre el cliente y el servidor tienen un impacto significativo en cómo interactúa la infraestructura de servicios de aplicaciones con las solicitudes y respuestas posteriores. Es importante que los equipos de seguridad, desarrollo e infraestructura de servicios de aplicaciones participen durante todo el ciclo de vida del desarrollo de software (SDLC). Además, implementar una solución arquitectónica lleva tiempo. Si se deja «para el final», se añaden días, semanas o incluso meses al plazo de comercialización. De lo contrario, el producto se lanza al mercado sin servicios de seguridad, lo que conlleva sus propios riesgos (y consecuencias).
La colaboración desde el primer día de desarrollo es la mejor —y más rápida— forma de garantizar que las aplicaciones estén disponibles, sean rápidas y seguras cuando pasen a producción.
Sobre el autor
Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.
Más artículos de Lori Mac VittieArtículos relacionados del blog
Cree servicios públicos seguros, resilientes y preparados para la IA con F5 y AWS
Descubre cómo las organizaciones del sector público pueden modernizar de forma segura sus aplicaciones y soluciones de IA, al tiempo que gestionan los sistemas heredados, el cumplimiento normativo y el riesgo operativo.
Protección de los sistemas de IA: por qué la seguridad debe avanzar al ritmo de la innovación
Desde acelerar avances revolucionarios en medicina y educación hasta transformar la vida cotidiana, la IA está cambiando nuestra forma de vivir y trabajar. Pero también ofrece grandes oportunidades a los ciberdelincuentes.
Avanzar hacia la optimización digital tras la transformación
Descubre estrategias de optimización digital para garantizar políticas de seguridad coherentes, impulsar la madurez de la transformación digital y superar los retos de la transformación.
Proyecto de código abierto destacado: mayor observabilidad con F5 Cloud Logger iApp
En el punto de mira del código abierto: cómo aumentar la observabilidad. Lee el blog de F5 para descubrir cómo exportar fácilmente la telemetría de BIG-IP a plataformas modernas de análisis en la nube.
El estado de la entrega de aplicaciones en 2018: la transformación digital impulsa la automatización y la multinube pese a las preocupaciones de seguridad
Descubre las principales conclusiones del cuarto informe anual de F5 sobre el estado de la entrega de aplicaciones.
Estado de la entrega de aplicaciones en 2017: automatización, API y DevOps
Descubre el informe sobre el estado de la entrega de aplicaciones de 2017. Lee el blog retrospectivo de F5 sobre los inicios del auge de las redes declarativas y los flujos de DevOps.