Open Source 2.0 stellt hohe Anforderungen an Sicherheit

Der rasante Siegeszug von sozialen Gemeinschaften und Web 2.0-Technologien zeigt sich am Wandel der Bedeutung des klassischen Intranets. Neue Portale machen fast täglich die Runde, in denen statt den Chefs die Nutzer selbst die Regie führen, die die großen von oben verordneten Markenbotschaften gelegentlich in Frage stellen. Die Marktmacht der Anwender und Konsumenten wächst und führt allmählich zur Aufhebung der bislang sorgsam gehüteten Grenzziehung zwischen Intranet und Extranet.

Sprich: Je offener und persönlicher ein Unternehmen mit den neuen Möglichkeiten im Mitmachweb umgeht, desto attraktiver erscheint es auch nach außen. Andererseits gilt gerade im Intranet - anders als im Extranet - ein erhöhtes Schutzbedürfnis, denn sensible Daten und Prozesse dürfen nicht ungefiltert nach draußen gelangen. Deshalb gilt es die Stellschrauben nicht nur beim externen Marketing anzusetzen, und das Intranet quasi dieser Außensteuerung nur anzugleichen, sondern auch die internen Prozesse einer permanenten Revision zu unterziehen.

Auf der anderen Seite punkten offene Lösungen der Marke Open Source neben mehr Transparenz und Offenheit auch mit technischen Vorteilen. So lassen sich etwa im Intranet durch in personalisierte Web-Desktops eingebettete Mashups weitere Anwendungen flexibel über eine globale Navigation integrieren und ansteuern. Darüber hinaus stehen neue Inhalte und Funktionen bereit, etwa durch Ausnutzung offener Schnittstellen in Form von Widgets auf dem Desktop.

Unter Widgets sind kleine Programmfenster zu verstehen, die der einzelne Mitarbeiter jederzeit seinem Desktop hinzufügen kann und die sich individuell konfigurieren und anordnen lassen. Dabei gilt es jedoch zu beachten, dass die Anmeldung über ein sicheres Single Sign-On Verfahren erfolgt, mit dem sich die Mitarbeiter am Web-Desktop und den anderen Anwendungen im Intranet einloggen, um ihre persönlichen Widgets zu laden.

Die unterschiedlichen Typen sollten auf die passenden Arbeitsprozesse im Unternehmen maßgeschneidert sein, bis hin zu aktiven RSS-Widgets. Generell gilt es ohnehin, den Mix aus offenen und proprietären Systemen und Werkzeugen beherrschbar zu machen, bis hin zum Content Management (CMS). Diese Philosophie sollten die Spezialisten bereits beim Redesign des Intranets beherzigen, sprich schon vor der Auswahl der technischen Werkzeuge, die mittlerweile auf mehrere Hundert angewachsen sind.

Neben dem Enterprise Open Source Directory gehören Alfresco, eZpublish, Bricolage, TYPO3, Joomla, Drupal, Wordpress, Media-Wiki, Plone und OpenCMS zum erweiterten Spektrum. Neben spezifischen Anforderungen an die jeweilige Lösung gilt es, das Systemumfeld sowie spezifische Anforderungen aus dem Support zu berücksichtigen.

Ebenso unverzichtbar sind neben einem solide aufgesetzten Prozessmanagement auch die Bedürfnisse der Nutzer an die Administrierbarkeit der neuen Umgebung. Außerdem eingehend zu berücksichtigen sind die Fremddatenintegration und die Anbindung externer Partner, die nicht nur das Extranet beeinflussen. Denn in Zukunft weichen die klassischen Grenzziehungen an der Netzwerkkante.

Projekte an den Schnittstellen exakt definieren

Welche Empfehlungen geben also Spezialisten, um Open Source basierte CMS-Lösungen möglichst optimal abzusichern und dem zunehmenden Wildwuchs zu entfliehen, sprich dem latenten Managementchaos vorzubeugen? Kritische Schwachpunkte sind etwa die dominante Skriptsprache PHP, aber auch Java. Wie lassen sich Schwachstellen bereits im Vorfeld beim Konzept und Programmierung unterbinden, etwa durch vorbeugende Awareness für Entwicklercommunities oder die Web-Administratoren?

"Die verwendete Sprache kann nicht direkt als Schwachpunkt angesehen werden", erläutert Mag. Roman Weinberger, Geschäftsführer beim IT-Spezialisten Studio78.at (www.studio78.at) in Wien. Der Experte rät den IT-Professionals vielmehr, die Sprachen hinsichtlich der Förderung von sicheren (Java) oder unsicheren Programmierstilen (PHP) zu unterscheiden.

Auf der Seite der Entwickler habe sich in letzter Zeit der Stellenwert von sicheren Entwicklungsmethoden, bedingt durch die teils massiven Sicherheitsprobleme bestehender Anwendungen, deutlich erhöht, so Weinberger weiter. Für neue Projekte stelle deshalb die Sicherheit eines der Hauptziele der Entwicklung dar, "und es wird vermehrt bei PHP auf OOP und diverse Frameworks zurückgegriffen."

Das Hauptproblem sieht der Experte aber vor allem bei der Integration in bestehende Anwendungen, was gerade mit Blick auf Sicherheitsaspekte noch wenig bedacht worden sei. "Hier haben auch Administratoren eine Möglichkeit, sanften Druck auf die Entwickler auszuüben indem sie unsichere beziehungsweise veraltete Umgebungsfeatures wie register_globals bei PHP nicht weiter unterstützen", regt Roman Weinberger an.

Zudem sind weitere technische kritische Punkte zu bedenken wie unzureichend gesicherte SQL-Abfragen, die Attacken wie eine SQL-Injection, LDAP-Injection, XSS oder CSRF nach sich ziehen können. "Auf Seite der Anwendungen sollte solchen Problemen mit durchgehender Input-Validierung, Escaping und gegebenenfalls der Verwendung von datenbankspezifischen Features wie z.B. Prepared Statements bei SQL entgegnet werden", ergänzt Geschäftsführer Günther Lackner von Studio78.

Zur Verhinderung von XSS sei das Escaping und/oder White-Listing aller auszugebenden Inhalte nötig. "Wenn eine Anwendung gegen XSS geschützt ist, lassen sich CSRFs vergleichsweise einfach mit in Formularen eingebetteten Shared-Secrets vermeiden", so der Experte weiter. Aktuelle Frameworks wie Ruby on Rails bieten dies bereits in transparenter Form an. Auch die Verwendung von nicht-transparenten Session-IDs stelle einen gewissen Schutz vor CSRFs (Cross Site Request Forgery Defense) dar.

Zusätzliche Schutzmaßnahmen wären außerdem vorgeschaltete Web-Applications-Firewalls - von kostengünstigen Lösungen wie dem mod_security für Apache bis hin zu dedizierter IPS-Hardware. Wie aber lassen sich großflächig angelegte Denial of Service Attacken (DDOS) vermeiden? "DDOS lassen sich nur sehr schwer vollständig vermeiden", räumt Weinberger ein. Die Wahl einer probaten Gegenstrategie beginne auf Seite der Web-Anwendung mit durchgängigem Caching und der Limitierung von "teuren" Aufrufen.