Mit der eingebetteten Analyse von Looker können Sie Ihre Benutzer und Kunden in die Lage versetzen, in einen iFrame eingebettete Daten in HTML-formatierten Webseiten, Portalen oder Anwendungen zu erkunden. Der iFrame führt die gesamte Looker-Anwendung aus und fordert nur die Daten an, die zum Anzeigen Ihrer Abfrage erforderlich sind. Standardmäßig ist es einem iFrame nicht erlaubt, Daten von Ihrer externen Website oder Anwendung zu lesen oder zu schreiben.
Das Einbetten von Daten kann zu Datenschutz- oder Sicherheitsbedenken führen. Um diese Bedenken auszuräumen, empfehlen wir Looker-Administratoren, die folgenden Best Practices zu befolgen:
- Wenn Sie Looker-Inhalte für Kunden einbetten, richten Sie diese Inhalte auf einer anderen Looker-Instanz als der Instanz ein, die Sie für interne Analysen verwenden.
- Verbinden Sie nur Daten mit der eingebetteten Looker-Instanz, die für eingebettete Nutzer zugänglich sein sollten. Diese können öffentlich sein.
- 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 jeden Satz von Berechtigungen, Nutzerattributen und Modellen eindeutig sein. Verwenden Sie nicht dieselbeexternal_user_idin verschiedenen Einbettungssitzungen für verschiedene interaktive Nutzer und verwenden Sie nicht dieselbeexternal_user_idfür einen einzelnen Nutzer, der über unterschiedliche Berechtigungen, Nutzerattributwerte oder Modellzugriff verfügt. - Aktivieren Sie ein geschlossenes System.
- Schützen Sie das signierte Einbettungs-Secret so, als ob es sich um Administratoranmeldedaten für Ihre eingebettete Looker-Instanz handelt. Lassen Sie die signierte Einbettung deaktiviert, wenn Sie sie nicht verwenden.
- Verwenden Sie für Ihre eingebetteten Looker-Instanzen eine starke Authentifizierung (signierte Einbettung, SAML, Google OAuth, 2FA).
- Wenn Sie die Einbettung ohne Cookies verwenden, schützen Sie das Sitzungsreferenztoken, damit es nur auf dem Hostserver der Einbettungsanwendung zugänglich ist. Das Sitzungsreferenztoken sollte niemals im Browser offengelegt werden.
- Wenn Sie eine Einbettung ohne Cookies verwenden und beim Abrufen einer Sitzung ohne Cookies die zulässige Einbettungsdomain festlegen, sollten Sie der Quelle des eingebetteten Browsers nie vertrauen. Pflegen Sie im Einbettungsanwendungsserver immer eine Zuordnung des eingebetteten Nutzers zur vertrauenswürdigen Quelle des eingebetteten Nutzers.
Looker bietet je nach Authentifizierungsstufe der Nutzer, die auf Ihre Daten zugreifen, unterschiedliche Einbettungsmethoden: öffentlich, privat und signierte Einbettung. Bei beiden Methoden können Sie JavaScript mit dem iFrame interagieren.
Öffentliche Einbettung
Wenn die Option Öffentlicher Zugriff eines Looks aktiviert ist,können Sie eine Visualisierung oder Datentabelle mithilfe eines iframe in eine externe Website einbetten. Sie können die Look-URL auch öffentlich teilen oder Daten in Tabellenanwendungen von Google oder Excel 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 und es werden keine zusätzlichen Filter oder Einschränkungen angewendet. Bevor Sie Öffentliche URLs aktivieren, sollten Sie die Sicherheitsaspekte berücksichtigen, die das Erstellen und Teilen einer öffentlichen URL für einen bestimmten Look mit sich bringt.
Ö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 auch einen Look – oder ein Explore oder Dashboard privat in einen iFrame einbetten. Damit der Inhalt angezeigt werden kann, ist eine Looker-Anmeldung erforderlich.
Authentifizierte Benutzer können nur auf die Inhalte zugreifen, die durch ihre zugewiesenen Looker-Berechtigungen vorgegeben werden. Wenn Sie die Berechtigungen in Looker ändern, ändert sich die Einbettungs-URL nicht. Es kann sich aber ändern, was der Nutzer sehen kann, wenn er auf die URL zugreift.
Wenn der Nutzer nicht authentifiziert ist, kann im iFrame entweder ein Fehler oder ein Anmeldebildschirm angezeigt werden. Das Aktivieren eines Anmeldebildschirms im iFrame ist jedoch nicht mit den Same-Origin-Schutzmaßnahmen 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 keine Sicherheitsbedenken verursachen.
Signierte Einbettung
Wenden Sie sich an einen Google Cloud-Vertriebsexperten, um Ihre Lizenz für dieses Feature zu aktualisieren.
Die signierte Einbettung geht noch einen Schritt weiter. Für die signierte 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 Browsersitzung erstellt und ein Cookie an den Browser ausgegeben.
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 erstellen, um auf jedes Modell zuzugreifen, mit dem die Looker-Instanz verbunden ist, sowie alle Nutzer mit beliebiger Berechtigung. In unserem Beispielcode erfahren Sie, wie Sie signierte URLs generieren.
Clickjacking ist ein Sicherheitsproblem des Browsers, das auftreten kann, wenn eingebetteter Code oder ein Skript ohne Wissen oder Zustimmung des Nutzers eine Funktion ausführt, zum Beispiel eine Schaltfläche, die offenbar eine andere Aktion ausführt. Clickjacking erfordert in der Regel eine statische URL. Die für eine signierte Einbettung generierte URL ist geheim und nur der Nutzer, der sich die Einbettung ansieht, sollte sie haben. Die Verwendung signierter Einbettungen erhöht nicht das Risiko von Clickjacking für die externe Website.
Signierte Einbettungsparameter
Die in der iFrame-URL enthaltenen Parameter sind für eingebettete Nutzer sichtbar, aber nicht bearbeitbar. Dazu gehören zum Beispiel:
user_attributes: Damit werden Daten weiter gefiltert.user_attributesist eine leistungsstarke Funktion. Überlegen Sie sich also, wie sie auf Ihre Looker-Instanz angewendet werden können.session_length: Beschränken Sie sich auf die geringstmögliche Dauer.
Einige Parameter wie user_attributes können in der Benutzeroberfläche ausgeblendet werden, wären aber in der Einbettungs-URL codiert. Das kann beispielsweise ungünstig sein, wenn ein Passwort ein Wert innerhalb der user_attribute eines Nutzers ist. Eine Möglichkeit, dies 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 Einbettung löschen, um zu verhindern, dass zu viele Gruppen inaktiv sind.
Der vorzeichenbehaftete Teil der URL enthält einen Zeitstempel. Sobald die URL für die Anmeldung verwendet wird, muss dieser Zeitpunkt +/- 5 Minuten ab der aktuellen Uhrzeit liegen. Sie können in session_length angeben, wie lange die Einbettungssitzung ab der Anmeldung über die URL dauern darf.
Zugriff auf signierte Einbettungen verwalten
Gehen Sie beim Erstellen der URL für Ihre eingebetteten Inhalte wie folgt vor:
- Verwenden Sie die niedrigste erforderliche Berechtigungsstufe.
- Gewähren Sie nur Zugriff auf die bestimmten Modelle, auf die der Nutzer Zugriff haben sollte.
- 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
Mithilfe der API von Looker können Sie den Zugriff auf eingebettete Inhalte mithilfe einer Proxy-Anwendung oder eines Reverse-Proxy-Servers aktivieren. In diesem Szenario erfolgt die Authentifizierung mithilfe von API-Schlüsseln. Diese sind an einen bestimmten Nutzer gebunden und haben dieselben Berechtigungen wie der Nutzer, der sie generiert. API-Schlüssel bestehen aus einer Client-ID und einem Clientschlüssel.
Zugriff auf eingebettete Inhalte mithilfe der API verwalten
Wenn Sie den Zugriff auf eingebettete Inhalte mit der API von Looker aktivieren, empfehlen wir Folgendes:
- Dedizierte Dienstkonten für den programmatischen API-Zugriff mit den erforderlichen Mindestberechtigungen erstellen
- Schutz der Client-ID und des Clientschlüssels, aus denen der API-Schlüssel besteht (bei der Authentifizierung über ein SDK)
Alle Nutzerattribute, die für eingebettete Nutzer über die API festgelegt wurden, aber nicht in der signierten Einbettungs-URL angegeben sind, werden beim nächsten Zugriff auf die signierte Einbettungs-URL auf ihre Standardwerte zurückgesetzt.
Eingebettete JavaScript-Ereignisse
Nachdem du deinen eingebetteten iFrame eingerichtet hast – öffentlich, privat, mit signierter Einbettung oder über die API –, kannst du mit ihm mithilfe von JavaScript interagieren. Um zu überprüfen, 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, muss der Stringwert im Argument eval aus einer vertrauenswürdigen Quelle stammen, z. B. dem Looker-Server oder CDN, und muss über HTTPS übertragen werden.
Keine Kundendaten gehen durch die Looker-CDNs. Nur statische Assets für die Looker-Webanwendung – JavaScript-Code, HTML-Seiten, CSS-Stile – werden vom CDN bereitgestellt.
Vom Kunden gehostete Bereitstellungen
Das Hosten Ihrer eigenen Looker-Instanz mag wie die ausfallsichere Methode erscheinen, um den Zugriff auf Daten, insbesondere eingebettete Inhalte, zu sperren. Wenn Ihre Benutzer jedoch über das Internet auf die Einbettungs-URL zugreifen müssen, bietet es keine besonderen Vorteile, Looker selbst zu hosten.
Vom Kunden gehostete Bereitstellungen sind in folgenden Fällen am besten geeignet:
- Ihre Nutzer müssen nicht über das Internet auf Looker zugreifen.
- Sie stellen Looker als Front-End bereit und greifen über die API auf eingebettete Inhalte zu.