Google Workspace erhöht automatisch die Sicherheit der Onlinesitzungen Ihrer Nutzer, indem Anmeldedaten für gerätegebundene Sitzungen (Device Bound Session Credentials, DBSC) verwendet werden. DBSC soll Session-Hijacking verhindern, das auch als Cookie-Diebstahl bezeichnet wird.
Diese Art von Cyberangriff erfolgt, wenn eine unbefugte Partei die Kontrolle über die aktive Websitzung eines Nutzers erlangt, indem sie das Sitzungscookie stiehlt – oft durch Malware auf dem Gerät des Nutzers. Ein Sitzungscookie ist eine kleine Datei, die die eindeutige Sitzungskennung enthält, die von der Website während der Anmeldung ausgegeben wird. Durch Vorlage dieses gestohlenen Cookies kann sich der Angreifer als der legitime Nutzer ausgeben und die authentifizierte Sitzung fortsetzen.
DBSC bindet die Sitzung eines Nutzers an sein jeweiliges Gerät. Dadurch wird es für Angreifer schwieriger, gestohlene Cookies auf anderen Geräten zu verwenden. Dadurch wird eine hardwarebasierte Sicherheitsgrenze geschaffen, die das Risiko eines unbefugten Zugriffs auf Nutzerkonten verringert und sensible Daten schützt. DBSC ist standardmäßig für alle Workspace-Konten aktiviert. Administratoren müssen nichts weiter tun, um diese Schutzmaßnahme zu aktivieren.
Voraussetzungen für die Verwendung von DBSC
- Chrome-Browser: Version 146 oder höher für Windows. Weitere Informationen dazu finden Sie unter Google Chrome aktualisieren.
- Hardwaresicherheit:Erfordert hardwarebasierte Sicherheitsfunktionen, um die kryptografischen Schlüssel, die zum Binden der Sitzung an das Gerät verwendet werden, sicher zu speichern. Unter Windows ist dies ein Trusted Platform Module (TPM), das auf den meisten Geräten mit Windows 11 standardmäßig vorhanden ist. In der Dokumentation des Geräteherstellers finden Sie Informationen zu den Hardwarefunktionen.
So wird DBSC-Schutz angewendet
DBSC-Schutz wird automatisch angewendet, wenn das Gerät und der Browser eines Nutzers die erforderlichen technischen Anforderungen erfüllen. In einigen Fällen bleiben Sitzungen möglicherweise ungebunden. Häufige Gründe:
- Nicht unterstützte Umgebung: Probleme mit dem Betriebssystem, der Browserversion oder der Hardwaresicherheit des Nutzers (z. B. ein TPM unter Windows).
- Vorhandene Sitzungen: DBSC-Schutz gilt nur für neue Sitzungen. Nutzer, die bereits angemeldet waren, als DBSC aktiviert wurde, müssen sich ab- und wieder anmelden, um ihre Sitzung zu binden.
- Browseränderungen: Bestimmte Browsererweiterungen oder manuelle Änderungen an Cookies können verhindern, dass DBSC richtig funktioniert.
DBSC mit dem kontextsensitiven Zugriff erzwingen
Beschränkt auf Desktop-Web-Apps und nicht für mobile Apps oder APIs anwendbar
Sie können die Sicherheit weiter erhöhen, indem Sie festlegen, dass Nutzer für den Zugriff auf bestimmte Google Workspace-Apps DBSC benötigen. Wenn Sie DBSC erzwingen, werden Nutzer aufgefordert, sich noch einmal anzumelden, wenn das System eine Abweichung von einer zuvor eingerichteten gebundenen Sitzung erkennt. Durch diese erneute Authentifizierung kann das System versuchen, eine neue, sichere Bindung herzustellen. Nutzer auf nicht unterstützten Plattformen werden daran gehindert, auf die geschützte App zuzugreifen. Diese Sicherheitsmaßnahme wird über den kontextsensitiven Zugriff konfiguriert.
So richten Sie die Durchsetzung von DBSC ein:
- Folgen Sie der Anleitung unter Zugriff auf Apps nur über DBSC-gebundene Sitzungen zulassen, um eine benutzerdefinierte Zugriffsebene zu erstellen.
- Weisen Sie den Apps, auf die nur über DBSC-gebundene Sitzungen zugegriffen werden soll, die Zugriffsebene im Monitormodus zu, um die Erzwingung zu simulieren, ohne den Nutzerzugriff zu blockieren.
- Nachdem Sie die Auswirkungen bewertet haben, weisen Sie Zugriffsebenen im Aktivmodus zu, um den Zugriff nur über sitzungsbasierte Geräte zu erzwingen. Weitere Informationen finden Sie unter Kontextsensitiven Zugriff bereitstellen.
Die Durchsetzung von DBSC erfolgt nicht sofort. Nach der Anmeldung eines Nutzers gibt es also einen Kulanzzeitraum, bevor die Durchsetzung erfolgt. Dieses Design berücksichtigt potenzielle vorübergehende Bindungsprobleme. Nach der Bindung prüft das System regelmäßig, ob Nutzer, die auf die angegebenen Apps zugreifen, Sitzungen haben, die an DBSC gebunden sind. Bei jeder erneuten Authentifizierung wird diese Kulanzfrist zurückgesetzt und DBSC wird während der erneuten Authentifizierung nicht erzwungen.
DBSC-Schutz und Sitzungsprobleme untersuchen
Mit dem Sicherheitsprüftool können Sie den DBSC-Schutz überwachen und Probleme mit Sitzungsunterbrechungen beheben. Es gibt zwei Logquellen für DBSC-Aktivitäten:
- Nutzer-Protokollereignisse: Hier können Sie die Bindung von Zugriffstokens an Nutzergeräte überwachen.
- Log-Ereignisse bei der Zugriffsbewertung: Hier können Sie den Status bestimmter Cookies prüfen.
Hinweis:DBSC-Protokollereignisse sind nur für das primäre Konto sichtbar, wenn mehrere Nutzerkonten im selben Chrome-Browserprofil angemeldet sind.
Schritt 1: Nach DBSC-Aktivitäten in Nutzer-Protokollereignissen suchen
Mit dieser Datenquelle können Sie feststellen, ob DBSC Schlüssel erfolgreich an Nutzergeräte bindet und Sitzungen validiert.
So prüfen Sie, ob DBSC Schlüssel bindet:
-
Öffnen Sie in der Admin-Konsole im Menü
Sicherheit
Sicherheitscenter
Prüftool.Hierfür ist die Administratorberechtigung Sicherheitscenter erforderlich.
- Wählen Sie unter Datenquelle die Option Nutzer-Protokollereignisse aus.
- Klicken Sie auf Bedingung hinzufügen.
- Wählen Sie für Attribut die Option Ereignis Ist als Operator DBSC-Schlüsselbindung als Ereignis aus.
- Klicken Sie auf Suchen.
- Sehen Sie sich in der Ergebnistabelle die Spalte Ereignisstatus an:
- Erfolgreich: Der DBSC-Schutz ist für den Nutzer aktiviert und die Sitzung ist geschützt.
- Fehler: Die DBSC-Bindung war nicht erfolgreich und der Schutz ist für den Nutzer nicht aktiviert.
- Keine Ergebnisse: Für diese Nutzersitzung wurde kein DBSC-Schutz versucht.
So prüfen Sie, ob DBSC Sitzungen validiert:
-
Öffnen Sie in der Admin-Konsole im Menü
Sicherheit
Sicherheitscenter
Prüftool.Hierfür ist die Administratorberechtigung Sicherheitscenter erforderlich.
- Klicken Sie auf Bedingung hinzufügen.
- Wählen Sie für Attribut die Option Ereignis Ist als Operator DBSC-Schlüsselvalidierung als Ereignis aus.
- Klicken Sie auf Suchen.
- Sehen Sie sich in der Ergebnistabelle die Spalte Ereignisstatus an:
- Erfolgreich: Das Cookie wurde erfolgreich validiert.
- Fehlgeschlagen: Die DBSC-Validierung ist fehlgeschlagen. Klicken Sie auf den Status, um zusätzliche Informationen wie einen Fehlercode zu erhalten.
Eine fehlgeschlagene Validierung bedeutet nicht unbedingt, dass die Sitzung des Nutzers unterbrochen wird. Wenn mehrere Validierungen nacheinander fehlschlagen, kann es zu Unterbrechungen kommen.
Schritt 2: Log-Ereignisse bei der Zugriffsbewertung auf verweigerte Zugriffe prüfen
Mit dieser Datenquelle können Sie ermitteln, ob der Zugriff auf das Cookie eines Nutzers verweigert wurde.
-
Öffnen Sie in der Admin-Konsole im Menü
Sicherheit
Sicherheitscenter
Prüftool.Hierfür ist die Administratorberechtigung Sicherheitscenter erforderlich.
- Wählen Sie für Datenquelle die Option Log-Ereignisse bei der Zugriffsbewertung aus.
- Klicken Sie auf Bedingung hinzufügen.
- Wählen Sie für Attribut die Option Ereignis Ist als Operator Cookie-Validierungsanfrage ablehnen als Ereignis aus.
- Klicken Sie auf Suchen.
- Klicken Sie in der Ergebnistabelle in der Spalte Ereignisstatus auf Abgelehnt oder in der Spalte Beschreibung auf den Link, um eine Seitenleiste zu öffnen, in der Sie die folgenden Gründe für fehlgeschlagene Versuche sehen können:
- DBSC_BOUND_COOKIE_MISSING
- DBSC_BOUND_COOKIE_CORRUPTED
- DBSC_BOUND_COOKIE_EXPIRED
Protokollereignisse werden nach Sitzung gruppiert. Um das Logvolumen zu verwalten, wird nur ein Ereignis pro Stunde für jede eindeutige Sitzung und jeden Typ eines fehlgeschlagenen Versuchs aufgezeichnet. Andere Versuche mit denselben Details werden in dieser Stunde nicht aufgezeichnet.
Schritt 3: Untersuchen, ob Sitzungsunterbrechungen durch DBSC verursacht werden
Nutzer können aus verschiedenen Gründen abgemeldet werden, z. B. aufgrund von Sitzungslängenbeschränkungen, von Administratoren definierten Richtlinien oder Netzwerkproblemen. Eine Abmeldung deutet nicht immer auf ein DBSC-Problem hin. Bestimmte Logfolgen können jedoch helfen, potenzielle DBSC-bezogene Aktivitäten oder Fälle zu identifizieren, in denen das System eine kompromittierte Sitzung blockiert hat.
Anhand dieser Punkte können Sie DBSC-bezogene Aktivitäten erkennen:
- Log-Sequenzen prüfen: Wenn Sie erfolglose DBSC-Schlüsselvalidierungen gefolgt von einer Deny Cookie Validation Request (Anfrage zur Cookie-Validierung ablehnen) finden, könnte DBSC die Ursache für die Abmeldung des Nutzers sein.
- Auswirkungen auf den Nutzer: Um das Konto zu schützen, muss sich ein Nutzer noch einmal anmelden, wenn beim Verknüpfungsvorgang ein Fehler auftritt.
Google, Google Workspace und zugehörige Warenzeichen und Logos sind Marken von Google LLC. Alle anderen Unternehmens- und Produktnamen sind Marken der jeweiligen Unternehmen.