Kennzeichen S(icherheit): Fünf Gründe für die Externalisierung der Sicherheit

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.

In Pocket speichern vorlesen Druckansicht
Lesezeit: 3 Min.
Von
  • Martin Kuppinger
  • Alexander Neumann

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.

Mehr Infos

Kennzeichen S(icherheit)

In der neuen "Kennzeichen S(icherheit)"-Kolumne auf heise Developer setzen sich die Analysten des Unternehmens KuppingerCole mit Themen wie Identity- und Access Management sowie IT-Governance aus Softwareentwicklungsperspektive auseinander. Es geht vor allem um die Frage, wie man Sicherheit für Anwendungen standardisieren und externalisieren kann, um Sicherheit und Nachvollziehbarkeit bei optimiertem Entwicklungsaufwand zu erreichen.

  1. Anwendungsentwicklung und Sicherheit
  2. An Ausbildung führt kein Weg vorbei

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.

Martin Kuppinger
ist Gründer und Senior Analyst bei Kuppinger Cole, einem auf IAM, GRC, Cloud Computing und verwandten Themen spezialisierten Analystenunternehmen. Er hat langjährige Erfahrung auch in der Softwarearchitektur.
(ane)