Modelo de seguridad

Opfield da a cada persona, token de API y agente de IA un acceso limitado exactamente a los recursos que necesitan, y registra cada acción en un único registro de auditoría: sin root compartido, sin contraseñas de administrador compartidas, sin listas de usuarios por herramienta. El responsable de la plataforma controla Opfield y la ubicación de los nodos gestionados, el responsable de seguridad define la política de identidades y secretos, y los responsables de los recursos aprueban el acceso a sus cargas de trabajo y a sus datos.

Opfield parte de que los hosts gestionados y los administradores son límites de confianza con consecuencias. Reduce las credenciales reutilizables y la dependencia de la shell directa mediante el registro saliente de los daemons, identidades PKI, ámbitos de recursos, operaciones auditadas y roles de daemon acotados.

Un despliegue seguro es correcto cuando la autoridad es explícita, las credenciales no se reutilizan entre límites de confianza, los cambios los verifica el entorno de ejecución propietario y los fallos no recurren silenciosamente a un camino menos seguro. «Accesible» no es lo mismo que «autorizado», y «visible en el inventario en caché» no es permiso para hacer cambios.

Principios clave:

registro de un solo uso en lugar de tokens de nodo reutilizables;
mTLS e identidad de Opfield fijada para el transporte gestionado;
ámbitos de recursos explícitos y permisos separados para revelar, exportar y montar;
secretos cifrados en reposo y salida enmascarada por defecto;
contenedores internos propiedad de Opfield excluidos de las API de ciclo de vida de los usuarios;
identidades de aplicación separadas para las vinculaciones de bases de datos gestionadas;
comportamiento de fallo seguro cuando no se pueden demostrar la propiedad, el derecho del plan, el estado del nodo o la compatibilidad del proveedor;
atribución inmutable en la auditoría tras los cambios en el ciclo de vida de las cuentas.

Opfield protege lo que se ejecuta en sus nodos y los caminos entre ellos. El sistema operativo del host y la red que lo rodea siguen siendo responsabilidad tuya: mantén las actualizaciones del sistema operativo, el bastionado del host y las reglas del perímetro.

Límites de confianza

Límite	Responsabilidad de seguridad
Host de Opfield	Proteger los secretos de la aplicación, el acceso a la base de datos, el entorno de ejecución de contenedores, los volúmenes persistentes y el acceso de administrador
PostgreSQL y Redis	Mantenerlos privados, autenticados, con copia de seguridad y restringidos a los servicios de Opfield
Relay	Conservar la identidad del servicio, la política firmada, el camino de autorización de la base de datos y la propiedad pública de `9443/tcp`
Nodo gestionado	Proteger la identidad del daemon, el servicio de systemd, el entorno de ejecución local, el almacenamiento y los privilegios específicos del rol
Build Worker	Aislar los builds de código no fiable de las cargas de trabajo ordinarias y de los endpoints de control del host
Nodo Ingress	Proteger las claves privadas TLS, la configuración de nginx, los logs y el tráfico público
Nodo Storage	Proteger las credenciales de propietario, las imágenes de almacenamiento, el material de la CA de bases de datos y la administración de los motores
Proveedor externo	Aplicar los controles específicos del proveedor sobre credenciales, retención, disponibilidad y red

Los administradores y cualquiera que pueda controlar el socket de Docker del host de Opfield tienen un nivel de confianza alto. Los contenedores internos propiedad de Opfield están ocultos y protegidos frente a las API normales de ciclo de vida de los usuarios, pero eso no convierte el acceso a Docker a nivel de host en un límite no fiable.

Identidad y autorización

Las sesiones humanas, los tokens de API, OAuth, MCP, los certificados de los daemons, las identidades de servicio, los principales de las vinculaciones de bases de datos, los tokens de logging y los tokens de inferencia son familias de credenciales separadas. No son intercambiables. El backend vuelve a comprobar los ámbitos, la propiedad de los recursos, los derechos del plan y el estado actual aunque la interfaz oculte una acción.

Los permisos limitados por recurso restringen qué objetos puede ver o modificar un usuario. Las acciones sensibles, como revelar credenciales, exportar claves privadas, acceder a archivos del host, acceder a la consola o modificar secretos, requieren una autoridad distinta del acceso de lectura ordinario. Las credenciales no se revelan durante una suplantación, las sesiones de consola de los nodos y las lecturas de archivos de los nodos se auditan, y los tokens de API y el asistente no pueden cambiar el inicio de sesión, el MFA ni las sesiones de su propia cuenta, conceder suplantaciones ni restaurar en grupos que vayan más allá de los permisos de quien llama. El asistente de IA pide aprobación antes de revelar o rotar credenciales o exportar claves privadas.

Tratamiento de los secretos

Los secretos se cifran en reposo y se enmascaran en las respuestas normales. Los valores de solo escritura deben sustituirse en lugar de recuperarse. Mantén las claves maestras fuera de las copias de seguridad de la base de datos, oculta los datos sensibles en los logs y las capturas de pantalla y evita pasar credenciales en argumentos de comandos o en URL de repositorios. El registro de auditoría oculta las cadenas de conexión, las URL secretas, las cabeceras de los webhooks y los valores secretos, y la inspección de contenedores, las vistas del entorno y la exportación de archivos nunca muestran las contraseñas y las claves de los enlaces de bases de datos y de almacenamiento.

Las cargas de trabajo con bases de datos gestionadas reciben identidades específicas de la vinculación, no credenciales de propietario. El conector de Secure Links compartido del nodo Docker de destino sirve cada vinculación en una red privada propia, a la que solo se une la carga de trabajo vinculada. Los container links funcionan igual: cada uno abre un puerto del destino, en una sola dirección, a un consumidor.

Dónde están los secretos en una instalación autoalojada

Todos los planes se pueden autoalojar, y una instalación autoalojada guarda sus secretos en el entorno que controlas:

Material	Dónde se guarda
Credenciales que Opfield guarda por ti: secretos y valores de entorno de Docker, credenciales de registros, tokens de DNS, de Cloudflare y de proveedores de hosting, claves SSH, secretos de OIDC y SMTP, credenciales de bases de datos y de almacenamiento, claves de proveedores de IA y de inferencia, secretos de firma de webhooks, claves privadas de autoridades de certificación y de ACME, y la clave de licencia, el token de instalación y el nonce de registro	La propia base de datos PostgreSQL de la instalación, cifrada con cifrado de sobre AES-256-GCM: cada valor tiene su propia clave de datos aleatoria, que se cifra con la clave maestra
Clave maestra (`PKI_MASTER_KEY`)	Se genera en el host de Opfield durante la instalación y se guarda en el archivo `.env` de la instalación con permisos restringidos; se pasa a los servicios de Opfield al arrancar y no se guarda en la base de datos
Clave privada TLS propia de Opfield	Un archivo en los datos persistentes de Opfield en el host de Opfield
Identidad de un nodo gestionado	La clave privada del daemon del nodo se queda en ese nodo
Claves TLS de las bases de datos gestionadas	Almacenamiento propiedad del daemon en el nodo Storage, fuera de la imagen de la base de datos

Cualquiera que controle el host de Opfield, su archivo .env o su socket de Docker puede llegar a este material. Mantén la copia de seguridad de la clave maestra separada de las copias de seguridad de la base de datos, y no pegues nunca el contenido de .env en chats ni en tickets de soporte. Consulta Actualizaciones, copias de seguridad y restauración para el conjunto de recuperación.

Qué sale de una instalación autoalojada

Opfield hace por sí mismo estas conexiones salientes. Todo lo demás depende de las integraciones que configures, como los proveedores de ACME y DNS, los sistemas de control de código fuente, los registros, los proveedores de identidad, el correo, los webhooks, los receptores SIEM y los proveedores de IA.

Destino	Finalidad	Datos enviados
Servicio de licencias (`license.opfield.dev`)	Registro tras el primer arranque, heartbeats cada 15 minutos con una clave de pago o cada 30 minutos en Community, activación y desactivación de claves, autorización de la versión antes de una actualización y descarga del commercial core en las instalaciones con licencia	ID de instalación, nombre de la instalación, versión de Opfield, versión del esquema de derechos, token de instalación, un nonce de petición aleatorio y los ID de las claves de firma fijadas; un nonce de registro de un solo uso en el registro, la clave de pago en la activación, y la versión de destino, el ID de la versión y la ruta del archivo en las actualizaciones. Consulta Planes y derechos
Servicio de actualizaciones (`get.opfield.dev`)	Comprobación de versiones al arrancar y cada 4 horas por defecto (`UPDATE_CHECK_INTERVAL_HOURS`), y descarga de versiones firmadas	Canal de versiones, componente y versión actual
Registros de contenedores como `ghcr.io`	Descarga de las imágenes de las versiones de Opfield	Peticiones estándar de descarga de imágenes
Cuenta en la nube (`account.opfield.dev`), solo después de que un administrador conecte la instalación a Opfield Cloud	Mostrar la instalación en tu cuenta en la nube y, cuando se permite la gestión remota, registrar nodos e iniciar actualizaciones	El estado de la instalación, su lista de servicios y los logs de los contenedores cuando la cuenta los pide; cada petición queda registrada en el registro de auditoría
Servicios de consulta de la IP pública	Detectar las direcciones públicas de Opfield y de los nodos gestionados	Peticiones HTTPS estándar; el backend de Opfield omite la consulta cuando están definidos tanto `PUBLIC_IPV4` como `PUBLIC_IPV6`

Opfield mantiene una lista firmada de las direcciones del servicio de licencias y usa la que responda; una lista de salida permitida necesita license.opfield.dev. LICENSE_SERVICE_URL en .env, por ejemplo un proxy de salida, se prueba primero.

El script de instalación solo contacta con el servicio de actualizaciones, los registros de contenedores y los repositorios de paquetes de Docker; Opfield se registra en el servicio de licencias poco después de su primer arranque. Los servicios de licencias y de actualizaciones no reciben configuración de la infraestructura, contenido de los recursos, secretos, logs, prompts ni respuestas de modelos. Opfield no contiene ningún cliente de telemetría de uso ni de informes de fallos. Cuando AI Workspace u Opfield Inference están activados, los prompts van a los proveedores de modelos que configura un administrador, no al equipo de Opfield.

Las respuestas del servicio de licencias son estados de licencia firmados. Opfield fija las claves públicas Ed25519 del servicio y acepta un estado solo cuando se firmó para esta instalación y esta petición y se emitió con una diferencia de menos de 15 minutos respecto al reloj local; rechaza los estados sin firmar, falsificados, repetidos o ajenos y vuelve a verificar los estados guardados cada vez que lee la licencia. Consulta Estados de licencia firmados.

Ejemplos de fallo seguro

Opfield rechaza o aplaza las operaciones cuando no puede demostrar la propiedad actual, la capacidad del nodo, el derecho del plan, la compatibilidad del proveedor o del modelo, la procedencia firmada de una actualización, la identidad de origen en la red o la autorización necesaria. El inventario en caché puede seguir visible para el diagnóstico, pero no puede autorizar un cambio.

Los fallos de disponibilidad no deben «arreglarse» introduciendo listeners anónimos, desactivando la validación de certificados, exponiendo puertos privados ni copiando credenciales de propietario en las cargas de trabajo.

Limitaciones de seguridad

Opfield no puede proteger un equipo de administrador comprometido, un root malicioso en el host, un propietario sin restricciones del socket de Docker, un proveedor de identidad externo comprometido ni los datos que exporte deliberadamente un usuario autorizado. Usa un bastionado de hosts independiente, segmentación de red, seguridad de los endpoints, copias de seguridad y controles organizativos.

Lista de decisiones de seguridad

Antes de adoptar Opfield para un entorno de producción, identifica quién controla el host de Opfield, Relay, cada host gestionado, el proveedor de identidad externo, los proveedores de control de código fuente, el DNS, el correo, los proveedores de IA y el almacenamiento de las copias de seguridad. Documenta qué partes pueden obtener datos de aplicaciones o credenciales en texto plano. Si una persona o un sistema es responsable de varios límites, registra esa concentración de privilegios en lugar de suponer que los ámbitos del producto la eliminan.

Para cada capacidad nueva, responde a cuatro preguntas:

¿A qué datos o infraestructura puede llegar?
¿Qué credencial autoriza ese acceso y dónde se guarda?
¿Qué prueba de auditoría o de Task demuestra lo que ocurrió?
¿Qué sigue funcionando, y qué debe fallar de forma segura, cuando la dependencia no está disponible?

Revisa el modelo tras cambios importantes de topología, identidad, proveedores o derechos del plan. Un diseño aprobado para un Ingress y una base de datos privada puede dejar de ser adecuado al añadir Build Workers, acceso público a bases de datos, proveedores de IA externos o automatización entre equipos.

Garantía del operador

Prueba la denegación con el mismo cuidado que el éxito: un usuario sin ámbito, un token revocado, un nodo con datos de capacidades desactualizados, una actualización sin firmar o que no coincide, una carga de trabajo sin la identidad de la vinculación y un destino saliente privado fuera de la política. Conserva las pruebas de auditoría y de error resultantes. Los controles de seguridad que nunca se han ejercitado ante un fallo deben tratarse como suposiciones.