Ein Assessment-Portal kann für einen Kunden einwandfrei funktionieren und trotzdem eine wichtige Frage offenlassen: Was passiert, wenn eine zweite Organisation damit arbeitet?
Stellen Sie sich vor, eine Beratung verlagert Nachweisanfragen und Prüfungen in eine gemeinsame Anwendung. Jeder Kunde erhält einen Zugang. Berater arbeiten an mehreren Mandaten. Eine prüfende Person darf ein Assessment freigeben, soll aber die zugrunde liegenden Antworten nicht ändern. Das sind unterschiedliche Berechtigungen, auch wenn alle dieselben Ansichten verwenden.
Machen Sie daraus vor der ersten Kundeneinladung eine Vorführung, die Sie gemeinsam mit Ihrem Entwicklungspartner prüfen können. Verwenden Sie ausschließlich erfundene Organisationen und künstliche Nachweise. Der folgende Ablauf hilft bei der Abnahme einzelner Zugriffsregeln. Er ersetzt keine vollständige Sicherheitsprüfung.
Legen Sie die Regel vor der Rolle fest
„Kunden sehen nur ihre eigenen Daten“ ist ein Anfang. Offen bleibt, ob ein Mitarbeiter alle Assessments seiner Organisation sehen darf, ob externe Mitwirkende Nachweise herunterladen können und wer weitere Personen einladen darf.
Halten Sie für einen Assessment-Ablauf vier Dinge fest: die Organisation der Person, ihre Zuordnung zum Auftrag, das betroffene Objekt und die erlaubte Aktion. Eine mögliche Regel lautet: „Eine prüfende Person beim Kunden darf zugewiesene Assessments lesen und freigeben, aber weder Antworten bearbeiten noch Kollegen einladen.“ Ob diese Regel zu Ihrer Leistung passt, entscheidet Ihr Team.
Trennen Sie Anmeldung und Berechtigung. Die Anmeldung stellt die Identität fest; die Autorisierung bestimmt, was diese Identität tun darf. OWASP empfiehlt, nur notwendige Rechte zu vergeben und Berechtigungen bei jeder Anfrage zu prüfen. Eine ausgeblendete Schaltfläche ersetzt keine Prüfung auf dem Server. [1]
Lassen Sie zwei erfundene Organisationen vorführen
Bereiten Sie eine Testumgebung mit zwei vollständig erfundenen Organisationen vor. Jede erhält ein klar unterscheidbares Assessment und eine künstliche Nachweisdatei. Hinzu kommen eine bearbeitende und eine prüfende Person beim Kunden sowie ein Berater mit bewusst begrenzter Zuordnung. Vereinbaren Sie die erwarteten Ergebnisse vor der Vorführung.
Bitten Sie Ihren Entwicklungspartner, fünf Situationen durchzugehen:
- Erlaubte Zugriffe funktionieren. Die bearbeitende Person öffnet das Assessment und die Nachweise, für die sie berechtigt ist. Die prüfende Person führt die vereinbarte Prüfung oder Freigabe aus. Halten Sie auch diese erfolgreichen Zugriffe fest: Ein defekter Download belegt keine korrekte Zugriffskontrolle.
- Die andere Organisation bleibt unzugänglich. Der Entwickler prüft in der Testumgebung mit dem Konto der ersten Organisation den Zugriff auf Datensätze und Dateizugänge der zweiten. Die Anwendung muss ihn gemäß den vereinbarten Regeln verweigern, auch wenn die Adresse des Objekts bereits bekannt ist.
- Leserechte werden nicht zu Änderungsrechten. Die prüfende Person versucht eine Aktion, die der bearbeitenden Rolle vorbehalten ist. Der Server muss sie ablehnen. Wiederholen Sie das für Einladungen, falls dafür eine eigene Rolle vorgesehen ist.
- Die Zuordnung zum Auftrag gilt. Der Berater kann das zugewiesene Assessment bearbeiten, aber kein unbeteiligtes. Soll Ihr Leistungsmodell ausdrücklich einen breiteren Zugriff erlauben, lassen Sie stattdessen diese konkrete Regel vorführen.
- Geänderte Rechte verändern das Ergebnis. Entfernen Sie eine Zuordnung oder reduzieren Sie eine Rolle. Wiederholen Sie die betreffenden Aktionen mit einer bestehenden Sitzung und nach einer erneuten Anmeldung. Notieren Sie, wann die Änderung greift und ob das Ihre Anforderung erfüllt.
Der OWASP-Testleitfaden unterscheidet Prüfungen zwischen gleichberechtigten Nutzern und Prüfungen über Berechtigungsstufen hinweg. Der Ablauf verbindet beide Ansätze mit einem Beratungsprozess. Technische Anfragen führt der Entwickler oder ein beauftragter Tester aus; echte Kundendaten gehören nicht in diese Übung. [2]
Verfolgen Sie Nachweise über die Ansicht hinaus
Ein Portal kann Tabellen exportieren, Downloadlinks bereitstellen oder Berichte im Hintergrund erzeugen. Nehmen Sie diese Wege in die Abnahme auf. Eine übersichtliche Kundenansicht sagt wenig darüber aus, ob eine Datei über einen anderen Zugang erreichbar ist.
Legen Sie für einen Export fest, welche Organisation und welcher Auftrag dazugehören. Prüfen Sie die erzeugte Datei, nicht nur die Seite, auf der sie angefordert wurde. Fragen Sie bei einem später fertiggestellten Bericht, wie die Anwendung feststellt, ob die anfordernde Person das Ergebnis dann noch erhalten darf.
Die OWASP-Empfehlungen für Anwendungen mit mehreren Mandanten behandeln unter anderem Speicher, Zwischenspeicher und Warteschlangen. Vor der Ausstellung eines signierten Dateilinks soll der Zugriff autorisiert werden. Seine Gültigkeitsdauer muss zum vorgesehenen Verhalten beim Entzug von Rechten passen. [3]
Das ist relevant, wenn jemand ein Projekt verlässt. Ein entzogener Portalzugang holt eine bereits heruntergeladene Datei nicht zurück. Auch ein zuvor ausgestellter Downloadlink kann bis zu seinem Ablauf weiter funktionieren. Lassen Sie das tatsächliche Verhalten vorführen und eine mögliche Verzögerung dokumentieren. Versprechen Sie keinen sofortigen Entzug sämtlicher Zugriffsmöglichkeiten, wenn die Anwendung ihn nicht leisten kann.
Machen Sie das Ergebnis zum Teil der Übergabe
Bewahren Sie ein kurzes Protokoll auf: vereinbarte Regel, verwendete Konten und künstliche Datensätze, erwartetes Ergebnis, beobachtetes Ergebnis und offene Abweichungen. Fragen Sie, welche Prüfungen nach Softwareänderungen automatisch laufen.
Nehmen Sie Berechtigungsänderungen in den Betriebsablauf auf. NIST zählt das Vergeben, Ändern und Entziehen von Rechten ausdrücklich zur Berechtigungsverwaltung. [4] Vereinbaren Sie, wer eine Änderung genehmigen darf und wie sie dokumentiert wird.
Scheitert eine Prüfung, vereinbaren Sie die Korrektur und wiederholen Sie den Test, bevor Sie den betroffenen Ablauf mit Kunden nutzen. Ein bestandener Durchlauf beweist keine umfassende Sicherheit. Er liefert Nachweise für genau die Grenzen, die Sie zu prüfen vereinbart haben.
Bringen Sie eine Berechtigungsfrage ins Scoping
Wählen Sie ein Assessment aus, benennen Sie die beteiligten Rollen und halten Sie fest, wer lesen, ändern, freigeben, exportieren und teilen darf. Markieren Sie offene Entscheidungen. Damit bringen Sie einen konkreten Teil Ihrer Methodik in einen Scoping-Workshop ein: mit Grenzen, die ein Entwicklungsteam umsetzen und vorführen kann.
Browserbite entwickelt individuelle Software für Beratungsabläufe. In einem Erstgespräch lässt sich klären, ob dieser Ablauf ein geeigneter Ausgangspunkt für das Scoping ist.
Quellen
[1] OWASP, Authorization Cheat Sheet — Identität und Berechtigung, minimale Rechte und Prüfung einzelner Anfragen.
[2] OWASP Web Security Testing Guide v4.2, Testing for Bypassing Authorization Schema — horizontale und vertikale Berechtigungsprüfungen.
[3] OWASP, Multi-Tenant Security Cheat Sheet — Mandantenkontext, Dateispeicher, Warteschlangen und signierte Links.
[4] NIST SP 800-210, General Access Control Guidance for Cloud Systems (2020).
Quellen geprüft am 29. September 2026. Die Übung ist eine beispielhafte Empfehlung; sie beschreibt keinen Kunden und kein Kundenprodukt.