Los 4 síntomas de una arquitectura rota (si te suenan, estás en riesgo)

1. Usuarios compartidos (“TurnoNoche”, “Operador1”)
2. Todo el mundo es admin (porque “si no, no camina”)
3. Cambios sin huella (prioridad, ubicación, categoría, cierre)
4. Permisos por persona (manuales, inconsistentes, imposibles de auditar)

Esto no solo es seguridad: es continuidad operativa. Cuando cambian turnos o rotan mandos, el caos se multiplica.

El modelo mínimo que sí funciona: 3 capas + separación de funciones

Para no frenar la operación, diseña roles desde la realidad de turnos.

Capa 1 — Acciones operativas (lo que el operador hace)

Acciones típicas:

• crear incidente (folio),
• capturar DMV (dato mínimo viable),
• triage,
• asignar tarea,
• actualizar estatus,
• adjuntar evidencia,
•  

Capa 2 — Acciones de decisión (lo que cambia el curso del incidente)

Acciones críticas:

• cambiar prioridad/categoría,
• reasignar recursos entre jurisdicciones/sitios,
• declarar “falso positivo” (sin evidencia es peligroso),
• cerrar con resultado,
• activar protocolos.

Capa 3 — Acciones de gobierno (lo que cambia el sistema)

Acciones de alto riesgo:

• crear/modificar catálogos,
• cambiar reglas de correlación/prioridad,
• alterar flujos,
• modificar retención,
• administrar integraciones,
• gestionar exportaciones masivas.

Regla de diseño: que nadie tenga simultáneamente (2) y (3) sin justificación y supervisión.

Separación de funciones (SoD): el control que salva auditorías

En operación crítica, hay acciones que no deben concentrarse.

Ejemplos de separación recomendada:

• Quien cierra el incidente no debería poder borrar/alterar evidencia.
• Quien administra reglas no debería poder editar la bitácora.
• Quien exporta datos no debería ser el mismo que autoriza la exportación (doble control).
• Quien cambia roles no debería ser el mismo que aprueba accesos (4-eyes principle).

Esto no es burocracia si se implementa con flujos: aprobación rápida, registro automático, vencimientos.

RBAC vs ABAC (y por qué necesitas ambos)

RBAC (Role-Based Access Control)

Permisos por rol: Operador, Supervisor, Mando, Auditor, Admin.

Pros: simple, entendible, entrenable.
Contras: rígido cuando hay múltiples sedes/zonas/jurisdicciones.

ABAC (Attribute-Based Access Control)

Permisos por atributos y contexto:

• sitio (A/B/C),
• agencia (Seguridad/PC/Movilidad),
• turno,
• nivel de clasificación,
• tipo de incidente,
• jurisdicción.

Pros: escala en multi-sede/multi-agencia.
Contras: se vuelve un monstruo si no tienes gobierno.

Recomendación práctica:
Usa RBAC como base y ABAC como restricciones (“puede, pero solo en su jurisdicción/sitio/turno”).

El punto ciego #1: “editar” datos críticos sin versionado

En operación crítica, “editar” debe significar crear una nueva versión, no reescribir el pasado.

Campos que deberían versionarse siempre:

• ubicación (dirección/coordenadas),
• prioridad,
• categoría,
• estatus de cierre,
• asignación de recursos,
• etiquetas de evidencia.

Cada cambio debe guardar:

• usuario,
• timestamp,
• motivo,
• valor anterior y nuevo.

Si no hay esto, no hay auditoría. Y sin auditoría, no hay defensa.

El punto ciego #2: exportaciones y capturas “para WhatsApp”

La fuga más común no es hacker: es “te mando el screenshot”.

Controles mínimos:

• roles explícitos para exportar,
• límites por volumen (“no export masivo sin aprobación”),
• watermarking o trazabilidad (si aplica),
• registro de accesos/descargas,
• expiración de enlaces/archivos.

Regla de oro: lo que sale del sistema debe dejar huella, o te quedas sin control narrativo y legal.

Diseño recomendado: 8 roles típicos.

1) Operador de monitoreo

Crear/actualizar incidentes, triage, adjuntar evidencia, asignar tareas dentro de reglas.

2) Despachador / Coordinador

Asignar recursos, actualizar estatus, coordinar comunicaciones.

3) Supervisor de turno

Cambios críticos (prioridad/categoría) con motivo, reasignaciones, autorizaciones rápidas.

4) Mando/Comandante del incidente

Activación de protocolos, decisiones multi-agencia, cierre final en eventos críticos.

5) Analista / Inteligencia

Acceso a analítica, búsqueda avanzada, correlación; sin permisos de edición crítica.

6) Auditor / Control interno

Acceso de lectura + exportación limitada y registrada; sin edición.

7) Administrador de plataforma (TI)

Configuración técnica, integraciones; sin capacidad de editar incidentes “en producción”.

8) Administrador de seguridad (IAM)

Gestión de usuarios/roles, políticas de acceso; idealmente separado de TI.

KPIs y pruebas que te dicen si tu modelo está sano

• % de usuarios con credenciales individuales (objetivo: ~100%)
• % de acciones críticas con motivo registrado
• de roles por usuario (mientras más, peor; indica “parches”)
• de excepciones temporales otorgadas y vencidas correctamente
• Incidentes cerrados sin evidencia mínima (debería tender a cero)
• Exportaciones por rol y por volumen (detección de anomalías)

La implementación pragmática (sin frenar operación): 30 días

Semana 1: mapear decisiones críticas + catálogo de acciones (qué se permite y quién).
Semana 2: diseñar roles RBAC base + restricciones ABAC por sitio/jurisdicción/turno.
Semana 3: activar versionado de campos críticos + motivos obligatorios.
Semana 4: controles de exportación + auditoría + pruebas con turnos reales.

Riesgo a evitar: diseñarlo desde TI sin operación. Debe ser co-diseño con quien vive el turno.

Cierre: en operación crítica, los permisos son parte del proceso, no un detalle técnico

Si tu plataforma permite:

• cerrar sin evidencia,
• editar sin huella,
• exportar sin control,
• o compartir usuarios…

entonces no importa cuántas pantallas tengas: el costo aparecerá cuando más duele.