Kennzeichen S(icherheit): Security bei der Entwicklung für die Cloud

Müssen Entwickler anders als gewohnt programmieren, wenn sie Cloud-Anwendungen schreiben? Die Geister scheiden sich beim Beantworten der Frage, doch eines ist klar: Viele Ansätze, die bei der Entwicklung anderer Anwendungen eine Rolle spielen, sind auch für die Cloud gültig.

Einer der Gründe (wenn auch nicht der einzige) für das Cloud Computing ist eine hohe Skalierbarkeit, die man durch die Verteilung von Ressourcen in der Cloud erreicht. Das lässt sich beim Programmieren durch ähnliche Ansätze erreichen, etwa bei der Programmierung auf einem Multiprozessor-System und/oder bei der Entwicklung von Multithreaded-Programmen. Es ist wichtig, Prozesse in kleine, modulare Teile zu gliedern – Atomizität, Statuslosigkeit sowie Synchronisierung sind wichtige Konzepte und haben bei der Entwicklung von Cloud-Applikationen ebenfalls ihre Geltung.

Ein guter Vergleich ist der mit der Entwicklung innerhalb einer serviceorientierten Architektur (SOA). Hier spielen die genannten Faktoren eine wichtige Rolle, doch es kommt noch ein zusätzlicher Punkt hinzu: eine Sicherheitskomponente, die Authentisierung und Autorisierung innerhalb einer SOA bereitstellt. Dort finden sich mehrere verbreitete Standards, etwa WS-Security bei SOAs auf Basis von SOAP oder Spring Security.

Mehr Infos

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.

1. Anwendungsentwicklung und Sicherheit
2. An Ausbildung führt kein Weg vorbei
3. Fünf Gründe für die Externalisierung der Sicherheit
4. "Cloud-readiness" – Auswirkungen für Softwareentwickler
5. U-Prove – Microsofts Technik für Datensicherheit
6. Trends von der European Identity Conference
7. Braucht es eine andere Softwareentwicklung für sichere Cloud-Anwendungen?
   

Beim Cloud Computing kann es jedoch viel komplexer zugehen: Oftmals werden einzelne Module komplett aus der Kontrolle eines Unternehmens ausgegliedert. So fließen Daten zwischen Unternehmen und Applikationsprovidern hin und her. Das ist einerseits vorteilhaft, da sich Firmen mehr auf ihr Kerngeschäft fokussieren und somit Anwendungen und Prozesse auslagern können. Andererseits ist das problematisch, da es wesentlich schwieriger ist, die Kontrolle zu behalten über das, was mit den Daten geschieht und wer Zugriff auf die Prozesse hat.

In der heutigen IT-Landschaft ist es immer noch üblich, auf Benutzer und Rollenkonzepte zu setzen. Daher liegt es auf der Hand, sie auch im Cloud-Umfeld zu verwenden. Das führt jedoch langfristig zu Problemen, gerade wenn die Komplexität der Cloud-Infrastruktur zunimmt, was durchaus bei einer positiven Bilanz einer Cloud-Initiative eines Unternehmens zu erwarten ist. Benutzer-IDs, Passwörter und Rollen sind meist stark an einen Kontext gebunden und haben in einem verteilten Cloud-Konzept keine eindeutige Gültigkeit. Dafür sind Richtlinien notwendig, die den Umgang mit Daten oder Prozessen regeln.

Es gibt dazu mehrere Ansätze, die sich mit dem Thema beschäftigen. Das von Microsoft spezifizierte Identity Metasystem realisiert es beispielsweise, Informationen zu Benutzern in sogenannten "Claims" mitzuliefern und sie im gesamten Prozess mitzutragen. Die Claims können nicht nur Informationen über den Benutzer enthalten, sondern auch weitere Datenfelder, die für den Prozessablauf wichtig sind. Somit lässt sich von der herkömmlichen, aber unsicheren Praxis absehen, Teile von Prozessen als privilegierter Benutzer auszuführen – das war (und ist) leider oft der Fall.

Der XACML-Standard (eXtensible Access Control Markup Language) erfährt zunehmend Beachtung und findet mittlerweile selbst in komplexen Umgebungen Anwendung. Er definiert sowohl eine XML-Sprache zur Zugriffskontrolle als auch eine standardisierte verteilte Architektur. Letztere besteht aus mehreren Teilen:

• Policy Enforcemente Point (PEP),
• Policy Decision Point (PDP),
• Policy Information Point (PIP) und
• Policy Administration Point (PAP).

Der Policy Enforcemente Point sitzt überall dort, wo ein Zugang überprüft werden muss und sich entweder einteilen oder abweisen lässt. Er führt jedoch keine Entscheidung durch, sondern fragt sie beim Policy Decision Point ab. Der kann wiederum (wenn notwendig) zusätzliche Informationen bei Policy Information Points abfragen. Die lassen sich – wie ihr Name verrät – zum Verwalten der einzelnen Policies verwenden. Die XACML-Sprache lässt sich gut innerhalb der definierten XACML-Architektur einsetzen, sie ist aber unabhängig von der Architektur – demnach eignet sie sich auch gut zum Austausch von Policies.

Interessant ist die Verknüpfung des Identity Metasystem mit XACML. Dadurch dass Ersteres in den Claims beliebige Daten mitliefern kann, ließe sich auch eine XACML-Policy mit übergeben, und diese könnte man dann dazu benutzen, um in feiner Auflösung den Zugang zu kontrollieren. In dem Zusammenhang bedeutet "feine Auflösung", den Zugang bis ins kleinste Detail zu regeln – beispielsweise den Zugriff auf bestimmte Datenfelder. Das steht im Gegensatz zu einer groben Auflösung, die lediglich den Zugang zum kompletten Prozess bewilligt, mit allem, was er enthalten mag.

Es ist jedoch noch einiges zu tun, bevor sich ein solcher Ansatz auch konsequent einsetzen lässt. Zum einen gibt es noch wenig Erfahrung beim Einsatz, zum anderen sind noch einige Fragen offen, insbesondere zur Skalierung: Wie lässt sich etwa ein solches Konzept effizient einsetzen, wenn Transaktionen immer feiner und modularer werden, über traditionelle Unternehmensgrenzen hinaus verteilt sind und drastisch in der Zahl zunehmen?

Letztlich geht es aber besonders um das Vertrauen (Trust). In einer verteilten Umgebung ist es sicherlich von Vorteil, mit einem Datensatz gleich noch eine Policy mitzuliefern, die den Umgang mit den Daten regelt. Man muss sich jedoch darauf verlassen können, dass die Regeln auch eingehalten werden. Das gilt ebenso beim Einsatz von Policy Decision Points, die Anfragen zur Zugriffserteilung von Policy Enforcement Points beantworten. Man muss sich darauf verlassen können, dass die Enforcement Points die Entscheidungen von den Decision Points korrekt umsetzen.

Das verwandte Rights Managements erreicht das durch sogenannte "Trusted Clients": Man verlässt sich auf die Softwareanbieter von Client-Software (wie die DRM-Media-Player), die ihre Software angeblich ordnungsgemäß absichern. Doch für eine verteilte Umgebung, in der viele unterschiedliche Module innerhalb und außerhalb eines Unternehmens verteilt sind, gibt es zwar gute Ansätze, aber noch keine komplette und offene Lösung. Eines ist aber sicher: Daran wird fieberhaft gearbeitet.

Felix Gaehtgens
ist Senior Analyst bei Kuppinger Cole, einem auf Identity Management, GRC, Cloud Computing und verwandten Themen spezialisierten Analystenunternehmen. (ane)