Capítulo 31 — Seguridad de TO, IoT y sistemas ciberfísicos: implementación II
Mapa de la lección
Lección 31 publicada. Mapa, ejemplo, EX091.
flowchart TD
N0["Resultados de aprendizaje"]
N1["31.1 Inserción o actualización"]
N2["31.2 Validar en la escritura"]
N3["31.3 Versionado de la API"]
N4["Nota práctica"]
N5["31.1b Actualizaciones parciales y concurrencia"]
N6["Nota de campo: incidente de importación masiva"]
N7["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX091"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje"]
N1["31.1 Inserción o actualización"]
N2["31.2 Validar en la escritura"]
N3["31.3 Versionado de la API"]
N4["Nota práctica"]
N5["31.1b Actualizaciones parciales y concurrencia"]
N6["Nota de campo: incidente de importación masiva"]
N7["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX091"]
[Resultados de aprendizaje]
|
v
[31.1 Inserción o actualización]
|
v
[31.2 Validar en la escritura]
|
v
[31.3 Versionado de la API]
|
v
[Nota práctica]
|
v
[31.1b Actualizaciones parciales y concurrencia]
|
v
[Nota de campo: incidente de importación masiva]
|
v
[Síntesis del capítulo]
|
v
[Ejemplo resuelto] --> [Ejercicio EX091]
Resultados de aprendizaje
Usted podrá (1) añadir inserciones o actualizaciones idempotentes de hallazgos; (2) aplicar la validación del esquema en la escritura; (3) versionar las respuestas de la API de las herramientas del CNHP.
31.1 Inserción o actualización
La API de hallazgos del CNHP recibe PUT /findings/{id} con el cuerpo completo, de modo que el mismo id enviado dos veces produce una sola fila. En ABP, los identificadores de los hallazgos los genera el cliente al crearlos y se reutilizan en cada reintento, de modo que un fallo de red a mitad de la solicitud no puede crear un duplicado. Las huellas sugieren cuándo dos hallazgos pueden ser el mismo problema, pero una persona confirma cualquier fusión, porque dos hallazgos sobre el PLC-A pueden compartir un registro y tener aun así causas distintas. Las fusiones se registran con sus motivos.
31.2 Validar en la escritura
Rechace los campos desconocidos y los nombres prohibidos; fuerce la severidad a través de una enumeración. Los errores de validación devuelven códigos legibles por máquina. El almacén de hallazgos de Lena en ABP rechaza cualquier registro con un campo desconocido o un nombre prohibido, como payload o password, y devuelve un código que indica qué campo falló. La severidad solo acepta los valores acordados. El mismo validador se ejecuta en las creaciones interactivas y en las importaciones masivas, de modo que ninguna vía de entrada goza de más confianza que otra, y una importación de un escáner que envía risk_score se rechaza con el mismo código que el cliente móvil. Los errores se documentan con ejemplos.
31.3 Versionado de la API
Prefijo /v1/; dentro de v1, solo cambios aditivos. Los cambios incompatibles requieren /v2/ y una nota de migración.
Caso sintético — Ashford Batch Plant. Un cliente móvil envió risk_score; el validador lo rechazó: las puntuaciones vacías se quedan fuera (capítulo 15).
La API de Lena para ABP se ha mantenido en v1 hasta ahora. Lena publica la regla de cambios aditivos en la documentación de la API, y la integración continua compara cada esquema nuevo con la última versión para detectar campos eliminados o renombrados. Si alguna vez fuera necesario un cambio incompatible, v1 seguiría funcionando junto a v2 durante un periodo anunciado, para que los clientes móviles y las importaciones de escáneres puedan migrar sin fallar en mitad de una ventana.
31.4 Errores y límites
Las claves de idempotencia no deben derivarse solo de la hora del reloj. Una clave de idempotencia construida a partir de la hora actual cambia entre reintentos, así que cada reintento parece una solicitud nueva y crea un duplicado. Los clientes de Lena generan la clave una vez por operación lógica, la guardan con la solicitud pendiente y la reutilizan hasta que el servidor confirma el éxito. La regla se documenta con la API y las bibliotecas cliente la aplican, de modo que ningún desarrollador puede reintroducir el atajo basado en la hora. Las revisiones comprueban esta regla de forma explícita.
Nota práctica
La importación masiva desde escáneres debe pasar la misma validación de esquema que la creación interactiva, incluidas las comprobaciones de campos prohibidos.
31.1b Actualizaciones parciales y concurrencia
Un PATCH que permite cambiar la severidad sin referencias a la evidencia invita a rebajas silenciosas. Para los hallazgos del CNHP, prefiera un PUT completo del cuerpo validado, o un PATCH restringido que no pueda borrar los hashes de las capturas del monitor. Use ETags para que dos personas que corrigen no se pisen. Un cambio de estado a cerrado solo se acepta cuando la misma solicitud lleva un puntero a una nueva prueba. Los borrados masivos están prohibidos sin doble control. Documente la semántica de inserción o actualización en OpenAPI para que los clientes móviles no inventen identificadores de reintento.
Las ETags son obligatorias en cada actualización de un hallazgo.
Nota de campo: incidente de importación masiva
Una vía de importación de escáneres se saltaba las comprobaciones de campos prohibidos porque se consideraba de confianza. El campo de notas de alguien contenía una contraseña. Tras limpiarla y rotarla, la importación masiva se reconectó a través del mismo validador que la creación interactiva. La importación de confianza es la forma en que las cargas útiles entran en los almacenes sellados.
Los clientes que omiten el identificador del hallazgo al crearlo reciben un 400 con un enlace a la documentación de inserción o actualización, para que los reintentos no puedan inventar duplicados por accidente.
31.5 Ejemplo resuelto: inserción o actualización idempotente de registros de activos (ABP sintética)
Dos fuentes de inventario informan sobre el PLC-A: la exportación del proyecto de ingeniería y el descubrimiento pasivo en la red. La inserción o actualización de Lena se indexa por (sitio, etiqueta del activo), no por dirección IP, porque la IP cambia cuando se sustituye un controlador. Cada escritura lleva la fuente y una hora de observación; una observación posterior actualiza la versión del firmware solo si su fuente es autoritativa para ese campo (la exportación del proyecto gana para el firmware; el descubrimiento gana para «visto por última vez»). Reproducir dos veces la misma importación no produce ningún cambio: es la prueba que demuestra la idempotencia. Sin estas reglas, una importación masiva sobrescribió una vez el campo de firmware del PLC-A con «unknown» y lo ocultó a una comprobación de avisos de seguridad.
Ejercicios — capítulo 31
- EX091 — Inserción o actualización. ¿Por qué un POST sin id es arriesgado ante los reintentos? Rúbrica: 3 = duplicados al reintentar; 2 = vago; 1 = incorrecto; 0 = nada.
- EX092 — Rechazo. Cuerpo JSON que debe recibir un 400. Rúbrica: 3 = contiene payload/password/risk_score; 2 = débil; 1 = cuerpo válido; 0 = nada.
- EX093 — Versión. ¿Es seguro en v1 renombrar reason_code a reason? Rúbrica: 3 = no, es incompatible, va a v2; 2 = dubitativo; 1 = sí; 0 = nada.
Síntesis del capítulo
Escrituras idempotentes, esquema estricto, versiones explícitas.
Siga estudiando — capítulo 31 de 50
← Capítulo 30 (borrador) · Índice de capítulos del curso · Capítulo 32 (borrador) →