Wenn eine Anwendung, eine Karte oder ein Web-Service über eine öffentliche (mit dem Internet verbundene und anonym zugängliche) Website oder Anwendung zur Verfügung gestellt wird, stellt sich häufig die Frage, wie der Zugriff, der in der Regel durch öffentliche Benutzer erfolgt, ordnungsgemäß gesichert werden kann. Organisationen möchten Benutzern (z. B. der Öffentlichkeit) einen einfachen Zugriff ermöglichen, indem sie weder eine Authentifizierung noch ein eingerichtetes Konto verlangen. Verständlicherweise möchten sie sicherstellen, dass die Daten von diesen Endbenutzern nicht missbraucht, unrechtmäßig abgerufen oder aufbewahrt werden.
In den meisten webbasierten Workflows fordert ein Client (häufig ein Webbrowser) Informationen – im Allgmeinen in Form eines Kartenbildes, einer Reihe von räumlichen Features und Attributen oder einer Raster- oder Vektorkartenkachel – von einem Webserver an. Diese Anforderungen haben eine Antwort zur Folge, die an den Client zurückgesendet wird. Der Client überträgt diese teilweise oder vollständige Darstellung der Daten auf das Clientgerät des Benutzers, wo sie zum Rendern eines Indikators oder Bildes oder zum Bereitstellen der gewünschten Kartenumgebung verwendet werden. Im Folgenden werden Überlegungen zum Datenzugriff bei den gängigen Servicetypen aufgeführt.
Beim Zugriff auf Kartenbild-Layer, die auch als dynamische Kartenservices bezeichnet werden, enthält das Antwortbild nur Pixel, d. h. eine Darstellung der Daten mit einer bestimmten kartografischen Konfiguration. Es wird auf einem Server generiert und als Bild an den Client zurückgegeben. Kartenservices können so konfiguriert werden, dass nur diese Art von dynamischem Kartenbild zulässig ist. Zu diesem Zweck wird die Abfragefunktion des Kartenservice deaktiviert. Dadurch wird verhindert, dass einzelne Datensätze an den Client weitergegeben werden. Diese Konfiguration kann jedoch eine eingeschränkte Funktionalität zur Folge haben und sollte daher nur in Betracht gezogen werden, wenn eine einfache Kartendarstellung ausreicht.
Feature-Layer können aus Karten- oder Feature-Services erstellt werden. Sie unterscheiden sich von Kartenbild-Layern, da die Feature-Daten, einschließlich ihrer Geometrie und Attribute, vom Server an den Client zurückgegeben werden müssen und im Client-Browser gerendert werden. Jeder öffentlich zugängliche Feature-Layer sendet kontinuierlich Datenblöcke an den Client. Dabei kann es sich um eine Anforderung vom Server für eine bestimmte geographische Ausdehnung oder eine Reihe von Features zu einem bestimmten Zeitpunkt handeln. Wenn eine Anwendung einen Feature-Layer verwendet, werden die Daten vom Client heruntergeladen, um sie ordnungsgemäß zu rendern. Da Feature-Layer auf dieser Datenübertragung an den Client basieren, sind Anforderungen wie “Ich möchte sicherstellen, dass Benutzer keine Daten herunterladen” funktional nicht mit einer App oder einem Workflow kompatibel, die von Feature-Layern abhängig sind.
Image-Services ermöglichen es Benutzern, dynamisch eine bestimmte Ausdehnung anzufordern, um ein Bild zu generieren. Die ursprüngliche Bildauflösung kann eine tatsächliche Raster-Darstellung der Daten bis zur maximalen vom Service unterstützten Bildgröße zurückgeben. Diese Bilder werden auf den Client, z. B. einen Web-, Desktop- oder mobilen Client, heruntergeladen und geben die entsprechende Datenteilmenge direkt an den Client weiter. Image-Services unterstützen außerdem eine Download-Funktion. Sie ist standardmäßig nicht aktiviert und kann zum Herunterladen des ursprünglichen Bildes oder eines konvertierten Formats verwendet werden. Sofern diese Funktion nicht ausdrücklich für die Funktionalität in einer App benötigt wird, sollte sie deaktiviert werden.
Bei den oben genannten Servicetypen können Daten nur im Szenario mit dem Kartenbild-Layer wirklich auf den Benutzerzugriff beschränkt werden. Da die Daten über ein gerendertes Bild übertragen werden, sind keine Attribute oder spezifischen Geometrien verfügbar.
Auch bei der Veröffentlichung von Daten und Services gibt es noch mehrere Methoden, mit denen ein gewisses Maß an Einschränkungen auf den Service angewendet werden kann, um die Anzahl der Benutzer oder die öffentliche Exposition zu verringern.
Die Referrer-basierte Beschränkung ist ein gängiges Muster zur Einschränkung der Datennutzung. Hierfür wird entweder ein Reverse-Proxy oder ein anderer Proxy-Typ benötigt, der einzelne HTTP-Anforderungen an den Service überprüfen und die Anforderungen ablehnen kann, die keinen Referrer-HTTP-Anforderungsheader mit einem Wert bereitstellen, der auf einer Allowlist steht. Konventionell generieren und senden alle Browser diesen Anforderungsheader von Anwendungen, die Ressourcen von einer anderen Domäne anfordern, sodass dies eine zuverlässige Methode zur Steuerung des browserbasierten Datenverkehrs ist.
Die Methode kann zwar effektiv sein, um Missbrauch entgegenzuwirken, schützt die Daten jedoch nicht vollständig, da ein Referrer-Header leicht von Angreifern manipuliert oder zu einer skript- oder programmgesteuerten Anforderung hinzugefügt werden kann, damit die Anforderung den Proxy passieren kann. Die API-Schlüssel der ArcGIS Location Platform können so festgelegt werden, dass nur bestimmte Domänen im Referrer-Header unterstützt werden. Weiterhin können sie dahingehend eingeschränkt werden, dass sie in einer Anwendung in dieser Domäne oder von einer Person, die den Header-Wert manipulieren kann, nicht verwendet werden können.
Eine weitere Option zum Sichern des Zugriffs besteht darin, Anforderungen auf der Grundlage eines Quell-IP-Bereichs zu beschränken. Dabei kann eine Ressource nur dann anonym angefordert werden, wenn die ursprüngliche IP-Adresse für die Anforderung innerhalb eines erwarteten Bereichs, z. B. einem lokalen Netzwerk oder einer NAT-basierten externen IP-Adresse für eine Organisation, liegt. Diese Einschränkungen können auf Webserver-, Load Balancer- oder Reverse-Proxy-Ebene angewendet werden. IP-basierte Filter können ebenfalls nützlich sein, um den Zugriff aus bestimmten Ländern oder Regionen zu filtern oder den Zugriff von einem bestimmten System mit einer festen externen IP-Adresse zu ermöglichen.
Die Verwendung eines API-Schlüssels ist eine weitere gängige Methode, um die Wiederverwendung eines öffentlichen Layers einzuschränken. Dazu wird jeder Anforderung ein API-Schlüssel hinzugefügt, der von einem API Management-Layer oder einem Reverse-Proxy-Layer validiert wird und Anforderungen ablehnt, die keinen gültigen API-Schlüssel enthalten. Während diese Methode einfachen Missbrauch verhindern kann, ist es für einen Angreifer relativ einfach, den verwendeten API-Schlüssel zu identifizieren und wiederzuverwenden, um Anforderungen in seiner eigenen Anwendung oder seinem eigenen Service auszuführen. API-Schlüssel werden vom Browser oder von der Client-Anwendung an den Server gesendet, sodass sie immer für den Client sichtbar sind und ggf. extrahiert und für andere Zwecke wiederverwendet werden können. Die beste Methode zur Reduzierung dieses Risikos besteht darin, zulässige Referrer pro Schlüssel zu erzwingen und Schlüssel auf unerwartete oder böswillige Verwendung zu überwachen.
Zusammenfassend lässt sich sagen, dass alle Daten, auf die in einer Anwendung zugegriffen werden kann, als vollständig öffentlich betrachtet werden sollten, wenn die gewünschte Zielgruppe der Anwendung oder des Service die breite Öffentlichkeit ist. Die meisten der oben vorgeschlagenen Beschränkungen können umgangen werden, und ein Angreifer kann in der Regel einen Weg finden, um eine Kopie der Daten für die Wiederverwendung zu extrahieren. Eine sorgfältige Zugriffsverwaltung, Haftungsausschlüsse und die Bereitstellung von Daten über öffentliche Data-Sites sind Methoden, um diese Vorbehalte hinsichtlich der öffentlichen Datenfreigabe abzubauen. Zudem können durch Umsetzen dieser Empfehlungen einige Bedenken hinsichtlich einer unsachgemäßen Verwendung zumindest zum Teil zu entschärft werden.