Seguridad y compliance

Cuatro pilares de seguridad y compliance

Autenticación + RBAC

JWT con refresh tokens · 5 roles diferenciados · permisos por yard (multi-yard nativo, ADR-008).

Auditoría inmutable

AuditLog con append-only · timestamp, usuario, IP, payload completo · base para resolución de disputas.

Cumplimiento LFPDPPP

Datos personales del chofer (nombre, licencia) con consentimiento; fotos de inspección con retención controlada.

Despliegue dedicado

Sin multi-tenancy · los datos del cliente viven en su infraestructura · cumple políticas internas del cliente.

---

Autenticación y autorización (RBAC)

Resumen ejecutivo

El sistema usa JWT (JSON Web Tokens) con refresh tokens. Cada usuario tiene roles por yard — un usuario puede ser Yard Manager en Dulces Nombres y solo Viewer en Saltillo.

Cada acción del sistema se autoriza contra:

1. El rol global del usuario (Admin o no).
2. El rol del usuario en el yard objetivo (vía UserYardAccess).

No se permite ninguna escritura sin un rol explícito en el yard al que pertenece la operación.

Detalle técnico

Mecánica:

• Login → JWT (15 min) + refresh token (30 días con rotación).
• AuthorizationBehavior de MediatR (pipeline behavior) intercepta cada command y valida permiso.
• UserYardAccess se carga en cada request desde el JWT claims (no DB lookup por request).
• Logout → invalidación del refresh token en RevokedTokens table.

Roles definidos:

Rol	Scope	Resumen
Admin	Global	Configuración, catálogos, usuarios
YardManager	Por yard	Layout, anomalías, fuerza cierres
Operator	Por yard	Captura entrada/salida, rondín
GateOperator	Por yard	Vista de caseta, registro rápido
Viewer	Por yard	Solo lectura

---

Audit log inmutable

Resumen ejecutivo

Cada acción significativa del sistema queda registrada en un AuditLog que no permite borrar ni modificar. Si surge una disputa (“¿quién movió mi trailer?”, “¿desde cuándo está aquí?”, “¿alguien forzó este cierre?”) hay evidencia objetiva inmediata.

Qué se audita:

• Login y logout.
• Cada MovementEvent (entrada, salida, confirmación, corrección, cierre forzado).
• Cada cambio de layout (edición de zonas, perímetro).
• Cada apertura, transición o cierre de anomalía.
• Administración: alta/baja de usuarios, modificación de catálogos.

Política: retención 5 años, alineada con compliance aduanal.

Detalle técnico

Modelo:

public class AuditLog : IEntity {
  public Guid Id { get; init; }                  // immutable
  public DateTime OccurredAt { get; init; }
  public Guid UserId { get; init; }
  public string IpAddress { get; init; }
  public string ActionType { get; init; }        // ej. "MovementEvent.EntryRegistered"
  public string EntityType { get; init; }
  public Guid EntityId { get; init; }
  public string PayloadJson { get; init; }       // antes y después
  public string? Reason { get; init; }           // requerido para operaciones sensibles
}

Garantías:

• Trigger SQL Server impide UPDATE y DELETE sobre la tabla (excepto vía rotación programada al cumplir retención).
• El AuditBehavior de MediatR escribe en la misma transacción del command — atómico.
• Particionamiento por mes (ADR-007) para mantener performance.

---

Cumplimiento LFPDPPP (Ley Federal de Protección de Datos Personales en Posesión de los Particulares)

Resumen ejecutivo

El YMS maneja datos personales del chofer del tractor: nombre y número de licencia. Para esto:

• Los datos se obtienen del documento físico (hoja de salida) o se capturan voluntariamente — el sistema no infiere ni enriquece con fuentes externas.
• El acceso a estos campos está restringido por rol (no aparecen en Viewer).
• Las fotos de inspección con personas visibles están sujetas al mismo régimen.
• El cliente, como responsable del dato, define el aviso de privacidad mostrado al transportista en la garita.

Detalle técnico

Datos personales identificados:

• ShipmentDocument.DriverName, DriverLicense.
• Personas visibles en fotos de inspección.

Controles implementados:

• Campos PII marcados en el modelo con atributo [PersonalData].
• Endpoint admin DELETE /api/admin/personal-data/{userId} para ejercer derecho ARCO (Acceso, Rectificación, Cancelación, Oposición) — rectifica o anonimiza datos del chofer manteniendo el evento operativo.
• Logs de acceso a campos PII (segregado del audit log general).

Retención:

Tipo de dato	Retención
Fotos de daños (anomalías)	5 años — soporte legal ante disputas
Fotos de inspección 360° normales	1 año
Audit log	5 años
Datos personales del chofer	5 años desde último movimiento, después anonimización

---

Seguridad en integraciones

Canal	Mecanismo
Webhook entrante de Samsara	Firma HMAC con secret compartido + idempotencia por EventId
Webhook saliente al cliente	Firma HMAC + reintentos con backoff exponencial
API REST de consulta	JWT con scope Viewer mínimo + rate limiting por token
Tráfico cliente→servidor	HTTPS obligatorio · HSTS · cipher suites modernas
Almacenamiento BD	Encryption at rest (TDE de SQL Server) si el cliente lo activa

---

Modelo de deployment-per-customer y compliance

Por qué deployment-per-customer simplifica compliance

Con una instancia separada por cliente:

• Soberanía del dato: los datos del cliente nunca salen de su infraestructura ni se mezclan con otros.
• Auditoría externa simplificada: el cliente puede auditar su instancia sin involucrar al proveedor.
• Configuración de retención individual: cada cliente fija sus políticas (ej. cliente A pide retención 7 años, cliente B 5 años).
• Tickets independientes: un incidente en un cliente no afecta a los demás.

Trade-off: mayor costo de operación vs SaaS multi-tenant. Compensado por la robustez requerida en el dominio.

---

Continúa

• Stack y arquitectura →
• Integraciones →
• Pasa a Entrega → para alcance del MVP y roadmap.