von Johannes Klampfl
Die Arbeit im Online-Marketing-Bereich erfordert oft den Export von Daten aus verschiedenen Google-Quellen. Dieser Blog-Artikel beginnt daher mit einer Einführung in Google APIs und wie man auf sie zugreift. Darüber hinaus konzentrieren wir uns auf API-Authentifizierungsmethoden und erklären, wie sie funktionieren und wann welche verwendet werden sollte. Abschließend betrachten wir die Identitätswechsel von Dienstkonten, ein leistungsstarkes Tool zum Freischalten sicherer und optimierter Berechtigungen in Google Cloud, das die Zugriffskontrolle vereinfacht und die Sicherheit mühelos erhöht.
Webanalyse steht für Messbarkeit und ist die Grundlage für langfristige Erfolgskontrolle und Effizienzsteigerung Ihrer (Online) Marketing Aktivitäten.
Mehr ErfahrenDieser Blogartikel konzentriert sich auf eine Node.js-Implementierung, was bedeutet, dass einige Links Sie zur entsprechenden Node.js-Dokumentation führen. Dennoch wird der Großteil generisch sein und gilt für alle Programmiersprachen.
Google APIs (Schnittstellen) sind verschiedene Arten von Computerprogrammen, die Ihnen bei verschiedenen Aufgaben helfen. Es gibt zwei Möglichkeiten, um herauszufinden, welche Arten von Google-APIs es gibt. Einerseits bietet der Google Cloud Marketplace Informationen zu Anwendungsmöglichkeiten oder Pricing der APIs. Die andere Möglichkeit besteht darin, sich die API-Bibliothek der GCP-Konsole anzusehen, die noch mehr Google-APIs enthält.
Beim Durchlesen der offiziellen Google-Dokumentation scheint der Begriff „Google-APIs“ für alle APIs von Google verwendet zu werden, und „Google Cloud-APIs“ oder einfach nur „Cloud-APIs“ wird für die Teilmenge von APIs verwendet, die sich auf die Google Cloud beziehen. Diese Blog-Artikelserie wird sich mit allen Google-APIs befassen. Um nur einige zu nennen: Campaign Manager 360 API, Google Analytics Reporting API, BigQuery API etc.
Es gibt zwei Optionen, um eine Liste dieser APIs zu erhalten, aber es scheint, dass diese Optionen nicht die selben/vollständigen APIs auflisten (Google Cloud Marketplace: 314-APIs vs. API-Bibliothek: 414-APIs). Ich würde empfehlen, die API-Bibliotheksseite zu verwenden, wollte aber eine Alternative für Nicht-GCP-Benutzer zeigen.
Eine Möglichkeit, eine Auflistung von Google Cloud-APIs zu erhalten, führt über den Google Cloud Marketplace.
Dieser Marktplatz ist eine Sammlung von Softwareprodukten und -diensten, die auf der GCP verfügbar sind. Der obige Link enthält zusätzlich einen Filter, der die Ergebnisse auf die Anzeige von Google-Produkten reduziert. Sie müssen kein GCP-Konto haben oder angemeldet sein, um diese API-Übersicht sehen zu können. Durch Klicken auf eine der angezeigten Google Cloud APIs werden wichtige Links angezeigt, z.B. zur Dokumentation, zum API-Explorer etc. und es wird das Pricing angezeigt (falls es sich um eine kostenpflichtige API handelt).
Screenshot Google Cloud Marketplace, Quelle: e-dialog
Nur als Randbemerkung: Für die meisten APIs der Google Cloud Platform gibt es keinen separaten Eintrag. Ein Beispiel zur Verdeutlichung: Sie werden keinen Eintrag für „BigQuery API“ finden, sondern nur den GCP-Dienst „BigQuery“, der dann auf die BigQuery-API-Dokumentation verweist.
Google Cloud Marketplace Suchergebnis für ‚BigQuery‘, Quelle: e-dialog
Die zweite Methode, um eine Liste der Google-APIs zu erhalten, ist über die Google Cloud Platform-Konsole und den Menüpunkt: GCP > APIs und Dienste > Bibliothek.
Wie die GCP API Bibliothek zu finden ist., Quelle: e-dialog
Auf alle diese Google APIs kann nur über die Google Cloud Platform zugegriffen werden. Wenn Sie eine davon verwenden möchten, muss die entsprechende API zuerst aktiviert werden unter: GCP > APIs & Dienste > Aktivierte APIs und Dienste > + APIs und Dienste aktivieren. Alle aktivierten Google-APIs für das ausgewählte Projekt werden auf derselben Seite aufgelistet.
APIs und Services in der GCP aktivieren, Quelle: e-dialog
Auf viele Google-APIs kann über den Google-APIs-Explorer zugegriffen werden, der eine großartige Möglichkeit bietet, mit API-Methoden zu interagieren, ohne Code schreiben zu müssen. Er kann für Debugging- und Lernzwecke verwendet werden. Um dieses Tool nutzen zu können, ist die oben erläuterte Aktivierung der entsprechenden API nicht erforderlich.
Google empfiehlt die Verwendung ihrer Client-Bibliotheken, um mit ihren APIs zu interagieren. Wenn die seltene Situation eintritt, dass diese Bibliotheken Ihre spezifischen Anforderungen nicht erfüllen, können Sie Ihren eigenen Code schreiben, um direkt auf diese APIs zuzugreifen.
Es existieren ebenfalls mobile Firebase-Clientbibliotheken, welche hier nicht weiter behandelt werden.
Die empfohlenen und neueren Bibliotheken heißen „Google Cloud Client Libraries“. Diese Bibliotheken unterstützen REST und gRPC, handhaben die Authentifizierung und bieten einen intuitiven und konsistenten Stil über alle APIs und Sprachen hinweg. Derzeit zeigt die folgende Liste 116 APIs, auf die über den Node.js-Client zugegriffen werden kann.
Diese Clients verwenden im Hintergrund „Google Auth Library“ zur Authentifizierung, die folgende Authentifizierungsmethoden anbietet:
Die zweite und ältere Bibliothek heißt „Google API Client Libraries“. Google empfiehlt, diese Bibliotheken nur dann zu verwenden, wenn die „Google Cloud Client Library“ die gewünschte Sprache nicht unterstützt. Diese Bibliotheken unterstützen REST (nicht gRPC) und übernehmen die Authentifizierung. Die folgende Seite bietet eine Dokumentation für 228 APIs, auf die über Node.js zugegriffen werden kann.
Folgende Autehntifizierungsmethoden werden unterstützt:
Jede Google-API hat unterschiedliche Kontingente, was bedeutet, dass die API-Nutzung limitiert ist. Die wichtigsten API Metriken können über GCP > IAM und Admin > Quoten oder über GCP > APIs und Dienste > API auswählen > Registerkarte QUOTAS angezeigt werden. Es ist möglich, Kontingene zu reduzieren (z. B. um Kosten zu sparen) oder eine Erhöhung über ein Formular zu beantragen.
API Quota in der GCP prüfen, Quelle: e-dialog
Es gibt mehrere Methoden für die Authentifizierung von Google APIs. Dieser Blog-Artikel konzentriert sich auf die wichtigsten Authentifizierungsmethoden und erklärt, wie sie funktionieren und wann welche Methode zu verwenden ist.
Wenn ein API-Schlüssel verwendet werden muss, wird dies durch die Google API selbst festgelegt und kann nicht von der aufrufenden Anwendung entschieden werden. Es gibt spezifische Google APIs, die die Verwendung eines API-Schlüssels erfordern, wie zum Beispiel die Google Maps JavaScript API, die Google Geocoding API und die Google Picker API.
API-Schlüssel können im Google Cloud Platform Console erstellt werden. Ihr Zweck besteht darin, die Anwendung oder das Projekt zu identifizieren, das die API aufruft. Dadurch kann Google API-Quoten und Kosten auf Grundlage der API-Nutzung durchsetzen.
API-Schlüssel gelten im Allgemeinen als nicht sicher, da sie oft auf der Client-Seite verwendet werden. Die oben genannte Google Maps JavaScript API wird auf der Frontend-Seite implementiert, und somit ist der API-Schlüssel für jeden sichtbar.
Um die Sicherheit von API-Schlüsseln zu erhöhen, bietet Google die Möglichkeit, sie auf bestimmte Websites, IP-Adressen, Android-Anwendungen oder iOS-Anwendungen zu beschränken. Darüber hinaus können API-Schlüssel darauf beschränkt werden, nur bestimmte APIs aufrufen zu können.
ADC ist ein Verfahren, das von den Google-Authentifizierungsbibliotheken (z. B. Google Auth Library: Node.js Client) verwendet wird, um automatisch Anmeldeinformationen basierend auf der Anwendungsumgebung zu finden. Aufgrund von ADC muss der Code nicht zwischen Entwicklungs- und Produktionsumgebungen geändert werden.
ADC sucht nach Anmeldeinformationen in folgender Reihenfolge/Orten:
Umgebungsvariable GOOGLE_APPLICATION_CREDENTIALS: Der erste Ort, die Umgebungsvariable, kann auf einen Speicherort verweisen, an dem eine Anmeldeinformationen-JSON-Datei abgelegt ist. Es wird nicht empfohlen, Service Account Keys für dieses Szenario herunterzuladen und zu verwenden. Der Hauptanwendungsfall besteht darin, eine Anmeldeinformationskonfigurationsdatei für die Workload Identity Federation zu verwenden, was nicht Gegenstand dieses Artikels ist.
Benutzeranmeldeinformationen über gcloud: Bei der lokalen Arbeit werden normalerweise Benutzeranmeldeinformationen über den Befehl gcloud auth login bereitgestellt. Dennoch wird ADC diese Anmeldeinformationen nicht verwenden. Stattdessen verwendet es nur Anmeldeinformationen, die über gcloud auth application-default login bereitgestellt werden. Beide Befehle öffnen denselben Authentifizierungsfluss, wie im Screenshot unten zu sehen ist.
OAuth2 und JWTs (nächstes Kapitel) werden beide für die Authentifizierung und Autorisierung verwendet und weisen einige Ähnlichkeiten auf:
OAuth wird hauptsächlich verwendet, um Drittanbietern den Zugriff auf Ressourcen im Namen eines Benutzers zu gewähren. Diese Technologie wird oft für soziale Anmeldungen (ermöglicht Benutzern, sich bei einer Website oder Anwendung mit ihren Social-Media-Konten anzumelden) und den Zugriff auf APIs von Drittanbietern verwendet (siehe Beispiel unten).
Wenn OAuth in Kombination mit einem Dienstkonto verwendet wird, wird das oben gezeigte Anmelde-Popup (oder ein ähnliches) nicht angezeigt.
Normalerweise sind drei Parteien daran beteiligt, einen OAuth-Flow zu realisieren.
Im OAuth-Flow beantragt die Client-Anwendung zunächst die Autorisierung des Ressourcenbesitzers, um auf die Ressource zuzugreifen. Sobald der Ressourcenbesitzer die Autorisierung erteilt, sendet die Client-Anwendung eine Anfrage an den Autorisierungsserver, um ein Zugriffstoken zu erhalten. Der Autorisierungsserver überprüft die Identität des Clients und die Autorisierung des Ressourcenbesitzers und stellt ein Zugriffstoken aus. Die Client-Anwendung kann dann das Zugriffstoken verwenden, um im Auftrag des Ressourcenbesitzers auf die Ressource zuzugreifen.
In einigen Fällen kann auch eine vierte Partei beteiligt sein: der Ressourcenserver. Der Ressourcenserver ist der Server, der die Ressource hostet, auf die die Client-Anwendung zugreifen möchte. In diesem Fall verwendet die Client-Anwendung das Zugriffstoken, das vom Autorisierungsserver erhalten wurde, um die Ressource vom Ressourcenserver anzufordern. Der Ressourcenserver überprüft das Zugriffstoken und stellt die angeforderte Ressource an die Client-Anwendung aus, wenn es gültig ist.
Dieser Standard verwendet in der Regel eine Kombination aus Zugriffstoken und Auffrischungstoken. Zugriffstoken sind kurzlebige Token (laufen nach einer Stunde oder weniger ab) und werden regelmäßig gegen neue Zugriffstoken ausgetauscht. Um ein neues Zugriffstoken vom Autorisierungsserver zu erhalten, verwendet die Client-Anwendung das langlebige Zugriffstoken (läuft nach Tagen oder Wochen ab). Daher werden OAuth-Tokens in der Regel vom Autorisierungsserver überprüft.
Je nachdem, wo der OAuth-Flow stattfinden soll, stehen verschiedene Bibliotheken zur Verfügung (z. B. für serverseitige Webanwendungen, für JavaScript-Webanwendungen, für Dienstkonten).
JWT wird hauptsächlich für die Authentifizierung und Autorisierung von Benutzern und Diensten in einer Anwendung oder einem System verwendet. Es ist daher besonders nützlich für die Kommunikation von Server zu Server und von Server zu API.
Zusätzliche Unterschiede zu OAuth sind:
Im Bereich des Online-Marketings, insbesondere bei der Ausfuhr von Google-Daten (Zugriff auf APIs von Drittanbietern), wird OAuth häufig als Authentifizierungsmethode verwendet. Gelegentlich wird jedoch auch JWT verwendet. Der entsprechende Node.js-Code könnte ähnlich aussehen wie der folgende:
const { google } = require("googleapis");
const jwt = new google.auth.JWT(
process.env.CLIENT_EMAIL,
null,
process.env.PRIVATE_KEY,
scopes
);
Dieser Ansatz ist nur möglich, wenn ein Dienstkonto und eine Schlüsseldatei für das Dienstkonto (nicht empfohlen) verwendet werden. Darüber hinaus muss die entsprechende API diese JWT-Methode unterstützen. Sie können mehr darüber hier lesen.
Sie können in GCP Dienstkonten erstellen, die dann verwendet werden können, um Anfragen an Google APIs zu stellen. Diese Konten sind nützlich, um die Anwendung unabhängig von bestimmten Benutzerkonten zu machen (stellen Sie sich vor, ein Kollege verlässt das Unternehmen) und sind der empfohlene Ansatz.
Beim Aufrufen von GCP-APIs (z. B. BigQuery) benötigt das Dienstkonto die entsprechenden IAM-Rollen, während beim Aufrufen von Nicht-GCP-APIs (z. B. Google Analytics) das Dienstkonto zum entsprechenden Konto hinzugefügt werden muss.
Oft werden diese Dienstkonten in Kombination mit OAuth2 verwendet, es gibt jedoch eine andere Möglichkeit: Schlüsseldateien. Sie sollten diese Option vermeiden, wenn möglich, aufgrund der folgenden Risiken: Offenlegung von Anmeldeinformationen (ein böswilliger Akteur erhält Zugriff auf Ressourcen), Eskalation von Privilegien (ein böswilliger Akteur verwendet das Dienstkonto, um seine eigenen Privilegien zu eskalieren) und Identitätsmaskierung (ein böswilliger Akteur verschleiert seine Identität durch das Dienstkonto).
Nachfolgend finden Sie ein Beispiel für Node.js-Code zur Verwendung einer Schlüsseldatei:
const {google} = require('googleapis');
const auth = new google.auth.GoogleAuth({
keyFile: '/path/to/your-secret-key.json',
scopes: ['https://www.googleapis.com/auth/cloud-platform'],
});
Die Identität eines Dienstkontos in der Google Cloud Platform (GCP) ist ein leistungsstarkes Tool zur effektiven Verwaltung von Berechtigungen. Benutzer können damit vorübergehend die Berechtigungen eines Dienstkontos übernehmen, wodurch die Zugriffskontrolle optimiert und die mit langlebigen Schlüsseln verbundenen Sicherheitsrisiken verringert werden.
Ein Servicekonto in Google Cloud Platform (GCP) ist ein spezielles Benutzerkonto, das von Anwendungen, Servern oder automatisierten Prozessen und nicht von einer echten Person verwendet wird. Dieses Servicekonto verfügt über spezielle Berechtigungen zum Ausführen bestimmter Aufgaben in GCP. Solche Servicekonten sind praktisch, da sie unabhängig von Benutzerkonten sind (denken Sie an die Fluktuation der Mitarbeiter).
Stellen wir uns vor, einem bestimmten Servicekonto ist auf Projektebene die Rolle „BigQuery-Administrator“ zugewiesen, um einen täglichen Datenupload durchzuführen. Dem Benutzerkonto des Entwicklers ist nur die Rolle „BigQuery-Datenbetrachter“ zugewiesen.
Die Identitätsübernahme eines Servicekontos ist nun so, als würde man jemanden eine „Maske“ dieses Servicekontos tragen lassen, um eine Aufgabe zu erledigen. In unserem Fall fungiert der Entwickler als Servicekonto (nimmt die Identität an), um dessen privilegiertere Berechtigungen nutzen zu können. Dadurch kann der Entwickler Aufgaben ausführen, die durch die Rolle „BigQuery-Administrator“ zulässig sind, z. B. neue Tabellen erstellen.
Eines muss erwähnt werden: Der Entwickler kann diese Identitätsübernahme nur durchführen, wenn das Benutzerkonto des Entwicklers über die erforderlichen Berechtigungen dafür verfügt. Eine Rolle, die die Identitätswechsel von Servicekonten ermöglicht, ist „Service Account Token Creator“ (see Google documentation).
Jetzt ist es an der Zeit zu beschreiben, warum und wann Sie diese Authentifizierungsmethode verwenden sollten. Die größten Vorteile dieser Methode sind:
Temporärer Zugriff
Stellen wir uns ein Servicekonto vor, das einen komplexen Satz von Rollen hat, die auf verschiedenen Zugriffsebenen (Projektebene, BigQuery-Datensatzebene, BigQuery-Tabellenebene usw.) gewährt werden. Anstatt einem Benutzerkonto denselben Rollensatz zu gewähren, könnten Sie einfach die Rolle „Service Account Token Creator“ gewähren und sie entfernen, wenn sie nicht mehr benötigt wird (oder eine zeitbasierte IAM-Bedingung hinzufügen, um den Zugriff zu einem bestimmten Zeitpunkt automatisch zu entfernen).
Reduzieren Sie die Berechtigungsverwaltung
Durch Identitätsdiebstahl wird die Berechtigungsverwaltung auf eine kleinere Anzahl von Servicekonten zentralisiert, was die Übersicht vereinfacht und potenzielle Fehlkonfigurationen reduziert.
Minimieren des Expositionsfensters
Im Falle eines Sicherheitsvorfalls ist es einfacher, Identitätsdiebstahlrechte zu widerrufen oder die Berechtigungen des imitierten Servicekontos zu ändern, ohne die Basisberechtigungen des Benutzers zu beeinträchtigen.
Projekt- und/oder organisationsübergreifend
Direkte Rollenzuweisungen über Projekte und/oder Organisationen hinweg können komplexer zu verwalten sein und zu einem breiteren Zugriff als nötig führen.
Dienstkontoschlüssel
Durch die Identitätswechsel von Dienstkonten entfällt die Notwendigkeit, Dienstkontoschlüssel zu verwenden und zu verwalten, was die Sicherheit erheblich erhöht. Durch die Vermeidung der Verteilung von Dienstkontoschlüsseln wird das Risiko einer Schlüsselkompromittierung verringert.
Die bereits erwähnte Rolle „Service Account Token Creator“ kann auf verschiedenen Ebenen gewährt werden:
Um zu überprüfen, wer diese Rolle auf Service Account-Ebene gewährt hat, besuchen Sie: GCP > IAM & Admin > Service Accounts > klicken Sie auf eine SA > BERECHTIGUNGEN
Eine beliebte Möglichkeit, ein Servicekonto zu imitieren, ist die gcloud CLI. Sie können die Impersonation für einen bestimmten Befehl verwenden, indem Sie das Flag —impersonate-service-account verwenden:
gcloud storage buckets list --impersonate-service-account=<>
Um die Impersonation für alle Befehle zu verwenden, können Sie die folgende Konfiguration verwenden:
gcloud config set auth/impersonate_service_account <>
Um die Impersonation zu stoppen, verwenden Sie diesen Befehl:
gcloud config unset auth/impersonate_service_account <>
Zusammenfassend lässt sich sagen, dass die Identitätswechsel von Dienstkonten der Schlüssel ist, wenn es darum geht, Ihre Google Cloud Platform-Berechtigungen sicher und verwaltbar zu halten.
Sie reduziert die Risiken, die mit langfristigen Dienstkontoschlüsseln verbunden sind, erleichtert die Kontrolle darüber, wer auf was Zugriff hat, und sorgt mit klaren Protokollen darüber, wer was getan hat, für Ordnung.
Verwenden Sie, wann immer es sinnvoll ist, die Identitätswechsel von Dienstkonten, anstatt direkte Rollen zu vergeben.
Wir freuen uns auf Ihre Anfrage und beraten Sie gerne unverbindlich! Füllen Sie dazu einfach das Kontaktformular aus oder rufen uns direkt an.
Jetzt kontaktierenNewsletter
Holen Sie sich unsere Online Marketing-Insights und Trends direkt in Ihr Postfach!