Kennzeichen S(icherheit): Externalisierte Sicherheit – richtig gemacht
Die Grundidee der Externalisierung von Sicherheit aus Anwendungen heraus wurde schon mehrfach angesprochen. Wenn es aber um das Wie geht, sieht man sich schnell mit zwei Herausforderungen konfrontiert: Granularität und Performance.
- Martin Kuppinger
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 Grundidee der Externalisierung von Sicherheit aus Anwendungen heraus wurde schon mehrfach in dieser Kolumne angesprochen. Wenn es aber um das Wie geht, sieht man sich schnell mit zwei Herausforderungen konfrontiert: Granularität und Performance.
Beim Blick auf SOA-Umgebungen wird das schnell deutlich. Zum einen geht es bei ihnen darum, die Möglichkeit zu schaffen, dass nicht nur der Aufruf von Services autorisiert wird, sondern dass sich auch innerhalb von Services Abfragen gegen das Autorisierungssystem durchführen lassen, um eine zentrale Regelbasis zu nutzen. Mit anderen Worten: Man muss in der Lage sein, auf einfache Weise das Policy Enforcement zu starten und den PEP (Policy Enforcement Point) praktisch in der Anwendung zu verankern, mit dem auf den PDP (Policy Decision Point) zugegriffen wird.
Hierzu gibt es einige interessante Ansätze von Anbietern solcher Lösungen. Klar ist aber: Wer feine Granularität möchte, muss eine Bindung aus seinen Anwendungen zu externen Systemen eingehen. Das sollte so geschehen, dass man die externen Autorisierungssysteme flexibel austauschen kann, um sich nicht an einen bestimmten Hersteller zu binden.
Solch ein interessanter Denkansatz ist, Claims zu verwenden, also letztlich Attribute auf Basis von Standard-Federation-Techniken transportieren zu lassen. Der Reiz ist, dass diese Schnittstellen heute schon deutlich etablierter sind als beispielsweise direkte XACML-Schnittstellen (eXtensible Access Control Markup Language). Hierüber lohnt es sich in jedem Fall nachzudenken.
Termini kurz erläutert
Eine Kolumne ist nicht der Ort, Termini zu erläutern, weswegen wir die im Artikel erwähnten Begriffe in diesem Kasten kurz erklären.
- PEP: Policy Enforcement Point, Schnittstelle aus der Anwendung zum Autorisierungssystem
- Context Handler: kümmert sich darum zu erkennen, welche zusätzlichen Informationen für die Autorisierung benötigt werden, oft Teil des PDP
- PDP: Policy Decision Point, führt die eigentliche Autorisierungsprüfung durch
- PAP: Policy Administration Point, Verwaltungsschnittstelle für die Autorisierungsregeln
- PRP: Policy Retrieval Point, Datenspeicher oder Schnittstelle für die Autorisierungsregeln
- PIP: Policy Information Point, Datenspeicher oder Schnittstelle für weitere Autorisierungsinformationen wie Attribute zum Benutzer
Die zweite Herausforderung ist die Performance. Wenn man aus einer Anwendung heraus über den PEP zum PDP muss, dieser auf einen PRP (Policy Retrieval Point) und vielleicht auch noch – je nach Konstruktion auf dem Umweg über einen Context Handler – auf einen PIP (Policy Information Point) muss, um Regeln (PRP) und weitere Attribute zum Benutzer und dessen Kontext (PIP) zu ermitteln, kann der Weg ganz schön lang werden. Und Länge bedeutet eben auch einen Einfluss auf die Performance. Mit anderen Worten: Es ist genau zu überlegen, wo man welche Komponenten platziert – und jede Komponente muss auf Performance optimiert sein. Dem Caching beispielsweise von Regeln kommt eine ebenso wichtige Bedeutung zu wie der lokalen Platzierung etwa von PDPs, die damit verteilt arbeiten.
Viel konzeptionelle Arbeit ist nötig, aber das Ergebnis einer zentralisierten, nachvollziehbaren Steuerung von Autorisierung ist die Arbeit wert. Es ist ja nicht so, dass das alles neu wäre – in Host-Umgebungen finden sich solche Ansätze in anderer Form oft schon seit vielen Jahren und manchmal gar seit Jahrzehnten.
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.
Die Kolumne bisher
- Anwendungsentwicklung und Sicherheit
- An Ausbildung führt kein Weg vorbei
- Fünf Gründe für die Externalisierung der Sicherheit
- "Cloud-readiness" – Auswirkungen für Softwareentwickler
- U-Prove – Microsofts Technik für Datensicherheit
- Trends von der European Identity Conference
- Braucht es eine andere Softwareentwicklung für sichere Cloud-Anwendungen?
- Security bei der Entwicklung für die Cloud
- Über den effizienten LDAP-Einsatz
(ane)
