In diesem Artikel werden häufige Anwendungsfälle für den kontextsensitiven Zugriff beschrieben. Außerdem finden Sie hier Beispielkonfigurationen, die im einfachen Modus entwickelt wurden.
Beispiele für Zugriffsebenen, die mithilfe des CEL-Editors im erweiterten Modus entwickelt wurden, finden Sie in diesem Artikel.
Fremdfirmen nur über das Unternehmensnetzwerk Zugriff gewähren
Viele Unternehmen möchten von ihnen beauftragten Fremdfirmen nur eingeschränkten Zugriff auf Unternehmensressourcen gewähren. Ein Beispiel wäre ein Unternehmen, das von Fremdfirmen allgemeine Supportanrufe bearbeiten lässt oder deren Auftragnehmer in Hilfe- und Callcentern arbeiten. Ähnlich wie die normalen Angestellten müssen die Mitarbeiter der Fremdfirma eine unterstützte Lizenz haben, damit die Richtlinien für den kontextsensitiven Zugriff für sie gelten.
In diesem Beispiel erhält die Fremdfirma nur aus einem bestimmten, unternehmenseigenen IP-Bereich heraus Zugriff auf Unternehmensressourcen.
| Name der Zugriffsebene | contractor_access |
| Fremdfirmen erhalten Zugriff, wenn sie: | Attribute erfüllen |
| Attribut der Bedingung 1 | IP-Subnetz (öffentlich) 74.125.192.0/18 |
| Zuweisung der Zugriffsebene | Organisationseinheiten für Auftragnehmer Allen Apps, die Auftragnehmer nutzen |
Zugriffe über bekannte Hacker-IP-Adressen blockieren
Viele Unternehmen versuchen ihre Ressourcen vor Manipulationen zu schützen, indem sie Zugriffe aus sehr riskanten Quellen blockieren.
In diesem Beispiel wird die IP-Adresse 74.125.195.105 blockiert. Nutzer erhalten Zugriff auf Unternehmensressourcen, wenn sie für ihre Sitzung nicht diese IP-Adresse verwenden. Sie können mehrere IP-Adressen und Bereiche angeben.
| Name der Zugriffsebene | block_highrisk |
| Nutzer erhalten Zugriff, wenn sie: | Attribute nicht erfüllen |
| Attribut der Bedingung 1 | IP-Subnetz (öffentlich) 74.125.195.105 |
| Zuweisung der Zugriffsebene | Oberste Organisationseinheit Alle Apps |
Zugriff von einem bestimmten privaten Netzwerk in Google Cloud zulassen
Viele Unternehmen leiten den Nutzer-Traffic über eine Virtual Private Cloud (VPC) an Google weiter. Eine VPC ist ein sicheres, isoliertes Netzwerk in der Google Cloud-Umgebung.
Traffic, der über Ihre VPC weitergeleitet wird, verwendet möglicherweise private IP-Adressen. Dies kann zu Problemen mit Richtlinien für öffentliche IP-Adressen oder Regionen führen.
In diesem Beispiel können Sie Traffic aus diesen bestimmten VPCs zulassen.
| Name der Zugriffsebene | vpc_access |
| Nutzer erhalten Zugriff, wenn sie: | Attribute erfüllen |
| Attribute der Bedingung 1 |
IP-Subnetz (privat) Privates IP-Subnetzwerk: //compute.googleapis.com/projects/project- name-test/global/networks/network-name VPC-Subnetz: 74.125.192.0/18 |
| Zuweisung der Zugriffsebene |
Organisationseinheiten für alle Nutzer Allen Apps, die Auftragnehmer nutzen |
Wichtige Hinweise:
- Nur direkter Traffic: Diese Zugriffsebene funktioniert nur für Traffic, der direkt von der auf der Zulassungsliste stehenden VPC auf die Google-Server gelangt. Wenn der Traffic zuerst über ein anderes Netzwerk oder einen anderen Tunnel geleitet wird, wird der Zugriff nicht gewährt. Google erkennt nur die letzte VPC, die den Traffic an seine Server sendet.
- Administratorberechtigungen: Zum Aufrufen von VPCs und Konfigurieren dieser Zugriffsebene müssen Administratoren die entsprechende IAM-Rolle (Identity and Access Management) haben, z. B. compute.networks.list, compute.subnetworks.list usw.
- Externe VPCs: Die VPC, die Sie auf die Zulassungsliste setzen, kann sich außerhalb Ihrer aktuellen Google Cloud-Domain befinden. Ein Administrator muss die Berechtigung zum Aufrufen haben, um die externe VPC hinzuzufügen.
Zugriff von bestimmten Standorten aus zulassen oder verbieten
Wenn Sie Mitarbeiter haben, die regelmäßig in anderen Büros Ihres Unternehmens oder bei Partnern arbeiten, können Sie die Standorte angeben, von denen aus sie auf Unternehmensressourcen zugreifen dürfen.
Wenn beispielsweise eine Gruppe von Vertriebsmitarbeitern regelmäßig Kunden in Australien und Indien besucht, können Sie der Gruppe den Zugriff ausschließlich vom Unternehmensbüro sowie von Australien und Indien aus erlauben. Wenn die Mitarbeiter die Geschäftsreise mit einem privaten Urlaub in einem anderen Land verbinden, haben sie dort keinen Zugriff auf Unternehmensressourcen.
In diesem Beispiel können die Mitarbeiter aus dem Vertriebsteam nur aus folgenden Ländern auf Unternehmensressourcen zugreifen: USA (Unternehmensbüro), Australien und Indien.
| Name der Zugriffsebene | sales_access |
| Vertriebsmitarbeiter erhalten Zugriff, wenn sie: | Attribute erfüllen |
| Attribut der Bedingung 1 | Standort USA, Australien, Indien |
| Zuweisung der Zugriffsebene | Gruppe von Vertriebsmitarbeitern Allen Apps, die von Vertriebsmitarbeitern verwendet werden |
Sie können auch per Richtlinie den Zugriff aus bestimmten Ländern blockieren, indem Sie festlegen, dass Nutzer nur Zugriff erhalten, wenn die Bedingungen nicht erfüllt sind. In diesem Fall listen Sie die Länder auf, aus denen kein Zugriff möglich sein soll.
Verschachtelte Zugriffsebenen verwenden, anstatt bei der Zuweisung mehrere auszuwählen
Wenn Sie versuchen, einer bestimmten Organisationseinheit oder Gruppe sowie einer Anwendung (oder mehreren Anwendungen) Zugriffsebenen zuzuweisen, wird möglicherweise eine Fehlermeldung angezeigt. In dieser werden Sie aufgefordert, die Anzahl der Anwendungen oder Zugriffsebenen zu reduzieren.
Um diesen Fehler zu vermeiden, können Sie die Anzahl der Zugriffsebenen reduzieren, die während der Zuweisung verwendet werden. Verschachteln Sie sie einfach in eine einzige Zugriffsebene. Die verschachtelte Zugriffsebene verknüpft mehrere Bedingungen mit einem ODER-Vorgang, wobei jede Bedingung eine einzelne Zugriffsebene enthält.
In diesem Beispiel befinden sich US-West, US-Ost und US-Zentral in drei separaten Zugriffsebenen. Angenommen, Sie möchten Nutzern den Zugriff auf die Anwendungen ermöglichen, wenn sie eine der Zugriffsebenen US-West oder US-Ost oder US-Zentral erfüllen.Mithilfe des Operators „OR“ können Sie eine einzelne verschachtelte Zugriffsebene (US-Regionen) erstellen. Wenn Sie die Zugriffsebenen zuweisen möchten, weisen Sie der Anwendung die Organisationseinheit oder Gruppe „US-Regionen“ zu.
|
Name der Zugriffsebene |
USRegions |
|
Nutzer erhalten Zugriff, wenn sie: |
Attribute erfüllen |
|
Attribut der Bedingung 1 (nur 1 Zugriffsebene pro Bedingung) |
Zugriffsebene USWest |
|
Logische Verknüpfung der Bedingungen 1 und 2 mit: |
ODER |
|
Nutzer erhalten Zugriff, wenn sie: |
Attribute erfüllen |
|
Attribut der Bedingung 2 |
Zugriffsebene USEast |
|
Bedingung 2 und Bedingung 3 verknüpfen mit |
ODER |
|
Nutzer erhalten Zugriff, wenn sie: |
Attribute erfüllen |
|
Attribut der Bedingung 3 |
Zugriffsebene USCentral |
Unternehmenseigener Computer, aber kein unternehmenseigenes Mobilgerät
In einem Unternehmen benötigen die Mitarbeiter vielleicht einen unternehmenseigenen Computer, aber kein unternehmenseigenes Mobilgerät.
Erstellen Sie zuerst eine Zugriffsebene für Computer:
|
Name der Zugriffsebene |
aldesktop_access |
|
Nutzer erhalten Zugriff, wenn sie |
Attribute erfüllen |
|
Attribut der Bedingung 1 |
Geräterichtlinie
Geräteverschlüsselung = nicht unterstützt Betriebssystem des Geräts macOS = 0.0.0 Windows =0.0.0 Linux OS = 0.0.0 Chrome OS = 0.0.0 |
Erstellen Sie dann eine Zugriffsebene für Mobilgeräte:
|
Name der Zugriffsebene |
almobile_access |
|
Nutzer erhalten Zugriff, wenn sie |
Attribute erfüllen |
|
Attribut der Bedingung 1 |
Betriebssystem des Geräts iOS = 0.0.0 Android = 0.0.0 |
Grundlegende Gerätesicherheit erzwingen
In den meisten Unternehmen können Mitarbeiter mittlerweile nur auf Unternehmensdaten zugreifen, wenn sie dafür ein verschlüsseltes Gerät mit der mindestens erforderlichen Betriebssystemversion nutzen. Manche verlangen auch, dass Mitarbeiter unternehmenseigene Geräte verwenden.
Sie können diese Richtlinien entweder für alle Ihre Organisationseinheiten oder nur für diejenigen konfigurieren, in denen mit sensiblen Daten gearbeitet wird, z. B. die Geschäftsführung, die Buchhaltung und die Personalabteilung.
Sie haben mehrere Möglichkeiten, eine Richtlinie zu konfigurieren, die verschlüsselte Geräte, eine mindestens erforderliche Betriebssystemversion und die Nutzung eines unternehmenseigenen Geräts vorschreibt. Jede hat Vor- und Nachteile.
Eine Zugriffsebene, die alle Sicherheitsanforderungen enthält
In diesem Beispiel werden die Attribute „Geräteverschlüsselung“, „Mindestens erforderliche Betriebssystemversion“ und „Unternehmenseigenes Gerät“ zusammen in einer Zugriffsebene verwendet. Nutzer müssen alle Bedingungen erfüllen, um Zugriff zu erhalten.
Verwendet ein Nutzer also z. B. ein verschlüsseltes unternehmenseigenes Gerät, auf dem aber nicht die mindestens erforderliche Betriebssystemversion installiert ist, erhält er keinen Zugriff.
Vorteil: Einfache Einrichtung. Wenn Sie diese Zugriffsebene einer App zuweisen, muss ein Nutzer alle Voraussetzungen erfüllen, um Zugriff zu erhalten.
Nachteil: Wenn Sie die einzelnen Sicherheitsanforderungen verschiedenen Organisationseinheiten zuweisen möchten, müssen Sie für jede Anforderung eine eigene Zugriffsebene erstellen.
| Name der Zugriffsebene | device_security |
| Nutzer erhalten Zugriff, wenn sie: | Attribute erfüllen |
| Attribut der Bedingung 1 : (Sie können alle Attribute in eine Bedingung aufnehmen oder drei Bedingungen erstellen und mit UND verknüpfen.) |
Geräterichtlinie Betriebssystem des Geräts |
Drei einzelne Zugriffsebenen
In diesem Beispiel wird für jedes der drei Attribute „Geräteverschlüsselung“, „Unternehmenseigenes Gerät“ und „Mindestens erforderliche Betriebssystemversion“ eine eigene Zugriffsebene erstellt. Nutzer müssen nur die Bedingungen einer Ebene erfüllen, um Zugriff zu erhalten. Die Zugriffsebenen haben eine logische OR-Verknüpfung.
Ein Nutzer erhält also auch dann Zugriff, wenn er ein verschlüsseltes privates Gerät verwendet, auf dem nicht die mindestens erforderliche Betriebssystemversion installiert ist.
Vorteil: Zugriffsebenen lassen sich genau definieren. Sie können die Zugriffsebenen einzeln unterschiedlichen Organisationseinheiten zuweisen.
Nachteil: Nutzer müssen nur die Bedingungen einer Zugriffsebene erfüllen.
| Name der Zugriffsebene | device_encryption |
| Nutzer erhalten Zugriff, wenn sie: | Attribute erfüllen |
| Attribut der Bedingung 1 |
Geräterichtlinie |
| Name der Zugriffsebene | corp_device |
| Nutzer erhalten Zugriff, wenn sie: | Attribute erfüllen |
| Attribut der Bedingung 1 |
Geräterichtlinie |
| Name der Zugriffsebene | min_os |
| Nutzer erhalten Zugriff, wenn sie: | Attribute erfüllen |
| Attribut der Bedingung 1 |
Geräterichtlinie |
Eine Zugriffsebene mit verschachtelten Zugriffsebenen
In diesem Beispiel wird für jede der drei Sicherheitsanforderungen „Geräteverschlüsselung“, „Mindestens erforderliche Betriebssystemversion“ und „Unternehmenseigenes Gerät“ eine eigene Zugriffsebene erstellt. Zusätzlich zu diesen drei Zugriffsebenen gibt es eine vierte, übergeordnete Zugriffsebene.
Wenn Sie Apps die vierte Zugriffsebene zuweisen, müssen Nutzer die Bedingungen aller drei Zugriffsebenen erfüllen, um Zugriff zu erhalten. Die Zugriffsebenen haben eine logische UND-Verknüpfung.
Beispiel: Ein Nutzer verwendet ein privates verschlüsseltes Gerät, auf dem nicht die mindestens erforderliche Betriebssystemversion ausgeführt wird. Er erhält keinen Zugriff.
Vorteil: Sie können die Sicherheitsanforderungen flexibel auf die Zugriffsebenen 1, 2 und 3 verteilen. Mithilfe der Zugriffsebene 4 können Sie auch eine Richtlinie mit allen Sicherheitsanforderungen erzwingen.
Nachteil: Verweigerte Zugriffe werden im Audit-Log nur für die Ebene 4 erfasst, nicht für die Ebenen 1, 2 und 3, weil sie nicht direkt Apps zugewiesen sind.
Erstellen Sie zuerst drei Zugriffsebenen wie weiter oben im Beispiel „Drei einzelne Zugriffsebenen“ beschrieben: „Verschlüsselung_Gerät“, „unternehmenseigenes_Gerät“ und „min_Betriebssystem“. Erstellen Sie dann eine vierte Zugriffsebene namens „device_security“ mit drei Bedingungen. Verwenden Sie in jeder Bedingung eine Zugriffsebene als Attribut. Sie können in einer Bedingung maximal 1 Zugriffsebene als Attribut angeben.
| Name der Zugriffsebene | device_security |
| Nutzer erhalten Zugriff, wenn sie: | Attribute erfüllen |
| Attribut 1 der Bedingung 1 (nur eine Zugriffsebene pro Bedingung) |
Zugriffsebene Geräteverschlüsselung |
| Logische Verknüpfung der Bedingungen 1 und 2 mit: | UND |
| Nutzer erhalten Zugriff, wenn sie: | Attribute erfüllen |
| Attribut der Bedingung 1 | Zugriffsebene unternehmenseigenes_Gerät |
| Bedingung 2 und Bedingung 3 verknüpfen mit | UND |
| Nutzer erhalten Zugriff, wenn sie: | Attribute erfüllen |
| Attribut der Bedingung 1 | Zugriffsebene min_Betriebssystem |