Kalender
|
September '10 | |||||
| Mo | Di | Mi | Do | Fr | Sa | So |
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | |||
Kategorien
Allgemeines
Donnerstag, 9. April 2009
Sichere OGC-Services
Es hat mich schon lange gestört, dass man GeoWebDienste (z.B. WMS, WFS) nicht auf einfache und möglichst kostengünstige Art so absichern kann, dass nur die Nutzer diese Dienste nutzen können, die das auch können sollen. Normalerweise ist es so, dass wenn ein Dienst im Netz (Internet wie auch Intranet) steht, dieser auch von jedem (der die URL kennt) genutzt werden kann. Es gibt keine Möglichkeiten aus den Diensten heraus, den Zugriff zu beschränken.
Wenn man die Dienste selber verändert (z.B. durch anfügen eines Requests in der Form User=irgendwer&passwort="meinpass" so sind diese nicht mehr universell einsetzbar, weil ein solcher Request im Allgemeinen vom Server abgewiesen wird. Jede Lösung, die ich kenne hat den einen oder anderen Haken und kann nur mit ausgewählten Anwendungen (meist des Hersteller der Sicherheitslösung) genutzt werden.
Aufgabe war also eine Lösung zu finden, die die Dienste nicht "anfasst", die aber einen verlässlichen Schutz gewährleisten kann.
Es lag nahe sich in dem großen Baukasten an OpenSource-Lösungen umzuschauen und daraus eine entsprechende Lösung zusammenzustellen. Diese Lösung kann nur, da sie die Dienste selbst nicht verändern soll, darin bestehen, auf Netzwerkebene einen sicheren Kanal herzustellen und dafür zu benutzen.
Die gefundene Lösung benutzt ...
Wenn man die Dienste selber verändert (z.B. durch anfügen eines Requests in der Form User=irgendwer&passwort="meinpass" so sind diese nicht mehr universell einsetzbar, weil ein solcher Request im Allgemeinen vom Server abgewiesen wird. Jede Lösung, die ich kenne hat den einen oder anderen Haken und kann nur mit ausgewählten Anwendungen (meist des Hersteller der Sicherheitslösung) genutzt werden.
Aufgabe war also eine Lösung zu finden, die die Dienste nicht "anfasst", die aber einen verlässlichen Schutz gewährleisten kann.
Es lag nahe sich in dem großen Baukasten an OpenSource-Lösungen umzuschauen und daraus eine entsprechende Lösung zusammenzustellen. Diese Lösung kann nur, da sie die Dienste selbst nicht verändern soll, darin bestehen, auf Netzwerkebene einen sicheren Kanal herzustellen und dafür zu benutzen.
Die gefundene Lösung benutzt ...
... OpenVPN um eine sichere Verbindung herzustellen. Die Einzelheiten sind HIER beschrieben.
Kurz: es wird eine getunnelte sichere Netzwerkverbindung mittels Software hergestellt, die völlig transparent ein weiteres Netzwerk über eine zusätzliche (virtuelle) Netzwerkkarte bereitstellt. Wenn also der Server im Netz erreichbar ist, kann dieser über eine virtuelle "zweite Leitung" sichere Dienste bereitstellen.
Hier findet sich eine Anleitung, wie man ganz praktisch eine solche Verbindung einrichtet, was am Server gemacht werden muss und worauf zu achten ist. Diese Anleitung ist aber nur als Einstieg gedacht - für einen produktiven Einsatz muss noch die eine oder andere Einstellung erfolgen (vorletzter Absatz).
Vorteile: (gegenüber anderen Lösungen)
- Dienste können so genutzt werden wie nicht abgesicherte Dienste
- keine Anpassungen an den (GIS)-Clients nötig
- volle OGC-Konformität
- es können weitere Dienste des Servers über diese Verbindung genutzt werden (Websites o.ä.)
- zertifikatsbasierte Authentifizierung (ohne passende Zertifikate geht nix)
Nachteile:
- Einsatz für WebGIS-Anwendungen nicht wirklich sinnvoll (aber möglich!)
- mögliche IP-Kollisionen (wenn VPN gleichen Adressbereich wie normales Netz nutzt)
- zertifikatsbasierte Authentifizierung (mal eben mit Benutzernamen & Passwort anmelden geht nicht)
- Keine weiter einstellbaren Zugriffsbeschränkungen (nur auf bestimmtes Gebiet z.B.)
Die Idee VPNs (virtuelle private Netzwerke) für diesen Zweck einzusetzen hatte ich schon länger, hatte aber immer Respekt vor der Komplexität einer solchen Lösung. Nun hab ich es einfach mal ausprobiert und es ist nicht so schlimm wie gedacht - eher: es ist erstaunlich einfach ein solches VPN aufzusetzen. Es handelt sich ja um eine erprobte Technologie, die schon lange eingesetzt wird.
Nach meinen Erfahrungen mit dieser Lösung werde ich diese auch für den produktiven Einsatz vorsehen und erweitern.
Erweiterungsideen:
- IP-Basierte Zugriffsverwaltung (Zuordnung Zertifikat bzw. MAC zu IP)
- IP-Logging
- Trennung von offenen & geschützten Diensten auf einem Server durch entsprechende Apache-Konfiuration
- usw.
Kurz: es wird eine getunnelte sichere Netzwerkverbindung mittels Software hergestellt, die völlig transparent ein weiteres Netzwerk über eine zusätzliche (virtuelle) Netzwerkkarte bereitstellt. Wenn also der Server im Netz erreichbar ist, kann dieser über eine virtuelle "zweite Leitung" sichere Dienste bereitstellen.
Hier findet sich eine Anleitung, wie man ganz praktisch eine solche Verbindung einrichtet, was am Server gemacht werden muss und worauf zu achten ist. Diese Anleitung ist aber nur als Einstieg gedacht - für einen produktiven Einsatz muss noch die eine oder andere Einstellung erfolgen (vorletzter Absatz).
Vorteile: (gegenüber anderen Lösungen)
- Dienste können so genutzt werden wie nicht abgesicherte Dienste
- keine Anpassungen an den (GIS)-Clients nötig
- volle OGC-Konformität
- es können weitere Dienste des Servers über diese Verbindung genutzt werden (Websites o.ä.)
- zertifikatsbasierte Authentifizierung (ohne passende Zertifikate geht nix)
Nachteile:
- Einsatz für WebGIS-Anwendungen nicht wirklich sinnvoll (aber möglich!)
- mögliche IP-Kollisionen (wenn VPN gleichen Adressbereich wie normales Netz nutzt)
- zertifikatsbasierte Authentifizierung (mal eben mit Benutzernamen & Passwort anmelden geht nicht)
- Keine weiter einstellbaren Zugriffsbeschränkungen (nur auf bestimmtes Gebiet z.B.)
Die Idee VPNs (virtuelle private Netzwerke) für diesen Zweck einzusetzen hatte ich schon länger, hatte aber immer Respekt vor der Komplexität einer solchen Lösung. Nun hab ich es einfach mal ausprobiert und es ist nicht so schlimm wie gedacht - eher: es ist erstaunlich einfach ein solches VPN aufzusetzen. Es handelt sich ja um eine erprobte Technologie, die schon lange eingesetzt wird.
Nach meinen Erfahrungen mit dieser Lösung werde ich diese auch für den produktiven Einsatz vorsehen und erweitern.
Erweiterungsideen:
- IP-Basierte Zugriffsverwaltung (Zuordnung Zertifikat bzw. MAC zu IP)
- IP-Logging
- Trennung von offenen & geschützten Diensten auf einem Server durch entsprechende Apache-Konfiuration
- usw.
Trackbacks
Trackback für spezifische URI dieses Eintrags
Keine Trackbacks
Suche
Blog abonnieren
CC
Powered by
