Eine Produktionsumgebung ohne IT ist schon seit einiger Zeit weder denkbar noch durch die notwendige Digitalisierung realistisch umsetzbar. Dies bedeutet aber gleichzeitig, dass eine komplette Abschottung der Produktion zum Internet immer schwieriger wird und zum Beispiel moderner Cyber Security Software und den sehr wichtigen und notwendigen Updates, die regelmäßig durchgeführt werden müssen, gar nicht möglich ist. Daher stellt sich die Frage, wie man einen entsprechend abgesicherten Zugriff auf das Internet für den sensiblen Bereich der Produktion realisiert, darüber die Kontrolle behält, alle Zugriffe protokolliert und diese gleichzeitig überwacht.
Auf den ersten Blick scheint das Thema recht simple zu sein, was es aber auf den zweiten Blick nicht ist. In Zeiten, in denen immer mehr Dienste aus der Cloud kommen und teilweise auch On Premises bereitgestellte Dienste für ihren Betrieb Teildienste aus der Cloud benötigen, wird es immer schwieriger grundsätzlich keinen Zugriff auf das Internet zuzulassen. Diese Problematik tritt nicht nur bei der Nutzung von CDN’s auf, weiter ist auch eine Differenzierung bei den Clouddiensten innerhalb eines Anbieters nötig. Der Ansatz des Whitelisting macht die Aufgabe nicht leichter und ein Verzicht auf diesen Ansatz erhöht das Risiko deutlich oder ist bei den Vorgaben für bestimmte Umgebungen gar nicht möglich. Hierunter fallen nicht nur KRITIS Umgebungen, sondern auch alle anderen die in der jeweiligen Risikobetrachtung die entsprechende Sensibilität haben. Grundsätzlich muss man sich aber auch unabhängig der jeweiligen Umgebung darüber im Klaren, dass man eine Verbindung zum Internet öffnet. Da die IT nicht nur aus der eigentlichen Technik besteht, sondern auch organisatorische Anforderungen umzusetzen sind, muss die Implementierung einer solchen Lösung allen Anforderungen gerecht werden, dies es umzusetzen gillt. Um aber diesen Beitrag nicht völlig ausufern zu lassen, orientiert sich die vorgestellte Lösungsvariante am BSI Grundschutz und dort an den Anforderungen für Systeme mit erhöhten Schutzbedarf (H), welche natürlich die Basis- (B) und Standard-Anforderung (S) miteinschließt. Weiter setzt dieser Lösung voraus, dass sich alle Anfragen über einen klassischen WebProxy abwickeln lassen. So zu sagen führt der Blick nach vorne in Richtung moderner Anforderungen auch gleichzeitig zurück in die Vergangenheit der Internetzugriffe und zu einer Renaissance des klassischen WebProxy Server für den Internetzugriff.
Die Wahl des Klassikers, der OpenSource WebProxy Squid, kommt nicht von ungefähr und basiert u.a. auf den folgenden Überlegungen: Ein dedizierter WebProxy lässt sich leicht mit der P-A-P Anforderung des BSI Grundschutz in Einklang bringen. Bei verteilten Standorten kann eine entsprechende Verkettung und somit Hierarchie aufgebaut werden. Das Protokoll wird von (so gut wie) allen unterstützt. Die Umsetzung einer Multi Vendor Strategie ist gegeben, da sich der klassische Squid auf einem eigenständigen System immer von der Implementierung eines WebProxy des Firewall- oder Security Gateway-Herstellers unterscheidet. Durch die Linux Basis und des konsequenten Einsatzes von lizenzkostenfreier OpenSource Software werden zwei weitere Anforderungen umgesetzt. Es werden die digitale Souveränität gestärkt und die Kosten reduziert, was im Falle eines Einsatzes im öffentlichen Bereich auch eine Anforderung des Bundesrechnungshofes ist. Alle anderen können sich mindestens darüber freuen, dass keine Lizenzkosten entstehen. Ein Squid WebProxy bietet zudem die Möglichkeit ein umfangreiches Regelwerk zu erstellen, was sich sehr individuell für ein solches Szenario anpassen lässt und er bietet zudem eine sehr gute Protokollierung aller Zugriffe. Das erzeugte Protokoll kann von sehr vielen Sicherheitssystemen, wie SIEM oder diverser SOC Implementierung, verarbeitet und analysiert werden, was einen weiteren wichtigen Punkt der Anforderungen erfüllt. Denn es ist essentiell die Kontrolle zu behalten und dies auch überprüfbar umzusetzen. Zu den weiteren Vorteil der eigenständigen Linux/Squid Lösung gehört das Potential mit einer großen Anzahl an Option viele Dinge zu automatisieren. Das ist auch ein wenig den Diensten in der Cloud geschuldet, da hier sehr dynamisch IP-Bereich oder FQDNs angepasst werden müssen und alles was man aktualisieren kann, hilft im täglichen Betrieb. Das hat auch Vorteile für die Sicherheit selbst, da IP-Bereiche oder FQDNs, die der Anbieter für bestimmte Dienste nicht mehr nutzt, werden automatisch entfernt. Sehr vorbildlich verhält sich hier zum Beispiel Amazon, über ein json File kann man mit entsprechenden Queries sich selbst die passenden Listen für die verschiedenen AWS Dienste erzeugen.
Der WebProxy selbst und dessen Zugriff auf das Internet muss natürlich entsprechend abgesichert erfolgen, um damit u.a. mehrere Ebenen zum Schutz Produktionsumgebungen zu implementiere. Das System an sich gehört grundsätzlich in eine DMZ und sollte entsprechend den Vorgaben des BSI gehärtet werden, wie es die Maßnahmen für Linux Systeme und den Dienst vorsehen. Durch entsprechende Firewallrichtlinien wird zusätzlich zu den ACL’s im Squid selbst festgelegt, welche Systeme oder Netze auf den Dienst zugreifen dürfen. Der Zugriff auf das Internet selbst wird durch weitere Maßnehmen geschützt. Dabei bedient sich diese Lösung den auf einer Fortigate zur Verfügung stehen Optionen, wie IPS, URL-, Botnet- DNS-Filter und der Internet Service Database. Diese werden entsprechend verwendet, um den Zugriff des WebProxy selbst auf das Internet mit einer zusätzlichen Instanz und unabhängig weiterer ACL’s im Squid zu regeln. Einen weiteren Punkt sollte man auch nicht vernachlässigen, denn sowohl der WebProxy als auch Firewalls bieten die Option von zeitgesteuerten Zugriffen bzw. Regelwerken.
All diejenigen, die jetzt denken, dass dies Mehraufwand bedeutet, haben recht, nur gibt es (IT-)Sicherheit aber nicht zum Nulltarif und hier geht es ja nicht um den Standardwebzugriff irgendwelcher Office Clients, sondern um die Absicherung der Produktion, damit diese definiert und abgesichert auf die notwendigen Dienste im Internet zugreifen darf. Ein WebProxy ist für diesen Anwendungsfall auch nicht in die Jahre oder aus der Mode gekommen, im aktuellen Artikel von Microsoft für die notwendigen Zugriffe für verschiedene Dienste von Office/Microsoft 365 oder Azure werden nach wie vor FQDN’s angeben mit dem Hinweis diese im Proxy entsprechend freizugeben.
Die hier beschrieben Lösung ist nur ein und nicht „der“ Weg um Produktionsumgebungen Zugriff auf das Internet zu gewähren. Die passende Lösung richtet sich natürlich nach den jeweiligen Rahmenbedingungen und den zur Verfügung stehenden Optionen. Die hier vorgestellte Lösung soll aber mindestens den Blick für die Sensibilität und den notwendigen Schutzbedarf von Produktionsumgebungen schärfen und dazu beitragen Lösungen zu findet einen sicheren Zugriff auf externe Ressourcen auch für diese sensiblen Bereiche zu gewähren.