Edge-Sicherheit

Das Cloud-Gateway prüft Connector-Zugangsdaten, Hardwareidentität, festen Bereich, aktive Dienstrechte, zugewiesene Arbeitsplätze und konfigurierte IP-Einschränkungen. Diese Kontrollen sichern nicht automatisch sämtliche lokalen Schnittstellen.

Lokale Netzwerkgrenze

Beide lokalen Schnittstellen sind standardmäßig deaktiviert. Für ihre Aktivierung ist eine private EDGE_LOCAL_PRINCIPALS_FILE erforderlich. Jede Maschine erhält ein eigenes zufälliges Token mit mindestens 32 Zeichen, eine eindeutige id, ausdrückliche workCenterIds und nur die benötigten Aktionen: read, production, station-progress, scrap, status. Platzhalterrechte für alle Arbeitsplätze gibt es nicht. Token einzeln rotieren und den Dienst anschließend neu starten.

REST benötigt PLC_REST_ENABLED=true, PLC_TLS_CERT und PLC_TLS_KEY. Standardbindung ist PLC_SERVER_HOST=127.0.0.1, Port 3005. Verwende ein vertrauenswürdiges HTTPS-Zertifikat und Authorization: Bearer <Maschinen-Token> auf jeder Route einschließlich Health. Anfragen mit Browser-Origin werden abgewiesen; es gibt keine freizügige CORS-Freigabe. Unverschlüsseltes HTTP ist ausschließlich auf einer wörtlichen Loopback-Adresse mit NODE_ENV=development und EDGE_ALLOW_INSECURE_LOOPBACK=true möglich und benötigt weiterhin Authentifizierung.

Eingehendes OPC UA benötigt OPCUA_SERVER_ENABLED=true, OPCUA_SERVER_CERT und OPCUA_SERVER_KEY. Standard ist OPCUA_SERVER_HOST=127.0.0.1, Port 4841, Pfad /UA/EnneaEdge. Angeboten wird ausschließlich SignAndEncrypt mit Basic256Sha256; anonyme Sitzungen sind deaktiviert. Maschinen-id als Benutzername, Token als Passwort verwenden. Das Client-Anwendungszertifikat gezielt in OPCUA_TRUST_DIR/server vertrauen und das Edge-Zertifikat auf der SPS freigeben. Unbekannte Zertifikate werden abgewiesen. Ausgehende SPS-Verbindungen verwenden den getrennten Speicher OPCUA_TRUST_DIR/client und ebenfalls diesen verschlüsselten Modus/diese Richtlinie.

Lesen ist auf die Schnittmenge aus lokalen Maschinenrechten und aktuellem Cloud-Cache begrenzt. Schreiben erfordert eine erlaubte Aktion, einen zugewiesenen Arbeitsplatz und einen dazu gehörenden gecachten Auftrag. Mengen sind ganze Zahlen zwischen 0 und 1.000.000; Stationsmeldungen müssen zur konfigurierten Station, Rolle und Reihenfolge passen. REST-JSON ist auf 16 KiB begrenzt. Jede Schreibanfrage benötigt eine eindeutige requestId mit 16–128 Zeichen (Buchstaben, Ziffern, Unterstrich oder Bindestrich) und einen timestamp in Unix-Millisekunden innerhalb von fünf Minuten zur Edge-Uhr. OPC-UA-Meldemethoden hängen diese beiden Argumente an. Uhren synchronisieren. Wiederholungsschutz und gepuffertes Ereignis werden gemeinsam in einer SQLite-Transaktion gespeichert. Wiederholte IDs ergeben REST 409 beziehungsweise einen fehlerhaften Methodenstatus, auch nach Neustart. Das garantiert keine exakt einmalige Verarbeitung in der Cloud.

Pro Maschine gelten 600 Anfragen/Minute, 120 Schreibanfragen/Minute und maximal 10 Schreibanfragen pro Sekunde. REST begrenzt zusätzlich auf insgesamt 1.200 Anfragen/Minute. Bei 429/fehlerhaftem Methodenstatus verzögern und unklare Ergebnisse mit unveränderter Anfragekennung abgleichen. Firewalls weiterhin auf genehmigte SPS beschränken; keine direkte Internetfreigabe.

Cloud-Zugriff nutzt die HTTPS- und WebSocket-Adressen der Bereitstellung. Erlaube nur vereinbarte Wege zwischen Rechner, Cloud, SPS und Druckern. TCP-Druckerziele können physische Aufträge auslösen und brauchen passende Einschränkungen.

Identität und Geheimnisse

Die Hardware-ID ist derzeit eine erzeugte gespeicherte Kennung, kein manipulationssicherer Hardwarefingerabdruck. Behandle Zustandsdatei und API-Schlüssel als Zugangsdaten. Eine Kopie kann die Identität auf einen anderen Rechner übertragen. Ersetze Rechner über ein bewusstes Bereitstellungsverfahren.

Zustand liegt standardmäßig unter ~/.ennea/edge oder EDGE_STATE_DIR. Der Dienst erzwingt private Verzeichnisse (0700), reguläre Dateien ohne zusätzliche Hardlinks (0600), atomaren Konfigurationsaustausch sowie entsprechende Windows-ACLs für Dienstidentität, SYSTEM und Administratoren. Symbolische Links/Reparse Points werden abgewiesen; bestehende Cache-/Logrechte werden vor dem Öffnen eingeschränkt. Beschränke .env, private Zertifikatschlüssel, edge-config.json, SQLite-Dateien und Protokolle auf Dienstkonto und berechtigte Administratoren. Nutze geschützten Speicher sowie das vereinbarte Verschlüsselungs- und Sicherungsverfahren. TLS für Cloud-Verkehr verschlüsselt nicht automatisch lokale Zustandsdateien.

Entferne Registrierungstokens nach der Einrichtung. Teile keine Schlüssel, Tokens, Zustandsdateien oder vollständigen Fertigungsinhalte in Tickets und öffentlichen Beispielen. Schütze Sicherungen entsprechend.

Begrenzte Rechte und Widerruf

Weise nur benötigte Arbeitsplätze und Dienstrechte zu. Registrierung erzeugt wartenden Zugriff; ein Administrator muss genehmigen und einrichten. Produktionsmeldungen, Störungen und Druck haben unterschiedliche Rechte.

Widerrufe bei kompromittierten oder ausgemusterten Rechnern Connector und relevante Dienstrechte. Rotiere Zugangsdaten über die erlaubte Verwaltung und installiere sie sicher. Bewahre gepufferte Arbeit für den Abgleich auf oder isoliere sie vor dem Löschen. Eine Konfigurationsänderung ruft bereits gesendete SPS- oder Druckerbefehle nicht zurück.

Bestehende Installationen aktualisieren

1. Dienst geordnet stoppen und Identität, SQLite-Datenbank sowie offene Ereignisse verschlüsselt sichern. Nicht neu registrieren und keine offenen Ereignisse verwerfen.
2. Ein eigenes dienstkontoeigenes Zustandsverzeichnis anlegen. edge-config.json, data/ und logs/ gemeinsam verschieben und EDGE_STATE_DIR auf den kanonischen Pfad setzen. Alte relative DATA_DIR/LOG_DIR entfernen oder auf die migrierten Verzeichnisse richten. Eine alte Konfiguration im Arbeitsverzeichnis stoppt den Start mit einem Migrationshinweis, statt unbemerkt eine neue Identität anzulegen.
3. Maschinenrechte als private JSON-Datei bereitstellen, etwa [{"id":"plc-a","token":"<zufaelliges-geheimnis-mit-mindestens-32-zeichen>","workCenterIds":["WC-A"],"actions":["read","production"]}]. Platzhalter ausschließlich lokal ersetzen; keine Tokens einchecken. Dateipfad in EDGE_LOCAL_PRINCIPALS_FILE setzen.
4. TLS-/OPC-UA-Zertifikate und gegenseitiges Vertrauen einrichten. SPS-Clients auf Zugangsdaten, Anfrage-IDs und Zeitstempel aktualisieren. Nur benötigte Schnittstellen aktivieren. Ausgehende Mappings von None/Sign/veralteten Richtlinien auf SignAndEncrypt/Basic256Sha256 umstellen. Unsichere/ungültige Konfigurationen werden abgewiesen; HTTPS-/WSS-Cloudweiterleitungen werden nicht verfolgt.
5. Mit eigenem Dienstkonto starten. Anonyme/falsch berechtigte Anfragen, erlaubtes Lesen und Zertifikatsvertrauen prüfen; anschließend eine genehmigte Meldung und ihr Cloud-Ergebnis verifizieren. Bei früher offengelegten Zugangsdaten diese über die freigegebenen Verwaltungswege rotieren.
6. Je Betriebssystem/Architektur ein separates Archiv mit pnpm --filter @ennea/edge-runtime package:runtime erstellen. Es enthält Node 24 und eine geprüfte native SQLite-Bindung. Prüfsumme/Manifest prüfen und start.sh oder start.cmd nutzen. Node-18/pkg-Programme werden nicht mehr gebaut. Vor Verteilung den Freigabe-Signaturprozess anwenden.

Windows muss das Setzen der Zustands-ACL für das Dienstkonto erlauben; andernfalls stoppt der Start. Dienstidentität und effektive ACLs auf dem Ziel-Windows-Rechner vor Inbetriebnahme prüfen. POSIX-Tests belegen keine Windows-Betriebsbereitschaft.

Aktualisierung und Wiederherstellung

Nutze eine vereinbarte Paketversion, erhalte den Zustand und prüfe Cloud- und SPS-Verhalten nach Updates. Prüfe einen repräsentativen Verbindungsabbruch und offene beziehungsweise nicht weiter verarbeitete Ereignisse. Pufferung garantiert keinen unbegrenzten Schutz vor Datenverlust.

Siehe Installation, API-Referenz und Fehlerbehebung.