Back to top

Was Sie schon immer über Sicherheit bei Suchmaschinen wissen wollten

(aber bisher nicht zu fragen wagten) 

Sicherheit bei Suchmaschinen ist einer der am wenigsten verstandenen Aspekte von Suchtechnologien. Es gibt zahlreiche Texte über Relevanz und Skalierbarkeit, aber so gut wie keine Artikel über die Sicherheitsarchitektur von Suchmaschinen. Das ist traurig, denn auch hier gibt es eindeutig einen richtigen und einen verkehrten Weg. Nicht selten müssen Anbieter von Suchmaschinen und Contentquellen erst eine Reihe schlechter Ideen ausprobieren, ehe sie schließlich die richtige Lösung finden. 

Dieser Blog ist Teil unserer "Graduate Level Courses" zu Suchmaschinenarchitektur (in Teil 1 haben wir das Relevancy Ranking behandelt). Im Folgenden werden wir technische Details zu Sicherheitsarchitektur, Methoden und Abwägungen besprechen.

Und los geht's! 

 

Das Ziel: Keine Kompromisse

Um das von Vornherein klar zu stellen, unser Ziel wird sein, eine gesicherte Suchmaschine zu erstellen, die sich in jeder Hinsicht wie eine Suchmaschine ohne Sicherheitsvorkehrungen verhält. Der einzige Unterschied wird sein, dass der Benutzer nur eine Teilmenge der verfügbaren Dokumente sieht – diejenigen, auf die er Lesezugriff hat. 

Dies ist wichtig, weil die meisten Suchmaschinen bei Abfragen mit Document-Level-Security Einschränkungen, Abkürzungen und Ungenauigkeiten aufweisen.  

Unser "kompromissloser" Ansatz wird insbesondere die folgenden Anforderungen haben:

  • Nur Dokumente, die der Benutzer lesen darf, werden in den Suchergebnissen angezeigt
    • Es reicht nicht, einfach nur die Metadaten auszublocken. Wenn der Benutzer keinen Lesezugriff auf das Dokument hat, darf es gar nicht in den Suchergebnissen erscheinen
  • Die Gesamtzahl der Dokumente, die von der Abfrage gefunden wurden, muss angezeigt werden
    • Hierbei muss es sich um die exakte Zahl handeln, keine Schätzung
    • Diese Zahl darf nur die Dokumente enthalten, auf die der Benutzer Lesezugriff hat
  • Alle Facetten müssen angezeigt werden
    • Auch diese Zahl muss exakt sein, keine Schätzung
    • Diese Zahl darf nur die Dokumente enthalten, auf die der Benutzer Lesezugriff hat. (Anmerkung: "Facetten" sind hier dasselbe wie "Navigatoren")
  • Leistung: Die Suche muss schnell erfolgen
    • Die Geschwindigkeit darf maximal 10% langsamer sein als in einer ungesicherten Umgebung
  • Stabilität: Die Suche muss auch funktionieren, wenn die eigentlichen Contentserver nicht verfügbar sind
    • So muss es z.B. noch möglich sein, nach Dokumenten in Contentquelle X zu suchen, wenn der dazugehörige Server X gerade zu Wartungszwecken heruntergefahren wurde

 

Das Problem: Viele Sicherheitsmodelle 

Das Problem mit sicheren Dokumentsuchen ist, dass es sich hierbei um ein "weites Problem" handelt (siehe unseren Blog zu Types of Hard). Anders ausgedrückt, da es viele verschiedene Contentquellen gibt, gibt es auch viele Zugriffsmethoden und Sicherheitsmodelle. (Dies mag einer der Hauptgründe sein, warum Suchmaschinen so große Sicherheitsprobleme aufweisen – es gibt einfach zu viele Sonderfälle.) 

Werfen wir also zuerst einen Blick auf einige Sicherheitsmodelle für Contentquellen, um einen Eindruck des Umfangs unseres Problems zu bekommen. 

 

Access Control Lists 

Die meisten Contentquellen basieren auf Zugriffssteuerungslisten (Access Control Lists, ACLs). Für Suchzwecke gesehen handelt es sich hierbei um Listen von Benutzern und Gruppen, die Lesezugriff auf ein Dokument haben. 

Anmerkung: Für uns sind nur die LESE-Berechtigungen von Bedeutung. Die sonstigen Zugriffsberechtigungen (schreiben, löschen, ändern usw.) sind für die Suche irrelevant. 

Rollen 

In der Praxis sind Rollen ein Zwischenschritt, der bestimmt, ob ein Benutzer oder eine Gruppe Lesezugriff auf ein Dokument hat. So kann beispielsweise die Gruppe "Accounting" der Rolle "Reviewer" zugeordnet sein, welche beispielsweise Lesezugriff auf alle Dokumente in einer Datenbank hat. 

Gruppenmitgliedschaft

Ein Benutzer kann Mitglied in mehreren benannten Gruppen sein. Wenn einer Gruppe Zugriff auf ein Dokument gestattet wird, erhalten alle Mitglieder dieser Gruppe automatisch diese Zugriffsberechtigung. Von allen Aspekten der Sicherheit ist die Gruppenmitgliedschaft der dynamischste. Ständig werden Mitarbeiter entlassen oder neue Mitarbeiter eingestellt. Daher ändert sich die Gruppenmitgliedschaft ständig. 

Außerdem gibt es keine datenbankübergreifende Konsistenz der Gruppen. Die meisten Contentsysteme pflegen ihre eigenen Gruppen. Das bedeutet, dass eine Person auf einem SharePoint-System zur Gruppe "SharePoint:Developers" und gleichzeitig auf einem Documentum-System zur Gruppe "Documentum:Developers" gehören kann. 

 

Verweigern 

Individuen und Gruppen können nicht nur Zugriff auf Dokumente erhalten, der Zugriff kann ihnen auch ausdrücklich verweigert werden. Das Verweigern hat in der Regel Vorrang vor dem Zulassen des Zugriffs. Anders ausgedrückt, wenn derselbe Benutzer für ein Dokument sowohl für Zulassen als auch Verweigern eingetragen ist, wird dem Benutzer der Zugriff verweigert. 

Dasselbe trifft zu, wenn der Benutzer zwar für Zugriff Zulassen eingetragen ist, eine seiner Gruppen aber für Verweigern eingetragen ist. In dem Fall wird dem Benutzer weiterhin der Zugriff verweigert (daher wird Verweigern seltener verwendet).

 

Hierarchische Sicherheit (Ordner) 

Viele Systeme ordnen ihre Dokumente in einer hierarchischen Struktur (Ordner, Verzeichnisse, Spaces, Datenbanken, Kabinette usw.). Meist wird die Sicherheit dann auch hierarchisch gehandhabt. So muss der Benutzer beispielsweise Zugriff auf den übergeordneten Container haben (wie die Datenbank oder den Space), damit er diesen nach Dokumenten durchsuchen kann (er muss natürlich auch Zugriff auf die jeweiligen Dokumente haben). 

Hierarchische Sicherheit bedeutet, dass der Zugriff nicht mehr durch eine einzelne Liste der Benutzer und Gruppen definiert wird. Wenn beispielsweise die Gruppe "Developers" Zugriff auf Datenbank X hat, und die Gruppe "Virginia Employees" Zugriff auf Dokument X.Y (Dokument Y in Datenbank X) erhält, dann haben nur Mitglieder der Gruppe "Developers", die auch in der Gruppe "Virginia Employees" sind, Zugriff auf Dokument X.Y. Anders ausgedrückt, nur die Quersumme der Benutzer der Gruppen "Developers" und "Virginia Employees" haben Lesezugriff auf Dokument X.Y. 

 

Sonstige Eigenarten 

Über die Jahre sind uns eine Vielzahl weiterer Eigenarten der Sicherheitsfunktionen begegnet:

  • Kennzeichnung "Public": Einige Systeme verwenden eine besondere Markierung, um öffentlich zugängliche Dokumente zu kennzeichnen
  • Erforderliche Gruppen: Damit sind Gruppen gemeint, in denen der Benutzer Mitglied sein muss, um ein Dokument lesen zu dürfen. Erforderliche Gruppen haben die gleiche Wirkung wie hierarchische ACLs (siehe oben), werden aber im Dokument selbst definiert
  • Besitzer: Viele Systeme vermerken den Besitzer eines Dokuments, der immer Zugriff auf das Dokument hat. Diese Angabe hat Vorrang vor allen anderen Einschränkungen.

 

Im nächsten Abschnitt werden wir die Methoden Early Binding und Late Binding vergleichen.

0