Seguridad

​

Autenticación de la plataforma

• API Key — una clave estática enviada en el header X-API-Key, habilitada con API_KEY_ENABLED.
• Access Manager — autenticación basada en tokens, habilitada con PLUGIN_AUTH_ENABLED. Cuando ambos modos están habilitados, Access Manager tiene prioridad.

curl -X GET https://tu-instancia-flowker/v1/workflows \
  -H "X-API-Key: tu-api-key"

• Modo API Key — el middleware valida la clave en cada solicitud; una clave válida otorga acceso a todos los endpoints. Configura la clave mediante variables de entorno o configuración de arranque.
• Modo Access Manager — cada solicitud lleva un Bearer token y cada ruta aplica un permiso por recurso y por acción. Así se aplica la autorización basada en roles y en políticas.
• Las credenciales inválidas o ausentes retornan 401 Unauthorized.

​

Autenticación de executors

{
  "name": "fraud-check",
  "description": "Scoring de fraude vía Tracer",
  "baseUrl": "https://tracer.example.com",
  "endpoints": [
    {
      "name": "analyze",
      "path": "/v1/transactions/analyze",
      "method": "POST",
      "timeout": 30
    }
  ],
  "authentication": {
    "type": "bearer",
    "config": {
      "token": "eyJhbGciOiJSUzI1NiIs..."
    }
  }
}

​

Seguridad de red

• Todos los endpoints de la API requieren HTTPS en producción
• Las llamadas de executors a proveedores externos utilizan HTTPS
• Los datos sensibles (credenciales, payloads de solicitud/respuesta) siempre se transmiten por canales cifrados

• Los orígenes permitidos son configurables por despliegue
• Las credenciales no están permitidas en solicitudes de origen cruzado (AllowCredentials está deshabilitado)
• Las respuestas de preflight se cachean para rendimiento

​

Resiliencia

• Transita por los estados closed → open → half-open
• Los umbrales se configuran globalmente (fallas consecutivas antes de abrir)
• El estado half-open permite un número limitado de solicitudes de prueba antes de cerrarse completamente

• Cantidad fija de 5 reintentos con backoff exponencial (1s, 2s, 4s, 8s)
• Backoff exponencial entre intentos
• Solo las fallas transitorias activan reintentos (errores de red, respuestas 5xx)

​

Registro de auditoría

• Los eventos de auditoría son consultables vía el endpoint /v1/audit-events con filtros por tipo de evento, acción, resultado, recurso y rango de fechas
• Cada entrada incluye un hash criptográfico que la vincula con la entrada anterior, formando una cadena a prueba de manipulaciones
• La integridad de la cadena de hashes es verificable vía el endpoint /v1/audit-events/{id}/verify
• Los logs incluyen timestamps, identificación del actor (con dirección IP), tipo de acción y recursos afectados

​

Próximos pasos