Die vielen Sicherheitsdiskussionen rund um Facebook, Google Streetview, libri.de, SchülerVZ und andere soziale Netzwerke sowie eCommerce-Websites machen zwei Dinge deutlich: Datenschutz wird wieder ernst genommen – und Sicherheit wird in Software-Architekturen untergewichtet.
Dass Datenschutz wieder ins Blickfeld rückt, ist eine interessante Entwicklung der letzten zwei bis drei Jahre. Nach den intensiven Diskussionen der 70er und 80er Jahre war es lange ruhig um dieses Thema. Nun ist es nicht mehr nur für die „Geeks“ und Spezialisten interessant, sondern beschäftigt die breite Öffentlichkeit und die Politik wieder.
Das bedeutet auch, dass ein zu laxer Umgang mit diesem Thema ein Risiko für die Geschäftsmodelle von Unternehmen darstellt. Facebook bessert nur auf Druck der amerikanischen und europäischen Benutzer nach und auch andere Dienstanbieter reagieren auf die geänderte Erwartungshaltung – manche schneller, manche langsamer, abhängig vom Selbstverständnis und vom Geschäftsmodell.
Wenn man sich viele der Schwachstellen in Bezug auf Sicherheit und Datenschutz anschaut wird aber auch deutlich, dass diese in Mängeln der Software-Architektur begründet liegen. Unzureichende Konzepte für die Authentifizierung und Autorisierung von Zugriffen sind nicht die Ausnahme, sondern die Regel.
Dabei wird gerne damit argumentiert, dass es bei der Realisierung solcher Dienste nicht um Sicherheit ginge, sondern darum, schnell eine bestimmte Funktionalität auf den Markt zu bringen. Mit anderen Worten: Sicherheit interessiert das Business nicht.
Diese Argumentation wird derzeit ad absurdum geführt – und sie war schon immer ziemlich hanebüchen. Wenn der Vertrauensverlust zur Abwanderung von Benutzern führt, dann hat das Einfluss auf die Geschäftsmodelle. Und jeder weiß, dass es schwer ist, ein erschüttertes Vertrauen von Kunden wieder herzustellen und abgewanderte Kunden zurückzugewinnen.
Letztlich besitzt die Argumentation, Sicherheit sei nicht geschäftsrelevant, etwa die Validität der Aussage, dass ein Auto keine Bremsen brauche, weil man ja damit fahren will. Software braucht also keine Sicherheit, weil man etwas anderes damit machen möchte?
Vielleicht hat es ein bisschen länger gedauert, bis das Risiko bei Software und Internet-Diensten auch von der breiten Öffentlichkeit verstanden wurde, weil man eben nicht gegen den Baum fährt und tot ist. Den Nutzern ist inzwischen aber zunehmend klar, dass es ohne Sicherheit nicht geht. Diese Entwicklung lässt sich übrigens schon länger beobachten, man denke nur an die Sicherheitsdiskussionen rund um Microsoft-Produkte und die massiven Anstrengungen, die Microsoft hier unternommen hat (und unternehmen musste).
Es wird Zeit, dass Sicherheit als eine Grundfunktion jeder Anwendung und jedes Dienstes verstanden und von Beginn an in der Architektur berücksichtigt wird. Dann ist der Aufwand auch überschaubar, weil man sich Patches spart, Fehler vermeidet und nicht mühsam neue, unzureichende Funktionen dazu entwickeln muss.
Gute Softwarearchitektur berücksichtigt immer die Sicherheit, macht sie flexibel und steuerbar. Dann kann man auch mit „offenen“ Modellen beginnen, aber statt später mühsam Krückenlösungen zu schaffen, mit denen man Informationen von Benutzern besser schützt, muss man nur noch einen Schalter umlegen und die Konfiguration anpassen.
Das ist gute Software-Architektur. Vernachlässigt eine Software-Architektur die Sicherheit, ist sie hingegen schlecht. Denn sie spart nur vermeintlich Zeit und Geld und bringt nur vermeintlich eine schnellere Time-to-Market. Tatsächlich ist der Unterschied in der Umsetzung gering, die Konsequenzen fehlender Softwaresicherheit können dagegen das gesamte Geschäftsmodell gefährden.
Es ist höchste Zeit für „Sicherheit by Design“. Das gilt übrigens nicht nur für Internetdienste, sondern auch für interne Anwendungen. Denn auch dort liegt oft noch vieles im Argen. Und dort kann man die Time-to-Market sogar optimieren, weil man bei standardisierter und externalisierter Sicherheit auf Basis von generischen Sicherheitsdiensten weniger Zeit für das Testen und die Abnahmeprozesse von Software benötigt.