Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

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. Mit Zugriffsebenen können Sie den Zugriff auf Ressourcen basierend auf der IP-Adresse und den Attributen des Endnutzergeräts einschränken. 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.

Hinweis

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 anhand der IP-Adresse oder der Attribute des Endnutzergeräts einschränken möchten, erstellen Sie eine Zugriffsebene. Für einige Attribute, z. B. Geräteattribute, ist eine Chrome Enterprise Premium-Lizenz erforderlich. Die Lizenzvalidierung erfolgt nur, wenn Sie Zugriffsebenen konfigurieren, und hat keine Auswirkungen auf den Laufzeitzugriff. Informationen zum Erstellen einer Zugriffsebene finden Sie im Leitfaden zu Access Context Manager. IAP verwendet den Namen der Zugriffsebene, um sie mit einer IAP-gesicherten Anwendung zu verknüpfen.

Die Verwendung von bereichsbezogenen Richtlinien 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.

Wenn Sie der IAM-Richtlinie eine bedingte IAM-Bindung hinzufügen, wird der Zugriff auf Ihre Ressourcen basierend auf 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 mit 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 die Bedingungen für die Zugriffsebene an, die die Hauptkonten erfüllen müssen, um auf die Ressource zuzugreifen.
- 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 das Kästchen neben der Ressource an, für die Sie die IAM-Rolle eines Hauptkontos entfernen möchten.
Klicken Sie im rechten Infofeld unter Rolle / Hauptkonto auf die Rolle, die Sie aus dem Hauptkonto entfernen möchten.
Klicken Sie neben dem Hauptkonto auf Entfernen.
Klicken Sie im Dialogfeld Rolle vom Hauptkonto entfernen auf Entfernen. Wenn Sie alle nicht übernommenen Rollen des Hauptkontos für die ausgewählte Ressource entfernen möchten, setzen Sie ein Häkchen, 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.

Exportieren Sie die folgenden Variablen, bevor Sie die unten aufgeführten anwendungsspezifischen API-Schritte ausführen:

 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

 1. Export the following App Engine variables:
 <pre class="devsite-click-to-copy prettyprint lang-html" suppresswarning="suppresswarning">
 \# The APP_ID is usually the project ID
 export GAE_APP_ID=<var>APP_ID</var>
 export GAE_BASE_URL=${IAP_BASE_URL}/appengine-${GAE_APP_ID}</pre>

 1. Get the IAM policy for the App Engine app using the `getIamPolicy` method. The empty data bit at the end turns the `curl` request into POST instead of GET.

curl -i -H "Authentication: Bearer $(gcloud auth print-access-token)" \\
    ${GAE_BASE_URL}/:getIamPolicy -d ''

1. Fügen Sie der JSON-Datei der IAM-Richtlinie die bedingte IAM-Bindung hinzu. Das folgende Beispiel zeigt eine bearbeitete „policy.json“-Datei, die die Rolle „iap.httpsResourceAccessor“ an zwei Nutzer bindet und ihnen Zugriff auf die IAP-gesicherten Ressourcen gewährt. Es wurde eine IAM-Bedingung hinzugefügt, um ihnen nur dann Zugriff auf die Ressourcen zu gewähren, wenn die Anforderung der Zugriffsebene ACCESS_LEVEL_NAME erfüllt ist und der URL-Pfad der Ressource mit „/“ beginnt. Jede Bindung kann nur eine Bedingung haben.

**Beispiel für eine policy.json-Datei**

{
"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"
          }
        }
        ]
  }
}

1. 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

 You can also update the IAM policy of a App Engine
 service, all versions, or a specific version of a service. To do this for a specific version of a service:

 1. Export the following additional variables.

    export GAE_SERVICE=SERVICE_NAME
    export GAE_VERSION=VERSION_NAME

1. 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}

1. Rufen Sie die IAM-Richtlinie für die Version mit den oben gezeigten Befehlen getIamPolicy und setIamPolicy ab und legen Sie sie fest.

### GKE und Compute Engine

1. Exportieren Sie die Projekt-ID Ihres Backend-Dienstes.

     export BACKEND_SERVICE_NAME=BACKEND_SERVICE_NAME

 2. Get the IAM policy for the Compute Engine app using the `getIamPolicy` method. The empty data bit at the end turns the `curl` request into POST instead of GET.
 <pre class="devsite-click-to-copy prettyprint lang-html" suppresswarning="suppresswarning">
 curl -i -H "Authentication: Bearer $(gcloud auth print-access-token)" \\
     ${IAP_BASE_URL}/compute/services/${BACKEND_SERVICE_NAME}:getIamPolicy \\
     -d ''</pre>
 3. Add your IAM conditional binding to the IAM policy JSON file.
    The following is an example of an edited `policy.json` file that binds the
    `iap.httpsResourceAccessor` role to two users, granting them access to the IAP-secured resources. An IAM
    condition has been added to grant them access to the resources only if the <var>ACCESS_LEVEL_NAME</var> access level requirement is met and the resource URL path starts with `/`.
    Each binding can have only one condition.

    <br/>**Example policy.json file**

{
  "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"
        }
      }
    ]
  }
}

4. 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}

Bedingungen für Hostnamen und Pfad 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

Wenn Sie Cloud-Audit-Logs für Ihr IAP-gesichertes Projekt aktivieren, können Sie autorisierte und nicht autorisierte Zugriffsanfragen sehen. So rufen Sie Anfragen und alle Zugriffsebenen auf, die ein Anfragender erfüllt hat:

Rufen Sie in der Google Cloud Console den Log-Explorer für Ihr Projekt auf.
Zur Seite „Logs“
Wählen Sie in der Drop-down-Liste Ressourcenauswahl eine Ressource aus. IAP-gesicherte HTTPS-Ressourcen befinden sich unter App Engine-Anwendung und Compute Engine-Backend-Dienst. IAP-gesicherte SSH- und TCP-Ressourcen finden Sie unter Compute Engine-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.

Kontextsensitiven Zugriff mit Identity-Aware Proxy einrichten Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.