Access Context Manager – Übersicht

Dieses Dokument bietet einen allgemeinen Überblick über den Access Context Manager-Dienst und seine Funktionen. Google Cloud Organization Administratoren können mit Access Context Manager eine detaillierte, attributbasierte Zugriffssteuerung für Projekte und Ressourcen in Google Clouddefinieren. Als Administrator definieren Sie zuerst eine Zugriffsrichtlinie. Dies ist ein organisationsweiter Container für Zugriffsebenen und Dienstperimeter.

Zugriffsebenen beschreiben die Anforderungen, die Anfragen erfüllen müssen. Beispiele:

  • Gerätetyp und Betriebssystem
  • IP-Adresse
  • Nutzeridentität

Dienstperimeter definieren Sandboxes von Ressourcen. Ressourcen innerhalb des Perimeters können Daten frei austauschen, aber keine Daten außerhalb des Perimeters exportieren. Access Context Manager ist nicht für die Durchsetzung von Richtlinien zuständig. Access Context Manager ist vielmehr dafür konzipiert, bestimmte Regeln oder Kontexte zu definieren. Die Richtlinie wird an verschiedenen Stellen konfiguriert und erzwungen, z. B. in VPC Service Controls. Weitere Informationen zu diesen Diensten finden Sie in den entsprechenden Nutzerhandbüchern.

Sie können Access Context Manager-Richtlinien für die folgenden Chrome Enterprise Premium-Lösungskomponenten konfigurieren und erzwingen:

Vorteile

Viele Unternehmen verlassen sich auf ein Perimetersicherheitsmodell wie eine Firewall, um interne Ressourcen zu schützen. Ein Perimetersicherheitsmodell ist stark bewacht und hat nur einen einzigen Ein- und Ausgangspunkt. Alles, was sich außerhalb des Perimeters befindet, gilt als gefährlich. Alles, was sich innerhalb der Mauern befindet, gilt als vertrauenswürdig.

Firewalls und das Perimetersicherheitsmodell funktionieren gut, wenn es eine klar definierte Grenze um bestimmte Nutzer und Dienste gibt. Ist eine Belegschaft mobil, erhöht sich jedoch die Vielfalt der Geräte, zum Beispiel wenn Nutzer eigene Geräte (BYOD) und cloudbasierte Dienste verwenden. Dieses Szenario führt zu zusätzlichen Angriffsvektoren, die vom Perimetermodell nicht berücksichtigt werden. Daher ist der Perimeter nicht mehr nur der physische Standort des Unternehmens und es kann nicht davon ausgegangen werden, dass alles, was sich darin befindet, sicher ist.

Mit Access Context Manager können Sie die Größe des privilegierten Netzwerks reduzieren und zu einem Modell wechseln, bei dem Endpunkte keine netzwerkbasierte Umgebungsautorität haben. Stattdessen können Sie den Zugriff basierend auf dem Kontext der Anfrage gewähren, z. B. Gerätetyp, Nutzeridentität und mehr, und bei Bedarf trotzdem den Zugriff auf das Unternehmensnetzwerk prüfen.

Access Context Manager ist ein wesentlicher Bestandteil der BeyondCorp-Initiative von Google. Weitere Informationen finden Sie unter BeyondCorp.

Zugriffsrichtlinien

Eine Zugriffsrichtlinie ist ein Container für alle Ihre Access Context Manager-Ressourcen, z. B. Zugriffsebenen und Dienstperimeter.

Sie können eine Zugriffsrichtlinie im Kontext einer Organisation erstellen und die Zugriffsrichtlinie auf Organisationsebene überall in Ihrer Organisation verwenden. Wenn Sie die Verwaltung einer Zugriffsrichtlinie delegieren möchten, können Sie eine Zugriffsrichtlinie für Bereiche erstellen und den Bereich der Richtlinie auf Ordner- oder Projektebene festlegen. Der delegierte Administrator, dem die bereichsbezogene Richtlinie zugewiesen ist, kann nur die bereichsbezogene Zugriffsrichtlinie und nicht die Zugriffsrichtlinie auf Organisationsebene verwalten.

Die Version einer Zugriffsrichtlinie wird mit einer etag verwaltet. Mit etag können Sie Änderungen an Ihrer Zugriffsrichtlinie vornehmen, z. B. Änderungen an Zugriffsebenen oder an einer bestimmten Version der Richtlinie. Wenn mehrere Quellen Ihre Zugriffsrichtlinie ändern, können Sie mit dem Feld etag für das gcloud-Befehlszeilentool und API-Aufrufe unbeabsichtigte Überschreibungen und Konflikte vermeiden.

Informationen zum Erstellen von Zugriffsrichtlinien finden Sie unter Zugriffsrichtlinie erstellen.

Zugriffsebenen

Zugriffsebenen werden verwendet, um den Zugriff auf Ressourcen basierend auf Kontextinformationen über die Anfrage zu ermöglichen. Mithilfe von Zugriffsebenen können Sie Vertrauensebenen organisieren. Sie können beispielsweise eine Zugriffsebene mit dem Namen High_Level erstellen, die Anfragen von einer kleinen Gruppe berechtigter Personen zulässt. Sie können auch eine allgemeinere Gruppe angeben, der Sie vertrauen möchten, z. B. einen IP-Bereich, für den Sie Anfragen zulassen möchten. In diesem Fall können Sie eine Zugriffsebene mit dem Namen Medium_Level erstellen, um diese Anfragen zuzulassen.

Nachdem Sie Zugriffsebenen definiert haben, können Dienste zur Erzwingung diese verwenden, um zu bestimmen, ob eine Anfrage berücksichtigt werden soll. Sie können beispielsweise festlegen, dass für Medium_Trust viele Ressourcen verfügbar sind, für bestimmte sensiblere Ressourcen jedoch die Ebene High_Trust erforderlich ist. Diese Prüfungen werden zusätzlich zur Standard-IAM-Richtlinie angewendet.

Zugriffsebenen können angepasst werden. Die Zugriffsebenen High_Trust und Medium_Trust sind Beispiele. Sie können mehrere Zugriffsebenen als Teil einer Zugriffsrichtlinie angeben.

Access Context Manager bietet zwei Möglichkeiten, Zugriffsebenen zu definieren:

  • Eine einfache Zugriffsebene besteht aus einer Sammlung von Bedingungen, die zum Testen von Anfragen verwendet werden. Bedingungen können als eine Gruppe von Attributen definiert werden, die Sie testen möchten, z. B. Gerätetyp, IP-Adresse oder Nutzeridentität. Die Attribute werden entweder als AND-Vorgang (alle müssen wahr sein) oder als NOR-Vorgang (keines darf wahr sein) kombiniert, um zu bestimmen, ob die Bedingung erfüllt ist.

  • Benutzerdefinierte Zugriffsebenen werden mithilfe einer Teilmenge der Common Expression Language erstellt. Zusätzlich zum Anfragekontext für einfache Zugriffsebenen können Sie auch benutzerdefinierte Zugriffsebenen verwenden, um Anfragen basierend auf Daten von Drittanbieterdiensten zuzulassen. Weitere Informationen finden Sie unter Benutzerdefinierte Zugriffsebenen. 

!(origin.region_code in ['RU', 'BY', 'UA']) -> FAILED  // levels.regions_check

inIpRange(origin.ip, ['205.220.128.0/23']) -> GRANTED  // levels.ip_check

!(origin.region_code in ['RU', 'BY', 'UA']) || inIpRange(origin.ip, ['205.220.128.0/23']) -> GRANTED

levels.regions_check || levels.ip_check -> GRANTED

IP-Adresse

Sie können eine Zugriffsebene basierend auf der IP-Adresse der ursprünglichen Anfrage gewähren. Der Bereich der zulässigen IP-Adressen wird in Form eines CIDR-Blocks (Classless Inter-Domain Routing) angegeben, der eine detaillierte Kontrolle über die zulässigen IP-Adressen ermöglicht.

Eine Zugriffsebene kann mehrere IP-Adressbereiche enthalten.

Informationen zum Erstellen einer Zugriffsebene, die den Zugriff nur auf einen bestimmten Bereich von IP-Adressen zulässt, z. B. innerhalb eines einzelnen Unternehmensnetzwerks, finden Sie unter Zugriffsebene für den Zugriff auf Unternehmensnetzwerke erstellen.

Die folgenden IP-Bereiche werden von Access Context Manager als private Bereiche behandelt:

  • 10.0.0.0/8 (RFC 1918)
  • 172.16.0.0/12 (RFC 1918)
  • 192.168.0.0/16 (RFC 1918)
  • 100.64.0.0/10 (RFC 6598 Shared Address Space)
  • fc00::/7 (IPv6 Unique Local Addresses RFC 4193)

Gerätetyp

Access Context Manager verwendet die Endpunktprüfung, um Informationen zu Nutzergeräten wie Betriebssystem, Gerätetyp oder Version zu erfassen. Sie können eine Zugriffsebene basierend auf diesen Daten gewähren. Sie können beispielsweise Geräten, auf denen die neueste Version des primären Betriebssystems Ihres Unternehmens ausgeführt wird, eine weniger restriktive Zugriffsebene gewähren.

Informationen zum Gewähren einer Zugriffsebene basierend auf solchen Geräteattributen finden Sie unter Zugriff nach Gerätetyp einschränken.

Nutzeridentität

In einigen Szenarien möchten Sie bestimmten Entitäten möglicherweise eine Zugriffsebene gewähren. In diesen Szenarien bestimmt die Identität des Aufrufers, ob die Bedingung erfüllt ist. Dieses Szenario wird häufig zusammen mit Dienstkonten und VPC Service Controls verwendet. Beispielsweise können Sie dieses Szenario verwenden, um einer Cloud Functions-Funktion den Zugriff auf Daten zu ermöglichen, die durch VPC Service Controls geschützt sind.

Sie können reine Identitätszugriffsebenen mit dem gcloud-Befehlszeilentool erstellen und verwalten, aber nicht mit der Google Cloud -Console.

Informationen zum Erstellen einer einfachen Zugriffsebene finden Sie unter Zugriffsebene für Access Context Manager erstellen.

Informationen zum Erstellen einer Zugriffsebene, die den Zugriff basierend auf dem Kontext einer Anfrage ermöglicht, finden Sie unter Benutzerdefinierte Zugriffsebene erstellen.

Bedingungen kombinieren

Eine Zugriffsebene kann mehrere Bedingungen enthalten. Die Bedingungen können mit dem Operator AND oder OR ausgewertet werden. Sie können den Modus angeben, wenn Sie eine Zugriffsebene erstellen oder aktualisieren.

Der Fall AND ist die strengere und standardmäßige Option. Bei dieser Option wird die Zugriffsebene nur gewährt, wenn alle Bedingungen erfüllt sind. Sie können beispielsweise festlegen, dass eine Anfrage aus dem Unternehmensnetzwerk und von einem Gerät mit der neuesten Version eines Betriebssystems stammen muss.

OR ist eine weniger einschränkende Option. Bei dieser Option muss nur eine von vielen Bedingungen erfüllt sein. Dies ist manchmal nützlich, wenn Sie mit Nutzeridentitäten arbeiten, z. B. um bestimmte Entitäten (wie Dienstkonten) von den normalen Anforderungen auszuschließen.

Bedingungen verschachteln

Bedingungen können so verschachtelt werden, dass eine Bedingung von einer anderen Bedingung abhängt. Wenn Sie beispielsweise die beiden Zugriffsebenen „Mittleres Vertrauen“ und „Hohes Vertrauen“ haben, können Sie die Anforderungen für „Hohes Vertrauen“ so festlegen, dass zusätzlich zu anderen Bedingungen auch „Mittleres Vertrauen“ erforderlich ist.

Verschachtelte Bedingungen können die Verwaltung der Zugriffsebenen erleichtern. Sie können zum Beispiel festlegen, dass Ihre moderateste Zugriffsebene eine Mindestversion des Betriebssystems verlangt und dass die stärker einschränkenden Ebenen davon abhängig sind. Wenn Sie die Mindestversion in Zukunft aktualisieren, müssen Sie nur eine einzige Bedingung aktualisieren, anstatt jede Zugriffsebene in der Richtlinie.

Beachten Sie beim Verschachteln von Zugriffsebenen die folgenden Limits und Einschränkungen:

  • Keine Zirkelbezüge: Zirkelbezüge sind nicht zulässig. Zugriffsebenen können nicht in einer Schleife aufeinander verweisen, weder direkt (z. B. Level_A erfordert Level_B und Level_B erfordert Level_A, oder eine Zugriffsebene verweist auf sich selbst) noch transitiv (z. B. Level_A erfordert Level_B, Level_B erfordert Level_C und Level_C erfordert Level_A). Wenn Sie versuchen, eine Zugriffsebene zu erstellen oder zu aktualisieren, die eine zirkuläre Abhängigkeit einführt, schlägt der Aufruf mit dem Fehler INVALID_ARGUMENT fehl.

  • Maximale Abhängigkeiten pro Bedingung: In einer einfachen Zugriffsebene kann die requiredAccessLevels-Liste einer einzelnen Bedingung auf bis zu 15 andere Zugriffsebenen verweisen.

  • Verschachtelungstiefe: Da Access Context Manager verschachtelte Zugriffsebenen in der Reihenfolge ihrer Abhängigkeiten auswertet, anstatt sie rekursiv zu erweitern, gibt es keine separate maximale Tiefenbegrenzung für eine Kette verschachtelter Zugriffsebenen, die über das allgemeine Limit für Zugriffsebenen pro Zugriffsrichtlinie hinausgeht. Alle referenzierten Zugriffsebenen müssen zur selben Zugriffsrichtlinie gehören.

Weitere Informationen