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.
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 Zugriffsebenen an, die die Hauptbevollmächtigten 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 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:
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.
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 dem Hauptkonto alle nicht übernommenen Rollen für die ausgewählte Ressource entziehen möchten, klicken Sie erst auf das Kästchen und dann auf Entfernen.
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 die folgenden 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 diecurl
-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 Rolleiap.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 MethodesetIamPolicy
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
undsetIamPolicy
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 diecurl
-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 Rolleiap.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 MethodesetIamPolicy
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 auffoo.com
normalisiertcafé.fr
wird aufxn--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:
-
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. 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.
- Autorisierte Zugriffe sind mit einem blauen
- 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.