El contexto es el rey

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Objetos de consumo. Objetos empresariales. Objetos industriales.

Teléfonos. Tabletas. Fáblets. Portátiles. Ordenadores de sobremesa.

Uso intensivo de computación. Uso intensivo de red. Uso intensivo de almacenamiento.

Casa. Trabajo. Restaurante. Coche. Parque. Hotel.

El panorama está cambiando en ambos lados del negocio: las aplicaciones y los clientes. El término «usuario» ya no se refiere únicamente a una persona. También incluye sistemas y dispositivos que se conectan, comparten e interactúan automáticamente con aplicaciones en todo el centro de datos.

Pensemos, por ejemplo, en la tendencia emergente de la arquitectura de microservicios, que descompone las aplicaciones monolíticas en sus distintas partes. Cada parte constituye un servicio independiente y ofrece una API (interfaz) a través de la cual pueden comunicarse otras partes (servicios) y los «usuarios».

¿No formas parte del 36 % que está experimentando con los microservicios? (Typesafe, 2015) Seguir utilizando arquitecturas de aplicaciones bien conocidas no te protegerá del impacto de la creciente diversidad de «usuarios», especialmente si te estás adentrando en el Internet de las cosas. Nuestros datos indican que algunos de vosotros sí lo estáis haciendo: el 22 % de todos los encuestados cree que tendrá una importancia estratégica durante los próximos 2-5 años, y el 15 % ya se está adelantando con planes para adquirir tecnología compatible con el IoT en los próximos 12 meses.

Eso significa que los «objetos» deberán considerarse como «usuarios», con su propio conjunto específico de necesidades y requisitos en materia de seguridad y rendimiento, por no hablar de la disponibilidad.

Esto significa que los servicios de red y de aplicaciones encargados de ofrecer un conjunto cada vez más diverso de aplicaciones a un número creciente de clientes en aún más ubicaciones deben ser capaces de distinguir entre un usuario humano y un objeto conectado. Para optimizar el rendimiento y garantizar la seguridad, es imprescindible que los servicios responsables del rendimiento y la seguridad puedan aplicar la política adecuada en el momento oportuno, teniendo en cuenta el conjunto de variables existentes en ese preciso instante.

Eso significa que deben gestionar el tráfico (los datos y las comunicaciones, en términos de aplicaciones) teniendo en cuenta el contexto de toda la transacción: el usuario, la aplicación y la finalidad de la comunicación que se intenta establecer.

Puedes entender el contexto de forma muy similar a como quizá te enseñaron (si tienes edad suficiente; y no, no tienes por qué admitirlo si prefieres no hacerlo) las cinco preguntas que debes plantearte al recopilar información básica: quién, qué, dónde, cuándo y por qué. Al analizar el tráfico y obtener una respuesta a cada una de estas preguntas, puedes reunir suficiente contexto para tomar una decisión adecuada sobre cómo gestionar el intercambio. Denegarlo. Permitirlo. Analizarlo. Depurarlo. Optimizarlo. Encaminarlo. Estas son algunas de las tareas que realizan los servicios de aplicaciones «en la red», y las llevan a cabo mejor y con mayor eficacia cuando lo hacen dentro del contexto del intercambio.

• Quién
  Identifica al usuario. ¿Es una persona? En caso afirmativo, ¿es un usuario corporativo o un consumidor? ¿Es un dispositivo u otra aplicación? En ese caso, ¿qué dispositivo y qué aplicación? Aunque mi bombilla inteligente pueda tener acceso a una aplicación de generación de informes de datos, no tiene acceso a los sistemas de contabilidad.
• Qué
  ¿Qué están haciendo? ¿Enviando datos? ¿Solicitando datos? ¿Buscando? HTTP contiene una gran cantidad de información que puede ayudar a determinarlo sin necesidad de profundizar demasiado. ¿Es una solicitud HTTP POST o GET? ¿Una operación UPDATE o DELETE? El estado por sí solo puede darnos pistas sobre la finalidad de este intercambio.
• Dónde
  ¿Desde dónde lo hacen? ¿Están en casa? ¿En la sede central? ¿En el Starbucks de enfrente o al otro lado del mundo? ¿En una red local o a través de Internet? La geolocalización es un medio habitual para restringir el acceso a aplicaciones, recursos y datos. Al proporcionar aplicaciones a los usuarios, independientemente de su tipo, la ubicación es importante, sobre todo si existen políticas corporativas que prohíben acceder a determinados tipos de datos o aplicaciones desde lugares públicos, como el aeropuerto o el Starbucks de la zona.
• Cuándo
  ¿Qué hora es? Y, lo que es más importante, ¿qué hora es tanto aquí como en el lugar donde se encuentra el usuario? ¿Está intentando acceder a un sistema a las 3:00 desde un lugar donde son las 8:00? Por ejemplo, sabemos por diversos estudios que se ha observado un aumento significativo del tráfico de bots fuera del horario laboral, entre las 18:00 y las 21:00. Podríamos combinar estos datos con el «quién» y determinar al instante si Alice debería estar trabajando a las 3:00 cuando se encuentra en la sede central de la empresa.
• Por qué
  El «por qué» es como la inexistente capa 8. Solo puede deducirse a partir del «qué», y para ello hay que ser capaz de relacionar pistas obtenidas de datos que, por lo demás, son bastante básicos, como el URI (suponiendo que se base en HTTP, algo bastante razonable hoy en día). Una vez que sabemos qué están haciendo, como enviar datos, quizá queramos saber por qué los envían. ¿Se trata de una actualización del perfil o están enviando datos de sensores? ¿Están realizando una búsqueda o enviando un pedido?

Estos son los elementos que conforman el contexto. No es imprescindible recopilar los cinco (al fin y al cabo, esto no es Pokémon) para poder decidir cuál es la forma adecuada de proceder. Sin embargo, sí es necesario tener visibilidad (acceso) de los cinco, por si hiciera falta. Por eso, la visibilidad de toda la pila de red —desde las capas 2 a 7— es tan importante para los servicios de aplicaciones. Porque cada uno de ellos puede necesitar evaluar una solicitud o respuesta dentro del contexto en el que se produjo, y solo la visibilidad de toda la pila garantiza que se pueda acceder a esa información y obtenerla cuando sea necesario.

Esa es una de las ventajas que aporta un proxy inteligente: la visibilidad necesaria para garantizar que los arquitectos (e ingenieros) de redes, seguridad e infraestructuras puedan implementar políticas que requieran contexto para asegurar la seguridad, la velocidad y la fiabilidad que, en última instancia, necesita todo usuario, ya sea una persona, un sensor o un software.

Sobre el autor

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

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 Vittie