Semantische Suche mit Berechtigungen in PHP

Eine Suche, die ein Dokument findet, auf das der Benutzer keinen Zugriff hat, ist bereits fehlgeschlagen, selbst wenn die Oberfläche den abschließenden Link verbirgt. In Dokumentensystemen, Akten, Backoffices und Wissensdatenbanken entsteht das Risiko früher: im Index, in den abgerufenen Fragmenten, in den angezeigten Metadaten und in einer Antwort, die aus nicht autorisiertem Kontext generiert wird.

Die semantische Suche mit Berechtigungen in PHP muss die Autorisierung als Teil des Abrufs behandeln, nicht als dekorative Prüfung der Ansicht. Das Ziel besteht nicht nur darin, nützliche Ergebnisse zurückzugeben: Es gilt sicherzustellen, dass jedes Kandidatenfragment, jedes Zitat und jede Antwort ausschließlich aus Inhalten abgeleitet wird, die der authentifizierte Principal zu diesem Zeitpunkt einsehen darf.

Entscheidungen, die vor der Indexierung getroffen werden müssen

Beginnen Sie mit der Definition des Korpus und seines Zugriffsmodells. Nicht alle Inhalte haben denselben Lebenszyklus oder dieselbe Sensibilität: Eine öffentliche Richtlinie, ein internes Handbuch, eine Akte und eine extern geteilte Datei erfordern unterschiedliche Regeln. Sie müssen außerdem entscheiden, welche Aktion die Suche ermöglicht: einen Titel finden, einen Auszug lesen, das Dokument öffnen, einen Anhang herunterladen oder eine Zusammenfassung anfordern. Die Berechtigung zur Auffindbarkeit impliziert nicht zwingend die Leseberechtigung.

• Principal: Benutzer, Dienstkonto oder delegierte Sitzung, die die Abfrage ausführt.
• Bereich: Organisation, Workspace, Projekt, Akte oder Repository, in dem gesucht werden darf.
• Aktion: auffinden, lesen, herunterladen oder verwalten.
• Ressource: Dokument und Fragment mit ihrem Status, ihrer Klassifizierung und ihrer Zugehörigkeit.
• Fehlertoleranz: Bei der Autorisierung muss Nichtoffenlegung Vorrang haben; ein False Negative ist lästig, ein False Positive kann eine Sicherheitslücke sein.

Vektorähnlichkeit versteht keine Geschäftsregeln. Ein Embedding repräsentiert Nähe in der Bedeutung, nicht die Legitimität des Zugriffs. Daher darf sich das Design weder darauf verlassen, dass ein „ähnliches“ Ergebnis sicher ist, noch darauf, dass ein generatives Modell unzulässigen Kontext ignoriert.

Referenzarchitektur und führende Datenquelle

Bewahren Sie Berechtigungen in einer transaktionalen führenden Datenquelle auf: der PHP-Anwendung, ihrer Datenbank oder dem Dokumentensystem, das die Ressourcen steuert. Der Index ist eine wiederherstellbare Projektion, nicht die Autorität, die über Zugriff entscheidet. Wenn der Index beschädigt ist, verzögert wird oder unvollständige Daten erhält, muss die Autorisierungsschicht die Auslieferung verhindern können.

Ein robuster Ablauf trennt vier Phasen:

1. Inhalt wird aus einer identifizierbaren Version des Dokuments extrahiert und mit kohärenten Grenzen in Fragmente aufgeteilt.
2. Repräsentationen für den Abruf werden berechnet und zusammen mit Bereichs- und Versionsmetadaten gespeichert.
3. Die Abfrage erstellt einen autorisierbaren Filter für den Principal und ruft Kandidaten nur innerhalb dieses Bereichs ab.
4. Die Anwendung prüft für jeden Kandidaten Berechtigung und Gültigkeit erneut, bevor sie ihn anzeigt oder als Kontext verwendet.

Kapseln Sie diese Verantwortlichkeiten in PHP. Ein Richtliniendienst muss can($principal, 'read', $dokument) auflösen; ein Indexadapter muss Filter erhalten, die aus dieser Entscheidung abgeleitet sind; und der Ergebnisassembler darf nur verifizierte Kandidaten akzeptieren. Vermeiden Sie, dass Controller, Templates oder Prompts Berechtigungsfilter selbst zusammensetzen.

Metadaten, die Filtern ohne Raten ermöglichen

Jedes Dokument und Fragment benötigt eine stabile Kennung für Organisation und Ressource, eine Inhaltsversion, einen Indexierungsstatus und eine Referenz auf das Elterndokument. Fügen Sie die Attribute hinzu, die zur Ausdrückung der Richtlinie erforderlich sind, replizieren Sie jedoch nicht unnötig sensible Daten.

• tenant_id oder Organisation: obligatorische Barriere in Mandantenumgebungen.
• document_id und chunk_id: Nachverfolgbarkeit vom Ergebnis bis zur Quelle.
• acl_revision: Version der bei der Indexierung angewendeten Richtlinie.
• audience: einfacher Bereich wie internes Publikum, Team, Projekt oder Akte.
• lifecycle_state: aktiv, archiviert, gelöscht oder zur Überprüfung ausstehend.
• content_revision: verhindert, dass eine bereits ersetzte Version zitiert wird.

Indexieren Sie keine riesige Benutzerliste pro Fragment, wenn die Richtlinie auf veränderlichen Gruppen basiert: Das erhöht Kosten, legt Beziehungen offen und altert schlecht. Es ist vorzuziehen, soweit möglich nach stabilen Bereichen zu filtern und Ausnahmen in der nachgelagerten Prüfung aufzulösen. Wenn die Abruf-Engine keine zuverlässigen Filter unterstützt, darf sie keine Inhalte aus mehreren Sicherheitsbereichen im selben durchsuchbaren Raum erhalten.

Vor dem Abruf filtern und danach verifizieren

Vorabfilterung reduziert die Angriffsfläche: Die semantische Abfrage muss Organisation, aktiven Status und die zulässigen Bereiche einschließen, bevor die endgültigen Kandidaten berechnet werden. Dadurch wird verhindert, dass verbotener Text das Ranking, Auszüge oder den Kontext einer assistierten Antwort beeinflusst.

Die nachgelagerte Verifizierung bleibt dennoch erforderlich. Berechtigungen können sich zwischen Abfrage und Lesen ändern, eine Vererbung kann von nicht projizierten Daten abhängen oder der Index kann verzögert sein. Rufen Sie für jeden Kandidaten das aktuelle Dokument ab oder fragen Sie einen Autorisierungs-Cache mit sicherer Invalidierung ab. Wenn die Prüfung fehlschlägt, verwerfen Sie das Fragment, ohne seinen Titel, seine Bewertung oder seine Existenz offenzulegen.

Bei assistierter Generierung geben Sie dem Modell nur bereits autorisierte und verifizierte Fragmente. Definieren Sie einen konkreten Anwendungsfall, etwa das Zusammenfassen abgerufener Ergebnisse; bewerten Sie Antworten mit zulässigen und verbotenen Fällen; bewahren Sie überprüfbare Zitate auf; begrenzen Sie die Kosten pro Abfrage; und halten Sie eine nicht generative Alternative wie eine Ergebnisliste bereit. Ein Modell ersetzt weder die Zugriffsrichtlinie noch die menschliche Kontrolle über sensible Inhalte.

Vererbung, Links und Entzüge, die einfache Designs brechen

Gruppen, geerbte Ordner und geteilte Links führen indirekte Änderungen ein. Eine Person, die eine Gruppe verlässt, ein Dokument, das den Ordner wechselt, oder ein Link, der abläuft, müssen sich sowohl auf das Öffnen als auch auf den Abruf auswirken. Modellieren Sie die Rangfolge zwischen direkten Berechtigungen, Vererbung und Verweigerungen explizit und testen Sie Konflikte.

Entzüge erfordern eine strengere Strategie als Erteilungen. Veröffentlichen Sie Ereignisse zu Inhalts- und ACL-Änderungen über eine transaktionale Warteschlange oder ein Änderungsprotokoll; ein Worker berechnet Metadaten neu und entfernt oder indexiert Fragmente erneut. Während der Index konvergiert, schützt die nachgelagerte Verifizierung die Auslieferung. Markieren Sie bei Löschungen die Ressource in der führenden Datenquelle sofort als nicht verfügbar und bereinigen Sie ihre Fragmente asynchron, mit Warnungen, wenn die Verzögerung das Betriebsziel überschreitet.

Überprüfbare Ergebnisse, Tests und Beobachtbarkeit

Zeigen Sie Titel, begrenzten Auszug, Speicherort und Datum nur an, wenn auch diese Felder lesbar sind. Jedes Ergebnis muss zur ursprünglich autorisierten Ressource führen; ein Zitat darf keinen Pfad, Autor oder Text eines verborgenen Dokuments offenlegen. Verwenden Sie bei fehlenden Ergebnissen eine neutrale Meldung: Bestätigen Sie nicht, ob Inhalte außerhalb des Benutzerbereichs existieren.

Erstellen Sie eine Testmatrix mit Benutzern aus unterschiedlichen Organisationen, Mitgliedern und Nichtmitgliedern von Gruppen, eingeschränkten Administratoren, abgelaufenen Links und während einer Sitzung entzogenen Ressourcen. Testen Sie direkte Abfragen, Synonyme, seltene Begriffe und Fragen, die darauf ausgelegt sind, verbotene Inhalte anzuziehen. Zu den erwarteten Ergebnissen gehören leere Listen, wenn alles Relevante untersagt ist.

Protokollieren Sie, ohne unnötigerweise sensible Abfragen zu speichern, die Indexversion, angewendete Filter, die Anzahl der Kandidaten vor und nach der Verifizierung, Latenz, Verweigerungen und den Synchronisationsverzug. Ein Anstieg nachträglich verworfener Treffer kann auf veraltete ACLs hinweisen; null Ergebnisse nach einer Migration können übermäßig restriktive Filter anzeigen; Abfragen zwischen Organisationen sind ein Isolierungsalarm.

Wann eine andere Lösung zu wählen ist und Abschlusscheckliste

Semantische Suche lohnt sich nicht immer. Für kleine Kataloge und stabiles Vokabular sind Filter, Textsuche und hierarchische Navigation besser erklärbar und günstiger. Sie sind auch vorzuziehen, wenn Berechtigungen sehr dynamisch sind und die Engine nicht sicher nach Attributen filtern kann. Setzen Sie semantischen Abruf ein, wenn er bei in natürlicher Sprache formulierten Abfragen echten Mehrwert bietet und die vollständige Zugriffskontrolle aufrechterhalten werden kann.

• Die führende Datenquelle entscheidet über den Zugriff, und der Index kann neu aufgebaut werden.
• Alle Fragmente haben Organisation, Dokument, Version und Status.
• Die Abfrage filtert vor dem Abruf und verifiziert vor der Auslieferung.
• Erteilungen, Änderungen, Entzüge und Löschungen verfügen über beobachtbare Synchronisierung.
• Assistierte Antworten verwenden nur autorisierten Kontext, Zitate und eine Alternative ohne KI.
• Die Tests umfassen bewusste Versuche unzulässigen Zugriffs und leere Ergebnisse.