Internet de las Cosas (IoT)

Es el análisis de grandes cantidades de datos de manera inteligente a través de modelos de descripción, predicción y optimización con el objetivo de obtener información para mejorar la toma decisiones. Los procedimientos utilizados para encontrar patrones repetitivos debido a su complejidad requieren software especializado.

Es el término que se usa para definir la visión de un entorno físico del mundo real, a través de un dispositivo tecnológico. (gafas especiales, teléfonos inteligentes...) para obtener una mejor percepción de dicho objeto.

Es la información (normalmente audiovisual) generada por ordenador que simula un entorno de apariencia real. Dicho entorno es contemplado por el usuario a través de un dispositivo (gafas, casco de realidad virtual...) pudiendo ir acompañado de otros que permiten una mayor interacción, intensificando la sensación de realidad.

Es una denominación para la manufactura avanzada. Una nueva manera de organizar los medios de producción. El nombre pretende describir una cuarta* revolución industrial basada en la integración de sistemas ciber-físicos en la manufactura y la logística y en el uso intensivo de las TICs en los procesos industriales.
(*) La primera revolución se basó en la energía de vapor, la segunda en la energía eléctrica, la tercera está ligada a las Tecnologías de la Información y Comunicaciones (TICs), siendo la cuarta la que enfatiza y acentúa la innovación digital en la industria.

Es el el acrónimo inglés de Manufacturing Execution System. Se trata de un aplicativo software para realizar el seguimiento de la producción industrial. Estos dirigen y monitorizan los procesos de producción en la planta, incluyendo el trabajo manual o automático de informes, así como preguntas online y enlaces a las tareas que tienen lugar en la planta.

El OEE (Overall Equipment Effectiveness o Eficiencia Global de los Equipos) es un indicador clave utilizado en entornos industriales para medir el rendimiento real de una máquina, línea o proceso productivo.

El OEE se compone de tres factores:

• Disponibilidad: porcentaje de tiempo en el que el equipo está operativo respecto al tiempo planificado.

• Rendimiento: velocidad real de producción frente a la velocidad teórica.

• Calidad: proporción de unidades buenas respecto al total producido.

El resultado se expresa como un porcentaje y permite identificar pérdidas asociadas a paradas, ineficiencias o defectos. En proyectos de digitalización industrial e IoT, el OEE se utiliza como referencia para analizar datos en tiempo real, detectar cuellos de botella y priorizar mejoras que impacten directamente en la productividad y la eficiencia operativa.

IIC

El Consorcio de Internet Industrial se fundó en marzo de 2014 para reunir a las organizaciones y tecnologías necesarias para acelerar el crecimiento de Internet industrial mediante la identificación, el ensamblaje, las pruebas y la promoción de las mejores prácticas. Los miembros trabajan en colaboración para acelerar el uso comercial de tecnologías avanzadas. La membresía incluye innovadores tecnológicos pequeños y grandes, líderes del mercado vertical, investigadores, universidades y organizaciones gubernamentales.

RAMI4.0

Es un mapa tridimensional que muestra los aspectos más importantes de Industria 4.0. RAMI4.0 garantiza que todos los participantes involucrados compartan una perspectiva común y desarrollen un entendimiento común.

Es un concepto inicial basado en estándares definidos para soluciones industriales. Reúne los elementos vitales de Industria 4.0 en un modelo en capas 3D. Esta estructura se puede utilizar para organizar y desarrollar sistemáticamente las tecnologías de la Industria 4.0.

• Fase de estudio y diseño de la seguridad
• Fase de integración
• Fase de monitorización
• Plan de contingencia

En proyectos IoT, solo se llega deprisa, pero acompañado se llega más lejos.

En los proyectos IoT podemos apoyarnos en socios tecnológicos para diferentes tipos de ingeniería como es el caso de la infraestructura de comunicaciones cloud privadas, los sistemas de almacenamiento de datos redundado de proximidad y la monitorización continua IoT.

Sobretodo, debemos proteger con ciberseguridad la práctica de cualquier proyecto IoT nuevo, proteger la disponibilidad, integridad y confidencialidad en esta evolución digital será indispensable.

Las oportunidades son muchísimas y diferentes según las necesidades del tipo de industria. En la fábrica 4.0 o fábrica conectada, podemos abordar proyectos de conectividad para tener mayor control y manejo como para la mejora de calidad productiva, ahorro de defectuosos, optimización de procesos, ahorro de energía, mejoras en la productividad y mayor vigilancia de la producción.

En general el uso de sensores, dispositivos Gateway IoT industriales, cortafuegos, routers, infraestructura de conectividad 4G, LoRaWAN, SigFox, NB-IoT ,... y una plataforma o espacio cloud privado, público o híbrido. Se aconseja acceder a un cloud privado para mayor seguridad.

En entornos IoT industriales se utilizan protocolos de comunicación diseñados para garantizar fiabilidad, interoperabilidad y seguridad, adaptándose al tipo de dispositivo, red y caso de uso.

En el nivel de campo y automatización industrial son habituales protocolos como OPC UA, Modbus TCP, PROFINET, EtherNet/IP o S7, utilizados para la comunicación entre sensores, PLCs y sistemas de control.

Para la transmisión de datos hacia plataformas IT o cloud se emplean protocolos orientados a mensajería y eventos, como MQTT, AMQP o HTTP/REST, que permiten comunicaciones eficientes, desacopladas y escalables. MQTT es especialmente común en proyectos IoT por su bajo consumo de ancho de banda y su capacidad para trabajar en entornos con conectividad limitada.

En escenarios de conectividad inalámbrica o de largo alcance se utilizan tecnologías y protocolos como LoRaWAN, NB-IoT, LTE-M o 5G, según los requisitos de consumo energético, cobertura y latencia.

La elección del protocolo depende del contexto industrial, los requisitos de seguridad y el modelo de integración. Para las empresas es importante priorizar protocolos estandarizados, con soporte de cifrado, autenticación y gestión de identidades, que faciliten la interoperabilidad y la evolución futura del sistema.
 

En este enlace del "Instituto nacional de ciberseguridad de España" se resumen los diferentes protocolos y sus recomendaciones de seguridad.
https://www.incibe-cert.es/blog/iot-protocolos-comunicacion-ataques-y-recomendaciones.

Una plataforma cloud industrial debe ofrecer un conjunto de servicios orientados a la seguridad, la gestión del ciclo de vida de los dispositivos y la explotación eficiente de los datos.

En primer lugar, debe proporcionar gestión segura de dispositivos IIoT, incluyendo autenticación fuerte, gestión de identidades, control de accesos, cifrado de comunicaciones y capacidad para aplicar políticas de seguridad de forma centralizada. Es clave que permita aislar dispositivos y flujos de datos para evitar accesos no autorizados o movimientos laterales.

En el ámbito de los datos, la plataforma debe incorporar servicios de ingesta y procesamiento capaces de manejar flujos en tiempo real y grandes volúmenes de información, utilizando tecnologías estandarizadas y escalables. Esto incluye almacenamiento seguro, gestión de históricos y capacidades de procesamiento para analítica avanzada.

Además, es fundamental que ofrezca herramientas de visualización y explotación, como cuadros de mando y sistemas de reporting, que permitan convertir los datos industriales en información operativa útil. Todo ello debe apoyarse en mecanismos de alta disponibilidad, respaldo, monitorización continua y cumplimiento normativo, garantizando que la plataforma sea fiable, escalable y adecuada para entornos industriales críticos.
 

Si, Sarenet ofrece una plataforma cloud IIoT con capacidad de abordar cualquier proyecto, con software libre.

Sarenet provisiona orquestador de contenedores o Kubernetes (K8s).

Facilita el uso de múltiples hosts, optimiza los recursos, facilita la automatización en proyectos IoT y posibilita la escalabilidad en los cluster de servidores.

El primer paso en el sector industrial es realizar un inventario IP y estudiar bien las debilidades antes de añadir nueva conectividad en una zona productiva.

La réplica de datos desde entornos IIoT u OT hacia un entorno cloud debe diseñarse como parte del plan de continuidad y recuperación, priorizando la seguridad y la mínima interferencia con la operación industrial.

El proceso comienza identificando qué datos y sistemas deben replicarse (históricos, configuraciones, máquinas virtuales, bases de datos o flujos IIoT) y definiendo los objetivos de recuperación (RPO y RTO). A partir de ahí, se implementan mecanismos de réplica continua o programada desde la red OT hacia una zona intermedia segura (DMZ industrial), evitando accesos directos al entorno productivo.

La transferencia hacia el cloud se realiza mediante conexiones cifradas y controladas, utilizando tecnologías de réplica y backup que permiten mantener copias actualizadas fuera de la planta. Estas réplicas pueden almacenarse en infraestructuras cloud privadas, públicas o híbridas, con opciones de inmutabilidad para proteger los datos frente a errores humanos o ataques de ransomware. 

El resultado es un plan de contingencia que permite recuperar información crítica o activar entornos alternativos en el cloud, reduciendo el impacto de incidentes, paradas de producción o desastres físicos sin comprometer la seguridad del entorno industrial.

Sarenet realiza la configuración del enrutamiento de tráfico dentro de redes de área extensa y despliega de forma privada los lazos de unión al cloud industrial, instala cortafuegos que protegen el acceso a Cloud desde la red IT del cliente.

Sarenet despliega cortafuegos que separan IT de OT, de esta forma controla la interacción en las redes internas del cliente en proyectos IoT.

Sarenet instala sondas (Guardian) en la red productiva y vigila las vulnerabilidades, las nuevas amenazas o conexiones inseguras a la red productiva, mediante dispositivos específicos dedicados exclusivamente a vigilar nuevas amenazas sobre activos IP en la red OT.

Una red cloud industrial privada para IoT se construye combinando infraestructura dedicada, conectividad segura y una arquitectura orientada a la segregación y al control.

El diseño comienza definiendo los requisitos del entorno industrial: tipo de dispositivos IoT, volumen y criticidad de los datos, latencias admisibles, necesidades de disponibilidad y requisitos regulatorios. Con esta información se dimensiona una infraestructura cloud privada, normalmente basada en virtualización y contenedores, que permita aislar cargas, escalar recursos y garantizar rendimiento predecible.

La conectividad entre planta y cloud se realiza mediante redes privadas (MPLS, SD-WAN o enlaces dedicados), integradas con firewalls y segmentación lógica para separar tráfico IoT, IT y accesos externos. Es habitual incorporar una DMZ industrial para controlar el intercambio de datos entre el entorno productivo y la plataforma cloud.

Sobre esta base se despliegan servicios de ingesta, almacenamiento y procesamiento de datos IoT, con mecanismos de autenticación, cifrado, control de accesos y monitorización continua. El resultado es una red cloud industrial privada que permite explotar datos IoT con seguridad, control y continuidad operativa, sin depender de infraestructuras compartidas ni exponer el entorno de producción.
 

Sarenet realiza la integración de conexiones remotas a través de túneles seguros y configura zonas iDMZ (DMZ industrial) para la interacción de datos OT.

La captura de señales IoT y su integración en una red cloud privada se realiza mediante una arquitectura en capas que separa claramente el entorno físico, la conectividad y el procesamiento de datos.

En el nivel de campo, los sensores y dispositivos IoT recogen señales físicas (temperatura, presión, consumo, estado de máquina, etc.) y las envían a un gateway IoT industrial. Este gateway se encarga de agregar los datos, traducir los protocolos de comunicación y aplicar controles básicos de seguridad antes de transmitir la información.

La comunicación hacia la red cloud privada se realiza a través de enlaces seguros, ya sea mediante redes cableadas, 4G/5G, radio o WAN privada, utilizando cifrado, autenticación y control de accesos. Habitualmente, el tráfico se canaliza a través de una zona intermedia (DMZ o red perimetral) para aislar el entorno productivo del entorno IT y cloud.

Una vez en la cloud privada, los datos se almacenan y procesan en plataformas diseñadas para análisis, visualización y explotación avanzada, manteniendo siempre el control sobre la ubicación de los datos, las políticas de seguridad y los accesos. Este enfoque permite escalar proyectos IoT con garantías de seguridad, rendimiento y cumplimiento normativo.
 

La monitorización continua de vulnerabilidades IP en redes industriales se basa en herramientas diseñadas específicamente para entornos OT, que permiten detectar riesgos sin interferir en la operación.

Estas soluciones utilizan sensores pasivos que analizan el tráfico de red en tiempo real, identifican activos, protocolos industriales y patrones de comunicación, y construyen un inventario dinámico de dispositivos. A partir de este aprendizaje, detectan comportamientos anómalos, configuraciones inseguras o exposiciones a vulnerabilidades conocidas.

Habitualmente se integran con plataformas de detección y respuesta para OT, capaces de correlacionar eventos, alertar ante amenazas emergentes y priorizar riesgos según el impacto en la producción. Estas herramientas se complementan con sistemas de gestión de vulnerabilidades y SIEM, que permiten una visión centralizada del estado de seguridad.

Este enfoque continuo permite anticiparse a incidentes, reducir la superficie de ataque y mantener la seguridad del entorno industrial sin necesidad de escaneos activos que puedan afectar a la estabilidad de los sistemas de producción.
 

Una puerta de enlace IoT es una solución para habilitar la comunicación IoT, generalmente comunicaciones de dispositivo a dispositivo o, comunicaciones de dispositivo a nube. La puerta de enlace suele ser un dispositivo de hardware que aloja software de aplicación que realiza tareas esenciales. En su nivel más básico, la puerta de enlace facilita las conexiones entre diferentes fuentes de datos y destinos.

• Un Gateway IoT Industrial, trabaja con diferentes tecnologías de conectividad.
• Conectividad radio de corto alcance (WiFi, ZigBee, BLE,...)
• Conectividad radio de bajo consumo y largo alcance (LoRaWAN,SigFox, NB-IoT, LTE-M,..)
• Conectividad Celular (GSM, 4G, 5G, ...)

Es necesario conectar sensores de manera cableada o inalámbrica y recoger con el Gateway los valores de la señal. El Gateway entiende el protocolo de comunicación durante la recogida de la señal industrial y lo traduce para poder enviar los datos a un entorno cloud.

Sobretodo, se debe pensar en la fiabilidad y en la seguridad. Para ello nos fijamos en:

• Evaluación de componentes HW y SW
• Sistemas de arranque confiables
• Metodología segura de almacenamiento
• Protección de los datos que se almacenan
• Los mecanismos para actualizaciones de seguridad
• Mecanismos de autenticación seguros y confiables
• La seguridad que dispone en las comunicaciones de tipo multiprotocolo

Existen diferentes referencias europeas como ISA99/IEC62443 para el diseño de la seguridad en sistemas y redes de control industrial. 

Ver más en: https://www.incibe-cert.es/blog/estandares-ciberseguridad-redes-inteligentes

Contar con un socio tecnológico es conveniente para cualquier fase dentro del tratamiento de incidentes de ciberseguridad. Prevención, Detección, Recuperación y Respuesta.

Lo primero que debemos prever es el disponer de un plan de contingencia, esto es algo que se debe construir antes de cualquier cambio o antes de cualquier uso de tecnologías habilitadoras para IoT industrial.

Te recomendamos la lectura de la siguiente publicación realizada por ENISA (European Union Agency for Cybersecurity) sobre las buenas prácticas para la seguridad IoT.

https://www.enisa.europa.eu/publications/good-practices-for-security-of-iot-1

Es importante compartimentar la red para llegar a controlar mejor cualquier desvío, vulnerabilidad o amenaza existente, dentro del ecosistema digital de riesgos de la conectividad.

Separar la red de oficina (IT) de la red de producción (OT) es un principio básico de seguridad y continuidad operativa en entornos industriales.
La red de oficina está expuesta de forma habitual a Internet, correo electrónico, navegación web y dispositivos de usuario, lo que incrementa el riesgo de infecciones, accesos no autorizados o errores humanos. En cambio, la red de producción alberga sistemas críticos que controlan procesos industriales y cuya indisponibilidad puede provocar paradas, daños materiales o riesgos para la seguridad.

Al mantener ambas redes segregadas mediante segmentación y firewalls, se evita que una incidencia en IT se propague al entorno OT. Además, se controla de forma precisa qué sistemas pueden intercambiar datos y bajo qué condiciones, normalmente a través de zonas intermedias como una DMZ industrial.

Este enfoque, alineado con estándares como IEC 62443, permite mejorar la seguridad, reducir la superficie de ataque y garantizar que la digitalización industrial y los proyectos IoT se realicen sin comprometer la estabilidad ni la seguridad de la producción.
 

El uso de software libre en proyectos IoT ofrece ventajas claras en términos de flexibilidad, control y sostenibilidad tecnológica, especialmente en entornos industriales y empresariales.

Una de las principales ventajas es la independencia del proveedor. Al basarse en tecnologías abiertas, la empresa evita el bloqueo tecnológico y puede evolucionar su arquitectura, cambiar de integradores o escalar el proyecto sin depender de un fabricante concreto.

El software libre facilita además la interoperabilidad, ya que suele apoyarse en estándares abiertos ampliamente adoptados. Esto permite integrar dispositivos, plataformas y sistemas heterogéneos, algo habitual en entornos IoT industriales.

Desde el punto de vista técnico, aporta transparencia y control. El acceso al código permite auditar el funcionamiento, reforzar la seguridad, adaptar funcionalidades y cumplir requisitos regulatorios o de soberanía del dato.

Por último, el software libre favorece la escalabilidad y la innovación. Existen ecosistemas maduros en torno a tecnologías como contenedores, orquestadores, plataformas de mensajería o analítica de datos, que permiten construir soluciones IoT robustas sin costes de licencia por dispositivo, manteniendo un modelo sostenible a largo plazo.
 

Es la ingeniería necesaria para el procesamiento de datos.

• Sistemas de ingesta de datos en un cluster (Apache Kafka, NiFi,..), recolectar datos a través de colectores (MQTT, OPC UA, S7,...).
• Procesamiento y almacenamiento de datos ( Spark, Apache Hbase,...)
• Reporte de datos ( Visualización "dashboards": Kibana, Grafana, Superset,...).

HBase es una base de datos distribuida no relacional de código abierto modelada a partir de Google BigTable y escrita en Java. Su desarrollo forma parte del proyecto Hadoop de la Fundación de Software Apache y se ejecuta sobre HDFS, proporcionando capacidades al estilos de BigTable para Hadoop.

Una plataforma de logística de datos, integrados en tiempo real y de procesamiento de eventos sencillos. Apache NiFi es una plataforma de logística de datos integrados para la automatización del movimiento de datos entre sistemas diversos.

Es un centro de soporte técnico, dedicado exclusivamente a los servicios relacionados con la seguridad digital. Es un servicio de vigilancia continua para mejorar la seguridad de los equipos finales y de la infraestructura de comunicaciones.

La latencia es el tiempo que tarda un paquete de datos en viajar desde un punto de una red hasta otro y regresar con la respuesta. En términos simples, representa el retraso que existe entre una petición y la recepción de la respuesta dentro de un sistema de comunicaciones. 

En una interacción típica entre una persona usuaria y un servidor, la persona usuaria envía una solicitud (por ejemplo, abrir una web o realizar una consulta a una base de datos) y el servidor devuelve una respuesta. La latencia mide el tiempo que tarda ese proceso en completarse.

Una forma intuitiva de entenderlo es imaginar un partido de ping-pong:

• La persona usuaria sería la jugadora A.
• El servidor sería el jugador B.
• La solicitud sería la pelota.
• La latencia sería el tiempo que tarda la pelota en volver al jugador que la lanzó. 

La latencia es crítica porque afecta directamente al rendimiento de las aplicaciones y a la experiencia de las personas usuarias. Si el tiempo de respuesta entre sistemas es elevado, las aplicaciones pueden comportarse de forma lenta o ineficiente.

Una latencia elevada puede provocar, entre otros efectos:

• Menor fluidez en la colaboración y el trabajo diario.
• Peor rendimiento de aplicaciones y servicios.
• Una experiencia de uso más lenta o frustrante. 

Incluso en redes con gran capacidad de ancho de banda, una latencia elevada puede hacer que el sistema “parezca lento”, porque lo importante no es solo cuántos datos pueden enviarse, sino cuánto tarda cada intercambio de información.

La latencia total de una comunicación es el resultado del tiempo que tarda un paquete de datos en recorrer toda la red, desde el origen hasta el destino y de vuelta. 
En ese recorrido intervienen múltiples elementos, entre ellos:

• La distancia entre los dos puntos de comunicación.
• Los dispositivos de red por los que pasan los datos.
• La congestión de la red.
• La tecnología utilizada para transmitir la información. 

Cada uno de estos factores puede añadir retrasos adicionales al tránsito de los paquetes.

La distancia física entre los puntos de comunicación es uno de los factores más evidentes que afectan a la latencia. Cuanto mayor sea la distancia que debe recorrer la información, mayor será el tiempo necesario para completar el trayecto.

Por ejemplo, conectarse a un servidor ubicado en la misma ciudad generará menos latencia que hacerlo con uno situado en otro continente. 

Este efecto se puede entender con la analogía del ping-pong: si la mesa es más grande, la pelota tarda más en ir de un lado a otro.

La tecnología utilizada para transportar los datos también influye en la latencia. Distintos medios de transmisión presentan características diferentes en términos de estabilidad y tiempo de respuesta. 

Estos son algunos ejemplos de rangos de latencia típicos:

• Fibra FTTH: aproximadamente 5-20 ms, muy estable y adecuada para aplicaciones en tiempo real.
• 4G/LTE: alrededor de 30-90 ms.
• 5G: entre 25-40 ms en condiciones habituales.
• Satélite LEO: aproximadamente 25-50 ms.
• Satélite GEO: entre 500-800 ms debido a la gran distancia hasta el satélite geostacionario.

Esto demuestra que la elección de tecnología puede tener un impacto significativo en el rendimiento de la red.
 

Los datos que viajan por una red no siempre siguen una ruta directa entre origen y destino. Con frecuencia deben atravesar múltiples dispositivos de red, como rúteres o sistemas intermedios.

Cuando existen muchas etapas en la ruta de comunicación (lo que se conoce como saltos de red), cada dispositivo añade un pequeño retraso al proceso. Esto puede aumentar la latencia total incluso si la distancia geográfica no es especialmente grande.

Cada dispositivo intermedio que procesa un paquete de datos introduce cierto tiempo adicional en la comunicación. Esto se debe a que los equipos de red deben recibir, analizar y reenviar el paquete hacia su siguiente destino.

Si la ruta incluye numerosos dispositivos o si la red no está bien optimizada, los paquetes pueden atravesar múltiples nodos antes de llegar al destino, lo que incrementa el tiempo total de tránsito.

La latencia total de una comunicación en red se compone de varios tipos de retraso que se producen durante el recorrido de los datos.

• Latencia de propagación: es el tiempo que tarda la señal en viajar físicamente por el medio de transmisión (fibra, radio, etc.) entre origen y destino. Depende principalmente de la distancia.
• Latencia de transmisión: es el tiempo necesario para enviar todos los bits de un paquete al medio de transmisión. Depende del tamaño del paquete y del ancho de banda del enlace.
• Latencia de procesamiento: es el tiempo que emplean rúteres, switches u otros dispositivos para analizar el paquete y decidir cómo reenviarlo.

El ancho de banda mide cuánta información puede transmitirse simultáneamente por una red, pero no mide la velocidad con la que cada paquete viaja.

Una red puede tener una gran capacidad de transmisión (por ejemplo, 1 Gbps) y aun así experimentar lentitud si el tiempo de respuesta entre sistemas es elevado.

Además, cuando el tráfico supera el ancho de banda disponible, se generan colas de paquetes que aumentan la latencia y el jitter, lo que deteriora el rendimiento de la red.

La calidad de una red no depende únicamente de la latencia. Existen otros factores clave que influyen en el rendimiento.

Entre ellos destacan:

• Pérdida de paquetes (packet loss): ocurre cuando algunos paquetes enviados no llegan a su destino. Puede producirse por congestión, dispositivos saturados o mala calidad del medio de transmisión.
• Jitter: es la variación de la latencia a lo largo del tiempo. No se refiere al tiempo medio de respuesta, sino a lo irregular que es ese retraso.

Cuando el jitter es elevado, la comunicación se vuelve impredecible y el rendimiento de servicios en tiempo real se deteriora.

Estos son algunos ejemplos de estrategias para reducir la latencia en una red:

• Reducir la distancia entre sistemas, utilizando centros de datos cercanos o redes de distribución de contenidos.
• Elegir tecnologías de red más eficientes, como fibra óptica frente a tecnologías más antiguas.
• Seleccionar proveedores que optimicen las rutas de red y eviten congestión.
• Aplicar políticas de calidad de servicio (QoS) para priorizar tráfico crítico, como la voz IP. 

Estas decisiones ayudan a mejorar el tiempo de respuesta percibido por las personas usuarias.
 

Una forma habitual de medir la latencia es calcular el tiempo de ida y vuelta de un paquete de datos entre dos nodos de la red.

Este tiempo se mide en milisegundos y se conoce como RTT (Round Trip Time). Representa el tiempo total que tarda la información en enviarse desde un origen, llegar al destino y volver con la respuesta.

Una de las herramientas más comunes para medir la latencia es el comando ping.

Ping es una herramienta de diagnóstico de red que permite verificar la conectividad entre dos nodos, como servidores, ordenadores o rúteres. 

Al ejecutarlo, el sistema envía paquetes de prueba y calcula el tiempo de ida y vuelta (RTT), proporcionando así una medición directa de la latencia de la conexión.

Los valores de latencia aceptables dependen de la tecnología de red y del tipo de aplicación. 

Estos son algunos rangos orientativos de latencia según la tecnología utilizada:

• FTTH: 5-20 ms
• 5G: 25-40 ms (aproximadamente)
• 4G: 30-90 ms
• Satélite LEO: 25-50 ms
• Satélite GEO: 500-800 ms

Las aplicaciones en tiempo real, como voz IP o videollamadas, requieren latencias bajas para funcionar correctamente, mientras que servicios asíncronos como el correo electrónico pueden tolerar retrasos mayores sin que la persona usuaria perciba problemas.

La integración entre SD-WAN y SASE parte de una idea muy clara: la conectividad y la seguridad ya no deben tratarse como dos capas separadas, especialmente en organizaciones con sedes distribuidas, personas trabajando en remoto y uso intensivo de SaaS o cloud. SD-WAN aporta inteligencia sobre la conectividad, mientras que SASE añade una capa de seguridad distribuida que evita tener que hacer pasar todo el tráfico por el CPD central para inspeccionarlo.

SD-WAN gestiona el tráfico de forma dinámica sobre distintos tipos de enlace y decide en tiempo real qué camino es el más adecuado para cada tipo de aplicación o servicio. Eso resuelve el problema de la agilidad, de la redundancia y de la priorización del tráfico. Sin embargo, por sí sola no incorpora toda la capa de seguridad necesaria. Ahí es donde entra SASE: integra funciones como inspección de tráfico, prevención de amenazas, control de acceso y Zero Trust Network Access directamente sobre la red, pero distribuidas en la nube y cercanas a cada sede o persona usuaria.

La clave operativa de esta integración es que el tráfico ya no necesita “volver atrás” al centro de datos para ser inspeccionado antes de salir hacia internet o hacia una aplicación en la nube. Ese backhaul introduce latencia, genera cuellos de botella y complica la experiencia de uso. Con SASE sobre SD-WAN, la inspección y la aplicación de políticas de seguridad ocurren en el punto de presencia más próximo, manteniendo el mismo nivel de control sin penalizar el rendimiento.

Esto encaja especialmente bien en arquitecturas donde una empresa tiene múltiples ubicaciones pequeñas, trabajo híbrido estructural y un peso creciente de las aplicaciones SaaS. En lugar de seguir arrastrando un modelo centralizado pensado para otra época, la organización pasa a una lógica distribuida, donde la conectividad sigue siendo inteligente gracias a SD-WAN y la seguridad acompaña al tráfico allí donde se genera. El resultado no es sólo una red más rápida, sino una arquitectura más coherente con la realidad operativa actual.
 

La latencia es uno de los criterios más importantes a la hora de decidir entre MPLS y conectividad basada en internet, porque no afecta sólo a la velocidad percibida, sino a la estabilidad y previsibilidad del comportamiento de la red. En entornos corporativos, especialmente cuando hay voz, videoconferencia, acceso a sistemas críticos o interacción constante entre sedes, no basta con “tener conexión”; hace falta que el tráfico llegue con tiempos consistentes.

MPLS sigue teniendo valor precisamente por eso. Al circular por la red privada del operador y no por internet público, ofrece una latencia mucho más predecible y controlada, además de calidad de servicio garantizada. Esto es especialmente relevante en organizaciones con tráfico interno intenso entre delegaciones, en sectores regulados o en escenarios donde una variación de latencia puede afectar directamente a la operativa, como ocurre con VoIP o con ciertos accesos a sistemas centrales.

La conectividad sobre internet puede funcionar bien en muchos contextos, pero introduce más variabilidad. La ruta que siguen los datos, la congestión del camino o el comportamiento de terceros operadores pueden alterar los tiempos de respuesta. Esto no significa que internet sea siempre una mala opción, sino que exige asumir mayor incertidumbre. De hecho, en redes modernas, esa incertidumbre puede compensarse parcialmente con SD-WAN, que elige en tiempo real el enlace más adecuado y mejora el uso de múltiples accesos. Pero incluso en ese escenario, la latencia sigue siendo un factor de diseño clave.

Por eso, cuando una organización valora qué arquitectura necesita, la pregunta no debería ser sólo cuánto ancho de banda requiere, sino qué tolerancia real tiene ante la variación de latencia. Si la respuesta es baja y la calidad debe mantenerse de forma consistente, MPLS sigue siendo una base muy sólida. Si el entorno permite más flexibilidad y se complementa con inteligencia de red, internet puede jugar un papel mayor dentro de una arquitectura híbrida.
 

Diseñar una arquitectura híbrida con MPLS, SD-WAN y SASE no consiste en apilar tecnologías, sino en asignar a cada una un papel claro dentro de una red corporativa más amplia. El punto de partida siempre debe ser entender cómo trabaja la organización: cuántas sedes tiene, cuánto tráfico viaja entre ellas, cuánto peso tienen el cloud y el SaaS, cuántas personas trabajan en remoto y cuál es la tolerancia real ante una caída o degradación del servicio.

En esa combinación, MPLS suele actuar como base de conectividad privada y estable para sedes fijas o entornos donde la latencia predecible y la calidad garantizada siguen siendo muy importantes. SD-WAN aporta la capa de inteligencia operativa: permite usar múltiples enlaces, decidir dinámicamente qué tráfico va por cuál, automatizar el failover y simplificar la gestión de redes distribuidas. Por su parte, SASE introduce la capa de seguridad distribuida sobre esa conectividad, evitando que todo el tráfico tenga que volver al CPD central para ser inspeccionado.

La arquitectura híbrida funciona bien cuando cada tecnología resuelve un problema distinto. MPLS cubre la necesidad de una red privada sólida. SD-WAN optimiza el uso de los distintos accesos disponibles y aporta flexibilidad. SASE protege a personas usuarias, sedes y tráfico cloud con una lógica distribuida y coherente con el trabajo moderno. Esto encaja especialmente bien en organizaciones que no pueden permitirse depender sólo de internet, pero tampoco quieren seguir operando con un modelo totalmente centralizado y rígido.

Lo importante es que la red resultante sea una sola arquitectura, no tres capas desconectadas. Las políticas de acceso, la priorización del tráfico, la redundancia, la visibilidad y la seguridad deben estar alineadas. Cuando eso ocurre, la organización obtiene lo mejor de cada enfoque: calidad donde más se necesita, agilidad donde hay más variabilidad y seguridad donde el tráfico realmente se genera. 
 

Zero Trust no sustituye a tecnologías como MPLS o SD-WAN, ni compite con ellas. Se integra por encima de ellas como una arquitectura de acceso y control. La conectividad resuelve cómo circula el tráfico; Zero Trust define quién puede acceder a qué, desde dónde, en qué condiciones y con qué límites. Por eso son capas complementarias y no alternativas.

MPLS puede ofrecer una red privada de alta calidad entre sedes, pero por sí sola no implica que todos los accesos internos deban considerarse legítimos. Del mismo modo, SD-WAN puede gestionar el tráfico de forma inteligente y flexible, pero tampoco determina automáticamente si una persona usuaria, un dispositivo o un sistema deberían tener acceso a un recurso concreto. Ahí entra Zero Trust: elimina la confianza implícita y convierte cada acceso en una decisión explícita basada en identidad y contexto.

En una arquitectura real, esto se traduce en que la red puede seguir siendo privada, resiliente y eficiente, pero los accesos dejan de depender del simple hecho de estar conectada o conectado a ella. Un equipo en una sede, una persona usuaria remota o un sistema de proveedor no obtienen acceso amplio por compartir infraestructura. Cada uno recibe únicamente lo que necesita y bajo reglas concretas. Si además la red está segmentada, el resultado es una conectividad robusta sobre la que se apoya una seguridad mucho más granular.

Esta integración es especialmente importante porque evita un error común: asumir que una red corporativa bien diseñada equivale a una red segura por defecto. La conectividad y la seguridad no son lo mismo. Cuando Zero Trust se incorpora desde el diseño, MPLS o SD-WAN dejan de ser sólo medios de transporte y pasan a formar parte de una arquitectura donde la confianza ya no viaja implícita con el tráfico.
 

ZTNA se implementa a partir de una lógica muy distinta a la de la VPN tradicional. Mientras la VPN suele conceder un acceso amplio a la red una vez superado el punto de autenticación, ZTNA concede acceso sólo a las aplicaciones o recursos concretos que cada persona usuaria necesita, validando identidad y contexto en cada sesión. La diferencia de fondo es que la VPN abre la puerta a una red; ZTNA abre la puerta sólo a lo estrictamente necesario.

En la práctica, esto significa que la organización deja de pensar en “dar acceso remoto a la red corporativa” y pasa a diseñar políticas específicas por recurso. Una persona usuaria puede acceder a una aplicación interna determinada desde un dispositivo corporativo gestionado y en unas condiciones concretas, pero no por ello obtiene visibilidad ni capacidad de movimiento hacia el resto de la infraestructura. Ese enfoque reduce mucho la exposición en caso de robo de credenciales o de compromiso de un equipo remoto.

Frente a la VPN, ZTNA también encaja mejor con entornos híbridos y con uso intensivo de SaaS o cloud, porque no obliga a crear siempre ese viaje de ida y vuelta hacia el centro de datos. El acceso se da de forma más directa y controlada, con mejor experiencia para las personas usuarias y con una lógica más alineada con Zero Trust. Esto no significa que la VPN desaparezca por completo en todos los entornos, pero sí que deja de ser la respuesta por defecto para cualquier necesidad de acceso remoto.

Implementarlo bien exige trabajar identidad, MFA, políticas de acceso, segmentación y visibilidad sobre dispositivos. No es sólo cambiar de tecnología, sino cambiar de modelo mental: pasar de “conectar personas usuarias a la red” a “conectar personas usuarias únicamente con lo que deben utilizar”. Esa diferencia es la que hace que ZTNA sea un enfoque más sólido para redes corporativas distribuidas. 
 

El uso de redes WiFi públicas introduce un riesgo evidente de exposición en un contexto donde las personas usuarias trabajan con credenciales, aplicaciones corporativas, correo y datos sensibles fuera de entornos controlados. El problema no es sólo que esas redes sean compartidas, sino que la organización tiene muy poca capacidad para saber cómo están configuradas, qué otras personas están conectadas, qué visibilidad existe sobre el tráfico o si hay mecanismos de protección realmente fiables.

Desde la perspectiva empresarial, esto aumenta la superficie de ataque sobre dispositivos remotos. Si una persona usuaria accede desde una red pública sin controles adecuados, el equipo queda más expuesto a interceptación, a entornos inseguros o a contextos donde es más difícil garantizar la integridad de la conexión. En ese escenario, las credenciales, las sesiones activas o el propio dispositivo pueden convertirse en el punto de apoyo inicial de una intrusión.

El riesgo se vuelve aún mayor si la organización sigue confiando en un modelo donde, una vez conectado el equipo, se le concede acceso amplio a la red. Por eso, en el corpus el problema de los dispositivos remotos no se plantea como una simple cuestión de conectividad, sino como un cambio de arquitectura. Si el equipo está fuera de la oficina, la seguridad debe apoyarse más en la identidad, en la verificación del contexto, en la protección del endpoint y en enfoques como SASE o ZTNA, que reducen el impacto de trabajar desde redes no controladas.
 

Los dispositivos IoT conectados a redes corporativas no deben tratarse como elementos neutros o secundarios, porque amplían de forma muy clara la superficie de ataque. En muchos casos, son equipos con menor capacidad de protección nativa, con ciclos de actualización irregulares o con funciones muy concretas, pero conectados a una infraestructura donde conviven sistemas mucho más críticos. Eso obliga a aplicarles controles específicos y no simplemente integrarlos como si fueran un endpoint convencional más.

El primer control esencial es la segmentación. Un dispositivo IoT no debería compartir el mismo espacio de red que sistemas corporativos críticos, equipos de administración o recursos sensibles. Si queda comprometido, la segmentación debe impedir que sirva como trampolín hacia otros activos. Además, el acceso que ese dispositivo mantiene hacia fuera y hacia dentro debe limitarse a lo estrictamente necesario para su función. Si sólo tiene que comunicarse con una plataforma concreta, no debería poder hablar con mucho más.

También resulta muy importante controlar identidad, gestión y exposición. Si el dispositivo admite autenticación o administración remota, esos accesos deben estar restringidos, protegidos y monitorizados. Del mismo modo, cualquier firmware, software asociado o integración con otros sistemas debe entrar dentro del alcance de la gestión de vulnerabilidades. En entornos donde no siempre es fácil actualizar rápido, las medidas compensatorias cobran aún más peso.

Por último, conviene observar el comportamiento. Igual que sucede con otros elementos del entorno, un dispositivo IoT comprometido puede empezar a generar tráfico extraño, conexiones no previstas o actividad incompatible con su función habitual. Cuando estos dispositivos forman parte de la red corporativa, no basta con que “funcionen”; hace falta integrarlos en una arquitectura donde su conectividad, su visibilidad y su alcance estén realmente controlados. 
 

Proteger la conectividad entre sedes implica garantizar no sólo que los datos viajen, sino que lo hagan de forma segura, controlada y con un comportamiento predecible. En entornos corporativos, esta conectividad suele ser crítica porque soporta aplicaciones de negocio, acceso a sistemas centrales y comunicaciones internas que no pueden degradarse sin impacto directo.

En la práctica, la protección se basa en combinar conectividad privada o controlada con mecanismos de seguridad integrados. Tecnologías como MPLS aportan aislamiento respecto a internet público, mientras que arquitecturas más modernas incorporan controles adicionales como segmentación, cifrado y políticas de acceso alineadas con identidad. La idea no es confiar únicamente en el medio de transporte, sino en cómo se gobierna el acceso y el flujo de datos.

Además, la monitorización continua juega un papel clave. No basta con establecer la conexión; es necesario observar su comportamiento, detectar anomalías y reaccionar ante degradaciones o intentos de acceso indebido. Cuando esta conectividad forma parte de una arquitectura más amplia, su protección debe integrarse con el resto de capas de seguridad, no funcionar como un elemento aislado.

MPLS aporta principalmente control, estabilidad y previsibilidad frente a redes basadas en internet público. Al tratarse de una red privada gestionada por el operador, el tráfico no depende de rutas variables ni de condiciones externas, lo que se traduce en una latencia más consistente y una menor variabilidad en el rendimiento.

Esto resulta especialmente relevante en entornos donde la calidad de servicio es crítica, como aplicaciones de voz, videoconferencia o sistemas corporativos que requieren tiempos de respuesta estables. En internet público, estos parámetros pueden fluctuar en función de la congestión o de factores fuera del control de la organización.

Además, MPLS permite aplicar políticas de calidad de servicio de forma más precisa, priorizando tráfico crítico y garantizando que determinadas aplicaciones mantengan su rendimiento incluso en situaciones de carga. También ofrece un mayor aislamiento, lo que reduce la exposición directa frente a amenazas externas.

No obstante, su valor no está en sustituir completamente a internet, sino en formar parte de una arquitectura donde se combine con otras tecnologías para equilibrar coste, flexibilidad y rendimiento.

La calidad de servicio en redes MPLS se garantiza mediante la capacidad de clasificar y priorizar el tráfico en función de su criticidad. No todos los datos se tratan igual: aplicaciones sensibles como VoIP o sistemas de negocio reciben un tratamiento preferente frente a tráfico menos crítico.

Esto se logra definiendo políticas que asignan diferentes niveles de prioridad y reserva de recursos a cada tipo de tráfico. De este modo, incluso en situaciones de saturación, los flujos más importantes mantienen su calidad, evitando degradaciones que afectarían directamente a la operativa.

Además, al tratarse de una red controlada por el operador, MPLS permite mantener niveles de latencia, jitter y pérdida de paquetes dentro de parámetros más estables que en internet público. Esta previsibilidad es clave para garantizar que las aplicaciones funcionen de forma consistente.

La calidad de servicio no es un elemento aislado, sino una característica integrada en la arquitectura de la red, diseñada desde el principio para soportar aplicaciones críticas.

SD-WAN aporta flexibilidad y capacidad de adaptación en entornos donde la conectividad ya no es homogénea ni estática. En lugar de depender de un único tipo de enlace, permite combinar múltiples accesos —como MPLS, fibra o internet— y gestionarlos de forma inteligente.

Uno de sus principales beneficios es la capacidad de tomar decisiones en tiempo real sobre por dónde enviar el tráfico. Esto permite optimizar el rendimiento, evitar enlaces degradados y adaptarse a cambios en la red sin intervención manual. En entornos dinámicos, donde las condiciones pueden variar rápidamente, esta capacidad resulta especialmente valiosa.

Además, simplifica la gestión de redes distribuidas. En lugar de configurar cada sede de forma independiente, SD-WAN permite aplicar políticas centralizadas, lo que reduce complejidad y mejora la coherencia operativa.

También contribuye a mejorar la resiliencia, ya que facilita el uso de múltiples enlaces y la conmutación automática en caso de fallo. En conjunto, SD-WAN no sustituye a otras tecnologías, sino que actúa como una capa de inteligencia que optimiza su uso.

El failover automático en SD-WAN se basa en la capacidad de detectar degradaciones o caídas en los enlaces y redirigir el tráfico de forma inmediata hacia rutas alternativas. Este proceso no depende de intervención manual, lo que permite mantener la continuidad del servicio incluso en situaciones de fallo.

Para ello, la solución monitoriza constantemente parámetros como latencia, pérdida de paquetes o disponibilidad de cada enlace. Cuando uno de estos parámetros supera los umbrales definidos, el sistema interpreta que el enlace no es adecuado para determinados tipos de tráfico y redirige automáticamente esos flujos.

La clave está en que el failover no se limita a detectar caídas completas. También puede actuar ante degradaciones parciales, moviendo tráfico crítico a enlaces más estables antes de que la calidad del servicio se vea afectada.

Este enfoque permite que la red sea mucho más resiliente, ya que no depende de un único camino ni de una reacción manual ante incidencias.

La selección de enlaces en tiempo real en entornos como SD-WAN se basa en una combinación de métricas técnicas y prioridades de negocio. No se trata sólo de elegir el enlace más rápido, sino el más adecuado para cada tipo de tráfico en cada momento.

Entre los criterios más relevantes están la latencia, la pérdida de paquetes y la estabilidad del enlace. Estos parámetros permiten evaluar si un camino es adecuado para aplicaciones sensibles como voz o vídeo. Sin embargo, también se tienen en cuenta políticas definidas por la organización, como priorizar ciertos servicios o utilizar determinados enlaces para tipos de tráfico específicos.

Además, el contexto operativo influye en la decisión. Un enlace puede ser adecuado en un momento determinado y no en otro, por lo que la selección debe ser dinámica. Esto es especialmente importante en entornos donde las condiciones de red cambian con frecuencia.

El resultado es una gestión del tráfico más eficiente, donde cada flujo utiliza el camino más adecuado en función de su criticidad y de las condiciones reales de la red.

La priorización de tráfico crítico se basa en identificar qué aplicaciones o servicios son esenciales para la operación y asegurar que reciben un tratamiento preferente dentro de la red. Esto se logra mediante mecanismos de calidad de servicio que clasifican el tráfico y le asignan distintos niveles de prioridad.

En la práctica, esto implica que, en situaciones de congestión, el tráfico crítico mantiene su rendimiento mientras que otros flujos menos sensibles pueden experimentar degradación. Por ejemplo, la voz o el acceso a sistemas de negocio deben mantenerse estables incluso si la red está saturada.

La clave está en definir correctamente qué se considera crítico. Si demasiados flujos se etiquetan como prioritarios, la eficacia del sistema disminuye. Por eso, la priorización debe ser selectiva y alineada con las necesidades reales del negocio.

Además, esta política debe aplicarse de forma coherente en toda la red, no sólo en un punto concreto, para garantizar que el tráfico mantiene su tratamiento preferente a lo largo de todo el recorrido.

La saturación de red afecta especialmente a aplicaciones sensibles al tiempo de respuesta, como VoIP, videoconferencia o sistemas interactivos. Cuando la red alcanza su capacidad, aumentan la latencia, el jitter y la pérdida de paquetes, lo que se traduce en cortes, retrasos o degradación de la experiencia.

A diferencia de otros tipos de tráfico, estas aplicaciones no toleran bien la variabilidad. Un pequeño aumento en la latencia o en la pérdida de paquetes puede tener un impacto significativo en su funcionamiento. Por eso, en entornos donde estas aplicaciones son críticas, la saturación no es sólo un problema de rendimiento, sino de operatividad.

La mitigación pasa por aplicar mecanismos de priorización, dimensionar correctamente la red y utilizar tecnologías que permitan distribuir el tráfico de forma eficiente. Sin estas medidas, la calidad de las aplicaciones más sensibles se ve comprometida en cuanto la red se acerca a su límite.
 

Diseñar una arquitectura de red resiliente implica asumir que los fallos van a ocurrir y preparar la infraestructura para que, cuando sucedan, el impacto sea mínimo. La resiliencia no consiste en evitar cualquier incidencia, sino en garantizar que la red sigue operativa a pesar de ellas.

Esto se logra combinando redundancia, diversidad de enlaces y capacidad de conmutación automática. No basta con tener un respaldo; es necesario que ese respaldo sea independiente y capaz de asumir la carga en caso de fallo del enlace principal.

También es importante integrar mecanismos de monitorización que permitan detectar problemas antes de que afecten al servicio y reaccionar de forma rápida. En entornos modernos, tecnologías como SD-WAN facilitan esta adaptación dinámica, mejorando la capacidad de respuesta ante cambios en la red. 

La automatización de redes distribuidas se basa en centralizar la definición de políticas y delegar en la infraestructura su ejecución automática. En lugar de configurar cada sede de forma independiente, se establecen reglas globales que se aplican de manera coherente en todo el entorno.

Tecnologías como SD-WAN facilitan este enfoque, permitiendo gestionar múltiples ubicaciones desde un punto central. Esto incluye la configuración de enlaces, la priorización de tráfico, la seguridad y la respuesta ante incidencias. La red deja de depender de configuraciones manuales y pasa a operar según políticas definidas previamente.

Además, la automatización permite reaccionar en tiempo real a cambios en las condiciones de red. Por ejemplo, si un enlace se degrada, el sistema puede redirigir el tráfico automáticamente sin necesidad de intervención humana.

Este enfoque no sólo reduce la complejidad operativa, sino que también mejora la consistencia y la capacidad de respuesta ante incidencias. 

La monitorización en tiempo real del estado de la red se basa en obtener visibilidad continua sobre su funcionamiento, no sólo en términos de disponibilidad, sino también de calidad y comportamiento. No basta con saber si un enlace está activo; es necesario entender cómo está respondiendo en cada momento.

En la práctica, esto implica recoger métricas como latencia, pérdida de paquetes, jitter, ocupación de enlaces y estabilidad de las conexiones. Estas variables permiten detectar degradaciones antes de que se traduzcan en problemas visibles para las personas usuarias. Además, la monitorización debe abarcar todos los puntos de la red: sedes, enlaces, accesos a cloud y tráfico interno.

El valor real aparece cuando esta información se analiza de forma continua y se compara con patrones normales de funcionamiento. De este modo, es posible identificar desviaciones y anticiparse a fallos. En arquitecturas modernas, esta visibilidad suele integrarse con sistemas de alerta y automatización, que permiten actuar sin esperar a que el problema escale. 

La falta de centralización en la gestión de red introduce riesgos relacionados con la inconsistencia, la falta de visibilidad y la dificultad para responder de forma coordinada ante incidencias. Cuando cada parte de la red se gestiona de forma independiente, es más fácil que aparezcan configuraciones incoherentes o desalineadas.

Esto puede traducirse en problemas de seguridad, ya que políticas diferentes en distintas sedes pueden abrir brechas no previstas. También dificulta la monitorización, porque la información está fragmentada y no permite tener una visión global del estado de la red.

Además, la respuesta ante incidencias se vuelve más lenta y compleja. Sin un punto central de control, identificar el origen de un problema o aplicar una solución de forma coordinada resulta mucho más difícil.

En entornos distribuidos, la centralización no es sólo una cuestión de eficiencia, sino un elemento clave para mantener el control y la coherencia de la infraestructura.

Resumen gráfico de nuestras tertulias de industria 4.0

La guía de smart city para administraciones locales