1. Server-Setup
Das zentrale Element für einen gesicherten Web-Zugriff ist das Server-Dokument im Namens- und Adreßbuch (N&A). Nach der Installation eines neuen Server müssen die Voreinstellungen im Abschnitt "HTTP Server" angepaßt werden. Die von Notes vorgegebenen Einstellungen reichen für eine sichere Web-Site nicht aus.
Im ersten Schritt sollte im Abschnitt Sicherheitseinstellungen die Option: "HTTP-Client zum Durchsuchen von Datenbanken zulassen" auf NEIN gesetzt werden. Dies verhindert, daß Außenstehende durch die Eingabe des Domännamen im Web-Browser eine vollständige Liste aller auf dem Server befindlichen Datenbanken erhalten. Mit Hilfe der Datenbanknamen lassen sich oft Rückschlüsse auf interne Vorgänge ziehen. Durch die offenliegende Serverstruktur erhält der Außenstehende die Möglichkeit den Web-Server auszuspionieren.
Soll nur eine geschlossene Benutzergruppe auf den Server Zugriff erhalten, so kann die Option "Anonymous HTTP zulassen" auf NEIN gesetzt werden. Dadurch werden Benutzer gezwungen sich beim erstmaligen Zugriff auf die Web-Site zu authentifizieren. Damit der Domino-Server die Authentifizierung überprüfen kann, wird im N&A im Personendokument ein verschlüsseltes Paßwort eingetragen.
Als nächster Schritt sollte im Abschnitt "Mapping" der Parameter "Home-URL" geändert werden. Dieser
Wenn ein Benutzer nur den Domännamen eingibt, z.B. http://www.mysite.com, wird die eingebende URL mit dem Parameter ergänzt und die zugehörige Seite geöffnet (z.B. http://www.mysite.com/home.nsf?OpenDatabase). Es ist aber auch möglich, direkt auf ein Dokument in der Datenbank zu verweisen, indem als Parameter die vollständige URL mit der Doc-ID eingetragen wird.
2. Datenbankzugriff
Neben den Anpassungen des Servers ist es auch wichtig die Zugriffskontrollisten (ZKL) in den Datenbanken anzupassen.
Beim Zugriff mit einem Notes-Client erfolgt die Authentifizierung über ein Zertifikat in der Benutzer-ID. Im Gegensatz hierzu erfolgt beim Web-Zugriff die Benutzerüberprüfung durch den Benutzernamen und das im Personendokument abgelegte, verschlüsselte HTTP-Paßwort. Solange sich der Benutzer nicht authentifiziert hat, greift er anonym auf den Server zu. Deshalb sollten die ZKL der Datenbanken um den Eintrag "Anonymous" mit dem Benutzertyp "unbestimmt" ergänzt werden. Falls der Eintrag nicht vorhanden ist, werden allen Benutzer automatisch die Rechte des "Default"-Eintrags zugewiesen.
Als weiterer Gesichtspunkt sollte die Systemdatenbanken (dazu gehören u.a. names.nsf, catalog.nsf, log.nsf, certlog.nsf, adminp.nsf, billing.nsf, events4.nsf, statrep.nsf) beachtet werden. Bei diesen Datenbanken ist es wichtig diesen Zugriff einzuschränken. Neben dem Datenbankkatalog (catalog.nsf) ist insbesondere das Notes-Serverprotokoll (log.nsf) ein Angriffspunkt, um Informationen über Benutzer- und Dateistruktur zu erhalten. Ein einfacher Versuch mit der Eingabe http://Domännamem/log.nsf/?OpenDatabase macht dies deutlich.
Die durch die Server-Tasks automatisch erstellten Datenbanken verwenden die Schablonen mit den Vorgabewerten der ZKL. Bei allen Schablonen wird der "Default"-Zugriff auf Leser gesetzt. Werden also neue Datenbanken auf der Basis dieser Schablonen erstellt, muß anschließend die ZKL angepaßt werden um zu verhindern das ein unbefugter Zugriff von Außen ermöglicht wird.
Ein Löschen dieser Datenbanken löst das Problem nicht, da die auf dem Server ablaufenden Tasks automatisch die Systemdatenbanken anlegen. Zum Beispiel wird standardmäßig, aufgrund des Eintrags in der Notes.ini, nachts um 1.00 der Katalog-Task gestartet, der die nicht vorhandene Katalogdatenbank neu anlegt. Grundsätzlich reicht für einen Web-Server der Aufruf des HTTP-Tasks in der Notes.ini (ServerTasks=HTTP) aus. Zudem erhöht dies auch die Leistung des Domino-Server, da keine unnötigen Tasks Ressourcen verbraucht werden.
Um zusätzlich die Gefahr von offen Datenbank zu verhindern, sollten die ZKL’s der Schablonen angepaßt werden. Dazu muß der in eckigen Klammern stehende Vorgabewert "[-Default -]" auf "Kein Zugriff" gesetzt werden. Weiterhin muß beachtet werden, daß bei einem Software-Update die Schablonen automatisch ersetzt werden und die evtl. vorgenommene Anpassungen erneut durchgeführt werden müssen.
Eine weitere wichtige Einstellung ist "Max. Internet Browser Zugriff" im Abschnitt "Erweitert" in der ZKL einer Datenbank. Hier kann der Zugriff, unabhängig von den allgemeinen Einstellungen in der ZKL, für den Web-Benutzer eingeschränkt werden.
Hiermit ist es möglich, daß die Zugriffsrechte zwischen Notes- und Web-Zugriff für den selben Benutzer abweichen können. Gelangt z.B. ein Unbefugter an das HTTP-Paßwort eines Datenbankmanagers, ist somit der mögliche Schaden geringer, da der Max. Zugriff auf Leser gesetzt ist
3. Datenbankgestaltung
Neben den allgemeinen Einstellungen zur Konfiguration einer Domino-Platform, muß genauso sensible mit der Entwicklung von Web-Anwendungen umgegangen werden. Insbesondere dann, wenn die Anforderung besteht die Funktionsfähigkeit einer Anwendung sowohl für das Web als auch für Notes sicherzustellen. Mit der Funktion @UserRoles läßt sich erkennen, ob der Nutzer über das Web oder über Notes auf die Anwendung zugreift. Beim Zugriff über das Web wird "$$WebClient" an die Liste der Benutzerfunktionen angehängt. Um für den Web-Benutzer und Notes-Benutzer unterschiedliche Informationen anzuzeigen oder Vorgänge ablaufen zu lassen, kann in den Formeln @UserRoles für Masken, Teilmasken, Aktionen und Hide-When-Formeln angewendet werden. Bei der Gestaltung von Ansichten darf auf keinen Fall die Funktion @UserRoles angewendet werden. Ansonsten müßte jedesmal beim Aufruf einer Ansicht der vollständige Ansichtenindex neu berechnet werden und es käme beim gleichzeitigen Aufruf einer Ansicht von eine Notes-Client und Web-Browser zu Problemen.
In komplexeren Anwendungen ist es deshalb sinnvoll Web- und Notes-Design klar zu trennen, indem eigenständige Masken und Ansichten erstellt werden. Durch die damit gewonnene Übersichtlichkeit über die Designobjekte läßt sich eine solche Anwendung einfacher erweitern und pflegen.
Um das Zusammenspiel des für das Web und Notes getrennten Design zu gewährleisten, bestehen zwei Möglichkeiten:
1. Die Maskenformel in allen Ansichten wird verwendet um die Web- oder Notes-Maske aufzurufen. Mit der Vergabe von Aliasnamen muß sichergestellt werden, daß der im Feld Form gespeicherte Maskennamen immer identisch ist
2. Als weitere Möglichkeit kann eine Maske verwendet werden, die beim Öffnen eine berechnete Teilmaske für das Web oder Notes einbindet. Hierbei ist zu beachten, das ggf. ein verwendetes Rich-Text-Feld unbedingt in der Maske anstatt der Teilmaske plaziert sein muß.
Eine weitere Problematik ist, daß wenn keine spezielle Vorkehrungen getroffen werden, alle Designobjekte wie Masken, Ansichten und Navigatoren vom Web aus geöffnet werden können. Also auch Designobjekte die bei einer in Notes und Web integrierten Anwendung gar nicht für den Web-Zugriff vorgesehen sind. Hierbei muß allerdings der vergebene Name des jeweiligen Objektes dem Benutzer bekannt sein. Da jedoch meist aussagekräftige Bezeichnungen oder aber die in Notes unterstützen Standardnamen für einige Ansichten (z.B. ($all), ($inbox)) verwendet werden, fällt es für einen Außenstehenden nicht besonders schwer. So kann z.B. jede in Notes vorhandene Ansicht mit der nachfolgenden URL-Syntax geöffnet werden:
http://Domännamen/Datenbankpfad/ViewID?OpenView
Hierbei ist der Parameter "ViewID" entweder die von Notes vergebene 32-stellige hexadezimale ID oder aber ein vom Entwickler vergebener Name oder Aliasname. Genauso lassen sich auch Navigatoren und Masken öffnen und bei entsprechender Berechtigung können dann sogar neue Dokumente angelegt werden. In Analogie hierzu kann auch jedes in der Datenbank angelegte Dokumente geöffnet werden. Hierbei muß der nachfolgende URL-Syntax zum Öffnen eines Dokumentes eingehalten werden:
http://Domännamen/Datenbankpfad/Viewname/DocID?OpenDocument
Falls das Dokument über eine sortierte Ansicht geöffnet wird, kann anstatt der Doc-ID auch ein Schlüssel aus der ersten Ansichtenspalte angeben werden. Ist ein Dokument erstmal im Web-Browser geöffnet, so besteht unter Berücksichtigung der ZKL und der Dokumentenberechtigung die Möglichkeit das Dokument zu bearbeiten oder auch zu löschen. Mit der Änderung des letzten Parameters in der URL in "?EditDocument" bzw. "?DeleteDocument" kann ein Dokument unabhängig davon, was im Maskendesign vorgegeben ist, bearbeitet oder gelöscht werden. Dies ist besonders dann Fatal, wenn z.B. in einem Diskussionsforum keine Registrierung erfolgt und alle Web-Benutzer unter den Synonym "Anonymous" arbeiten. Wird dazu noch der Benutzer "Anonymous" als Autor im Dokument eingetragen, so besteht für jeden Web-Benutzer die Möglichkeit fremde Dokumente zu bearbeiten und ggf. zu löschen.
Um eine solche offene Datenbankgestaltung zu verhindern und damit nicht jedem etwas geübten Web-Benutzer mit Notes-Kenntnissen Angriffspunkte zu bieten, müssen vom Designer die Funktionsweise von Domino-Anwendungen verstanden werden. Jede Ansicht und jeder Navigator kann in Domino mit einer Maske verknüpft werden. Hierfür muß die Maske mit einem speziellen Namen benannt werden. Mit "$$ViewTemplate for Viewname" bzw. "$$NavigatorTemplate for Navigatorname" läßt sich individuell für jede Ansicht und Navigator eine Maske gestalten. Alle anderen Ansichten und Navigatoren für die keine eigene Maske angelegt ist, werden mit einer Vorgabemaske angezeigt: "$$ViewTemplateDefault" für Ansichten und "$$NavigatorTemplate" für Navigatoren. Diese Vorgabemasken sollten dafür verwendet werden, alle nur für den Notes-Client vorgesehene Ansichten und Navigatoren vor dem unberechtigten Zugriff vom Web aus zu schützen.
Eine weitere Sicherheitslücke sind Dokumente, die nicht in die Designstruktur passen. Dieses kann vorkommen, wenn z.B. die Gestaltung einer operativ eingesetzten Datenbank im nachhinein geändert wird und somit Dokumente mit einer nicht mehr vorhandenen Maske existieren. Dies trifft genauso auf Dokumente zu, die aus anderen Datenbanken in die Web-Datenbank eingefügt werden.
Notes verwendet bei Dokumenten mit fehlender Maske die Vorgabemaske, die aber nur in den seltensten Fällen eine für das Web zulässige Maske ist. Hieraus ergibt sich die Gefahr, daß der Web-Benutzer mit der Vorgabemaske Informationen angezeigt bekommt, die auf gar keinem Fall Außenstehenden zugänglich gemacht werden dürfen. Um dies zu verhindern, ist es zweckmäßig eine Maske ohne Feldinhalte ggf. mit einem Hinweis als Vorgabemaske zu bestimmen.
Weiterhin sollte durch einen Agenten verhindern werden, daß Dokumente mit sensiblen Inhalten in die Datenbank eingefügt werden dürfen. In diesem Zusammenhang stellt sich dann auch die Frage, was mit hereingesendeten Dokumenten passieren soll. Ist die Datenbank über das N&A Buch als Mail-In-Datenbank definiert, so sollten die Dokumente nur nach vorheriger Prüfung in die Datenbank eingefügt werden Ebenso sollte die Option "Gespeicherte Maske in Datenbank verwenden" in den Datenbankeigenschaften unbedingt deaktiviert werden.
Die hier vorgestellten Erfahrungen sollen keinesfalls davon abhalten weiterhin Domino-Anwendungen zu entwickeln, schließlich ist Domino als ursprünglich Groupware-Plattform eine hervorragenden Umgebung typische Internet/Intranet-Anwendungen unter Betrachtung der Gesichtspunkte von Flexibilität, Schnelligkeit und Kosteneffizienz zu erstellen. Es soll lediglich aufgezeigt werden, daß sich die Entwicklung derartiger Anwendungen von herkömmlichen Notes-Anwendungen unterscheidet. Der Domino-Designer muß sich sowohl weitgehend mit der Funktionsweise des Internets, des Domino-Servers und mit Notes als Entwicklungsplattform auskennen. Wer "mal eben schnell" den HTTP-Task auf den Notes-Servern startet, sollte sich vorher genau überlegen, welche potentielle Gefahren damit verbunden sind.
Autoren: Frank Brockmeyer, Marcus Soldner
Weitere Informationen zu diesem Thema (Stand Oktober 2002):