Aber so arbeitet Notes nun einmal.
Am Besten du liest dir das hier einmal durch:
Handling von Leser und Autorenfeldern, wann ziehen sie, wann nicht
Die 10 Regeln die Leser und Autoren Felder betreffen
Regel #1 - Die ACL hat immer das letzte Wort
Die Zugriffskontroll Liste (Access Control List (ACL)) bestimmt immer welche Art eines Zugriffes jemand auf eine Datenbank hat. Alle folgenden Regeln greifen
zu guter Letzt auf diese Regel zurück. Wenn jemand in einer Datenbank nur "Einlieferer" Rechte hat, dann kann er keine Dokumente lesen, egal was sonst noch
eingestellt wird. Diesen Benutzer in ein Leser oder Autoren Feld einzutragen wird keine Auswirkungen haben.
Regel #2 - Autoren Felder können keine Rechte verleihen die vorher nicht existierten
Ein Autoren Feld kann den Zugang zu einem Dokument nicht einschränken. Wenn ein Benutzer Editorenrechte (oder höhere Rechte) in der Datenbank hat, dann hat
ein Autoren Feld keine Auswirkungen für diesen Benutzer, was wieder auf Regel #1 zurückzuführen ist. Genau das gleiche gilt, wenn ein Benutzer nur Leser oder
ein noch niedrigeres Zugriffsrecht hat. Dann hat ein Autoren Feld wieder keinen Einfluß, weil die ACL sagt, das das einzige was dieser Benutzer tun kann
lesen ist. Als ganzes bedeutet das, das ein Autoren Feld nur dann anwendbar ist, wenn der fragliche Benutzer Autoren Rechte in der Datenbank hat.
Regel #3 - Leser Felder begrenzen den Zugriff
Ein Leser Feld begrenzt den Zugang immer und es hängt überhaupt nicht von den Zugriffsrechten des Benutzers ab. Wenn man ein Leser Feld in ein Dokument
einbaut und es mit einem Wert gefüllt ist, z.B. nur mit Ihrem Namen, dann haben sie und nur sie die Möglichkeit dieses Dokument zu sehen, vollkommen egal
welche Rechte der andere hat.
Regel #4 - Leser und Autoren Felder müssen immer den vollständigen qualifizierten Benutzernamen enthalten
Wenn sie Benutzer Namen in Leser oder Autoren Felder eintragen, müssen diese immer den qualifizierten Namen enthalten. Das bedeutet, das das "CN=" und alle
anderen Bestandteile wie UO ... im Benutzer Namen sichtbar sein müssen. Wenn das nicht der Fall ist, dann wird der Name nicht zu dem entsprechenden Benutzer
passen und der Benutzer wird keinen Zugang erhalten.
Regel #5 - Rollen können in Leser und Autoren Feldern benutzt werden
Um eine Rolle in diesen beiden Feldtypen verwenden zu können, muß der Name der Rolle in eckige Klammern gesetzt werden. So kann man zum Beispiel indem man
"[administrator]" in ein Leser Feld einträgt verhindern, das irgendwer der nicht diese in der ACL eingetragene Rolle hat dieses Dokument lesen kann.
Regel #6 - Wenn ein Leser Feld leer ist, dann kann jeder das Dokument lesen
Nur weil ein Leser Feld in einem Dokument existiert, heißt das noch lange nicht, das jedes einzelne Dokument das diese Maske benutzt Lese Sicherheit
eingebaut hat. Da Leser Felder den Zugang begrenzen, bedeutet ein leerer Wert, das der "Zugriff für niemand verboten" ist. Oder anders ausgedrückt. "jeder
darf zugreifen".
Regel #7 - Wenn ein Autoren Feld leer ist, dann kann niemand mit Autoren Rechten in der Datenbank dieses Dokument bearbeiten.
Da Autoren Felder den Zugriff auf ein Dokument garantieren, bedeutet ein leerer Wert, "hier bekommt keiner Zugriff" oder "niemand der Autoren Rechte hat darf
hier ändern". Benutzer mit Editoren oder höheren Rechten sind dann aber immer noch in der Lage diese Dokumente zu bearbeiten. Siehe Regel #1.
Regel #8 - Wenn es mehrere Sicherheits Felder (entweder Leser oder Autor) in einem Dokument gibt, dann wird im Hintergrund aus allen Werten in allen
Feldern ein "virtuelles" Sicherheits Feld gebildet, das für die Zugriffskontrolle genutzt wird.
Das muß man jetzt etwas ausführlicher erklären. Wenn man z.B. zwei Leser Felder in seiner Maske hat, von denen eines den Wert "[Administrator]" und das
andere den Wert "CN=Amadeus Tester/O=Testfirma" hat, dann ergeben diese beiden Felder zusammen, das alle die für diese Datenbank die Rolle "[Administrator]"
haben und außerdem der Benutzer Amadeus Tester dieses Dokument in einer Ansicht sehen können.
Um dieses Beispiel weiterzuentwickeln fügen wir man jetzt ein weiteres Leser Feld in das Dokument ein, lassen dieses Feld aber leer. Normalerweise bedeutet
ein leeres Leser Feld, das jeder das Dokument lesen kann, nur das in diesem Fall noch andere Leser Felder in dem Dokument sind, so das nicht ausschließlich
dieses neue Feld zur Kontrolle benutzt wird. Was jetzt passiert ist, das alle drei Leser Felder kombiniert werden um den Zugriff auf dieses Dokument zu
regeln. Wenn alle drei Felder ein "NULL" Wert (kein Eintrag) ergeben, dann kann jeder das Dokument lesen. Da die anderen beiden Felder aber nicht leer sind,
ändert das hinzufügen des dritten Feldes ohne Eintrag nichts an den Zugriffsrechten. Das Dokument kann immer noch nur von unserem Benutzer Amadeus Tester,
bzw. von allen denen die Rolle "[Administrator]" in der Datenbank zugewiesen wurde gelesen werden.
Bei Autoren Felder ist es der gleiche Vorgang. Mehrere Autoren Felder verbinden sich zu einem übergeordneten "virtuellen" Autoren Feld. Wenn jemand (mit
Autoren Rechten in der ACL, um noch einmal kurz auf Regel #1 hinzuweisen) in mindestens einem dieser Felder eingetragen ist, dann ist er in der Lage dieses
Dokument zu verändern. Es spielt auch hier keine Rolle ob ein Autoren Feld leer ist, während die anderen gefüllt sind.
Regel #9 - Wenn es sowohl Leser als auch Autoren Felder in einem Dokument gibt, dann sind die Autoren Felder auch Leser Felder
Diese Regel scheint auf den ersten Blick keinen Sinn zu machen. Also brauchen wir ein Beispiel. Nehmen wir an, daß dieses Dokument ein Leser Feld hat in das
die "[Administrator]" Rolle eingetragen ist. Außerdem hat das Dokument ein Autoren Feld mit "CN=Amadeus Tester/O=Testfirma". Weil Amadeus Tester im Autoren
Feld eingetragen ist, wird er automatisch auch in der Lage sein das Dokument in den entsprechenden Ansichten zu sehen. Er muß also nicht zusätzlich noch im
Leserfeld eingetragen werden. Das geht auf Regel #2 zurück. Das Leser Feld hat den Zugriff gelöscht, Das Autoren Feld ihn aber wieder garantiert.
Was ich zeigen will ist ,das hier Autoren Felder einen Unterschied für Benutzer machen können, deren Zugriffsrechte mindestens Editor oder höher sind. Wenn
Amadeus Tester der Entwickler dieser Datenbank ist, dann kommt das Autoren Feld ins Spiel und erlaubt es ihm die Dokumente in Ansichten zu sehen, obwohl er
eigentlich kein Leser ist.
Regel #10 - Leser Felder werden während der Replikation angewandt
Diese Funktionalität wird häufig übersehen. Dabei ist sie wirklich wichtig. Nehmen wir einmal an wir haben eine Datenbank mit zehn Dokumenten. Sie sind nur
in zwei dieser Dokumente eingetragen. Sie können nur diese zwei Datenbanken sehen aber wenn sie in die Eigenschaften der Datenbank gehen, dann sehen sie das
es zehn Dokumente gibt. Sie können auf dem Server keine Ansicht erstellen, aber sie wollen alle Dokumente sehen. Also erstellen sie eine lokalen Replik der
Datenbank, bauen dort die Ansicht ein die alle Dokumente zeigen soll und öffnen die Ansicht. Sie können aber immer noch nur diese beiden Dokumente sehen. Das
passiert nicht, weil die Leser Felder auf ihre Lokale Replik angewendet werden. Sie sehen tatsächlich alles. Wenn sie auf die Datenbank Eigenschaften der
Lokalen Replik gehen werden sie feststellen, das sie tatsächlich nur zwei Dokumente in dieser Datenbank haben. Domino/Notes läßt es nicht zu, das sie
Dokumente zu denen sie keinen Zugriff haben lokal replizieren.
In einer ähnlichen Art, kann man z.B. eine manuelle Replikation zwischen zwei Servern starten. Wenn es Dokumente gibt die sich geändert haben, oder Sie sehen
die Änderungen nicht, dann wurden diese Änderungen zwischen den beiden Servern nicht repliziert. Eine Sache die viele Entwickler vergessen, ist, das in eine
Datenbank immer eine Rolle mit eingebaut werden sollte die in ein Leser Feld eingetragen wird um "LocalDomainServers" das Recht zu geben Dokumente zu
replizieren.
Verschiedene Beobachtungen und Tipps
1. Geben Sie sich selbst Zugriff
Wenn Sie eine Anwendung entwickeln bei der sie Leser und/oder Autoren Felder benutzen werden, dann gibt es einige Dinge die sie beachten sollten.
Jedes einzelne Dokument, das ein Leser Feld hat das nicht leer ist, sollte automatisch auch ein zusätzliches Leserfeld enthalten in dem eine definierte Rolle
z.B. "[Administrator]" eingetragen wird. Wenn alle vorhandenen Leser Felder leer sind, dann kann jeder das Dokument sehen. Aber wenn eines der Leserfelder
gefüllt ist, dann können nur noch die Benutzer, die in diesen Feldern eingetragen wurden diese Dokumente sehen. Es ist schon häufiger passiert das ein
Entwickler nachträglich an einem Dokument in einer Datenbank arbeiten wollte weil lein Benutzer irgendwelche Fragen oder Probleme hatte. Er konnte das aber
nicht, weil er keinen Zugriff auf die entsprechenden Dokumente hatte. Deswegen konnte er nichts tun um Unterstützung für dieses Dokument zu leisten. Oder es
gibt in einer Datenbank ein Leserfeld in dem exakt ein Benutzer eingetragen ist und dieser Benutzer verläßt das Unternehmen. Das sind schwerwiegende Gründe
warum man immer ein "Administrator" Leser Feld mit einer entsprechenden Rolle mit einbauen sollte.
Normalerweise macht man das auf die folgende Art und Weise:
Man erstellt ein verstecktes "AdminReaders" Feld ganz am Ende der Maske. Das Feld ist vom Typ Leser und Berechnet. In der Berechnung des Feldes wird geprüft,
ob die Zusammenfassung aller anderen Leser Felder einen Wert enthält oder nicht. Wenn ein Wert eingetragen ist, dann wird die Rolle eingetragen. Zum
Beispiel:
@If(@Elements(Readers1 : Readers2 : Readers3) != 0; "[Admin]"; "")
Sie werden sich fragen, was für den Fall passieren soll, das die Anwendung "wirklich" vertraulich ist, und wenn die Eigentümer der Anwendung noch nicht
einmal den Support in die Dokumente schauen lassen wollen. In diesem Fall wird das AdminReaders Feld immer noch eingebaut. Nur die zum Zugriff benötigte
Rolle wird nicht in der ACL eingetragen. Auf diese Weise sieht der Entwickler der die Anwendung pflegt die Dokumente nicht. In der Bedienungs Anleitung der
Datenbank wird die Rolle aber genannt. Auf diese Art kann der Entwickler wenn er Zugriff benötigt (und glauben sie mir das ist keine Frage des ob sondern des
wann) zum Datenbank Verantwortlichen gehen und ihm sagen, das er diese Rolle in die Datenbank eintragen und ihm den entsprechenden Zugriff geben soll. Nach
Beendigung der Pflegearbeiten kann dem Entwickler die Rolle wieder entzogen werden. Wichtig ist, das diese "Hintertür" aber immer da ist wenn sie denn einmal
gebraucht wird.
Wenn man für die Öffentliche Hand oder eine Firma arbeitet, dann kann der obige Absatz einen dazu bringen sich wie ein Wurm zu krümmen, weil man
"Hintertürchen" in einer Anwendung nicht sehen will. Aber wenn der Entwickler der die Anwendung unterstützt keine Manager Rechte auf der Datenbank hat, dann
muß er erst zu dem jeweils Verantwortlichen gehen um diesen Zugriff zu erhalten.
2. Server Zugriff gestatten
Wenn die Datenbank zwischen unterschiedlichen Servern repliziert werden soll, dann sollte ein anderes zusätzliches Leser Feld eingebaut werden das eine
"[Replikator]" Rolle enthält (wenn notwendig). Hier muß man sicherstellen, das "LocalDomainServers" diese Rolle haben. Dieser Eintrag erlaubt es den Servern
alle Dokumente zu sehen und zu replizieren.
3. Leser Felder und Ansichten
Diese Eigenschaft von Leser Feldern wird von Entwicklern häufig übersehen und sie kann die Datenbank erheblich verlangsamen. Um das Problem zu verstehen
braucht man ein wenig Hintergrundwissen über die Art wie der Notes Client mit dem Domino Server zusammenarbeitet. Was jetzt kommt ist ein extrem
vereinfachtes Beispiel:
Wenn eine Ansicht geöffnet wird dann sagt der Client zum Server, Ok Junge gibt doch bitte mal den ersten Teil des Ansichts Indexes. Der ganze Index kann
ziemlich groß sein, so das zunächst einmal nur ein Brocken des Indexes gesendet wird um die Geschwindigkeit zu erhöhen. Das kann man sehen und nachvollziehen
wenn man eine große Ansicht öffnet, das oberste Dokument markiert und dann mit der Pfeil-unten Taste nach unten scrollt. Irgendwann wird es eine Pause geben.
Das ist der Zeitpunkt an dem der Server den nächsten Teil des Indexes zum Client schickt.
Jetzt hat der Server den ersten Teil des Ansichtsindex gesendet. Der Client sucht sich jetzt die Dokumente die er anzeigen darf und zeigt diese. Wenn das was
er anzeigen darf nicht genug ist um auf den Bildschirm zu passen, dann fordert der Client den Server auf den nächsten Teil des Index zu schicken. Wieder
sucht sich der Client die Dokumente die er darstellen kann. Dieser Ablauf wiederholt sich bis der Bildschirm komplett aufgefüllt worden ist.
Jetzt stellen sie sich eine Ansicht mit 100.000 Dokumenten vor die alle Leser Felder haben und von denen sich nur einen verschwindend geringen Bruchteil,
sagen wir 5 Stück lesen dürfen. Der Client und der Server müssen den gesamten Index bis zum Ende durchgehen nur um herauszufinden das es trotzdem nicht genug
Dokumente sind um den Bildschirm zu füllen. Erst dann werden sie auf dem Bildschirm angezeigt. Das macht die Ansicht wirklich langsam.
Um dieser Falle aus dem Weg zu gehen sollten Sie es vermeiden Ansichten zu benutzen bei denen der Benutzer eine so geringe Anzahl von Dokumenten sehen wird
wenn es irgendwie möglich ist. Manchmal mag das aufgrund der Anforderung an die Anwendung unmöglich sein. dann sollten Sie zumindest darauf hinweisen, damit
sie später, wenn sich die Anwender über die mangelnde Performance beschweren "ich hab es euch ja gesagt" sagen können.
4. ein letzter Trick
Wenn man die Regel #9 benutzt (Autoren Felder sind auch Leser Felder) kann das sehr nützlich sein. Nehmen wir einmal an das sie eine Anwendung entwickelt
haben bei der die Leute Dokumente erstellen können, aber nur die Dokumente sehen sollen die sie auch erstellt haben. Das kann man sehr einfach erreichen
indem jeder Autoren Zugriff in der ACL auf die Datenbank bekommt. Die Benutzer die die entsprechenden Dokumente bearbeiten sollen werden in die
entsprechenden Autoren Felder eingetragen. Anschließend wird ein Leser Feld erstellt, das einen Wert enthält der keinen Benutzernamen darstellt. Weil das
Leser Feld nicht leer ist, ist das Dokument nicht für jeden zu sehen, Es ist auf die Personen beschränkt, die in dem Leser Feld eingetragen sind (erinnern
sie sich, hier steht kein echter Name). Aber es ist jetzt auch für alle Benutzer sichtbar, deren Namen in den Autoren Feldern stehen. Und da die Benutzer nur
Autoren Rechte in der Datenbank haben können Sie, auch dann wenn sie durch irgendeinen dummen Zufall auch andere Dokumente sehen würden, diese Dokumente
nicht ändern, weil sie in deren Autoren Feld nicht eingetragen sind.
Zusammenfassung
Das Sicherheits Modell von Notes ist eines der besten in der IT und es ist extrem verläßlich und sicher. Wenn, bezogen auf die eingebaute Sicherheit von
Leser und Autorenfeldern, die oben genannten Regeln angewendet werden wenn man eine Datenbank erstellt, sollte das helfen sichere Datenbanken zu
entwickeln
