Bundesamt für Sicherheit in der Informationstechnik

M 4.453 Einsatz eines Security Token Service (STS)

Verantwortlich für Initiierung: Leiter IT

Verantwortlich für Umsetzung: Administrator

Ein Security Token Service ( STS ) ist ein Web-Service, über den Identitäts- und Berechtigungsinformationen angefordert, erneuert und überprüft werden können. Das Prinzip ist das eines Claims-based (deutsch etwa anspruchsbasierten) Identitätsmodells, wobei ein Anspruch (Claim) eine Aussage einer Entität über eine andere Entität oder sich selbst bedeutet, etwa über einen Benutzernamen oder ein bestimmtes Recht. Ein STS kann genutzt werden, um die Authentisierung und Autorisierung auszulagern oder, wenn mehrere Anwendungen oder Dienste den STS nutzen, einen Single Sign-on zu realisieren. Grundsätzlich wird eine Entkopplung von Diensten und ihren Aufrufern vorgenommen, nach der ein Dienst nicht mehr jedem einzelnen Aufrufer hinsichtlich der übermittelten Identitätsinformationen direkt vertrauen muss, sondern lediglich einem STS . Der Aufrufer kann dabei ebenfalls ein Web-Service sein (Web-Service-Authentisierung), aber auch eine Client-Anwendung oder ein Browser (passiver Client), wobei in letzterem Fall der STS als Webanwendung auftritt (Web-SSO).

Eine Vereinfachung entsteht dadurch, dass nicht mehr jede Anwendung oder jeder Dienst die Authentisierung von Benutzern, die Verwaltung von Benutzerkonten und Kennwörtern, die Anbindung an Verzeichnisdienste und die Integration in weitere Identitäts- und Zugriffskontrollsysteme der Institution beherrschen muss. Naturgemäß hat dieser Architekturwechsel jedoch bedeutende Auswirkungen auf Sicherheitsfragen.

Da der STS selbst auch einen Web-Service darstellt, sind für ihn die Maßnahmen des Bausteins B 5.24 Web-Services ebenfalls umzusetzen. Diese Maßnahme umfasst im Folgenden zusätzlich die Aspekte der Nutzung eines STS durch einen anderen Web-Service, gegebenenfalls auch aus einer anderen Institution heraus.

In der Praxis ist häufig ein STS bereits gegeben. Wird ein nicht selbst betriebener STS genutzt, handelt es sich um ein Outsourcing von Authentisierungsfunktionen. Es sind daher auch die Maßgaben des Bausteins B 1.11 Outsourcing und gegebenenfalls des Bausteins B 1.17 Cloud-Nutzung zu beachten. Bei einer Individualvereinbarung mit dem STS -Anbieter sind vertragliche Regelungen derart zu treffen, dass der Schutz der durch die Zugriffskontrolle gesicherten Daten gewährleistet ist. Andernfalls sind die Vertragsbedingungen des Anbieters genau daraufhin zu prüfen, ob diese dem Schutzbedarf gerecht werden. Ob ein bestimmter STS für eine Anwendung verwendet werden darf, hängt vom Schutzbedarf der Anwendung und der Möglichkeit weiterer Maßnahmen ab, den Schutz der Zugriffskontrolle eventuell noch zu verstärken, zum Beispiel durch eine Zwei-Faktor-Authentisierung. Hier ist das Vertrauen in den Anbieter durch klare Kriterien und die Stichhaltigkeit ihrer Einhaltung zu begründen.

Aber auch, wenn der STS innerhalb der eigenen Institution betrieben wird, findet durch die Auslagerung der Authentisierung eine Vererbung des Schutzbedarfs auf den STS statt, der mit Kumulationseffekten einhergeht, wenn mehrere Anwendungen oder Dienste als Konsumenten auftreten.

Es ist davon auszugehen, dass ein STS seinen Schutzbedarf bezüglich Vertraulichkeit und Integrität nach dem Maximumprinzip von den Daten erbt, auf die durch seine Verwendung zugegriffen werden kann. Bezüglich der Verfügbarkeit ist das ebenfalls der Fall, wenn die Nutzung des STS die einzige effektiv nutzbare Möglichkeit der Authentisierung darstellt. Zusätzlich sind Kumulationseffekte zu berücksichtigen, falls der STS die Authentisierung für eine hohe Anzahl von Diensten oder institutionen übernimmt.

Hinzu kommt, dass am STS nicht nur die Information vorliegen muss, welcher Benutzer welche Ansprüche hat, sondern durch die Anfragen nach Tokens auch Daten anfallen, welcher Benutzer welchen Dienst wie oft und in welchem Kontext nutzt. Bei menschlichen Benutzern ist hier die Privatsphäre zu betrachten (etwa durch Beachtung von Baustein B 1.5 Datenschutz ), bei maschinellen die Vertraulichkeit der Metadaten.

Die Realisierung eines STS ist mittels verschiedener Techniken (zum Beispiel REST) möglich, praktisch werden STS allerdings häufig mittels SOAP implementiert. Hierbei kommen im Allgemeinen Standards aus der WS-*-Familie zum Einsatz, um die Funktionalität und Interoperabilität zu gewährleisten.

Der Begriff des Security Tokens ist im Standard WS-Security definiert als jegliches Datenobjekt, das einen oder mehrere Claims, also verbürgte Aussagen über eine Entität, enthält und einer SOAP -Nachricht hinzugefügt werden kann. Häufig werden Security Tokens digital signiert, um die Aussagekraft kryptographisch nachzuweisen.

WS-Security unterstützt verschiedene Typen von Security Tokens, etwa das UsernameToken für die Authentisierung mittels Benutzername und Passwort. Das Passwort wird dabei als Hashwert übertragen, in dessen Berechnung eine Nonce (Zufallswert) und ein Zeitstempel einfließen, um Replay-Angriffe zu verhindern. Ein anderer vorgesehener Tokentyp ist das BinarySecurityToken für nicht XML -basierte Formate wie etwa X.509-Zertifikate. Weitere Tokentypen sind über einen Erweiterungsmechanismus vorgesehen.

Die meisten STS nutzen heute Token, die in der Security Assertion Markup Language (SAML) beschrieben werden. Dabei handelt es sich um einen verbreiteten Standard zur Beschreibung von Claims. Ein SAML Security Token (genauer eine SAML Assertion; die Spezifikation enthält außerdem noch weitere Elemente, die jedoch vor allem für Web-SSO benötigt werden) ist eine Beschreibung von Identitätsinformationen, Attributen, Authentisierungs- und Autorisierungsentscheidungen in XML , welche für eigene Zwecke erweiterbar ist.

Der SAML-Standard hat sich von Version 1.1 zu Version 2.0 bedeutend erweitert und umfasst nun weitere Protokolle und Einsatzszenarien (Profiles), welche sich vor allem um Web-SSO drehen. In jedem Fall ist eine grundlegende Entscheidung für einen in ausgereiften und in interoperablen Implementationen vorliegenden Satz von Standards zu treffen, die miteinander und mit den geplanten Kommunikationspartnern kompatibel sind und den jeweiligen Sicherheitsanforderungen gerecht werden.

In der Spezifikation WS-Trust, welche auf WS-Security aufbaut, wird der STS selbst mit seinen Aktionen definiert. Wenn ein Server eine Authentisierung verlangt, schickt der Client einen Request for Security Token (RST), zum Beispiel mit seinem Benutzernamen und Passwort in Form eines UsernameToken, an den STS. Hierin kann spezifiziert werden, welcher Tokentyp benötigt wird, welche Claims im Token enthalten sein sollen und wie das auszustellende Token zu sichern ist. Der STS liefert eine Request for Security Token Response (RSTR) zurück, die das Security Token enthält, welches der Client nun dem Server präsentieren kann. Dieser kann es je nach Szenario entweder anhand der Signatur selbst überprüfen oder wiederum dem STS zur Überprüfung vorlegen.

Damit Sicherheitstoken als vertrauenswürdig gelten können, sollten sie entweder verifizierbar signiert sein, oder die Übertragung muss auf anderem Weg durchgängig abgesichert sein, etwa auf Transportebene. Da die Signatur eines STS allerdings auch der Bestätigung der Claims in einem Security Token dient, müsste ihr Fehlen durch andere Maßnahmen wie etwa eine sichere Authentisierung während des Austauschs ausgeglichen werden.

Vertrauliche Daten wie etwa Passwörter dürfen nie ungesichert zu einem STS oder von diesem zum Konsumenten übertragen werden. Hier ist immer ein sicheres Hash-Verfahren mit Zufallskomponente (Salt, zum Beispiel mit Nonce) einzusetzen. Zusätzlich sind Replay-Angriffe durch geeignete Methoden, etwa den Einsatz von Zeitstempeln, zu verhindern, falls der Transportkanal diese nicht schon zuverlässig unterbindet.

Wenn das Security Token nicht den direkten, verschlüsselten Weg vom STS zum Server nimmt, muss auch dessen Inhalt durch Verschlüsselung geschützt werden, um zu verhindern, dass unbefugte Dritte das Token zur Authentisierung einsetzen können. Hierfür reicht es, den kryptographischen Teil, also die Signatur des STS , zu verschlüsseln. Enthält die Assertion jedoch weitere vertrauliche Daten, sind auch diese zu schützen. Grundsätzlich ist aber die benötigte Vertraulichkeit durch das Prinzip der Datensparsamkeit zu minimieren, indem immer nach möglichst allgemeinen Claims (zum Beispiel "Benutzer ist volljährig") gefragt wird.

Als weitere Schutzmaßnahme ist eine kurzfristige Lebensdauer für Token je nach Schutzbedarf anzusetzen, um den Schaden bei missbräuchlicher Verwendung zu verringern. Die meisten Frameworks geben hier Standards vor, die nach Möglichkeit verkürzt werden sollten.

Durch die vielen ineinander spielenden Standards samt ihrer verschiedenen Versionen und Standardisierungsgrade haben in der Vergangenheit Implementierungen häufig Schwachstellen aufgewiesen, die die Sicherheit erheblich beeinträchtigt oder sogar ausgehebelt haben. Da es sich bei den zugrundeliegenden Sicherheitsfunktionen um XML -Encryption, XML -Signaturen sowie häufig TLS/SSL handelt, spielen entsprechende Angriffe auch hier eine Rolle, was umso schwerer wiegt, je mehr kritische Autorisierungsentscheidungen von dem STS getroffen werden.

Angriffe wie XML Signature Wrapping, also die böswillige Änderung einer Nachricht, ohne dass die Signatur ungültig wird, werden vor allem dadurch möglich, dass die Erzeugung und Prüfung von Signaturen nicht aufeinander abgestimmt sind. Hier sollten entweder dieselbe Softwarebasis zum Einsatz kommen, oder, wenn dies nicht möglich ist (zum Beispiel externe STS , XML -Gateways), ausgiebige Tests der Schnittstellen nach jeder Anpassung stattfinden. Grundsätzlich sind etablierte, gut getestete Bibliotheken und Frameworks zur Realisierung der STS -Funktionalität auszuwählen, zu denen Informationen über Schwachstellen und Sicherheitspatches zeitnah bereitstehen und eingespielt werden müssen. Bei der Absicherung der Kommunikationswege ist Maßnahme M 4.450 Absicherung der Kommunikation bei Web-Services zu beachten.

In jedem Fall ist bei der Komplexität der Materie unbedingt Sachverstand bezüglich des sicheren Einsatzes eines STS bereits während der Konzeptionsphase hinzuzuziehen.

Prüffragen:

  • Wurde auch der STS selbst als Web-Service modelliert und entsprechend angemessene Maßnahmen aus dem Baustein B 5.24 Web-Services umgesetzt?

  • Wurden bei Nutzung eines fremden STS die Maßnahmen des Bausteins B 1.11 Outsourcing und B 1.17 Cloud-Nutzung beachtet?

  • Wurde die SSL/TLS Konfiguration vor der Freigabe zur Nutzung auf Fehler geprüft und wird der Status in periodischen Abständen validiert?

  • Entsprechen die vertraglichen Regelungen mit dem STS-Betreiber dem Schutzbedarf der über den STS zugänglichen Daten und Anwendungen?

  • Wurde die Vertraulichkeit der am STS anfallenden Daten betrachtet?

  • Wird die Datensparsamkeit durch möglichst allgemeine Claims konsequent durchgesetzt?

  • Wurden ausgereifte Bibliotheken und Frameworks für die Nutzung der STS-Funktionalität ausgewählt, für die auch aktuelle Informationen über Schwachstellen und Sicherheitspatches verfügbar sind?

  • Werden entweder Token signiert oder der Transportkanal durchgängig verschlüsselt und authentisiert?

  • Werden alle Passwörter nur als Hashwert übertragen mit Schutz gegen Brute-Force- und gegen Replay-Angriffe?

  • Wurde die Lebensdauer für Security Token möglichst niedrig gewählt?

Stand: 14. EL Stand 2014