Foto: Brett Sayles · Fuente original · Pexels License. Redimensionado para web, sin alterar el contenido. No implica respaldo del autor ni del fabricante.
Segmentar la red de RFID, etiquetas electrónicas y PDA significa darles su propio espacio de red con reglas explícitas: qué dispositivo habla con qué servidor, en qué puertos y con qué autenticación, y nada más. La base es el mínimo privilegio. Pide al proveedor un inventario de flujos, protocolos y puertos, verifica cifrado y gestión de credenciales, y prueba que un dispositivo comprometido o mal configurado no alcance sistemas de caja o corporativos. La segmentación reduce riesgo, no lo elimina.
Premisa: cada dispositivo debe poder hacer solo lo que necesita
Los lectores RFID, las bases de etiquetas electrónicas y las PDA industriales son equipos con sistema operativo, firmware y credenciales. Muchas veces se instalan con prisa en la misma red que las cajas registradoras o los equipos administrativos porque “ya hay cable”. Esa comodidad convierte cualquier fallo de un dispositivo en un riesgo para toda la red.
La idea de fondo es el mínimo privilegio: cada dispositivo debe tener acceso únicamente a los destinos y puertos que su función requiere. Para llegar a eso necesitas saber qué habla con qué, algo que el proveedor debería poder documentarte antes de la instalación.
El documento NIST SP 800-213 propone partir del contexto del sistema para definir qué capacidades de ciberseguridad se esperan de un dispositivo IoT y de su fabricante. Úsalo como marco para tus preguntas, sin interpretarlo como una certificación de ningún producto.
Primero el inventario de flujos
Pide al proveedor, por escrito, una tabla de flujos para cada tipo de dispositivo. Sin ella no se puede escribir una regla de firewall que se pueda defender.
| Dispositivo | Habla con | Dirección y protocolo | Pregunta para TI |
|---|---|---|---|
| Lector RFID fijo | Middleware o servidor de aplicación | Salida desde el lector, o conexión entrante al lector | ¿Quién inicia la conexión y puede cerrarse la entrante? |
| Base o punto de acceso ESL | Plataforma de gestión (local o nube) | Normalmente hacia plataforma; puertos y protocolos según fabricante | ¿Qué dominios o IP necesita y es posible fijarlos? |
| PDA industrial | Wi‑Fi, MDM, WMS, servicio de actualizaciones | Varios destinos | ¿Qué se bloquea sin romper actualizaciones críticas? |
| Impresora de etiquetas | Servidor de impresión o PDA | Puertos de impresión y administración | ¿Se puede deshabilitar la administración remota? |
Los protocolos y puertos exactos dependen de cada fabricante y modelo; esta tabla es una plantilla de preguntas, no una lista de requisitos de ningún producto.
Decisiones de diseño que debes poder explicar
- Segmento propio. Separa los dispositivos de captura de la red de punto de venta y de la corporativa, con reglas entre segmentos.
- Reglas de salida y entrada. Permite solo los destinos documentados; revisa por qué un dispositivo necesitaría acceso a Internet abierto.
- Cifrado en tránsito. Pregunta qué canales usan TLS u otro cifrado, cómo se validan certificados y qué ocurre cuando vencen.
- Administración. Quién puede entrar a la consola del dispositivo, desde qué segmento y con qué método de autenticación; evita credenciales compartidas.
- Actualizaciones. Cómo recibe firmware y parches y cómo se prueban antes de desplegar.
Cada punto debe tener un responsable. Si “el proveedor lo gestiona”, aclara su acceso: quién lo concede, cómo se revoca y cómo queda registrado.
Qué pedir y cómo validar lo que el proveedor afirme
Una afirmación como “el sistema es seguro” no es verificable. Pide evidencias específicas: documento de arquitectura de red, lista de puertos y servicios abiertos, método de autenticación de cada interfaz, política de gestión de vulnerabilidades y de parches, y cómo se cambian las credenciales por defecto. Después valida lo que puedas en un entorno de prueba: comprueba que los puertos documentados son los únicos abiertos, que las credenciales de fábrica ya no funcionan y que el dispositivo falla de manera controlada si no hay acceso a un destino.
Para el registro de actividad, la hoja de OWASP sobre logging recomienda registrar fallos de autenticación, cambios de configuración y errores de conexión, y proteger los registros del acceso no autorizado. Pregunta qué registra cada dispositivo y adónde envía esos registros. La guía NIST SP 800-92 sobre gestión de registros ofrece un marco general para organizarlos.
Ejemplo hipotético: tienda con ESL, RFID y cajas
Ejemplo ilustrativo, no es un diseño certificado. Una tienda tiene tres segmentos: cajas, administración y un segmento nuevo para dispositivos de captura. En él caben las bases de etiquetas electrónicas, dos lectores RFID y las PDA. Las reglas permiten que las bases hablen solo con la plataforma de gestión documentada, que los lectores se comuniquen con el servidor de aplicación y que las PDA lleguen al WMS y al MDM. Las cajas no pueden iniciar conexiones hacia el segmento de captura, y viceversa.
En la prueba de aceptación, TI conecta un portátil de prueba al segmento de captura e intenta alcanzar una caja y el servidor administrativo; ambos intentos deben fallar y quedar registrados. Si alguno funciona, la regla está mal y se corrige antes de operar.
Límites de la segmentación
Segmentar no protege contra credenciales débiles, firmware con vulnerabilidades ni errores humanos. Tampoco reemplaza el monitoreo: sin registros nadie sabrá si una regla se está violando. Además, las reglas envejecen: cada actualización del proveedor o cada tienda nueva puede añadir flujos que nadie documentó. Programa una revisión periódica de reglas con el responsable de TI y registra los cambios.
Considera también la parte no técnica: quién puede conectar un lector nuevo, quién autoriza abrir un puerto y qué pasa cuando un proveedor pide acceso remoto temporal. Una política escrita con responsables nombrados evita decisiones improvisadas durante una urgencia.
Siguiente paso
Pide al proveedor la tabla de flujos de cada dispositivo y revísala con tu equipo de seguridad antes de la instalación; es el documento que más ahorra discusiones. Para aclarar qué equipos y conexiones intervienen en tu proyecto, puedes escribir a ARKCOM en garkcom.com/contact.
Fuentes y alcance
- NIST SP 800-213 IoT Device Cybersecurity Guidance for the Federal Government · NIST CSRC
Marco NIST para requisitos de ciberseguridad de dispositivos IoT (solo resumen revisado) - Logging Cheat Sheet · OWASP Cheat Sheet Series
Guía de registro de eventos: campos, datos a excluir, protección - NIST SP 800-92 Guide to Computer Security Log Management · NIST CSRC
Marco general de gestión de registros de seguridad (solo resumen revisado)
Artículo informativo preparado con apoyo de IA. No constituye una cotización, garantía de desempeño ni validación de compatibilidad. Confirma las especificaciones vigentes con el fabricante y valida tu caso con una prueba. Conoce el criterio editorial.
Las referencias respaldan aspectos concretos, no una garantía de resultados ni la vigencia de todas las condiciones descritas. Los ejemplos y listas de verificación orientan la evaluación; no sustituyen asesoría técnica o jurídica para tu caso. Las fotografías son ilustrativas: no acreditan clientes, instalaciones ni proyectos de ARKCOM, ni implican respaldo de marcas o personas. Los precios visibles no son cotizaciones para México.
¿Qué necesita tu operación?
Comparte tu proceso, volumen y sistemas actuales para iniciar la conversación.
Contactar a ARKCOM