Autorisierte Nutzung von Multi-Profil-Browsern für QA, Agenturen und Sicherheitsteams

Die Grundregel: Trennen Sie Arbeit, die bereits erlaubt ist

Ein Browserprofil kann Cookies, Speicher, Verlauf, Erweiterungen, Berechtigungen und Einstellungen von einem anderen Arbeitskontext getrennt halten. Diese Trennung ist nützlich, wenn die zugrunde liegende Tätigkeit autorisiert ist. Sie gewährt keine Rechte an einem Konto, Dienst, Netzwerk, einer Person oder einem Datensatz.

Machen Sie vor dem Anlegen eines Profils die Autorisierungskette eindeutig:

Frage	Aufzubewahrender Nachweis
Wem gehört das System oder Konto?	Benannte Organisation und verantwortliche Kontaktperson
Wer hat die Arbeit autorisiert?	Vertrag, Leistungsbeschreibung, Ticket, Testplan oder Einsatzregeln
Welche Objekte und Konten gehören zum Umfang?	Genaue Umgebungen, Origins, Konto-IDs, Profil-IDs und Ausschlüsse
Welche Aktionen sind erlaubt?	Lesen, veröffentlichen, testen, zurücksetzen, einladen, exportieren, automatisieren oder andere benannte Vorgänge
Welche Daten dürfen verwendet werden?	Klassifizierungen für synthetische, Test-, kundenseitig bereitgestellte, persönliche und vertrauliche Daten sowie deren Aufbewahrung
Wann gilt die Erlaubnis?	Beginn, Ablauf, Wartungsfenster und Widerrufsweg
Was erfordert eine Freigabe?	Extern sichtbare, destruktive, massenhafte, zugriffsändernde oder kostenverursachende Aktionen
Wann muss die Arbeit beendet werden?	Unklarer Umfang, unerwartete Daten, Dienstauswirkungen, widerrufener Zugriff oder unbekanntes Ergebnis

Technischer Zugriff ist kein Erlaubnisnachweis. Eine gespeicherte Sitzung kann weiter funktionieren, nachdem ein Teammitglied ausgeschieden ist oder ein Kunde die Zusammenarbeit beendet hat. Die bedienende Person muss aufhören, sobald die Berechtigung entzogen wird, auch wenn der Browser das Konto weiterhin öffnen kann.

Ein gemeinsames Betriebsmuster

Dieselben fünf Phasen machen unterschiedliche Multi-Profil-Abläufe nachvollziehbar.

1. Autorisieren

Benennen Sie Systemverantwortliche, gegebenenfalls Kunden, Bedienpersonen, den erlaubten Zweck, Objekte, Konten, Aktionen, Zeiträume, Datenverarbeitung, Freigaben und Abbruchbedingungen. Ein Kunde kann Arbeit an Objekten autorisieren, die er kontrolliert; er kann keine Rechte an einem anderen Dienst gewähren, die er selbst nicht besitzt.

2. Vorbereiten

Erstellen Sie ein Profil für die konkrete Umgebung, den Kunden, die Rolle oder den Testfall. Wenden Sie nur die benötigten Erweiterungen, Proxys, Sprachangaben, Berechtigungen und Zugangsdaten an. Bevorzugen Sie vom Dienst unterstützte Delegation und persönliche Benutzerkonten gegenüber gemeinsam genutzten Passwörtern oder kopiertem Sitzungsschlüsselmaterial.

3. Ausführen

Nutzen Sie für veränderlichen Zustand jeweils eine verantwortliche Person oder Arbeitslast. Erzwingen Sie Grenzen für Umfang, Ziel, Parallelität, Rate und Kosten. Zeigen Sie Änderungen mit hohen Auswirkungen vorab an und binden Sie die Freigabe an das genaue Ziel und die konkrete Aktion.

4. Dokumentieren

Dokumentieren Sie handelnde Person, delegierte Arbeitslast, Profilverweis, Aktion, Freigabe, Zeit, Ziel, Ergebnis und relevante Versionen. Die Protokollierungsempfehlungen von OWASP empfehlen zu erfassen, wann, wo, wer und was, zugleich aber Protokolle zu schützen und technische Geheimnisse auszuschließen. Halten Sie ungeschützte Cookies, Passwörter, Token, Proxy-Zugangsdaten, Seiteninhalte und unnötige personenbezogene Daten aus gewöhnlichen Protokollen heraus.

5. Wiederherstellen und abschließen

Beenden Sie das Profil sauber, prüfen Sie den erwarteten Zustand, bewahren Sie nur genehmigte Nachweise auf, widerrufen Sie temporären Zugriff und geben Sie das Profil an die verantwortliche Person zurück. Endete die Ausführung in unbekanntem Zustand, untersuchen Sie ihn vor einem erneuten Versuch. Stellen Sie eine bekanntermaßen intakte Kopie wieder her oder isolieren Sie beschädigten Zustand, statt unbemerkt fortzufahren.

QA- und Lokalisierungsteams

Sinnvolle Profilgrenzen

QA-Teams können separate Profile verwenden für:

• anonyme, angemeldete und neu registrierte Zustände;
• Administrator-, Redaktions-, Support- und gewöhnliche Benutzerrollen;
• Entwicklung, Staging und ausdrücklich genehmigte produktive Smoke-Tests;
• Kombinationen aus Sprache, Zeitzone, Farbschema und Berechtigungen;
• Konfigurationen mit und ohne Erweiterungen;
• einen sauberen Erststartzustand und einen bewusst aktualisierten dauerhaften Zustand; sowie
• mehrere Teilnehmende in einem genehmigten Mehrbenutzerszenario.

Playwright verwendet isolierte Browserkontexte, damit Tests getrennte Cookies, Local Storage und Session Storage erhalten, und unterstützt mehrere Kontexte für Szenarien mit mehreren Nutzenden. Die Dokumentation zu Browserkontexten erklärt zudem, weshalb ein sauberer Ausgangszustand die Übernahme früherer Fehler verringert. Das ist ein hilfreiches Testmuster; ein dauerhaftes Produktprofil und ein temporärer Automatisierungskontext können jedoch unterschiedlichen Zustand bewahren. Dokumentieren Sie, welches Modell Ihr Test tatsächlich verwendet.

Lokalisierungs- und Regionaltests

Eine reproduzierbare Lokalisierungsmatrix kann deklarierte Sprache, Zeitzone, Viewport, Eingabemethode, Textrichtung und Testdaten variieren. Playwright dokumentiert in seiner Emulationsanleitung die Emulation von Sprache, Zeitzone, Geolocation, Farbschema und anderen Kontexteinstellungen. Behandeln Sie Emulation als kontrollierte Eingabe, nicht als Beweis dafür, dass der Test jedes Gerät, Netzwerk, jede Rechtsregion oder die Erfahrung realer Nutzender repräsentiert.

Verwenden Sie einen Proxy oder eine Geolocation-Eingabe nur, wenn Netzbetreiber, Zieldienst und Testvereinbarung dies erlauben. Ein geänderter Netzwerkweg schafft weder einen Anspruch auf regional beschränkte Inhalte noch die Erlaubnis, eine Zugriffsentscheidung des Dienstes zu umgehen.

Die W3C-Kurztipps zur Internationalisierung empfehlen UTF-8, deklarierte Dokumentsprache, lokale Datenformate, sichtbare Sprachnavigation, passende Rechts-nach-links-Richtung und Validierung. Überführen Sie diese Grundsätze in beobachtbare Prüfungen, zum Beispiel:

• Die gewählte Sprache bleibt bei Navigation und erneuter Authentifizierung erhalten.
• Datum, Uhrzeit, Zahlen, Namen, Adressen, Sortierung und Pluralformen verwenden die vorgesehene Spracheinstellung.
• Übersetzter Text kann sich ausdehnen, ohne abgeschnitten zu werden oder Steuerelemente zu verdecken.
• Gemischtsprachige und rechts-nach-links gesetzte Inhalte bewahren Lese- und Fokusreihenfolge.
• Formulare akzeptieren und liefern die vorgesehenen Zeichensätze.
• Links und Fehlermeldungen bleiben ohne Abhängigkeit von maschineller Übersetzung verständlich.

Tests der Barrierefreiheit

Trennen Sie Zustände der Barrierefreiheit, wenn dies die Reproduzierbarkeit verbessert, reduzieren Sie Barrierefreiheit aber nicht auf eine Profilvorgabe. Testen Sie Tastaturbedienung, Fokus, Zoom, Screenreader, Kontrasteinstellungen, reduzierte Bewegung, Fehler und barrierefreie Authentifizierung anhand der WCAG 2.2. Die Bewertungsübersicht des W3C hält fest, dass Werkzeuge helfen, aber kein Werkzeug allein feststellen kann, ob eine Website barrierefrei ist; eine sachkundige menschliche Bewertung bleibt erforderlich.

QA-Ablaufplan: Prüfung eines regionalen Releases

Autorisierung: Die produktverantwortliche Person genehmigt die Staging-Origin, zwei Testrollen, unterstützte Sprachen, Testzeiträume und synthetische Konten.

Profile: Ein sauberes Profil pro Rollen- und Sprachpaar sowie ein separates Upgradeprofil, das den Zustand des vorherigen Releases bewahrt.

Aktionen: Über den unterstützten Testweg authentifizieren, Navigations- und Formularprüfungen ausführen, Sprach- und Barrierefreiheitsverhalten untersuchen, genehmigte Testartefakte erfassen und jedes Profil sauber beenden.

Nachweise: Build-ID, Browserversion, Sprach- und Zeitzoneneingaben, Rolle, Testergebnis, geschwärzte Fehlerdetails und Artefaktverweise.

Abbruchbedingungen: Unerwartete produktive Origin, echte Kundendaten, Berechtigung außerhalb der zugewiesenen Rolle, Dienstbeeinträchtigung oder Aufforderung zum Export aktiven Sitzungszustands.

Agenturen und Kundenarbeit

Sinnvolle Profilgrenzen

Agenturen können Arbeit nach Kunde, juristischer Person, Marke, Umgebung, Zieldienst und Bedienrolle trennen. Das kann versehentliche kundenübergreifende Aktionen verringern und Übergaben eindeutiger machen. Die stärkste Grenze verbindet Profiltrennung mit den eigenen Organisations-, Rollen- und Delegationsfunktionen des Zieldienstes.

Ein Agenturablauf sollte Folgendes besitzen:

• eine aktuelle Kundenautorisierung und eine benannte kundenseitig verantwortliche Person;
• sofern verfügbar, einen vom Dienst unterstützten Benutzer oder eine delegierte Rolle für jede Bedienperson;
• eine für das Profil verantwortliche Person und einen dokumentierten Übergabezustand;
• kundenspezifische Ordner, Tags, Erweiterungen, Proxys und Aufbewahrungsregeln;
• Freigaben für Veröffentlichung, Zugriffsänderungen, Massenaktionen, Löschung und Ausgaben;
• einen für die zuständigen Kunden- oder Kontoverantwortlichen sichtbaren Auditverlauf;
• einen schnellen Prozess für Widerruf, Geräteverlust, Personalwechsel und Vertragsende; sowie
• einen vor dem Onboarding vereinbarten Export- und Löschplan.

Verwenden Sie ungeschützte Zugangsdaten nicht als Mittel zur Zusammenarbeit. Wenn Test- oder Automatisierungswerkzeuge authentifizierten Zustand speichern, schützen Sie ihn wie einen Zugangsnachweis. Die Authentifizierungsanleitung von Playwright warnt, dass gespeicherter Browserzustand Cookies und Header enthalten kann, mit denen sich das Konto nachahmen lässt, und deshalb nicht in Repositories eingecheckt werden sollte.

Agentur-Ablaufplan: genehmigte Inhaltsübergabe

Autorisierung: Die Leistungsbeschreibung benennt das kundenseitig kontrollierte Inhaltssystem, die Marke, Bedienpersonen, erlaubte Inhaltsvorgänge, die für Freigaben verantwortliche Person und das Enddatum der Zusammenarbeit.

Profile: Ein Kundenarbeitsbereich mit getrennten Redaktions- und Veröffentlichungsprofilen. Jede Person nutzt eine eigene Dienstidentität; das Veröffentlichungsprofil ist kein gemeinsam genutzter Passworttresor.

Aktionen: Die redaktionell tätige Person erstellt einen Entwurf, das System zeichnet Vorschau und Inhaltsrevision auf, die benannte kundenseitige Freigabeperson genehmigt genau diese Revision und die veröffentlichende Person reicht sie einmal ein.

Nachweise: Handelnde Person, Kunde, Profil, Inhaltsrevision, Freigabeverweis, Ziel, Übermittlungsergebnis und Zeit. Inhaltswerte werden nur aufbewahrt, soweit Kundenvereinbarung und Datenrichtlinie dies erlauben.

Wiederherstellung: Geht die Antwort nach dem Einreichen verloren, prüfen Sie vor einem erneuten Versuch das Zielsystem. Endet die Zusammenarbeit, widerrufen Sie den Zugriff, geben genehmigte Datensätze zurück und löschen oder bewahren verbleibende Profildaten gemäß Vereinbarung auf.

Weiterhin unzulässige Handlungen

Kundenarbeit rechtfertigt nicht:

• das Anlegen falscher Konten, Bewertungen, Interaktionen oder Identitäten;
• Spam oder unaufgeforderte Massennachrichten;
• Zugriff auf ein Konto, nachdem der Kunde oder Dienstinhaber die Erlaubnis widerrufen hat;
• Kauf, Sammlung, Wiedergabe oder Freigabe gestohlener Zugangsdaten oder Sitzungen;
• die Verschleierung der handelnden Person gegenüber einer autorisierten Untersuchung;
• die Umgehung von Plattformdurchsetzung zur Wiederherstellung unzulässigen Zugriffs; oder
• Tätigkeiten außerhalb der Rechte des Kunden, des geltenden Rechts oder der Dienstbedingungen.

Weist eine Plattform eine Aktion zurück, untersuchen Sie Autorisierung und Geschäftsprozess. Behandeln Sie Profil, Proxy oder Automatisierungsweg nicht als Erlaubnis, die Entscheidung zu umgehen.

Sicherheits- und Incident-Response-Teams

Schriftlicher Umfang zuerst

Sicherheitsteams benötigen mehr als eine allgemeine Aufforderung, „die Website zu testen“. NIST SP 800-115 bietet Empfehlungen für Planung und Durchführung technischer Sicherheitstests, Analyse von Erkenntnissen und Entwicklung von Abhilfemaßnahmen. NIST definiert Einsatzregeln als vor dem Test festgelegte Beschränkungen, die dem Team die Befugnis zu bestimmten Tätigkeiten erteilen.

Die Einsatzregeln sollten benennen:

• genaue Hosts, Anwendungen, APIs, Mandanten und Konten im Umfang;
• ausdrücklich ausgeschlossene Drittanbieterdienste und Produktivabhängigkeiten;
• erlaubte Verfahren und Werkzeuge;
• gegebenenfalls Testausgangsnetze oder -geräte;
• Grenzen für Zeitplan, Rate, Parallelität und Dienstauswirkungen;
• Testkonten, Rollen und genehmigte Daten;
• verbotene Handlungen wie Persistenz, Social Engineering, destruktive Änderungen oder Denial of Service;
• Umgang mit Nachweisen, Verschlüsselung, Zugriff, Aufbewahrung und Vernichtung;
• Kontaktpersonen für Vorfälle und Notfälle;
• sofortige Abbruchbedingungen; sowie
• Erwartungen an Berichterstattung, Behebung, erneuten Test und Offenlegung.

Erfordert der Nachweis Zugriff oder Auswirkungen über diese Regeln hinaus, stoppen Sie und holen Sie vor dem Fortfahren eine schriftliche Autorisierung ein.

Sinnvolle Profilgrenzen

Innerhalb einer autorisierten Bewertung können separate Profile Folgendes isolieren:

• Kunde A von Kunde B;
• Testidentitäten von gewöhnlicher privater Browsernutzung;
• jede Testrolle oder jeden Mandanten;
• passive Validierung von genehmigten aktiven Tests;
• einen sauberen Ausgangszustand von verändertem Testzustand;
• Nachweise der Vorfallreaktion von fortgesetzter betrieblicher Arbeit; und
• den Zustand eines erneuten Tests vom ursprünglichen Befund.

Verwenden Sie Profile zum Schutz von Umfang und Nachweisen, nicht um Herkunft oder Zweck eines Tests zu verbergen. Wechseln Sie Profile, Netzwerke oder Identitäten nicht, um Ratenbegrenzungen, Sperren oder andere Kontrollen zu umgehen, sofern der Systeminhaber dieses Verhalten nicht ausdrücklich in die Einsatzregeln aufgenommen hat.

Sicherheits-Ablaufplan: autorisierte Regression der Zugriffskontrolle

Autorisierung: Der Systeminhaber benennt die Staging-Anwendung, zwei Testmandanten, gewöhnliche und administrative Testrollen, erlaubte Anfragen, Ratenbegrenzung, Zeitfenster und Notfallkontakt. Produktion und Identitätsinfrastruktur Dritter sind ausgeschlossen.

Profile: Ein sauberes Profil für jede genehmigte Rolle und jeden Mandanten. Jedes enthält synthetische Testdaten und eine vom Dienst ausgegebene Testidentität.

Aktionen: Prüfen Sie, dass jede Rolle ihre erwarteten Ressourcen erreicht, und führen Sie dann die genehmigten Negativfälle aus, die bestätigen, dass anderen Rollen und Mandanten der Zugriff verweigert wird. Verwenden Sie nur die zur Reproduktion eines Befunds nötigen Anfragen.

Nachweise: Anwendungs- und Browserversionen, Testfall, handelnde Person, Mandanten- und Rollenverweise, Anfragekorrelations-IDs, geschwärzte Antwortnachweise, Zeit und Ergebnis. Bewahren Sie keine bei der Prüfung angetroffenen fremden Datensätze auf.

Abbruchbedingungen: Personenbezogene oder produktive Daten erscheinen, der Dienst wird instabil, ein Test verlässt den benannten Mandanten, Zugangsdaten außerhalb des Testsatzes werden offengelegt oder der Systeminhaber widerruft die Autorisierung.

Wiederherstellung: Stoppen Sie aktive Anfragen, informieren Sie die benannte Kontaktperson, bewahren Sie minimale geschützte Nachweise auf, widerrufen Sie Testzugangsdaten, stellen Sie Testzustand wieder her und dokumentieren Sie, ob ein erneuter Test sicher ist.

Erlaubnis hat mehrere Ebenen

Nutzen Sie diese Entscheidungstabelle bei unklarer Autorisierung:

Situation	Entscheidung
Ihr Unternehmen besitzt das Staging-System, der Testplan nennt Konto und Aktionen, und die bedienende Person hat die zugewiesene Rolle	Innerhalb der dokumentierten Grenzen fortfahren
Ein Kunde beauftragt eine Agentur über die unterstützten Rollen des Dienstes mit der Kontoverwaltung, und der Vertrag deckt die Arbeit ab	Mit benanntem Zugriff sowie Freigabe-, Audit- und Offboarding-Kontrollen fortfahren
Ein Kunde verlangt Zugriff auf ein Konto eines Drittanbieters, das er weder besitzt noch kontrolliert	Stoppen; der Kunde kann diese Erlaubnis nicht erteilen
Eine Sicherheitskontaktperson ermutigt allgemein, nennt aber weder Objektliste noch Testumfang	Stoppen; schriftliche Einsatzregeln einholen
Eine gültige Sitzung bleibt nach Ausscheiden einer Person bestehen	Stoppen und widerrufen; der technische Zugriff hat die Autorisierung überdauert
Ein Test findet echte Zugangsdaten oder personenbezogene Daten außerhalb des genehmigten Datensatzes	Stoppen, Zugriff minimieren, Nachweise schützen und die benannte Kontaktperson informieren
Eine Plattform blockiert eine Aktion und als Reaktion sollen Profile oder Proxys gewechselt werden	Stoppen; Isolation nicht zur Umgehung der Durchsetzung einsetzen
Ein Arbeitsablauf erzeugt falsche Interaktionen, Spam, Betrug, Phishing, Diebstahl von Zugangsdaten oder unbefugten Zugriff	Verboten

Was Profiltrennung nicht belegen kann

Eine Profilgrenze kann versehentliche Zustandsvermischung verringern. Sie kann für sich allein nicht belegen, dass:

• die bedienende Person autorisiert ist;
• die Kontoidentität echt ist;
• der Browser ein separates physisches Gerät darstellt;
• eine simulierte Spracheinstellung eine ortsansässige Person oder einen rechtmäßigen regionalen Anspruch repräsentiert;
• ein Proxy Zugriff von seinem scheinbaren Standort autorisiert;
• Erweiterungen oder Endgerät vertrauenswürdig sind;
• eine Website die Sitzung akzeptiert; oder
• ein Sicherheitstest innerhalb des Umfangs liegt.

Behandeln Sie das Profil als eine Kontrolle innerhalb eines größeren Systems aus Identität, Autorisierung, Datenverarbeitung, Audit, Wiederherstellung, Verträgen und menschlicher Prüfung. Wird eine dieser Ebenen unklar, bedeutet sicherer Betrieb, die Arbeit zu stoppen und die Unklarheit vor dem Fortfahren zu klären.