Checkliste zur Härtung

Härtung bedeutet, vermeidbare Rechte zu verringern und die Wiederherstellung vor einem Vorfall vorhersehbar zu machen. Der Sicherheitsverantwortliche genehmigt Ausnahmen, der Plattformverantwortliche setzt Host- und Netzwerkkontrollen um, und die Dienstverantwortlichen weisen nach, dass strengere Kontrollen benötigte Abläufe nicht unterbrechen. Priorisieren Sie Kontrollen nach Auswirkung auf Kunden und Reichweite von Zugangsdaten, nicht nach der Länge der Checkliste.

Beginnen Sie mit den Grenzen, die die gesamte Installation kompromittieren können: Zugriff auf den Opfield-Host, Administratoridentitäten, Verschlüsselungs- und PKI-Schlüssel, PostgreSQL, Redis, Relay-Identität und Backup-Speicher. Härten Sie dann Rollen verwalteter Nodes, Workloads, Anbieter und Automatisierung.

• Halten Sie Opfield- und Daemon-Hosts gepatcht und, wo praktikabel, ihren Rollen vorbehalten.
• Beschränken Sie PostgreSQL und Redis auf das private Anwendungsnetzwerk.
• Legen Sie nur die HTTPS- und Relay-Ports offen, die das Deployment benötigt.
• Verlangen Sie MFA für Administratoren und halten Sie den Kreis der Administratoren klein.
• Bewahren Sie Master-Schlüssel und Backups außerhalb des Opfield-Hosts auf.
• Verwenden Sie Dienst-Zugangsdaten mit Ressourcen-Scope und kurze Rotationsintervalle.
• Bevorzugen Sie unveränderliche Image-Digests und dedizierte Build Worker.
• Verbieten Sie Host-Bind-Mounts sowie privilegierten und Gerätezugriff, es sei denn, ein ausdrücklich unterstützter Ablauf erfordert sie.
• Halten Sie verwaltete Datenbanken privat und verwenden Sie Binding-Identitäten.
• Lassen Sie die Prüfung von TLS-Zertifikaten für externe Datenbankverbindungen eingeschaltet und schalten Sie sie für Verbindungen ein, die nach einem Upgrade auf 2.11 TLS certificate is not verified anzeigen.
• Überwachen Sie die automatische Verlängerung der Zertifikate von Opfield, Relay und Daemons und bewahren Sie die System-PKI für den internen Transport; siehe Nodes: Verlängerung von Zertifikaten.
• Senden Sie Audit-Ereignisse bei Bedarf an ein unabhängig kontrolliertes SIEM.
• Prüfen Sie regelmäßig Quell-Integrationen, Registry-Zugangsdaten, OAuth-Clients, Tokens und aktive Sitzungen.
• Behandeln Sie API-Tokens und OAuth-Berechtigungen mit administrativen Scopes wie admin:system, admin:users, settings:opfield:edit oder nodes:manage als Administrator-Zugangsdaten: Seit 2.11 kann programmatischer Zugriff sie tragen. Geben Sie jedem einen Verantwortlichen, ein Ablaufdatum und den engsten Ressourcen-Scope.
• Entfernen Sie nach Vorfällen vorübergehende Wartung, Offenlegungen zur Fehlersuche und manuelle Änderungen am Host.

Veröffentlichen Sie keine Screenshots, Support-Pakete oder Logs, bevor Secrets, interne Adressen, Kundennamen und Repository-URLs geschwärzt wurden.

Control Plane

• Betreiben Sie Opfield auf einer dedizierten VM oder einem dedizierten Host und beschränken Sie direkten Shell- und Docker-Zugriff.
• Halten Sie PostgreSQL, Redis, internes gRPC und den Inferenzkern in privaten Netzwerken.
• Schützen Sie .env, Verschlüsselungsschlüssel, PKI-Schlüssel, hochgeladene Artefakte und die Relay-Identität durch restriktive Eigentümerrechte und Backups.
• Verwenden Sie HTTPS für die kanonische öffentliche URL und prüfen Sie das Verhalten von Cookies, WebSockets, OAuth und Proxy.
• Deaktivieren Sie ungenutzte Authentifizierungsmethoden und Integrationen.

Verwaltete Nodes

• Verwenden Sie eine Registrierungsidentität pro Host-Rolle und kopieren Sie Daemon-Zertifikate nie zwischen Hosts.
• Beschränken Sie ausgehende Ziele, wo praktikabel, auf Opfield/Relay und benötigte Anbieter.
• Schützen Sie systemd-Units, Konfiguration, Vertrauensanker für Updates, Laufzeit-Sockets und lokalen Speicher.
• Halten Sie die Rollen Ingress, Build Worker, Storage und Relay entsprechend ihrem Risiko voneinander isoliert.
• Alarmieren Sie bei veralteter letzter Meldung, eingeschränkten Fähigkeiten, Festplattendruck und Update-Inkompatibilität.

Workloads und Builds

• Bevorzugen Sie per Digest festgelegte Images und prüfen Sie Quelle, Build-Logs, Schwachstellenrichtlinie und Herkunftsgrenzen.
• Führen Sie Git-Builds nur auf dedizierten Build Workern aus.
• Verwenden Sie verwaltete Volumes statt Host-Bind-Mounts.
• Gewähren Sie keinen privilegierten Modus, keine beliebigen Geräte, kein Host-Netzwerk und keinen Zugriff auf das Host-Dateisystem ohne eine ausdrückliche, unterstützte Anforderung.
• Speichern Sie Laufzeit- und Build-Secrets über ihre getrennten verschlüsselten Wege.

Daten und private Konnektivität

• Lassen Sie verwaltete Datenbanken standardmäßig unveröffentlicht.
• Verwenden Sie eine Binding-Identität pro Anwendungsbeziehung und prüfen Sie, dass Owner-Zugangsdaten nie in die Workload-Konfiguration gelangen.
• Schützen Sie die Opfield-eigenen Verbindungsnetzwerke und den Secure-Link-Connector vor Lebenszyklusaktionen von Benutzern.
• Sichern Sie Anwendungsdaten über engine-native Verfahren und testen Sie die Wiederherstellung unabhängig von der Wiederherstellung von Opfield.
• Lassen Sie direktes Datenbank-TLS eingeschaltet, es sei denn, eine bewusste Ausnahme für ein privates Netzwerk ist dokumentiert.

Betriebliche Absicherung

Prüfen Sie nach einem festen Zeitplan Administratormitgliedschaften, Gruppen-Scopes, Tokens, OAuth-Clients, Quell-Integrationen, DNS-Connectors, SMTP-Zugangsdaten, SIEM-Ziele und aktive Sitzungen. Testen Sie Ablehnungspfade mit Identitäten ohne Administratorrechte.

Führen Sie Übungen zu Vorfall, Wiederherstellung, Update, Relay-Failover, Node-Neustart, Neuerstellung von Workloads und Wiederherstellung von Datenbank-Bindings durch. Entfernen Sie vorübergehenden Zugriff zur Fehlersuche und dokumentieren Sie jede akzeptierte Ausnahme mit Verantwortlichem und Ablaufdatum.

Umgang mit Ausnahmen

Manche Workloads benötigen eine Kontrolle, die die Standardrichtlinie vermeidet, etwa eine direkte Veröffentlichung der Datenbank, Host-Netzwerk, ein Gerät oder breiteren Zugriff auf Anbieter. Behandeln Sie das als geprüfte Ausnahme, nicht als versteckten Schalter. Halten Sie die geschäftliche Anforderung, die betroffenen Ressourcen, die eingeführte Bedrohung, ausgleichende Kontrollen, den genehmigenden Verantwortlichen, das Prüfdatum und den Auslöser für die Entfernung fest.

Schwächen Sie nicht einen ganzen Node oder eine ganze Installation, um einen Workload unterzubringen, wenn ein dedizierter Node, ein Netzwerksegment oder ein externer Dienst die Ausnahme isolieren kann. Prüfen Sie Ausnahmen nach Änderungen an Anwendung, Laufzeit, Node-Rolle oder Anbieter erneut.

Prüfung und Wiederherstellung

Weisen Sie für jede Härtungsmaßnahme sowohl die beabsichtigte Operation als auch die erwartete Ablehnung nach. Prüfen Sie die Wiederherstellung für Administratoren nach dem Deaktivieren ungenutzter Authentifizierung, die Wiederherstellung von Workloads nach dem Entfernen des Host-Zugriffs, das Build-Verhalten unter Egress-Einschränkungen, die Zertifikatsverlängerung mit eingeschränkten DNS-Zugangsdaten und den Datenbankzugriff über Binding-Identitäten nach Neustarts von Node und Workload.

Halten Sie eine Wiederherstellungsmethode vor, die nicht von der zu reparierenden Komponente abhängt. Backup-Schlüssel müssen zugänglich sein, wenn der Opfield-Host verloren ist; die Wiederherstellung für Administratoren muss funktionieren, wenn OIDC oder E-Mail nicht verfügbar sind; engine-native Backups müssen wiederherstellbar sein, wenn die Control Plane nicht verfügbar ist. Bewahren Sie Belege auf und prüfen Sie sie nach einem festen Zeitplan.