Sicherheitsmodell

Opfield gibt jeder Person, jedem API-Token und jedem KI-Agenten Zugriff mit Scope auf genau die Ressourcen, die sie benötigen, und erfasst jede Aktion in einem Audit-Log: kein gemeinsames root, keine gemeinsamen Administratorpasswörter, keine Benutzerlisten pro Werkzeug. Der Plattformverantwortliche kontrolliert Opfield und die Platzierung verwalteter Nodes, der Sicherheitsverantwortliche legt Identitäts- und Secret-Richtlinien fest, und die Ressourcenverantwortlichen genehmigen den Zugriff auf ihre Workloads und Daten.

Opfield geht davon aus, dass verwaltete Hosts und Administratoren folgenreiche Vertrauensgrenzen sind. Es verringert wiederverwendbare Zugangsdaten und die Abhängigkeit von direktem Shell-Zugriff durch ausgehende Registrierung der Daemons, PKI-Identitäten, Ressourcen-Scopes, auditierte Operationen und abgegrenzte Daemon-Rollen.

Ein sicheres Deployment ist erreicht, wenn Befugnisse ausdrücklich sind, Zugangsdaten nicht über Vertrauensgrenzen hinweg wiederverwendet werden, Änderungen von der zuständigen Laufzeit geprüft werden und Fehler nicht stillschweigend auf einen weniger sicheren Weg ausweichen. „Erreichbar“ ist nicht dasselbe wie „autorisiert“, und „im zwischengespeicherten Inventar sichtbar“ ist keine Erlaubnis zur Änderung.

Grundprinzipien:

einmalige Registrierung statt wiederverwendbarer Node-Tokens;
mTLS und fest hinterlegte Opfield-Identität für den verwalteten Transport;
ausdrückliche Ressourcen-Scopes und getrennte Berechtigungen zum Anzeigen, Exportieren und Einbinden;
im Ruhezustand verschlüsselte Secrets und standardmäßig maskierte Ausgabe;
von Lebenszyklus-APIs für Benutzer ausgenommene Opfield-eigene interne Container;
getrennte Anwendungsidentitäten für Bindings verwalteter Datenbanken;
Ablehnung, wenn Zuständigkeit, Leistungsumfang, Node-Zustand oder Kompatibilität des Anbieters nicht nachgewiesen werden können (fail closed);
unveränderliche Audit-Zuordnung nach Änderungen im Lebenszyklus eines Kontos.

Opfield sichert, was auf seinen Nodes läuft, und die Pfade zwischen ihnen. Das Betriebssystem des Hosts und das Netzwerk drumherum bleiben in Ihrer Verantwortung: Behalten Sie OS-Updates, Host-Härtung und Perimeterregeln bei.

Vertrauensgrenzen

Grenze	Sicherheitsverantwortung
Opfield-Host	Anwendungs-Secrets, Datenbankzugriff, Container-Laufzeit, persistente Volumes und Administratorzugriff schützen
PostgreSQL und Redis	Privat, authentifiziert, gesichert und auf Opfield-Dienste beschränkt halten
Relay	Dienstidentität, signierte Richtlinie, Autorisierungspfad für Datenbanken und öffentliche Zuständigkeit für `9443/tcp` bewahren
Verwalteter Node	Daemon-Identität, systemd-Dienst, lokale Laufzeit, Speicher und rollenspezifische Rechte schützen
Build Worker	Builds aus nicht vertrauenswürdigen Quellen von gewöhnlichen Workloads und Endpunkten zur Host-Steuerung isolieren
Ingress Node	Private TLS-Schlüssel, nginx-Konfiguration, Logs und öffentlichen Datenverkehr schützen
Storage Node	Owner-Zugangsdaten, Speicher-Images, Material der Database CA und Engine-Administration schützen
Externer Anbieter	Anbieterspezifische Kontrollen für Zugangsdaten, Aufbewahrung, Verfügbarkeit und Netzwerk anwenden

Administratoren und jeder, der den Docker-Socket des Opfield-Hosts kontrollieren kann, genießen ein hohes Maß an Vertrauen. Opfield-eigene interne Container sind verborgen und vor normalen Lebenszyklus-APIs für Benutzer geschützt, doch das macht Docker-Zugriff auf Host-Ebene nicht zu einer nicht vertrauenswürdigen Grenze.

Identität und Autorisierung

Menschliche Sitzungen, API-Tokens, OAuth, MCP, Daemon-Zertifikate, Dienstidentitäten, Binding-Prinzipale von Datenbanken, Logging-Tokens und Inferenz-Tokens sind getrennte Familien von Zugangsdaten. Sie sind nicht austauschbar. Das Backend prüft Scopes, Ressourcenzuständigkeit, Leistungsumfang und aktuellen Zustand erneut, selbst wenn die Oberfläche eine Aktion ausblendet.

Berechtigungen mit Ressourcen-Scope begrenzen, welche Objekte ein Benutzer sehen oder ändern kann. Sensible Aktionen wie das Anzeigen von Zugangsdaten, der Export privater Schlüssel, Zugriff auf Host-Dateien, Konsolenzugriff und das Ändern von Secrets erfordern eine andere Befugnis als gewöhnlicher Lesezugriff. Zugangsdaten werden während eines Identitätswechsels nicht angezeigt, Konsolensitzungen und Dateilesevorgänge auf Nodes werden auditiert, und API-Tokens und der Assistent können weder Anmeldung, MFA oder Sitzungen ihres eigenen Kontos ändern noch Identitätswechsel gewähren oder in Gruppen jenseits der Berechtigungen des Aufrufers wiederherstellen. Der KI-Assistent bittet um Genehmigung, bevor er Zugangsdaten anzeigt oder rotiert oder private Schlüssel exportiert.

Umgang mit Secrets

Secrets werden im Ruhezustand verschlüsselt und in normalen Antworten maskiert. Nur schreibbare Werte müssen ersetzt statt abgerufen werden. Bewahren Sie Master-Schlüssel außerhalb von Datenbank-Backups auf, schwärzen Sie Logs und Screenshots und vermeiden Sie es, Zugangsdaten über Befehlsargumente oder Repository-URLs zu übergeben. Das Audit-Log schwärzt Verbindungszeichenfolgen, geheime URLs, Webhook-Header und Secret-Werte, und Container-Inspektion, Umgebungsansichten und Archivexport zeigen nie die Passwörter und Schlüssel von Datenbank- und Speicherverbindungen.

Workloads mit verwalteten Datenbanken erhalten Binding-spezifische Identitäten, keine Owner-Zugangsdaten. Der gemeinsame Secure-Link-Connector des Ziel-Docker-Nodes bedient jedes Binding in einem eigenen privaten Netzwerk, dem nur der gebundene Workload beitritt. Container-Links funktionieren genauso: Jeder öffnet einen Port des Ziels in einer Richtung für einen Verbraucher.

Wo Secrets in einer selbst gehosteten Installation liegen

Jeder Tarif kann selbst gehostet werden, und eine selbst gehostete Installation hält ihre Secrets in der Umgebung, die Sie kontrollieren:

Material	Wo es gespeichert wird
Zugangsdaten, die Opfield für Sie speichert: Docker-Secrets und Umgebungswerte, Registry-Zugangsdaten, Tokens für DNS, Cloudflare und Hosting-Anbieter, SSH-Schlüssel, OIDC- und SMTP-Secrets, Zugangsdaten für Datenbanken und Speicher, Schlüssel für KI- und Inference-Anbieter, Signatur-Secrets für Webhooks, private Schlüssel von Zertifizierungsstellen und ACME sowie Lizenzschlüssel, Installationstoken und Registrierungs-Nonce	Die eigene PostgreSQL-Datenbank der Installation, verschlüsselt mit AES-256-GCM-Envelope-Verschlüsselung: Jeder Wert hat einen eigenen zufälligen Datenschlüssel, der mit dem Master-Schlüssel verschlüsselt ist
Master-Schlüssel (`PKI_MASTER_KEY`)	Wird bei der Installation auf dem Opfield-Host erzeugt und mit eingeschränkten Berechtigungen in der Datei `.env` der Installation aufbewahrt; er wird den Opfield-Diensten beim Start übergeben und nicht in der Datenbank gespeichert
Eigener privater TLS-Schlüssel von Opfield	Eine Datei in den persistenten Daten von Opfield auf dem Opfield-Host
Identität eines verwalteten Nodes	Der private Schlüssel des Daemons bleibt auf diesem Node
TLS-Schlüssel verwalteter Datenbanken	Daemon-eigener Speicher auf dem Storage Node, außerhalb des Datenbank-Images

Wer den Opfield-Host, seine Datei .env oder seinen Docker-Socket kontrolliert, kann dieses Material erreichen. Bewahren Sie das Backup des Master-Schlüssels getrennt von Datenbank-Backups auf und fügen Sie den Inhalt von .env nie in Chats oder Support-Tickets ein. Den Wiederherstellungssatz beschreibt Updates, Backups und Wiederherstellung.

Was eine selbst gehostete Installation verlässt

Opfield baut von sich aus diese ausgehenden Verbindungen auf. Alles andere hängt von Integrationen ab, die Sie konfigurieren, etwa ACME- und DNS-Anbieter, Quellcodeverwaltungen, Registries, Identitätsanbieter, E-Mail, Webhooks, SIEM-Empfänger und KI-Anbieter.

Ziel	Zweck	Gesendete Daten
Lizenzdienst (`license.opfield.dev`)	Registrierung nach dem ersten Start, Heartbeats alle 15 Minuten mit einem kostenpflichtigen Schlüssel oder alle 30 Minuten in Community, Aktivierung und Deaktivierung von Schlüsseln, Autorisierung von Releases vor einem Update und Download des kommerziellen Kerns für lizenzierte Installationen	Installations-ID, Installationsname, Opfield-Version, Schemaversion des Leistungsumfangs, Installationstoken, eine zufällige Anfrage-Nonce und die IDs der fest hinterlegten Signaturschlüssel; bei der Registrierung eine einmalige Registrierungs-Nonce, bei der Aktivierung der kostenpflichtige Schlüssel und für Updates Zielversion, Release-ID und Dateipfad. Siehe Tarife und Leistungsumfang
Update-Dienst (`get.opfield.dev`)	Release-Prüfungen beim Start und standardmäßig alle 4 Stunden (`UPDATE_CHECK_INTERVAL_HOURS`) sowie Downloads signierter Releases	Release-Kanal, Komponente und aktuelle Version
Container-Registries wie `ghcr.io`	Herunterladen von Opfield-Release-Images	Gewöhnliche Image-Pull-Anfragen
Cloud-Konto (`account.opfield.dev`), erst nachdem ein Administrator die Installation mit der Opfield Cloud verbunden hat	Anzeige der Installation in Ihrem Cloud-Konto und, wenn die Fernverwaltung erlaubt ist, Registrierung von Nodes und Starten von Updates	Zustand der Installation, ihre Dienstliste und Container-Logs, wenn das Konto danach fragt; jede Anfrage wird im Audit-Log erfasst
Dienste zur Ermittlung der öffentlichen IP	Erkennung der öffentlichen Adressen von Opfield und verwalteten Nodes	Gewöhnliche HTTPS-Anfragen; das Opfield-Backend überspringt die Ermittlung, wenn sowohl `PUBLIC_IPV4` als auch `PUBLIC_IPV6` gesetzt sind

Opfield führt eine signierte Liste der Adressen des Lizenzdienstes und verwendet die, die antwortet; eine Egress-Allowlist benötigt license.opfield.dev. LICENSE_SERVICE_URL in .env, zum Beispiel ein Egress-Proxy, wird zuerst versucht.

Das Installationsskript kontaktiert nur den Update-Dienst, Container-Registries und Docker-Paketquellen; Opfield registriert sich kurz nach seinem ersten Start beim Lizenzdienst. Lizenz- und Update-Dienst erhalten keine Infrastrukturkonfiguration, Ressourceninhalte, Secrets, Logs, Prompts oder Modellantworten. Opfield enthält keine Nutzungstelemetrie und keinen Client für Absturzberichte. Wenn AI Workspace oder Opfield Inference aktiviert ist, gehen Prompts an die Modellanbieter, die ein Administrator konfiguriert, nicht an das Opfield-Team.

Antworten des Lizenzdienstes sind signierte Lizenzzustände. Opfield hinterlegt die öffentlichen Ed25519-Schlüssel des Dienstes fest und akzeptiert einen Zustand nur, wenn er für diese Installation und Anfrage signiert und höchstens 15 Minuten abweichend von der lokalen Uhr ausgestellt wurde; es lehnt unsignierte, gefälschte, wiederholte oder fremde Zustände ab und prüft gespeicherte Zustände bei jedem Lesen der Lizenz erneut. Siehe Signierte Lizenzzustände.

Beispiele für Ablehnung im Zweifel

Opfield lehnt Operationen ab oder stellt sie zurück, wenn es aktuelle Zuständigkeit, Node-Fähigkeit, Leistungsumfang des Tarifs, Kompatibilität von Anbieter und Modell, Herkunft eines signierten Updates, Identität der Netzwerkquelle oder erforderliche Autorisierung nicht nachweisen kann. Zwischengespeichertes Inventar kann zur Diagnose sichtbar bleiben, autorisiert aber keine Änderung.

Verfügbarkeitsprobleme dürfen nicht „behoben“ werden, indem anonyme Listener eingeführt, die Zertifikatsprüfung deaktiviert, private Ports offengelegt oder Owner-Zugangsdaten in Workloads kopiert werden.

Grenzen der Sicherheit

Opfield kann keinen kompromittierten Administrator-Endpunkt, kein bösartiges root auf dem Host, keinen uneingeschränkten Eigentümer des Docker-Sockets, keinen kompromittierten externen Identitätsanbieter und keine Daten schützen, die ein autorisierter Benutzer bewusst exportiert. Verwenden Sie unabhängige Host-Härtung, Netzwerksegmentierung, Endpunktsicherheit, Backups und organisatorische Kontrollen.

Checkliste für Sicherheitsentscheidungen

Bevor Sie Opfield für eine Produktionsumgebung einführen, ermitteln Sie, wer den Opfield-Host, Relay, jeden verwalteten Host, den externen Identitätsanbieter, Quellcodeverwaltungen, DNS, E-Mail, KI-Anbieter und den Backup-Speicher kontrolliert. Dokumentieren Sie, welche Parteien Anwendungsdaten oder Zugangsdaten im Klartext erhalten können. Ist eine Person oder ein System für mehrere Grenzen zuständig, halten Sie diese Konzentration von Rechten fest, statt anzunehmen, dass Produkt-Scopes sie beseitigen.

Beantworten Sie für jede neue Funktion vier Fragen:

Welche Daten oder Infrastruktur kann sie erreichen?
Welche Zugangsdaten autorisieren diesen Zugriff, und wo werden sie gespeichert?
Welcher Audit- oder Task-Beleg weist nach, was geschehen ist?
Was bleibt betriebsbereit, und was muss abgelehnt werden, wenn die Abhängigkeit nicht verfügbar ist?

Prüfen Sie das Modell nach wesentlichen Änderungen an Topologie, Identität, Anbietern oder Leistungsumfang erneut. Ein Entwurf, der für einen Ingress und eine private Datenbank genehmigt wurde, ist möglicherweise nicht mehr angemessen, nachdem Build Worker, öffentlicher Datenbankzugriff, externe KI-Anbieter oder teamübergreifende Automatisierung hinzugekommen sind.

Absicherung durch Operatoren

Testen Sie Ablehnungen ebenso bewusst wie Erfolge: einen Benutzer ohne Scope, ein widerrufenes Token, einen Node mit veralteten Fähigkeitsdaten, ein unsigniertes oder nicht passendes Update, einen Workload ohne Binding-Identität und ein privates ausgehendes Ziel außerhalb der Richtlinie. Bewahren Sie die entstehenden Audit- und Fehlerbelege auf. Sicherheitskontrollen, die nie unter Fehlerbedingungen erprobt wurden, sollten als Annahmen gelten.