Diferencia entre revisiones de «Privado: Seguridad de transmisión»

De PiTemp 2.0
Ir a la navegación Ir a la búsqueda
← Edición anterior
VisualWikitexto
 
Línea 7: Línea 7:


== 2. Alcance ==
== 2. Alcance ==
Este ensayo cubre la transmisión de datos desde el origen de la medición hasta su almacenamiento y visualización:
 
* Enlace '''sensor → puerta de enlace''' (cifrado propio del protocolo AES-128 CCM*).
Aplica a todas las capas de comunicación que intervienen en la transmisión de datos de temperatura:
* Enlace '''gateway → servidor local''' (MQTT cifrado).
 
* Enlace '''servidor local → servidor central PiTemp 2.0''' (TLS cifrado).
* Sensor inalámbrico → puerta de enlace Zigbee
* Comunicación '''servidor → base de datos PostgreSQL'''.
* Puerta de enlace → servidor local (MQTT sobre TLS)
* Acceso remoto a los paneles y APIs web de PiTemp 2.0 (HTTPS).
* Servidor local → servidor central PiTemp 2.0 (TLS)
* Servidor central → base de datos
* Acceso remoto a la interfaz web y API (HTTPS)


== 3. Descripción general ==
== 3. Descripción general ==
El sistema PiTemp 2.0 emplea mecanismos de cifrado y autenticación que garantizan:
PiTemp 2.0 emplea protocolos y mecanismos de seguridad reconocidos que garantizan:
* '''Confidencialidad:''' los datos transmitidos no pueden ser interpretados por terceros.
 
* '''Integridad:''' cualquier alteración en tránsito es detectable.
* '''Confidencialidad:''' los datos viajan cifrados extremo a extremo.
* '''Autenticación:''' solo dispositivos y servidores autorizados pueden participar en la comunicación.
* '''Integridad:''' cada mensaje está firmado digitalmente mediante hash SHA-256.
* '''No repudio:''' cada mensaje firmado digitalmente conserva trazabilidad hasta el origen.
* '''Autenticación:''' solo dispositivos y servidores autorizados pueden intercambiar datos.
* '''No repudio:''' las firmas y marcas temporales aseguran la trazabilidad completa.


== 4. Procedimiento de verificación ==
== 4. Procedimiento de verificación ==
* '''Verificación de cifrado punto a punto'''
* '''Capa Zigbee (sensores)''' Los sensores inalámbricos emplean el estándar '''Zigbee 3.0''', basado en '''IEEE 802.15.4''', que utiliza cifrado '''AES-128 CCM*''' para todas las tramas de datos.  La autenticación y el intercambio de claves se realizan mediante emparejamiento seguro (''link key'').  Por diseño del protocolo, no es posible la transmisión de datos en texto plano.<blockquote>Referencias técnicas: [https://standards.ieee.org/standard/802_15_4-2020.html IEEE 802.15.4-2020], [https://csa-iot.org/all-solutions/zigbee/ Zigbee 3.0 Security Architecture]</blockquote>'''Capa de transporte (MQTT, API, base de datos)'''
  * Se capturan y analizan tramas de comunicación entre sensor y gateway Zigbee, confirmando el uso de cifrado AES-128 interno al protocolo.
** Todas las conexiones utilizan '''TLS 1.2 o superior'''.
  * Se inspecciona la conexión MQTT para confirmar el uso de certificados y cifrado TLS 1.2 o superior.
** Los certificados son emitidos por la '''CA interna 3innova''' o por una autoridad de confianza.
  * Se revisan los parámetros de seguridad del servidor (puertos, certificados, protocolos habilitados).
** Las claves privadas se almacenan de forma segura en el servidor local.
** Los intentos de conexión no autenticados se rechazan y registran.  '''Verificación automática de integridad'''  Cada registro transmitido se asocia a una firma '''SHA-256'''.  El proceso diario de auditoría comprueba que los valores almacenados coinciden con los originales en los logs firmados, detectando cualquier alteración.


* '''Validación de certificados'''
== 5. Criterios de aceptación ==
  * Todos los certificados TLS están emitidos por una autoridad de confianza o por la CA interna 3innova.
  * Las conexiones cifradas emplean '''firmas digitales X9.62 ECDSA con SHA-384''', equivalentes a un nivel de seguridad ≥ RSA-3072.
  * Se comprueba la validez temporal, la integridad de la cadena de confianza y la ausencia de algoritmos obsoletos.
  * La caducidad y renovación de certificados se controlan mediante alertas automáticas.


* '''Verificación de integridad de datos'''
* Todas las comunicaciones activas deben emplear '''TLS 1.2+ o AES-128 CCM*'''.
  * Se comprueba que los mensajes firmados (hash SHA-256) coinciden en origen y destino.
* Los certificados deben ser válidos y vigentes.
  * Cualquier discrepancia genera alerta y se registra como incidente.
* Ninguna transmisión de datos en texto plano.


== 5. Criterios de aceptación ==
* Coincidencia del '''100 % de hashes''' entre los datos firmados y los registros almacenados.
* Todas las comunicaciones activas deben emplear '''cifrado TLS 1.2+''' o '''AES-128''' (según capa). 
* Los certificados deben ser válidos, no caducados y emitidos por autoridad reconocida o CA interna 3innova. 
* No debe existir transmisión de datos en texto plano en ningún punto de la cadena. 
* Los intentos de conexión no autenticados deben ser rechazados y registrados. 
* Coincidencia del 100% de hashes en origen y destino durante el ensayo.


== 6. Evidencias generadas ==
== 6. Evidencias generadas ==
* Declaración de conformidad de seguridad de transmisión (protocolo Zigbee 3.0, MQTT over TLS 1.2+).
* Registro de configuración del sistema (confirmación de cifrado y autenticación activa).
* Listado de certificados TLS vigentes (firma ECDSA-SHA-384 y fechas de caducidad).
* Informe firmado por el responsable técnico de 3innova confirmando el uso de protocolos seguros.


== 7. Gestión de no conformidades ==
* Declaración de conformidad de seguridad Zigbee 3.0 / IEEE 802.15.4.
* Comunicación no cifrada: bloqueo inmediato del canal y registro de incidencia.
* Registro de configuración TLS y certificados activos.
* Certificado caducado o inválido: sustitución y reinstalación en menos de 24 h.
* Informes automáticos de verificación de integridad (hash SHA-256).
* Fallo de autenticación de dispositivo: aislamiento del nodo y reproceso de emparejamiento seguro.
* Discrepancia de hash: investigación de causa raíz (posible retransmisión o alteración).


== 8. Periodicidad de ensayo ==
* Logs de conexión y autenticación de servidores.
* Ensayo completo: anual, o tras actualización de firmware o renovación de certificados.
* Verificación automática: comprobación diaria del estado y caducidad de certificados.
* Monitoreo continuo: detección en tiempo real de intentos de conexión no cifrada.


== 9. Conclusión ==
== 7. Conclusión ==
El sistema PiTemp 2.0 garantiza la seguridad de la transmisión mediante cifrado extremo a extremo, autenticación de dispositivos y validación continua de integridad.   
El sistema PiTemp 2.0 garantiza la '''seguridad de transmisión''' mediante cifrado extremo a extremo, autenticación de dispositivos y verificación diaria de integridad de datos.   


Este ensayo demuestra el cumplimiento de los requisitos de seguridad de datos establecidos en el Apéndice II del Anexo XI de la Orden ICT/155/2020.
Esto demuestra conformidad con los requisitos de seguridad del ''Apéndice II del Anexo XI'' de la '''Orden ICT/155/2020'''.

Revisión actual - 11:24 23 oct 2025

Privado: Seguridad de transmisión

1. Objeto

Verificar que las comunicaciones entre los distintos componentes del sistema PiTemp 2.0 (sensores, puertas de enlace, servidores y bases de datos) se realizan de forma segura, confidencial y protegida frente a interceptación o manipulación.

Este método de ensayo está asociado al punto 3 — Seguridad de Transmisión del Plan de Ensayos de Software PiTemp 2.0.

2. Alcance

Aplica a todas las capas de comunicación que intervienen en la transmisión de datos de temperatura:

  • Sensor inalámbrico → puerta de enlace Zigbee
  • Puerta de enlace → servidor local (MQTT sobre TLS)
  • Servidor local → servidor central PiTemp 2.0 (TLS)
  • Servidor central → base de datos
  • Acceso remoto a la interfaz web y API (HTTPS)

3. Descripción general

PiTemp 2.0 emplea protocolos y mecanismos de seguridad reconocidos que garantizan:

  • Confidencialidad: los datos viajan cifrados extremo a extremo.
  • Integridad: cada mensaje está firmado digitalmente mediante hash SHA-256.
  • Autenticación: solo dispositivos y servidores autorizados pueden intercambiar datos.
  • No repudio: las firmas y marcas temporales aseguran la trazabilidad completa.

4. Procedimiento de verificación

  • Capa Zigbee (sensores) Los sensores inalámbricos emplean el estándar Zigbee 3.0, basado en IEEE 802.15.4, que utiliza cifrado AES-128 CCM* para todas las tramas de datos. La autenticación y el intercambio de claves se realizan mediante emparejamiento seguro (link key). Por diseño del protocolo, no es posible la transmisión de datos en texto plano.

    Referencias técnicas: IEEE 802.15.4-2020, Zigbee 3.0 Security Architecture

    Capa de transporte (MQTT, API, base de datos)
    • Todas las conexiones utilizan TLS 1.2 o superior.
    • Los certificados son emitidos por la CA interna 3innova o por una autoridad de confianza.
    • Las claves privadas se almacenan de forma segura en el servidor local.
    • Los intentos de conexión no autenticados se rechazan y registran. Verificación automática de integridad Cada registro transmitido se asocia a una firma SHA-256. El proceso diario de auditoría comprueba que los valores almacenados coinciden con los originales en los logs firmados, detectando cualquier alteración.

5. Criterios de aceptación

  • Todas las comunicaciones activas deben emplear TLS 1.2+ o AES-128 CCM*.
  • Los certificados deben ser válidos y vigentes.
  • Ninguna transmisión de datos en texto plano.
  • Coincidencia del 100 % de hashes entre los datos firmados y los registros almacenados.

6. Evidencias generadas

  • Declaración de conformidad de seguridad Zigbee 3.0 / IEEE 802.15.4.
  • Registro de configuración TLS y certificados activos.
  • Informes automáticos de verificación de integridad (hash SHA-256).
  • Logs de conexión y autenticación de servidores.

7. Conclusión

El sistema PiTemp 2.0 garantiza la seguridad de transmisión mediante cifrado extremo a extremo, autenticación de dispositivos y verificación diaria de integridad de datos.

Esto demuestra conformidad con los requisitos de seguridad del Apéndice II del Anexo XI de la Orden ICT/155/2020.

Obtenido de «https://clientes.3innova.io/index.php?title=Privado:_Seguridad_de_transmisión&oldid=92»