Google stellt Unterstützung für Google Sync und unsichere Apps ein

 (workspaceupdates.googleblog.com)
1 Punkte von GN⁺ 2024-01-20 | 1 Kommentare | Auf WhatsApp teilen

Google-Workspace-Updates

  • Ab dem 30. September 2024: Drittanbieter-Apps, die nur ein Passwort verwenden, um auf Google-Konten und Google Sync zuzugreifen, werden nicht mehr unterstützt.
  • Änderung: Google Workspace unterstützt keine Anmeldemethode mehr für Drittanbieter-Apps oder -Geräte, bei der der Google-Nutzername und das Passwort des Nutzers weitergegeben werden müssen.
  • Sicherheitsrisiko: Das bisherige Verfahren Less Secure Apps (LSA) erhöht das Sicherheitsrisiko, da Google-Konto-Zugangsdaten mit Drittanbieter-Apps und -Geräten geteilt werden müssen.
  • Sicherere Methode: Es sollte die Option „Mit Google anmelden“ verwendet werden. Diese nutzt OAuth-Authentifizierung und ist eine sicherere und robustere Methode, um E-Mails mit anderen Apps zu synchronisieren.

Zeitplan für die Abschaltung des LSA-Zugriffs

  • Ab dem 15. Juni 2024: Die LSA-Einstellung wird aus der Admin-Konsole entfernt und kann nicht mehr geändert werden. Nutzer, bei denen sie aktiviert ist, können sich weiterhin verbinden, aber deaktivierte Nutzer können nicht mehr auf LSA zugreifen.
  • Ab dem 30. September 2024: Der LSA-Zugriff wird für alle Google-Workspace-Konten eingestellt. CalDAV, CardDAV, IMAP, POP und Google Sync funktionieren bei einer Anmeldung nur mit Passwort nicht mehr und müssen OAuth verwenden.

Einstellung des Google-Sync-Dienstes

  • Ab dem 15. Juni 2024: Neue Nutzer können sich nicht mehr über Google Sync mit Google Workspace verbinden.
  • 30. September 2024: Bestehende Google-Sync-Nutzer können sich nicht mehr mit Google Workspace verbinden.

Hinweise für Administratoren und Endnutzer

  • Administratoren: Sie sollten auf die sicherere Zugriffsart OAuth umstellen, damit Endnutzer diese Arten von Apps weiterhin mit ihren Google-Workspace-Konten verwenden können.
  • Auswirkungen auf Mobile Device Management (MDM): Bei Organisationen, die mit einem MDM-Anbieter IMAP-, CalDAV-, CardDAV-, POP- oder Exchange-ActiveSync-(Google-Sync)-Profile konfigurieren, wird der Dienst schrittweise eingestellt.
  • Scanner und andere Geräte: Scanner oder andere Geräte, die E-Mails über SMTP oder LSA senden, sollten für OAuth konfiguriert werden, eine alternative Methode verwenden oder mit einem App-Passwort für das Gerät eingerichtet werden.

Hinweise für Endnutzer

  • E-Mail-Anwendungen: Wenn Sie eine Outlook-Version vor Outlook 2016 verwenden, sollten Sie zu Microsoft 365 wechseln oder auf Outlook für Windows oder Mac umsteigen, das OAuth-Zugriff unterstützt.
  • Kalender-Anwendungen: Wenn Sie eine App verwenden, die passwortbasiertes CalDAV nutzt, sollten Sie zu einer Methode wechseln, die OAuth unterstützt.
  • Kontakte-Anwendungen: Wenn Sie unter iOS oder macOS Kontakte über CardDAV synchronisieren und sich nur mit einem Passwort anmelden, müssen Sie das Konto entfernen und erneut hinzufügen.

Hinweise für Entwickler

  • Entwickler: Sie sollten ihre Apps aktualisieren und OAuth 2.0 als Verbindungsmethode verwenden, um die Kompatibilität mit Google-Workspace-Konten zu erhalten.

Verfügbarkeit

  • Diese Änderung betrifft alle Google-Workspace-Kunden.

Meinung von GN⁺

  • Dieses Update ist eine wichtige Maßnahme zur Stärkung der Sicherheit für Google-Workspace-Nutzer. Die Kontosicherheit durch die Verwendung von OAuth statt weniger sicherer Apps (LSA), die nur Passwörter verwenden, zu verbessern, ist in der heutigen Cybersecurity-Landschaft unverzichtbar.
  • Es betrifft sowohl Administratoren als auch Endnutzer, insbesondere Nutzer von E-Mail-, Kalender- und Kontakte-Apps, die auf die neue Authentifizierungsmethode umsteigen müssen.
  • Dieser Beitrag liefert Google-Workspace-Nutzern und Administratoren nützliche Informationen, damit sie sich auf kommende Sicherheitsupdates vorbereiten und die notwendigen Maßnahmen ergreifen können.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-01-20
Hacker-News-Kommentare

  • Ein Nutzer hat Skripte, die mit Gmail interagieren, und war von der Nachricht über das Ende der Unterstützung für "Less Secure Apps" überrascht, ist aber beruhigt, dass App-Passwörter offenbar weiterhin funktionieren. Er befürchtet, dass viel Automatisierung ausfallen würde, falls nur noch OAuth unterstützt wird. Er beklagt die Komplexität von OAuth und bewertet die Dokumentation eines Perl-Moduls positiv, die klar erklärt, wie OAuth funktioniert.

  • Wenn OAuth nicht genutzt werden kann, kann ein Nutzer einen eigenen Proxy verwenden, damit IMAP- oder POP/SMTP-Clients auch mit „modernen“ E-Mail-Anbietern funktionieren, selbst wenn sie OAuth 2.0 nicht unterstützen. Der Client selbst muss nichts über OAuth wissen.

  • IMAP, SMTP und POP erlauben einen erheblichen Zugriff auf Google-Konten, können aber keine Zwei-Faktor-Authentifizierung oder Bot-Schutz-Prüfungen durchführen und sind daher anfällig für Credential-Stuffing-Angriffe. Es wird positiv bewertet, dass Google diesen Zugriff zum Schutz der Nutzer vor solchen Angriffen standardmäßig deaktiviert hat und dass diese Maßnahme nun für die übrigen Nutzer erfolgt.

  • Es wird darauf hingewiesen, dass diese Änderung offenbar darauf abzielt, Nutzer zu Googles eigenen Mail-Apps zu bewegen. Ohne die Gmail-App oder Google Sync, das bald eingestellt wird, gibt es keine Echtzeit-Benachrichtigungen für E-Mails. Ein Nutzer äußert Unmut darüber, obwohl er für Google Workspace bezahlt. Auf dem Desktop funktioniert Mimestream weiterhin, aber es besteht die Sorge, dass Google auch das noch unterbinden könnte.

  • Das Nervigste an Oauth2 und Google auf Android sei, dass man sich nicht mit einem Google-Konto in einem E-Mail-Client oder Kalender anmelden kann, ohne das gesamte Telefon mit diesem Google-Konto zu verknüpfen. Außerdem erhält dieses Google-Konto dadurch Richtlinienberechtigungen für das Gerät. Der Nutzer betont, dass sich das nicht vollständig ignorieren lässt, und weist darauf hin, dass Google die Nutzung von oauth2 innerhalb von WebView auf Android leicht einschränken kann.

  • App-Passwörter sind 16-stellige Passwörter, die nur bei Konten mit aktivierter Zwei-Faktor-Authentifizierung verwendet werden können. Es wird angemerkt, dass „weniger sichere Apps“ dasselbe Sicherheitsniveau bieten wie Apps mit OAuth-Unterstützung, allerdings durch serverseitige Mechanismen, die Google seit Langem bewerben konnte. Daraus folgt Kritik daran, dass Google Sicherheitsfragen in einer Weise auslegt, die die eigene Agenda fördert.

  • Es wird erklärt, dass App-Specific Passwords offenbar weiterhin funktionieren und dass Nutzer, die Apps ohne OAuth-Unterstützung verwenden, entweder zu einer App mit OAuth-Unterstützung wechseln oder ein App-Passwort erzeugen müssen, um Zugriff zu erhalten.

  • Es wird erklärt, dass diese Änderung nur für Workspace-Konten gilt und für normale Gmail-Konten bereits vor einigen Jahren eingeführt wurde.

  • Vor etwa zehn Jahren wurde ein System aufgebaut, das über die Integration mit dem Google-Konto-Verzeichnis die Authentifizierung einzelner Google-Konten im internen Netzwerk ermöglichte. Nach heutigen Maßstäben ist das weniger sicher, wurde aber positiv bewertet, weil es allen Zeit sparte, indem eine sofortige Verbindung zum internen Netzwerk auch ohne VPN möglich war.

  • Bei der Umstellung auf OAuth bei Microsoft gab es Schwierigkeiten; das Problem sei, dass der Prozess sehr intransparent ist. Man sendet ein Token, und der Server antwortet nur mit „Nein“, ohne zu erklären, warum es nicht funktioniert. Dadurch gingen mehrere Tage für die Fehlersuche verloren. Es wird die Frage aufgeworfen, ob Googles Mail-Server in dieser Hinsicht besser sind.