Best Practices für die Sicherheit von eingebetteten Analysen

Mit Looker Embedded Analytics können Sie Ihren Nutzern und Kunden das Entdecken von Daten ermöglichen, die in einen iFrame auf einer beliebigen HTML-formatierten Webseite, einem Portal oder in einer Anwendung eingebettet sind. Der iFrame führt die gesamte Looker-Anwendung aus und fordert nur die Daten an, die zum Anzeigen Ihrer Abfrage erforderlich sind. iFrames dürfen keine Daten von Ihrer externen Website oder Anwendung lesen oder schreiben.

Beim Einbetten von Daten kann es manchmal zu Bedenken hinsichtlich Datenschutz oder Sicherheit kommen. Daher sollten Looker-Administratoren diese Best Practices umsetzen, um diese Bedenken zu minimieren:

  • Wenn Sie Looker-Inhalte für Kunden einbetten, richten Sie Kundinhalte in einer separaten Looker-Instanz ein, die sich von der Instanz unterscheidet, die Sie für interne Analysen verwenden.
  • Verbinden Sie nur Daten mit der eingebetteten Looker-Instanz, auf die eingebettete Nutzer, die möglicherweise öffentlich sind, zugreifen dürfen.
  • Schützen Sie die zufälligen Tokens in öffentlichen Einbettungs-URLs so, als wären es Nutzeranmeldedaten, und deaktivieren Sie öffentliche URLs, wenn sie nicht verwendet werden.
  • Ein zugewiesener external_user_id-Wert muss für jede Gruppe von Berechtigungen, Nutzerattributen und Modellen eindeutig sein. Achten Sie darauf, dass Sie nicht dieselbe external_user_id für verschiedene Einbettungssitzungen für verschiedene interaktive Nutzer verwenden. Außerdem dürfen Sie nicht dieselbe external_user_id für einen einzelnen Nutzer verwenden, der unterschiedliche Berechtigungen, Nutzerattributwerte oder Modellzugriff hat.
  • Aktivieren Sie ein geschlossenes System.
  • Schützen Sie das signierte Einbettungs-Secret so, als wären es Administratoranmeldedaten für Ihre eingebettete Looker-Instanz. Deaktivieren Sie die signierte Einbettung, wenn Sie sie nicht verwenden.
  • Verwenden Sie eine starke Authentifizierung für Ihre eingebetteten Looker-Instanzen (signierte Einbettung, SAML, Google OAuth, 2FA).
  • Wenn Sie cookieless embed verwenden, schützen Sie das Sitzungsreferenztoken so, dass es nur auf dem Hostserver der eingebetteten Anwendung zugänglich ist. Das Sitzungsreferenztoken sollte niemals im Browser verfügbar gemacht werden.
  • Wenn Sie das cookieless-Einbettungsverfahren verwenden und die zulässige Einbettungsdomain beim Abrufen der cookieless-Sitzung festlegen, sollten Sie dem Ursprung des Browsers des eingebetteten Nutzers niemals vertrauen. Pflegen Sie immer eine Zuordnung des eingebetteten Nutzers zum vertrauenswürdigen Ursprung des eingebetteten Nutzers auf dem Einbettungsanwendungsserver.

Je nach erforderlicher Authentifizierungsebene für Nutzer, die auf Ihre Daten zugreifen, bietet Looker verschiedene Arten von Einbettungsmethoden: öffentlich, privat und signierte Einbettung. Mit jeder dieser Methoden können Sie über JavaScript mit dem iFrame interagieren.

Öffentliche Einbettung

Wenn die Option Öffentlicher Zugriff für einen Look aktiviert ist, können Sie eine Visualisierung oder Datentabelle mit einem HTML-iframe-Tag in eine externe Website einbetten. Sie können die Look-URL auch öffentlich freigeben oder Daten in Google- oder Excel-Tabellenkalkulationsanwendungen importieren.

Die URL und die Einbettungs-URL innerhalb des iframe-Tags enthalten ein zufälliges Token und können nicht erraten werden. Jeder mit der Einbettungs-URL kann jedoch auf die Daten zugreifen. Es werden keine zusätzlichen Filter oder Einschränkungen angewendet. Wir empfehlen, die Sicherheitsrisiken zu berücksichtigen, die mit dem Erstellen und Freigeben einer öffentlichen URL für einen bestimmten Look verbunden sind, bevor Sie Öffentliche URLs aktivieren.

Öffentliche URLs und öffentliche Einbettungs-URLs laufen nie ab und können nicht widerrufen werden. Wenn Sie eine öffentliche URL teilen, geben Sie die Abfrage und nicht die tatsächlichen Daten frei.

Private Einbettung

Wenn Sie keinen öffentlichen Zugriff auf Ihren Look zulassen möchten, können Sie ihn auch privat in ein iFrame einbetten. Das gilt auch für Explores und Dashboards. In diesem Fall ist eine Looker-Anmeldung erforderlich, um die Inhalte aufzurufen.

Authentifizierte Nutzer können nur auf die Inhalte zugreifen, die durch ihre zugewiesenen Looker-Berechtigungen festgelegt werden. Wenn Sie ihre Berechtigungen in Looker ändern, ändert sich die Einbettungs-URL nicht. Was der Nutzer sehen darf, wenn er auf die URL zugreift, kann sich jedoch ändern.

Wenn ein Nutzer nicht authentifiziert ist, können Sie entweder eine Fehlermeldung oder einen Anmeldebildschirm im iFrame anzeigen. Das Aktivieren eines Anmeldebildschirms im iFrame ist jedoch nicht mit dem Same-Origin-Schutz von Looker kompatibel.

Private Einbettungs-URLs laufen nie ab und können nicht widerrufen werden. Da der Link jedoch nur für Personen funktioniert, die Zugriff auf Ihre Looker-Instanz und diese Daten haben, sollte das Senden eines Links kein Sicherheitsrisiko darstellen.

Signierte Einbettung

Wenden Sie sich an einen Google Cloud-Vertriebsspezialisten, um Ihre Lizenz für diese Funktion zu aktualisieren.

Signiertes Einbetten geht noch einen Schritt weiter als das private Einbetten. Bei der signierten Einbettung müssen sich Nutzer nicht mit einem Looker-Nutzerkonto authentifizieren. Stattdessen können sie über Ihre eigene Anwendung mit der URL in einem iFrame authentifiziert werden. Bei der Authentifizierung wird eine neue Browsersitzung erstellt und ein Cookie für den Browser ausgestellt.

Nutzerberechtigungen, ‑kennungen und ‑attribute werden alle als Parameter in der URL übergeben, die mit einem geheimen Schlüssel signiert wird. Jeder, der Zugriff auf den geheimen Schlüssel hat, kann eine URL erstellen, um auf ein beliebiges Modell zuzugreifen, mit dem diese Looker-Instanz verbunden ist, und zwar als beliebiger Nutzer mit beliebigen Berechtigungen. In unserem Beispielcode erfahren Sie, wie Sie signierte URLs generieren.

Clickjacking ist ein Problem mit der Browsersicherheit, das auftreten kann, wenn eingebetteter Code oder ein Skript eine Funktion ohne Wissen oder Einwilligung des Nutzers ausführt, z. B. eine Schaltfläche, die scheinbar etwas anderes bewirkt. Clickjacking erfordert in der Regel eine statische URL. Die für eine signierte Einbettung generierte URL ist geheim und sollte nur dem Nutzer bekannt sein, der die Einbettung aufruft. Durch die Verwendung signierter Einbettungen wird das Clickjacking-Risiko für die externe Website nicht erhöht.

Signierte Einbettungsparameter

Die in der iFrame-URL enthaltenen Parameter sind für Nutzer, die das Video einbetten, sichtbar, können aber nicht bearbeitet werden. Dazu gehören zum Beispiel:

  • user_attributes: Diese werden verwendet, um Daten weiter zu filtern. user_attributes sind leistungsstark. Überlegen Sie sich daher, wie sie auf Ihre Looker-Instanz angewendet werden können.
  • session_length: Halten Sie diese Zeit so kurz wie möglich.

Einige Parameter wie user_attributes können in der Benutzeroberfläche ausgeblendet werden, sind aber weiterhin in der Einbettungs-URL codiert. Das ist möglicherweise unerwünscht, wenn ein Passwort beispielsweise ein Wert in der user_attribute eines Nutzers ist. Eine Möglichkeit, dieses Problem zu umgehen, besteht darin, eine temporäre Gruppe zu erstellen, das Passwort als Attribut auf Gruppenebene festzulegen und dann die Gruppen-ID in der Einbettungs-URL zu übergeben. Sie können die Gruppe nach der Einbettungssitzung löschen, um zu viele abgelaufene Gruppen zu vermeiden.

Der signierte Teil der URL enthält einen Zeitstempel. Wenn die URL zum Anmelden verwendet wird, muss die Zeit +/- 5 Minuten von der aktuellen Zeit abweichen. In session_length können Sie festlegen, wie lange die Einbettungssitzung dauern darf, nachdem die URL zum Anmelden verwendet wurde.

Signierten Zugriff für Einbettungen verwalten

Beim Erstellen der URL für eingebettete Inhalte gilt Folgendes:

  • Verwenden Sie die niedrigste erforderliche Berechtigungsstufe.
  • Weisen Sie nur Zugriff auf die spezifischen Modelle zu, auf die der Nutzer zugreifen können soll.
  • Verwenden Sie group_ids, um einen Nutzer einer Gruppe zuzuweisen und dem eingebetteten Nutzer zu erlauben, den Zugriff auf seinen Looker-Ordner zu steuern.

Looker API

Mit der Looker API können Sie den Zugriff auf eingebettete Inhalte über eine Proxyanwendung oder einen Reverse-Proxyserver aktivieren. In diesem Szenario erfolgt die Authentifizierung über API-Schlüssel, die an einen bestimmten Nutzer gebunden sind und die gleichen Berechtigungen wie der Nutzer haben, der sie generiert. API-Schlüssel bestehen aus einer Client-ID und einem Clientschlüssel.

Einbettungszugriff mit der API verwalten

Wenn Sie den Zugriff auf eingebettete Inhalte über die Looker API aktivieren, empfehlen wir Folgendes:

  • Erstellen Sie dedizierte Dienstkonten für den programmatischen API-Zugriff mit den minimal erforderlichen Berechtigungen.
  • Schutz der Client-ID und des Clientschlüssels, aus denen der API-Schlüssel besteht (bei der Authentifizierung mit einem SDK).

Alle Nutzerattribute, die für eingebettete Nutzer über die API festgelegt, aber nicht in der signierten eingebetteten URL angegeben werden, werden beim nächsten Zugriff auf die signierte eingebettete URL auf ihre Standardwerte zurückgesetzt.

Eingebettete JavaScript-Ereignisse

Nachdem Sie das Einbettungs-iFrame öffentlich, privat, mit signierter Einbettung oder über die API eingerichtet haben, können Sie mit JavaScript mit diesem iFrame interagieren. Um zu prüfen, ob die Informationen, mit denen Sie arbeiten, tatsächlich aus dem iFrame von Looker stammen, können Sie JavaScript-Ereignisse abhören.

Wenn Sie Domains der Zulassungsliste hinzufügen, können Sie mit dem Platzhalter nur bestimmten Subdomains Zugriff auf Ihre JavaScript-Ereignisse gewähren.

Wenn Sie die JavaScript-Funktion eval verwenden, muss der Stringwert im Argument eval aus einer vertrauenswürdigen Quelle wie dem Looker-Server oder CDN stammen und über HTTPS übertragen werden.

Kundendaten werden niemals über die Looker-CDNs übertragen. Nur statische Assets der Looker-Webanwendung – JavaScript-Code, HTML-Seiten, CSS-Stile – werden über das CDN bereitgestellt.

Vom Kunden gehostete Bereitstellungen

Das Hosten einer eigenen Looker-Instanz mag als sichere Methode erscheinen, um den Zugriff auf Daten, insbesondere eingebettete Inhalte, zu sperren. Wenn Ihre Nutzer jedoch über das Internet auf die Einbettungs-URL zugreifen müssen, bietet das Hosting von Looker keine besonderen Vorteile.

Vom Kunden gehostete Bereitstellungen eignen sich am besten in folgenden Fällen:

  • Ihre Nutzer müssen nicht über das Internet auf Looker zugreifen.
  • Sie verwenden Looker als Frontend und greifen über die API auf eingebettete Inhalte zu.