Política de seguridad de la información

Esta política cubre Oriax: la aplicación web, su base de datos y la infraestructura donde se ejecuta. Alcanza a toda persona con acceso a esos sistemas.

Oriax trata datos de negocio de sus clientes —correo, agenda, archivos y movimientos bancarios— siempre por delegación y con autorización expresa de la persona titular.

Oriax prepara, la persona envía. El sistema redacta borradores, organiza y propone, pero no envía correos, no publica ni ejecuta acciones irreversibles frente a terceros sin aprobación explícita.

No es una preferencia de diseño: es una medida de seguridad. Reduce el daño posible de un fallo del modelo, de un error nuestro o de un acceso indebido.

Los datos de cada negocio están separados por la propia base de datos mediante políticas de fila de PostgreSQL, no por comprobaciones en el código de la aplicación.

• Toda tabla de negocio lleva el identificador del negocio y una política que la filtra.
• Las políticas se aplican con FORCE ROW LEVEL SECURITY: rigen incluso para el dueño de las tablas.
• La aplicación conecta con un rol sin privilegios de superusuario y sin capacidad de eludir las políticas, comprobado sobre la base de producción.
• El identificador de quien consulta se fija dentro de la transacción, no en la sesión: una conexión reutilizada por el gestor de conexiones no puede arrastrar el contexto de otro cliente.
• Una prueba automatizada verifica el aislamiento y se ejecuta contra la base real antes de cada cambio en el esquema.

Una consulta que olvide su contexto no devuelve datos ajenos: no devuelve nada. El fallo por omisión es la ausencia de datos, nunca su filtración.

• En tránsito: TLS en todo el trayecto, incluida la conexión a la base de datos.
• Credenciales de terceros en reposo: cifrado autenticado AES-256-GCM con vector de inicialización distinto por registro. La base guarda el sobre cerrado; la clave nunca se almacena junto a los datos.
• Contraseñas: derivación con scrypt y sal aleatoria de 16 bytes por contraseña. No se guardan reversibles ni se pueden recuperar, solo restablecer.
• Sesiones: el identificador de sesión se guarda como resumen SHA-256. Quien obtuviera la tabla no obtendría sesiones utilizables.

Las claves y credenciales viven en Google Secret Manager, con acceso concedido de forma individual a la identidad que ejecuta el servicio. No se escriben en el código, no se suben al repositorio y no viajan en la imagen del contenedor.

Oriax se ejecuta en Google Cloud Run como contenedor sin disco persistente: nada sobrevive al reinicio de una instancia salvo lo que está en la base de datos. La base es PostgreSQL gestionado, con copias de seguridad del proveedor.

El despliegue es automático desde el repositorio: cada cambio queda registrado con autor, fecha y contenido, y no existe forma de modificar lo que corre en producción sin dejar ese rastro.

Oriax no almacena datos de tarjetas de pago, no accede a credenciales bancarias —el acceso a información financiera se hace mediante un proveedor especializado que nunca nos entrega las claves del banco— y no vende ni cede datos de clientes a terceros.

Los datos de los clientes no se utilizan para entrenar modelos de inteligencia artificial, ni propios ni de terceros.

La responsabilidad de esta política recae en la dirección de Oriax. Se revisa al menos una vez al año, y siempre que se produzca un incidente de seguridad o un cambio relevante en la arquitectura.