IoT sin IT: cómo gestionar infraestructura rogue cuando Operaciones actúa solo

El email que todo equipo IT acaba recibiendo

Llega un correo de Operaciones. Tono amable, mensaje directo: necesitan acceso al router para poner en marcha el nuevo sistema de contadores de energía. Ya está todo contratado, el proveedor lleva semanas trabajando en la instalación y el proyecto tiene visibilidad en dirección. Solo falta ese pequeño detalle.

Ese pequeño detalle es, literalmente, la puerta de entrada a la red corporativa.

Lo que describe esa petición —en su brevedad— dice mucho: no ha habido revisión de arquitectura, no hay documentación del sistema, no se conoce qué protocolos usan los dispositivos, cómo se comunican entre sí, qué endpoints remotos contactan ni quién tiene acceso administrativo al servidor del proveedor. Alguien firmó un contrato y espera que IT ejecute sin preguntar. Y cuando IT hace preguntas, IT se convierte en el obstáculo.

Este artículo va sobre cómo salir de esa trampa: técnicamente y organizativamente.

Primero, lo que no vas a hacer

No vas a dar acceso administrativo al router corporativo a un proveedor externo. Punto. No importa cuánta presión venga de arriba, no importa que el contrato ya esté firmado. Conceder ese acceso no es solo un riesgo técnico: es asumir responsabilidad directa sobre todo lo que pase después.

Tampoco vas a conectar dispositivos IoT industriales de origen desconocido directamente a la red de producción. No porque quieras bloquear el proyecto, sino porque esos dispositivos no tienen inventario de seguridad validado, no sabes si su firmware está parcheado, no conoces sus certificados TLS ni si los tienen, y no existe ningún procedimiento documentado de respuesta a incidentes si algo falla.

Pero tampoco vas a decir simplemente que no. Porque eso no resuelve nada y convierte a IT en el departamento que frena el negocio.

La solución técnica: VLAN dedicada con control estricto de egreso

La respuesta técnica a este problema tiene nombre concreto: segmentación de red mediante VLAN específica para IoT, completamente aislada de la red corporativa y de la red OT de producción.

La lógica es simple. Los dispositivos IoT necesitan comunicarse: entre ellos, con un servidor local o en la nube, y posiblemente recibir actualizaciones de firmware. Ese tráfico puede existir en un segmento completamente controlado sin tocar nunca la red donde viven los sistemas críticos de la empresa.

Qué incluye una arquitectura mínima viable

• VLAN dedicada para IoT: los contadores y cualquier dispositivo del sistema viven aquí. Sin acceso lateral hacia otras VLANs, sin visibilidad de la red corporativa.
• Firewall con reglas de egreso explícitas: si el sistema solo necesita comunicarse con el servidor del proveedor en la nube, se permite exactamente eso —IP o dominio específico, puerto concreto— y se deniega y registra todo lo demás. Todo lo demás.
• Throttling de ancho de banda: los dispositivos IoT no deberían poder saturar el enlace de internet corporativo. Un límite razonable evita que un fallo de firmware o un comportamiento anómalo impacte al resto de la operación.
• Logging activo: cualquier comunicación fuera de los endpoints autorizados genera una alerta. Si un contador de energía intenta contactar una IP desconocida a las 3 de la mañana, quieres saberlo.
• Acceso remoto del proveedor por VPN controlada: si el proveedor necesita acceso para mantenimiento o soporte, ese acceso se gestiona mediante una VPN dedicada con autenticación fuerte, acceso con privilegios mínimos y registro de sesión. No con credenciales compartidas al router.

Esta arquitectura no es cara. Requiere switches gestionados —que probablemente ya existen en una fábrica mediana—, configuración firewall y tiempo de un técnico. El coste es bajo. La alternativa, un incidente de seguridad en red de producción, puede paralizar la fábrica días o semanas.

La separación IT/OT no es opcional ni negociable

Hay un principio que en entornos industriales debería estar grabado en piedra: la red IT y la red OT deben mantenerse separadas. Siempre.

La red IT es la corporativa: correo, ERP, ficheros, comunicaciones. La red OT es la operativa: PLCs, sensores, sistemas SCADA, maquinaria de producción. Un compromiso en la red IT puede ser grave. Un compromiso en la red OT puede parar físicamente una fábrica, dañar equipos o, en entornos críticos, poner en riesgo personas.

Los contadores de energía IoT son, por su naturaleza, sistemas OT o adyacentes a OT. No pertenecen a la red corporativa ni a la red de producción activa. Pertenecen a su propio segmento, con sus propias reglas.

Cualquier proveedor serio que trabaje con infraestructura industrial debería entender esto. Si el proveedor que Operaciones contrató no lo plantea así desde el principio, eso ya dice algo sobre cómo aborda la seguridad de sus clientes.

El problema real: change management que no existe

Aquí es donde hay que ser honesto. La situación de Operaciones firmando un contrato de infraestructura sin pasar por IT no es un problema técnico. Es un problema de gobernanza.

Si existiera un proceso formal de gestión del cambio —un comité que incluya IT, Operaciones y Seguridad antes de que cualquier proyecto con implicaciones de red avance—, este escenario no habría ocurrido. Operaciones tiene razón en sus necesidades: mejorar la eficiencia energética, tener visibilidad del consumo en planta, optimizar costes. Eso es legítimo y valioso. El problema no es que hayan buscado una solución. El problema es que lo hicieron en silo.

La conversación que hay que tener no es solo técnica. Es con dirección, y debe plantear algo concreto: necesitamos un proceso que garantice que cualquier decisión con impacto en infraestructura pase por una revisión conjunta antes de firmar contratos. No para frenar proyectos, sino para que lleguen a producción sin sorpresas.

Mientras tanto, la situación actual no desaparece. Hay que gestionarla con lo que hay.

Cómo escalar sin ser el villano

Hay una distinción importante que algunos profesionales de IT aprenden a las malas: tu trabajo es proporcionar información técnica precisa sobre los riesgos. La decisión sobre si asumir esos riesgos corresponde a dirección.

Eso cambia completamente el encuadre de la conversación. En lugar de bloquear el proyecto, IT documenta y eleva:

• Los riesgos específicos identificados: proveedor con acceso remoto no auditado, dispositivos sin inventario de seguridad validado, ausencia de políticas de parches documentadas, falta de certificados SSL/TLS verificados.
• Los requisitos mínimos para proceder con seguridad: VLAN dedicada, reglas de firewall, acuerdo de acceso remoto firmado, revisión de arquitectura con el proveedor.
• Una estimación del coste de implementar correctamente frente al coste potencial de un incidente.

Y sobre este último punto hay una postura que tiene mucho sentido en la práctica: si IT gestiona activamente esa conexión, IT asume responsabilidad sobre los fallos que ocurran detrás de ella. Si Operaciones quiere gestionar su propio acceso de forma independiente, que firmen que son ellos quienes controlan completamente quién usa esa infraestructura y bajo qué condiciones. Esa frase, trasladada a un documento formal, suele aclarar bastante rápido quién quiere realmente asumir qué.

RGPD, NIS2 y lo que no es opcional

Antes de que el sistema entre en producción, hay pasos que no son sugerencias. Son cumplimiento normativo.

DPIA (Evaluación de Impacto de Protección de Datos): si los contadores de energía recogen datos que puedan vincularse a personas —patrones de presencia, actividad de trabajadores—, el RGPD exige una evaluación formal antes de poner el sistema en marcha. Una brecha en ese contexto no es solo un problema técnico: es una auditoría de la Agencia Española de Protección de Datos y multas que pueden alcanzar los 20 millones de euros.

NIS2: si la empresa opera en sectores considerados infraestructura crítica o relevante, la Directiva NIS2 ya ha transpuesto obligaciones de gestión de riesgos en cadena de suministro, notificación de incidentes y responsabilidad de dirección. Un proveedor IoT sin auditoría de seguridad encaja perfectamente en el tipo de riesgo que NIS2 busca controlar.

Revisión de arquitectura con el proveedor: no como cortesía, sino como condición para continuar. Cualquier proveedor que no pueda documentar qué puertos usa, qué datos envía y a dónde, cómo gestiona credenciales y qué plan tiene ante una brecha, no está listo para operar en una red industrial.

Las tres preguntas que nadie está haciendo todavía

Hay aspectos que en el calor del momento —con el proyecto atrasado y Operaciones presionando— quedan fuera de la conversación. Pero son exactamente los que determinan si esto acaba bien o mal.

¿Quién es responsable si un dispositivo en esa VLAN se compromete y lanza ataques internos? La segmentación reduce el radio de explosión, pero no lo elimina. Si un contador infectado empieza a hacer reconocimiento lateral o actúa como punto de pivote, necesitas tener claro de antemano quién investiga, quién decide aislar y quién comunica a dirección. Eso no se improvisa en el momento del incidente.

¿Cómo se audita qué datos está extrayendo el proveedor y a dónde van? Los logs de egreso te dicen a qué IPs se conectan los dispositivos. Pero no te dicen qué datos se envían en esas conexiones. Si el contrato no especifica con precisión qué datos recoge el proveedor, dónde los almacena, por cuánto tiempo y bajo qué condiciones los cede a terceros, tienes un problema de RGPD que existe independientemente de lo bien que hayas configurado el firewall.

¿Qué pasa si el servidor del proveedor cae durante producción crítica? Si el sistema de contadores depende de conectividad con la nube para funcionar —y muchos diseños IoT actuales lo hacen—, un fallo del proveedor puede dejarte sin visibilidad energética en el peor momento. ¿Hay modo local? ¿Existe un SLA con penalización? ¿Hay un plan de contingencia documentado? Si nadie ha preguntado esto antes de firmar, hay que preguntarlo ahora.

El coste de hacerlo mal frente al coste de hacerlo bien

Una fábrica con infraestructura IoT comprometida puede enfrentarse a escenarios muy concretos: sabotaje de sistemas de control de producción, extracción de datos de consumo que revelen información competitiva sensible, uso de la infraestructura de la empresa para atacar a terceros —con la responsabilidad legal que eso conlleva—, o simplemente un corte de servicio en el peor momento posible.

Frente a eso, implementar correctamente la arquitectura descrita —VLAN, firewall con egress control, VPN para acceso remoto, logging— tiene un coste bajo, especialmente en una instalación donde ya existe infraestructura de red gestionada. No es un proyecto nuevo. Es configuración inteligente de lo que ya hay.

Además, si se aprovecha el momento para establecer formalmente ese comité de cambios —IT, Operaciones, Seguridad— que revise proyectos con implicaciones de infraestructura antes de que lleguen a contrato, el retorno se multiplica. No solo en este proyecto, sino en todos los que vengan después.

Ni el primero ni el último

Este escenario —Operaciones comprando tecnología sin consultar a IT, luego pidiendo que IT lo conecte sin hacer preguntas— no es nuevo. Ocurre constantemente en empresas de todos los tamaños, y la tendencia se acelera a medida que el hardware industrial se vuelve más accesible y los proveedores venden directamente a responsables de planta o de mantenimiento sin pasar por infraestructura.

La respuesta no es endurecer el control de IT hasta la parálisis. Es crear los procesos que permiten a Operaciones moverse rápido y a IT garantizar que lo que se conecta a la red no supone un riesgo que nadie ha evaluado. Eso requiere que alguien en dirección entienda que un sysadmin que hace preguntas no está obstaculizando el proyecto: está haciendo exactamente su trabajo.

Si en tu empresa este tipo de decisiones se toman todavía en silo, quizás este proyecto es la ocasión para plantear cómo debería funcionar el proceso la próxima vez.