Best Practices für die Sicherheit von eingebetteten Analysen

Mit eingebetteten Looker-Analysen können Sie Ihren Nutzern und Kunden ermöglichen, in einem iFrame eingebettete Daten auf jeder Webseite, in einem Portal oder in einer Anwendung im HTML-Format zu untersuchen. 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 gestattet, Daten von Ihrer externen Website oder App zu lesen oder zu schreiben.

Das Einbetten von Daten kann manchmal Datenschutz- oder Sicherheitsbedenken darstellen. Um diesen Problemen entgegenzuwirken, empfehlen wir Looker-Administratoren die folgenden Best Practices:

  • Wenn Sie Looker-Inhalte in Kunden einbetten, richten Sie Kundeninhalte auf einer separaten Looker-Instanz ein, die Sie für interne Analysen verwenden.
  • Verbinden Sie nur Daten mit der eingebetteten Looker-Instanz, die für eingebettete Nutzer öffentlich zugänglich sein soll.
  • Die zufälligen Tokens in öffentlichen eingebetteten URLs schützen, als wären sie Anmeldedaten von Nutzern, und öffentliche URLs werden deaktiviert, wenn sie nicht verwendet werden.
  • Ein zugewiesener external_user_id-Wert muss für jeden angegebenen Satz von Berechtigungen, Nutzerattributen und Modellen eindeutig sein. Achte darauf, nicht dasselbe external_user_id für verschiedene eingebettete Sitzungen für verschiedene interaktive Nutzer zu verwenden. Achte außerdem darauf, nicht dasselbe external_user_id für einen einzelnen Nutzer mit unterschiedlichen Berechtigungen, Nutzerattributwerten oder Modellzugriffen zu verwenden.
  • Aktivieren Sie ein geschlossenes System.
  • Schützen Sie das SSO-Einbettungsgeheimnis so, als wären es Administratoranmeldedaten für Ihre eingebettete Looker-Instanz. Sorgen Sie dafür, dass die SSO-Einbettung deaktiviert ist, wenn Sie sie nicht verwenden.
  • Verwenden Sie eine starke Authentifizierung für Ihre eingebetteten Looker-Instanzen (SSO, SAML, Google OAuth, 2FA).
  • Wenn Sie Einbettung von Cookies verwenden, müssen Sie das Sitzungsreferenz-Token schützen, damit nur über den Host der eingebetteten Anwendung darauf zugegriffen werden kann. Das Referenztoken für die Sitzung sollte im Browser nicht offengelegt werden.
  • Wenn Sie eine Einbettung ohne Cookies verwenden und die zulässige Domain für die Einbettung beim Erwerben einer Sitzung ohne Cookies festlegen, vertrauen Sie dem Ursprung des Browsers des eingebetteten Nutzers nie. Behalten Sie immer die Zuordnung des eingebetteten Nutzers zum vertrauenswürdigen Ursprung des eingebetteten Nutzers im Server der eingebetteten Anwendung bei.

Je nach Authentifizierungsebene des Nutzers, der auf Ihre Daten zugreift, sind in Looker verschiedene Arten von Einbettungsmethoden verfügbar: öffentlich, privat und Einmalanmeldung (SSO). Bei jeder dieser Methoden können Sie JavaScript mit dem iFrame verwenden.

Öffentliche Einbettung

Wenn die Option Öffentlicher Zugriff von Look 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 freigeben 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, aber jeder mit der eingebetteten URL kann 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 öffentliche eingebettete URLs laufen nie ab und können nicht widerrufen werden. Bei der Freigabe einer öffentlichen URL wird die Abfrage weitergegeben, nicht die tatsächlichen Daten.

Private Einbettung

Wenn Sie den öffentlichen Zugriff auf Ihren Look nicht zulassen möchten, können Sie auch einen Look eingebettet haben oder ein Dashboard oder ein Dashboard privat in einen iFrame einbetten. Dann ist ein Looker-Log-in erforderlich, um den Inhalt aufrufen zu können.

Authentifizierte Nutzer können nur auf die Inhalte zugreifen, die über die ihnen zugewiesenen Looker-Berechtigungen festgelegt werden. Wenn Sie die Berechtigungen in Looker ändern, hat das keine Auswirkungen auf die eingebettete URL, aber darauf, was der Nutzer sieht, wenn er auf die URL zugreift.

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

Private eingebettete 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 haben, kann das Senden eines Links keine Sicherheitsbedenken darstellen.

Einmalanmeldung (SSO)

Wenden Sie sich an einen Google Cloud-Vertriebsexperten, um Ihre Lizenz für dieses Feature zu aktualisieren.

Die Einmalanmeldung (SSO) ist noch einen Schritt weiter. Für die SSO-Einbettung müssen sich 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 ein Cookie an den Browser gesendet.

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

Clickjacking ist ein Sicherheitsproblem im Browser, 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 eine andere Aktion ausführt. Für Clickjacking ist normalerweise eine statische URL erforderlich. Die für eine SSO-Einbettung generierte URL ist geheim und nur der Nutzer, der sie einbettet, sollte sie haben. Durch die SSO-Einbettung erhöht sich das Clickjacking-Risiko nicht für die externe Website.

SSO-Einbettungsparameter

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

  • user_attributes: Damit lassen sich Daten weiter filtern. user_attributes sind sehr leistungsstark. Überlegen Sie also, wie sie sich auf Ihre Looker-Instanz auswirken können.
  • session_length: Achten Sie darauf, dass die minimale Dauer beibehalten wird.

Einige Parameter wie user_attributes können auf der Benutzeroberfläche ausgeblendet werden, würden aber dennoch in der eingebetteten URL codiert werden. Das kann unerwünscht sein, wenn ein Passwort beispielsweise 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. Um Gruppenüberschreitungen zu vermeiden, können Sie die Gruppe nach der Einbettungssitzung löschen.

Der signierte Teil der URL enthält einen Zeitstempel. Nachdem die URL für die Anmeldung verwendet wurde, muss diese Zeit bis zu fünf Minuten dauern. Unter session_length können Sie angeben, wie lange die Einbettungssitzung dauern kann, wenn die URL für die Anmeldung verwendet wird.

Zugriff auf SSO-Einbettungen verwalten

Beachten Sie beim Erstellen der URL für Ihre eingebetteten Inhalte Folgendes:

  • Verwenden Sie die niedrigste erforderliche Berechtigungsstufe.
  • Weisen Sie nur bestimmten Modellen Zugriff zu, auf die der Nutzer zugreifen kann.
  • 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.

Zugriff auf eingebettete Inhalte über eine API verwalten

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

  • Dedizierte Dienste sorgen für den programmatischen API-Zugriff mit der Mindestanzahl an erforderlichen Berechtigungen.
  • Schutz der Client-ID und des Clientschlüssels, die den API-Schlüssel ausmachen (bei Authentifizierung).

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

Eingebettete JavaScript-Ereignisse

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

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, muss der Stringwert im Argument eval von einer vertrauenswürdigen Quelle stammen, z. B. vom Looker-Server oder von CDN. Außerdem muss er sich im HTTPS-Transport befinden.

Über die Looker-CDNs werden keine Kundendaten gesendet. Nur statische Assets von Looker-Webanwendung (JavaScript-Code, HTML-Seiten, CSS-Stile) werden über CDN bereitgestellt.

Vom Kunden gehostete Bereitstellungen

Das Hosten einer eigenen Looker-Instanz kann wie die fehlersichere Möglichkeit erscheinen, den Zugriff auf Daten, insbesondere eingebettete Inhalte, zu sperren. Wenn Ihre Nutzer jedoch über das Internet auf die eingebettete URL zugreifen müssen, bietet es sich nicht an, Looker selbst zu hosten.

In folgenden Fällen eignen sich vom Kunden gehostete Bereitstellungen am besten:

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