Eine nützliche administrative Suche bedeutet nicht, dass beliebige Benutzer beliebige Tabellenfelder abfragen dürfen. Sie soll bei konkreten betrieblichen Aufgaben helfen und gleichzeitig berücksichtigen, welche Datensätze die jeweiligen Rollen sehen dürfen. In einer PHP-Anwendung muss diese Abgrenzung serverseitig umgesetzt und auf jede Route angewendet werden, die Informationen zurückgibt – nicht nur auf die Backoffice-Oberfläche.
Für eine sichere Suche im PHP-Backoffice muss festgelegt werden, was „Suchen“ bedeutet, welche Kriterien zulässig sind, wie der Zugriffsbereich bestimmt wird und welche Grenzen die Datenbank schützen. Diese Kriterien gelten sowohl für eine einfache SQL-Abfrage als auch für ein System mit Suchindex.
Beginnen Sie mit den Aufgaben und dem Zugriffsbereich
Klären Sie zunächst, welche Aufgaben die Suche lösen soll: eine Bestellung anhand ihrer Referenz finden, ein Konto anhand seiner E-Mail-Adresse suchen oder Vorfälle nach Status prüfen. Halten Sie für jede Aufgabe fest, wer sie ausführt und welche Datensätze diese Person abfragen darf. Definieren Sie den Umfang nicht als „alles, was in der Tabelle steht“: Eine Person im Support benötigt möglicherweise Zugriff auf bestimmte Kunden, während eine Person mit Administrationsaufgaben mit einer anderen Gruppe arbeiten kann.
Überführen Sie diese Regeln in ein nachvollziehbares Berechtigungsmodell, etwa nach Organisation, Team, Eigentümer, Region oder einer anderen Domänenbeziehung. Legen Sie außerdem fest, ob sich der Zugriff im Laufe der Zeit ändern kann und was geschieht, wenn einer Person während einer geöffneten Sitzung Berechtigungen entzogen werden. Die Oberfläche kann Optionen ausblenden, aber die maßgebliche Regel muss serverseitig geprüft werden.
Definieren Sie explizite Filter und validieren Sie jedes Kriterium
Legen Sie eine begrenzte Liste durchsuchbarer Felder und Filtertypen fest. Eine Maske kann beispielsweise eine exakte Referenz, einen Status aus einer Liste und einen Datumsbereich unterstützen. Wandeln Sie nicht beliebige vom Client übermittelte Parameter in Spalten, SQL-Bedingungen oder Zugriffskriterien um.
Validieren Sie Werte serverseitig: Prüfen Sie Formate, Längen, Wertebereiche, zulässige Werte und Kombinationen. Verwenden Sie vorbereitete Abfragen, um Werte vom SQL-Statement zu trennen. Vorbereitete Parameter schützen dynamische Spaltennamen oder Sortierreihenfolgen nicht von selbst; solche Elemente müssen aus einer serverseitig definierten Zulassungsliste stammen.
Fachliche Filter und Autorisierungsbedingungen sind zwei verschiedene Dinge. Ein Benutzer kann „Status ausstehend“ anfordern, darf aber keine Organisations-ID übermitteln, um seinen Zugriffsbereich zu erweitern. Bestimmen Sie diesen Bereich anhand der authentifizierten Identität und der geltenden Regeln, nicht anhand editierbarer Formularfelder.
Wenden Sie die Autorisierung auf Zeilen, Zählungen und zugehörige Aktionen an
Die Zugriffsbedingung muss Teil der Abfrage sein, mit der die Ergebnisse abgerufen werden. Datensätze zunächst abzurufen und erst danach in PHP zu filtern, kann Daten in Logs, im Speicher, in Antworten oder über Hilfsrouten offenlegen. Außerdem erschwert es Paginierung und Zählungen. Bauen Sie die Abfrage nach Möglichkeit so auf, dass Autorisierungsbedingungen und Suchfilter gemeinsam angewendet werden.
Prüfen Sie alle zugehörigen Ausgaben. Eine Ergebnisanzahl kann verraten, wie viele Datensätze außerhalb des autorisierten Bereichs existieren. Automatische Vorschläge können Namen oder E-Mail-Adressen offenlegen, und für einen Export können andere Regeln gelten als für die Bildschirmansicht. Auch Links zu Detailansichten und Massenaktionen müssen den Zugriffsbereich berücksichtigen. Vermeiden Sie unterschiedliche Antworten, durch die sich feststellen lässt, ob ein unzugänglicher Datensatz existiert, wenn auch diese Information sensibel ist.
Zentralisieren Sie die Erstellung von Zugriffskriterien, wenn dies zu ihrer einheitlichen Pflege beiträgt. Verwechseln Sie eine gemeinsam genutzte Abstraktion jedoch nicht mit einer automatischen Autorisierung: Prüfen Sie, ob jede Abfrage und jeder Endpunkt sie korrekt verwendet.
Entscheiden Sie zwischen SQL und einem Suchindex
SQL reicht oft aus, wenn die Filter klar definiert sind, die Relevanz bei der Textsuche keine komplexen Anforderungen stellt und die Datenbank die Abfrage mit geeigneten Indizes bewältigen kann. SQL ist eine direkte Option, um Gleichheit, Wertebereiche, Beziehungen und zulässige Sortierungen zu kombinieren. Prüfen Sie den Ausführungsplan und die Indizes, bevor Sie eine weitere Komponente hinzufügen.
Ein Suchindex kann sinnvoll sein, wenn Fehlertoleranz, linguistische Analyse, Textrelevanz oder die Suche in großen Datenmengen erforderlich ist und SQL die geforderten betrieblichen Ziele nicht erreicht. Er bringt jedoch zusätzlichen Synchronisierungsaufwand, Aktualisierungsverzögerungen, Zugriffskontrollen und Betriebsaufwand mit sich. Der Index ersetzt die Datenbank nicht als maßgebliche Quelle für Berechtigungen.
Enthält der Index Daten aus mehreren Zugriffsbereichen, müssen Sie die Abfrage vor der Rückgabe von Dokumenten durch Autorisierung einschränken und berücksichtigen, wie Änderungen oder der Entzug von Berechtigungen weitergegeben werden. Prüfen Sie den Zugriff für sensible Aktionen erneut anhand der maßgeblichen Datenquelle. Legen Sie fest, welche Verzögerung akzeptabel ist und was bei einem veralteten oder nicht verfügbaren Index geschieht. Als Ausweichlösung kann die erweiterte Suche vorübergehend deaktiviert werden – Kontrollen dürfen nicht ausgelassen werden.
Begrenzen Sie Aufwand, Sortierung und Antwortvolumen
Legen Sie eine maximale Seitengröße fest und verwenden Sie eine stabile Paginierung. Bei großen Datenmengen oder häufig wechselnden Ergebnissen kann Cursor-Paginierung einen Teil der Probleme beim Überspringen von Zeilen vermeiden. Dafür sind jedoch eine konsistente Sortierung und klar definierte Fortsetzungskriterien erforderlich.
Erlauben Sie die Sortierung nur nach vorgesehenen Feldern und legen Sie eine deterministische sekundäre Sortierung fest, beispielsweise anhand einer eindeutigen ID. Begrenzen Sie die Länge von Suchbegriffen, Datumsbereiche und die Anzahl der Filter. Vermeiden Sie leere Suchanfragen, die kostspielige Tabellendurchläufe auslösen. Ziehen Sie für aufwendige Vorgänge Ratenbegrenzungen und maximale Ausführungszeiten in Betracht. Die Suche sollte keine Felder zurückgeben, die die Oberfläche nicht benötigt.
Prüfen Sie Berechtigungen und Grenzfälle
Fügen Sie positive und negative Tests für unterschiedliche Rollen und Zugriffsbereiche hinzu. Prüfen Sie, ob jeder Benutzer die zulässigen Datensätze findet und keine anderen erhält, wenn Filter geändert, Seiten durchgeblättert, Ergebnisse sortiert oder Detailseiten angefordert werden. Berücksichtigen Sie kombinierte Filter, ungültige Werte, leere Ergebnisse und Datensätze, deren Eigentümer oder Zugriffsbereich sich geändert hat.
Testen Sie auch Zählungen, Vorschläge, Exporte und Massenaktionen. Ein aussagekräftiger Test prüft nicht nur, ob ein fremder Datensatz in der Liste fehlt, sondern auch, ob er sich über eine exakte Referenz finden oder anhand einer Hilfsantwort erschließen lässt. Prüfen Sie bei geänderten Berechtigungen, ob das Verhalten entsprechend der festgelegten Richtlinie aktualisiert wird.
Betriebsmetriken sollten bei der Diagnose helfen, ohne eine weitere Offenlegung zu verursachen. Erfassen Sie Latenz, Fehler, Ergebnisvolumen und Vorgangstyp, vermeiden Sie jedoch die Speicherung sensibler Suchbegriffe oder unnötiger personenbezogener Daten. Beschränken Sie den Zugriff auf diese Logs und legen Sie deren Aufbewahrungsdauer fest. Beobachten Sie langsame Abfragen und Indexfehler getrennt, damit sich Leistungsprobleme von Autorisierungsfehlern unterscheiden lassen.
Checkliste vor der Veröffentlichung von Änderungen
- Aufgaben, Rollen und Zugriffsbereiche sind dokumentiert.
- Durchsuchbare Felder, Filter, Sortierungen und Grenzwerte sind eindeutig festgelegt.
- Der Server validiert Parameter und verwendet keine Clientdaten, um Zugriff zu gewähren.
- Die Autorisierung gilt für Ergebnisse, Zählungen, Vorschläge, Detailansichten und Exporte.
- Für SQL oder den Suchindex gibt es eine Leistungsstrategie und eine Ausweichlösung für Fehlerfälle.
- Die Tests umfassen erlaubte und verweigerte Zugriffe, Berechtigungsänderungen und kombinierte Filter.
- Logs und Metriken ermöglichen die Diagnose, ohne unnötig sensible Begriffe zu speichern.
Eine administrative Suche ist bereit, wenn sie die vorgesehenen Aufgaben mit nachvollziehbaren Ergebnissen, kontrolliertem Aufwand und überprüfbaren Zugriffsgrenzen unterstützt. Erfordert eine Verbesserung der Relevanz, mehr Daten durchsuchbar zu machen oder einen Index einzuführen, bewerten Sie diese Änderung als Teil des Sicherheitsmodells und nicht als Implementierungsdetail.
