Back to top

Gruppenerweiterung und Abfragemodifikation

Von Paul Nelson, leitender Architekt bei Search Technologies

 

Dieser Artikel ist Teil unserer Reihe der "Graduate Level Courses" zur Implementierung von Document-Level-Security in Systemen der Unternehmenssuche. Wenn Sie am Anfang anfangen wollen, geht es hier zum ersten Artikel unserer Reihe: Sicherheit bei Suchmaschinen.

 

Filtern von Abfragen

Bei Document-Level-Security mit Early Binding muss jede ausgeführte Abfrage modifiziert werden, sodass die Suchmaschine nur Dokumente ausgibt, auf die der Benutzer Lesezugriff hat. Hierzu wird eine Abfrage erstellt, die in etwa wie folgt aussieht: 

 

(Ursprüngliche Abfrage des Benutzers<user’s>) AND 

    (isPublic:true OR 

         ( parentACLs: ( PUBLIC:ALL OR user OR group1 OR group2 . . . ) AND 

           allowACLs: ( PUBLIC:ALL OR user OR group1 OR group2 . . . ) AND NOT 

           denyACLs:( user OR group1 OR group2 . . . ) 

         ) 

     ) 

Um diese Abfrage zu implementieren muss aus allen Contentquellen eine Liste aller Gruppen gesammelt werden, in denen der Benutzer Mitglied ist (Klicken Sie auf das untenstehende Diagramm, um die Grafik in höherer Auflösung zu sehen). 

 

Hierzu muss eine Verbindung zu jeder Contentquelle hergestellt werden, um alle Gruppen abzurufen, in denen der Benutzer Mitglied ist. Dies ist notwendig, weil die mit dem Dokument indexierten ACLs Gruppennamen enthalten. Wenn ein Benutzer Mitglied einer Gruppe ist, die in einer ACL vermerkt ist, muss diese Gruppe in dem OR-Ausdruck (siehe oben) enthalten sein, wenn der Sicherheitsfilter erstellt wird. 

 

Warum nicht Gruppen erweitern während Dokumente indexiert werden? 

Wenn ein Dokument mit allen Mitgliedern der Gruppe indexiert wird (und nicht nur mit dem Namen der Gruppe), wäre die Suche schneller. Beim Ausführen der Abfrage müssten nicht mehr die Gruppenmitgliedschaften des Benutzers überprüft werden. 

Bei der Gruppenerweiterung während dem Indexieren muss das Dokument dann jedoch erneut indexiert werden, wenn sich Gruppenmitgliedschaften ändern. In großen Unternehmen ändert sich die Gruppenmitgliedschaft oft mehrmals täglich, wenn Mitarbeiter eingestellt oder entlassen oder anderen Projekten zugeteilt werden. Wenn die Gruppen jetzt während dem Indexieren erweitert würden, müsste die gesamte Datenbank ständig neu indexiert werden. 

Daher ist es ein guter Kompromiss zwischen Abfrageleistung (und Komplexität) und Indexleistung, die Gruppenmitgliedschaft des jeweiligen Benutzers während der Abfrage zu bestimmen. 

Das Hinzufügen weiterer Begriffe mit Gruppenbezug verlangsamt die Abfragen zwar, aber da diese einfache boolesche Abfragen sind und größtenteils aus OR-Begriffen bestehen, kann die Ausführung des Filterausdrucks sehr effizient gestaltet werden. Weiterhin ändert sich der Dokumentindex nur, wenn sich die ACL selbst ändert (nicht, wenn sich Gruppenmitgliedschaften ändern), sodass Updates des Index minimal gehalten werden. 

 

Gruppencache

Um schnell die Gruppenmitgliedschaften eines Benutzers berechnen zu können, sobald eine Abfrage eingereicht wird, muss ein Cache der Gruppenmitgliedschaften angelegt werden. Es gibt zwei Arten Cache:

Cache, der aufgebaut wird, während die Abfrage ausgeführt wird

  • Dies bedeutet meist, dass die erste Abfrage recht langsam beantwortet wird, da alle Gruppenmitgliedschaften (für den Benutzer wie auch seine verschachtelten Gruppen) berechnet werden müssen
  • Dieses Problem kann durch Cache Warming reduziert werden

Cache, der beim Systemstart vorgebaut wird

Hierbei werden alle Gruppenmitgliedschaften für alle Gruppen im Vorhinein heruntergeladen. Diese Methode hat einige Vorteile:

  • Die Gruppenerweiterung kann schnell erfolgen (einfaches Nachschlagen in der vorbereiteten Datenbank)
  • Die Gruppenerweiterung stellt keine zusätzliche Last für den Server der Contentquelle dar
  • Die Gruppenerweiterung kann auch vorgenommen werden, wenn die Contentserver offline sind

Allgemein gesprochen ist die zweite Methode die Bevorzugte. Allerdings dauert es bei dieser Methode länger, wenn eine Gruppenmitgliedschaft aufgehoben wird, bis der betroffene Benutzer auch wirklich seinen Zugriff auf die jeweiligen damit verbundenen Dokumente gesperrt bekommt.

Normalerweise werden Gruppencaches regelmäßig im Hintergrund aktualisiert. Die Frequenz, mit der sie aktualisiert werden, hängt ab von: Der Belastung, die das Update für die Infrastruktur der Contentquelle darstellt, der Frage, wie aktuell Gruppenmitgliedschaften sein müssen und den häufigsten Benutzern des Systems. Die meisten Systeme verfügen auch über eine Schaltfläche zum direkten Update, über welche in besonderen Situationen sofortige Updates vorgenommen werden können. 

 

Verschachtelte Gruppen

Wenn ein Benutzer Mitglied der Gruppe "Architects" ist, und diese Gruppe "Architects" wiederum Mitglied der Gruppe "Technical" ist, dann ist der Benutzer damit auch Mitglied der Gruppe "Technical". 

Die Methode zum Bestimmen von Gruppen in anderen Gruppen nennt man "Verschachtelte Gruppen". Ein rekursiver Algorithmus wird genutzt, um diese Gruppen zu erweitern und zu einer vollständigen Liste der Gruppenmitgliedschaften eines Benutzers zu führen. 

 

Mehrfache Benutzernamen 

Da die meisten Systeme heutzutage Benutzer über zentrales LDAP oder Windows Active Directory verwalten, ist das Problem mehrfach vorkommender Benutzernamen geringer als früher. 

Wenn jedoch ein altes Legacy-System mit eigener separater Benutzernamen-Datenbank verwendet wird (sowie auch möglicherweise einem separaten Authentifizierungsmechanismus), dann muss eine Verbindung zwischen dem Standard-Benutzernamen im Directory-Server und dem Benutzernamen im Legacy-System erstellt werden. 

Dies geschieht je nach Fall und kann bedeuten:

  • Manipulation der Zeichenfolge
    • Wenn die Namen einer bestimmten Form folgen (z.B. "vorname.nachname@servername.com"), kann die Verknüpfung der Namen über ein Skript als Teil der Pipeline für die Gruppenerweiterung implementiert werden
  • Besondere Benutzeroberfläche
    • Der Benutzer kann aufgefordert werden, seinen Benutzernamen und sein Passwort für das Legacy-System einzugeben. Wenn die Passwortabfrage erfolgreich war, wird eine Verknüpfung zwischen dem Benutzernamen im Legacy-System und dem Benutzernamen im Standard-Directory in einer Datenbank gespeichert
  • Jemand kann alle Benutzernamen manuell verbinden

Das Endergebnis ist eine Verknüpfung des Benutzernamens im Legacy-System mit dem Eintrag des Benutzers im Directory. Dies wird meist im Directory selbst gespeichert (d.h. im LDAP oder Active Directory) und für Gruppenerweiterungen verwendet, wenn der Benutzer eine Suche einreicht.

 

Besondere Fälle: Name Mangling bei Gruppennamen, Intersection ACLs, komplexe Sicherheitsmodelle

Benutzer- und Gruppennamen im Sicherheitsfilter der Suche müssen exakt zu den indexierten Entsprechungen in den ACL-Feldern passen. Daher müssen alle Änderungen an ACLs während dem Indexieren auch in der Gruppenerweiterung bei der Abfrage reflektiert sein. Das schließt ein:

  • Name Mangling bei Gruppennamen: Der Name oder die URL der Contentquelle muss jeder Gruppe hinzugefügt werden,damit diese über alle Gruppen aus allen Contentquellen einzigartig bleibt
  • Intersection ACLs: Wenn die Suchmaschine das Feld parentACLs nicht unterstützt, müssen (basierend auf der Gruppenmitgliedschaft des Benutzers) Intersection ACLs berechnet und dem Sicherheitsfilter hinzugefügt werden
  • ACL-Bezeichner: Wenn komplexe Sicherheitsmodelle durch Indexieren der ACL-IDs implementiert werden, muss der Benutzer gegen jede Sicherheitsbestimmung in jeder ACL-ID geprüft werden und die Prüf-ID muss dem Sicherheitsfilter hinzugefügt werden
  • ACL-Codierung: Wenn die Suchmaschine den Benutzer- und Gruppennamen über Base32 oder MD5 codiert hat, müssen diese Namen auch während der Gruppenerweiterung codiert werden, ehe sie dem Sicherheitsfilter hinzugefügt werden

 

Optimierung für Contentquellen 

Wenn eine Contentquelle denyACLs oder parentACLs nicht erfordert, kann der Sicherheitsfilter modifiziert werden, um effizienter zu arbeiten. 

Angenommen, Contentquelle "A" nutzt alle drei Arten der ACLs (allow, deny und parent), während Contentquelle "B" nur allowACLs verwendet. Der daraus resultierende Suchausdruck könnte wie folgt aussehen:

(Ursprüngliche Abfrage des Benutzers) AND 

    (isPublic:true OR 

         ( parentACLs:( PUBLIC:ALL OR user OR A:group1 OR A:group2 . . . ) AND

           allowACLs:( PUBLIC:ALL OR user OR A:group1 OR A:group2 . . . OR B:group1 OR                      B:group2 . . . ) AND NOT 

          denyACLs:( user OR A:group1 OR A:group2 . . . ) 

         ) 

Man sieht hier, wie die Gruppen für B nur im Feld allowACLs eingeschlossen sind. 

In der Praxis wird eine solche Optimierung die Leistung bei der Suche nicht groß verbessern. Token, die nie in eine spezielles Feld indexiert werden, werden schnell durch die Suchmaschine abgewiesen und automatisch aus dem Suchausdruck entfernt. 

Jedoch wird das Entfernen dieser Elemente aus dem Ausdruck die Gesamtgröße (Zeichenzahl) der Abfrage reduzieren. Das könnte von Bedeutung sein, wenn die Suchmaschine Maximalgrenzen für die gesamte Abfragegröße vorgibt. Wenn es sich um viele Gruppen handelt (Hunderte), könnte auch die Suchdauer reduziert werden. 

Um diese Optimierung vorzunehmen müssen die Contentquellen der Gruppenerweiterung berichten, ob sie parentACLs oder denyACLs verwenden. Die Gruppenerweiterung kann diese Information dann verwenden, um die optimierten Abfragefilter zu berechnen.

 

Das war's! 

Wenn Sie alle sechs Artikel zum Implementieren von Document-Level-Security durchgearbeitet und verstanden haben, haben Sie jetzt Ihren Abschluss als Spezialist für Sicherheit bei Suchmaschinen! 

Meiner Meinung nach stellt der in diesen Artikeln beschriebene Ansatz eine Referenz für die Sicherheit bei Suchmaschinen dar. Er bietet hohe Leistung und Stabilität, während gleichzeitig keine Kompromisse bei Sicherheit oder Suchfunktionalität eingegangen werden.

Als Abschluss für diese Reihe möchte ich noch einige Gedanken und Hoffnungen für die Zukunft teilen. Was wir brauchen, sind branchenweite Normen für die Sicherheit.

 

<< Dokument Acls Indexieren                                                      Branchenweite Normen >> 

 

--Paul

0