uflow
Seguridad operacional

Secretos, credenciales y API keys: la otra mitad de la seguridad del motor

Las políticas de crédito consultan bureaus y APIs con credenciales sensibles. Cómo gestionarlas bien: secretos con alcance por carpeta, API keys con ciclo de vida, 2FA y mínimo privilegio.

Actualizado en julio de 2026 · 5 min de lectura

En resumen

Las credenciales de bureaus y APIs se guardan en un almacén de secretos y se referencian por nombre: no viven en las políticas ni en el código. Se separan por ambiente, se rotan sin tocar los flujos y las integraciones usan identidades propias revocables.

Una política de crédito productiva maneja credenciales que valen oro: usuarios de bureau, tokens de APIs internas, claves de proveedores. La guía de segregación de roles cubre quién puede tocar la política; esta cubre la otra mitad — cómo se custodia lo que la política usa para conectarse al mundo.

Escrito porSantiago Etchegoyen · CTO de uFlow

CTO de uFlow. Responsable de la arquitectura del motor de decisiones: integración por API, orquestación de bureaux y fuentes de datos, ejecución de modelos en producción y la seguridad de la plataforma.

Credenciales fuera de la política

La regla base: ninguna credencial se escribe dentro de un nodo. uFlow provee un almacén de secretos donde las credenciales se guardan protegidas y los nodos las referencian por nombre, sin exponer su valor.

El beneficio es doble: el diseño evita exponer el valor en la configuración del flujo, y rotarlo es cambiarlo en un solo lugar — no cazar todos los nodos que lo copiaron.

Alcances: un secreto por contexto

Los secretos tienen alcance — globales o acotados a un contexto — lo que permite separar credenciales por ambiente o por unidad de negocio.

Ese diseño resuelve limpio dos necesidades típicas de una institución:

  • Separar ambientes: la carpeta de pruebas usa las credenciales de sandbox del bureau; la de producción, las reales — con el mismo nombre de secreto, sin tocar las políticas.
  • Separar unidades de negocio: cada vertical o país con sus propias credenciales y su propio costo por consulta.
  • Exposición explícita: el uso de un secreto en integraciones salientes se habilita a propósito — lo sensible no viaja por accidente.

API keys para sistemas, con ciclo de vida

Los sistemas que ejecutan políticas por API se autentican con credenciales propias, revocables en cualquier momento, y operan con tokens temporales con expiración. El detalle del esquema de autenticación vive en la documentación técnica.

Una práctica recomendada: una identidad por sistema integrador — cada integración con permisos propios y revocación quirúrgica si algo se compromete.

Personas: 2FA, expiración y mínimo privilegio

Para los usuarios humanos, el motor permite exigir segundo factor (con app de autenticación), configurar expiración de contraseñas por usuario y separar permisos de forma granular: editar no es ejecutar, y consultar no es ninguna de las dos.

La recomendación operativa: 2FA obligatorio para administradores y para cualquier usuario con acceso a políticas o datos sensibles, y revisión periódica de que cada rol conserve solo los permisos que su función necesita.

Documentación técnica

Cómo se implementa esto en el motor, paso a paso.

Preguntas frecuentes

Dudas habituales

¿Quién debería poder leer un secreto?+

Nadie, después de creado: los secretos se referencian, no se leen. Quien configura el nodo usa el nombre del secreto sin ver su valor, y el valor no aparece en configuraciones ni en logs. Si hay dudas sobre un secreto, se rota — no se inspecciona.

¿Cada cuánto conviene rotar las API keys?+

Ante cualquier sospecha de compromiso, cuando alguien con acceso deja el equipo, y periódicamente según la política interna de la institución. Revocar y regenerar toma minutos, y con un usuario por sistema integrador el impacto queda acotado a esa integración.

¿Te sirve para tu proceso de decisión?

Transforma tu proceso de evaluación crediticia con el motor de decisiones.