Bei den Elementen für die Sicherheit von Anwendungenmaus dem vorangegangenen Artikel lag der Schwerpunkt auf den Maßnahmen, die für die Umsetzung von Compliance-Anforderungen von besonderer Bedeutung sind. In diesem Artikel wird generell diskutiert, welche Sicherheitsmechanismen in Anwendungen genutzt werden können und sollten, um einerseits ein hohes Maß an Sicherheit zu erreichen, andererseits aber den Entwicklungs- und Administrationsaufwand zu minimieren.
„Externe Sicherheit“
Die wohl wichtigste Regel ist, dass Sicherheit nicht hart codiert werden darf. Der prinzipiell größte Fehler, der gemacht werden kann, sind Anwendungen, bei denen beispielsweise individuelle Benutzer in Leserfeldern genannt sind. Grundsätzlich gilt, dass die Festlegung, welche Benutzer was in welchen Anwendungen machen dürfen, extern – außerhalb des Domino Designers – verwaltet werden sollte. Die Standardschnittstellen sind einerseits die Administration von Personen und Gruppen im Domino Directory und andererseits die Verwaltung von ACLs bei den einzelnen Datenbanken.
Gruppen – nicht Benutzer
Eine zweite wichtige Grundregel, die in einem solchen Design Aufgabe des Administrators ist, heißt: Arbeiten Sie mit Gruppen, nicht mit einzelnen Benutzern. Es ist grundsätzlich deutlich einfacher, mit Gruppen zu arbeiten. Es gibt generell nur eine überschaubare Zahl von Gruppen, die weitgehend statisch ist. Dagegen ist die Liste der Benutzer meistens recht dynamisch, weil immer wieder Mitarbeiter ein Unternehmen verlassen, neu eingestellt werden oder in einen anderen Unternehmensbereich wechseln. Wenn einzelne Benutzer in ACLs aufgenommen und beispielsweise Rollen zugeordnet werden, führen diese Änderungen zu einem erheblichen administrativen Aufwand. Außerdem müssen die Änderungen zumindest teilweise über den AdminP- Prozess auch aufwändig in einzelnen Datenbanken umgesetzt werden. Wenn mit Gruppen gearbeitet wird, beschränkt sich der Konfigurationsaufwand dagegen darauf, die Mitgliedschaft in den Gruppen bei Bedarf anzupassen. Da einzelne Gruppen meist bei mehreren Datenbanken beispielsweise für die Vergabe von Zugriffsberechtigungen verwendet werden, verringert sich der administrative Aufwand auf diese Weise erheblich. Außerdem wird die gesamte Administration übersichtlicher und auch die Nachvollziehbarkeit der aktuellen Sicherheitskonfiguration erhöht.
Rollenkonzepte
Der Kernpunkt bei der Entwicklung einer Anwendung ist die Frage, ob es sinnvoll oder erforderlich ist, ein Rollenkonzept zu erarbeiten. Es gilt also zu klären, ob es innerhalb der Anwendung Bereiche gibt, für die spezielle Zugriffsberechtigungen erforderlich sind oder ob ein Benutzer, der beispielsweise Editor-Zugriff hat, alle Dokumente in der Datenbank in gleicher Weise nutzen darf. Sobald man unterschiedliche Berechtigungen – und sei es nur für spezielle Konfigurationsdokumente – benötigt, ist ein Rollenkonzept unerlässlich.
Dabei müssen die Aufgaben definiert werden, die spezielle Rollen erfordern. Es bietet sich an, eine Liste der Masken, Agenten und anderer Designelemente mit speziellen Einschränkungen für die Nutzung zu erstellen und dieser Liste die Nutzergruppen zuzuordnen. Die Liste kann als Basis für die Beschränkung der Anzahl an Rollen dienen. Letztlich gilt es, den Kompromiss zwischen der erforderlichen Anzahl spezieller Rollen und den Anforderungen eines differenzierten Sicherheitskonzepts zu finden.
In den meisten Fällen wird man mit ein oder zwei speziellen Administratorenrollen, eventuell noch differenziert nach Lese- und Änderungsberechtigungen auskommen. Da die Rollen vor allem in Leser- und Autorenfeldern genutzt werden und es hier meist unterschiedliche Berechtigungen geben soll, ist eine solche „doppelte“ Definition von Rollen häufig unumgänglich – und auch bei gängigen Datenbanken wie dem Domino Directory zu finden (Bild 1).
Zusammenarbeit mit externen Entwicklern
Wenn man Anwendungen von externen Entwicklern erstellen lässt, muss man mit diesen das Sicherheitskonzept genau abstimmen. Wichtig ist, dass man einerseits die oben genannten Grundregeln vorgibt und andererseits die erforderlichen Rollen für eine Anwendung gemeinsam festlegt, um einerseits mit ausreichend differenzierten Zugriffsberechtigungen arbeiten zu können, andererseits aber auch eine überschaubare Zahl von zu konfigurierenden Rollen zu haben. Letztlich geht es auch hier darum, einen
vernünftigen Kompromiss zwischen dem Wunsch nach einer differenzierten Sicherheitsadministration und einem überschaubaren Aufwand zu finden.
Klare Vorgaben für den externen Entwick sind für die Umsetzung sicherer Anwendungen auf jeden Fall wichtig. Die Grundregeln wie beispielsweise die konsequente Nutzung von Rollen gehören auch ins Pflichtenheft. Sonst hat man, vor allem bei der Zusammenarbeit mit unterschiedlichen Entwicklern, nach einiger Zeit etliche Anwendungen mit unterschiedlichen Sicherheitsmodellen, die nicht miteinander harmonieren.
Konkrete Umsetzung bei der Administration
Die Umsetzung der Sicherheitsmodelle erfolgt auf mehreren Ebenen. Wie oben bereits erwähnt, müssen Administratoren einerseits Gruppenkonzepte definieren, um für die wichtigsten Anforderungen mit standardisierten Gruppen arbeiten zu können. Wenn man ein gut definiertes Gruppenmodell hat, das sowohl aufbau- als auch ablauforganisatorische Aspekte einbezieht, wird man nur noch selten für Anwendungen zusätzliche Gruppen definieren müssen. Spezifische administrative Aufgaben auf Anwendungsebene übernehmen in solchen Fällen entweder Vorgesetzte oder IT-Verantwortliche in den Fachbereichen, die man generell definieren kann.
Außerdem müssen die Administratoren die ACLs korrekt setzen, also das Zugriffsniveau, spezielle Berechtigungen und die Rollenzuordnung vornehmen.
Konkrete Umsetzung beim Design
Rollen können auch von einem Agent bei der Einrichtung der Anwendung automatisch angeleg werden. Es bietet sich an, eine Maske für die Konfiguration zu erstellen, mit der Benutzer zu Rollen zugeordnet oder wieder aus diesen entfernt werden. Dazu muss ein entsprechender Agent programmiert werden, der diese Zuordnungen übernimmt. Ein solches Dokument macht wiederum ein Rollenmodell zwingend erforderlich, damit die Administration der Rollen nur von ausgewählten Benutzern durchgeführt werden kann.
Innerhalb der Anwendungen spielen die Festlegungen einerseits in den Leser- und Autorenfeldern und andererseits für die Sicherheit beispielsweise von Masken eine wichtige Rolle (Bild 2). Mit Letzteren kann eingeschränkt werden, wer in einer Anwendung Dokumente, die auf Basis einer Maske erstellt wurden, lesen darf und wer Dokumente mit einer bestimmten Maske erstellen darf. Damit werden die standardmäßigen Berechtigungen eingeschränkt, die mit der ACL definiert wurden. In diesen Listen sollten nur Gruppen und Rollen ausgewählt werden.
Leser- und Autorenfelder
Die Leser- und Autorenfelder können eingesetzt werden, um beispielsweise die Zugriffe auf unterschiedliche Dokumente zu steuern, die auf Basis der gleichen Maske erstellt wurden. Sie lassen sich aber auch nutzen, um zusätzlichen Benutzern die Berechtigung zum Ändern von Dokumenten zu geben oder Benutzern die Berechtigung zum Ändern zu entziehen. Dabei gilt, dass Benutzer, die im Autorenfeld aufgeführt sind, Änderungen an Dokumenten vornehmen dürfen. Standardmäßig sind das diejenigen, die ein Dokument erstellen – soweit mit solchen Feldern gearbeitet wird. Um davon abzuweichen, muss man das Feld mit einer Formel berechnen lassen. Diese Formel sollte wiederum Bezug auf Standard-benutzergruppen oder auf Rollen nehmen, denen die Berechtigungen zugeordnet werden – soweit man nicht mit dem Standardmodell arbeiten möchte, bei dem nur der Ersteller die von ihm erzeugten Dokumente auch bearbeiten darf.
Die Erfahrungen mit Leser- und Autorenfeldern zeigen aber, dass hier auch Probleme auftauchen können, vor allem wenn nur der Ersteller später auch Zugriffsrechte für ein Dokument hat. Daher sollte man mit diesen Mechanismen sehr vorsichtig sein. Immerhin gibt es mit den Full Access-Administratoren Benutzer, die auch unter Umgehung der Einstellungen in Leserfeldern auf Dokumente zugreifen können. Solangeman in solchen Feldern aber mit Standardgruppen und Rollen arbeitet, bleibt man vor solchen Probleme verschont.
Generell gilt, dass alle spezifischen Anpassungen wie insbesondere die Nutzung von Leserund Autorenfeldern und spezielle Einstellungen im Register Sicherheit von Masken und Ansichten genau dokumentiert werden sollten.
Nachvollziehbarkeit
Ein weiteres wichtiges Thema ist die Nachvollziehbarkeit dessen, was in Anwendungen geschieht. Ein probates Mittel dafür ist die Verwendung von Antwortdokumenten, womit frühere Versionen eines Dokuments erhalten und Änderungen nachvollziehbar bleiben.
Darüber hinaus bietet sich vor allem die Verwendung von Agents an, die zusätzliche Informationen über das, was gemacht wurde, in Logdateien schreiben. Es empfiehlt sich, für die Logdateien Notes-Datenbanken zu verwenden. Damit lassen sich auch spezielle Anforderungen an die Protokollierung erfüllen, beispielsweise durch umfassende Aufzeichnung der Änderungen, die von bestimmten Benutzern durchgeführt wurden. Der Aufwand dafür ist durchaus überschaubar, kann aber helfen, auf die immer häufigeren Fragen von Revisoren gute Antworten zu haben.