Modèle de sécurité

Opfield donne à chaque personne, jeton d’API et agent d’IA un accès limité exactement aux ressources dont il a besoin, et enregistre chaque action dans un seul journal d’audit : pas de root partagé, pas de mots de passe d’administration partagés, pas de listes d’utilisateurs par outil. Le responsable de la plateforme contrôle Opfield et le placement des nœuds gérés, le responsable de la sécurité définit la politique d’identité et de secrets, et les responsables des ressources approuvent l’accès à leurs charges de travail et à leurs données.

Opfield considère les hôtes gérés et les administrateurs comme des frontières de confiance lourdes de conséquences. Il réduit les identifiants réutilisables et la dépendance au shell direct grâce à l’enrôlement sortant des démons, aux identités PKI, aux scopes de ressources, aux opérations auditées et aux rôles bornés des démons.

Un déploiement sécurisé réussit lorsque l’autorité est explicite, que les identifiants ne sont pas réutilisés d’une frontière de confiance à l’autre, que les modifications sont vérifiées par l’environnement d’exécution propriétaire, et que les échecs ne se rabattent pas silencieusement sur un chemin moins sûr. « Joignable » ne signifie pas « autorisé », et « visible dans l’inventaire en cache » n’est pas une permission de modifier.

Principes clés :

enrôlement à usage unique plutôt que jetons de nœuds réutilisables ;
mTLS et identité Opfield épinglée pour le transport géré ;
scopes de ressources explicites et permissions distinctes d’affichage, d’export et de montage ;
secrets chiffrés au repos et sortie masquée par défaut ;
conteneurs internes appartenant à Opfield exclus des API de cycle de vie des utilisateurs ;
identités applicatives distinctes pour les liaisons de bases de données managées ;
échec fermé lorsque la propriété, le droit, l’état du nœud ou la compatibilité du fournisseur ne peuvent pas être prouvés ;
attribution d’audit immuable après les changements de cycle de vie des comptes.

Opfield sécurise ce qui s’exécute sur ses nœuds et les chemins qui les relient. Le système d’exploitation des hôtes et le réseau qui les entoure restent de votre ressort : maintenez les mises à jour du système, le durcissement des hôtes et les règles de périmètre.

Frontières de confiance

Frontière	Responsabilité de sécurité
Hôte Opfield	Protéger les secrets applicatifs, l’accès à la base de données, l’environnement d’exécution des conteneurs, les volumes persistants et l’accès administrateur
PostgreSQL et Redis	Les garder privés, authentifiés, sauvegardés et réservés aux services Opfield
Relay	Préserver l’identité de service, la politique signée, le chemin d’autorisation de la base de données et la détention du port public `9443/tcp`
Nœud géré	Protéger l’identité du démon, le service systemd, l’environnement d’exécution local, le stockage et les privilèges propres au rôle
Build Worker	Isoler les builds de sources non fiables des charges de travail ordinaires et des points de terminaison de contrôle des hôtes
Nœud Ingress	Protéger les clés privées TLS, la configuration nginx, les journaux et le trafic public
Nœud Storage	Protéger les identifiants de propriétaire, les images de stockage, le matériel de la Database CA et l’administration des moteurs
Fournisseur externe	Appliquer les contrôles propres au fournisseur en matière d’identifiants, de conservation, de disponibilité et de réseau

Les administrateurs et toute personne capable de contrôler le socket Docker de l’hôte Opfield bénéficient d’un niveau de confiance élevé. Les conteneurs internes appartenant à Opfield sont masqués et protégés des API de cycle de vie normales des utilisateurs, mais cela ne fait pas de l’accès Docker au niveau de l’hôte une frontière non fiable.

Identité et autorisation

Les sessions humaines, les jetons d’API, OAuth, MCP, les certificats des démons, les identités de service, les principaux des liaisons de bases de données, les jetons de journalisation et les jetons d’inférence sont des familles d’identifiants distinctes. Elles ne sont pas interchangeables. Le serveur revérifie les scopes, la propriété des ressources, les droits et l’état actuel, même lorsque l’interface masque une action.

Les permissions limitées aux ressources restreignent les objets qu’un utilisateur peut voir ou modifier. Les actions sensibles comme l’affichage des identifiants, l’export des clés privées, l’accès aux fichiers des hôtes, l’accès à la console et la modification des secrets exigent une autorité distincte de l’accès en lecture ordinaire. Les identifiants ne sont pas affichés pendant une usurpation d’identité, les sessions de console des nœuds et les lectures de fichiers des nœuds sont auditées, et les jetons d’API et l’assistant ne peuvent ni modifier la connexion, la MFA ou les sessions de leur propre compte, ni accorder l’usurpation d’identité, ni restaurer dans des groupes au-delà des permissions de l’appelant. L’assistant d’IA demande une approbation avant d’afficher ou de faire tourner des identifiants ou d’exporter des clés privées.

Gestion des secrets

Les secrets sont chiffrés au repos et masqués dans les réponses normales. Les valeurs en écriture seule doivent être remplacées plutôt que récupérées. Conservez les clés maîtresses hors des sauvegardes de la base de données, masquez les journaux et les captures d’écran, et évitez de transmettre des identifiants via des arguments de commande ou des URL de dépôts. Le journal d’audit masque les chaînes de connexion, les URL secrètes, les en-têtes des webhooks et les valeurs secrètes, et l’inspection des conteneurs, les vues de l’environnement et l’export d’archives n’affichent jamais les mots de passe et les clés des liens vers les bases de données et le stockage.

Les charges de travail des bases de données managées reçoivent des identités propres à chaque liaison, et non des identifiants de propriétaire. Le connecteur secure-link partagé du nœud Docker cible sert chaque liaison sur son propre réseau privé, que seule la charge de travail liée rejoint. Les liens entre conteneurs fonctionnent de la même manière : chacun ouvre un port de la cible, dans un seul sens, vers un seul consommateur.

Où se trouvent les secrets dans une installation auto-hébergée

Chaque plan peut être auto-hébergé, et une installation auto-hébergée conserve ses secrets dans l’environnement que vous contrôlez :

Matériel	Emplacement de stockage
Identifiants qu’Opfield stocke pour vous : secrets et valeurs d’environnement Docker, identifiants de registres, jetons DNS, Cloudflare et d’hébergeurs, clés SSH, secrets OIDC et SMTP, identifiants de bases de données et de stockage, clés des fournisseurs d’IA et d’Inference, secrets de signature des webhooks, clés privées des autorités de certification et d’ACME, ainsi que la clé de licence, le jeton d’installation et le nonce d’enregistrement	La base PostgreSQL propre à l’installation, chiffrés par chiffrement d’enveloppe AES-256-GCM : chaque valeur a sa propre clé de données aléatoire, chiffrée avec la clé maîtresse
Clé maîtresse (`PKI_MASTER_KEY`)	Générée sur l’hôte Opfield pendant l’installation et conservée dans le fichier `.env` de l’installation avec des permissions restreintes ; elle est transmise aux services Opfield au démarrage et n’est pas stockée dans la base de données
Clé privée TLS propre à Opfield	Un fichier dans les données persistantes d’Opfield sur l’hôte Opfield
Identité d’un nœud géré	La clé privée du démon du nœud reste sur ce nœud
Clés TLS des bases de données managées	Stockage appartenant au démon sur le nœud Storage, hors de l’image de la base

Toute personne qui contrôle l’hôte Opfield, son fichier .env ou son socket Docker peut atteindre ce matériel. Conservez la sauvegarde de la clé maîtresse séparément des sauvegardes de la base de données, et ne collez jamais le contenu de .env dans une discussion ou un ticket de support. Voir Mises à jour, sauvegardes et restauration pour le jeu de reprise.

Ce qui quitte une installation auto-hébergée

Opfield établit de lui-même ces connexions sortantes. Tout le reste dépend des intégrations que vous configurez, comme les fournisseurs ACME et DNS, les systèmes de gestion de sources, les registres, les fournisseurs d’identité, l’e-mail, les webhooks, les récepteurs SIEM et les fournisseurs d’IA.

Destination	Objectif	Données envoyées
Service de licences (`license.opfield.dev`)	Enregistrement après le premier démarrage, signaux de présence toutes les 15 minutes avec une clé payante ou toutes les 30 minutes en Community, activation et désactivation des clés, autorisation de version avant une mise à jour, et téléchargement du cœur commercial pour les installations sous licence	Identifiant de l’installation, nom de l’installation, version d’Opfield, version du schéma des droits, jeton d’installation, un nonce de requête aléatoire et les identifiants des clés de signature épinglées ; un nonce d’enregistrement à usage unique lors de l’enregistrement, la clé payante lors de l’activation, ainsi que la version cible, l’identifiant de version et le chemin du fichier pour les mises à jour. Voir Plans et droits
Service de mise à jour (`get.opfield.dev`)	Vérification des versions au démarrage et toutes les 4 heures par défaut (`UPDATE_CHECK_INTERVAL_HOURS`), et téléchargement des versions signées	Canal de versions, composant et version actuelle
Registres de conteneurs comme `ghcr.io`	Récupération des images des versions d’Opfield	Requêtes standard de récupération d’images
Compte cloud (`account.opfield.dev`), uniquement après qu’un administrateur a connecté l’installation à Opfield Cloud	Afficher l’installation dans votre compte cloud et, lorsque la gestion à distance est autorisée, enrôler des nœuds et lancer des mises à jour	L’état de l’installation, sa liste de services et les journaux des conteneurs lorsque le compte les demande ; chaque demande est enregistrée dans le journal d’audit
Services de recherche d’IP publique	Détecter les adresses publiques d’Opfield et des nœuds gérés	Requêtes HTTPS standard ; le serveur Opfield ignore la recherche lorsque `PUBLIC_IPV4` et `PUBLIC_IPV6` sont tous deux définis

Opfield conserve une liste signée des adresses du service de licences et utilise celle qui répond ; une liste d’autorisation du trafic sortant nécessite license.opfield.dev. LICENSE_SERVICE_URL dans .env, par exemple un proxy sortant, est essayé en premier.

Le script d’installation ne contacte que le service de mise à jour, les registres de conteneurs et les dépôts de paquets Docker ; Opfield s’enregistre auprès du service de licences peu après son premier démarrage. Les services de licences et de mise à jour ne reçoivent ni configuration de l’infrastructure, ni contenu des ressources, ni secrets, ni journaux, ni prompts, ni réponses des modèles. Opfield ne contient ni télémétrie d’utilisation ni client de rapport de plantage. Lorsqu’AI Workspace ou Opfield Inference est activé, les prompts vont aux fournisseurs de modèles configurés par un administrateur, et non à l’équipe Opfield.

Les réponses du service de licences sont des états de licence signés. Opfield épingle les clés publiques Ed25519 du service et n’accepte un état que s’il a été signé pour cette installation et cette requête, et émis à moins de 15 minutes de l’horloge locale ; il refuse les états non signés, falsifiés, rejoués ou étrangers et revérifie les états stockés chaque fois qu’il lit la licence. Voir États de licence signés.

Exemples d’échec fermé

Opfield refuse ou diffère les opérations lorsqu’il ne peut pas prouver la propriété actuelle, la capacité du nœud, le droit du plan, la compatibilité du fournisseur ou du modèle, la provenance signée d’une mise à jour, l’identité de la source réseau ou l’autorisation requise. L’inventaire en cache peut rester visible pour le diagnostic, mais ne peut pas autoriser une modification.

Les pannes de disponibilité ne doivent pas être « corrigées » en introduisant des écouteurs anonymes, en désactivant la validation des certificats, en exposant des ports privés ou en copiant des identifiants de propriétaire dans les charges de travail.

Limites de sécurité

Opfield ne peut pas protéger un poste d’administrateur compromis, un root d’hôte malveillant, un propriétaire de socket Docker sans restriction, un fournisseur d’identité externe compromis, ni des données délibérément exportées par un utilisateur autorisé. Utilisez un durcissement indépendant des hôtes, une segmentation réseau, une sécurité des postes, des sauvegardes et des contrôles organisationnels.

Liste de décisions de sécurité

Avant d’adopter Opfield pour un environnement de production, identifiez qui contrôle l’hôte Opfield, Relay, chaque hôte géré, le fournisseur d’identité externe, les fournisseurs de gestion de sources, le DNS, l’e-mail, les fournisseurs d’IA et le stockage des sauvegardes. Documentez quelles parties peuvent obtenir des données applicatives ou des identifiants en clair. Si une personne ou un système détient plusieurs frontières, consignez cette concentration de privilèges plutôt que de supposer que les scopes du produit l’éliminent.

Pour chaque nouvelle fonctionnalité, répondez à quatre questions :

Quelles données ou quelle infrastructure peut-elle atteindre ?
Quel identifiant autorise cet accès et où est-il stocké ?
Quels éléments d’audit ou de tâche prouvent ce qui s’est passé ?
Qu’est-ce qui reste opérationnel, et qu’est-ce qui doit échouer de manière fermée, lorsque la dépendance est indisponible ?

Réexaminez le modèle après tout changement significatif de topologie, d’identité, de fournisseur ou de droits. Une conception approuvée pour un ingress et une base de données privée peut ne plus convenir après l’ajout de Build Workers, d’un accès public à une base de données, de fournisseurs d’IA externes ou d’une automatisation entre équipes.

Assurance de l’opérateur

Testez le refus aussi délibérément que le succès : un utilisateur sans scope, un jeton révoqué, un nœud aux données de capacités périmées, une mise à jour non signée ou non correspondante, une charge de travail sans identité de liaison, et une destination sortante privée hors politique. Conservez les éléments d’audit et d’erreur obtenus. Les contrôles de sécurité qui n’ont jamais été éprouvés en situation d’échec doivent être considérés comme des hypothèses.