Betreutes Browsen

von Dr. Christian Knermann

Mit Chrome Enterprise bietet Google gleich mehrere Optionen zur zentralen Verwaltung des hauseigenen Browsers. Um die grundlegenden Einstellungen kümmern sich Gruppenrichtlinien sowie der Clouddienst Chrome Enterprise Core sogar komplett kostenfrei. Im Test zeigten sich ein hervorragendes Management für Windows-Clients, während andere Plattformen mit Abstrichen leben müssen. Doch alles in allem überzeugte das Werkzeug dank seiner flexiblen Methoden zum Einhegen des Browsers.

Während Anwendungen und Dienste aus der Cloud zunehmend Einzug in den Arbeitsalltag von Anwendern und Administratoren halten, verlieren konventionelle Applikationen zur Installation auf einem Desktopbetriebssystem an Bedeutung. Stattdessen übernehmen Brow-ser zunehmend die Rolle der Schaltzentrale für geschäftskritische Anwendungen und Dienste. Ob Office-Anwendungen, ERP oder Projektmanagementtools – cloudnative Applikationen, die direkt im Browser laufen, haben sich längst etabliert. Diese Entwicklung lässt die Wahl des Betriebssystems an Relevanz verlieren. Sie verlangt aber umso mehr nach einer effizienten wie sicheren Verwaltung von Browsern und dies möglichst plattformübergreifend auf ausgewachsenen Desktopbetriebssystemen wie auch mobilen Endgeräten.

Der weltweit marktführende Browser Chrome basiert auf dem maßgeblich von Google unterstützten Open-Source-Projekt Chromium, bringt aber im Gegensatz zu seiner quelloffenen Basis weitere Funktionen mit. So versorgt Google den Brow-ser automatisch mit Updates. Unter dem Label "Chrome Enterprise" unterstützt der Hersteller für Windows, Linux sowie macOS zudem Methoden zur zentralen Konfiguration, die komplett lokal und ohne Cloud funktionieren.

Alternativ kümmert sich der Clouddienst "Chrome Enterprise Core" kostenfrei und plattformübergreifend um die Pflege von Einstellungen sowie Erweiterungen und bezieht dabei auch iOS sowie das hauseigene Android mit ein. Chrome Enterprise Core (CEC) tritt damit die Nachfolge des früheren Chrome Browser Cloud Management (CBCM) an. Die kostenpflichtige Variante "Chrome Enterprise Premium" umfasst darüber hinaus weitere Funktionen, wie Dienste zur erweiterten Erkennung und Abwehr von Malware sowie Filterung von Webseiten. Hinzu kommen in diesem Tarif Regelwerke für Data Loss Prevention (DLP) und Conditional Access.

Separates Paket für Unternehmen

Die Setuproutine, die Google standardmäßig zum Download bereitstellt, richtet sich primär an Endanwender, die den Browser in Eigenregie auf einem nicht verwalteten Client verwenden. Diese Variante kommt auch ohne lokale Admin-Rechte aus und installiert den Browser einfach im Benutzerkontext des Anwenders. Im Rahmen von Chrome Enterprise bietet Google weitere Downloads speziell für den Einsatz in Unternehmen an. Neben universellen PKG- und DMG-Paketen für macOS findet sich hier ein MSI-Paket, mit dem Administratoren Chrome unter Windows im Computerkontext installieren und mittels eines Systems zur zentralen Softwareverteilung automatisiert ausbringen können. Dabei unterstützt Google sowohl x86- und x86-64-Systeme als auch die Plattform ARM64.

Alternativ zum MSI-Paket hat Google hier auch den Dateityp "Bundle" im Angebot. Dieses Paket enthält weitere Komponenten, die Administratoren für eine zentrale Verteilung und Konfiguration des Browsers benötigen. Insgesamt liefert Google drei MSI-Pakete mit, darunter neben dem eigentlichen Browser auch den "Legacy Browser Support". Letzterer ist inzwischen aber nicht mehr als separate Installation erforderlich, da aktuelle Versionen von Chrome die Funktion bereits ab Werk mitbringen. Die Option öffnet auf Wunsch bestimmte ältere Webseiten, die in Chrome nicht funktionieren, automatisch in einem alternativen Browser.

Ebenso optional ist das MSI-Paket der "Endpoint Verification". Bei der Endpunktprüfung handelt es sich um eine Cloudfunktion aus dem Umfang von Chrome Enterprise Premium, die den Zugriff auf Daten im Unternehmen basierend auf dem Standort des Geräts, dessen Sicherheitsstatus oder anderen Attributen kontextsensitiv steuert.

Management offline möglich

Die Ressourcen aus dem Bundle dienen dazu, die Einstellungen des Browsers lokal und ohne Cloudanbindung zu beeinflussen. So gibt die im Paket enthaltene JSON-Datei ".\GoogleChromeEnterpriseBundle64\Configuration\initial_preferences" dem Browser Starteinstellungen mit. Dabei auf JSON zu setzen, hat den Vorteil, dass dies auch auf Clients funktioniert, die keiner Active-Directory-Domäne angehören. Es handelt sich dabei jedoch nur um eine empfohlene Erstkonfiguration, die die Endanwender anschließend ändern können. Außerdem fließen die Einstellungen nur beim ersten Start des Browsers ins Benutzerprofil ein.

Für Windows-Clients in unserer Domäne erwiesen sich Gruppenrichtlinienobjekte (Group Policy Objects, GPO) somit als der flexiblere und auch komfortablere Weg. Dazu lieferte uns Google im Bundle passende GPO-Vorlagen vom Typ ADMX und die entsprechenden Sprachdateien mit, die wir in unserem Active Directory (AD) nur noch an den zentralen Ablageort der Richtlinien-Definitionen kopieren mussten.

Zentrales Element ist die Datei "chrome. admx" mit über 200 Richtlinien zur Konfiguration des Browsers. Diese stellte uns sowohl im Bereich der Computerkonfiguration als auch unterhalb der Benutzerkonfiguration Einstellungen zur Verfügung. Wir durften somit wählen, ob wir Konfigurationen des Browsers pauschal pro Computer oder auf Basis einzelner Benutzer oder Gruppen setzen wollten. Die Mehrzahl der Einstellungen liegt im Ordner "Google Chrome". Sie geben die Konfiguration des Browsers fix vor, sodass Benutzer nicht davon abweichen können.

Gegenüber dieser üblichen Funktionsweise von GPO ist aber eine Besonderheit erwähnenswert: Einige Einstellungen finden sich zusätzlich noch einmal unterhalb des Ordners "Google Chrome / Default Settings (users can override)". Ähnlich der Datei "master_preferences" konnten wir Nutzern darüber für den ersten Start empfohlene Voreinstellungen mitgeben, von denen sie anschließend dann aber abweichen durften.

Erweiterungen per GPO steuerbar

Per GPO ließ sich definieren, ob Nutzer überhaupt Erweiterungen aus dem Chrome Web Store installieren dürfen. Dabei konnten wir unerwünschte Erweiterungen anhand einer Blockliste ausschließen oder explizit freigegebene mittels Allow-List zulassen. Unternehmenskritische Erweiterungen ließen sich auch zwangsweise installieren. Die gesperrten, erlaubten oder sogar erzwungenen Erweiterungen trugen wir mit ihrer jeweiligen ID in die mehrzeiligen Eingabemasken der entsprechenden Einstellungen im GPO ein. Dazu mussten wir zunächst die ID der betreffenden Erweiterung ermitteln.

Die IDs fanden wir, indem wir die Erweiterungen auf einem Referenzsystem installierten, im Browser die interne URL "chrome://extensions/" ansteuerten und dann den Entwicklermodus aktivierten. Noch einfacher gelangten wir an die IDs, indem wir die Webseite der Add-ons im Chrome Web Store besuchten und den 32 Zeichen langen String am Ende der URLs in unser GPO übernahmen.

Pauschaler regelten wir den Zugriff auf Erweiterungen mittels der Einstellung "Configure allowed app/extension types", die bestimmte Klassen erlaubt, etwa nur Themes. Die Einstellung "Extension management settings" erlaubt oder sperrt Erweiterungen basierend auf den Rechten, die sie einfordern. So blockierten wir etwa alle Erweiterungen, die Zugriff auf USB-Schnittstellen verlangen. Bereits vorhandene Erweiterungen entfernte der Browser daraufhin zwar nicht, deaktivierte sie aber.

Fehlende Übersicht in heterogenem Umfeld

Weniger komfortabel gestaltete sich die Konfiguration des Browsers auf anderen Plattformen. Google unterstützt offiziell macOS (x86- und ARM-Prozessoren), Linux in 64-Bit-Varianten als DEB-Paket für Debian- und Ubuntu-Plattformen sowie als RPM-Paket für Fedora und OpenSUSE. Die Beispiele für entsprechende Konfigurationsdateien fanden wir im ZIP-Archiv des Enterprise-Bundles für Win-dows. Für macOS liegt diese in Form der Property-List-Beispieldatei "com.google. Chrome.plist" vor, deren XML-Code wir nach unseren Wünschen anpassen konnten, um das File dann in ein Konfigurationsprofil für ein Drittanbieter-MDM zu konvertieren.

Für Linux-Systeme dient die bereits erwähnte Datei "initial_preferences" als Vorlage für separate JSON-Dateien, die wir manuell oder über ein Werkzeug zur zentralen Verteilung auf Endpunkte befördern konnten. Richtlinien im Ordner "/etc/opt/chrome/policies/recommended" wirken als Empfehlung, von der ein Anwender abweichen darf. Vorgaben aus dem Ordner "/etc/opt/chrome/policies/ managed" sind verpflichtend, Benutzer können sie nicht ändern.

Die GPO erwiesen sich somit vor allem praktisch, wenn es um Windows-Clients in einem AD geht. Für Clients außerhalb einer Domäne und heterogene Umgebungen mit macOS oder Linux gerät das Management schnell mühsam und unübersichtlich. Über alle Plattformen hinweg vermissten wir beim lokalen Management zudem ein zentrales Berichtswesen zur Konfiguration der Clients und der installierten Erweiterungen.

In sieben Schritten zum Cloudmanagement

Hier kommt Chrome Enterprise Core ins Spiel, das sich plattformübergreifend um Instanzen des Browsers kümmert und auch mobile Endgeräte abdeckt. Schaltzentrale ist die webbasierte Google Admin Console. Unternehmen, die bereits Google Workspace oder Chromebooks einsetzen, dürfte die Konsole bereits vertraut sein. Doch auch Admins, die bislang noch keine Berührung damit hatten, finden schnell einen Zugang zu dem Werkzeug und verwalten damit den Browser und seine Erweiterungen.

Für unseren Test hatten wir uns auf der Chrome-Enterprise-Webseite für die kostenlose Variante registriert. Dazu verlangt Google lediglich eine geschäftliche E-Mail-Adresse, also eine eigenständige E-Mail-Domain und nicht etwa eine Adresse bei einem Freemail-Anbieter. Nach der Registrierung gelangten wir zur Auswahl der Abos. Neben dem bereits ausgewählten Chrome Enterprise Core standen hier das ebenfalls kostenfreie Paket "Google Workspace Essentials Starter" sowie ein 30-tägiger Testzeitraum des kostenpflichtigen Chrome Enterprise-Upgrades für ChromeOS zur Wahl.

Im Hinblick auf Google Workspace gilt es allerdings zu beachten, dass die Registrierung einer individuellen DNS-Domain in der Konsole mindestens das kostenpflichtige Paket "Google Workspace Essentials Premium" voraussetzt und so beließen wir es bei der Auswahl von Chrome Enterprise Core. Sobald wir ein Passwort für unseren Account festgelegt hatten, begrüßte uns Chrome Enterprise mit einem Assistenten, der in sieben einfach nachzuvollziehenden Schritten durch die grundlegende Konfiguration führte.

Zuvor kümmerten wir uns aber in den Kontoeinstellungen um höhere Sicherheit und richteten eine Telefonnummer sowie eine zweite E-Mail-Adresse zur Wiederherstellung unseres Kontos im Notfall ein. Weiterhin unterstützt Google hier gängige Methoden der Zweifaktor-Authentifizierung, darunter Time-based One-Time-Passwords (TOTP), Push-Benachrichtigungen, Hardware-Sicherheitsschlüssel und Passkeys. So gerüstet kehrten wir zum Assistenten zurück, der uns mit der Admin-Konsole vertraut machte.

Im ersten Schritt erzeugte der Assistent für uns unterhalb der Stammorganisationseinheit (OE) eine Unter-OE mit einer weiteren verschachtelten OE darin. Ähnlich wie GPOs im AD helfen OEs, die Aufbauorganisation sowie die logische oder geografische Struktur eines Unternehmens abzubilden und Einstellungen gezielt auf bestimmte Benutzer- oder Gerätegruppen – in diesem Fall auf bestimmte Installationen des Chrome-Browsers – anzuwenden. Dies setzten wir daraufhin auch sofort in die Tat um, entfernten die Test-OEs wieder und legten eine Struktur für die Standorte unseres Unternehmens an.

Im nächsten Schritt leitete uns der Assistent an, für eine oder mehrere OEs die Browserberichte zu aktivieren. Die Cloudberichte liefern Admins Informationen zu allen verwalteten Browsern, deren Versionen sowie zu Profil- und Gerätedaten, ebenso zur Nutzung von Apps und Erweiterungen. Standardmäßig aktualisiert die Konsole die Berichtsdaten alle 24 Stunden, wir konnten aber alternativ auch pro OE einen beliebigen Wert von drei bis 24 Stunden definieren. Für verwaltete Profile von Benutzern mussten wir das Reporting später noch separat aktivieren.

Geräte auch ohne angemeldeten Benutzer verwalten

Weiter führte uns der Assistent durch die Token-basierte Registrierung eines Browsers, wahlweise auf unserem aktuellen Device, von dem aus wir die Konsole bedienten oder alternativ auf einem separaten Testgerät. Wir wählten letztere Option und bestimmten eine Ziel-OE, für die wir einen Token erzeugten. Ein solcher Token – eine alphanumerische Zeichenkette – eignet sich zur mehrfachen Registrierung von Browsern, die bei Verwendung des Tokens automatisch in der gewünschten OE landen. Der Token ist nur einmalig zur Registrierung erforderlich, wir konnten ihn später gefahrlos zurückrufen und durch einen anderen ersetzen. Die Browser blieben jeweils mit einer individuellen Geräte-ID, ihrem Computernamen, Betriebssystem sowie der Betriebssystemversion in der Konsole registriert.

Der Assistent beschrieb für Windows, macOS, Linux, Android und iOS das passende Vorgehen. Unter Windows mussten wir lediglich eine Reg-Datei herunterladen und auf dem Zielgerät in die Registrierung importieren. Alternativ funktionieren ebenso das manuelle Eintragen des Tokens in der Registrierung, die Verteilung per GPO oder die Bereitstellung in VMware Workspace One.

Unter macOS erwartet der Browser eine XML-Datei mit dem Token im lokalen Pfad "/Library/Google/Chrome/", die wir dort einfach manuell ablegen oder aber über Drittanbieter wie etwa Jamf verteilen konnten. Linux-Clients suchen nach einer Datei mit dem Namen "CloudManagementEnrollmentToken" im Pfad "/etc/opt/ chrome/policies/enrollment". Für Android und iOS lieferte der Assistent die nötigen Informationen zur Konfiguration mithilfe der Google-Endpunktverwaltung sowie mit den MDM-Werkzeugen mehrerer Drittanbieter, darunter Cisco Meraki, Microsoft Intune und Jamf Pro.

Sobald wir den Browser nun neu starteten, registrierte er sich automatisch in der gewünschten OE innerhalb der Google Admin Console. Auf diese Weise fügten sich auch im Kontext eines Benutzers installierte Instanzen des Browsers in die zentrale Verwaltung ein, sobald sie beim Neustart einen Token fanden. Einstellungen, die wir nun auf der Ebene der OE konfigurierten oder von höherer Stelle dorthin vererbten, traten unmittelbar in den verwalteten Browsern in Kraft und dies unabhängig davon, ob im Kontext des Browsers ein Benutzer mit einem Profil angemeldet war oder nicht.

Zum Einstieg in die Richtlinien führte uns der Assistent in den folgenden beiden Schritten zunächst durch die Konfiguration grundlegender Einstellungen, exemplarisch zur Konfiguration von Startseite und Inkognito-Modus der verwalteten Browser. Weiterhin demonstrierte der Assistent die erzwungene Installation von Chrome-Erweiterungen am Beispiel einiger Erweiterungen von Google, darunter Google-Übersetzer, Google Drive und Notizen oder auch Chrome Remote Desktop. Derart erzwungene Erweiterungen konnten wir per Richtlinie auch gleich in der Symbolleiste der verwalteten Browser anpinnen.

Flexibles Usermanagement

Im vorletzten Schritt unterstützte uns der Assistent bei der Registrierung unserer DNS-Domain. Für viele große Provider, wie etwa 1&1, AWS, Cloudflare oder GoDaddy, verifiziert die Konsole eine Domain halbautomatisch. In unserem Fall forderte die Konsole uns auf, einen bestimmten TXT-Record als Eigentumsnachweis im DNS einzutragen. Zu guter Letzt konnten wir dann einen weiteren Benutzer anlegen und diesem optional eine von vier abgestuften Rollen bis hin zum Super-Admin mit den höchsten Berechtigungen innerhalb der Konsole zuweisen. Damit war die grundlegende Konfiguration erledigt und wir orientierten uns weiter in der Konsole.

Im Bereich "Verzeichnis / Organisationseinheiten" des vertikalen Hauptmenüs am linken Rand verwalteten wir unsere Hierarchie von OEs. Weitere Benutzerkonten legten wir dann unter dem Punkt "Verzeichnis / Nutzer" manuell an. Alternativ synchronisiert der Google Cloud Directory Sync (GCDS) einen generischen LDAP-Server oder ein AD mit der Cloud. Als neuere Option gleicht die Verzeichnissynchronisierung wahlweise Entra ID, Active Directory, OpenLDAP oder benutzerdefinierte LDAP-Verzeichnisse mit der Google Admin Console ab. Diese Option befand sich zum Zeitpunkt unseres Tests allerdings noch im Beta-Stadium.

Individuelle Rangfolge der Richtlinien

Alle Optionen zur Verwaltung unserer Browser fanden wir gesammelt unter dem Menüpunkt "Chrome-Browser". Darunter lieferte uns die Konsole die detaillierten Berichte für Geräte im Bereich "Verwaltete Browser" und für Benutzer im neuen Untermenü "Verwaltete Profile". Unsere Richtlinien konfigurierten wir im Bereich "Chrome-Browser / Einstellungen". Dort wählten wir im Sub-Menü zunächst die gewünschte OE und legten dann im Hauptbereich des Fensters auf der Registerkarte "Nutzer- und Browsereinstellungen" die gewünschten Vorgaben fest.

Alternativ konnten wir Einstellungen hier auch Gruppen anstelle von Organisationseinheiten zuweisen, um sie granular nur auf bestimmte Benutzer anzuwenden. Um in der Vielzahl an Optionen nicht den Überblick zu verlieren, filterten wir hier die Plattform "Chrome für Computer" heraus. Diese zeigt nur Einstellungen an, die den Browser unter Windows, macOS oder Linux betreffen. Weitere Filteroptionen blenden die Einstellungen für die Plattformen ChromeOS sowie die mobilen Browser unter Android, iOS und iPadOS ein.

Insbesondere beim parallelen Einsatz von lokalen GPOs oder bei einem Wechsel von GPO zur Verwaltung in der Cloud gilt es, die Rangfolge der Richtlinien zu beachten. Google fasst Vorgaben im Maschinenkontext aus GPO sowie anderweitig verteilte JSON-Dateien unter dem Begriff der Plattformrichtlinien zusammen. Standardmäßig haben diese die höchste Priorität, gefolgt von Cloudeinstellungen auf Geräteebene. Erst dann kommen lokale Einstellungen auf Benutzerebene und zu guter Letzt Cloudvorgaben für Benutzer. Mithilfe der Richtlinie "Rangfolge der Richtlinien" konnten wir diese Prioritäten verändern.

Verwaltete Profile trennen Arbeit von Privatem

Sehr angetan waren wir von den Optionen zum Verwalten von Benutzerprofilen. Diese erwiesen sich insbesondere als praktisch, wenn die private Mitnutzung dienstlicher Geräte gestattet ist oder in BYOD-Szenarien, wenn Mitarbeiter oder auch Externe eigene Rechner verwenden wollen. Dann empfehlen sich zwar die zusätzlichen Sicherheitsfunktionen von Chrome Enterprise Premium, doch auch die kostenfrei verfügbaren Richtlinien überzeugen. Google hat den vielfältigen Möglichkeiten mit dem Dokument "Profile separation with Chrome browser" sogar einen separaten Leitfaden gewidmet.

Mithilfe der Richtlinien konnten wir flexibel festlegen, wie der Browser sich verhalten soll, wenn bereits lokale Daten vorhanden sind oder wenn sich Benutzer mit einem persönlichen oder einem verwalteten Konto einer anderen Organisation anmelden wollen. So waren wir etwa in der Lage zu bestimmen, dass Chrome bei der Anmeldung eines von uns verwalteten Benutzerkontos dem Benutzer zur Wahl stellt, lokal bereits bestehende Browserdaten ins geschäftliche Profil zu migrieren.

Alternativ erzwingt die Profiltrennung ein separates Unternehmensprofil, sodass Benutzer parallel zwei Browsersitzungen mit komplett getrennten Lesezeichen und Browserverläufen betreiben können. Das geschäftliche Profil versahen wir mit Namen und Logo der Organisation, sodass Benutzer auch optisch erkennen, in welchem Kontext sie sich gerade befinden.

Ebenso gingen wir bei den Erweiterungen im Bereich "Chrome-Browser / Apps und Erweiterungen vor". Im Vergleich zu GPOs und Textdateien gelang die Konfiguration hier deutlich intuitiver. Über das Plus-Zeichen unten rechts wählten wir Erweiterungen in einem grafischen Dialog mit Suchfunktion direkt aus dem Chrome Web Store. Daraufhin blockierten wir die jeweilige Erweiterung, erlaubten sie oder erzwangen ihre Installation, auf Wunsch auch gleich mit Anpinnen in der Symbolleiste des Browsers. Sobald wir Einstellungen vorgenommen hatten, konnten wir an unseren verbundenen Browsern beobachten, dass diese unmittelbar aktiv wurden. Im Gegensatz zu GPOs setzen die Browser die Einstellungen somit praktisch ohne Zeitverzögerung sofort um.

Fazit

Google stellt dem hauseigenen Browser mit Chrome Enterprise Core umfangreiche Möglichkeiten für das zentrale Management zur Seite und dies mit überraschend großem Funktionsumfang sogar kostenlos. Mittels GPO oder Textdateien bleibt die Konfiguration komplett lokal, erfordert aber, Einstellungen ganz oder teilweise in JSON und XML zu notieren. Dies unterstützt vor allem Admins, die Windows-Clients mithilfe von Gruppenrichtlinien verwalten. In heterogenen Umgebungen gerät die Verwaltung dagegen schnell komplex und unübersichtlich.

IT-Verantwortliche, die extern gehostete Cloudanwendungen nicht scheuen, greifen stattdessen zum Cloudmanagement über die Google Admin Console. Die kümmert sich um die Konfiguration zahlreicher Chrome-Instanzen und Benutzerprofile mitsamt Erweiterungen komfortabel grafisch und plattformüber- greifend. Admins profitieren hier zudem von den vielfältigen Optionen zur Trennung von privaten und geschäftlichen Profilen.

Produkt	Plattformübergreifendes Management für den Browser Google Chrome.
Hersteller	Google https://chromeenterprise.google/products/cloud-management/
Preis	Chrome Enterprise Core ist kostenlos, während für Chrome Enterprise Premium 6 US-Dollar pro Benutzer und Monat anfallen.
Systemvoraussetzungen	Chrome-Browser unter macOS, iOS, iPadOS, Android, Microsoft Windows oder Linux.
Technische Daten	https://www.it-administrator.de/downloads/datenblaetter

Lokale Verwaltung von Windows	7
Lokales Management anderer OS	6
Cloudmanagement	8
Verwaltete Profile	8
Erweiterungen administrieren	8
Die Details unserer Testmethodik finden Sie unter https://www.it-administrator.de/testmethodik/

Google Chrome Enterprise Core