Erfahren Sie, wie Sie eine berechtigungsbewusste globale Suche mit schnellem Indexing und strikten Zugriffskontrollen pro Datensatz entwerfen, damit Nutzer schnelle Ergebnisse erhalten, ohne dass Daten durchsickern.
Globale Suche bedeutet meist eine einzige Suchbox, die die gesamte App durchsucht: Kunden, Tickets, Rechnungen, Dokumente, Benutzer und alles andere, womit Menschen arbeiten. Sie treibt oft Autovervollständigung und eine schnelle Ergebnisliste an, damit Nutzer direkt zu einem Datensatz springen können.
Ein Leak entsteht, wenn die Suche etwas zurückgibt, das der Nutzer nicht wissen darf. Selbst wenn er den Datensatz nicht öffnen kann, kann eine einzige Zeile — ein Titel, ein Personenname, ein Tag oder ein hervorgehobener Ausschnitt — sensible Informationen offenbaren.
Suche wirkt oft wie „nur lesend“, deshalb unterschätzen Teams das Risiko. Aber Daten können über Ergebnis-Titel und -Vorschauen, Autovervollständigungen, Ergebnisanzahlen, Facetten wie „Kunden (5)“ und sogar über Zeitunterschiede (schnell für manche Begriffe, langsamer für andere) preisgegeben werden.
Das Problem taucht meist später auf, nicht am ersten Tag. Anfangs liefern Teams Suche, wenn es nur eine Rolle gibt oder in einer Testdatenbank alle alles sehen. Mit dem Produktwachstum kommen Rollen (Support vs. Sales, Manager vs. Agent) und Funktionen wie gemeinsame Postfächer, private Notizen, eingeschränkte Kunden und „nur meine Konten“. Wenn die Suche noch von den alten Annahmen ausgeht, fängt sie an, team- oder kundenspezifische Hinweise zurückzugeben.
Ein häufiger Fehler ist, "alles" für die Geschwindigkeit zu indexieren und dann zu versuchen, Ergebnisse in der App nachzufiltern. Das ist zu spät. Die Suchmaschine hat bereits entschieden, was passt, und kann eingeschränkte Datensätze über Vorschläge, Zählungen oder Teilfelder offenbaren.
Stellen Sie sich einen Support-Agenten vor, der nur Tickets für seine zugewiesenen Kunden sehen darf. Er tippt „Acme“ und die Autovervollständigung zeigt „Acme - Legal escalation“ oder „Acme breach notification“. Selbst wenn ein Klick mit „Zugriff verweigert" fehlschlägt, ist der Titel allein schon ein Datenleck.
Das Ziel einer berechtigungsbewussten globalen Suche ist einfach gesagt, aber schwer umzusetzen: schnelle, relevante Ergebnisse liefern und gleichzeitig die gleichen Zugriffsregeln durchsetzen, die gelten, wenn ein Datensatz geöffnet wird. Jede Anfrage muss so behandeln, als könne der Nutzer nur seinen Ausschnitt der Daten sehen, und die UI darf keine zusätzlichen Hinweise (wie Zählungen) außerhalb dieses Ausschnitts leaken.
Globale Suche wirkt simpel, weil Nutzer Wörter eingeben und Antworten erwarten. Im Hintergrund schaffen Sie jedoch eine neue Angriffsfläche für Datenoffenlegung. Bevor Sie einen Index oder Datenbank-Feature wählen, klären Sie zwei Dinge: welche Objekte Sie durchsuchen (Entitäten) und welche Teile dieser Objekte sensibel sind.
Eine Entität ist jeder Datensatz, den jemand schnell finden möchte. In den meisten Business-Apps gehören dazu Kunden, Support-Tickets, Rechnungen, Bestellungen und Dateien (oder Dateimetadaten). Es können auch Personen-Datensätze (Benutzer, Agenten), interne Notizen und Systemobjekte wie Integrationen oder API-Schlüssel sein. Hat etwas einen Namen, eine ID oder einen Status, den jemand eintippen könnte, landet es wahrscheinlich in der globalen Suche.
Regeln pro Tabelle sind grob: entweder hat man Zugriff auf die ganze Tabelle oder nicht. Beispiel: nur die Finanzabteilung darf die Rechnungsseite öffnen. Das ist leicht zu verstehen, bricht aber zusammen, wenn verschiedene Personen unterschiedliche Zeilen derselben Tabelle sehen sollen.
Regeln pro Datensatz entscheiden Sichtbarkeit Zeile für Zeile. Beispiel: ein Support-Agent darf Tickets sehen, die seinem Team zugewiesen sind, während ein Manager alle Tickets in seiner Region sehen kann. Eine weitere übliche Regel ist Mandantenbesitz: in einer Multi-Tenant-App darf ein Nutzer nur Datensätze sehen, bei denen customer_id = their_customer_id.
Genau hier leckt die Suche oft. Wenn Ihr Index einen Treffer zurückgibt, bevor Sie den Zeilenzugriff prüfen, haben Sie bereits offengelegt, dass etwas existiert.
„Dürfen" ist selten ein einfaches Ja/Nein. Meist ist es eine Kombination aus Besitz (von mir erstellt, mir zugewiesen), Mitgliedschaft (mein Team, meine Abteilung, meine Rolle), Umfang (meine Region, Geschäftseinheit, Projekt), Zustand des Datensatzes (veröffentlicht, nicht archiviert) und Sonderfällen (VIP-Kunden, rechtliche Sperren, eingeschränkte Tags).
Schreiben Sie diese Regeln zuerst in einfacher Sprache auf. Später übersetzen Sie das in ein Datenmodell plus serverseitige Prüfungen.
Suchergebnisse enthalten oft eine Vorschau, und Vorschauen können sensible Daten offenbaren, selbst wenn der Nutzer den Datensatz nicht öffnen kann.
Ein sicherer Standard ist, zunächst nur minimale, nicht-sensible Felder anzuzeigen, bis der Zugriff bestätigt ist: ein Anzeigename oder Titel (manchmal maskiert), eine kurze Kennung (z. B. Bestellnummer), ein grober Status (Offen, Bezahlt, Versendet), ein Datum (erstellt oder aktualisiert) und ein generisches Entitätenlabel (Ticket, Rechnung).
Konkretes Beispiel: Wenn jemand „Acme merger" sucht und ein eingeschränktes Ticket existiert, ist „Ticket: Acme merger draft - Legal" bereits ein Leak. Sicherer wäre „Ticket: Restricted" ohne Ausschnitt oder gar kein Ergebnis, je nach Richtlinie.
Wenn Sie diese Definitionen früh richtig festlegen, werden spätere Entscheidungen einfacher: was Sie indexieren, wie Sie filtern und was Sie bereit sind preiszugeben.
Menschen nutzen globale Suche, wenn sie es eilig haben. Dauert es länger als eine Sekunde, vertrauen sie ihr nicht mehr und greifen wieder zu manuellen Filtern. Geschwindigkeit ist aber nur die halbe Miete. Eine schnelle Suche, die auch nur einen Datensatztitel, einen Kundennamen oder ein Ticketthema leakt, ist schlimmer als gar keine Suche.
Die Kernregel ist nicht verhandelbar: Berechtigungen müssen zur Abfragezeit durchgesetzt werden, nicht nur in der UI. Eine Zeile zu verbergen, nachdem Sie sie bereits abgerufen haben, ist zu spät, weil das System schon Daten berührt hat, die es nicht hätte zurückgeben dürfen.
Das gilt für alles rund um die Suche, nicht nur für die Ergebnisliste. Vorschläge, Top-Treffer, Zählungen und sogar „keine Ergebnisse"-Verhalten können Informationen leaken. Autocomplete, das „Acme Renewal Contract" anzeigt, obwohl der Nutzer ihn nicht öffnen darf, ist ein Leak. Eine Facette, die „12 passende Rechnungen" anzeigt, ist ein Leak, wenn der Nutzer nur 3 sehen darf. Selbst die Antwortzeit kann Informationen verraten, wenn eingeschränkte Treffer die Anfrage verlangsamen.
Eine sichere globale Suche braucht vier Dinge:
Eine nützliche Denkweise: Behandeln Sie Suche wie eine weitere Daten-API, nicht nur als UI-Feature. Das bedeutet, dieselben Zugriffsregeln, die Sie für Listenseiten anwenden, müssen auch für Indexaufbau, Abfrageausführung und alle zugehörigen Endpunkte gelten (Autocomplete, kürzliche Suchen, beliebte Abfragen).
Eine Suchbox ist schnell gebaut. Eine berechtigungsbewusste globale Suche ist schwieriger, weil der Index Ergebnisse sofort liefern möchte, während Ihre App niemals Datensätze offenbaren darf, zu denen der Nutzer keinen Zugriff hat.
Nachfolgend drei Muster, die Teams am häufigsten verwenden. Die richtige Wahl hängt davon ab, wie komplex Ihre Zugriffsregeln sind und wie viel Risiko Sie tolerieren können.
Ansatz A: Nur „sichere" Felder indexieren, dann nach Klick Berechtigung prüfen. Speichern Sie ein minimales Dokument im Suchindex, z. B. eine ID plus ein nicht-sensibles Label, das sicher ist, jedem anzuzeigen, der die Such-UI erreichen kann. Wenn ein Nutzer ein Ergebnis anklickt, lädt Ihre App den vollständigen Datensatz aus der Primärdatenbank und wendet dort die echten Berechtigungsregeln an.
Das reduziert das Leckrisiko, kann die Suche aber flach wirken lassen, weil Nutzer wenig Kontext in den Ergebnissen bekommen. Es braucht außerdem eine sorgfältige UI-Formulierung, damit ein "sicheres" Label nicht versehentlich Geheimnisse offenbart.
Ansatz B: Berechtigungsattribute im Index speichern und dort filtern. Sie fügen Felder wie tenant_id, team_id, owner_id, Rollenflags oder project_id in jedes indizierte Dokument ein. Jede Abfrage fügt Filter hinzu, die den aktuellen Nutzerbereich abgleichen.
Das liefert schnelle, reichhaltige Ergebnisse und gute Autocomplete-Funktionen, funktioniert aber nur, wenn Zugriffsregeln als Filter ausdrückbar sind. Wenn Berechtigungen von komplexer Logik abhängen (z. B. „zugewiesen ODER diese Woche on-call ODER Teil eines Incidents"), wird es schwer, korrekt zu bleiben.
Ansatz C: Hybrid. Grobe Filter im Index, finale Prüfung in der Datenbank. Filtern Sie im Index mit stabilen, breiten Attributen (Tenant, Workspace, Kunde) und prüfen Sie dann die bereitgestellten Kandidaten-IDs in der Primärdatenbank erneut, bevor Sie etwas zurückgeben.
Das ist oft der sicherste Weg für reale Apps: der Index bleibt schnell, und die Datenbank bleibt die Quelle der Wahrheit.
Wählen Sie A, wenn Sie die einfachste Lösung wollen und mit minimalen Snippets leben können. Wählen Sie B, wenn Sie klare, weitgehend statische Bereiche haben (Multi-Tenant, Team-basierter Zugriff) und sehr schnelle Autocomplete-Ergebnisse benötigen. Wählen Sie C, wenn Sie viele Rollen, Ausnahmen oder datensatzspezifische Regeln haben, die sich oft ändern. Für hochriskante Daten (HR, Finanzen, Medizin) bevorzugen Sie C, weil „fast korrekt" nicht akzeptabel ist.
Beginnen Sie damit, Ihre Zugriffsregeln so aufzuschreiben, wie Sie sie einem neuen Teammitglied erklären würden. Vermeiden Sie „Admin kann alles sehen", es sei denn, es ist wirklich so. Nennen Sie stattdessen die Gründe: „Support-Agenten dürfen Tickets ihres Tenants sehen. Team-Leads dürfen außerdem Tickets ihrer Organisationseinheit sehen. Nur der Ticketbesitzer und der zugewiesene Agent dürfen private Notizen sehen." Wenn Sie nicht sagen können, warum jemand einen Datensatz sehen kann, wird es schwer, das sicher zu kodieren.
Wählen Sie dann einen stabilen Identifier und definieren Sie ein minimales Suchdokument. Der Index sollte keine vollständige Kopie Ihrer Datenbankzeile sein. Bewahren Sie nur, was Sie zum Finden und Anzeigen in der Ergebnisliste benötigen, z. B. Titel, Status und eventuell einen kurzen, nicht-sensiblen Ausschnitt. Legen Sie sensible Felder hinter einen zweiten Fetch, der ebenfalls Berechtigungen prüft.
Entscheiden Sie danach, welche Berechtigungssignale Sie schnell filtern können. Das sind Attribute, die den Zugriff sperren und in jedem indizierten Dokument gespeichert werden können, z. B. tenant_id, org_unit_id und eine kleine Anzahl von Scope-Flags. Ziel ist, dass jede Abfrage Filter anwenden kann, bevor Ergebnisse zurückgegeben werden, inklusive Autocomplete.
Ein praktischer Workflow sieht so aus:
Geteilte Elemente und Ausnahmen sind typische Schwachstellen. Wenn ein Ticket über Teams geteilt werden kann, fügen Sie nicht einfach ein Boolean-Feld hinzu. Verwenden Sie explizite Grants, die per Filter geprüft werden können. Ist die Allowlist groß, bevorzugen Sie gruppenbasierte Grants statt einzelner Nutzer.
Eine sichere Suche hängt von einer langweiligen, aber wichtigen Sache ab: Der Index muss die Realität widerspiegeln. Wird ein Datensatz erstellt, geändert, gelöscht oder seine Berechtigungen ändern sich, müssen die Suchergebnisse schnell und vorhersehbar folgen.
Behandeln Sie das Indexieren als Teil Ihres Datenlebenszyklus. Ein nützliches Modell: Jedes Mal, wenn die Quelle der Wahrheit sich ändert, emitten Sie ein Event und der Indexer reagiert.
Gängige Ansätze sind Datenbank-Triggers, Anwendungsevents oder eine Job-Queue. Wichtig ist, dass Events nicht verloren gehen. Kann Ihre App den Datensatz speichern, aber die Indexierung schlägt fehl, bekommen Sie verwirrendes Verhalten wie „Ich weiß, dass es existiert, aber die Suche findet es nicht."
Viele Lecks entstehen, wenn Inhalte korrekt aktualisiert werden, aber die Zugriffsmetadaten nicht. Berechtigungsänderungen kommen durch Rollenupdates, Team-Wechsel, Besitzübertragungen, Kundenreassignments oder das Zusammenführen von Tickets.
Machen Sie Berechtigungsänderungen zu erstklassigen Events. Wenn Ihre berechtigungsbewusste Suche auf Tenant- oder Team-Filtern beruht, stellen Sie sicher, dass indizierte Dokumente die Felder enthalten, die benötigt werden, um das durchzusetzen (tenant_id, team_id, owner_id, allowed_role_ids). Wenn diese Felder sich ändern, reindexen.
Die heikle Frage ist die Blast-Radius: Eine Rollenänderung kann Tausende Datensätze betreffen. Planen Sie einen Bulk-Reindex-Pfad mit Fortschritt, Retries und der Möglichkeit zu pausieren.
Selbst mit guten Events bleibt ein Zeitfenster, in dem die Suche hinterherhinkt. Entscheiden Sie, was Nutzer in den ersten Sekunden nach einer Änderung sehen sollen.
Zwei Regeln helfen:
Suche dient der Entdeckung, aber das Ansehen der Details ist der Ort, an dem Lecks weh tun. Führen Sie zur Anzeige sensibler Felder eine zweite Berechtigungsprüfung zur Lesezeit durch. Wenn ein Ergebnis aufgrund eines veralteten Indexrutsches durchrutscht, sollte die Detailseite den Zugriff dennoch blockieren.
Ein gutes Muster: Zeigen Sie minimale Snippets in der Suche und prüfen Sie beim Öffnen oder Erweitern einer Vorschau die Berechtigung erneut. Wenn die Prüfung fehlschlägt, zeigen Sie eine deutliche Meldung und entfernen Sie das Element bei der nächsten Aktualisierung aus der sichtbaren Ergebnisliste.
Die Suche kann Daten leaken, selbst wenn Ihre „Datensatz öffnen"-Seite abgesichert ist. Ein Nutzer klickt vielleicht nie auf ein Ergebnis und erfährt trotzdem Namen, Kunden-IDs oder die Existenz eines sensiblen Projekts. Berechtigungsbewusste globale Suche muss nicht nur Dokumente, sondern auch Hinweise auf Dokumente schützen.
Autocomplete ist eine häufige Quelle von Lecks. Vorschläge basieren oft auf einer schnellen Präfix-Suche, die vollständige Berechtigungsprüfungen überspringt. Die UI wirkt harmlos, aber ein einzelner eingegebener Buchstabe kann einen Kundennamen oder die E-Mail eines Mitarbeiters offenbaren. Autocomplete muss dieselben Zugriffsfilter wie die Vollsuche ausführen oder aus einem vorgefilterten Vorschlagsset bestehen (z. B. pro Tenant und Rolle).
Facettenzählungen und „Ungefähr 1.243 Ergebnisse"-Banner sind ein weiterer stiller Leak. Zählungen können bestätigen, dass etwas existiert, auch wenn Sie die Datensätze verbergen. Wenn Sie Zählungen nicht sicher nach denselben Zugriffsregeln berechnen können, zeigen Sie weniger Details oder lassen Sie Zählungen weg.
Caching ist ein weiterer häufiger Übeltäter. Geteilte Caches über Nutzer, Rollen oder Tenants hinweg können „Resultat-Geister" erzeugen, bei denen ein Nutzer Ergebnisse sieht, die für jemand anderen generiert wurden. Das passiert bei Edge-Caches, Anwendungscaches und In-Memory-Caches innerhalb eines Suchservices.
Leak-Fallen, die Sie früh prüfen sollten:
Achten Sie abschließend auf zu breite Filter. „Nach Tenant filtern" ist der klassische Multi-Tenant-Fehler, aber das passiert auch innerhalb eines Tenants: Nach „Abteilung" filtern, wenn der Zugriff zeilenweise geregelt ist. Beispiel: Ein Support-Agent sucht „refund" und erhält Ergebnisse über alle Kunden im Tenant, inklusive VIP-Konten, die nur einem kleineren Team sichtbar sein sollten. Die Lösung ist prinzipiell einfach: Erzwingen Sie Zeilenregeln in jedem Abfragepfad (Suche, Autocomplete, Facetten, Exporte), nicht nur in der Datensatzansicht.
Viele Designs konzentrieren sich auf „wer darf was sehen", aber Lecks entstehen auch an den Rändern: leere Zustände, Zeitverhalten und kleine Hinweise in der UI. Berechtigungsbewusste Suche muss selbst dann sicher sein, wenn sie nichts zurückgibt.
Ein einfacher Leak ist Bestätigung durch Abwesenheit. Wenn ein nicht autorisierter Nutzer nach einem bestimmten Kundennamen, einer Ticket-ID oder E-Mail sucht und eine spezielle Meldung wie „Kein Zugriff" oder „Sie haben keine Berechtigung" erhält, haben Sie die Existenz bestätigt. Behandeln Sie „keine Ergebnisse" als Standard für sowohl „existiert nicht" als auch „existiert, aber nicht erlaubt". Halten Sie Antwortzeit und Formulierungen konsistent, damit Nutzer nicht anhand der Geschwindigkeit raten können.
Autovervollständigung und Suche-while-you-type sind Bereiche, in denen Privatsphäre rutscht. Teiltreffer auf E-Mails, Telefonnummern und staatlichen oder Kunden-IDs können mehr offenbaren, als beabsichtigt. Entscheiden Sie im Voraus, wie diese Felder behandelt werden.
Eine praktische Reihe von Regeln:
Wenn selbst ein einzelnes Zeichen hilft, Daten zu erraten, behandeln Sie das Feld als sensibel.
Suchendpunkte eignen sich für Enumerationsangriffe: viele Abfragen auszuführen, um zu kartografieren, was existiert. Fügen Sie Ratenbegrenzung und Anomalieerkennung hinzu, aber seien Sie vorsichtig, was Sie speichern. Logs mit rohen Abfragen können zum zweiten Datenleck werden.
Halten Sie es einfach: Rate-Limits pro Nutzer, pro IP und pro Tenant; loggen Sie Zählwerte, Zeiten und grobe Muster (nicht den vollständigen Abfrage-Text); alarmieren Sie bei wiederholten „Near-Miss"-Abfragen (z. B. sequentielle IDs); und fordern Sie nach wiederholten Fehlschlägen eine erhöhte Verifikation an.
Machen Sie Ihre Fehler langweilig. Verwenden Sie dieselbe Meldung und denselben leeren Zustand für „keine Ergebnisse", „nicht erlaubt" und „ungültige Filter". Je weniger Ihre Such-UI sagt, desto weniger kann sie versehentlich verraten.
Eine Support-Agentin, Maya, arbeitet in einem Team, das drei Kundenkonten betreut. Sie hat eine Suchbox in der App-Headerleiste. Das Produkt hat einen globalen Index über Tickets, Kontakte und Firmen, aber jedes Ergebnis muss Zugriffregeln folgen.
Maya tippt „Alic", weil ein Anrufer sagte, ihr Name sei Alice. Die Autovervollständigung zeigt einige Vorschläge. Sie klickt „Alice Nguyen - Ticket: Password reset." Bevor irgendetwas geöffnet wird, prüft die App den Zugriff für diesen Datensatz erneut. Ist das Ticket noch ihrem Team zugewiesen und erlaubt ihre Rolle den Zugriff, landet sie im Ticket.
Was Maya in den einzelnen Schritten sieht:
Vergleichen Sie das mit Leo, einem neuen Trainee. Seine Rolle darf nur Tickets sehen, die als „Public to Support" markiert sind und nur für einen Kunden. Leo tippt dieselbe Anfrage „Alic." Er sieht weniger Vorschläge, und keine der fehlenden wird angedeutet. Es gibt keine „5 Ergebnisse"-Zählung, die andere Treffer bestätigen würde. Die UI zeigt schlicht, was er öffnen darf.
Später weist ein Manager „Alice Nguyen - Password reset" von Mayas Team an ein spezialisiertes Eskalationsteam zu. Innerhalb eines kurzen Fensters (oft Sekunden bis wenige Minuten, je nach Synchronisationsansatz) zeigt Mayas Suche dieses Ticket nicht mehr. Hat sie die Detailseite geöffnet und aktualisiert, prüft die App die Berechtigung neu und das Ticket verschwindet.
Das ist das gewünschte Verhalten: schnelles Tippen und schnelle Ergebnisse, ohne dass Daten über Zählungen, Snippets oder veraltete Indexeinträge verraten werden.
Berechtigungsbewusste globale Suche ist erst „fertig", wenn die langweiligen Ränder sicher sind. Viele Lecks entstehen an Stellen, die harmlos wirken: Autocomplete, Ergebniszähler und Exporte.
Bevor Sie live gehen, prüfen Sie diese Punkte mit echten Daten, nicht mit Beispielen:
Erstellen Sie eine kleine Rollenmatrix (Rollen x Entitäten) und einen Datensatz mit absichtlich kniffligen Fällen: geteilte Datensätze, kürzlich entzogener Zugriff und tenant-übergreifende Lookalikes.
Testen Sie in drei Durchläufen: (1) Rollenmatrix-Tests, in denen Sie verifizieren, dass abgelehnte Datensätze niemals in Ergebnissen, Vorschlägen, Zählern oder Exporten auftauchen; (2) "Versuchen Sie, es kaputt zu machen"-Tests, in denen Sie IDs einfügen, nach E-Mail oder Telefon suchen und Teiltreffer ausprobieren, die nichts zurückgeben sollten; (3) Timing- und Cache-Tests, in denen Sie Berechtigungen ändern und bestätigen, dass Ergebnisse schnell aktualisiert werden, ohne veraltete Vorschläge.
Operativ planen Sie für den Tag, an dem Suchergebnisse „falsch aussehen". Protokollieren Sie den Abfragekontext (Nutzer, Rolle, Tenant) und die angewendeten Berechtigungsfilter, aber speichern Sie keine rohen sensiblen Abfragetexte oder Snippets. Für sicheres Debugging bauen Sie ein Admin-only Tool, das erklären kann, warum ein Datensatz gematcht hat und warum er erlaubt war.
Wenn Sie auf AppMaster (appmaster.io) aufbauen, ist ein praktischer Ansatz, Suche als serverseitigen Flow zu halten: modellieren Sie Entitäten und Beziehungen im Data Designer, erzwingen Sie Zugriffsregeln in Business Processes und verwenden Sie dieselbe Berechtigungsprüfung für Autocomplete, Ergebnisliste und Exporte, sodass es nur einen Ort gibt, an dem es richtig gemacht wird.
21. Jan. 2026
8 Min
20. Jan. 20268 Min
20. Jan. 20268 MinExperimentieren Sie mit AppMaster mit kostenlosem Plan.
Wenn Sie fertig sind, können Sie das richtige Abonnement auswählen.
