Diese Seite wurde von der Cloud Translation API übersetzt.

Kontextsensitiven Zugriff mit Identity-Aware Proxy einrichten

In diesem Leitfaden wird gezeigt, wie Sie IAP-Zugriffsrichtlinien (Identity-Aware Proxy) mithilfe von Zugriffsebenen und mit IAM Conditions Framework (Identity and Access Management) erweitern. Zugriffsebenen ermöglichen Zugriffsbeschränkungen für Ressourcen auf Grundlage der IP-Adresse und der Endnutzergeräteattribute. Die IAM-Bedingungen ermöglichen Zugriffsbeschränkungen auf Grundlage von URL-Hosts, Pfaden, Datum und Uhrzeit.

Abhängig von der Richtlinienkonfiguration kann Ihre vertrauliche Anwendung beispielsweise:

Allen Mitarbeitern Zugriff gewähren, wenn sie ein vertrauenswürdiges Unternehmensgerät im Unternehmensnetzwerk verwenden.
Den Mitarbeitern der Gruppe Remotezugriff Zugriff gewähren, wenn sie ein vertrauenswürdiges Unternehmensgerät mit einem sicheren Passwort und mit den aktuellen Patches in einem beliebigen Netzwerk verwenden.
Den Mitarbeitern in der Gruppe Privilegierter Zugriff nur dann Zugriff gewähren, wenn der URL-Pfad mit /admin beginnt.

Vorbereitung

Für den Start ist Folgendes erforderlich:

Eine mit IAP gesicherte Anwendung, für die Sie Zugriffsrechte für Einzelpersonen oder Gruppen hinzufügen möchten.
Nutzer- oder Gruppennamen, denen Sie Zugriff gewähren möchten.

Zugriffsebene einrichten

Wenn Sie den Zugriff auf der Grundlage der IP-Adresse oder von Endnutzer-Geräteattributen beschränken möchten, müssen Sie eine Zugriffsebene erstellen. Informationen zum Erstellen einer Zugriffsebene finden Sie im Leitfaden zu Access Context Manager. IAP ordnet den Namen der Zugriffsebene einer mit IAP gesicherten Anwendung zu.

Die Verwendung von Richtlinien mit Gültigkeitsbereich wird von IAP nicht unterstützt. Zugriffsebenen müssen in der Zugriffsrichtlinie der Organisation festgelegt werden. Weitere Informationen finden Sie unter Zugriffsrichtlinie erstellen.

IAM-Richtlinie bearbeiten

Eine mit IAP gesicherte Anwendung hat eine IAM-Richtlinie, die die IAP-Rolle an die Anwendung bindet.

Durch das Hinzufügen einer bedingten IAM-Bindung zur IAM-Richtlinie wird der Zugriff auf Ihre Ressourcen auf der Grundlage von Anfrageattributen weiter eingeschränkt. Diese Anfrageattribute umfassen:

Zugriffsebenen
URL-Host/-Pfad
Datum/Uhrzeit

Beachten Sie, dass in einer bedingten IAM-Bindung festgelegte Anfragewerte, die mit request.host und request.path verglichen werden, exakt angegeben werden müssen. Wenn Sie beispielsweise den Zugriff auf Pfade beschränken, die mit /internal admin beginnen, kann man die Beschränkung über /internal%20admin umgehen. Weitere Informationen zu Hostnamen- und Pfadbedingungen finden Sie unter Hostnamen- und Pfadbedingungen verwenden.

Fügen Sie der IAM-Richtlinie bedingte Bindungen hinzu und bearbeiten Sie sie. Führen Sie hierzu die unten beschriebenen Schritte durch.

Console

So fügen Sie eine bedingte Bindung mithilfe der Google Cloud Console hinzu:

Rufen Sie die IAP-Administratorseite auf.
Zur IAP-Administratorseite
Klicken Sie auf das Kästchen neben den Ressourcen, für die Sie IAM-Berechtigungen aktualisieren möchten.
Klicken Sie auf der rechten Seite im Infobereich auf Hauptkonto hinzufügen.
Geben Sie im Feld Neues Hauptkonto die Hauptkonten ein, denen Sie eine Rolle zuweisen möchten.
Wählen Sie in der Drop-down-Liste Rolle auswählen die Rolle Nutzer von IAP-gesicherten Web-Apps aus und geben Sie Bedingungen für Zugriffsebenen an, die die Hauptkonten erfüllen müssen, um auf die Ressource zugreifen zu können.
- Wenn Sie vorhandene Zugriffsebenen festlegen möchten, wählen Sie diese in der Drop-down-Liste Zugriffsebenen aus. Sie müssen die Rolle Nutzer von IAP-gesicherten Web-Apps auswählen und Berechtigungen auf Organisationsebene haben, um vorhandene Zugriffsebenen aufrufen zu können. Ihnen muss eine der folgenden Rollen zugewiesen werden:
  - Access Context Manager-Administrator
  - Access Context Manager-Bearbeiter
  - Access Context Manager-Leser
- Zum Erstellen und Verwalten von Zugriffsebenen verwenden Sie Access Context Manager.
Wenn Sie den Hauptkonten weitere Rollen hinzufügen möchten, klicken Sie auf Weitere Rolle hinzufügen.
Wenn Sie mit dem Hinzufügen von Rollen fertig sind, klicken Sie auf Speichern.

Sie haben der Ressource jetzt eine bedingte Bindung hinzugefügt.

So entfernen Sie eine bedingte Bindung:

Rufen Sie die IAP-Administratorseite auf.
Zur IAP-Administratorseite
Klicken Sie auf das Kästchen neben der Ressource, von der Sie die IAM-Rolle eines Hauptkontos entfernen möchten.
Klicken Sie auf der rechten Seite im Infofeld unter Rolle/Hauptkonto auf die Rolle, die Sie dem Hauptkonto entziehen möchten.
Klicken Sie neben dem Hauptkonto auf Entfernen.
Klicken Sie im Dialogfeld Rolle des Hauptkontos entfernen auf Entfernen. Wenn Sie alle nicht übernommenen Rollen aus dem Hauptkonto für die ausgewählte Ressource entfernen möchten, klicken Sie das Kästchen an, bevor Sie auf Entfernen klicken.

gcloud

Derzeit können Sie das gcloud-Tool nur zum Festlegen von bedingten Bindungen auf Projektebene verwenden.

Zum Festlegen bedingter Bindungen bearbeiten Sie die Datei policy.yaml Ihres Projekts in folgender Weise:

Öffnen Sie mit dem folgenden gcloud-Befehl die IAM-Richtlinie für die Anwendung:
```
gcloud iap web get-iam-policy --project=PROJECT_ID > policy.yaml
```
Bearbeiten Sie die Datei policy.yaml, um Folgendes anzugeben:
- Die Nutzer und Gruppen, auf die Sie die IAM-Bedingung anwenden möchten.
- Die Rolle iap.httpsResourceAccessor, die ihnen Zugriff auf die Ressourcen gewährt.
- Die IAM-Bedingung.
  
  Das folgende Snippet zeigt eine IAM-Bedingung mit nur einem festgelegten Attribut. Diese Bedingung gewährt dem Nutzer und der Gruppe Zugriff, wenn die Zugriffsebenenanforderungen für ACCESS_LEVEL_NAME erfüllt sind und der Ressourcen-URL-Pfad mit / beginnt.
```
bindings:
...
  - members:
    - group:EXAMPLE_GROUP@GOOGLE.COM
    - user:EXAMPLE_USER@GOOGLE.COM
    role: roles/iap.httpsResourceAccessor
    condition:
              expression: "accessPolicies/ORGANIZATION_NUMBER/accessLevels/ACCESS_LEVEL_NAME" in
                          request.auth.access_levels && request.path.startsWith("/")
              title: CONDITION_TITLE
...
```
Binden Sie die Richtlinie mithilfe des Befehls set-iam-policy an die Anwendung.
```
gcloud iap web set-iam-policy --project=PROJECT_ID policy.yaml
```

Die Cloud IAM-Richtlinie enthält jetzt eine bedingte Bindung.

API

Zum Bearbeiten der Datei policy.json Ihrer Anwendung gehen Sie wie unten für Ihren Anwendungstyp dargestellt vor. Weitere Informationen zum Verwenden der IAM API für das Verwalten von Zugriffsrichtlinien finden Sie unter Zugriff auf Ressourcen verwalten, die mit IAP gesichert sind.

Bevor Sie die folgenden anwendungsspezifischen API-Schritte ausführen, exportieren Sie Folgendes: Variablen:

 export PROJECT_NUM=PROJECT_NUMBER
 export IAP_BASE_URL=https://iap.googleapis.com/v1/projects/${PROJECT_NUM}/iap_web
 # Replace POLICY_FILE.JSON with the name of JSON file to use for setIamPolicy
 export JSON_NEW_POLICY=POLICY_FILE.JSON

App Engine

Exportieren Sie die folgenden App Engine-Variablen:

# The APP_ID is usually the project ID
export GAE_APP_ID=APP_ID
export GAE_BASE_URL=${IAP_BASE_URL}/appengine-${GAE_APP_ID}

Rufen Sie die IAM-Richtlinie für die App Engine-Anwendung mit der Methode getIamPolicy ab. Das leere Datenbit am Ende wandelt die curl-Anfrage in POST anstelle von GET um.
```
curl -i -H "Authentication: Bearer $(gcloud auth print-access-token)" \
${GAE_BASE_URL}/:getIamPolicy -d ''
```
Fügen Sie der JSON-Datei der IAM-Richtlinie die bedingte IAM-Bindung hinzu. Im Folgenden finden Sie ein Beispiel für eine bearbeitete Datei policy.json, mit der die Rolle iap.httpsResourceAccessor an zwei Nutzer gebunden und diesen Zugriff auf die mit IAP gesicherten Ressourcen gewährt wird. Es wurde eine IAM-Bedingung hinzugefügt, damit sie nur dann Zugriff auf die Ressourcen haben, wenn die Zugriffsebenenanforderung für ACCESS_LEVEL_NAME erfüllt ist und der URL-Pfad der Ressource mit / beginnt. Es kann nur eine Bedingung pro Bindung geben.

Beispieldatei policy.json
```
{
"policy": {
"bindings": [
{
  "role": "roles/iap.httpsResourceAccessor",
  "members": [
      "group:EXAMPLE_GROUP@GOOGLE.COM",
      "user:EXAMPLE_USER@GOOGLE.COM"
  ],
  "condition": {
    "expression": ""accessPolicies/ORGANIZATION_NUMBER/accessLevels/ACCESS_LEVEL_NAME" in request.auth.access_levels && request.path.startsWith("/")",
    "title": "CONDITION_NAME"
  }
}
]
}
}
```

Legen Sie die neue Datei policy.json mit der Methode setIamPolicy fest.

curl -i -H "Authentication: Bearer $(gcloud auth print-access-token)" \
${GAE_BASE_URL}:setIamPolicy -d @${JSON_NEW_POLICY}

App Engine-Dienste und -Versionen

Sie können auch die IAM-Richtlinie eines App Engine-Dienstes, aller Versionen oder einer bestimmten Version eines Dienstes aktualisieren. Führen Sie die folgenden Schritte für eine bestimmte Version eines Dienstes aus:

Exportieren Sie die folgenden zusätzlichen Variablen.

export GAE_SERVICE=SERVICE_NAME
export GAE_VERSION=VERSION_NAME

Aktualisieren Sie die exportierte Variable GAE_BASE_URL.

export GAE_BASE_URL=${IAP_BASE_URL}/appengine-${GAE_APP_ID}/services/${GAE_SERVICE}/versions/${GAE_VERSION}

Rufen Sie die IAM-Richtlinie für die Version ab und richten Sie sie mithilfe der oben dargestellten Befehle getIamPolicy und setIamPolicy ein.

GKE und Compute Engine

Exportieren Sie die Projekt-ID Ihres Back-End-Dienstes.
```
export BACKEND_SERVICE_NAME=BACKEND_SERVICE_NAME
```
Rufen Sie die IAM-Richtlinie für die Compute Engine-Anwendung mit der Methode getIamPolicy ab. Das leere Datenbit am Ende wandelt die curl-Anfrage in POST anstelle von GET um.
```
curl -i -H "Authentication: Bearer $(gcloud auth print-access-token)" \
 ${IAP_BASE_URL}/compute/services/${BACKEND_SERVICE_NAME}:getIamPolicy \
 -d ''
```
Fügen Sie der JSON-Datei der IAM-Richtlinie die bedingte IAM-Bindung hinzu. Im Folgenden finden Sie ein Beispiel für eine bearbeitete Datei policy.json, mit der die Rolle iap.httpsResourceAccessor an zwei Nutzer gebunden und diesen Zugriff auf die mit IAP gesicherten Ressourcen gewährt wird. Es wurde eine IAM-Bedingung hinzugefügt, damit sie nur dann Zugriff auf die Ressourcen haben, wenn die Zugriffsebenenanforderung für ACCESS_LEVEL_NAME erfüllt ist und der URL-Pfad der Ressource mit / beginnt. Es kann nur eine Bedingung pro Bindung geben.

Beispieldatei policy.json
```
{
"policy": {
"bindings": [
{
"role": "roles/iap.httpsResourceAccessor",
"members": [
  "group":EXAMPLE_GROUP@GOOGLE.COM,
  "user:EXAMPLE_USER@GOOGLE.COM"
],
"condition": {
  "expression": ""accessPolicies/ORGANIZATION_NUMBER/accessLevels/ACCESS_LEVEL_NAME" in request.auth.access_levels && request.path.startsWith("/")",
  "title": "CONDITION_NAME"
}
}
]
}
}
```

Legen Sie die neue Datei policy.json mit der Methode setIamPolicy fest.

curl -i -H "Content-Type:application/json" \
     -H "Authentication: Bearer $(gcloud auth print-access-token)" \
     ${IAP_BASE_URL}/compute/services/${BACKEND_SERVICE_NAME}:setIamPolicy \
     -d @${JSON_NEW_POLICY}

Hostnamen- und Pfadbedingungen verwenden

Der Zugriff auf Ihre Anwendung kann mithilfe des Hostnamens und des Pfads einer Anfrage-URL gesichert werden. Beispielsweise kann die IAM-Bedingung request.path.startsWith dazu verwendet werden, Mitarbeitern der Gruppe Privilegierter Zugriff nur dann Zugriff zu gewähren, wenn der URL-Pfad mit /admin beginnt.

Weitere Informationen zur Verwendung von Hostnamen- und Pfadbedingungen finden Sie unter Anfrageattribute.

Stringnormalisierung

Eine URL hat einen Hostnamen und einen Pfad. Beispielsweise enthält die URL https://sheets.google.com/create?query=param einen Hostnamen von sheets.google.com und einen Pfad von /create.

Back-Ends können Hostnamen und Pfade auf verschiedene Arten interpretieren. IAP normalisiert beim Prüfen der Richtlinien Hostnamen und Pfadstrings, um Mehrdeutigkeiten zu beseitigen.

IAP führt zwei Richtlinienprüfungen durch, wenn eine Anfrage einen nicht normalisierten Pfad enthält. Wenn der nicht normalisierte Pfad die Richtlinienprüfung besteht, normalisiert IAP den Pfad und eine zweite Richtlinienprüfung wird ausgeführt. Der Zugriff wird gewährt, wenn sowohl der nicht normalisierte als auch der normalisierte Pfad die Richtlinienprüfung bestehen.

Wenn eine Anfrage beispielsweise den Pfad /internal;some_param/admin enthält, führt IAP zuerst eine Richtlinienprüfung für den nicht normalisierten Pfad aus (/internal). Wenn diese Prüfung bestanden wird, führt IAP eine zweite Richtlinienprüfung für den normalisierten Pfad aus (/internal/admin).

Hostnamen

So werden Hostnamen normalisiert:

Punkte am Ende entfernen
Umwandlung in Kleinbuchstaben durchführen
Umwandlung in ASCII durchführen

Hostnamen, die Nicht-ASCII-Zeichen enthalten, werden mithilfe von Punycode weiter normalisiert. Sie müssen den Hostnamenstring mithilfe von Punycode umwandeln, damit ein Abgleich erfolgen kann.

Verwenden Sie dafür einen Converter wie Punycoder.

Im Folgenden finden Sie Beispiele für normalisierte Hostnamen:

FOO.com wird auf foo.com normalisiert
café.fr wird auf xn--caf-dma.fr normalisiert

Pfade

So werden Pfade normalisiert:

Pfadparameter entfernen
Relative Pfade in ihre absolute Entsprechung auflösen

Ein Pfadparameter enthält alle Zeichen von einem ; bis entweder zum nächsten / oder zum Ende des Pfads.

Anfragen, die am Anfang eines Pfadabschnitts ..; enthalten, gelten als ungültig. Beispiel: /..;bar/ und /bar/..;/ geben den Fehler HTTP 400: Bad Request zurück.

Im Folgenden finden Sie Beispiele für normalisierte Pfade:

/internal;some_param/admin wird auf /internal/admin normalisiert
/a/../b wird auf /b normalisiert
/bar;param1/baz;baz;param2 wird auf /bar/baz normalisiert

Subdomain-Endungen

Eine mit request.host.endsWith("google.com") festgelegte Richtlinie entspricht sowohl sub_domain.google.com wie testgoogle.com. Wenn Sie Ihre Richtlinie auf alle Subdomains beschränken möchten, die mit google.com enden, legen Sie Ihre Richtlinie auf request.host.endsWith(".google.com") fest.

Beachten Sie, dass die Festlegung Ihrer Richtlinie auf request.host.endsWith(".google.com") der Subdomain sub_domain.google.com entspricht, wegen des zusätzlichen Zeichens . aber nicht google.com.

Cloud-Audit-Logs und Zugriffsebenen

Durch Aktivieren von Cloud-Audit-Logging für Ihr mit IAP gesichertes Projekt können Sie feststellen, welche autorisierten und nicht autorisierten Zugriffsanfragen gesendet wurden. Prüfen Sie mit den zugehörigen Audit-Logs die Anfragen und alle Zugriffsebenen, die ein Anfragender erfüllt hat. Führen Sie hierzu folgende Schritte aus:

Zur Google Cloud Console Log-Explorer für Ihr Projekt.
Zur Seite „Logs“
Wählen Sie in der Drop-down-Liste Ressourcenauswahl eine Ressource aus. Mit IAP gesicherte HTTPS-Ressourcen befinden sich unter GAE-Anwendung und GCE-Back-End-Dienst. Mit IAP gesicherte SSH- und TCP-Ressourcen befinden sich unter einer GCE-VM-Instanz.
Wählen Sie in der Drop-down-Liste Logtyp die Option data_access aus.
- Der Logtyp data_access wird nur angezeigt, wenn nach dem Aktivieren von Cloud-Audit-Logging für IAP Traffic zu Ihrer Ressource gesendet wurde.
Maximieren Sie das Datum und die Uhrzeit des Zugriffs, den Sie untersuchen möchten.
- Autorisierte Zugriffe sind mit einem blauen i-Symbol gekennzeichnet.
- Nicht autorisierte Zugriffe haben ein orangefarbenes !!-Symbol.
Rufen Sie die vom Anfragenden erfüllten Zugriffsebenen auf. Erweitern Sie hierzu die Abschnitte durch Klicken, bis Sie protoPayload > requestMetadata > requestAttributes > auth > accessLevels erreichen.

Wenn Sie eine Anfrage aufrufen, werden alle Zugriffsebenen, die ein Nutzer erfüllt hat, aufgeführt, einschließlich Zugriffsebenen, die für den Zugriff nicht erforderlich waren. Für eine nicht autorisierte Anfrage wird aber nicht angezeigt, welche Zugriffsebenen nicht erfüllt wurden. Dazu müssen Sie die Bedingungen für die Ressource mit den Zugriffsebenen vergleichen, die für die Anfrage angegeben werden.

Weitere Informationen zu Logs finden Sie in der Anleitung Cloud-Audit-Logging.