Seguridad

  • Las conexiones live usan referencias env:NOMBRE y permisos de lectura; las referencias se resuelven solo en memoria al crear el adapter.
  • .env, logs, backups y bases locales están ignorados.
  • Los backups PostgreSQL de OPS-03 se cifran antes de salir del host, usan una passphrase externa y se almacenan fuera de los volúmenes de la aplicación; la CI verifica pérdida/restauración con datos sintéticos.
  • La API no devuelve URI, contraseñas ni tokens.
  • La API verifica tokens Bearer HMAC-SHA256 y RBAC por proyecto/recurso antes de inspeccionar o leer reportes.
  • El análisis nunca ejecuta insert, update, delete, DDL ni migraciones sobre un motor fuente.
  • Errores externos se traducen a mensajes seguros; los detalles técnicos quedan en logs locales controlados.

Perfiles y transporte

fixture es autocontenido y no abre conexiones live. local requiere AUTH_SIGNING_KEY_REF; secure exige la misma referencia y transporte verificable para cada motor live configurado. MongoDB recibe tls=true y, si aplica, un CA mediante MONGODB_TLS_CA_FILE; CouchDB requiere https:// y validación de certificado (COUCHDB_TLS_VERIFY, con CA opcional); Cassandra crea un contexto TLS que valida cadena y nombre de host (CASSANDRA_TLS_ENABLED, con CA opcional).

La demo pública puede activar PUBLIC_DEMO_ANONYMOUS=true únicamente junto con CONNECTION_PROFILE=secure. En ese caso la ausencia de Bearer se convierte en el rol restringido public_demo, con acceso solo al proyecto sintético public-demo y sin permisos de auditoría, exportación ni conexiones live. El valor predeterminado es false; el smoke de release usa además un token HMAC de GitHub para verificar el camino autenticado y RBAC.

La referencia es la única configuración de secretos admitida para credenciales y firma. La rotación cambia el valor externo, reinicia el proceso y emite tokens nuevos; no modifica los reportes SQLite ni persiste una URI completa. El scanner scripts/scan_secrets.py bloquea credenciales, tokens y llaves privadas versionadas, y las respuestas/auditoría aplican redacción defensiva.

Cassandra de integración

El perfil Docker de Cassandra activa autenticación y autorización. El fixture scripts/cassandra/cass-02-schema.cql crea datos exclusivamente sintéticos y el rol schemasafe_reader, con permiso SELECT solo en schemasafe_cass02. Las pruebas de CASS-03 auditan que el adapter acepta únicamente sus sentencias SELECT declaradas, rechaza scans de filas sin partition key antes de ejecutarlos y verifica que el rol no puede hacer INSERT. Esto es evidencia local/CI; el perfil secure añade TLS verificable para despliegues compartidos.

Antes de producción se requiere revisión de proveedor de secretos, ciclo de rotación, aislamiento por proyecto, retención de auditoría y threat model.

Plan de seguridad por versión

  • MVP: fixture mode, SQLite local, no secretos versionados y pruebas explícitas de no mutación.
  • Versión 1: tokens verificables, RBAC por proyecto/recurso, referencias de secretos de entorno, TLS verificable, timeouts, límites de consulta, redacción de logs y auditoría de denegaciones.
  • Posterior: SSO, rotación automática, aprobación de cambios, alertas, threat model revisado y pruebas de penetración.

No se debe abrir una conexión live desde el frontend ni aceptar una URI completa como dato persistente de una conexión sin separar host, base, referencia de secreto y política de permisos.