Offen aber nicht schutzlos So funktioniert Open-Source-Sicherheit

Open-Source Software, kurz OSS, hat in den letzten Jahren einen beeindruckenden Reifegrad erreicht. Wie sicher kann quelloffene Software aber wirklich sein, insbesondere wenn es um den Einsatz im Unternehmen geht? Dieser Artikel soll Licht ins Dunkel bringen.

Anbieter zum Thema

Vogel IT-Medien GmbH

Fujitsu Technology Solutions GmbH

TXOne Networks

Marktforscher haben die Qualität quelloffener Lösungen längst erkannt. Gartner beispielsweise empfiehlt Unternehmen, Open-Source-Datenbanken als erste Wahl für geschäftskritische Anwendungen in Betracht zu ziehen.

Laut des Gartner-Reports „The State of Open-Source RDBMSs, 2015“*, der im April 2015 veröffentlicht wurde, werden „bis 2018 über 70 Prozent neuer In-House-Anwendungen auf einem OSDBMS [Open-Source-Datenbankmanagementsystem] entwickelt werden. Außerdem werden mehr als 50 Prozent bestehender kommerzieller RDBMS [relationaler DBMS]-Instanzen entweder bereits [auf Open Source] umgerüstet sein oder sich im Prozess [der Konvertierung] befinden.“

Quelloffene Lösungen bieten Kunden die Möglichkeit, Kosten einzusparen und somit vermehrt in Innovation zu investieren, während Performance und Effizienz aufrechterhalten werden. Trotzdem werden diese Vorteile immer noch von Bedenken bezüglich der Sicherheit von OSS-Lösungen überschattet.

Der Unterschied

Um OSS-Sicherheit zu verstehen, müssen Open-Source-Lösungen zunächst von sogenannten Closed-Source-Lösungen, deren Quellcode nicht öffentlich verfügbar ist, abgegrenzt werden. Im Grundsatz ähneln sich die Sicherheitstechniken und -technologien von Open- und Closed-Source-Software. Den großen Unterschied macht aber die Transparenz aus.

Bei OSS ist alles für alle sichtbar und jedermann kann den Code überprüfen. Dadurch unterliegt OSS der ständigen Kontrolle durch die wachsamen Augen einer wachsenden Gruppe (Community) sowohl professioneller als auch unabhängiger Beobachter, die nach Fehlern und Hintertüren suchen. Jeder kann jederzeit den Code einsehen und die Hand heben, um auf ein Problem aufmerksam zu machen. Postgres und viele andere Open-Source-Projekte verbessern sich aufgrund dieser Transparenz ständig.

Anstatt geistiges Eigentum zu schützen, den Markt zu beeinflussen oder einen potenziellen Reputationsschaden zu kontrollieren, konzentrieren sich Mitwirkende an Open-Source-Projekten (sogenannte Contributors) darauf, die Software besser zu machen. Ihre Interessen decken sich mit denen der Anwender, da viele derjenigen, die den Code überprüfen, selbst Anwender sind.

Diese Pluralität und Vielfalt unter den Kontributoren kann zu einem Mangel an Vorhersehbarkeit führen, wenn es um die Entwicklung einer stringenten Produkt-Roadmap geht. Im Gegenzug gewährt der Ansatz jedoch ein großes Plus in Sachen Flexibilität, Sicherheit und Innovation.

Die Community besteht aber nicht ausschließlich aus Endanwendern. Auch viele Unternehmen arbeiten in der Community zusammen und investieren personelle, technische sowie zeitliche Ressourcen in die Entwicklung der Software. Indem sie gemeinsam an einem Strang ziehen, ergibt sich eine strategische Richtung, die an den Anforderungen der Endanwender ausgerichtet ist und nicht etwa an den kommerziellen Interessen eines einzelnen Anbieters.

Im Gegensatz dazu werden Closed-Source-Lösungen nur von einem einzelnen Contributor entwickelt – nämlich einem Unternehmen oder Einzelentwickler – und haben daher klare Roadmaps, die es exakt umzusetzen gilt. Das gewährt einen gewissen Grad an Verlässlichkeit und Vorhersagbarkeit, in welche Richtung sich die Software entwickelt.

Solche Projekte sind aber nach wie vor Blackboxes. Kunden können den Code nicht überprüfen und müssen sich auf die Maßnahmen verlassen, die der Anbieter in Sachen Datensicherheit trifft. Einige etablierte Markführer drohen ihren Kunden sogar mit rechtlichen Konsequenzen, sollten diese versuchen, die Sicherheit ihrer Software auf die Probe zu stellen.

Das sind natürlich extreme Beispiele und dieser Artikel ist nicht als Polemik gegen Closed-Source im Allgemeinen gedacht – viele Unternehmen haben fähige Teams, die sich mit der Sicherheit ihrer Software befassen und können gute Ergebnisse vorweisen. Doch der Mangel an Transparenz bleibt und zwingt ihre Kunden dazu, ihnen blind zu vertrauen, wenn es um ihre sensiblen und geschäftskritischen Unternehmensdaten geht.

Wie es funktioniert

Viele OSS-Lösungen haben Contributors, die einen Großteil ihrer Zeit darauf verwenden, sie instand zu halten und zu verbessern – besonders, wenn die Lösungen schon einige Zeit auf dem Markt sind. Die verlässlichsten und erfahrensten Kontributoren werden oft zu sogenannten „Committers“ –verantwortlich dafür, Änderungen am Quellcode für offizielle Releases vorzunehmen. Neben diesen gibt es eine große Zahl von Hobbyisten, Freiwilligen und Enthusiasten, die zur andauernden Diskussion um die Evolution des OSS-Projekts ihrer Wahl beitragen. Alle Beteiligten überprüfen ständig den Code.

Während jeder den Code testen kann, handhabt die Postgres Community beispielsweise Sicherheitszwischenfälle in einer disziplinierten Weise, falls sie dennoch auftreten sollten. Die Community meldet und behebt Probleme hauptsächlich durch die Organisation „Common Vulnerabilities and Exposures“ (CVE), die ein Verzeichnis von allgemein bekannten Sicherheitslücken in Computersystemen unterhält.

Jeder kann den „Security“-Link auf der PostgreSQL.org-Homepage nutzen, um Sicherheitsprobleme zu melden oder sie einzusehen. Bei Interesse suchen sie auf Mitre.org nach „PostgreSQL“. Zudem kooperiert die Community mit „Packagers“ und SaaS-Anbietern für PostgreSQL, also Unternehmen mit einem Bezug zu Postgres, um Patches für Anwender zu beschleunigen.

In der Praxis

Sehen wir uns den tatsächlichen Ablauf am Beispiel der Postgres Community an:

• 1. Wird ein Problem entdeckt, meldet es der Finder per E-Mail bei dem Kernteam aus Postgres-Committers, eine Gruppe von erfahrenen Postgres-Contributors. Sie untersuchen das Problem, den Schweregrad, die Auswirkungen auf das bestehende System und eine mögliche Lösung (Fix). Ist der Bug schwerwiegend, wird der Fix priorisiert und kann innerhalb von Tagen für Unternehmen, die Postgres nutzen, bereitgestellt werden.

• 2. Nachdem das Vorgehen und der Zeitrahmen gesetzt sind, wird das Fix-Update von einem erfahrenen Team aus Contributers und Committers entwickelt und die Veröffentlichung geplant.

• 3. Der Patch wird getestet, anschließend in der Regel in den Source-Tree integriert und erneut getestet.. In seltenen Fällen – nämlich dann, wenn ein besonders schweres Problem auftritt – wird die Integration in den Source-Tree erst im letztmöglichen Moment durchgeführt.

• 4. Der Patch wird veröffentlicht und alles geht wieder seinen gewohnten Gang der kontinuierlichen Überprüfung und Verbesserung.

Unterm Strich zeichnen sich Open-Source-Projekte mit sehr großen Communities wie Postgres dadurch aus, potenzielle Sicherheitsprobleme schnell identifizieren und beheben zu können. Sie sind völlig unbelastet von Firmenagenden und Bürokratie, profitieren von der Größe ihrer Community und florieren ihrer Natur gemäß durch Transparenz.

* Über den Autor

Dave Page gilt als Community-PostgreSQL-Veteran und ist Vice President and Chief Architect, Tools and Installers, bei EnterpriseDB. Der Anbieter einer Open-Source-basierten, relationalen Datenbanklösung wurde im Herbst 2015 zum zweiten Mal in Folge im Leader-Quadranten des „Magic Quadrant for Operational Database Management Systems“ platziert.

(ID:44256779)