metis-desk/docs/auditoria-de-infraestructura-informatica.md

# Auditoría de infraestructura informática y propuesta para Metis Desk

Fecha: 17 de octubre de 2026. Estado: propuesta revisada con el alcance funcional
acordado. El núcleo de la primera entrega está descrito en
[Infraestructura informática](infraestructura-informatica.md); los casos adicionales
se mantienen como ampliaciones posteriores.

## Resultado y límite acordado

Metis Desk debe ofrecer un inventario con conexiones entre equipos, interfaces y
sus direcciones IP, y una consulta de dónde se utiliza cada activo. Se conservan
las plantillas, los activos, los puestos, los perfiles y las relaciones existentes.
La vista Infraestructura reúne esa información por compañía.

Ejemplo del nivel requerido: «La impresora XXX está conectada al switch 1 y se utiliza
en A1, A2, A5 y P1». Si dispone de Ethernet y Wi-Fi, se registran ambas interfaces
con sus respectivas direcciones, sin exigir que ambas estén configuradas o en uso.

El controlador UniFi ya proporciona al usuario el detalle de su infraestructura de
red. Por tanto, la propuesta de Metis Desk no incluye puertos numerados de switches,
cables, rosetas, ocupación de conectores, VLAN, subredes, tablas de rutas, IPAM avanzado
ni monitorización o descubrimiento automático. Tampoco exige sincronizar UniFi para
poder registrar los datos básicos. Una integración futura requeriría un alcance propio.

Las interfaces se registran para identificar el medio y sus IP. No representan un
inventario exhaustivo de todos los conectores de un switch. La información detallada
de red permanece en UniFi; Metis Desk mantiene la información de equipos y uso necesaria
para el soporte, sin prometer que ambos sistemas estén sincronizados.

## Alcance y método de la auditoría

Revisión de código y documentación activa del repositorio y auditoría documental de
seis productos. Se han consultado fuentes oficiales; no se han instalado ni probado
sus interfaces. La comparación analiza modelos funcionales, no precios, rendimiento
ni disponibilidad comercial de cada función en todas las ediciones. Las conclusiones
para Metis Desk son recomendaciones propias, diferenciadas de lo documentado por los proveedores.

La comparación de mercado se conserva como referencia. Que una herramienta gestione
puertos o VLAN no convierte esas capacidades en requisitos para Metis Desk.

No se ha explorado la red de Abeto Design ni modificado su inventario. Este documento
no acredita conexiones o instalaciones reales de esa compañía.

## Situación actual comprobada

| Área | Existe hoy | Ajuste necesario para el alcance acordado |
| --- | --- | --- |
| Inventario | Activos con compañía, sede, estado técnico, marca, plantilla e historial | Reunir la infraestructura y facilitar la consulta de sus conexiones y uso |
| Plantillas | Router, firewall, switch, punto de acceso, NAS, servidor, impresora y otros equipos | Mantener sus datos descriptivos; separar las interfaces y direcciones repetibles |
| Relaciones | Conectado a, Alojado en, Depende de, Alimentado por e Instalado en; tipos propios | Reutilizar los vínculos entre activos, suficientes para indicar impresora ↔ switch |
| Puestos | Ordenador principal, responsable opcional, sede y composición | Conservar la exclusividad; los dispositivos compartidos no se duplican entre puestos |
| Perfiles | Contexto de persona y equipo para documentar configuraciones | Mostrar qué equipos y perfiles utilizan cada activo compartido |
| Impresión | Configuración perfil/impresora, USB o red, predeterminada y estados de preparación/retirada | Obtener una lista de equipos usuarios, distinguiendo uso configurado de tareas pendientes |
| Software | Aplicación y licencia como recursos; instalación vinculada a activo | Mantener su responsabilidad propia, separada de las conexiones de red |
| Carpetas | Recursos y configuración de acceso/mapeo con ruta | Relacionar explícitamente el recurso con el servidor o NAS cuando se necesite documentar su anfitrión |

Evidencias locales:

- [Catálogo de activos](../modules/assets/src/api/domain/asset-catalog-seed.ts).
- [Reserva exclusiva de miembros del puesto](../modules/assets/src/api/application/workstation-input.mapper.ts).
- [Valores de las relaciones](../modules/assets/src/api/domain/value-objects/asset-relationship-values.vo.ts).
- [Tipos de campos y plantillas](../modules/assets/src/api/domain/asset-definition.ts).
- [Relaciones entre activos](relaciones-entre-activos.md).
- [Puestos de trabajo](puestos-de-trabajo.md).
- [Impresoras del perfil](impresoras-del-perfil.md).
- [Contrato de impresión](../modules/companies/src/api/domain/printer-configuration-values.ts).
- [Contrato de instalación de software](../modules/companies/src/api/domain/software-installation-values.ts).

Consecuencias:

1. Una impresora compartida puede registrarse hoy como un único activo y vincularse
   a varios perfiles. No necesita incorporarse a cada puesto.
2. Una impresora USB puede formar parte de un puesto y mantener una relación con el
   ordenador. Esa composición no acredita una instalación de controlador.
3. Un servidor, NAS, switch o router puede existir sin puesto. Los servidores que hoy
   se utilizan excepcionalmente como ordenador principal conservan ese caso de uso;
   no se propone migrarlos ni bloquearlos automáticamente.
4. «Conectado a» ya permite representar el nivel de conexión solicitado. No hace falta
   sustituirlo por enlaces entre puertos ni representar cada cable paralelo.
5. Falta una estructura sencilla de interfaces y direcciones, junto con una vista
   consolidada del uso que aproveche las configuraciones ya existentes.

## Comparación documental

| Herramienta | Tratamiento documentado | Aprendizaje para Metis Desk |
| --- | --- | --- |
| GLPI | Puertos asociados a equipos, Ethernet/Wi-Fi y variantes virtuales; conexiones entre puertos, MAC, VLAN e historial | Tomar el inventario y las interfaces; mantener el detalle de puertos en UniFi |
| iTop 3.3 | Dispositivos, servidores e impresoras como elementos propios; interfaces, VLAN y relaciones de impacto/dependencia | Separar el dispositivo de las funciones y dependencias que presta |
| Jira Service Management Assets | Objetos relacionados por referencias entrantes/salientes y tipos de referencia | Mantener referencias navegables; una ficha aislada no explica la infraestructura |
| ServiceNow CMDB | Relaciones diferenciadas de conexión, alojamiento, dependencia y pertenencia | Dar significado explícito a cada relación y distinguir conexión de impacto |
| ManageEngine ServiceDesk Plus | CMDB con mapas de relaciones y dependencias; integración con herramientas de observabilidad | Consultar conexiones y uso; las integraciones no son requisito de esta propuesta |
| NetBox | Interfaces de dispositivos, IP, VLAN y cableado entre extremos | Tomar la asociación de direcciones a interfaces; su cableado e IPAM exceden el alcance acordado |

Fuentes y alcance de las afirmaciones:

- **GLPI:** [Network ports](https://help.glpi-project.org/documentation/tabs/network_ports)
  y [Connections](https://help.glpi-project.org/documentation/tabs/connections).
  La documentación distingue conexiones de equipos y puertos de red y permite datos manuales o de inventario automático.
- **iTop:** [CMDB 3.3](https://www.itophub.io/wiki/page?id=3_3_0:datamodel:itop-config-mgmt)
  y [dispositivos de usuario 3.3](https://www.itophub.io/wiki/page?id=3_3_0:datamodel:itop-endusers-devices).
  Se documentan dispositivos de red, interfaces físicas, VLAN e impresoras conectadas a red o PC.
- **Atlassian:** [referencias entre objetos](https://support.atlassian.com/assets/docs/what-is-a-reference/).
  Las referencias tienen dirección y un tipo que expresa su significado.
- **ServiceNow:** [relaciones entre CI](https://www.servicenow.com/docs/r/de-DE/servicenow-platform/configuration-management-database-cmdb/c_CIRelationships.html).
  La tabla distingue Connects to, Depends on, Hosted on y otras relaciones.
- **ManageEngine:** [CMDB de ServiceDesk Plus](https://www.manageengine.com/products/service-desk/itsm/it-cmdb-software.html)
  y [sincronización con OpManager](https://www.manageengine.com/network-monitoring/syncing-relationship-data.html).
  La descripción del proveedor contempla mapas e integración; no implica que toda edición los incluya.
- **NetBox:** [interfaces](https://netbox.readthedocs.io/en/stable/models/dcim/interface/),
  [direcciones IP](https://netbox.readthedocs.io/en/stable/models/ipam/ipaddress/)
  y [cables](https://netbox.readthedocs.io/en/stable/models/dcim/cable/).
  La documentación sitúa IP/VLAN en interfaces y representa conexiones físicas mediante extremos de cable.

La conclusión transversal de esta revisión es que los equipos compartidos conservan
su identidad y se conectan a otros registros. La asignación personal es una dimensión
más, junto a ubicación, conexiones y uso.

## Modelo funcional recomendado

| Concepto | Qué representa | Ejemplo |
| --- | --- | --- |
| Plantilla de activo | Datos descriptivos de un tipo de equipo | Impresora, NAS, switch |
| Activo | Un equipo concreto, físico o virtual cuando corresponda | Impresora XXX, switch 1, ordenador A1 |
| Puesto | Equipo principal y elementos asignados exclusivamente al conjunto | PC + monitores + impresora USB dedicada |
| Perfil | Contexto de usuario/equipo y sus configuraciones | Perfil de una persona en A1 |
| Interfaz | Medio de conexión de un activo que interesa documentar | Ethernet LAN, Wi-Fi, interfaz de gestión |
| Dirección IP | Dirección asociada a una interfaz concreta | Ethernet: 192.168.5.201; Wi-Fi: 192.168.5.202 |
| Conexión entre activos | Vínculo general entre dos equipos | Impresora XXX conectada al switch 1 |
| Configuración de uso | Cómo un perfil o equipo consume un activo o recurso | Impresora configurada en A1 o carpeta mapeada |
| Recurso publicado | Algo consumible ofrecido por un anfitrión | Carpeta compartida de un NAS |

### Plantillas y clasificación

Marca, modelo, serie, capacidad, características de hardware, firmware y datos
específicos del producto siguen en las plantillas. Hubs, gateways, controladoras y
otros equipos pueden usar plantillas propias.

Una clasificación funcional estable debe permitir filtrar familias sin depender
del nombre traducido ni del icono. Un gateway también puede hacer de router,
firewall y punto de acceso: registrar un solo aparato y sus funciones. La clasificación
exacta se debe acordar antes de modificar contratos; el icono sigue siendo presentación.

Las interfaces y sus IP requieren estructuras relacionadas. Evitar campos fijos
IP Ethernet/IP Wi-Fi, IP1/IP2 o listas separadas por comas, porque un activo puede
tener varias interfaces del mismo tipo y una interfaz puede tener varias direcciones.

### Interfaces e IP: información mínima

Por cada interfaz que interese documentar:

- Nombre o identificador comprensible: Ethernet, LAN1, Wi-Fi o Gestión.
- Tipo de conexión, inicialmente Ethernet, Wi-Fi y Otro.
- Cero, una o varias direcciones IP, admitiendo IPv4 e IPv6.
- MAC opcional y observaciones opcionales.

Una impresora puede tener Ethernet y Wi-Fi aunque solo Ethernet tenga una IP conocida.
Una interfaz sin dirección conocida no obliga a inventarla ni a borrar la interfaz.
En las tablas, las celdas sin valor muestran «—» conforme al patrón común.

La IP identifica una configuración, no la identidad del activo. Cambiar una IP conserva
el activo y su historial. Una misma dirección privada puede existir en compañías
diferentes. Dentro de una compañía, una coincidencia puede generar un aviso revisable;
no imponer unicidad absoluta sin conocer los contextos de red, que quedan fuera del alcance.
No es necesario administrar prefijos, máscaras, rangos, DHCP ni VLAN para guardar una IP.

### Conexiones entre equipos

Reutilizar «Conectado a» como vínculo entre dos activos de la misma compañía.
Debe poder consultarse en ambas fichas y conservar su vigencia e historial actual.
Ejemplos: impresora ↔ switch, PC ↔ switch, AP ↔ switch y NAS ↔ switch.

La conexión se registra aunque no se conozca la interfaz. Si interesa asociarla a
una interfaz documentada, se puede añadir una referencia opcional sobre ese mismo
vínculo, sin crear una segunda conexión independiente ni exigir el puerto remoto.
La concreta necesidad de esa referencia se resolverá en el diseño técnico.

Las relaciones existentes siguen siendo válidas y completas para este nivel de
detalle. No se marcan como incompletas por carecer de extremos de cable. Una sola
relación puede resumir la conexión entre dos equipos, incluso si UniFi conoce varios
enlaces físicos. Las asociaciones se documentan; no acreditan disponibilidad en tiempo real.

### Uso exclusivo, compartido y «Dónde se utiliza»

La exclusividad pertenece a la composición activa del puesto. Un activo compartido
puede ser utilizado por varios perfiles o equipos sin adquirir varias identidades ni
reservas exclusivas. Mantener la protección del ordenador y sus periféricos dedicados.

Para impresoras, la fuente de verdad del uso son las configuraciones de impresión
existentes. Desde ellas se obtiene el equipo de cada perfil y, cuando exista, su
puesto. La consulta «Dónde se utiliza» muestra equipos únicos —A1, A2, A5, P1— y
permite desplegar sus perfiles/usuarios y su configuración de impresora predeterminada.
Si varios perfiles de A1 utilizan la impresora, A1 aparece una sola vez en el resumen.

Distinguir configurada, pendiente de configurar y pendiente de retirar. Las configuraciones
retiradas o que nunca llegaron a configurarse permanecen en el historial, sin presentarse
como uso actual. Los avisos de referencias inactivas se conservan. No afirmar un uso
real observado: la información describe las configuraciones registradas en Metis Desk.

No mantener una segunda lista editable de ordenadores usuarios para las mismas
configuraciones. Si aparece un uso a nivel de equipo sin perfil, se diseñará una
asociación específica para ese caso y se integrará en la consulta agregada.

Estar conectado a un switch no significa utilizar la impresora. Estar en la misma
sede tampoco concede acceso. Conexión, uso y asignación exclusiva son dimensiones distintas.

### Impresión local y compartida

| Caso | Conexión documentada | Uso documentado |
| --- | --- | --- |
| USB dedicada | Impresora ↔ PC; puede pertenecer al puesto | Perfil configura esa impresora local |
| Impresora Ethernet | Impresora ↔ switch; interfaz Ethernet con sus IP si se conocen | Varios perfiles/equipos configuran el mismo activo |
| Impresora Wi-Fi | Impresora ↔ AP cuando interese y se conozca; interfaz Wi-Fi con sus IP | Varios perfiles/equipos configuran el mismo activo |
| USB compartida desde un PC | Impresora ↔ PC anfitrión; no necesita una IP propia | Otros equipos utilizan la impresora compartida desde ese anfitrión |

Para impresoras publicadas por un PC o servidor, registrar el anfitrión y el nombre
compartido o ruta cuando ese caso lo requiera. El modelo completo de colas y servidores
de impresión se reserva para una ampliación posterior; no es requisito para consultar
los equipos que hoy utilizan una impresora de red mediante los perfiles existentes.

### Servidores, NAS y recursos

Registrar cada servidor o NAS una vez, con sus interfaces/IP y conexiones generales.
Los roles —archivos, dominio, DNS, DHCP, impresión o aplicaciones— describen sus funciones;
no crear un activo duplicado por cada función ni exigir un puesto para administrarlo.

Una VM puede ser otro activo relacionado mediante «Alojado en», conservando identidad
e historial al cambiar de anfitrión. El NAS es el dispositivo y sus carpetas son recursos.
La relación explícita entre recurso y anfitrión se incorporará cuando ese caso sea necesario,
conservando los permisos y configuraciones actuales. No forma parte del mínimo de red
el modelado exhaustivo de servicios, clusters o dependencias de aplicaciones.

## Ejemplo de ficha de una impresora

Ejemplo ilustrativo del alcance, no inventario ni conexiones verificados de Abeto Design:

| Apartado | Contenido |
| --- | --- |
| Información | Impresora XXX, modelo, serie, sede y estado |
| Interfaces | Ethernet: 192.168.5.201; Wi-Fi: 192.168.5.202 |
| Conexiones | Switch 1 por Ethernet; AP 1 por Wi-Fi, si se conoce y está documentado |
| Dónde se utiliza | A1, A2, A5 y P1; perfiles y estados de configuración asociados |
| Historial | Cambios de datos, direcciones, conexiones y configuraciones |

Las dos direcciones son ilustrativas; no se presupone que ambas interfaces estén
configuradas o conectadas simultáneamente. Tampoco es obligatorio conocer el AP.

```mermaid
flowchart LR
    Printer[Impresora XXX] ---|Conectada a| Switch[Switch 1]
    Printer --- Ethernet[Ethernet: 192.168.5.201]
    Printer --- Wifi[Wi-Fi: 192.168.5.202]
    A1[Equipo A1] -. Configuración de impresión .-> Printer
    A2[Equipo A2] -. Configuración de impresión .-> Printer
    A5[Equipo A5] -. Configuración de impresión .-> Printer
    P1[Equipo P1] -. Configuración de impresión .-> Printer
```

El esquema muestra conexión, interfaces y uso. Las líneas de uso son una consulta
agregada de los perfiles, no nuevas asociaciones editables que dupliquen sus datos.

## Diseño de persistencia propuesto

Propuesta conceptual, no esquema aprobado ni migración lista para ejecutar:

- `asset_interfaces`: identidad UUID v7, compañía, activo, nombre, tipo de conexión,
  MAC opcional y observaciones. Solo interfaces relevantes para documentar el activo.
- `asset_interface_addresses`: identidad UUID v7, interfaz y dirección IP normalizada.
  Mantener las referencias y validaciones de pertenencia a compañía.
- `asset_relationships`: reutilizar la entidad existente para conexiones entre equipos,
  alojamiento y dependencias. No crear `network_connections` para puertos o cables.
- `printer_configurations`: conservar la fuente de verdad del uso de impresoras;
  obtener equipos/perfiles/puestos mediante consultas, sin copiar listas de usuarios.

No se proponen tablas de puertos de switch, cableado, VLAN, segmentos, pools o rangos
IP. Las futuras publicaciones de recursos o usos sin perfil se diseñarán por separado
cuando existan casos concretos, sin bloquear esta entrega.

Todas las entidades de negocio, incluidas las internas, requieren identidad propia.
Mantener FK, validación de compañía, transacciones, historial, idempotencia y migraciones
explícitas. La dirección no sustituye el UUID del activo o interfaz. Las referencias
repetibles se almacenan de forma relacional, sin listas de IP en texto ni JSON.
Los módulos consumidores acceden por servicios públicos; el ORM permanece en Infrastructure.
MariaDB y la arquitectura existente cubren este alcance.

Los campos IP o MAC que ya existan en características o notas requieren una revisión
antes de proponer migración. No eliminarlos ni reinterpretarlos automáticamente.
Una migración futura debe identificar la interfaz cuando se conozca, conservar el
historial y establecer una única fuente editable para la información normalizada.

## Cambios de interfaz recomendados

Añadir **Infraestructura** en la compañía como vista del mismo inventario, con filtros
de equipos de red, servidores/almacenamiento y periféricos compartidos. Mostrar nombre,
tipo, sede, estado, direcciones y vínculos generales según el contenido disponible.
Estos filtros necesitan clasificación funcional explícita; no deben usar iconos como
reglas de negocio. Un equipo puede aparecer en varias vistas por sus funciones.

La ficha del activo reúne **Información**, **Interfaces**, **Conexiones**,
**Dónde se utiliza** e **Historial**, según corresponda. Los apartados pueden ser
secciones de la ficha; no se exige crear una pestaña por cada uno. Reutilizar
componentes, listados, selectores y diálogos existentes.

- Impresora: interfaces con IP, dispositivos conectados y equipos/perfiles que la utilizan.
- Switch: equipos conectados a nivel de activo, sin cuadrícula ni ocupación de puertos.
- Servidor/NAS: interfaces, conexiones y relaciones de alojamiento o recursos ya documentadas.
- Puesto: componentes exclusivos y consulta de uso compartido derivada de sus perfiles,
  sin incorporar la impresora compartida a su reserva exclusiva.

Una representación gráfica sencilla es opcional y posterior a las consultas en tabla.
Un acceso manual al controlador UniFi puede añadirse si resulta útil; no se presupone
API, descubrimiento, enlace profundo a un dispositivo ni sincronización automática.

## Alternativas y recomendación

| Alternativa | Ventaja | Problema | Decisión propuesta |
| --- | --- | --- | --- |
| IP y uso en notas o campos fijos | Entrega mínima | No permite consultar y mantener varias interfaces/IP o referencias con claridad | Documentación transitoria |
| Quitar la exclusividad de los puestos | Aparente simplicidad | Mezcla reserva, conexión y uso compartido | Descartar |
| Inventario, relaciones entre equipos, interfaces/IP y uso derivado | Aprovecha el modelo actual y cubre el límite solicitado | Requiere interfaces/IP y consultas consolidadas | Recomendada |
| Replicar el detalle de red de UniFi | Más información técnica | Duplica una función que el usuario ya tiene cubierta | Fuera del alcance |

La recomendación es propia. De GLPI se toma el inventario y la distinción entre medios;
de iTop, Atlassian y ServiceNow, las relaciones; de NetBox, el concepto de direcciones
asociadas a interfaces. Sus funciones más amplias no se trasladan como obligaciones.

## Orden de implantación y aceptación

### 1. Hacer visible la infraestructura y su uso

Acordar la clasificación funcional y crear la vista de infraestructura. Reutilizar
«Conectado a» entre activos y ofrecer la consulta de conexiones desde ambos extremos.
Mostrar en impresoras los equipos que las utilizan, derivados de perfiles y configuraciones.
Separar estado técnico, reserva exclusiva y uso compartido al presentarlos.

Aceptación:

- Una impresora está conectada al switch 1 sin introducir ningún puerto.
- A1, A2, A5 y P1 pueden utilizarla sin duplicar su activo ni sus reservas de puesto.
- Dos perfiles de A1 no duplican A1 en la lista agregada.
- Se distinguen configuraciones activas, pendientes de configurar/retirar e historial.
- Un servidor, NAS o switch se administra sin crear un puesto.

### 2. Incorporar interfaces y direcciones

Alta y edición de interfaces relevantes para el activo, con sus direcciones IP,
validación e historial. Captura manual; UniFi no es una dependencia para guardar.
No exigir conocer un switch, AP, subred o puerto para registrar una interfaz o IP.

Aceptación:

- Una impresora conserva Ethernet y Wi-Fi con IP diferentes.
- Puede guardarse una interfaz sin IP conocida o con varias IPv4/IPv6.
- Un activo puede tener dos interfaces Ethernet diferenciadas por nombre.
- Cambiar o retirar una IP conserva la identidad del activo y su historial.
- Dos compañías pueden registrar la misma IP privada sin conflicto.
- Guardar los mismos datos no añade revisiones; las referencias de otra compañía se rechazan.

### 3. Completar casos concretos de publicación y uso

Cuando se necesite: anfitrión de carpeta compartida, impresora USB compartida desde
un PC, alojamiento de VM o uso de un activo a nivel de equipo sin perfil.
Reutilizar las asociaciones existentes y evitar registros duplicados de un mismo uso.
El modelo exhaustivo de colas o servicios requerirá su propio diseño.

### 4. Mejoras opcionales de consulta

Mapa sencillo entre equipos y acceso al controlador UniFi, si aportan utilidad.
Una integración automática se evaluará como tarea separada con origen, reconciliación
e historial; no implica ampliar el alcance a gestión de cableado, IPAM o monitorización.

## Decisiones de alcance para la siguiente entrega

1. El puesto mantiene su composición exclusiva; la infraestructura compartida tiene activos propios.
2. Las conexiones son entre equipos, sin detalle de puertos ni cables.
3. Cada activo puede tener varias interfaces y cada interfaz cero o varias IP.
4. El uso de impresoras se consulta desde las configuraciones de sus perfiles, agrupado por equipo.
5. Infraestructura será una vista del mismo inventario y sus asociaciones, sin duplicarlo.
6. UniFi conserva el detalle de red; una integración no es necesaria para esta propuesta.
7. La entrega comienza por conexiones/uso visibles e interfaces/IP. Los casos adicionales
   de recursos publicados se incorporan conforme se necesiten.

Este documento actualiza la propuesta funcional. No implementa cambios de código,
no modifica datos y no cambia por sí mismo las reglas vigentes del dominio.