OAuth-Clients freigeben

Auf dieser Seite wird beschrieben, wie Sie einen OAuth-Client für eine andere Anwendung in Ihrer Organisation freigeben.

Übersicht

Wenn Sie OAuth-Clients für mehrere Projekte freigeben, verwenden Sie einen einzelnen benutzerdefinierten OAuth-Client für mehrere IAP-geschützte Anwendungen (Identity-Aware Proxy), anstatt für jede Anwendung einen neuen OAuth-Client zu erstellen. Dieser Ansatz vereinfacht die Verwaltung, insbesondere für Organisationen mit vielen Anwendungen.

Beim Konfigurieren von IAP können Sie einen von zwei OAuth-Clienttypen verwenden:

  • Von Google verwalteter OAuth-Client: IAP verwendet diesen standardmäßig automatisch. Für diese integrierte Option ist keine manuelle Clienterstellung erforderlich, sie hat jedoch zwei wichtige Einschränkungen:

    • Nur Zugriff für Nutzer innerhalb Ihrer Organisation (interne Nutzer)
    • Auf dem Zustimmungsbildschirm wird Google Cloud das Branding von Google anstelle des Brandings Ihrer Organisation angezeigt.

  • Benutzerdefinierter OAuth-Client: Sie erstellen und verwalten diesen selbst. Diese Option:

    • Kann von mehreren Anwendungen gemeinsam genutzt werden
    • Ermöglicht die Anpassung des Brandings auf dem Zustimmungsbildschirm
    • Unterstützt den Zugriff für externe Nutzer (außerhalb Ihrer Organisation)

Wenn Sie einen benutzerdefinierten OAuth-Client erstellen, können Sie ihn flexibel für eine einzelne Anwendung verwenden oder für mehrere Anwendungen freigeben. Die Freigabe eines benutzerdefinierten OAuth-Clients bietet mehrere Vorteile:

  • Reduziert den Verwaltungsaufwand bei der Verwaltung mehrerer Kunden
  • Vereinfacht die Aktivierung von IAP für Teammitglieder, die keinen Zugriff auf die Seite „Anmeldedaten“ haben sollten
  • Ermöglicht den programmatischen (nicht browserbasierten) Zugriff auf Anwendungen, die durch IAP geschützt sind.

Informationen zum Erstellen von OAuth-Clients finden Sie unter OAuth-Clients für IAP erstellen. Weitere Informationen zu von Google verwalteten OAuth-Clients finden Sie unter OAuth-Konfiguration anpassen, um IAP zu aktivieren.

Hinweis

Erstellen Sie einen neuen OAuth-Client, indem Sie die Schritte unter OAuth-Client erstellen ausführen, oder verwenden Sie einen vorhandenen OAuth-Client.

Programmatischer Zugriff

OAuth-Clients für den programmatischen Zugriff konfigurieren, damit sich nicht browserbasierte Anwendungen bei Ihren IAP-geschützten Ressourcen authentifizieren können. So können Skripts, automatisierte Jobs und Back-End-Dienste sicher auf Ihre geschützten Anwendungen zugreifen, ohne dass sich ein Nutzer interaktiv anmelden muss.

Sie können diese Authentifizierungseinstellungen auf jeder Ebene Ihrer Ressourcenhierarchie anwenden: Organisation, Ordner oder Projekt.

Eine Anleitung zur Implementierung finden Sie im Leitfaden zur programmatischen Authentifizierung und in der Dokumentation zur Verwaltung von IAP-Einstellungen.

gcloud

  1. Bereiten Sie eine Einstellungsdatei mit Ihren OAuth-Client-IDs vor:

    cat << EOF > SETTINGS_FILENAME
  access_settings:
    oauth_settings:
      programmatic_clients: [clientId1, clientId2, ..]
EOF

  2. Wenden Sie die Einstellungen mit dem Befehl gcloud iap settings set an:

    gcloud iap settings set SETTINGS_FILENAME \
  [--organization=ORGANIZATION | --folder=FOLDER | --project=PROJECT] \
  [--resource-type=RESOURCE_TYPE] \
  [--service=SERVICE] \
  [--version=VERSION]

    Beispiele für Befehle:

    # Organization level
gcloud iap settings set SETTINGS_FILENAME --organization=ORGANIZATION

# Folder level
gcloud iap settings set SETTINGS_FILENAME --folder=FOLDER

# Project level (web resources)
gcloud iap settings set SETTINGS_FILENAME \
  --project=PROJECT \
  --resource-type=iap_web

# App Engine service in a project
gcloud iap settings set SETTINGS_FILENAME \
  --project=PROJECT \
  --resource-type=app-engine \
  --service=SERVICE

    Wobei:

    • SETTINGS_FILENAME: Die von Ihnen vorbereitete YAML-Datei.
    • ORGANIZATION: Die Organisations-ID
    • FOLDER: Die Ordner-ID
    • PROJECT: die Projekt-ID
    • RESOURCE_TYPE: Der IAP-Ressourcentyp (app-engine, iap_web, compute, organization oder folder)
    • SERVICE: Der Dienstname (optional für die Ressourcentypen compute oder app-engine)
    • VERSION: Der Versionsname (nicht zutreffend für compute, optional für app-engine)

API

  1. JSON-Datei mit Einstellungen vorbereiten:

    cat << EOF > iap_settings.json
{
  "access_settings": {
    "oauth_settings": {
      programmatic_clients: [clientId1, clientId2, ..]
    }
  }
}
EOF

  2. Ressourcennamen abrufen:

    gcloud iap settings get \
  [--organization=ORGANIZATION | --folder=FOLDER | --project=PROJECT] \
  [--resource-type=RESOURCE_TYPE] \
  [--service=SERVICE] \
  [--version=VERSION]

  3. Aktualisieren Sie die Einstellungen mit dem Ressourcennamen:

    curl -X PATCH \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-d @iap_settings.json \
"https://iap.googleapis.com/v1/RESOURCE_NAME:iapSettings?updateMask=iapSettings.accessSettings.oauthSettings.programmaticClients"

    Wobei:

    • ORGANIZATION: Die Organisations-ID
    • FOLDER: Die Ordner-ID
    • PROJECT: die Projekt-ID
    • RESOURCE_TYPE: Der IAP-Ressourcentyp (app-engine, iap_web, compute, organization oder folder)
    • SERVICE: Der Dienstname (optional für die Ressourcentypen compute oder app-engine)
    • VERSION: Der Versionsname (nicht zutreffend für compute, optional für app-engine)

Melden Sie sich nach der Konfiguration mit einer der konfigurierten OAuth-Client-IDs in der Anwendung an. Weitere Informationen finden Sie unter Programmatische Authentifizierung.

Browserzugriff

Führen Sie die folgenden Schritte aus, um IAP zu aktivieren, damit Ihre Client-ID und Ihr Secret über dieGoogle Cloud Console verwendet werden:

Risiken

Es ist zwar bequem, einen Client für mehrere Anwendungen freizugeben, aber es birgt auch Risiken. In diesem Abschnitt wird beschrieben, welche potenziellen Risiken bei der gemeinsamen Nutzung von Clients bestehen und wie sie reduziert werden können.

Single Point Of Failure

Wenn Sie einen OAuth-Client für viele Anwendungen verwenden, wird ein Single Point Of Dependency erstellt. Wird ein Client fälschlicherweise gelöscht oder geändert, hat dies Auswirkungen auf jede Anwendung, die diesen Client verwendet. Gelöschte OAuth-Clients können innerhalb von 30 Tagen wiederhergestellt werden.

So können Sie dieses Betriebsrisiko effektiv managen:

Dies ist in erster Linie ein Betriebsrisiko und kein Sicherheitsrisiko. Mit geeigneten Zugriffssteuerungen und Monitoring überwiegen die Vorteile der gemeinsamen Nutzung von OAuth-Clients in Bezug auf Komfort und Verwaltung in der Regel diese Überlegung.

Schwachstellen bei Clientschlüsseln

Damit Sie einen Client freigeben können, müssen Sie Ihren Clientschlüssel für andere Personen und Skripts freigeben. Dadurch sind Ihre Clientschlüssel einem größeren Risiko ausgesetzt, in falsche Hände zu gelangen. IAP kann nicht unterscheiden, ob Tokens von Ihrer Anwendung oder aus einem gehackten Clientschlüssel erstellt wurden.

So können Sie dieses Risiko minimieren:

  • Clientschlüssel wie Passwörter schützen und niemals als Klartext speichern
  • Implementieren Sie die sichere Verwaltung von Anmeldedaten mit Secret Manager.
  • Zugriff auf Ihre IAP-Ressourcen mit Cloud-Audit-Logging überwachen
  • Ein offengelegter Clientschlüssel wirkt sich nur auf die Authentifizierung aus, nicht auf die Autorisierung für den Zugriff auf Ressourcen. Wenn Sie vermuten, dass Ihr Secret offengelegt wurde, setzen Sie es sofort zurück.

Für den programmatischen Zugriff auf IAP-geschützte Ressourcen sollten Sie die JWT-Authentifizierung für Dienstkonten verwenden, anstatt OAuth-Clientgeheimnisse für einzelne Nutzer freizugeben. Dieser Ansatz bietet eine bessere Sicherheitsisolation und behält gleichzeitig die Vorteile eines gemeinsamen OAuth-Clients für Ihre Anwendungen bei.

Hinweise zum Umfang der Berechtigung

Wenn Sie OAuth-Clients freigeben, verwenden alle Anwendungen dieselben Berechtigungsbereiche. Für IAP sind openid und email die einzigen erforderlichen Bereiche. Diese Überlegung an sich stellt kein erhebliches Risiko dar, aber es ist wichtig, Folgendes zu verstehen:

  • OAuth wird in IAP nur für die Authentifizierung (Identitätsüberprüfung) verwendet. Die Autorisierung (Ressourcenzugriff) wird separat über IAM-Richtlinien verwaltet.
  • Selbst wenn Anmeldedaten für die Authentifizierung kompromittiert werden, benötigt ein Angreifer weiterhin die entsprechenden IAM-Berechtigungen, um auf geschützte Ressourcen zuzugreifen.
  • Wenn Sie den Client auf die erforderlichen openid- und email-Bereiche beschränken, können Sie potenzielle Sicherheitsrisiken begrenzen.