Visual Planning sicher über das Internet bereitstellen – Anforderungen und Empfehlungen

Der Wunsch, einen Visual-Planning-Server über das Internet erreichbar zu machen, entsteht häufig durch den Einsatz von VPgo. Anwender sollen beispielsweise auch außerhalb des Unternehmensnetzwerks mobil auf ihre Planung zugreifen können.

Dabei ist ein wichtiger technischer Aspekt zu beachten:

Durch die Veröffentlichung wird nicht automatisch ausschließlich VPgo aus dem Internet erreichbar.

Ohne zusätzliche technische Maßnahmen wird grundsätzlich der Visual-Planning-Applikationsserver bzw. dessen Apache-Tomcat-Umgebung erreichbar gemacht. Abhängig von der Konfiguration können damit neben VPgo auch weitere Visual-Planning-Funktionen und Schnittstellen aus dem Internet angesprochen werden.

Dazu können beispielsweise gehören:

• VPgo
• der Visual Planning Rich Client
• API-Schnittstellen
• weitere von Visual Planning bereitgestellte Web- und Schnittstellenendpunkte
• URL-basierte Exporte und Aufrufe
• kundenspezifische Schnittstellen oder Erweiterungen, die über dieselbe Serverumgebung bereitgestellt werden

VPgo ist damit häufig die Motivation für die Internetfreigabe, aber nicht zwangsläufig deren einzige technische Auswirkung.

Welche zusätzlichen Anforderungen entstehen durch die Internetfreigabe?

Ein ausschließlich intern erreichbarer Visual-Planning-Server kann normalerweise nur aus dem eigenen bzw. einem verbundenen Netzwerk angesprochen werden.

Wird Visual Planning über das Internet bereitgestellt, erweitert sich der Kreis der grundsätzlich erreichbaren Systeme. Damit steigen die Anforderungen an Absicherung, Aktualisierung und Überwachung der Serverumgebung.

Das ist keine Besonderheit von Visual Planning oder VPgo, sondern gilt grundsätzlich für Anwendungen, die aus dem Internet erreichbar gemacht werden.

Für den sicheren Betrieb ist dabei nicht nur Visual Planning selbst relevant. Zur Serverplattform gehören mehrere Komponenten:

• Visual Planning
• VPgo
• Apache Tomcat
• Java Runtime bzw. JDK
• Betriebssystem und Systembibliotheken
• Webserver bzw. Reverse Proxy
• TLS-/HTTPS-Konfiguration
• Firewall und Netzwerkfreigaben

Für diese Komponenten werden regelmäßig Fehler und Sicherheitslücken bekannt und durch neue Versionen oder Sicherheitsupdates behoben.

Eine bei der Einrichtung aktuelle und sicher konfigurierte Installation muss deshalb auch im laufenden Betrieb regelmäßig gepflegt und aktualisiert werden.

Nicht jeder erreichbare Dienst muss auch aus dem Internet erreichbar sein

Eine wichtige Aufgabe bei der Veröffentlichung besteht darin, zunächst festzulegen, welche Visual-Planning-Funktionen tatsächlich von außen benötigt werden.

Soll beispielsweise lediglich VPgo extern verwendet werden, bedeutet dies nicht automatisch, dass auch Rich Client, APIs oder URL-basierte Funktionen frei aus dem Internet erreichbar sein müssen.

Umgekehrt kann ein externer Zugriff auf bestimmte APIs oder den Rich Client ausdrücklich gewünscht sein.

Entscheidend ist, dass die Veröffentlichung bewusst und kontrolliert erfolgt.

Es sollte insbesondere geprüft werden:

• Welche URLs und Endpunkte sind von außen erreichbar?
• Welche davon werden tatsächlich benötigt?
• Welche Authentifizierung ist für den jeweiligen Endpunkt erforderlich?
• Können nicht benötigte Zugriffswege gesperrt werden?
• Müssen bestimmte Schnittstellen auf einzelne IP-Adressen oder Netze eingeschränkt werden?
• Welche Endpunkte können über einen Reverse Proxy gezielt freigegeben bzw. blockiert werden?

Grundprinzip: Möglichst nur die Zugriffswege aus dem Internet bereitstellen, die für den jeweiligen Anwendungsfall tatsächlich benötigt werden.

Reverse Proxy statt direkter Tomcat-Freigabe

Wir empfehlen, einen Visual-Planning-Server nicht einfach über seinen Tomcat-Port im Internet bereitzustellen.

Eine typische Architektur ist:

Internet → Firewall → HTTPS / Reverse Proxy → Tomcat → Visual Planning

Der Reverse Proxy bildet eine kontrollierbare Schicht zwischen Internet und Visual-Planning-Applikationsserver.

Damit können beispielsweise:

• ausschließlich notwendige Dienste veröffentlicht,
• bestimmte URL-Pfade freigegeben oder gesperrt,
• Schnittstellen auf bestimmte Quell-IP-Adressen eingeschränkt,
• HTTPS zentral konfiguriert,
• Zugriffe protokolliert und
• interne Serverstrukturen vom Internet getrennt

werden.

Gerade wenn die ursprüngliche Motivation lediglich der Zugriff über VPgo ist, sollte geprüft werden, ob andere Visual-Planning-Zugriffswege ebenfalls öffentlich erreichbar sein sollen.

HTTPS verwenden

Visual Planning verarbeitet je nach Planung personenbezogene und betriebliche Daten. Der Zugriff über das Internet sollte deshalb ausschließlich verschlüsselt über HTTPS erfolgen.

Eine unverschlüsselte HTTP-Verbindung sollte nicht verwendet werden.

Auch das verwendete TLS-Zertifikat sowie dessen Ablaufdatum müssen überwacht und rechtzeitig erneuert werden.

Tomcat und Java regelmäßig aktualisieren

Besondere Bedeutung haben Apache Tomcat und Java, da sie wesentliche Bestandteile der Visual-Planning-Serverplattform darstellen.

Sicherheitskorrekturen für Apache Tomcat werden über aktualisierte Tomcat-Versionen bereitgestellt. Entsprechend sollte regelmäßig geprüft werden, ob die eingesetzte Version weiterhin aktuell und unterstützt ist.

Auch die eingesetzte Java-Version muss regelmäßig auf einen aktuellen Sicherheitsstand gebracht werden.

Dabei reicht es nicht aus, lediglich zu prüfen, ob Tomcat oder Java weiterhin funktionieren. Entscheidend ist auch, ob die eingesetzten Versionen noch unterstützt werden und aktuelle Sicherheitskorrekturen erhalten.

Eine technisch funktionierende Installation benötigt deshalb trotzdem regelmäßige Wartung.

Sicherheitsupdates und Visual-Planning-Kompatibilität

Updates der Serverkomponenten sollten gleichzeitig nicht ungeprüft auf einem produktiven Visual-Planning-System installiert werden.

Eine neue Java- oder Tomcat-Version kann Auswirkungen auf Visual Planning, VPgo, Rich Client, APIs oder kundenspezifische Erweiterungen haben.

Daraus ergeben sich zwei gleichermaßen wichtige Anforderungen:

Sicherheitsupdates sollten zeitnah installiert werden und gleichzeitig mit der eingesetzten Visual-Planning-Version kompatibel sein.

Vor größeren Versionswechseln sollte deshalb geprüft werden, welche Kombinationen aus Visual Planning, Java und Tomcat unterstützt bzw. getestet sind. Gegebenenfalls sollte ein Update zunächst in einer Testumgebung durchgeführt werden.

Firewall und Netzwerkzugriff begrenzen

Grundsätzlich sollte nach dem Prinzip gearbeitet werden:

Nur das freigeben, was tatsächlich benötigt wird.

Insbesondere Datenbankports, Tomcat-Verwaltung, SSH/RDP oder andere Administrationsschnittstellen gehören nicht ungeschützt ins öffentliche Internet.

Aber auch bei Visual-Planning-eigenen Diensten kann eine Einschränkung sinnvoll sein.

Beispielsweise kann es sinnvoll sein:

• VPgo allgemein über HTTPS bereitzustellen,
• bestimmte APIs ausschließlich für bekannte Gegenstellen freizugeben,
• technische Schnittstellen über IP-Freigaben einzuschränken oder
• administrative Zugriffe ausschließlich über VPN zuzulassen.

Welche Maßnahmen sinnvoll sind, hängt vom jeweiligen Anwendungsfall ab.

Benutzerkonten und Berechtigungen

Bei über das Internet erreichbaren Anwendungen kommt der Benutzer- und Berechtigungsverwaltung eine besondere Bedeutung zu.

Daher sollten:

• individuelle Benutzerkonten verwendet,
• nicht mehr benötigte Benutzer deaktiviert,
• sichere Kennwörter eingesetzt,
• technische Konten nur für ihren jeweiligen Zweck verwendet und
• Berechtigungen auf das erforderliche Minimum beschränkt

werden.

Besonders bei technischen Schnittstellen sollte geprüft werden, welche Berechtigungen der verwendete Benutzer tatsächlich benötigt.

Monitoring und Protokollierung

Ein über das Internet erreichbarer Visual-Planning-Server sollte überwacht werden.

Neben der reinen Verfügbarkeit ist insbesondere darauf zu achten, dass:

• Server und Dienste ordnungsgemäß laufen,
• Zertifikate gültig bleiben,
• ausreichend Speicherplatz vorhanden ist,
• Auffälligkeiten nachvollzogen werden können und
• Fehler- und Zugriffsprotokolle für eine Analyse verfügbar sind.

Monitoring ergänzt damit die regelmäßige technische Wartung und hilft, Probleme frühzeitig zu erkennen.

Eigenbetrieb beim Kunden oder betreutes Hosting

Neben der technischen Absicherung ist entscheidend, wer für den laufenden sicheren Betrieb der Visual-Planning-Umgebung verantwortlich ist.

Bei einer Installation im Kundennetzwerk liegt diese Verantwortung grundsätzlich beim Betreiber bzw. muss zwischen Kunde, IT-Dienstleister und Visual-Planning-Betreuer eindeutig geregelt werden.

Bei einem betreuten Hosting können diese Aufgaben Bestandteil des laufenden Serverbetriebs sein.

Wartungsaufwand bei klassischen Windows-Installationen

Bei einer klassischen Windows-Installation von Apache Tomcat wird Tomcat häufig als eigener Windows-Dienst betrieben.

Ein Tomcat-Update ist dabei nicht automatisch Bestandteil der normalen Windows-Updates.

Je nach Installation gehören zu einem Update beispielsweise:

• neue Tomcat-Version bereitstellen,
• vorhandene Konfiguration prüfen,
• kundenspezifische Einstellungen übernehmen bzw. vergleichen,
• Windows-Dienst berücksichtigen bzw. aktualisieren,
• Visual Planning wieder bereitstellen,
• Dienst neu starten und
• anschließend die verwendeten Visual-Planning-Funktionen prüfen.

Dabei sollte nicht ausschließlich VPgo getestet werden. Abhängig von der jeweiligen Installation können beispielsweise auch Rich Client, APIs und weitere Schnittstellen betroffen sein.

Zusätzlich muss die verwendete Java-Version überwacht und gegebenenfalls aktualisiert werden.

Für einen individuell betriebenen Windows-Server sollte deshalb für die regelmäßige Prüfung, Durchführung und Kontrolle von Tomcat- und Java-Updates ein laufender Administrationsaufwand eingeplant werden.

Nach unseren Erfahrungen kann hierfür bei einer üblichen Visual-Planning-Installation im Jahresmittel als Planungsgröße etwa 30 bis 60 Minuten administrativen Aufwand für Prüfung und Pflege der Visual-Planning-Serverplattform pro Monat und Server angesetzt werden.

Dieser Aufwand fällt nicht zwingend jeden Monat in gleicher Höhe an. In einem Monat kann lediglich die Prüfung des Versions- und Sicherheitsstands erforderlich sein, während ein relevantes Update inklusive Installation und Funktionstest entsprechend mehr Zeit benötigt.

Größere Versionswechsel, Störungen oder notwendige Anpassungen sind in dieser Größenordnung nicht enthalten.

Paketbasierte Aktualisierung unter Linux

Bei einem entsprechend aufgebauten Linux-Hosting können viele Serverkomponenten über die Paketverwaltung der verwendeten Distribution gepflegt werden.

Das betrifft beispielsweise:

• Betriebssystembibliotheken,
• Java,
• Apache Tomcat und
• weitere Serverkomponenten.

Sicherheitskorrekturen können dadurch über den normalen Paketmechanismus der Distribution installiert werden.

Die Wartung einer einheitlich aufgebauten Linux-Plattform lässt sich damit wesentlich stärker standardisieren und automatisieren.

Das bedeutet ausdrücklich nicht, dass Linux-Systeme keine Wartung benötigen oder grundsätzlich sicherer als Windows-Systeme sind.

Der wesentliche Vorteil liegt in einer einheitlichen, paketbasierten und zentral administrierbaren Serverplattform.

Warum dieser Unterschied bei mehreren Servern relevant wird

Bei einem einzelnen Server erscheint ein monatlicher Aufwand von beispielsweise 30 Minuten zunächst gering.

Bei mehreren individuell betriebenen Kundenservern summiert sich dieser Aufwand jedoch. Zusätzlich können sich die Installationen hinsichtlich Windows-Version, Java-Version, Tomcat-Version, Visual-Planning-Version und kundenspezifischer Konfiguration unterscheiden.

Eine zentral administrierte Linux-Hostingplattform ermöglicht dagegen, viele dieser Aufgaben nach einem einheitlichen Verfahren durchzuführen:

Sicherheitsmeldung → Prüfung → Paketupdate → Neustart → Funktionskontrolle / Monitoring

Dadurch lässt sich insbesondere bei einer größeren Anzahl von Installationen der manuelle Aufwand pro Server reduzieren.

Verantwortlichkeiten eindeutig festlegen

Dieser Punkt sollte insbesondere bei kundenseitig betriebenen Visual-Planning-Systemen eindeutig geregelt werden.

Wird ein Visual-Planning-Server für den Zugriff aus dem Internet freigegeben, bedeutet die ursprüngliche Installation nicht automatisch, dass Visual Planning, Tomcat, Java, Betriebssystem oder die Internetfreigabe anschließend dauerhaft durch den ursprünglichen Installationspartner betreut werden.

Es sollte daher festgelegt werden, wer für den sicheren Betrieb und die regelmäßige Prüfung verantwortlich ist.

Zu klären sind insbesondere:

• Wer überwacht Sicherheitsmeldungen für Tomcat und Java?
• Wer prüft den Versionsstand?
• Wer führt notwendige Updates durch?
• Wer prüft anschließend die verwendeten Visual-Planning-Funktionen?
• Wer aktualisiert Betriebssystem und weitere Serverkomponenten?
• Wer überwacht Zertifikate und deren Laufzeit?
• Wer kontrolliert die aus dem Internet erreichbaren Visual-Planning-Endpunkte?
• Wer reagiert auf eine relevante Sicherheitsmeldung?

Fazit

Der externe Zugriff auf VPgo ist häufig der Anlass, einen Visual-Planning-Server über das Internet erreichbar zu machen. Die technische Auswirkung kann jedoch über VPgo hinausgehen.

Abhängig von der Konfiguration können auch Rich Client, APIs, URL-basierte Exporte und weitere Visual-Planning-Endpunkte erreichbar sein.

Deshalb sollte bei einer Internetfreigabe nicht nur die Frage gestellt werden:

„Wie machen wir VPgo erreichbar?“

Sondern:

„Welche Teile unseres Visual-Planning-Servers sollen aus dem Internet erreichbar sein – und wie stellen wir genau diese sicher bereit?“

Mit einer geeigneten Architektur, HTTPS, Reverse Proxy, gezielten Netzwerkfreigaben sowie der kontinuierlichen Pflege von Visual Planning, Apache Tomcat, Java und Betriebssystem lässt sich Visual Planning kontrolliert für den externen Zugriff bereitstellen.

Bei kundeneigenen Installationen sollte eindeutig geregelt werden, wer diese Aufgaben dauerhaft übernimmt. Bei einem betreuten Hosting können Absicherung, Updates und Monitoring auf einer einheitlichen Plattform zentral organisiert werden.

Die Internetfreigabe eines Visual-Planning-Servers ist damit keine einmalige Konfigurationsaufgabe, sondern Bestandteil des dauerhaften technischen Betriebs.

Siehe auch: VPGo Voraussetzungen,Einfügen eines SSL Zertifikats,Visual Planning Installieren mit Tomcat, Apache Webserver und PostgreSQL