De la primera apertura a la entrega del informe

# ADMIN-01 — Panel administrativo de RackClick cliente-servidor

Fecha: 27.09.2026 · Estado: propuesta documentada, NO implementada en RC7.
Origen: requisito de gestionar usuarios, contraseñas, grupos y permisos desde la futura aplicación web. No modifica ni adopta RC7; no sustituye la QA offline pendiente.

## 1. Objetivo y límite

Una instalación del Systemhaus alojará la cartera y permitirá que varios técnicos trabajen desde sus navegadores. Primera plataforma de despliegue: Windows. Las versiones concretas de Windows y Windows Server soportadas deberán figurar en una matriz de instalación y pruebas; no se promete compatibilidad con versiones no ensayadas. La vía definitiva prevista sigue siendo ASP.NET Core con base de datos; el piloto Python/SQLite R3 continúa como piloto separado. La versión del runtime, motor y plan de migración se fijarán al preparar la entrega de servidor.

El panel administra identidades y acceso, no es un editor SQL directo. La modificación de racks y puertos continúa en la GUI operativa, con la misma jerarquía Systemhaus → cliente → sede → edificio → sala → rack. Si más adelante una instalación sirve a varios Systemhäuser, necesitará un límite adicional de aislamiento, no sólo otro nombre en la cabecera.

RC7 offline no puede proteger datos frente a quien dispone del HTML y JSON completos. No añadiremos una pantalla de contraseña cosmética que prometa esa protección.

## 2. Estructura del panel

| Sección | Información visible | Acciones previstas |
|---|---|---|
| Resumen | Estado del servicio, versión, usuarios activos, conflictos, última copia y última restauración probada | Abrir incidencias y tareas; ningún verde si el estado no se conoce |
| Usuarios | Nombre, identificador, activo/desactivado, proveedor de identidad, grupos, últimas sesiones | Alta, editar perfil, desactivar, restablecer acceso, revocar sesiones |
| Grupos de usuarios | Equipos como Technik-DE, Technik-ES y Externos | Crear, renombrar, añadir/quitar miembros; ver impacto |
| Grupos de clientes | Carteras como Clientes-A, Clientes-B o delegaciones | Crear agrupaciones y asociar clientes; no duplicar inventario |
| Roles y asignaciones | Capacidades y ámbitos asociados a grupos | Asignar rol + ámbito, revisar cambios, guardar con auditoría |
| Permisos efectivos | Usuario + cliente/recurso + operación | Explicar permitido/denegado y qué asignación lo causa |
| Clientes e infraestructura | Identidad y estructura de cada cliente | Acceso al editor autorizado; altas y archivado según permiso |
| Transferencias de datos | Importaciones, exportaciones, estado y alcance | Prevalidar importación, descargar exportes autorizados, consultar errores |
| Auditoría | Actor, fecha UTC, operación, ámbito, resultado, correlación y cambios permitidos | Filtrar; exportar sólo con autorización |
| Copias y restauración | Destino, último éxito, retención, integridad y prueba de restore | Copia manual, programación, restauración controlada |
| Configuración | Nombre Systemhaus, idioma, identidad, sesión y parámetros operativos | Cambiar sólo ajustes autorizados; ocultar secretos |

En el encabezado: Systemhaus, usuario actual y entorno (ensayo/operación). Una ruta visible identifica siempre el cliente; cambiar de cliente debe renovar el contexto y descartar o resolver borradores antes de guardar en otro ámbito.

## 3. Modelo de permisos comprensible

Dos clases de grupos, con nombres editables:

1. Grupo de usuarios: quiénes trabajan juntos (por ejemplo Technik-DE).
2. Grupo de clientes: sobre qué cartera se aplica una autorización (por ejemplo Clientes-A).

Una asignación relaciona un grupo de usuarios, un rol y un ámbito. El ámbito puede ser un cliente o grupo de clientes. Al principio evitaremos permisos por puerto individual y grupos anidados: su complejidad no está justificada para la primera entrega. Sede/rack como ámbitos más estrechos se dejan como evolución explícita, no como función implícita.

Ejemplo: Ana pertenece a Technik-DE. Technik-DE tiene Técnico sobre Clientes-A y Lector sobre Clientes-B. Ana puede editar la infraestructura de Clientes-A, leer Clientes-B y no ve Clientes-C. Los nombres de los grupos no conceden permisos por sí mismos.

El estilo es familiar para quien administra AD/NTFS, pero no se replican automáticamente sus algoritmos de herencia o las GPO. Las GPO configuran políticas; aquí se autoriza el acceso a datos y operaciones de RackClick.

## 4. Roles iniciales propuestos

Los nombres visibles pueden cambiar; las capacidades internas conservan identificadores estables. Los siguientes valores son defaults de diseño que deberán contrastarse con pruebas y aceptación del servidor.

| Capacidad | Administrador Systemhaus | Administrador de datos (ámbito asignado) | Técnico (ámbito asignado) | Lector (ámbito asignado) |
|---|---|---|---|---|
| Ver infraestructura | Sí | Sí | Sí | Sí |
| Crear/editar racks y equipos | Sí | Sí | Sí | No |
| Conectar/desconectar y editar puertos/notas | Sí | Sí | Sí | No |
| Eliminar rack/equipo | Sí | Sí | No por defecto; capacidad delegable | No |
| Ver informe en pantalla | Sí | Sí | Sí | Sí |
| Generar descarga JSON/CSV/XLS/PNG/PDF | Sí | Sí, con permiso de exportación | No por defecto | No por defecto |
| Importar datos | Sí | Sí, con permiso de importación | No | No |
| Gestionar cuentas, grupos y asignaciones | Sí | No | No | No |
| Ver auditoría de datos del cliente | Sí | Sí | No por defecto | No |
| Programar backups/restaurar base de datos | Sí o rol operativo específico | No | No | No |

Conservamos la decisión de que el técnico puede crear/editar su trabajo, mientras importar/exportar queda reservado inicialmente al administrador. Eliminar infraestructura es una capacidad separada para poder delegarla sin conceder administración de usuarios. Desconectar un cable se considera trabajo técnico autorizado, con auditoría y protección de concurrencia.

Un lector con acceso a datos puede hacer capturas o usar impresión del navegador. Bloquear el botón de exportar no impide copiar información que ya se le ha mostrado. La política controla los endpoints y descargas de RackClick; no promete DRM.

## 5. Cálculo de permisos efectivos

- Denegación por defecto: una operación sin autorización aplicable no se permite.
- Primera versión: concesiones explícitas por grupo y ámbito, sin reglas «Deny» personalizadas ni herencia NTFS implícita.
- Si varios grupos conceden capacidades sobre el mismo cliente, se unen las concesiones. Pertenecer también a Lector no elimina un permiso de edición concedido por Técnico.
- Cuenta desactivada, sesión revocada o ámbito ajeno bloquean la operación aunque existiera un rol anterior.
- Sin asignación global automática por llamarse «Technician» o por ser usuario autenticado.
- El panel de permisos efectivos muestra cada capacidad, su ámbito y la asignación/grupo de origen. Debe advertir sobre asignaciones que amplíen mucho el acceso.
- La revocación se aplicará a la siguiente petición autorizada; una escritura todavía no confirmada volverá a comprobar autorización antes de confirmar la transacción. Se documentará el tratamiento de operaciones largas.
- El sistema no permite borrar/desactivar al último administrador utilizable sin un procedimiento de recuperación verificado.

El permiso de grupo de clientes implica acceso también a clientes que se incorporen después a ese grupo. Añadir un cliente al grupo requiere mostrar el impacto y auditarlo. Esto evita que una simple reorganización amplíe acceso sin ser visible.

## 6. Usuarios, contraseñas y sesiones

El alta local incluye identidad, nombre visible, estado y grupos. No habrá cuentas/contraseñas de demo activas en una instalación productiva. El primer administrador se configura mediante un procedimiento de instalación con credencial de un solo uso o alta inicial equivalente.

Las contraseñas existentes no se muestran ni se recuperan en texto. El administrador inicia un restablecimiento con vencimiento y uso único; el usuario establece su nueva contraseña. Se utilizará un componente de identidad mantenido, hashing de contraseñas con sal y política documentada. La elección y parámetros se verificarán al implementar; no se construye criptografía propia.

La interfaz permitirá desactivar usuarios, revocar sesiones, cambiar la propia contraseña y consultar sesiones autorizadas. Los secretos y tokens no aparecerán en logs, historial de cambios, JSON de inventario ni exportes de auditoría. Se contemplan límites de intentos, protección de sesiones y MFA; exigiremos MFA administrativo o una decisión explícita de despliegue antes de operación productiva. No se afirma que MFA exista hoy.

Diseño preparado para AD/OIDC posterior: proveedor + identificador externo separado del nombre visible. La pertenencia a grupos externos tendrá un mapeo explícito y auditado. «Integrar AD» no significa almacenar la contraseña del dominio ni conceder automáticamente acceso a todos sus usuarios.

## 7. Comprobación en servidor y datos

Toda petición exige identidad, operación y ámbito: lecturas, escrituras, búsquedas, conteos, informes, descargas, originales importados y trabajos en segundo plano. La API no confía en un clientId suministrado por el navegador ni en que un botón esté oculto.

Entidades previstas: User, UserGroup, UserGroupMember, Role, Permission, RolePermission, Client, ClientGroup, ClientGroupMember, AccessGrant, Session y AuditEvent. Infraestructura y conexiones mantienen claves al cliente propietario. Una conexión debe verificar ambos extremos y su pertenencia, incluso si el usuario tiene acceso a los dos clientes. En la primera versión no se permiten conexiones entre clientes distintos; cualquier excepción futura requiere un modelo propio.

Consultas y mutaciones aplican aislamiento de cliente; las restricciones de la base de datos refuerzan la coherencia. Una importación valida todo antes de confirmar y conserva el original exacto con acceso restringido. No se ofrecen descargas de originales mediante rutas públicas predecibles.

Se conserva Click-Click en la GUI. La autorización y validación de la conexión ocurren en el servidor sin añadir un clic rutinario; reserved conserva su confirmación intencional.

## 8. Concurrencia y auditoría

Dos técnicos pueden abrir el mismo rack. Cada escritura incluye revisión conocida; si otro ya cambió el recurso, el servidor responde conflicto sin sobrescribir silenciosamente. La GUI explica quién/cuándo cambió lo permitido, conserva el borrador local y ofrece recargar/comparar antes de reintentar. Las operaciones reintentables tendrán identificación idempotente.

La auditoría registra actor, operación, recurso/cliente, tiempo, resultado e identificador de petición. Los cambios se describen sin incluir credenciales. El histórico visible del proyecto offline no sustituye el registro del servidor. La auditoría no es editable mediante la GUI de inventario; su retención y exportación se especificarán con la política operativa.

## 9. Copias y administración de datos

Soportar copia manual y programada a destinos autorizados (disco local, USB o ruta de red). El servicio usa permisos mínimos sobre el destino. Veeam y Synology pueden formar parte del respaldo de la infraestructura, pero el procedimiento debe demostrar consistencia de la base, archivos asociados y restauración.

El dashboard diferencia «última copia terminada», «última copia verificada» y «última restauración probada». No anuncia éxito sólo porque existe un archivo. Restaurar exige alcance, copia previa, control de sesiones/escrituras y verificación antes de reabrir servicio. El backup completo requiere permiso operativo global, aunque un administrador de datos sólo pueda exportar clientes asignados.

## 10. Flujo administrativo de ejemplo

1. Crear Clientes-A y asociar dos clientes sintéticos.
2. Crear Technik-DE.
3. Crear la cuenta de un técnico y asignarla a Technik-DE mediante invitación/restablecimiento seguro.
4. Conceder Técnico a Technik-DE en Clientes-A; no conceder importación/exportación.
5. Abrir Permisos efectivos, elegir ese usuario y ambos clientes: confirmar lectura/edición y ausencia de exportación.
6. Iniciar sesión con el técnico: editar nota y conectar dos puertos válidos; verificar que no accede a Clientes-B.
7. Revocar la asignación y repetir con su sesión abierta: la siguiente petición debe quedar bloqueada.
8. Revisar la auditoría del alta, asignación, edición y revocación.

## 11. Pruebas de aceptación antes de uso real

| ID | Escenario | Resultado exigido |
|---|---|---|
| ADM-01 | Técnico con cliente A intenta leer B por URL/API | Bloqueo; no se filtra inventario, conteo ni nombres |
| ADM-02 | Técnico autorizado crea/edita A | Guarda datos correctos; auditoría del actor |
| ADM-03 | Técnico importa o exporta sin capacidad | API rechaza aunque se invoque manualmente |
| ADM-04 | Lector intenta modificar, conectar o eliminar | Rechazo completo; sin cambios parciales |
| ADM-05 | Dos grupos conceden lectura y edición | Permisos efectivos explican la unión de concesiones |
| ADM-06 | Cuenta desactivada con sesión abierta | Siguiente petición bloqueada; sesión revocada |
| ADM-07 | Se retira grupo o asignación | Nuevo permiso se aplica sin esperar cierre voluntario |
| ADM-08 | Cambio de membresía de un grupo de clientes | Impacto visible, permiso recalculado, auditoría |
| ADM-09 | Usuario sin permisos invoca informe/CSV/original | No obtiene datos por rutas alternativas |
| ADM-10 | Dos técnicos editan misma revisión | Uno confirma; otro recibe conflicto sin pérdida silenciosa |
| ADM-11 | Reintento de escritura/importación | Una operación efectiva, sin duplicados |
| ADM-12 | Conexión con extremo de otro cliente | Rechazo atómico, incluso con permiso sobre ambos |
| ADM-13 | Restablecimiento usado dos veces o vencido | Segundo uso/vencido rechazado; secreto no registrado |
| ADM-14 | Cambio de permisos por no administrador | Rechazo y evento apropiado, sin elevación de privilegios |
| ADM-15 | Eliminar/desactivar último administrador | Bloqueo o procedimiento de recuperación verificado |
| ADM-16 | Backup/restore con datos y archivos | Restauración consistente comprobada, no sólo archivo creado |
| ADM-17 | Catálogos, búsqueda y paginación con varios clientes | Sin filas, totales o metadatos ajenos |
| ADM-18 | Acción por lotes con un recurso no autorizado | Resultado atómico según contrato; sin modificación ajena |
| ADM-19 | CSRF, origen indebido, sesión inválida | Operación rechazada; la sesión válida sigue controlada |
| ADM-20 | Usuario vuelve a iniciar sesión tras revocación | No reaparecen concesiones antiguas de caché |

Todas estas pruebas están PLANIFICADAS. No son resultados ejecutados ni sustituyen pruebas de instalación Windows, rendimiento o recuperación.

## 12. Orden de construcción propuesto

A. Contrato de identidades, capacidades, ámbitos y matriz de pruebas.
B. Modelo persistente y autorización en API; pruebas de aislamiento antes de exponer la GUI.
C. Alta inicial segura, sesiones y restablecimientos.
D. Panel Usuarios/Grupos/Asignaciones/Permisos efectivos conectado a datos reales.
E. Edición concurrente y auditoría; importación/exportación autorizadas.
F. Backup/restore y empaquetado como servicio Windows; guía de instalación limpia.
G. QA multiusuario y aceptación del usuario. AD/OIDC, ámbitos más finos y Linux se incorporan en entregas posteriores identificadas.

No se da una fecha de entrega de servidor sin revisar el estado exacto de los artefactos y sus pruebas. Este documento deja el requerimiento incorporado y verificable sin cambiar la prioridad de la aceptación offline.

## 13. Referencias técnicas contrastadas

Consulta: 27.09.2026. La propuesta de RackClick es propia; estas referencias fundamentan controles generales, no certifican nuestra implementación.

- Microsoft Learn — Resource-based authorization: https://learn.microsoft.com/en-us/aspnet/core/security/authorization/resource-based?view=aspnetcore-10.0
  Permite evaluar identidad, recurso y operación; un atributo de autenticación aislado no decide por sí solo el acceso a cada recurso.
- OWASP — Authorization Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html
  Denegación por defecto y validación de permisos en cada petición.
- OWASP — Password Storage Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html
  Almacenamiento mediante hashing de contraseñas, no contraseñas recuperables en texto.
- OWASP — Authentication Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html
  Controles de autenticación, restablecimiento y gestión de sesiones.