Kennzeichen S(icherheit): Braucht es eine andere Softwareentwicklung für sichere Cloud-Anwendungen?
Die "Public" Cloud wird als Plattform sowohl für die Softwareentwicklung als auch die Ausführung von Anwendungen immer beliebter. Viele betrachten allerdings beim Cloud Computing gerade Sicherheitsrisiken oft als Hindernis für den Einsatz. Doch was ändert sich wirklich im Vergleich zu "klassischer" Programmierung?
- Martin Kuppinger
Die "Public" Cloud wird als Plattform sowohl für die Softwareentwicklung als auch die Ausführung von Anwendungen immer beliebter. Viele betrachten allerdings beim Cloud Computing gerade Sicherheitsrisiken oft als Hindernis für den Einsatz. Doch was ändert sich wirklich im Vergleich zu "klassischer" Programmierung?
Letztlich geht es um die Frage, wie man sichere Anwendungen entwickeln kann, die interne und externe Dienste nutzen, die sich flexibel bei unterschiedlichen und hierfür vorgesehenen Service-Providern ausführen lassen und das in virtualisierten Umgebungen. Nur ist das wirklich grundlegend anders als die Realisierung von SOA-Applikationen? Es geht darum, dass man Services nutzt, sie orchestriert und sicherstellt, dass man die Services nur in definierter Weise von definierten Identitäten nutzen kann. Die Identitäten können Benutzer, aber auch andere Dienste sein.
Kennzeichen S(icherheit)
In der "Kennzeichen S(icherheit)"-Kolumne 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.
Die größte Änderung ist wohl, dass man einige Sicherheitsrisiken nicht mehr ignorieren kann, die man bei internen Anwendungen oft übersehen hat. Das Risiko von Angriffen durch privilegierte Benutzer verändert sich, weil es neben den internen IT-Administratoren und den privilegierten Benutzern der Anwendung nun auch noch die Administratoren der externen Cloud gibt, die man berücksichtigen muss. Da Risiko und Schwere von internen Angriffen heute ohnehin noch größer als die von externen Angriffen sind, sollte man sich damit sowieso beschäftigen. Durchgängige Konzepte für eine Ende-zu-Ende-Sicherheit, bei der sich Services im Kontext der Benutzer und nicht über technische Benutzerkonten mit umfassenden Berechtigungen aufrufen lassen, gehören auch zu guten internen SOA-Sicherheitskonzepten.
Letztlich kann man es einfach auf den Punkt bringen: Wer heute Best Practices bei der Entwicklung sicherer SOA-Anwendungen konsequent umsetzt, tut sich auch mit der Realisierung von sicheren Anwendungen für die interne, hybride oder externe Cloud nicht allzu schwer tun. Das setzt aber konsistente Konzepte nicht nur für die Verwaltung und Authentifizierung von Benutzern und Diensten, sondern insbesondere auch für die Autorisierung voraus. Sie müssen granular sein und Teil der Anwendungen werden. XACML (eXtensible Access Control Markup Language) ist hierfür einer der wichtigsten Standards.
Klar ist aber, dass man mit Workarounds oder der Ignoranz des Themas Sicherheit in der Cloud nicht mehr weiterkommt, sondern dass man ein "Security by Design" braucht. In immer komplexeren verteilten Anwendungen lässt sich Sicherheit nicht mehr nachträglich dazuprogrammieren, sondern man muss sie von Beginn an berücksichtigen.
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)
