Browserarbeit übergeben, ohne ungeschützte Zugangsdaten zu teilen

Teams sagen häufig, sie müssten „eine Anmeldung teilen“, obwohl die tatsächliche Anforderung enger ist: einen Entwurf prüfen, einen autorisierten Shop aktualisieren, einen regionalen Fehler reproduzieren oder einen Supportablauf fortsetzen. Wer bei der Aufgabe statt beim Passwort ansetzt, erhält mehr Möglichkeiten.

Was als ungeschützte Zugangsdaten gilt

Offensichtliche Beispiele sind Passwörter, Wiederherstellungscodes, Seeds für Einmalpasswörter, private Schlüssel und Proxy-Passwörter. Browserarbeit bringt weitere, weniger sichtbare Zugangsdaten mit sich:

• Authentifizierungs-Cookies und Sitzungskennungen;
• OAuth-Zugriffs- und Aktualisierungstoken;
• Passwortmanager-Datensätze und AutoFill-Daten;
• privates Schlüsselmaterial eines Passkeys oder Zugriff auf den Authentifikator, der es besitzt;
• Zustand vertrauenswürdiger Geräte und Wiederherstellungszustand; sowie
• ein Profilarchiv, das eine dieser Kategorien enthält.

Die NIST-Empfehlung zur Sitzungsverwaltung beschreibt eine Browsersitzung als Kontinuität, die auf dem Besitz eines Sitzungsgeheimnisses beruht. Das OWASP Session Management Cheat Sheet macht die betriebliche Folge deutlich: Solange ein Sitzungstoken gültig ist, kann er der stärksten Authentifizierung entsprechen, durch die er erzeugt wurde.

Ein verschlüsseltes Profilpaket legt diese Werte weder gegenüber einem Speicheranbieter noch gegenüber beiläufig Beobachtenden offen. Nachdem das Gerät einer autorisierten empfangenden Person das Profil entschlüsselt und gestartet hat, kann der Browser die Sitzung dennoch ausüben. Die Übergabe hat Befugnis übertragen, auch wenn die empfangende Person nie ein Cookie liest.

Trennen Sie die Aufgabe von der Befugnis

Formulieren Sie vor der Wahl eines Freigabemechanismus eine kurze Zugriffserklärung:

Die namentlich benannte Person A darf bis zum Zeitpunkt E von dem genehmigten Gerät D aus die Aktionen B an der Ressource C nach Freigabe- und Auditregel F ausführen.

Dieser Satz deckt unnötige Befugnisse auf. Lautet die Aufgabe „Diesen Entwurf freigeben“, ist eine vollständige Administratorsitzung übermäßig. Unterstützt der Zieldienst bereits eine prüfende Rolle, erhöht die Freigabe von Browserzustand das Risiko, ohne zusätzliche Funktionen zu bieten.

NISTs Zero Trust Architecture empfiehlt den Zugriff auf einzelne Ressourcen pro Sitzung mit den für die Aufgabe minimal benötigten Rechten. Dieser Grundsatz ist auch ohne ein Produkt mit der Bezeichnung „Zero Trust“ anwendbar. Er ist ein nützlicher Designtest für jede Browserübergabe.

Bevorzugen Sie diese Modelle in der angegebenen Reihenfolge

1. Namentlicher Zugriff beim Zieldienst

Verwenden Sie die eigenen Team-, Organisations-, Rollen-, Delegations- oder Freigabefunktionen des Website- oder Anwendungsinhabers, sofern sie vorhanden sind. Jede Person authentifiziert sich mit einem eigenen Konto und Authentifikator. Der Zieldienst kann dadurch seine Berechtigungen erzwingen, Aktionen der bedienenden Person zuordnen, Risikokontrollen anwenden und eine Person widerrufen, ohne die Zugangsdaten aller zu ändern.

Dies ist gewöhnlich das stärkste Modell, weil die Autorisierung dort liegt, wo die Aktion verstanden wird. Ein Browsermanager kann eine gemeinsam genutzte Administratorsitzung einer Website nicht zuverlässig in eine prüfende Rolle auf Websiteebene umwandeln.

Gemeinsame und Gruppenkonten verringern die Verantwortlichkeit. NIST SP 800-53 Rev. 5 empfiehlt Organisationen, ihre Nutzung zu beschränken und vor der Genehmigung ausdrückliche Bedingungen festzulegen.

2. Begrenzte Delegation durch den Zieldienst

Bietet ein Dienst OAuth oder ein anderes Delegationsprotokoll, gewähren Sie einem Client oder Akteur nur die erforderlichen Ressourcen, Aktionen und die nötige Lebensdauer. RFC 9700 empfiehlt, die Berechtigungen von Zugriffstoken auf das erforderliche Minimum und die Zielgruppe auf den vorgesehenen Ressourcenserver zu beschränken.

Bevorzugen Sie kurzlebige, widerrufbare und auf eine Zielgruppe beschränkte Gewährungen. Sendergebundene Token können eine Wiederverwendung nach Tokenverlust erschweren, helfen jedoch nicht, wenn Angreifende sowohl Token als auch zugehöriges Schlüsselmaterial erlangen. Clientgerät und Software bleiben innerhalb der Bedrohungsgrenze.

Delegation ist für Automatisierung besonders geeignet, weil ein Skript die Berechtigung für einen definierten Vorgang erhalten kann, ohne das Passwort oder die allgemeine Browsersitzung einer Person zu bekommen. Das Auditereignis sollte die auslösende Person, den delegierten Akteur, die Ressource, den Umfang und das Ergebnis benennen.

3. Vermittelte Nutzung eines gespeicherten Geheimnisses

Manche Altsysteme bieten nur gemeinsam genutzte Zugangsdaten. Ein kontrollierter Zugangsdatenbroker oder Passwortmanager kann das Kopieren verringern, indem er einem genehmigten Browserablauf erlaubt, ein Geheimnis zu verwenden, ohne es in Chat, Tickets, Dokumenten oder gewöhnlichen Anwendungsausgaben anzuzeigen.

Dies verbessert Verwahrung, Rotation und Zugriffsprüfung, behebt aber nicht das Kontomodell des Zieldienstes. Nach der Anmeldung können weiterhin alle Personen als dieselbe Websiteidentität handeln. Die entstandene Sitzung bleibt vertraulich und benötigt eigene Kontrollen für Zeitüberschreitung, Widerruf und Geräte.

Das OWASP Secrets Management Cheat Sheet empfiehlt feingranularen Zugriff, minimale menschliche Berührung von Geheimniswerten, Lebenszykluskontrollen und Audits darüber, wer ein Geheimnis angefordert und verwendet hat. Ein Browserprodukt sollte nach Möglichkeit über einen undurchsichtigen Verweis integrieren, statt zu einem weiteren allgemeinen Geheimnisspeicher zu werden.

4. Geschützte Übergabe einer Browsersitzung

Verwenden Sie ein gemeinsam authentifiziertes Profil nur, wenn der Zieldienst keine angemessene Delegation bietet und der autorisierte Arbeitsablauf tatsächlich Sitzungskontinuität erfordert. Dies ist die normale Übergabe mit dem höchsten Risiko, weil die empfangende Person die Fähigkeit erhält, über das aktive Konto zu handeln.

Zu den Mindestkontrollen gehören:

• eine ausdrücklich verantwortliche und eine genehmigte empfangende Person;
• eine festgelegte Aufgabe, Ressource und Ablaufzeit;
• ein aktiver schreibender Prozess oder ein getestetes Konfliktmodell;
• clientseitige Verschlüsselung vor jedem Cloud-Upload;
• Autorisierung des Empfangsgeräts und lokaler Schutz;
• eine Sperre gegen unklare gleichzeitige Arbeit;
• Auditereignisse für Gewährung, Download, Öffnen, vertrauliche Aktion, Schließen, Widerruf und Wiederherstellung;
• normale Schnittstellen, die geschwärzten Zustand statt Cookies oder Token zurückgeben; und
• ein Plan zum Widerruf der Sitzung beim Zieldienst.

Dieses Modell kann den Zugangsdatenwert vor beiläufigem Kopieren und Cloud-Speicher schützen. Es kann den Zieldienst nicht dazu bringen, zwei Personen zu unterscheiden, die dasselbe authentifizierte Konto verwenden. Es schützt die Sitzung außerdem weder vor Schadsoftware noch vor einer bösartigen Erweiterung oder einer autorisierten empfangenden Person, die die gewährte Befugnis missbraucht.

5. Übertragung ungeschützter Zugangsdaten

Das Kopieren eines Passworts, Cookies, Wiederherstellungscodes, Passkeys oder Profilarchivs in eine Nachricht, Tabelle, ein Ticket, Skript oder einen ungeschützten Export schafft ein dauerhaftes Geheimnis mit unklaren Kopien und schwachem Widerruf. Vermeiden Sie es.

Erfordert ein außergewöhnlicher Altprozess eine Übertragung, behandeln Sie diese nach dem genehmigten Zugangsdatenverfahren der Organisation, minimieren Empfängerzahl und Lebensdauer und rotieren oder widerrufen anschließend die Zugangsdaten. Behandeln Sie die Verschlüsselung der Nachricht nicht als Ersatz für persönliche Verantwortlichkeit oder eine Aufzeichnung jeder Kopie.

Vergleichen Sie die Befugnis, nicht nur die Bequemlichkeit

Modell	Zieldienst erkennt die bedienende Person	Umfang kann zur Aufgabe passen	Widerrufsgrenze	Wichtigstes verbleibendes Risiko
Namentlich benanntes Mitglied beim Zieldienst	Meist ja	Gewöhnlich am stärksten	Ein Mitglied oder eine Rolle entfernen	Übermäßige Berechtigungen beim Zieldienst
Begrenztes delegiertes Token	Akteur und Client können dargestellt werden	Stark bei engen Umfängen und Zielgruppen	Gewährung oder Token widerrufen	Kompromittierung von Token, Client oder Schlüssel
Vermittelte gemeinsame Anmeldung	Nach Anmeldung häufig nein	Durch das gemeinsame Konto begrenzt	Geheimnis rotieren und Sitzungen beenden	Gemeinsame Websiteidentität und aktive Sitzungen
Verschlüsselte Browsersitzung	Beim Zieldienst gewöhnlich nein	Auf Profilebene, oft breit	Freigabe und Zielsitzung widerrufen	Empfangsgerät kann die gesamte Sitzungsbefugnis ausüben
Kopie ungeschützter Zugangsdaten	Keine zuverlässige persönliche Identität	Gewöhnlich breit	Kopien finden, rotieren und Sitzungen beenden	Unbekannte Kopien und geringe Verantwortlichkeit

Die Tabelle zeigt, weshalb „Niemand kann das Passwort sehen“ kein vollständiges Erfolgskriterium ist. Entscheidend ist, wie viel Befugnis die empfangende Person ausüben kann, wie lange sie gilt und welches System sie widerrufen kann.

Passkeys verbessern die Authentifizierung, mit einem Vorbehalt zur Freigabe

WebAuthn erzeugt einen auf eine Relying Party begrenzten Public-Key-Zugangsnachweis. Die WebAuthn-Level-3-Spezifikation hält fest, dass der Authentifikator den privaten Schlüssel verwahrt und das Website-Skript signierte Ergebnisse statt des privaten Zugangsnachweises erhält. Bei korrekter Umsetzung ermöglicht dies phishingresistente Authentifizierung.

Passkeys schaffen nicht automatisch Teamrollen. Ein Zieldienst kann für jedes namentlich benannte Mitglied einen separaten Zugangsnachweis registrieren und damit individuellen Zugriff bewahren. Ein Passkey-Anbieter kann auch die Synchronisierung oder Freigabe von Authentifizierungsschlüsseln unterstützen. NIST SP 800-63B-4 erkennt dieses Modell an und benennt zugleich Risiken wie unbefugte Schlüsselnutzung, Verbreitung auf mehrere Geräte, Kompromittierung der Synchronisierungsinfrastruktur und schwierigen Widerruf.

Bevorzugen Sie für ein autorisiertes Team ein namentlich benanntes Dienstkonto und einen Authentifikator pro Person. Ist ein gemeinsam genutzter Passkey das einzige unterstützte Modell, behandeln Sie ihn als gemeinsamen Authentifikator, dokumentieren Sie mögliche empfangende Personen und verwaltete Geräte und prüfen Sie, wie der Anbieter gemeinsame Schlüssel anzeigt, widerruft und wiederherstellt. Der Zieldienst kann weiterhin jede Aktion unter einem einzigen Konto protokollieren.

Definieren Sie die Browserübergabe als Vertrag

Eine kontrollierte Übergabe sollte diese Fragen beantworten, bevor Profilzustand übertragen wird:

1. Wer handelt? Verwenden Sie eine namentlich benannte Organisationsidentität, niemals eine allgemeine Bedienerbezeichnung.
2. Wer hat autorisiert? Dokumentieren Sie verantwortliche Person oder Richtlinienentscheidung, ohne Freigabegeheimnisse zu speichern.
3. Was wird geteilt? Benennen Sie Profil und Aufgabe. Vermeiden Sie ein ungeschütztes Inventar seiner Cookies oder Zugangsdaten.
4. Was darf die empfangende Person tun? Trennen Sie Start-, Bearbeitungs-, Export-, Automatisierungs-, Freigabe- und Administratorberechtigungen.
5. Wo darf es ausgeführt werden? Beschränken Sie den Zugriff auf registrierte, für die Daten geeignete vertrauenswürdige Geräte.
6. Wie lange gilt er? Legen Sie eine Ablaufzeit fest und schließen Sie inaktive Sitzungen.
7. Dürfen zwei schreibende Prozesse handeln? Verwenden Sie einen aktiven schreibenden Prozess, sofern Konfliktverhalten nicht bewusst entwickelt und getestet wurde.
8. Was wird dokumentiert? Protokollieren Sie Akteur, Gerät, Profilverweis, Aktion, Ergebnis und Zeit. Schließen Sie Geheimniswerte und Seiteninhalte standardmäßig aus.
9. Wie wird widerrufen? Decken Sie sowohl die Browserfreigabe als auch die Sitzung beim Zieldienst ab.
10. Wie wird wiederhergestellt? Bewahren Sie eine letzte bekanntermaßen intakte Version, ohne versehentlich widerrufene Befugnisse wiederherzustellen.

Verschlüsselung gehört in diesen Vertrag. Sie schützt Daten bei Speicherung und Übertragung. Autorisierung entscheidet, wer den Entschlüsselungsweg erhalten darf. Gerätevertrauen und lokale Isolation schützen die Nutzung. Audit unterstützt Verantwortlichkeit und Untersuchungen. Keine dieser Kontrollen ersetzt die anderen.

Halten Sie Automatisierung außerhalb der Geheimnisgrenze

APIs, SDKs, Befehlszeilenwerkzeuge und Agenten müssen häufig ein Profil starten oder eine genehmigte Lebenszyklusaktion ausführen. Cookie-Werte, Passwörter, Passkeys, Proxy-Zugangsdaten oder ein ungeschütztes Profilarchiv benötigen sie nur selten.

Eine enge Schnittstelle kann einen undurchsichtigen Profil- oder Geheimnisverweis annehmen und zurückgeben:

• ob die Aktion autorisiert wurde;
• einen geschwärzten Zustand wie bereit, gesperrt, abgelaufen oder widerrufen;
• einen Prozess- oder Sitzungsverweis mit begrenzter Lebensdauer;
• einen strukturierten Fehler und Wiederherstellungsschritt; sowie
• einen Verweis auf das Auditereignis.

Sie sollte keine Zugangsdaten zurückgeben, nur weil der Aufrufende das Profil starten darf. Export, Massenfreigabe oder andere geheimnistragende Vorgänge benötigen eine separate Richtlinie und gegebenenfalls ausdrückliche Freigabe.

Inhalte von Websites und Automatisierungseingaben bleiben ebenfalls nicht vertrauenswürdig. Eine Seitenanweisung darf einen Agenten nicht dazu bringen können, Sitzungsschlüsselmaterial über Protokolle, Werkzeugausgaben, Screenshots oder einen Supportkanal offenzulegen.

Widerruf hat zwei Ebenen

Das Entfernen einer mitarbeitenden Person aus einem Browserarbeitsbereich stoppt künftigen autorisierten Zugriff über diesen Arbeitsbereich. Es beweist nicht, dass die Sitzung beim Zieldienst ungültig ist. Ein Gerät kann bereits entschlüsselten Zustand besitzen, und eine kopierte oder weiterhin laufende Sitzung kann fortbestehen.

Wenn der Zugriff regulär endet:

1. Teamgewährung widerrufen und Profillease schließen;
2. verschlüsseltes lokales Material gemäß Aufbewahrungsrichtlinie entfernen;
3. soweit unterstützt, die betreffende Sitzung beim Zieldienst beenden;
4. Mitgliedschaft oder delegierte Gewährung der Person beim Zieldienst entfernen; und
5. geschwärzte Auditnachweise für den genehmigten Zeitraum aufbewahren.

Bei Verdacht auf Kompromittierung isolieren Sie außerdem betroffene Profilversionen, widerrufen aktive Sitzungen und Token, entfernen nicht autorisierte Authentifikatoren, rotieren offengelegte gemeinsame Geheimnisse und prüfen Auditereignisse. Die Wiederherstellung eines älteren Profil-Snapshots kann ein altes Sitzungsgeheimnis zurückbringen; die Wiederherstellung muss daher den Widerrufsstatus beachten.

Verbleibende Grenzen nach einer sorgfältigen Übergabe

• Clientseitige Verschlüsselung schützt gespeicherte und übertragene Daten, ein autorisiertes Endgerät muss jedoch entschlüsseln, was der Browser benötigt.
• Eine Browsersperre steuert Parallelität auf Produktebene, nicht jede Aktion beim Zieldienst.
• Eine gemeinsam genutzte Sitzung gibt dem Zieldienst gewöhnlich eine Kontoidentität, unabhängig vom ausführlicheren Auditverlauf des Browserprodukts.
• Ein kompromittiertes Gerät oder eine kompromittierte Erweiterung kann über eine gültige Sitzung handeln, ohne ein lesbares Passwort zu extrahieren.
• Der Widerruf einer Arbeitsbereichsgewährung und einer Websitesitzung sind getrennte Vorgänge.
• Dienstbedingungen, Kundenvertrag und geltendes Recht bestimmen weiterhin, ob ein Arbeitsablauf delegiert werden darf.
• Manche Dienste bieten keinen sicheren Ersatz für individuellen Zugriff. In diesem Fall kann es verantwortungsvoll sein, den Umfang zu reduzieren oder die Übergabe abzulehnen.

RFC 6265 beschreibt Cookies als umgebungsbezogene Befugnis: Ein Browser kann sie an eine Anfrage anhängen, obwohl die anfragende Partei den Cookie-Wert nie kennt. Das ist die zentrale Grenze der Sitzungsfreigabe. Verborgene Zugangsdaten verringern die Offenlegung, nicht aber die Befugnis, die der Browser ausüben kann.