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.
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: | Zugriff_Fremdfirma |
| Fremdfirmen erhalten Zugriff, wenn sie: | Attribute erfüllen |
| Attribut der Bedingung 1: | IP-Subnetz (öffentlich) 74.125.192.0/18 |
| Wem wird die Zugriffsebene zugewiesen? | Organisationseinheiten für Fremdfirmen Allen Apps, die die Fremdfirmen 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_riskante |
| Nutzer erhalten Zugriff, wenn sie: | Attribute nicht erfüllen |
| Attribut der Bedingung 1: | IP-Subnetz (öffentlich) 74.125.195.105 |
| Wem wird die Zugriffsebene zugewiesen? | Oberste Organisationseinheit Alle Apps |
Zugriff aus einem bestimmten privaten Netzwerk in Google Cloud zulassen
Viele Unternehmen leiten den Nutzertraffic ü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 von 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 |
| Wem wird die Zugriffsebene zugewiesen? |
Organisationseinheiten für alle Nutzer Allen Apps, die Auftragnehmer nutzen |
Wichtige Hinweise:
- Nur direkter Traffic: Diese Zugriffsebene funktioniert nur für Traffic, der die Google-Server direkt von der auf der Zulassungsliste stehenden VPC aus erreicht. Wenn der Traffic zuerst über ein anderes Netzwerk oder einen anderen Tunnel geleitet wird, wird kein Zugriff gewährt. Google erkennt nur die letzte VPC, die den Traffic an die Server sendet.
- Administratorberechtigungen: Um VPCs aufzurufen und diese Zugriffsebene zu konfigurieren, müssen Administratoren die entsprechende Identity and Access Management (IAM) Rolle haben, z. B. compute.networks.list und compute.subnetworks.list.
- 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: | Zugriff_Vertrieb |
| Vertriebsmitarbeiter erhalten Zugriff, wenn sie: | Attribute erfüllen |
| Attribut der Bedingung 1: | Standort USA, Australien, Indien |
| Wem wird die Zugriffsebene zugewiesen? | Gruppe von Vertriebsmitarbeitern Alle Apps, die Vertriebsmitarbeiter nutzen |
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 (OR), 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, Nutzer sollen auf Anwendungen zugreifen können, wenn sie die Bedingungen für eine der Zugriffsebenen „US-West“, „US-Ost“ oder „US-Zentral“ erfüllen.In diesem Fall können Sie mit dem Operator OR eine einzelne verschachtelte Zugriffsebene namens „US-Regionen“ erstellen. Wenn Sie die Zugriffsebenen zuweisen möchten, weisen Sie der Anwendung die Organisationseinheit oder Gruppe „US-Regionen“ zu.
|
Name der Zugriffsebene: |
US-Regionen |
|
Nutzer erhalten Zugriff, wenn sie: |
Attribute erfüllen |
|
Attribut der Bedingung 1: (nur 1 Zugriffsebene pro Bedingung) |
Zugriffsebene US-West |
|
Logische Verknüpfung der Bedingungen 1 und 2 mit: |
OR |
|
Nutzer erhalten Zugriff, wenn sie: |
Attribute erfüllen |
|
Attribut der Bedingung 2: |
Zugriffsebene US-Ost |
|
Logische Verknüpfung der Bedingungen 2 und 3 mit: |
OR |
|
Nutzer erhalten Zugriff, wenn sie: |
Attribute erfüllen |
|
Attribut der Bedingung 3 |
Zugriffsebene US-Zentral |
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 dieser Möglichkeiten hat Vor- und Nachteile.
Eine Zugriffsebene, die alle Sicherheitsanforderungen enthält
Bei 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: | Sicherheit_Gerät |
| Nutzer erhalten Zugriff, wenn sie: | Attribute erfüllen |
| Attribut der Bedingung 1 (Sie können alle Attribute zu einer Bedingung hinzufügen oder drei Bedingungen erstellen und sie mit AND 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. Es handelt sich um eine logische ODER-Verknüpfung von Zugriffsebenen.
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: | Verschlüsselung_Gerät |
| Nutzer erhalten Zugriff, wenn sie: | Attribute erfüllen |
| Attribut der Bedingung 1: |
Geräterichtlinie |
| Name der Zugriffsebene: | unternehmenseigenes_Gerät |
| Nutzer erhalten Zugriff, wenn sie: | Attribute erfüllen |
| Attribut der Bedingung 1: |
Geräterichtlinie |
| Name der Zugriffsebene: | min_Betriebssystem |
| 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. Es handelt sich um eine logische UND-Verknüpfung von Zugriffsebenen.
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 drei Zugriffsebenen wie oben unter „Drei einzelne Zugriffsebenen“ beschrieben: „device_encryption“, „corp_device“ und „min_os“. 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: | Sicherheit_Gerät |
| Nutzer erhalten Zugriff, wenn sie: | Attribute erfüllen |
| Attribut der Bedingung 1 (nur 1 Zugriffsebene pro Bedingung) |
Zugriffsebene device_encryption |
| Logische Verknüpfung der Bedingungen 1 und 2 mit: | AND |
| Nutzer erhalten Zugriff, wenn sie: | Attribute erfüllen |
| Attribut der Bedingung 1: | Zugriffsebene corp_device |
| Logische Verknüpfung der Bedingungen 2 und 3 mit: | AND |
| Nutzer erhalten Zugriff, wenn sie: | Attribute erfüllen |
| Attribut der Bedingung 1: | Zugriffsebene min_os |