Wie funktioniert die Token-Authentifizierung von ArcGIS Server?

Antwort

Hinweis: Dieser Artikel gilt für die ArcGIS-Versionen 9.x bis 10.2. In neueren unterstützten Versionen von ArcGIS Enterprise ist HTTPS standardmäßig aktiviert.

In ArcGIS Server werden zwei Authentifizierungsmethoden unterstützt: Authentifizierung auf Webebene (dazu gehören die integrierte Windows-Authentifizierung, PKI und HTTP Basic/Digest) und Authentifizierung auf GIS-Ebene (wird auch als Token-Authentifizierung bezeichnet). Sie müssen eine Methode auswählen, die Methoden können nicht kombiniert werden.
Um höchstmögliche Sicherheit zu erreichen, wird die Authentifizierung auf Webebene empfohlen. Die Authentifizierung auf GIS-Ebene kann in weniger sicheren Umgebungen verwendet werden, wenn die Architektur einen Load Balancer anstelle eines Web Adaptor vorschreibt, oder in Situationen, in denen eine Integration des Webservers in den von ArcGIS Server verwendeten Benutzerspeicher (beispielsweise integrierte ArcGIS Server-Konten) nicht möglich ist.

In diesem Artikel wird erläutert, wie die Token-Authentifizierung funktioniert und wie sie konfiguriert werden sollte.

Wenn ArcGIS Server für die Verwendung der Authentifizierung auf GIS-Ebene konfiguriert ist, werden die Benutzer in Client-Anwendungen aufgefordert, Benutzernamen und Kennwörter anzugeben. Anschließend senden diese Client-Anwendungen Benutzername und Kennwort an ArcGIS Server und erhalten im Gegenzug ein Token. Dieses Token kann dann bei nachfolgenden Anforderungen verwendet werden, sodass Benutzername und Kennwort nicht gesendet werden müssen.

Wenn ArcGIS Server nicht richtig konfiguriert ist, birgt die Verwendung von Token Sicherheitsrisiken in sich. Nachfolgend werden diese Risiken und entsprechende Abhilfemaßnahmen erörtert.

Risiko 1. Nach außen dringende Benutzernamen und Kennwörter

Alle Clients und APIs von Esri senden Benutzernamen und Kennwörter über HTTPS (verschlüsselt), wenn dies aktiviert ist. Wenn die Option nicht aktiviert ist, werden Benutzernamen und Kennwörter möglicherweise als Klartext über das Netzwerk gesendet. Um dies zu verhindern, wird dringend empfohlen, bei Verwendung der Authentifizierung auf GIS-Ebene HTTPS in ArcGIS Server zu aktivieren. Es wird standardmäßig nicht aktiviert.

Risiko 2: Replay-Angriffe

Ein gängiger Angriff besteht darin, den Netzwerkdatenverkehr auszuspionieren und Informationen wie Token abzurufen, um sie bei einem bösartigen Angriff wiederzuverwenden. Ein Angreifer, der ein ArcGIS Server-Token eines Benutzers abgerufen hat, könnte sich über einen bestimmten Zeitraum als dieser Benutzer ausgeben.

Es gibt Möglichkeiten, diese Art von Angriff zu minimieren. Die wirkungsvollste Möglichkeit besteht darin, für die gesamte Kommunikation HTTPS vorzuschreiben, sodass alle an und von ArcGIS Server gesendeten Daten verschlüsselt werden.

Außerdem gibt es Möglichkeiten, dieses Risiko über die Token-Einstellungen für ArcGIS Server zu minimieren. ArcGIS Server gibt sowohl Kurz- als auch und Langzeit-Token aus. Langzeit-Token müssen an eine IP-Adresse oder einen Referrer gebunden sein. Wenn ein Token an eine IP-Adresse gebunden ist, werden nur von dieser IP-Adresse stammende Token akzeptiert. Dies bedeutet, dass ein wiederverwendetes Token eines anderen Computers abgelehnt wird. Wenn ein Token an einen Referrer gebunden ist, muss ein bestimmter HTTP-Header, der als Referrer bezeichnet wird, festgelegt sein. Anderenfalls wird das Token abgelehnt. Client-Anwendungen entscheiden, ob Referrer oder IP-Adressen verwendet werden. Die Nutzung des Referrers kann die Sicherheit der Implementierung verringern und wird daher nicht empfohlen.

Kurzzeit-Token müssen nicht an eine IP-Adresse oder einen Referrer gebunden sein, da das Token oft nur für einen sehr kurzen Zeitraum gültig ist, was die Wiederverwendung erschwert. Der maximale Zeitraum für Kurzzeit-Token kann konfiguriert werden und so auf bis zu eine Minute reduziert werden.

Risiko 3: Entwicklungspraktiken

Token können über HTTP GET oder HTTP POST abgerufen werden. Die Verwendung von POST ist immer sicherer. Bei GET-Anforderungen bleiben möglicherweise Benutzernamen und Kennwörter im Verlauf von Netzwerkgeräten und im Browserverlauf zurück. APIs und Produkte von Esri verwenden POST beim Abrufen von Token. Als Arbeitserleichterung für Skriptersteller können Token jedoch über GET-Anforderungen abgerufen werden. Esri rät davon ab, in sicheren Umgebungen Token über GET-Anforderungen abzurufen.