Back to top

Erfassen, Manipulieren und Indexieren von Dokument-ACLs

Von Paul Nelson, leitender Architekt bei Search Technologies

 

Dies ist der vierte Artikel unserer Reihe der "Graduate Level Courses" zu Document-Level-Security in Suchmaschinen. Die vorangehenden Artikel haben beschrieben:

 

Indexieren von Dokument-ACLs

Um die Document-Level-Security auf bestmögliche Art zu implementieren, muss jedes Dokument zusammen mit einer oder mehreren Access Control Lists indexiert werden:

 

ACLs sind Listen mit Benutzern und Gruppen, denen Zugriff auf das Dokument gestattet (oder verweigert) wurde. Diese Listen werden von Abfragefiltern verwendet, um sicherzustellen, dass die Suchergebnisse nur Dokumente enthalten, auf die der Benutzer Lesezugriff hat. 

Eine komplette Implementierung indexiert die folgenden Felder für die Suchmaschine:

  • allowACLs: Eine Liste der Benutzer und Gruppen, denen Zugriff auf das Dokument gestattet ist
  • denyACLs: Eine Liste der Benutzer und Gruppen, denen Zugriff auf das Dokument verweigert ist
    • Das Verweigern hat Priorität gegenüber ACLs, die Zugriff zulassen
  • parentACLs: Eine Liste der Benutzer und Gruppen, die Zugriff auf den primären Container haben, der das Dokument enthält
    • Nur Benutzer, die Zugriff sowohl auf den Container als auch das Dokument haben. dürfen das Dokument einsehen
  • isPublic
    • Dokumente, die mit der Kennzeichnung "isPublic" versehen sind, sind für alle Benutzer sichtbar
    • Dies hat Vorrang vor allen anderen ACLs

Das untenstehende Venn-Diagramm zeigt die Interaktion von Feldern der obenstehenden Access Control Lists.

Beim Indexieren von ACLs muss der Konnektor auch weitere Transformationen vornehmen, um sicherzustellen, dass alle Teile der Sicherheitsarchitektur harmonisch zusammenspielen. Diese zusätzlichen Transformationen werden in den folgenden Unterabschnitten beschrieben. 

 

Name Mangling bei Gruppennamen 

Die Gruppe "Developer" in einer SharePoint-Site wird sich von der Gruppe "Developer" in einem Jive-System unterscheiden. Daher müssen alle Gruppennamen mit dem Namen oder der URL der Contentquelle zusammengelegt werden, um jegliche Verwechselungen zu vermeiden.

Zum Beispiel: "SPSiteX:Developer" und "JiveSpaceY:Developer" wären die vollständigen Gruppennamen, die von der Suchmaschine indexiert würden. 

 

Vererbte ACLs abflachen 

Einige Quellen wie NTFS verwenden vererbte ACLs. In solchen Systemen werden die ACLs der übergeordneten Container (übergeordneter Ordner bei NTFS) automatisch auf Unterordner weitergereicht. Diese ACLs können durch ACLs in Unterordnern oder Unterdokumenten überschrieben werden.

Anders als die oben beschriebenen "parentACLs" (bei denen die ACL des übergeordneten Containers eine weitere Einschränkung für den Zugriff darstellt), werden vererbte ACLs einfach mit den expliziten ACLs des Dokuments kombiniert, um so eine vollständige Liste aller Benutzer und Gruppen zu liefern, die Zugriff auf das Dokument haben. 

Als Venn-Diagramm betrachtet stellen sich die Benutzer mit Zugriff auf ein Dokument wie folgt dar:

Die Handhabung von vererbten ACLs erfolgt durch den Konnektor, der alle vererbten ACLs im übergeordneten Ordner lesen muss (und diese wahrscheinlich in einem Cache ablegt, um die Leistung zu verbessern) und die vererbten ACLs dann mit den expliziten ACLs aller verschachtelten Dokumente im Ordner verbindet. 

Hierbei ist zu beachten, dass dafür nicht das oben beschriebene Feld "parentACLs" verwendet wird. Stattdessen werden alle vererbten ACLs einfach dem Feld "allowACLs" hinzugefügt. 

 

Inkrementelles Indexieren von Änderungen an ACLs 

Ein häufiges Problem bei vielen Contentquellen ist, dass Änderungen an der ACL eines Dokuments nicht als Änderung des Dokuments selbst zählen. Anders ausgedrückt wird das "Datum der letzten Änderung" des Dokuments nicht beeinflusst. Dieses Problem tritt auch häufig bei hierarchischen ACLs und vererbten ACLs auf. Es kommt nur selten vor, dass man eine Contentquelle antrifft, in der eine Änderung an einer höherstufigen ACL (übergeordneter Ordner, Datenbank, Space usw.) auch das Datum der letzten Änderung für das Dokument aktualisiert. 

Aus diesem Grund verwenden die meisten Konnektoren eine Snapshot-Methode, um inkrementelle Updates in der Datenbank zu erkennen. Wo Document-Level-Security genutzt wird, werden die Snapshots die Dokumenten-ID, das Datum der letzten Änderung und die ACL enthalten, sodass Änderungen an der ACL erkannt werden, wenn der neue Snapshot mit dem alten Snapshot verglichen wird. Das Indexieren wird durch Unterschiede zwischen dem alten und dem neuen Snapshot ausgelöst.

 

ACL-Codierung 

Viele ACLs enthalten lange Gruppennamen, eventuell auch mit Leerstellen und Satzzeichen. Als Beispiel: "SharePoint:Virginia Employees". 

Einige Suchmaschinen können solche Elemente nicht als einzelnes Token indexieren, sondern indexieren die einzelnen Wörter als separate Token. Wenn so etwas geschieht, müssten Suchen nach Benutzernamen oder Gruppennamen in der ACL als Phrasen durchgeführt werden. Das würde die Leistung drastisch reduzieren. 

Um dieses Problem zu lösen können Benutzernamen und Gruppennamen als Zeichenfolge über Base32 codiert werden. Dadurch würde "SharePoint:Virginia Employees" geändert zu "KNUGC4TFKBXWS3TUHJLGS4THNFXGSYJAIVWXA3DPPFSWK4YA". Da in dieser Zeichenfolge keine Satzzeichen oder Leerstellen vorkommen, können die meisten Suchmaschinen diese als einzelnes Token indexieren. 

Eine Alternative wäre, alle Benutzernamen und Gruppennamen in MD5 zu konvertieren. Beispiel: "SharePoint:Virginia Employees" würde zu "88dd43e132fd8814f9e8271fbd747409" geändert. Hierdurch erhält man in der Regel kleinere Token. Der Nachteil ist, dass die Kodierung nicht rückgängig gemacht werden kann, wodurch das Debuggen erschwert wird.

 

Ungewöhnliche Sicherheitsmodelle 

Unserer Erfahrung nach würde eine Umfrage, wie Sicherheitsmodelle bei Contentquellen in der Praxis implementiert sind in etwa die folgenden Resultate liefern:

  • 85% nutzen nur "allowACLs"
    • Anders ausgedrückt, die meisten Dokument-ACLs bestehen aus einer einfachen Liste der Benutzer und Gruppen, welche Zugriff auf das Dokument gestattet bekommen haben
  • 10% nutzen auch hierarchische ACLs
    • Einige wichtige Contentquellen nutzen hierarchische ACLs, wie etwa Lotus Notes und Atlassian Confluence
  • 4.9% nutzen "denyACLs"
  • 0.1% nutzen andere, komplexere Modelle
    • Zum Beispiel: Documentum nutzt die Access Control Lists "required groups" (Erforderliche Gruppen) und "required set" (Erforderliche Sätze). Diese werden aber sehr selten verwendet
    • Ein anderes Beispiel sind vererbte ACLs zum Verweigern in NTFS. Auch diese werden sehr selten verwendet

Wie geht man also diese 0,1% an? 

 

Eine Methode ist es, das gesamte Sicherheitsobjekt für das Dokument als einzelnes, nicht unterteilbares Objekt zu betrachten. Dieses wird dann im Feld "allowACLs" als einzelner Bezeichner indexiert – anstelle mehrerer Listen von Benutzern und Gruppen. Dieser Bezeichner kann aus der ursprünglichen Contentquelle kommen (wie etwa bei Documentum) oder kann aus der MD5-Signatur der ursprünglichen ACL-Informationen berechnet werden – wodurch im Prinzip alle Benutzer, Gruppen, Kennzeichnungen und andere Sicherheits-Metadaten in einem einzelnen Token eingefasst werden. 

Auf gewisse Art ist dieser ACL-Bezeichner eine "virtuelle Gruppe". Ein Benutzer kann während der Gruppenerweiterung dieser virtuellen Gruppe hinzugefügt werden, wenn er allen Kriterien entspricht, die von den gesamten Sicherheitseinschränkungen verlangt werden. 

Der Prozess würde dann wie folgt funktionieren: 

 

Während dem Indexieren:

  1. Dokument X verfügt über eine komplexe Reihe Sicherheitseinschränkungen --> CONSTRAINTS_Y
  2. MD5 erstellen für CONSTRAINTS_Y --> MD5_Y
  3. MD5_Y in allowACLs für das Dokument indexieren
  4. MD5_Y und CONSTRAINTS_Y für später in DATABASE_Z ablegen

 

Während der Abfrage:

  1. Der Benutzer (mit Gruppenmitgliedschaft und anderen Metadaten) wird mit allen Einschränkungen in DATABASE_Z verglichen. Dazu gehört CONSTRAINTS_Y
    • Da der Algorithmus alle Informationen des Benutzers mit allen Informationen in CONSTRAINTS_Y vergleicht, können diese beliebig komplex sein (und müssen nicht wie Filter bei Abfragen in Suchmaschinen codiert sein)
  2. Wenn der Benutzer die Anforderungen in CONSTRAINTS_Y erfüllt, wird MD5_Y dem Sicherheitsfilter für das Feld allowACLs hinzugefügt (in der Suchanfrage)
  3. Die von der Suchmaschine ausgegebenen Ergebnisse enthalten dann alle Dokumente, bei denen der Benutzer die komplexen Sicherheitsanforderungen in CONSTRAINTS_Y erfüllt.

Beachten Sie, dass diese Methode nur funktioniert, wenn die Zahl der "besonderen" Einschränkungen relativ gering ist. Wenn in dem oben beschriebenen Algorithmus Tausende verschiedener Werte für MD5_Y enthalten sind, gegen die ein einzelner Benutzer geprüft werden muss, wird der Algorithmus Abfragen erstellen, die zu lang werden, um noch schnell genug ausgeführt zu werden. In diesem Fall kann die komplexe Struktur nur behandelt werden, indem die Indexstruktur (zusätzliche Sicherheitsfelder) und/oder die Suchmaschine selbst modifiziert wird. 

 

Wenn eine Suchmaschine keine übergeordneten ACLs unterstützt

Alle Suchmaschinen, die Document-Level-Security bieten, unterstützen "allowACLs", die meisten auch "denyACLs". Leider unterstützen nur wenige Suchmaschinen "parentACLs". 

Dies ist noch kein Problem, solange die Suchmaschine lange Abfragen mit Hunderten von Elementen unterstützen kann. Bei diesen Suchmaschinen kann die Sicherheitsarchitektur durch externe Technologien unterstützt werden. 

Bei solchen Suchmaschinen, die nur ein einzelnes Feld für ACLs unterstützen und keine langen Abfragen erlauben, kann eine Technologie genutzt werden, die man Intersection ACLs nennt. 

 

Intersection ACLs

Um die Technologie anschaulich zu machen, nutzen wir das folgende Szenario:

  • Confluence dient als Contentquelle
  • Der Confluence "SPACE_A" enthält die folgende Access Control List:
    • [Groups] Developers, QA. Diese Gruppen würden normalerweise in das Feld parentACLs indexiert werden
  • Innerhalb von SPACE_A befindet sich ein Dokument (Document_A), welches die folgende Access Control List enthält:
    • [Groups] Virginia Employees, Executives. Diese Gruppen würden normalerweise in das Feld allowACLs indexiert werden

Da kein Feld parentACLs besteht, könnte der Konnektor stattdessen alle möglichen Kombinationen der Gruppen indexieren und als "Intersection ACLs" einrichten. Diese würden dann in das Feld "allowACLs" eingefügt und wie folgt aussehen: 

    allowACLs = 

         Developers+Virginia_Employees, 

         Developers+Executives, 

         QA+Virginia_Employees, 

         Executives+QA 

 

Anmerkung:

  1. Jedes Element (wie z.B. "Developers+Virginia_Employees") wird in der ACL als einzelner Eintrag behandelt
    • Diese sind die "Intersection ACLs", die nur akzeptiert werden, wenn ein Benutzer Mitglied in beiden Gruppen ist, die in dem Paar angegeben sind
  2. Paare von Gruppen werden normalisiert, um die Gesamtzahl möglicher Paare zu reduzieren (Entfernen von Duplikaten)
    • Beispiel: Die Kombination "Executives+QA" beschreibt dieselben Einschränkungen wie "QA+Executives". Daher werden die beiden Paare normalisiert, wobei die Gruppen im Paar nach ihrer alphabetischen Reihenfolge angeordnet werden

Während der Abfrage wird der Benutzer automatisch um alle Intersection ACLs erweitert, zu denen er gehört. Beispiel: Ein QA-Techniker, der in Virginia arbeitet, hat "QA+Virginia_Employees" zu seinem Sicherheitsfilter hinzugefügt, zusätzlich zu allen anderen Gruppen, die durch den normalen Prozess der Gruppenerweiterung erstellt wurden. 

Wie bei allen diesen Lösungen funktionieren auch Intersection ACLs nur, wenn die Zahl der Überschneidungen, zu denen ein einzelner Benutzer gehören kann, auf Hunderte Möglichkeiten begrenzt ist (nicht Tausende). Dies trifft aber meist zu.

 

Der nächste Teil unserer Graduate Level Courses zu Document-Level-Security für Suchmaschinen wirft einen Blick auf Gruppenerweiterungen und Abfragemodifikationen.

 

<< Vorangehender Artikel                                                                        Gruppenerweiterung >>      

0