Internet- und Netzwerkzugang

Ca. 11 Min. Lesezeit

Die Weboberfläche von 2WinScada steuert reale Anlagen. Diese Seite beschreibt, was der Integrator tun muss, bevor von außerhalb des Anlagennetzes auf den Server zugegriffen wird, und wie die HTTPS-Zertifikate verwaltet werden. Setup und Haupt-API bieten eine Grundhärtung; wichtiger sind jedoch das Netzwerkdesign und die Disziplin bei den Konten.

Veröffentlichen Sie den Server nicht direkt

Am sichersten ist es, den Server überhaupt nicht ins Internet zu stellen. Betreiben Sie den Server hinter einem VPN (WireGuard, IPsec oder dem VPN der Firewall) oder einem Zero-Trust-Tunnel; die Anmeldeseite sollen nur authentifizierte Personen erreichen.

Empfohlene Reihenfolge

1. Betreiben Sie den Server hinter einem VPN oder einem Zero-Trust-Tunnel.
2. Ist eine direkte Veröffentlichung unumgänglich, leiten Sie nur den Port TCP 443 an den Server weiter. Siehe Ports.
3. Verwenden Sie für den öffentlichen DNS-Namen ein vertrauenswürdiges Zertifikat. Siehe Zertifikat und HTTPS.
4. Führen Sie Setup mit dem Internetprofil und nach Möglichkeit mit der Netzwerkbeschränkung für SystemAdmin aus. Siehe Setup-Einstellungen.
5. Setzen Sie die Regeln für Konten, Sicherungen und Updates um.
6. Führen Sie die Erreichbarkeitsprüfung aus und beheben Sie vor der Inbetriebnahme alle Warnungen. Siehe Erreichbarkeitsprüfung.

Ports

Port	Zweck	Weiterleiten?
TCP 443	Weboberfläche, API und Live-Datenverbindung (HTTPS)	Ja
TCP 80	Im Internetprofil nur Umleitung auf HTTPS	Optional

Leiten Sie die folgenden Ports niemals ins Internet weiter. Es sind interne Ports, die nur für die Verwendung innerhalb des Servers oder im vertrauenswürdigen Netz vorgesehen sind:

Port	Dienst
TCP 7100	Haupt-API-Dienst (wird über IIS genutzt)
TCP 7101 / 7105	Interne Dienstports
TCP 7102 / 7103	Notification- / RecordDevice-Dienst
TCP 7106 / 7107	MQTT Publisher / MCP Server
TCP 9000, 9003, 8812, 9009	Archivdatenbank (QuestDB)
TCP 1433, UDP/TCP 1434	SQL Server und SQL Server Browser
TCP 3389	Remotedesktop (nur über VPN verwenden)
TCP 1883 / 8883	MQTT-Broker (sofern er nicht bewusst mit eigenem TLS und eigener Authentifizierung veröffentlicht wird)

Während des Setups geänderte Ports ersetzen diese Standardwerte. Prüfen Sie neben dem Router auch die Windows-Firewall: Eine eingehende Regel, die im Profil Öffentlich (Public) alle Ports zulässt, hebt die Beschränkung im Router auf.

Ausgehende Verbindungen

Werden Alarmbenachrichtigungen per WhatsApp verwendet, erlauben Sie vom Server, auf dem der Benachrichtigungsdienst (NotificationService) läuft, ausgehende HTTPS-Verbindungen (TCP 443) zur Adresse graph.facebook.com. Dafür sind keine eingehenden Verbindungen oder Portweiterleitungen erforderlich. Hat das Anlagennetz keinen direkten Internetzugang, stellen Sie den ausgehenden Zugang über eine DMZ oder einen Unternehmens-Proxy bereit. Siehe WhatsApp-Einstellungen.

Zertifikat und HTTPS

Vertrauenswürdiges Zertifikat

• Beziehen Sie für den öffentlichen DNS-Namen (zum Beispiel scada.example.com) ein Zertifikat von einem kommerziellen Zertifikatsanbieter oder verwenden Sie Let's Encrypt mit win-acme. Exportieren Sie das Zertifikat zusammen mit dem privaten Schlüssel als PFX.
• Geben Sie die PFX-Datei bei der Erstinstallation auf der Seite IIS und SSL des Assistenten über die Option Vorhandenes PFX-Zertifikat verwenden an.
• Das Zertifikat muss die primäre Adresse und alle veröffentlichten zusätzlichen DNS-Namen abdecken. Ist die primäre Adresse eine IP-Adresse, muss auch diese IP im Zertifikat enthalten sein.
• Veröffentlichen Sie einen aus dem Internet erreichbaren Server nicht mit einem selbstsignierten Zertifikat.

Selbstsigniertes Zertifikat

Innerhalb des Anlagennetzes kann die Option Selbstsigniertes Zertifikat erstellen verwendet werden. Browser vertrauen diesem Zertifikat nicht und zeigen eine Warnung an. Setup fügt das Zertifikat nicht dem Speicher für vertrauenswürdige Stammzertifikate der Clients oder des Servers hinzu. So entfernen Sie die Warnung:

1. Suchen Sie im Installationsprotokoll (%ProgramData%\2WinScada\Logs\setup.log) den Fingerabdruck (Thumbprint) des Zertifikats.
2. Öffnen Sie auf dem Server certlm.msc und exportieren Sie unter Eigene Zertifikate > Zertifikate das Zertifikat mit diesem Fingerabdruck ohne privaten Schlüssel als .cer-Datei.
3. Importieren Sie diese Datei gemäß der Unternehmensrichtlinie nur auf den Clients, die auf den Server zugreifen, in den Speicher Vertrauenswürdige Stammzertifizierungsstellen.

Verteilen Sie weder den privaten Schlüssel noch die PFX-Datei an die Clients. Wird das Zertifikat erneuert, aktualisieren Sie auch das Vertrauen auf den Clients.

Zertifikat erneuern und austauschen

Setup ändert ein an die Website gebundenes Zertifikat niemals; selbst wenn bei einer Reparatur eine neue PFX-Datei angegeben wird, bleibt das vorhandene Zertifikat erhalten. Binden Sie das erneuerte Zertifikat selbst, bevor das alte abläuft:

1. Wählen Sie im Internetinformationsdienste (IIS)-Manager die 2WinScada-Website aus.
2. Wählen Sie im Fenster Sitebindungen (Bindings) den Eintrag https und anschließend das neue Zertifikat aus.

Wird win-acme verwendet, kann es das Zertifikat automatisch erneuern und binden. Beim Wechsel von einem selbstsignierten zu einem vertrauenswürdigen Zertifikat gehen Sie genauso vor; führen Sie anschließend mit Setup eine Reparatur aus, damit HSTS aktiviert wird.

Ist das gebundene Zertifikat abgelaufen, bricht die Reparatur bei der Vorprüfung ab; binden Sie zuerst ein gültiges Zertifikat.

HSTS

Der HSTS-Header, der dem Browser mitteilt, ausschließlich HTTPS zu verwenden, wird nur gesendet, wenn das Internetprofil aktiviert ist und alle öffentlichen Namen ein von einem vertrauenswürdigen Zertifikatsanbieter ausgestelltes Zertifikat liefern. Setup prüft bei jeder Installation, Reparatur und jedem Upgrade das an IIS gebundene Zertifikat. Bei einem selbstsignierten Zertifikat verhindert das Internetprofil die Installation nicht, HSTS bleibt jedoch deaktiviert, und Setup schreibt eine Warnung ins Protokoll.

WARNING

Bei aktivem HSTS lassen Browser nicht zu, dass eine Zertifikatswarnung übergangen wird. Läuft das Zertifikat ab, öffnet sich die Website nicht. Erneuern Sie das Zertifikat rechtzeitig.

Setup-Einstellungen

Die Einstellungen für den Internetzugang befinden sich auf der Seite Erweiterte Einstellungen des Assistenten. Die Optionen für MCP und unverschlüsseltes HTTP sind nur aktiv, wenn das Internetprofil aktiviert ist. Bei Reparatur und Upgrade behalten diese Optionen ihre bisherigen Werte.

Option im Assistenten	Einstellung für die unbeaufsichtigte Installation	Wirkung
Internetprofil: diesen Server für direkten Internetzugriff härten	INTERNET_PROFILE=1	Leitet HTTP-Anfragen auf HTTPS um, verhindert die Anzeige der Website in einem Rahmen (iframe) anderer Websites, lässt die Haupt-API nur auf diesem Computer (127.0.0.1) lauschen und sendet HSTS, wenn ein vertrauenswürdiges Zertifikat gebunden ist.
/mcp im Internet veröffentlichen	MCP_PUBLIC_ROUTE=1	Veröffentlicht den MCP-Endpunkt auf der Internetsite. Lassen Sie die Option deaktiviert, sofern nicht tatsächlich ein KI-Client von außerhalb des Netzes benötigt wird.
HTTP erlauben (keine Umleitung)	In der mit dem Produkt installierten Hilfe	Lässt unverschlüsselten HTTP-Zugriff offen; HTTPS-Umleitung und HSTS werden nicht angewendet. Nicht empfohlen: Anmeldedaten werden unverschlüsselt übertragen. Die Entscheidung zur Aktivierung verantworten der Installierende und der Kunde.
SystemAdmin-Anmeldung nur aus diesen Netzen (optional, CIDR)	ADMIN_ALLOWED_NETWORKS	Die SystemAdmin-Anmeldung wird nur aus den aufgeführten Netzen und vom Server selbst angenommen.

Für die Netzliste von SystemAdmin gilt:

• Trennen Sie die Netze mit ; oder ,, zum Beispiel 192.168.1.0/24;10.8.0.0/16. Verwenden Sie für einen einzelnen Computer /32.
• Bleibt das Feld leer, wird der installierte Wert beibehalten.
• Ist die Liste gefüllt, werden MCP-Schlüssel von SystemAdmin-Konten von jeder Adresse abgelehnt.
• Erscheint im Setup-Protokoll eine Warnung zu dieser Liste, wenden Sie sich an den 2WinScada-Support und beschränken Sie den Zugriff zusätzlich über VPN oder Firewall.

Nach der Aktivierung des Internetprofils können Clients die API nur noch über die Adresse https://<öffentlicher Name>/api erreichen; stellen Sie Integrationen, die die API direkt über ihren internen Port nutzen, auf diese Adresse um. Zeigt ein anderes Portal SCADA-Bildschirme in einem iframe an, verwenden Sie auf diesem Server kein Internetprofil oder gewähren Sie den Zugriff über VPN.

Um das Internetprofil in einer vorhandenen Installation zu aktivieren, führen Sie mit dem Paket derselben Version eine Reparatur oder mit dem Paket einer neueren Version ein Upgrade aus. Beispiel für eine unbeaufsichtigte Reparatur:

2WinScada.Setup.2.10.0.x64.exe /S /MODE=Repair /INTERNET_PROFILE=1 /MCP_PUBLIC_ROUTE=0 /ADMIN_ALLOWED_NETWORKS="10.8.0.0/16"

Geben Sie die Netzliste in der Befehlszeile in Anführungszeichen an.

Schutzmaßnahmen bei jeder Installation

Unabhängig davon, ob das Internetprofil aktiviert ist:

• Externe Systeme greifen über die Haupt-API auf die Dienste Notification und RecordDevice zu.
• Die Website sendet Sicherheitsheader und verbirgt die Versionsinformationen des Servers.
• Von Benutzern hochgeladene Dateien werden mit einer eingeschränkten Sicherheitsrichtlinie ausgeliefert.
• Der Health-Endpunkt von QuestDB ist nur von diesem Computer aus erreichbar.

Konten, Rollen und Schlüssel

• Geben Sie jeder Person ein eigenes Konto. Erteilen Sie dem Bedienpersonal die Rolle Monitor oder Operate. Erteilen Sie die Rolle Editor nur Ingenieuren, die Seiten gestalten; mit dieser Rolle können Dateien auf die Website hochgeladen werden. Erteilen Sie die Rolle UserAdministrator nur Personen, die Konten verwalten.
• Das bei der Installation angelegte erste Administratorkonto ist ein SystemAdmin-Konto. Verwenden Sie dieses Konto nur für die Verwaltung und mit einem langen, eindeutigen Passwort (mindestens 16 Zeichen empfohlen), und bewahren Sie das Passwort in einem Passwortmanager auf. Legen Sie für die Administratoren des Kunden eigene Konten in der Gruppe Administrators an.
• Verwenden Sie SCADA-Passwörter nicht in anderen Systemen. Entfernen Sie die Konten und API-Schlüssel ausgeschiedener Personen.
• Legen Sie bei API- und MCP-Schlüsseln für jeden Client einen eigenen Schlüssel mit der kleinstmöglichen Rolle an. Löschen Sie nicht verwendete Schlüssel. Versenden Sie Schlüssel nicht per E-Mail und nehmen Sie sie nicht in Screenshots oder Supportanfragen auf.
• Auch wenn eine reine Leseüberwachung veröffentlicht wird, sollten Schreib- und Steuerbefehle von außen bevorzugt nur VPN-Benutzern möglich sein.

Kontoverwaltung: Benutzer- und Gruppenverwaltung.

Browsersitzung

Ab 2.11 speichert die Weboberfläche den Schlüssel zur Sitzungserneuerung nicht mehr im Browserspeicher. Der Schlüssel bleibt in einem Cookie (HttpOnly), das Skripte auf der Seite (auch Ereigniscode) nicht lesen können. Der Zugriffsschlüssel ist für jeden Browser-Tab getrennt; ein neuer Tab oder ein neu gestarteter Browser öffnet die Sitzung selbstständig aus dem Cookie. Vor dem Upgrade geöffnete Sitzungen arbeiten bis zur nächsten Anmeldung auf die bisherige Weise (siehe Versionsaktualisierung).

Diese Änderung verhindert, dass der langlebige Erneuerungsschlüssel kopiert wird. Solange die Seite geöffnet ist, können Skripte auf der Seite (auch Ereigniscode) den Zugriffsschlüssel des Tabs bis zu seinem Ablauf (standardmäßig 4 Stunden) lesen und im Namen der Sitzung Anfragen senden. Unter 2.11 können nur SystemAdmin-Konten Ereigniscode hinzufügen oder ändern; siehe Ereigniscode.

• HTTPS wird empfohlen. Auf einer über HTTPS geöffneten Seite wird das Cookie nur über eine verschlüsselte Verbindung gesendet. Bei einfachem HTTP werden Cookie und Anmeldedaten unverschlüsselt im Netzwerk übertragen.
• Weboberfläche und API müssen auf derselben Website liegen: dasselbe Schema (http oder https) und derselbe Domainname; der Port darf abweichen. In der von Setup eingerichteten Struktur wird die API unter derselben Adresse wie die Website veröffentlicht, und es ist keine weitere Einstellung nötig. In älteren Installationen, in denen die Weboberfläche die API über einen anderen Port aufruft, öffnen Sie die Oberfläche mit dem Namen und dem Schema der API-Adresse; wird die API zum Beispiel über einen Servernamen aufgerufen, öffnen Sie die Oberfläche nicht über die IP-Adresse. Andernfalls sendet der Browser das Cookie nicht, und die Sitzung endet bei der ersten Erneuerung. Das Cookie wird nicht nach Port getrennt: Sind zwei Installationen unter demselben Servernamen, aber mit verschiedenen Ports (zum Beispiel Produktion und Test) gleichzeitig im selben Browserprofil geöffnet, überschreiben sie gegenseitig ihr Cookie, und Sitzungen enden unerwartet. Öffnen Sie solche Installationen unter verschiedenen Servernamen oder in getrennten Browserprofilen.
• Pro Konto gibt es einen einzigen Erneuerungsschlüssel. Jede Anmeldung mit einem Konto erzeugt einen neuen Schlüssel; Geräte, die sich früher mit demselben Konto angemeldet haben, verlieren ihre Sitzung bei der nächsten Erneuerung, spätestens nach Ablauf der Zugriffsdauer (standardmäßig 4 Stunden). Eine Abmeldung macht nur den Schlüssel dieses Browsers auf dem Server ungültig; eine Abmeldung an einem Gerät, das sich früher am Konto angemeldet hat, ändert auf dem Server nichts. Zu gemeinsam genutzten Kiosk-Konten siehe Sitzungserneuerung und gemeinsam genutzte Konten.
• MCP- und API-Clients sind nicht betroffen. Anmelde- und Token-Aktualisierungsaufrufe funktionieren wie bisher mit den Token im Body (siehe REST-API).

Sicherungen und Updates

• Lassen Sie die geplante Konfigurationssicherung aktiviert; sichern Sie die SQL-Server-Datenbank und den QuestDB-Datenordner. Bewahren Sie mindestens eine Kopie außerhalb des Servers auf und testen Sie einmal eine Wiederherstellung. Siehe Sicherung und Wiederherstellung.
• Installieren Sie Windows-Updates monatlich und 2WinScada-Updates bei ihrer Veröffentlichung. Bei einem Upgrade bleiben die Interneteinstellungen erhalten. Siehe Versionsaktualisierung.
• Lassen Sie Windows Defender bzw. den Virenschutz aktiviert. Verwenden Sie den Server nicht für E-Mail oder zum Surfen im Web.
• Verwenden Sie Remotedesktop nur über VPN und mit Authentifizierung auf Netzwerkebene (NLA).

Anmeldeereignisse überwachen

Die Haupt-API schreibt Anmeldeereignisse (erfolgreiche und fehlgeschlagene Anmeldungen, Sperren, ungültige API-Schlüssel) in die Protokolldateien. Passwörter, Codes, Token und Schlüssel werden nicht protokolliert. Jeder Eintrag enthält den Benutzernamen und die Client-Adresse. Die Namen und Einzelheiten der Ereignisse beschreibt die mit dem Produkt installierte Hilfe.

Prüfen Sie die Protokolle wöchentlich. Viele fehlgeschlagene Anmeldungen von derselben Adresse, Adresssperren oder Anmeldungen zu ungewöhnlichen Zeiten sind Anzeichen eines Angriffs; blockieren Sie diese Adressen in der Firewall oder stellen Sie auf reinen VPN-Zugang um.

Erreichbarkeitsprüfung

Das Installationspaket enthält ein Skript, das nur lesend arbeitet und die von außen erreichbare Angriffsfläche des Servers prüft. Das Skript ändert keine Einstellungen; es prüft offene interne Ports, Firewall-Regeln, die Remotedesktop-Einstellung, das Zertifikat und die Veröffentlichung der Website. Führen Sie die Prüfung vor der Inbetriebnahme aus, beheben Sie alle Warnungen und bewahren Sie den Bericht mit den Inbetriebnahmeunterlagen auf. Die Verwendung des Skripts beschreibt die mit dem Produkt installierte Hilfe.

Checkliste für die Inbetriebnahme

• [ ] Ein VPN oder Zero-Trust-Tunnel ist eingerichtet, oder nur Port 443 (optional 80) wird weitergeleitet.
• [ ] Ein vertrauenswürdiges Zertifikat ist gebunden; die Website öffnet sich unter dem öffentlichen Namen ohne Warnung.
• [ ] Setup wurde mit dem Internetprofil ausgeführt; über die Veröffentlichung von MCP wurde entschieden; bei festen Netzen ist die Netzliste für SystemAdmin festgelegt, und im Setup-Protokoll gibt es keine Warnung zu dieser Liste.
• [ ] Die Adresse http://<öffentlicher Name>/ wird auf HTTPS umgeleitet (oder unverschlüsseltes HTTP wurde bewusst offen gelassen und mit dem Kunden dokumentiert).
• [ ] Nach der Anmeldung öffnet sich die Sitzung in einem neuen Browser-Tab ohne Anmeldung (Weboberfläche und API liegen auf derselben Website).
• [ ] Die Konten sind persönlich und haben die kleinstmöglichen Rollen; SystemAdmin wird nur für die Verwaltung verwendet; nicht verwendete Konten und Schlüssel sind entfernt.
• [ ] Sicherungen sind geplant, und eine Wiederherstellung wurde getestet.
• [ ] Eine Testanmeldung erscheint im Protokoll als erfolgreiche Anmeldung mit der tatsächlichen Client-Adresse.
• [ ] Die Erreichbarkeitsprüfung zeigt keine Warnungen.