Webmapping - aber sicher

Rechtliche Aspekte

Ein anderes Problem ergibt sich fr den Anbieter von Webmapping Anwendungen daraus, dass die meisten Geodaten nicht frei zug舅glich sind. Von den Landesvermessungs舂tern werden zwar detaillierte Datens舩ze digital zur Verfgung gestellt (ALK/ALB-Datensatz, ATKIS, Topographische Karten etc.). Allerdings kosten diese Daten eine Menge Geld und drfen dann oft nur innerhalb der Behde oder Firma, die diese Daten gekauft hat, eingesetzt werden. Auch datenschutzrechtliche Grnde spielen bei der Berechtigung des Zugriffs eine Rolle. Dies ist z.B. der Fall bei den ALB-Daten, bei denen Namen und Adressen von Flurstcken enthalten sind.

Eine weit verbreitete Methode fr das Bezahlen von Geodaten in Webmapping Anwendungen ist das so genannte pay-per-click. Damit ist gemeint, dass der Geldbetrag, den der Anbieter eines Webmapping Services dem Anbieter der Geodaten zahlen muss, davon abh舅gig ist, wie oft die Webmapping Anwendung aufgerufen wurde. Da sich die Anzahl der Zugriffe auf eine Webseite schwer im Voraus bestimmen l舖st, werden die Kosten fr den Anbieter damit unkalkulierbar.

Aus diesen rechtlichen Problemen ergibt sich fr den Anbieter von Webmapping die Bedingung, die Anwendungen nur einem ausgew臧lten Nutzerkreis zur Verfgung zu stellen. Oftmals muss dabei auch zwischen einzelnen Nutzergruppen innerhalb einer Behde oder Firma unterschieden werden, so dass eine differenzierte Zugangsberechtigung notwendig wird.

In diesem Artikel wird von der Implementation einer Lung fr das skizzierte Problem fr eine mittelgroﾟe Behde in Deutschland berichtet. Zum Einsatz kamen dabei der UMN Mapserver 3.6 sowie Zope, die beide als Freie Software entwickelt werden. Sie werden in diesem Artikel kurz vorgestellt. Danach wird demonstriert, wie sie sich sich zu einer schnellen und sicheren Anwendung vereinigen lassen.

Funktionsweise

In seiner einfachsten Form wird der UMN Mapserver als CGI-Binary eingesetzt, das - wie in nachstehender Abbilung gezeigt - vom Webserver gestartet wird. Der Mapserver liest dann eine Konfigurationsdatei, die so genannte Mapdatei oder das Mapfile, ein. Dort wird festgelegt, welche Geodaten aus welchen Datenquellen gelesen werden sollen, wie sie dargestellt werden usw. Danach rendert der UMN Mapserver aus den Geodaten die Bilddateien (Karte, Legende, Referenzkarte etc.) und schreibt diese ins Dateisystem. In ein HTML-Template werden die Pfade zu diesen Dateien eingetragen. Dieses Template wird dem Webserver schlieﾟlich zur Darstellung bergeben.

Da innerhalb eines Mapfiles alle relevanten Informationen zur Darstellung der Karte festgelegt werden, korrespondiert jeweils eine Mapdatei mit einer Mapserver Anwendung.

In der hier vorgestellten Anwendung wird der Mapserver als CGI-Binary eingesetzt. Trotzdem sei an dieser Stelle der Vollst舅digkeit halber erw臧nt, dass es darber hinaus mlich ist, den UMN Mapserver ber Skriptsprachen (PHP, Perl, Python) anzusprechen.

Sicherheitslcken

Auch wenn der UMN Mapserver eine ganze Reihe von Mlichkeiten in der Konfiguration bietet, so konzentriert sich die Funktionalit舩 im Wesentlichen auf das Rendern von Karten. Das hat den Vorteil, dass der UMN Mapserver darin so gut ist, dass er - wie bereits erw臧nt - eine ernst zu nehmende Alternative zu allen propriet舐en Produkten darstellt, bzw. sie in vielerlei Hinsicht bertrifft. Allerdings verfgt der UMN Mapserver ber kein eigenes Sicherheitskonzept. Wenn mehrere Mapserver Anwendungen unter Verwendung des selben Mapserver CGIs in eine Webseite eingebaut werden, dann kann jeder Nutzer, der fr eine Anwendung die Zugangsberechtigung zum CGI bekommen hat, damit auch die anderen Mapserver Anwendungen starten, indem er den Namen einer anderen Mapdatei als CGI-Parameter bergibt.

Wenn es darum geht, einzelne Mapserver Anwendungen nur fr einige Nutzer zug舅glich zu machen, kommt kommt also der Mapdatei eine zentrale Bedeutung zu . Immerhin wird in dieser Datei festgelegt, welche Geodaten zug舅glich sind und welches Template an welcher Stelle verwendet werden soll. Es muss daher dafr gesorgt werden, dass das CGI-Binary prinzipiell fr alle Nutzer aber nur in Kombination mit einem bestimmten Mapfile zug舅glich sein.

Ein weiteres Problem stellen die Bilddateien dar. Sie werden - wie bereits erw臧nt - in das Dateissystem geschrieben. Danach sind sie von dort aus ber den Webbrowser sichtbar. Um zu garantieren, dass niemand unbefugt Karten von Geodaten sehen kann, zu denen er eigentlich keinen Zugang hat, muss auch bei der Herausgabe der Bilder durch den Webbrowser eine Beschr舅kung eingefhrt werden.

Die Tatsache, dass die Bilddateien in das Dateisystem geschrieben werden, stellt in Bezug auf mlicherweise voll laufenden Plattenplatz ein weiteres Sicherheitsproblem dar. Das Problem kann durch ein Skript gelt werden, das - abh舅gig von den Systemanforderungen - die Bilddateien mehr oder weniger h舫fig abr舫mt.

Sicherheitskonzept

Das Zope Sicherheitskonzept baut auf den drei S舫len Authentifikation, Rechte und Autorisierung auf. Die Authentifikation definiert sich als das Erkennen des Nutzers einer Anwendung. Die Rechte legen fest, welche Aktionen auf einem Objekt von welchen Rollen mlich sind. Die Autorisierung schlieﾟlich stellt eine Verbindung zwischen den Nutzern und den Rollen her, die den Zugang zu den Objekten festlegen.

Wie man sieht, haben die Rollen eine wichtige Funktion. Eine Rolle bekommt gewissen Rechte an einem Objekt (z.B. Ausfhren eines bestimmten CGI-Binaries, Anschauen einer Seite etc.). Die einzelnen Nutzer bekommen eine oder mehrere Rollen zugewiesen, ber die sie dann die Erlaubnis haben, die Aktionen auszufhren, die diesen Rollen erlaubt sind. Die Aufgabe beim Management der Zope Sicherheit liegt also darin, Informationen ber die Nutzer und ihre Rollen sowie den Objektrechten und die an sie gebundenen Rollen zu verwalten.

Die Mapdatei

Zun臘hst sorgen wir dafr, dass das Ausfhren des Mapserver-CGIs (und damit der Zugang zu jeder Mapdatei) nur fr einen Nutzer mit der Rolle Manager mlich ist. Vor den Aufruf des Mapserver Binaries wird das Skript mapserv-proxy geschaltet. Ihm wird die Proxyrolle Manager zugewiesen. Damit ist dieses Skript in der Lage, das Mapserver-Binary zu starten. Innerhalb des Skriptes wird jedoch zun臘hst mit Hilfe von Daten in einer Nutzerdatenbank berprft, ob die Ausfhrung des Mapservers mit der angeforderten Mapdatei erlaubt ist. Nur wenn dies der Fall ist, wird die Mapserver Anwendung gestartet.

Bilddateien

ﾄhnlich verh舁t es sich mit den Bilddateien. Auch sie sind nur sichtbar fr die Rolle Manager. Um sie fr einen Benutzer frei geben zu knen, wird der Name des Nutzers, der sie erzeugt hat, innerhalb des Namens der Bilddatei eingebaut. Wenn die Bilddateien angefordert werden, prft das Skript mapserv-images, das ebenso wie mapserv-proxy die Proxyrolle Manager hat, ob der Name des aktuelle authentifizierten Nutzers und der Nutzername, der im Namen der Bilddatei verwendet wurde, identisch sind. Erst dann wird die Bilddatei frei gegeben.

Die Mapserver Anwendungen

Das Beispiel enth舁t zwei Mapserver Anwendungen. Die erste wurde im Rahmen eines Projektes fr die Bezirksregierung Hannover entwickelt. Sie beinhaltet eine Strassensuche auf einem ALB-Datensatz, die es ermlicht, einzelne H舫ser anhand von Gemeinde- und Strassennamen sowie der Hausnummer zu finden. Die Bezirksregierung Hannover hat die ALK/ALB-Daten freundlicherweise zu Pr舖entationszwecken zur Verfgung gestellt. Ein Beispiel fr ein Ergebnis der Strassensuche ist im nachfolgender Abbildung dargestellt.

Die zweite Anwendung ist im Rahmen eines Praktikum bei der Firma Intevation GmbH erstellt worden. Ziel war, einen freien Vektordatansatz der Stadt Osnabrck zu erstellen und die Daten sowie die Mlichkeit einer Fehlereingabe im Internet bereit zu stellen. Ein Ausschnitt aus der Anwendung ist in nachfolgender Abbildung zu sehen.

Einrichtung der Gruppen

Wir richten nun die beiden Gruppen osnabrueck und strassensuche ein, deren Aufgabe es ist, die Zugangsrechte zu jeweils einer Mapserver Anwendung zu verwalten. Dies geht recht intuitiv ber eine Webschnittstelle, die den Administrator nach einer GruppenID (d.h. ein Name, ber den die Gruppe eindeutig referenziert wird) sowie einem ausfhrlichen Gruppennamen fragt. Dieser Gruppenname stellt sozusagen die etwas ausfhrlichere Beschreibung der Gruppe dar und kann - im Gegensatz zur GruppenID - sp舩er jederzeit ge舅dert werden.

Einrichtung der Nutzer

ﾄhnlich wie die Einrichtung der Gruppen funktioniert auch die Einrichtung der Nutzer. Allerdings knen sehr viel mehr Informationen - wie z.B. Adresse und Telefonnummer - zu einem Nutzer gespeichert werden. Dies erleichtert die Identifikation mit der Realperson. Auﾟerdem wird an dieser Stelle ein Passwort vergeben, ber das der Nutzer sich sp舩er authentifiziert (1. S舫le des Zope Sicherheitskonzeptes). Weiterhin knen die Nutzer einer oder mehreren Gruppen zugeordnet werden. Wenn man die Gruppen als Rollen definiert (s. auch den n臘hsten Abschnitt), dann entspricht dies der 3. S舫le des Zope Sicherheitskonzeptes, der Autorisierung.

In unserem Beispiel richten wir die drei Nutzer Silke, Ulrike und Jan ein. Silke wird in die Gruppe osnabrueck, Jan in die Gruppe strassensuche und Ulrike in beide Gruppen eingetragen.

Einrichtung der Rechte

Bisher liegen mit den Gruppen und Nutzern sowie den Mapfiles nur die Grundbausteine fr die Rechteverwaltung fest. Nun muss noch eine Verbindung zwischen den Gruppen und den Mapfiles hergestellt werden. In Termini des Sicherheitskonzeptes von Zope stellen die Gruppen sozusagen die Rollen dar, w臧rend die Mapfiles die Objekte sind, an denen nun die Rechte vergeben werden mssen (2. S舫le des Sicherheitskonzept).

ﾜber eine Webschnittstelle knen nun Rechte wie in nachfolgender Tabelle dargestellt eingetragen werden:

Rechteverwaltung fr Mapserver Anwendungen

Nutzer/Gruppe	Mapfile	Layer	Vorgang
osnabrueck	osnabrueck.map	*	Anzeigen
strassensuche	strassensuche.map	*	Anzeigen
osnabrueck	strassensuche.map	gebaeude	Anzeigen

Die beiden wichtigsten Spalten der Tabelle sind Nutzer/Gruppe und Mapfile. Damit wird die notwendigen Zuordnung von Gruppen zu den zur Ansicht erlaubten Mapfiles vorgenommen. Die dritte Spalte Layer ermlicht es, dass nur einzelne Kartenebenen zur Ansicht erlaubt werden, nicht aber die gesamte Anwendung mit allen Informationen. Standardm葹ig sind alle Layer bzw. Kartenebenen erlaubt. Dies wird durch den Stern gekennzeichnet. Die Spalte Vorgang spielt an dieser Stelle noch keine Rolle, da es zun臘hst tats臘hlich nur darum geht, Mapfiles anzuzeigen. Sie kommt dann ins Spiel, wenn die Digitalisierung hinzugefgt wird.

In vorliegendem Beispiel drfen alle Nutzer in der Gruppe osnabrueck (also Silke und Ulrike) die Osnabrck Anwendung komplett sehen, von der Strassensuche allerdings nur die Kartenebene gebaeude. Alle Nutzer in der Gruppe strassensuche (also Jan und Ulrike) drfen nur die Anwendung Strassensuche sehen.

Einbettung in das Sicherheitskonzept

Zun臘hst muss dafr gesorgt werden, dass nur autorisierte Nutzer einen Zugang zu der Tabelle bekommen, in der die Punktdaten eingetragen werden. In diesem Fall wurde dazu nicht auf das Konzept der Proxyrollen zurckgegriffen. Es gibt verschiedene kleine Skripte die Lese- oder Schreibzugriff auf die Tabelle haben. Zu Beginn jedes dieser Skripte wird berprft, ob der autorisierte Nutzer die Berechtigung hat, eine Punkteingabe in diese Tabelle durchzufhren.

An dieser Stelle kommt die Spalte Vorgang zum Einsatz, in der nun neben der Aktion Anschauen auch die Aktion Punkteingabe zur Verfgung gestellt wird. Statt des Mapfiles wird nun eine Tabelle angegeben, so dass es mlich ist, mehrere Anwendungen zur Punkteingabe nebeneinander zu verwalten. Die Sehenswrdigkeiten fr Osnabrck werden in der Tabelle sehenswuerdigkeiten gespeichert. Um der Gruppe osnabrueck die Rechte an der Digitalisierung dieser Sehenswrdigkeiten zu erteilen, muss die Rechtetabelle um den vierten Eintrag in folgender Tabelle erweitert werden.

Rechteverwaltung mit Digitalisierung

Nutzer/Gruppe	Mapfile/Tabelle	Layer	Vorgang
osnabrueck	osnabrueck.map	*	Anzeigen
strassensuche	strassensuche.map	*	Anzeigen
osnabrueck	strassensuche.map	gebaeude	Anzeigen
osnabrueck	sehenswuerdigkeiten	*	Punkteingabe