Best Practices für die Sicherheit von eingebetteten Analysen

Dank der integrierten Analysefunktion von Looker (PBL), können Looker und Nutzer Daten, die in einen iFrame eingebettet sind, in jede HTML-formatierte Webseite, in ein Portal oder in eine Anwendung einbetten. Der iFrame führt die gesamte Looker-Anwendung aus und fordert nur die Daten an, die zum Anzeigen Ihrer Abfrage erforderlich sind. Von Grund auf ist es einem iFrame nicht erlaubt, Daten von Ihrer externen Website oder Anwendung zu lesen oder zu schreiben.

Das Einbetten von Daten stellt manchmal Bedenken hinsichtlich Datenschutz oder Sicherheit dar. Wir empfehlen Looker-Administratoren die folgenden Best Practices, um diese Bedenken zu minimieren:

  • Wenn Sie Looker-Inhalte für Kunden einbetten, richten Sie Kundeninhalte auf einer separaten Looker-Instanz von der Instanz ein, die Sie für interne Analysen verwenden.
  • Verbinden Sie nur Daten mit der eingebetteten Looker-Instanz, die für eingebettete Nutzer, die möglicherweise öffentlich sind, zugewiesen werden sollte.
  • Schützen Sie die zufälligen Tokens in öffentlichen eingebetteten URLs wie Nutzeranmeldedaten und deaktivieren Sie öffentliche URLs, wenn sie nicht verwendet werden.
  • Ein zugewiesener external_user_id-Wert muss für jeden Satz von Berechtigungen, Nutzerattributen und Modellen eindeutig sein. Achte darauf, nicht dieselbe external_user_id für verschiedene Einbettungssitzungen für verschiedene interaktive Nutzer zu verwenden. Achte außerdem darauf, nicht dieselbe external_user_id für einen einzelnen Nutzer mit unterschiedlichen Berechtigungen, Nutzerattributwerten oder Zugriffsmodellen zu verwenden.
  • Aktivieren Sie ein geschlossenes System.
  • Schützen Sie das geheime SSO-Secret so, als wären es Administratoranmeldedaten für Ihre eingebettete Looker-Instanz. Lassen Sie die SSO-Einbettung deaktiviert, wenn Sie sie nicht verwenden.
  • Verwenden Sie für Ihre eingebetteten Looker-Instanzen eine starke Authentifizierung (SSO, SAML, Google OAuth, 2FA).

Looker bietet verschiedene Arten von Einbettungsmethoden, die von der Authentifizierungsstufe der Nutzer, die auf Ihre Daten zugreifen, erforderlich sind: öffentlich, privat und Einmalanmeldung (SSO). Bei beiden Methoden können Sie JavaScript verwenden, um mit dem iFrame zu interagieren.

Öffentliche Einbettung

Wenn die Option Öffentlicher Zugriff von Looker aktiviert ist,können Sie eine Visualisierungs- oder Datentabelle mithilfe eines HTML-iFrame-Tags in eine externe Website einbetten. Sie können die Look-URL auch öffentlich teilen oder Daten in Google- oder Excel-Tabellenanwendungen importieren.

Die URL und die Einbettungs-URL im iframe-Tag enthalten ein zufälliges Token und können nicht erraten werden. Allerdings kann jeder, der über die Einbettungs-URL verfügt, auf die Daten zugreifen. Es werden keine zusätzlichen Filter oder Einschränkungen angewendet. Wir empfehlen, die Auswirkungen auf die Sicherheit beim Erstellen und Freigeben einer öffentlichen URL für einen bestimmten Look zu berücksichtigen, bevor Sie öffentliche URLs aktivieren.

Öffentliche URLs und URLs, die einfach eingebettet sind, laufen nie ab und können nicht widerrufen werden. Wenn Sie eine öffentliche URL freigeben, teilen Sie damit nicht nur die Daten,sondern die Anfrage.

Private Einbettung

Wenn Sie den öffentlichen Zugriff auf Ihren Look nicht gewähren möchten, können Sie für eine Anmeldung auch einen Lookein Erkunden oder ein Dashboard privat in einem Look ansehen.

Authentifizierte Nutzer können nur auf die Inhalte zugreifen, die durch ihre zugewiesenen Looker-Berechtigungen festgelegt sind. Wenn Sie die Berechtigungen in Looker ändern, ändert sich die Einbettungs-URL nicht, aber die Inhalte, die der Nutzer beim Zugriff auf die URL sehen kann, können sich ändern.

Wenn der Nutzer nicht authentifiziert ist, kann entweder ein Fehler oder ein Anmeldebildschirm im iFrame angezeigt werden. Das Aktivieren eines Anmeldebildschirms im iFrame ist jedoch nicht mit den Same-Origin-Schutzmaßnahmen von Looker kompatibel.

Private Einbettungs-URLs laufen nicht 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 Sicherheitsproblem darstellen.

Einbettung der Einmalanmeldung (SSO)

Bitte wenden Sie sich an Ihren Account Manager, um Ihre Lizenz für diese Funktion zu aktualisieren.

Mit der eingebetteten Einmalanmeldung (SSO) gehen Sie noch einen Schritt weiter. Bei der SSO-Einbettung müssen sich die Nutzer nicht über ein Looker-Nutzerkonto authentifizieren. Stattdessen können sie über Ihre eigene Anwendung über die URL in einem iFrame authentifiziert werden. Bei der Authentifizierung wird eine neue Browsersitzung erstellt und es wird ein Cookie an den Browser gesendet.

Nutzerberechtigungen, Kennungen und Attribute werden als Parameter innerhalb der URL übergeben, die mit einem geheimen Schlüssel signiert ist. Jeder Nutzer mit Zugriff auf den geheimen Schlüssel kann eine URL für den Zugriff auf jedes Modell erstellen, mit dem die Looker-Instanz wie alle Nutzer mit entsprechender Berechtigung verbunden ist. In unserem Beispielcode erfahren Sie, wie Sie signierte URLs generieren.

Clickjacking ist ein Problem mit der Browsersicherheit, das auftreten kann, wenn der eingebettete Code oder ein Skript eine Funktion ohne Wissen oder Einwilligung des Nutzers ausführt, z. B. eine Schaltfläche, die scheinbar anderweitig funktioniert. Für Clickjacking ist normalerweise eine statische URL erforderlich. Die für eine SSO-Einbettung generierte URL ist geheim und sollte nur dem Nutzer zugewiesen sein. Durch die Verwendung der SSO-Einbettung wird das Clickjacking-Risiko der externen Website nicht erhöht.

SSO-Einbettungsparameter

Die in der iFrame-URL enthaltenen Parameter sind für eingebettete Nutzer sichtbar, lassen sich aber nicht bearbeiten. Dazu gehören zum Beispiel:

  • user_attributes: Damit werden die Daten weiter gefiltert. user_attributes sind leistungsstark, also überlegen Sie, wie sie auf Ihre Looker-Instanz angewendet werden könnten.
  • session_length: Halten Sie den Wert so kurz wie möglich.

Einige Parameter, z. B. user_attributes, können auf der Benutzeroberfläche ausgeblendet werden, werden aber in der eingebetteten URL codiert. Das kann unerwünscht sein, wenn beispielsweise ein Passwort ein Wert in der user_attribute eines Nutzers ist. Das lässt sich umgehen, indem Sie eine temporäre Gruppe erstellen, das Passwort als Attribut auf Gruppenebene festlegen und dann die Gruppen-ID in der eingebetteten URL übergeben. Sie können die Gruppe nach der Einbettungssitzung löschen, um einen Überschuss an abgelaufenen Gruppen zu vermeiden.

Der signierte Teil der URL enthält einen Zeitstempel. Nachdem die URL für die Anmeldung verwendet wurde, muss diese Zeit +/- 5 Minuten nach der aktuellen Uhrzeit liegen. Sie können in session_length angeben, wie lange die Einbettungssitzung dauern kann, wenn die URL für die Anmeldung verwendet wird.

SSO-Einbettungszugriff verwalten

Erstellen Sie die URL für Ihre eingebetteten Inhalte:

  • Verwenden Sie die niedrigste erforderliche Berechtigungsstufe.
  • Weisen Sie den Nutzern nur bestimmte Modelle zu, auf die sie Zugriff haben sollen.
  • Mit group_ids können Sie einen Nutzer einer Gruppe zuweisen und dem eingebetteten Nutzer 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 API3-Schlüssel, die an einen bestimmten Nutzer gebunden sind und dieselben Berechtigungen wie der Nutzer haben, der sie generiert. API3-Schlüssel bestehen aus einer Client-ID und einem Clientschlüssel.

Zugriff auf eingebettete Inhalte über die API verwalten

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

  • Beim Erstellen dedizierter Dienste wird der programmatische API-Zugriff mit den erforderlichen Mindestberechtigungen berücksichtigt.
  • Schutz der Client-ID und des Clientschlüssels, aus denen sich der API3-Schlüssel zusammensetzt (bei der Authentifizierung mit einem SDK).

Alle Nutzerattribute, die für das Einbetten von Nutzern über die API festgelegt, aber nicht in der SSO-URL angegeben wurden, werden auf ihre Standardwerte zurückgesetzt, wenn die SSO-URL das nächste Mal aufgerufen wird.

Eingebettete JavaScript-Ereignisse

Nachdem Sie den eingebetteten iFrame eingerichtet haben – öffentlich, privat, mit SSO oder über die API –, können Sie über JavaScript mit diesem iFrame interagieren. Wenn Sie überprüfen möchten, ob die Informationen, mit denen Sie arbeiten, tatsächlich aus dem iFrame von Looker stammen, können Sie die JavaScript-Ereignisse überwachen.

Verwenden Sie beim Hinzufügen von Domains zur Zulassungsliste den Platzhalter, damit nur bestimmte Subdomains auf Ihre JavaScript-Ereignisse zugreifen können.

Wenn Sie die JavaScript-Funktion eval verwenden, achten Sie darauf, dass der Stringwert im eval-Argument von einer vertrauenswürdigen Quelle stammt, z. B. vom Looker-Server oder CDN, und sich im HTTPS-Transport befindet.

Über Looker CDNs werden niemals Kundendaten erhoben. Es werden nur statische Assets der Looker-Webanwendung (JavaScript-Code, HTML-Seiten, CSS-Stile) aus CDN bereitgestellt.

Vom Kunden gehostete Bereitstellungen

Das Hosten Ihrer eigenen Looker-Instanz kann wie eine ausfallsichere Methode erscheinen, um den Zugriff auf Daten zu sperren, insbesondere auf eingebettete Inhalte. Wenn Ihre Nutzer jedoch über das Internet auf die eingebettete URL zugreifen müssen, hat Looker keine besonderen Vorteile.

Vom Kunden gehostete Bereitstellungen sind in folgenden Fällen besonders sinnvoll:

  • Ihre Nutzer müssen nicht über das Internet auf Looker zugreifen.
  • Sie sind ein Front-End für Looker und greifen über die API auf eingebettete Inhalte zu.