Bundesamt für Sicherheit in der Informationstechnik

M 4.455 Autorisierung bei Web-Services

Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Verantwortliche der einzelnen Anwendungen, Leiter IT

Verantwortlich für Umsetzung: Administrator, Entwickler

Autorisierung

Während Authentisierung das Ziel hat, eine behauptete Identität zu verifizieren, bezweckt die Autorisierung die Überprüfung, ob eine zuvor authentisierte Entität befugt ist, auf bestimmte Ressourcen zuzugreifen. Beide Begriffe ergänzen sich also zu den Bestandteilen von Identitäts- und Zugriffsmanagement (englisch Identity and Access Management, IAM), und vor jeder Autorisierung muss entsprechend eine Authentisierung erfolgt sein. Das wichtigste Prinzip der Autorisierung ist, dass bei jedem Zugriff auf eine Ressource geprüft werden muss, ob die Berechtigungen der anfragenden Entität diesen erlauben - und zwar bei jeder Aktion, sprich im Fall von Web-Services jeder einzelnen Anfrage.

Rollen und Rechte

Die Zuordnung und Verwaltung von Einzelberechtigungen zu jedem einzelnen Benutzer ist bei komplexeren Anwendungen nicht sinnvoll umsetzbar. Daher muss ein geeignetes Rollenmodell entwickelt werden, bei dem den Benutzern jeweils ihren Aufgaben entsprechende Rollen zugewiesen werden können, über die sie die erforderlichen Berechtigungen erhalten.

Besondere Herausforderungen bei Web-Services

Bei Web-Services und insbesondere bei Serviceorientierten Architekturen ( SOA ) gibt es im Gegensatz zu monolithischen Anwendungen nicht nur einen, sondern mehrere Punkte, an denen diese Überprüfung stattfinden muss, denn die Durchsetzung von Zugriffsregeln (Policies) hat am Zugriffspunkt zu jedem Dienst stattzufinden. Diese Überprüfungspunkte werden auch als Policy Enforcement Points (PEP) bezeichnet. Sowohl die Planung als auch die praktische Administration solcher Regelwerke ist eine komplexe Herausforderung und sollte in einem zentralen Tool durchführbar sein.

Die Autorisierungsprüfinstanz muss in der Lage sein, Web-Service-Nachrichten zu lesen. Oft werden solche Prüfungsinstanzen auch selbst als Web-Service realisiert und nutzen Web-Service-Standards für die Abbildung von Rollen und Rechten.

Organisationsübergänge

Besondere Herausforderungen stellen sich, wenn die Web-Service-Nutzung Organisationsgrenzen überschreitet. Dann müssen Konzepte gefunden und Regelungen getroffen werden, wie mit Autorisierungsentscheidungen bei Anfragen aus und an andere Organisationen umgegangen wird. Entsprechende Vertrauensbeziehungen sollten immer durch formale Regelungen und Rechtemodelle konkretisiert werden.

Schichten

Da moderne Anwendungen und damit auch Web-Services typischerweise in mehreren Schichten (mindestens zwei, besser drei, etwa Präsentation, Geschäftslogik und Datenhaltung) aufgebaut sind, stellt sich die Frage nach der Autorisierung nicht nur einmal, beim Zugriff auf die Präsentationsschicht, sondern darüber hinaus auch beim Zugriff jeder Schicht auf die jeweils darunter liegende.

Eine weitere, darüber liegende Schicht können in einer SOA Verzeichnisse (Repositories) bilden, also Datenbanken, die Informationen über Dienste etwa nach dem Standard UDDI bereitstellen.

Minimale Rechte

Grundsätzlich ist auf jeder Schicht das Prinzip Zugriff nur soweit erforderlich (englisch Least Privilege) einzuhalten: Es dürfen immer nur so viele Rechte vergeben werden, wie im aktuellen Kontext zur Durchführung der fachlichen Aufgabe benötigt werden. Dies impliziert insbesondere, dass administrative Rechte nur von besonderen Benutzern und nur zum Zweck der Administration ausgeübt werden dürfen. Das Prinzip der minimalen Berechtigungen gilt auch für den Zugriff auf Repositories, falls diese nicht komplett öffentlich sind.

Der Grundsatz der minimalen Berechtigungen gilt ebenso für die Systemberechtigungen, mit denen die Prozesse von Applikationsserver, Datenbank, XML -Firewall und anderen Komponenten laufen.

Öffentlich zugängliche Web-Services

Insbesondere wenn Web-Services großen, möglicherweise anonymen Benutzerschichten angeboten werden (etwa als Dienst im Internet), ist mit zufälligen und systematischen Angriffen auf die Autorisierung auf allen Schichten zu rechnen. Hier sind besondere architektonische Maßnahmen zu treffen.

Von außen erreichbare Schnittstellen sollten dabei in ein isoliertes Grenznetz ( DMZ ) verlagert und von internen Diensten und Datenbeständen getrennt werden. Ebenfalls in der DMZ angesiedelt werden kann ein ergänzender Security-Service, der alle Anfragen an den Web-Service zuerst überprüft. Dabei kann er auch die Authentisierung und Autorisierung der Anfragen übernehmen, etwa mithilfe des Zugriffs auf einen Verzeichnisdienst im internen Netz. Die eigentlichen Daten befinden sich auf einem Anwendungsserver, ebenfalls im internen Netz, zu welchem der Web-Service nur bestimmte Anfragen erlaubt.

Sicherheitsgateways

Da Web-Service-Kommunikation sich häufig zwischen verschiedenen Netzbereichen vollzieht, spielen klassische Firewallkonzepte zur sicheren Trennung der Netze eine große Rolle. Hier kommt allerdings die Tatsache hinzu, dass innerhalb von SOAP -Nachrichten beliebige Daten, Befehle und Dateien (als Anhänge) verschickt werden können, auf die eine Firewall, die lediglich auf Adress- und Portebene filtert, nicht gezielt reagieren kann.

Dem Zweck angemessene Web-Service-Firewalls müssen als Application Level Gateways (ALG) ausgeführt sein. Sie werden in diesem Fall häufig auch als XML -Firewall oder XML -Security-Gateway bezeichnet. Solche Systeme können XML filtern, parsen, auf Schadsoftware prüfen und SOAP-Nachrichten untersuchen, um beispielsweise bestimmte Aktionen oder Akteure zu blockieren.

Auch für die Autorisierung kann eine XML -Firewall genutzt werden. In diesem Fall trifft sie die Entscheidung, ob ein authentisierter Benutzer berechtigt ist, eine bestimmte Aktion auszuführen, indem das in der Nachricht enthaltene Security Token untersucht, ausgewertet und kryptographisch überprüft wird.

Standards

Bestehende IT-Systeme verfügen häufig über proprietäre Zugriffsmechanismen. Informationen über Entitäten und Attribute werden in der Regel in Zugriffslisten (Access Control Lists, ACL) gespeichert, die sehr unterschiedlich aussehen können. Dadurch werden ein Austausch und eine gemeinsame Nutzung über verschiedene Systeme hinweg unnötig erschwert. Im Bereich der Web-Services, wo bereits Schnittstellen, Datenmodelle und Authentisierungsmethoden homogenisiert sind, sollten deshalb einschlägige Standards auch für die Zugriffskontrolle umgesetzt werden.

Im Gegensatz zu anderen spezifischen Themen ist Autorisierung allerdings bisher nicht in einen dedizierten Standard der WS-*-Familie gemündet: Der Standard WS-Authorization wurde bis Anfang 2014 nicht veröffentlicht. Stattdessen gibt es verschiedene XML -Standards, die sich teilweise überschneiden, teilweise ergänzen und jeweils das Thema Autorisierung mit einem bestimmten Fokus in Angriff nehmen.

In SAML (Security Assertion Markup Language), einem standardisierten XML -Framework für die Beschreibung und Abfrage von Authentisierungs-, Autorisierungs- und Attributinformationen einer Entität, zum Beispiel über SOAP , lassen sich in sogenannten Assertions (Zusicherungen) unter anderem Autorisierungsentscheidungen kodieren und austauschen.

XACML (eXtensible Access Control Markup Language) auf der anderen Seite stellt eine Sprache dar, die XML -basiert beschreibt, wie Regeln und dazugehörige Anfragen und Antworten zu gestalten sind, um eine kontext- oder attributbasierte Autorisierung der Zugriffskontrolle auf Ressourcen zu ermöglichen. Neben dem einfachen Gewähren oder Verwehren von Aktionen gibt es hier die Möglichkeit, vor oder nach der Autorisierungsentscheidung bestimmte weitere Aktionen zu erzwingen. XACML hat seine Stärken vor allem in der feingranularen Beschreibung und Übertragung von Zugriffsrechten.

XACML und SAML überschneiden sich zwar teilweise als Standards für Authentisierung und Autorisierung, ergänzen sich aber aufgrund des unterschiedlichen Fokus auch und werden daher häufig in Kombination eingesetzt. Während SAML allgemein die Authentisierung sowie die Übertragung von Authentisierungs- und Autorisierungsentscheidungen zwischen Entitäten ermöglicht, deckt XACML vor allem die Autorisierungsentscheidungen selbst ab, also wie diese im PEP verarbeitet werden.

Gestaffelte Verteidigung

Insbesondere, wenn Daten oder Operationen höheren Schutzbedarf tragen, sollte die Autorisierung nicht nur an einer Stelle geprüft werden, sondern eine gestaffelte Verteidigung (Defense in Depth) stattfinden. So kann ein Sicherheits-Gateway bereits die Autorisierung einer Anfrage überprüfen und der Dienst selbst vor der Ausführung noch einmal, um mögliche Fehlkonfigurationen oder Software-Schwachstellen des Gateways abzufangen.

Schließlich sollte im Fehlerfall immer auf eine sichere Entscheidung zurückgefallen werden (Fail Securely): Geht es um Vertraulichkeit oder Integrität, muss bei fehlgeschlagener Autorisierung der Zugriff verweigert werden. Nur im Fall, dass die Verfügbarkeitsanforderungen die übrigen Sicherheitsanforderungen deutlich überwiegen, darf im Fehlerfall eine Erlaubnis des Zugriffs erfolgen. Eine solche Entscheidung muss jedoch in jedem Fall in einer Risikoanalyse dokumentiert werden.

Prüffragen:

  • Wurde ein geeignetes Rollen-und-Rechte-Modell entwickelt?

  • Werden bei jedem einzelnen Zugriff auf jede Ressource immer wieder die Zugriffsrechte überprüft?

  • Existiert bei einer SOA ein zentrales Tool für die Verwaltung von Rollen und Rechten?

  • Wird das Prinzip der minimalen Berechtigungen konsequent durchgehalten, insbesondere auch für administrative Zugriffe und die Dienstkonten der beteiligten Software?

  • Kommt bei öffentlich erreichbaren Web-Services eine sichere Architektur zum Einsatz, zum Beispiel in Form einer DMZ mit Security-Service oder XML -Security-Gateway?

  • Fällt bei fehlgeschlagener Autorisierung das System auf einen sicheren Zustand entsprechend des Schutzbedarfs zurück?

Stand: 14. EL Stand 2014