Risiken auf der Rechnung

Es gibt eine Reihe guter Gründe und eine Vielzahl Ansätze, "codierte Sicherheit" in Anwendungen zu vermeiden und Funktionen wie Benutzerverwaltung, Authentifizierung, Autorisierung und Auditing auszulagern und in standardisierter Form zu nutzen.

Der wohl wichtigste Grund für die Nutzung standardisierter, externer Sicherheitsfunktionen ist, dass sich damit Sicherheitsrisiken reduzieren lassen. Solche wiederholt verwendeten Sicherheitsfunktionen sind deutlich besser getestet, weswegen das Risiko von Sicherheitslücken geringer ist als das in selbst entwickeltem Code. Mancher mag zwar argumentieren, dass sich so die Voraussetzung für ein "single point of attack" schaffen lasse. Das ist aber nur ein Scheinargument, da die zentralen Funktionen wiederum besser gegen Angriffe zu schützen sind als viele verteilte Anwendungen, deren Sicherheitsfunktionen nur dem jeweiligen Entwickler bekannt sind.

Der zweite Grund sind die Kosten der Softwareentwicklung. Sicherheit ist für viele Programmierer ein ungeliebtes Kind, das man am Ende, nach der Umsetzung der eigentlichen Funktionen der Anwendung, noch dazu entwickelt. Aber auch das kostet Zeit und damit Geld. Die Nutzung wohldefinierter Klassen und Webservices verursacht deutlich weniger Aufwand. Allerdings liegt die Betonung auf "wohldefiniert" – Sicherheit zu realisieren muss einfach umzusetzen sein.

Ein weiteres Argument für die Externalisierung der Sicherheit sind die administrativen Kosten. Wenn man zentrale Verzeichnisse für die Benutzerverwaltung und zentrale Mechanismen für die Steuerung der Authentifizierung und Autorisierung nutzen kann, ist das im Betrieb günstiger als die dezentrale Administration vieler einzelner Anwendungen. Mehr noch: Zentrale Verwaltungskonzepte wie ein Identity Provisioning, ein zentrales Autorisierungsmanagement oder Werkzeuge für das Attestieren vergebener Berechtigungen lassen sich viel einfacher implementieren, wenn man standardisiert mit externalisierter Sicherheit arbeitet. Ansonsten steigen die Kosten für die Anbindung von Systemen, falls sie sich überhaupt in zentrale Verfahren einbinden lassen – bei proprietär entwickelter Sicherheit mangelt es häufig an geeigneten Schnittstellen.

Auch die Zeit, die man sowohl für die Entwicklung von Software als auch für ihre Abnahme benötigt, lässt sich durch standardisierte, externalisierte Sicherheit reduzieren. Die Wiederverwendung reduziert den Aufwand für die Entwicklung – zumindest bei "wohldefinierten", einfach nutzbaren Schnittstellen. Der Zeitraum für den Abnahmeprozess lässt sich damit oft massiv reduzieren, da man nur die Nutzung der Sicherheit prüfen muss, nicht aber die (bereits geprüften) externen Sicherheitsdienste.

Schließlich gibt es noch das Compliance-Argument. Anwendungen, deren Sicherheit nicht nachvollziehbar ist und deren Sicherheitsfunktionen nicht von außen steuerbar sind, befinden sich mit Blick auf gesetzliche und andere Vorschriften zumindest in einer Grauzone. Codierte Sicherheit stellt ein nicht kalkulierbares Sicherheitsrisiko dar.

Es gibt also genug Gründe, den unzweifelhaft bestehenden Aufwand zu betreiben, erst eine Sicherheitsarchitektur zu definieren, dann die erforderlichen externen Dienste bereitzustellen und schließlich die Entwickler zu schulen. Doch wer nicht unkalkulierbare Risiken hinsichtlich Sicherheit, Kosten und Zeit in Kauf nehmen möchte, kommt nicht umhin, diesen Schritt zu gehen.



KuppingerCole Select

Register now for KuppingerCole Select and get your free 30-day access to a great selection of KuppingerCole research materials and to live trainings.

Stay Connected

KuppingerCole on social media

Subscribe to our Podcasts

KuppingerCole Podcasts - listen anywhere


How can we help you

Send an inquiry

Call Us +49 211 2370770

Mo – Fr 8:00 – 17:00