Best Practices für die Sicherheit von eingebetteten Analysen

Mit eingebetteten Looker-Analysen 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 Kundeninhalte in einer separaten Looker-Instanz ein, die von der Instanz abweicht, die Sie für interne Analysen verwenden.
  • Verbinden Sie nur Daten mit der eingebetteten Looker-Instanz, auf die Nutzer, die die Daten einbetten, zugriff haben sollten. Das können auch Nutzer sein, die nicht zur Organisation gehören.
  • 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. Achte darauf, dass du nicht dieselbe external_user_id für verschiedene Einbettungssitzungen für verschiedene interaktive Nutzer verwendest. Außerdem solltest du 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 Secret für signiertes Einbetten so, als wären es Administratoranmeldedaten für Ihre eingebettete Looker-Instanz. Lassen Sie die Funktion für signiertes Einbetten deaktiviert, wenn Sie sie nicht verwenden.
  • Verwenden Sie die starke Authentifizierung für Ihre eingebetteten Looker-Instanzen (signierte Einbettung, SAML, Google OAuth, 2FA).
  • Wenn du das Einbetten ohne Cookies verwendest, solltest du das Sitzungsreferenztoken so schützen, dass es nur auf dem Hostserver der eingebetteten Anwendung zugänglich ist. Das Sitzungsreferenztoken darf niemals im Browser sichtbar sein.
  • Wenn du die Funktion „Einbetten ohne Cookies“ verwendest und beim Abrufen der Sitzung ohne Cookies die zugelassene Domain für das Einbetten festlegst, solltest du dem Ursprung aus dem Browser des Nutzers, der den eingebetteten Inhalt aufruft, niemals vertrauen. Der Einbettungsnutzer muss immer dem vertrauenswürdigen Ursprung des Einbettungsnutzers auf dem Einbettungsserver zugeordnet sein.

Looker bietet verschiedene Arten von Einbettungsmethoden, je nachdem, welche Authentifizierungsstufe für Nutzer erforderlich ist, die auf Ihre Daten zugreifen: öffentlich, privat und signierte Einbettung. Mit jeder dieser Methoden kannst du mit dem Iframe über JavaScript interagieren.

Öffentliche Einbettung

Wenn die Option Öffentlicher Zugriff für einen Look aktiviert ist,können Sie eine Visualisierung oder Datentabelle mithilfe eines HTML-iFrame-Tags in eine externe Website einbetten. Sie können die Looker-URL auch öffentlich freigeben oder Daten in Google- oder Excel-Tabellen importieren.

Die URL und die Einbettungs-URL im iframe-Tag enthalten ein zufälliges Token und können nicht erraten werden. Jeder, der die Einbettungs-URL kennt, kann jedoch auf die Daten zugreifen. Es werden keine zusätzlichen Filter oder Einschränkungen angewendet. Wir empfehlen, die Sicherheitsaspekte des Erstellens und Teilens einer öffentlichen URL für einen bestimmten Look zu berücksichtigen, bevor Sie Öffentliche URLs aktivieren.

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

Private Einbettung

Wenn Sie keinen öffentlichen Zugriff auf Ihren Look gewähren möchten, können Sie ihn auch privat in einen Iframe einbetten, einen Explore oder ein Dashboard, sodass zum Aufrufen der Inhalte eine Looker-Anmeldung erforderlich ist.

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 was der Nutzer beim Zugriff auf die URL sehen darf, kann sich ändern.

Wenn der Nutzer nicht authentifiziert ist, kannst du im Iframe entweder eine Fehlermeldung oder einen Anmeldebildschirm anzeigen. Die Aktivierung eines Anmeldebildschirms im iFrame ist jedoch nicht mit den Same-Origin-Schutzmaßnahmen von Looker kompatibel.

Private Embed-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 die Daten haben, sollte das Senden eines Links keine Sicherheitsrisiken darstellen.

Signierte Einbettung

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

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

Nutzerberechtigungen, ‑identitäten und ‑attribute werden alle als Parameter in der URL übergeben, die mit einem geheimen Schlüssel signiert ist. Jeder Nutzer mit Zugriff auf den geheimen Schlüssel kann eine URL erstellen, um als beliebiger Nutzer mit beliebigen Berechtigungen auf jedes Modell zuzugreifen, mit dem die Looker-Instanz verbunden ist. In unserem Beispielcode erfährst du, wie du signierte URLs generieren kannst.

Clickjacking ist ein Browsersicherheitsproblem, das auftreten kann, wenn eingebetteter Code oder ein Script eine Funktion ohne Wissen oder Einwilligung des Nutzers ausführt, z. B. eine Schaltfläche, die anscheinend etwas anderes tut. Für Clickjacking ist in der Regel eine statische URL erforderlich. Die für eine signierte Einbettung generierte URL ist geheim und sollte nur dem Nutzer zur Verfügung stehen, der die Einbettung aufruft. Die Verwendung von signierten Einbettungen erhöht das Clickjacking-Risiko für die externe Website nicht.

Signierte Parameter für die Einbettung

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

  • user_attributes: Mit diesen werden Daten weiter gefiltert. user_attributes sind leistungsstark. Überlegen Sie, wie sie auf Ihre Looker-Instanz angewendet werden können.
  • session_length: Begrenzen Sie die Zeit auf das Nötigste.

Einige Parameter wie user_attributes können in der Benutzeroberfläche ausgeblendet werden, werden aber trotzdem in der Einbettungs-URL codiert. Das ist beispielsweise nicht wünschenswert, wenn ein Passwort 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 vermeiden, dass zu viele abgelaufene Gruppen vorhanden sind.

Der signierte Teil der URL enthält einen Zeitstempel. Nachdem die URL zur Anmeldung verwendet wurde, muss diese Zeit +/- 5 Minuten von der aktuellen Zeit entfernt sein. In session_length kannst du festlegen, wie lange die Einbettungssitzung nach der Anmeldung mit der URL dauern darf.

Zugriff für signierte Einbettungen verwalten

Beachte beim Erstellen der URL für deine eingebetteten Inhalte Folgendes:

  • Verwenden Sie die niedrigste erforderliche Ebene der Berechtigungen.
  • Weisen Sie nur den spezifischen Modellen Zugriff zu, auf die der Nutzer zugreifen soll.
  • Verwenden Sie group_ids, um einem Nutzer eine Gruppe zuzuweisen und dem Nutzer, der die Einbettung vornimmt, die Möglichkeit zu geben, 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 spezielle Dienstkonten für den programmatischen API-Zugriff mit den minimal erforderlichen Berechtigungen.
  • Schützen Sie die Client-ID und das Clientgeheimnis, die den API-Schlüssel bilden (bei der Authentifizierung mit einem SDK).

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

Eingebettete JavaScript-Ereignisse

Nachdem du deinen Einbettungs-iFrame eingerichtet hast – öffentlich, privat, mit signiertem Einbetten oder über die API – kannst du mit JavaScript mit diesem iFrame interagieren. Sie können die JavaScript-Ereignisse überwachen, um zu prüfen, ob die verwendeten Informationen tatsächlich aus dem iframe von Looker stammen.

Wenn Sie Domains zur Zulassungsliste hinzufügen, können Sie mithilfe des Platzhalters festlegen, dass nur bestimmte Subdomains auf Ihre JavaScript-Ereignisse zugreifen dürfen.

Wenn Sie die JavaScript-Funktion eval verwenden, achten Sie darauf, dass der Stringwert im eval-Argument aus einer vertrauenswürdigen Quelle stammt, z. B. dem Looker-Server oder CDN, und über HTTPS übertragen wird.

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

Kundenseitig gehostete Bereitstellungen

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

Kundenseitig gehostete Bereitstellungen sind in folgenden Fällen am besten geeignet:

  • 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.