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.

Bei der Konfiguration von IAP können Sie einen der beiden OAuth-Clienttypen verwenden:

  • Von Google verwalteter OAuth-Client: Dieser wird von IAP standardmäßig verwendet. Bei dieser integrierten Option muss kein Client manuell erstellt werden. Es gibt jedoch zwei wichtige Einschränkungen:

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

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

    • Kann für mehrere Anwendungen freigegeben werden
    • Ermöglicht die Anpassung des Brandings auf dem Einwilligungsbildschirm
    • Unterstützt den Zugriff für externe Nutzer (außerhalb Ihrer Organisation)

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

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

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

Hinweise

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

Konfigurieren Sie OAuth-Clients für den programmatischen Zugriff, damit sich nicht browserbasierte Anwendungen bei Ihren mit IAP geschützten Ressourcen authentifizieren können. So können Scripts, automatisierte Jobs und Back-End-Dienste ohne interaktive Nutzeranmeldung sicher auf Ihre geschützten Anwendungen zugreifen.

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

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

gcloud

  1. Erstellen Sie eine Konfigurationsdatei mit Ihren OAuth-Client-IDs:

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

  2. Einstellungen mit dem Befehl gcloud iap settings set anwenden:

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

    Beispielbefehle:

    # 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: Dienstname (optional für compute- oder app-engine-Ressourcentypen)
    • VERSION: Versionsname (nicht 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: Dienstname (optional für compute- oder app-engine-Ressourcentypen)
    • VERSION: Versionsname (nicht für compute, optional für app-engine)

Melden Sie sich nach der Konfiguration mit einer der von Ihnen 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 ermöglichen, Ihre Client-ID und Ihr Secret über dieGoogle Cloud -Konsole zu verwenden:

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 Failure 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 verwalten:

Dies ist in erster Linie ein Betriebsrisiko und kein Sicherheitsrisiko. Bei geeigneten Zugriffssteuerungen und Überwachungsmaßnahmen überwiegen die Vorteile von freigegebenen OAuth-Clients in Bezug auf Benutzerfreundlichkeit 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 minimieren Sie dieses Risiko:

  • Clientschlüssel wie Passwörter schützen und niemals als Klartext speichern
  • Sichere Anmeldedatenverwaltung mit Secret Manager implementieren
  • Zugriff auf IAP-Ressourcen mit Cloud-Audit-Logging überwachen
  • Ein geleakter Clientschlüssel wirkt sich nur auf die Authentifizierung aus, nicht auf die Autorisierung zum Zugriff auf Ressourcen. Wenn Sie vermuten, dass Ihr Secret gehackt 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 Sicherheitsisolierung und behält gleichzeitig die Vorteile eines freigegebenen OAuth-Clients für Ihre Anwendungen bei.

Hinweise zum Umfang der Berechtigung

Wenn OAuth-Clients freigegeben werden, verwenden alle Anwendungen dieselben Berechtigungsbereiche. Für IAP sind openid und email die einzigen erforderlichen Bereiche. Dieser Aspekt ist an sich kein erhebliches Risiko, aber es ist wichtig, Folgendes zu wissen:

  • OAuth wird in IAP nur für die Authentifizierung (Identitätsbestätigung) verwendet. Die Autorisierung (Ressourcenzugriff) wird separat über IAM-Richtlinien verwaltet.
  • Selbst wenn Anmeldedaten manipuliert 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 minimieren.