Autorisierungsrichtlinien – Übersicht

Mit Autorisierungsrichtlinien können Sie sowohl Zugriffssteuerungsprüfungen als auch Prüfungen zur Bereinigung von Inhalten einrichten, wenn Anfragen oder Antworten über verschiedeneGoogle Cloud -Dienste wie Application Load Balancer, Agent Gateway (Private Preview) und Secure Web Proxy verarbeitet werden.

Bei Agent Gateway und Secure Web Proxy ist die Autorisierungsrichtlinie direkt an die Gateway-Ressource dieser Dienste angehängt. Bei einem Load Balancer ist die Autorisierungsrichtlinie an die Weiterleitungsregelressource des Load Balancers angehängt.

Hinweis :Obwohl sich Teile dieses Dokuments auf Autorisierungsrichtlinien in Bezug auf Cloud Load Balancing konzentrieren, gelten die hier behandelten Konzepte für Autorisierungsrichtlinien für alle oben genannten Google Cloud Dienste.

Mit einer Autorisierungsrichtlinie (AuthzPolicy), die an die Weiterleitungsregel eines Load-Balancers angehängt ist, können Sie Bedingungen festlegen, die die Autorisierung von Anfragen basierend auf ihrer Quelle und den beabsichtigten Vorgängen zulassen, einschränken oder delegieren. Anfragen, die diese Prüfungen bestehen, werden an den Backend-Dienst des Load-Balancers weitergeleitet. Anfragen, die diese Prüfungen nicht bestehen, werden mit einer nicht autorisierten Antwort abgelehnt.

Sie können Autorisierungsrichtlinien für die Weiterleitungsregel aller Application Load Balancer mit einem Load-Balancing-Schema von EXTERNAL_MANAGED oder INTERNAL_MANAGED konfigurieren. Die folgenden Application Load Balancer unterstützen Autorisierungsrichtlinien:

• Globale externe Application Load Balancer

• Regionale externe Application Load Balancer
• Regionale interne Application Load Balancer

• Regionsübergreifende interne Application Load Balancer

Regeln für Autorisierungsrichtlinien

Eine Autorisierungsrichtlinie besteht aus einer Liste von HTTP-Regeln, die mit der eingehenden Anfrage abgeglichen werden.

Für eine Autorisierungsrichtlinie mit der Aktion ALLOW oder DENY definiert eine HTTP-Regel (AuthzRule) die Bedingungen, die bestimmen, ob Traffic den Load Balancer passieren darf. Es ist mindestens eine HTTP-Regel erforderlich.

Für eine Autorisierungsrichtlinie mit der Aktion CUSTOM definiert eine HTTP-Regel (AuthzRule) die Bedingungen, die bestimmen, ob Traffic zur Autorisierung an den benutzerdefinierten Anbieter delegiert wird. Ein benutzerdefinierter Anbieter ist erforderlich, HTTP-Regeln sind optional.

Ein Richtlinienabgleich erfolgt, wenn mindestens eine HTTP-Regel mit der Anfrage übereinstimmt oder wenn in der Richtlinie keine HTTP-Regeln definiert sind.

Eine HTTP-Regel für eine Autorisierungsrichtlinie besteht aus den folgenden Feldern:

• from: Gibt die Identität des Clients an, der durch die Regel zugelassen wird. Die Identität kann aus einem Clientzertifikat in einer gegenseitigen TLS-Verbindung abgeleitet werden oder es kann sich um die Umgebungsidentität handeln, die der Client-VM-Instanz zugewiesen ist, z. B. aus einem Dienstkonto oder einem sicheren Tag.
• to: Gibt die von der Regel zulässigen Vorgänge an, z. B. die URLs, auf die zugegriffen werden kann, oder die zulässigen HTTP-Methoden.
• when: Hier können Sie zusätzliche Beschränkungen angeben, die erfüllt sein müssen. Sie können Common Expression Language (CEL)-Ausdrücke verwenden, um die Beschränkungen zu definieren.

Aktionen für Autorisierungsrichtlinien

Bei der Auswertung einer Anfrage gibt eine Autorisierungsrichtlinie die Aktion (AuthzAction) an, die auf die Anfrage angewendet werden soll. Eine Autorisierungsrichtlinie muss mindestens eine Aktion haben, die eine der folgenden sein kann:

• ALLOW: Die Anfrage kann an das Backend weitergeleitet werden, wenn sie mit einer der Regeln übereinstimmt, die in einer ALLOW-Richtlinie angegeben sind. Wenn ALLOW-Richtlinien vorhanden sind, aber keine Übereinstimmung vorliegt, wird die Anfrage abgelehnt. Mit anderen Worten: Die Anfrage wird abgelehnt, wenn keine der konfigurierten Autorisierungsrichtlinien mit einer ALLOW-Aktion der Anfrage entspricht. In Cloud Logging wird diese Aktion als denied_as_no_allow_policies_matched_request protokolliert.

  Damit eine ALLOW-Aktion angewendet werden kann, benötigen Sie mindestens eine HTTP-Regel.

• DENY: Die Anfrage wird abgelehnt, wenn sie mit einer der Regeln übereinstimmt, die in einer DENY-Richtlinie angegeben sind. Wenn DENY-Richtlinien vorhanden sind, aber keine Übereinstimmung vorliegt, wird die Anfrage zugelassen. Mit anderen Worten: Die Anfrage ist zulässig, wenn keine der konfigurierten Autorisierungsrichtlinien mit einer DENY-Aktion mit der Anfrage übereinstimmt. In Cloud Logging wird diese Aktion als allowed_as_no_deny_policies_matched_request protokolliert.

  Damit eine DENY-Aktion angewendet werden kann, benötigen Sie mindestens eine HTTP-Regel.

• CUSTOM: Die Autorisierungsentscheidung wird an einen benutzerdefinierten Autorisierungsanbieter wie IAP oder Diensterweiterungen delegiert. Weitere Informationen finden Sie unter Autorisierungsentscheidungen delegieren.

  Wenn für eine CUSTOM-Richtlinie HTTP-Regeln konfiguriert sind, muss die Anfrage mit den HTTP-Regeln übereinstimmen, damit der benutzerdefinierte Anbieter aufgerufen wird. Wenn jedoch keine HTTP-Regeln definiert sind, wird die Autorisierungsentscheidung in der Autorisierungsrichtlinie immer an einen benutzerdefinierten Autorisierungsanbieter delegiert. Weitere Informationen finden Sie in den Beispielen unter Autorisierungsrichtlinie zum Delegieren von Autorisierungsentscheidungen.

Reihenfolge der Auswertung von Autorisierungsrichtlinien

Eine Autorisierungsrichtlinie unterstützt CUSTOM-, DENY- und ALLOW-Richtlinien für die Zugriffssteuerung. Wenn einer einzelnen Ressource mehrere Autorisierungsrichtlinien zugeordnet sind, wird zuerst die CUSTOM-Richtlinie, dann die DENY-Richtlinie und schließlich die ALLOW-Richtlinie ausgewertet. Die Bewertung erfolgt nach den folgenden Regeln:

1. Wenn eine CUSTOM-Richtlinie vorhanden ist, die der Anfrage entspricht, wird die CUSTOM-Richtlinie mit einem benutzerdefinierten Autorisierungsanbieter ausgewertet. Wenn der benutzerdefinierte Anbieter die Anfrage ablehnt, wird sie abgelehnt. DENY- oder ALLOW-Richtlinien werden nicht ausgewertet, auch wenn sie konfiguriert sind.

2. Wenn DENY-Richtlinien vorhanden sind, die der Anfrage entsprechen, wird die Anfrage abgelehnt. ALLOW-Richtlinien werden nicht ausgewertet, auch wenn sie konfiguriert sind.

3. Wenn keine ALLOW-Richtlinien vorhanden sind, ist die Anfrage zulässig.

4. Wenn eine der ALLOW-Richtlinien der Anfrage entspricht, lassen Sie die Anfrage zu.

5. Wenn ALLOW-Richtlinien vorhanden sind, aber keine Übereinstimmung vorliegt, wird die Anfrage abgelehnt. Mit anderen Worten: Die Anfrage wird standardmäßig abgelehnt, wenn keine der konfigurierten AuthzPolicies mit ALLOW-Aktion mit der Anfrage übereinstimmt.

Für regionale externe Application Load Balancer, regionale interne Application Load Balancer, Agent Gateway und Secure Web Proxy –Google Cloud Dienste, die Richtlinienprofile unterstützen – ist die Reihenfolge der Autorisierungsrichtlinienauswertung so:

1. Wenn eine benutzerdefinierte Richtlinie zur Autorisierung von Anfragen (REQUEST_AUTHZ) mit der Anfrage übereinstimmt, wird die REQUEST_AUTHZ-Richtlinie mit einem benutzerdefinierten Autorisierungsanbieter ausgewertet. Wenn der benutzerdefinierte Anbieter die Anfrage ablehnt, wird sie abgelehnt. DENY-, ALLOW- und CONTENT_AUTHZ-Richtlinien werden nicht ausgewertet, auch wenn sie konfiguriert sind.

2. Wenn DENY-Richtlinien vorhanden sind, die der Anfrage entsprechen, wird die Anfrage abgelehnt. ALLOW- und CONTENT_AUTHZ-Richtlinien werden nicht ausgewertet, auch wenn sie konfiguriert sind.

3. Wenn keine ALLOW-Richtlinien vorhanden sind, wird die Anfrage mit der Auswertung der Inhaltsautorisierung (CONTENT_AUTHZ) fortgesetzt.

4. Wenn eine der ALLOW-Richtlinien mit der Anfrage übereinstimmt, wird die Anfrage zur CONTENT_AUTHZ-Auswertung weitergeleitet.

5. Wenn ALLOW-Richtlinien vorhanden sind, aber keine Übereinstimmung vorliegt, wird die Anfrage abgelehnt. CONTENT_AUTHZ-Richtlinien werden nicht ausgewertet.

6. Wenn eine CONTENT_AUTHZ-Richtlinie mit der Anfrage übereinstimmt, wird sie zuletzt ausgewertet. Wenn der benutzerdefinierte Anbieter die Anfrage ablehnt, wird sie abgelehnt.

Richtlinienprofile in Autorisierungsrichtlinien

Vorschau

Diese Funktion unterliegt den „Bedingungen für Pre-GA-Angebote“ im Abschnitt „Allgemeine Dienstbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA‑Funktionen stehen in der vorliegenden Form zur Verfügung und bieten möglicherweise nur eingeschränkten Support. Weitere Informationen finden Sie unter den Beschreibungen der Startphase.

Richtlinienprofile in Autorisierungsrichtlinien werden für die folgenden Google Cloud Dienste unterstützt:

• Regionale externe Application Load Balancer
• Regionale interne Application Load Balancer
• Agent Gateway
• Sicherer Web-Proxy

Ein Richtlinienprofil (PolicyProfile) in einer Autorisierungsrichtlinie kann die folgenden Typen haben:

• Autorisierungsprofil anfordern (REQUEST_AUTHZ): Hier werden Informationen in HTTP-Anfrageheadern verwendet, um Traffic zuzulassen oder abzulehnen.
• Profil für die Inhaltsautorisierung (CONTENT_AUTHZ): Bietet inhaltsbezogene Sicherheit und Filterung, um Prompt-Injection-Angriffe zu blockieren, Lecks sensibler Daten zu verhindern und schädliche Inhalte zu filtern.

Sie können eine Autorisierungsrichtlinie entweder mit einem REQUEST_AUTHZ-Profil oder einem CONTENT_AUTHZ-Profil konfigurieren, aber nicht mit beiden. Wenn kein Richtlinienprofil angegeben ist, wird standardmäßig das Profil REQUEST_AUTHZ verwendet.

Autorisierungsprofil anfordern

Autorisierungsrichtlinien, die das Richtlinienprofil REQUEST_AUTHZ verwenden, können Zugriffsentscheidungen für eingehenden Traffic entweder direkt auswerten oder delegieren. Sie können Zugriffsentscheidungen an Identity-Aware Proxy oder an eine benutzerdefinierte Autorisierungs-Engine delegieren, indem Sie eine Autorisierungserweiterung verwenden. Das REQUEST_AUTHZ-Richtlinienprofil basiert auf Informationen in den HTTP-Anfrageheadern, um eine Anfrage zuzulassen oder abzulehnen.

Auf eine Autorisierungsrichtlinie mit dem Richtlinienprofil REQUEST_AUTHZ kann die Aktion ALLOW, DENY oder CUSTOM angewendet werden. Eine Aktion vom Typ ALLOW oder DENY bedeutet, dass die Zugriffsentscheidung direkt ausgewertet wird. Bei einer Aktion vom Typ CUSTOM wird die Zugriffsentscheidung delegiert.

Wenn die Zugriffsentscheidung delegiert wird, verweist eine Autorisierungsrichtlinie, die für die Weiterleitungsregel des Load-Balancers konfiguriert ist, auf eine Erweiterung für die Anforderungsautorisierung, die in einem Callout-Backend-Dienst ausgeführt wird. Bei jeder Autorisierungsanfrage leitet der Load-Balancer die Anfrageheader über das ext_proc- oder ext_authz-Protokoll von Envoy an die Autorisierungserweiterung weiter. Abhängig von der Antwort der Erweiterung leitet der Load-Balancer-Proxy die Anfrage entweder an den zugehörigen Backend-Dienst weiter oder lehnt sie ab.

Wenn kein Richtlinienprofil angegeben ist, wird in der Autorisierungsrichtlinie standardmäßig das Autorisierungsprofil für Anfragen (REQUEST_AUTHZ) verwendet.

Profil für die Autorisierung von Inhalten

Autorisierungsrichtlinien mit dem Richtlinienprofil CONTENT_AUTHZ können verwendet werden, um die Nutzlasten Ihrer Anwendung genau zu untersuchen und Anfragen zuzulassen oder abzulehnen oder die Anfragen oder Antworten nach Bedarf zu ändern. Sie können Entscheidungen zum Zugriff entweder an Model Armor oder an Ihre eigene Erweiterung zur Bereinigung von Inhalten delegieren.

Auf eine Autorisierungsrichtlinie mit dem Richtlinienprofil CONTENT_AUTHZ kann nur die Aktion CUSTOM angewendet werden. Das bedeutet, dass die Anfrage nicht direkt bearbeitet werden kann und weitergeleitet werden muss.

Eine Autorisierungsrichtlinie, die in der Weiterleitungsregel des Load Balancers konfiguriert ist, verweist auf eine Erweiterung für die Inhaltsautorisierung. Bei jeder Autorisierungsanfrage leitet der Load Balancer den vollständigen Anfrage- und Antwortinhalt, einschließlich Headern, Text und Trailern, im Vollduplex-Streamingmodus (FULL_DUPLEX_STREAMED) über das ext_proc-Protokoll von Envoy an die Erweiterung für die Inhaltsautorisierung weiter. Je nach Antwort der Erweiterung leitet der Load-Balancer-Proxy die Anfrage entweder an ihr Ziel weiter oder lehnt sie ab. Das Ziel ist im Fall einer Anfrage der Backend-Dienst des Load Balancers und im Fall einer Antwort der Client.

Autorisierungsentscheidungen delegieren

Autorisierungsrichtlinien können direkt ausgewertet oder delegiert werden. Für komplexe Autorisierungsentscheidungen, die nicht mit einer Autorisierungsrichtlinie ausgedrückt werden können, können Sie eine Autorisierungsrichtlinie mit einer CUSTOM-Aktion erstellen und die Autorisierungsentscheidung über Diensterweiterungen an einen von Google verwalteten Dienst oder einen vom Nutzer verwalteten Dienst delegieren.

• Von Google verwalteter Dienst
  • Model Armor
  • Identity-Aware Proxy
• Nutzerverwalteter Dienst
  • ein Google Cloud Backend-Dienst
  • ein Dienst, der über einen voll qualifizierten Domainnamen (FQDN) zugänglich ist und das ext_proc- oder ext_authz-Protokoll von Envoy unterstützt

In der folgenden Tabelle sind die verschiedenen Dienste zusammengefasst, an die eine Autorisierungsentscheidung über Service Extensions delegiert werden kann.

Autorisierungsrichtlinie	Direkt bewertet	An Service Extensions delegiert (Autorisierungserweiterung)
		Von Google verwaltete Dienste		Nutzerverwaltete Dienste
		Model Armor	Identity-Aware Proxy	Google Cloud Backend-Dienst	FQDN-basierter Dienst
REQUEST_AUTHZ
CONTENT_AUTHZ

Diensterweiterungen

Mit Autorisierungsrichtlinien können Sie Autorisierungsentscheidungen an Service Extensions, insbesondere vom Typ „Autorisierungserweiterung“, delegieren. Autorisierungserweiterungen unterstützen Callouts, um benutzerdefinierte Logik in Google CloudApplication Load Balancer einzufügen. Mit dieser Funktion können Sie eigenen Code schreiben, um verschiedene Aktivitäten für Traffic auszuführen, der von einem Load Balancer verarbeitet wird, z. B. Header-Rewrites, inkrementelle Sicherheit, benutzerdefiniertes Logging und benutzerdefinierte Nutzerauthentifizierung.

Mit Service Extensions-Callouts weisen Sie den Load Balancer an, Traffic aus dem Load-Balancing-Datenverarbeitungspfad mithilfe von gRPC-Aufrufen an einen Callout-Dienst weiterzuleiten, der von Nutzern oder von Google verwaltet werden kann. Die verschiedenen Callout-Dienste sind in der vorherigen Tabelle definiert. Diese Callout-Dienste führen die Autorisierungserweiterung aus und können verschiedene Richtlinien oder Funktionen anwenden, bevor der Traffic zur weiteren Verarbeitung an den Load Balancer zurückgegeben wird. Das folgende Diagramm zeigt diesen Vorgang.

Autorisierungsrichtlinie, die die Autorisierungsentscheidung über eine Autorisierungserweiterung delegiert (zum Vergrößern klicken).

Wenn Sie Autorisierungsentscheidungen an eine Autorisierungserweiterung delegieren möchten, erstellen Sie eine Autorisierungserweiterung (AuthzExtension), die in einem Callout-Dienst ausgeführt wird. Anschließend können Sie eine Autorisierungsrichtlinie mit der Aktion CUSTOM erstellen und auf die von Ihnen erstellte Autorisierungserweiterung verweisen. Mit der Autorisierungserweiterung können sowohl die Autorisierung auf Anfrageebene (REQUEST_AUTHZ) als auch die Bereinigung von Inhalten (CONTENT_AUTHZ) durchgeführt werden.

Weitere Informationen dazu, wie Sie die Autorisierungsentscheidung an einen vom Nutzer verwaltetenGoogle Cloud -Backend-Dienst oder einen FQDN-basierten Dienst delegieren, finden Sie unter Autorisierungsentscheidung an einen vom Nutzer verwalteten Dienst delegieren.

Autorisierungserweiterungen im Datenverarbeitungspfad

Wenn Sie eine Autorisierungsentscheidung an Service Extensions delegieren, insbesondere an solche vom Typ Autorisierungserweiterung, beachten Sie die folgende Terminologie:

• Wenn eine benutzerdefinierte Autorisierungsrichtlinie mit einem REQUEST_AUTHZ-Richtlinienprofil auf eine Autorisierungserweiterung (AuthzExtension) verweist, wird die Autorisierungserweiterung als Anfrageautorisierungserweiterung bezeichnet.

• Wenn eine Autorisierungsrichtlinie mit einem CONTENT_AUTHZ-Richtlinienprofil auf eine Autorisierungserweiterung (AuthzExtension) verweist, wird die Autorisierungserweiterung als Inhaltsautorisierungserweiterung bezeichnet.

Im Pfad der Anforderungsverarbeitung wird zuerst eine Erweiterung für die Anforderungsautorisierung aufgerufen, gefolgt von der Richtlinienauswertung für „Verweigern“ und „Zulassen“, dann die Erweiterung für die Inhaltsautorisierung und schließlich die Traffic-Erweiterung. Eine Erweiterung zur Inhaltsautorisierung kann auch im Antwortverarbeitungspfad aufgerufen werden. Das folgende Diagramm zeigt die Reihenfolge, in der verschiedene Erweiterungen aufgerufen werden.

Hinweis :Die Erweiterung für die Autorisierung von Anfragen wird nur aufgerufen, wenn die Anfrageheader eingehen. Der Anfragetext sowie die Antwortheader und der Antworttext sind für die Erweiterung zur Anforderungsautorisierung nicht sichtbar.

Erweiterung für die Anforderungsautorisierung, die vor einer Erweiterung für die Inhaltsautorisierung aufgerufen wird (zum Vergrößern klicken).

Sie können sich verschiedene Erweiterungen als Hooks vorstellen, die an bestimmten Punkten des Datenverarbeitungspfads ausgelöst werden. Weitere Informationen zu den verschiedenen Erweiterungen finden Sie in der Dokumentation zu Service Extensions unter Extensibility points in the load balancing data path.

Model Armor

Mit Autorisierungsrichtlinien können Sie Model Armor aktivieren, um KI-Schutzmaßnahmen anzuwenden, die die Generierung schädlicher Inhalte, Prompt Injection und Datenlecks verhindern.

Dazu können Sie eine Autorisierungserweiterung (AuthzExtension) erstellen, die in einem Model Armor-Dienst ausgeführt wird. Anschließend können Sie eine Autorisierungsrichtlinie mit der Aktion CUSTOM und dem Profil CONTENT_AUTHZ erstellen, das auf die von Ihnen erstellte Autorisierungserweiterung verweist.

Weitere Informationen zum Delegieren der Autorisierung an Model Armor finden Sie unter Autorisierungsentscheidung an Model Armor delegieren.

Identity-Aware Proxy

Sie können Autorisierungsentscheidungen an Identity-Aware Proxy delegieren. IAP überprüft die Nutzeridentität und den Kontext der Anfrage, um festzustellen, ob ein Nutzer Zugriff auf eine Anwendung oder eine Ressource erhält.

Bei globalen externen Application Load Balancern und regionenübergreifenden internen Application Load Balancern können Sie die Autorisierungsentscheidung nicht über eine Autorisierungserweiterung an IAP delegieren.

Für regionale externe Application Load Balancer und regionale interne Application Load Balancer können Sie eine Autorisierungsrichtlinie konfigurieren, um die Autorisierungsentscheidung über eine Autorisierungserweiterung an IAP zu delegieren.

Weitere Informationen zur Verwendung von IAP als Autorisierungsdienst finden Sie unter Autorisierungsentscheidung an Identity-Aware Proxy delegieren.

Hauptkontobasierte Autorisierungsrichtlinie

Hinweis: Auf Prinzipalen basierende Autorisierungsrichtlinien werden für globale externe Application Load Balancer nicht unterstützt.

Um die Quelle des Traffics mit hoher Granularität zu ermitteln, können Sie Autorisierungsrichtlinien basierend auf Identitäten konfigurieren, die aus dem Zertifikat eines Clients abgeleitet werden. Für diese Methode muss Frontend-mTLS auf dem Load Balancer aktiviert sein. Außerdem werden die folgenden Zertifikatattribute als Hauptselektor zur Identifizierung verwendet:

• SANs des Clientzertifikat-URI (CLIENT_CERT_URI_SAN)
• SANs für DNS-Namen von Clientzertifikaten (CLIENT_CERT_DNS_NAME_SAN)
• Allgemeiner Name des Clientzertifikats (CLIENT_CERT_COMMON_NAME)

Wenn kein Prinzipal-Selektor für die Identifizierung angegeben ist, wird CLIENT_CERT_URI_SAN als Standard-Prinzipal-Selektor verwendet. Das bedeutet, dass die URI-SANs des Clientzertifikats bei der Autorisierung berücksichtigt werden.

Damit die prinzipalbasierte Autorisierung funktioniert, müssen die folgenden Bedingungen erfüllt sein:

• Frontend-mTLS muss aktiviert sein. Wenn Frontend-mTLS nicht aktiviert ist, legt der Client kein Zertifikat vor. Daher finden alle prinzipalbasierten Regeln in der Autorisierungsrichtlinie keine Zertifikatsinformationen, die ausgewertet werden können. Wenn beispielsweise eine Regel, die CLIENT_CERT_URI_SAN prüft, einen leeren Wert sieht,

• Es muss ein gültiges Clientzertifikat vorhanden sein. Auch wenn mTLS aktiviert ist, wird kein Clientzertifikat für die Autorisierung verwendet, wenn die Verbindung mit einem fehlenden oder ungültigen Zertifikat hergestellt wurde. Dieses Szenario tritt auf, wenn der mTLS-Clientvalidierungsmodus auf den permissiven Modus ALLOW_INVALID_OR_MISSING_CLIENT_CERT eingestellt ist. Auch in diesem Fall finden alle prinzipalbasierten Regeln in der Autorisierungsrichtlinie keine Zertifikatsinformationen, die ausgewertet werden können. Wenn beispielsweise eine Regel, die CLIENT_CERT_URI_SAN prüft, einen leeren Wert sieht,

Auswirkungen von Größenbeschränkungen für Attribute

Autorisierungsentscheidungen hängen von der Größe der Clientzertifikatattribute ab. Eine Anfrage wird abgelehnt, wenn ein Attribut sein Größenlimit überschreitet und die Richtlinie so konfiguriert ist, dass dieses Attribut validiert wird.

Eine Ablehnung kann unter den folgenden Bedingungen erfolgen:

• Die Richtlinie wird anhand von CLIENT_CERT_URI_SAN validiert und die URI-SANs des Zertifikats überschreiten die Größenbeschränkung.
• Die Richtlinie wird anhand von CLIENT_CERT_DNS_NAME_SAN validiert und die DNS-Namen-SANs des Zertifikats überschreiten die Größenbeschränkung.
• Die Richtlinie wird anhand von CLIENT_CERT_COMMON_NAME validiert und das Subject des Zertifikats (das den Common Name enthält) überschreitet die Größenbeschränkung.

Wenn das Attribut eines Zertifikats das Größenlimit überschreitet, aber nicht explizit vom Prinzipal-Selektor der Richtlinie validiert wird, wird die Anfrage trotzdem anhand der konfigurierten Prinzipalregeln ausgewertet. Wenn beispielsweise eine Richtlinie so konfiguriert ist, dass nur CLIENT_CERT_DNS_NAME_SAN validiert wird, wird eine Anfrage von einem Client mit zu großen URI-SANs aus diesem Grund nicht abgelehnt. Die Richtlinie fährt mit der Auswertung der Anfrage anhand der SANs des DNS-Namens fort.

Ein Beispiel für eine auf Hauptkonten basierende Autorisierungsrichtlinie finden Sie unter Autorisierungsrichtlinie zum Ablehnen von Anfragen.

Autorisierungsrichtlinie basierend auf Dienstkonten oder sicheren Tags

Eine Autorisierungsrichtlinie, die auf Dienstkonten oder sicheren Tags basiert, wird für die folgenden Load Balancer unterstützt:

• Regionale interne Application Load Balancer
• Regionsübergreifende interne Application Load Balancer

Hinweis: Das Anwenden von Autorisierungsrichtlinien basierend auf Dienstkonten oder Tags wird für externe Application Load Balancer nicht unterstützt.

Mit Autorisierungsrichtlinien, die auf Dienstkonten und sicheren Tags basieren, können Sie Sicherheitsregeln basierend darauf erzwingen, wer oder was den Traffic sendet, und nicht nur auf der IP-Adresse. Dies führt zu einer Umstellung von IP-basierten Regeln auf identitätsbasierte Kontrollen, bei denen Dienstkonten und sichere Tags verwendet werden, um den Sicherheitsbereich zu definieren. Sie können beispielsweise eine Autorisierungsrichtlinie erstellen, um Folgendes zu tun:

• einer Compute Engine-VM mit einem bestimmten Dienstkonto (my-sa-123@PROJECT_ID.iam.gserviceaccount.com) den Zugriff auf den Pfad /api/payments verweigern.

• Compute Engine-VMs mit einem sicheren Tag (Schlüssel/Wert-Paar environment: prod) dürfen den Pfad /api/payments erreichen.

Sie können Autorisierungsrichtlinien basierend auf Dienstkonten oder sicheren Tags anwenden, die an verschiedene Google Cloud -Dienste angehängt sind. Traffic, der von diesen Google Cloud Diensten stammt und mit einem bestimmten Dienstkonto oder einem sicheren Tag verknüpft ist, kann entweder zugelassen, abgelehnt oder zur weiteren Auswertung delegiert werden.

In der folgenden Tabelle sind die verschiedenen Google Cloud Dienste aufgeführt, die die Verwendung von Dienstkonten und sicheren Tags unterstützen.

Google Cloud -Dienst	Support für Dienstkonten	Unterstützung für sichere Tags
Compute Engine-VM (virtuelle Maschine)
Google Kubernetes Engine (GKE)-Knoten
Google Kubernetes Engine-Container (GKE)	^1	^1
Direct VPC für Cloud Run		^1
Connector für serverlosen VPC-Zugriff	^2	^2
Cloud VPN	^1	^1
Cloud Interconnect vor Ort	^1	^1
Application Load Balancer	^3	^3
Network Load Balancer	^3	^3

¹ Wird von Google Cloudnicht unterstützt.

² Die Quell-IP-Adresse ist eindeutig und kann stattdessen verwendet werden.

³ Dienstkonten und Tags werden nicht unterstützt, wenn Application Load Balancer und Network Load Balancer als Traffic-Quellen in einer mehrstufigen Architektur dienen.

In der folgenden Tabelle sind die verschiedenen VPC-Architekturen (Virtual Private Cloud) aufgeführt, die die Verwendung von Dienstkonten und Tags unterstützen.

VPC	VPC-Architektur	Support
Innerhalb von VPC	Projektübergreifend (freigegebene VPC)
Innerhalb von VPC	Regionenübergreifend
VPC-übergreifend	Cross-Peering-Link (Peering-VPC)
VPC-übergreifend	Cross Private Service Connect
VPC-übergreifend	Cross Network Connectivity Center-Spokes

Weitere Informationen zum Einrichten einer Autorisierungsrichtlinie, die auf Dienstkonten und Tags basiert, die an eine Google Cloud Ressource angehängt sind, finden Sie unter Autorisierungsrichtlinie basierend auf Dienstkonten oder Tags.

Kontingente

Informationen zu Kontingenten für Autorisierungsrichtlinien finden Sie unter Kontingente und Limits für Autorisierungsrichtlinien.

Preise

Preisinformationen finden Sie unter Netzwerkpreise: Cloud Load Balancing.

Nächste Schritte

• Autorisierungsrichtlinien für Application Load Balancer einrichten

• Autorisierungserweiterung konfigurieren