FORMFAKTEN Artikel über unseren Standpunkt zu Open Source
Mittwoch, 02.05.2018
Mit Umbraco verwenden wir ein OpenSource-System als Basis, auf der wir die Websites unserer Kunden aufbauen. Dies hat sehr viele Vorteile. Aber ist OpenSource die Lösung für alle Projekte?
Ohne Frage: Mit Umbraco schöpfen wir die Vorteile eines OpenSource-Projekts voll aus. Es gibt eine lebhafte Community, die Erweiterungen, Bugfixes und gute Laune in der Zusammenarbeit einbringt. Das Umbraco Headquarter in Dänemark hat seine Geschäftsmodelle, die seit einigen Jahren für stetes Wachstum sorgen, während die Community weiterhin ihre Lösungen auf der kostenlosen Plattform aufbauen kann. Das sieht nach einer typischen Win-Win-Situation aus.
Was wir besonders schätzen, ist die Tatsache, dass es schon einige Security Audits für Umbraco-basierte Systeme gegeben hat, deren Ergebnisse direkt an Umbraco zurückgespielt wurden. Hier trifft also die Aussage zu, dass OpenSource für mehr Sicherheit sorgt, weil die Community gegebenenfalls mit einem tieferen Blick auf das System und gegebenenfalls auf die Source Codes die Sicherheitsvorkehrungen überprüfen kann.
Es ist ein Geben und Nehmen und nicht ein Modell von unbegrenztem Freibier – eine Aussage, die nicht für jedes OpenSource-Projekte zutrifft.
OpenSource und Sicherheit
Ein Teil der Sicherheit kommt jedoch gar nicht von Umbraco, sondern von dem darunterliegenden ASP.NET-System. Das .NET-Framework und ASP.NET waren die längste Zeit nicht quelloffen, sind es aber seit etwa 3 Jahren.
Davor war der Quellcode nicht offen. Es konnte also niemand in der Community überprüfen, ob der Code nicht irgendwelche Lücken aufweist. Ich stelle fest, dass bei vielen Leuten, gerade in der Presse, sich so ein Reflex festgesetzt hat, dass ClosedSource automatisch zu schlechterer Sicherheit führt, weil der Code nicht überprüfbar ist. Dabei ist die Frage ja eigentlich nur, ob die üblichen Angriffe (Buffer Overflow, Code Injection, Cross Site Scripting und wie sie immer heißen mögen) zur Angreifbarkeit des Systems führen. Dazu braucht es nicht unbedingt den Source Code. Der Source Code kann allenfalls zusätzliche Hinweise auf die Angreifbarkeit geben.
Im Fall von .NET und Windows ist es so, dass Microsoft eine unglaubliche Menge an Ressourcen in die Überprüfung seiner Plattformen stecken konnte (und immer noch kann). Es ist nicht anzunehmen, dass die Community, die .NET nutzt, die Abermillionen an Codezeilen in der angemessenen Tiefe überprüfen kann. Andererseits gibt es Leute, die automatisierte Tests fahren, und dabei immer mal wieder größere Sicherheitslücken in OpenSource-Projekten finden, die bislang unentdeckt blieben – trotz offener Source Codes.
Es kann theoretisch jederzeit passieren, dass Angriffstests eine Angreifbarkeit des .NET Frameworks ergeben. Es ist aber meines Wissens noch nie passiert, dass jemand eine Lücke gefunden hätte, mit der auf einmal alle auf ASP.NET basierenden Websites gefährdet gewesen wären.
Vor ein paar Jahren gab es mal ein Problem mit dem (schon immer quelloffenen) ASP.NET MVC-Framework. Hier musste tatsächlich einmal eine DLL auf allen laufenden Systemen ausgewechselt werden. Seit Beginn unserer Arbeit mit Umbraco im Jahr 2011 war das das einzige zwingende System-Update. Das ist eine Bilanz, bei der ASP.NET-basierte Systeme schon wesentlich besser dastehen, als zum Beispiel PHP-basierte Systeme wie typo3, Drupal oder das allgegenwärtige WordPress.
Security by Hiding??
Der Vollständigkeit halber sollte gesagt werden, das die Kryptografie-Funktionen, die der IIS benutzt, auf der Kryptografie von Windows basieren. Der Windows-Code ist nicht quelloffen, die Funktionen werden daher nur von Microsoft überprüft. Es gibt Anzeichen, dass sich das in den nächsten 2-3 Jahren ändern könnte. Aber bis dahin gilt: Wir müssen Microsoft vertrauen, was die Implementierung ihrer Kryptografie anbetrifft. Was das .NET-Framework anbetrifft, liegen die essentiellen Kryptografie-Algorithmen als Managed Code vor und mittlerweile kann man auch den Sourcecode des .NET Frameworks auf Github einsehen. Update: Mittlerweile sind die Kryptografie-Funktionen von Windows auf Github einzusehen.
Das Pendant zur Windows-Kryptografie in der OpenSource-Welt ist OpenSSL. Sieht man sich die Schwierigkeiten von OpenSSL in den letzten paar Jahren an, dann drängt sich nicht gerade der Eindruck auf, dass diese quelloffene Implementierung irgendeinen Vorteil gegenüber den Implementierungen von Microsoft hätte.
Allerdings sollte man von dem Argument Abstand nehmen, dass ClosedSource-Implementierungen sicherer seien, weil die Angreifer den Source Code nicht auf Schwächen untersuchen können. Diese sogenannte Security by Hiding ist sehr trügerisch und könnte zu einem bösen Erwachen führen.
Für Schwachstellen in ClosedSource-Systemen wird in Geheimdienstkreisen und Kreisen der organisierten Kriminalität viel Geld gezahlt. Es gibt Experten, die dafür bezahlt werden, durch Re-Engineering analysierbaren Code zu erhalten, der dann auf Schwächen untersucht werden kann. Die Community hat meist die Mittel zu solch einem aufwändigen Re-Engineering nicht und kann daher nicht rechtzeitig gegensteuern.
Unterm Strich kann man sagen: Die Verschlüsselungsverfahren, die für SSL und andere Sicherheitsprotokolle entwickelt wurden, verlieren nichts von ihrer Sicherheit dadurch, dass ihr Source Code öffentlich ist. Es gibt also keinen vernünftigen Grund, den Source Code unter Verschluss zu halten. Ebenso gilt aber: Es gibt nur sehr wenig Leute da draußen, die in der Lage sind, diesen Source Code tatsächlich auf Schwachstellen untersuchen zu können.
Total Cost of Ownership
Ein weiterer Punkt bei der Entscheidungsfindung, welches System das bessere für eine bestimmte Anwendung ist, sind die Kosten, die im Betrieb eines Systems entstehen.
In der Vergangenheit hat sich gerade in Deutschland die hartnäckige Einstellung verbreitet, dass in der Server-Landschaft nur Linux sinnvoll ist. Ebenso hartnäckig ist die Fraktion, die sagt, dass auf dem Desktop Windows besser geeignet sei, als Linux – einfach wegen der Standard-Software, die es für den Desktop zu kaufen gibt.
Beide Seiten haben gleichermaßen unrecht. Wir verwenden seit Jahren Windows als Server-Betriebssystem, da Umbraco nur darauf läuft. Der Punkt ist, dass wir im Betrieb der Systeme eine Effektivität entwickeln, die sich für unsere Kunden in barer Münze auszahlt. Rechnet man hier die Miete für das Betriebssystem von ca. 25 € im Monat dagegen, zeigt sich, dass wir mit der höheren Effektivität für den Kunden letztlich mehr Kosten sparen, als der Kunde Miete zahlt. Noch besser sieht die Bilanz aus, wenn das Kundensystem auf einem Shared Hosting Server läuft.
Aber nicht nur die Kosten für das Betriebssystem müssen aufgebracht werden. Die Hauptkosten entstehen für die Administration und Wartung. Man muss zusehen, dass die Systeme mit Redundanz und eventuell mit Lastausgleich ausgestattet sind. Administratoren müssen in Bereitschaft stehen, damit im Fall des Falles reagiert werden kann. Solche Tätigkeiten erbringen wir idealerweise nicht selbst, sondern lassen sie von Dienstleistern erbringen.
Für Umbraco kommt zum Beispiel die Azure Cloud in Frage. Hier sind Redundanz, Lastausgleich, Austausch ausgefallener Komponenten etc. pp. im Preis inbegriffen. Und da zeigt sich: Das kostet für Linux genauso viel wie für Windows. Keines der Systeme kann hier wirklich Kostenvorteile für sich verbuchen.
Das Limux-Projekt
Die Stadt München hat Anfang der 2000er Jahre eine folgenschwere Entscheidung getroffen: Statt ihre Arbeitsplätze wie bisher mit Windows-Rechnern auszustatten, wurden 14.000 Arbeitsplätze auf Linux umgestellt.
Wer jetzt glaubt, die Stadt hätte damit irgendwelche Kosten gespart, weil man pro Arbeitsplatz gewisse Lizenzkosten für Windows erbringen muss, während Linux kostenlos ist, der befindet sich auf einem gedanklichen Holzweg.
Wir hörten so manche Geschichte darüber, wie es bei der Umstellung geknirscht hat. Bestimmte Programme waren nicht ersetzbar. Diese liefen dann auf vereinzelten Windows-Maschinen, die sich die Mitarbeiter dann teilen mussten. Neue Mitarbeiter, die Windows und die Microsoft-Programme wie Excel und Word gewohnt waren, mussten umgeschult werden. Die Reibungsverluste waren durchaus nennenswert.
Dennoch war das Projekt kein Misserfolg. Letztlich hat es gezeigt, dass das Durchbrechen der Reflexe in der IT möglich ist, wenn es denn politisch gewollt ist. Es war vielleicht nicht preisgünstiger, aber es haben andere Leute daran verdient – vielleicht auch mehr Firmen, die in Deutschland ansässig sind, womit sich eine bessere Steuerbilanz ergibt.
Es lässt sich nicht so leicht sagen, ob die Umstellung auf Linux mehr Vor- oder Nachteile gebracht hat. Was sich aber sagen lässt, ist, dass sich der politische Wille nicht gehalten hat. Es wurde kürzlich entschieden, wieder zu Windows zurückzukehren.
Was ist nun besser?
Wir können am Ende nur eines festhalten: Ob nun ein Open- oder ClosedSource-System genutzt wird, hängt sehr stark vom Einsatzzweck und sonstigen Faktoren der IT-Umgebung ab.
Wir für unseren Teil setzen auf Umbraco, ASP.NET und Windows Server, weil wir damit effizient maßgeschneiderte Enterprise-Lösungen für unsere Kunden anbieten können.
Was Websites für kleinere Unternehmen oder Vereine anbetrifft, so mag ein Linux-Hosting-Space und eine Wordpress-Installation ein gangbarer Weg sein.
Da mit .NET Core und Umbraco 9 das Content-Management-System unserer Wahl auch auf Linux lauffähig sein soll, werden wir uns die Entscheidung über das Server-Betriebssystem noch einmal vorlegen, sobald die entsprechenden Releases vorliegen. Update 2022: Mittlerweile sind wir bei der Umbraco-Version 10 und wir betreiben Produktivsysteme auf Linux. Die freie Wahl zwischen Windows und Linux halten wir für einen sehr großen Vorteil.
Eine weitere Variante sind sogenannte Headless-Systeme. Der Kunde mietet eine simple Variante von Umbraco in der Cloud. Diese dient dazu, um Contents und Medien zu erfassen. Das System muss nicht sonderlich hoch skalieren, weil es nur für die Verwaltung eingesetzt wird. Die Verteilung der Contents erfolgt durch ein Headless-Client-System. Das wiederum kann auf Linux laufen und mit NodeJs, ASP.NET Core oder anderen Technologien betrieben werden, die einen hohen Durchsatz ermöglichen. Auch hier sind Cloud-Varianten und Serverfarmen denkbar.
Eine weitere Variante ist ein System, vor dem ein Cache installiert wird, wie ihn zum Beispiel Amazon mit CloudFront anbietet. Auch hier wird die Skalierung auf die Cache-Systeme verschoben und die Requests können schneller bedient werden, weil Amazon-Caches überall auf der Welt verfügbar sind.