Bevor Sie ein selbst gehostetes BI-Tool mit einer Datenbank verbinden: Checkliste für minimale Berechtigungen

Beginnen Sie damit, die Verbindung abzubilden

Dies ist eine allgemeine Planungscheckliste und keine Beschreibung von Funktionen, die in jeder BI-Anwendung oder Datenbank verfügbar sind. Nutzen Sie die Dokumentation der konkreten Produkte, Versionen und Verbindungsmethode, die Sie einsetzen möchten, um die folgenden Fragen zu beantworten.

Halten Sie vor dem Einrichten einer Verbindung fest, welche BI-Anwendung eine Verbindung herstellt, welches Datenbankkonto sie verwendet, wie die Anwendung die Datenbank erreicht und wer gespeicherte Fragen oder Dashboards öffnen kann. Behandeln Sie Berechtigungen in der Anwendung und in der Datenbank als getrennte Prüfpunkte.

• Benennen Sie die BI-Anwendungsinstanz sowie die Datenbank oder Datenbanken, mit denen sie kommunizieren wird.
• Halten Sie fest, wer sich anmelden, Berichte erstellen oder bearbeiten und freigegebene Dashboards ansehen kann.
• Ermitteln Sie, wo die Verbindungszugangsdaten gespeichert sind und wer sie ändern darf.
• Skizzieren Sie den Netzwerkpfad und notieren Sie, welche Systeme oder Teams die einzelnen Bereiche verwalten.

Prüfen Sie Anwendungsrollen und Datenbankberechtigungen getrennt

Behandeln Sie dies als Prüfaufgabe und nicht als Annahme darüber, wie Rollen in einem bestimmten Produkt funktionieren. Prüfen Sie die Dokumentation Ihrer BI-Anwendung und testen Sie, was Konten mit den Rollen Betrachter, Berichtseditor und Administrator tun können. Prüfen Sie unabhängig davon, welche Leseberechtigungen das für die Verbindung konfigurierte Datenbankkonto besitzt.

Wenn gespeicherte Fragen, Dashboards, Exporte oder geplante Abfragen Teil Ihres Vorhabens sind, beziehen Sie auch diese in die Prüfung ein. Betrachten Sie eine Anwendungsrolle nicht als Ersatz für die Prüfung der Datenbankberechtigungen.

• Listen Sie die Anwendungsrollen auf, die Sie verwenden möchten, und die Aktionen, die jede Rolle erlauben soll.
• Dokumentieren Sie die Datenbankberechtigungen des Kontos für die BI-Verbindung.
• Testen Sie, was repräsentative Benutzer über die geplanten Berichte und Freigabemethoden sehen können.
• Halten Sie alle Verhaltensweisen, die Sie nicht überprüfen können, als offene Fragen fest.

Richten Sie ein eng begrenztes Konto für die Datenquelle ein

Verwenden Sie für die BI-Verbindung ein dediziertes Konto, statt sich als Root anzumelden oder ein Konto mit Schreibzugriff zu verwenden. Ein [Leitfaden von Basedash zum Erstellen von Dashboards mit MySQL-Daten](https://www.basedash.com/blog/how-to-build-dashboards-on-mysql-data) empfiehlt ein dediziertes, schreibgeschütztes Konto mit möglichst geringen Berechtigungen.

Legen Sie anschließend fest, welcher Lesezugriff für Ihre Berichtsanforderungen angemessen ist. Prüfen Sie die Datenbankdokumentation und fragen Sie eine Datenbankadministratorin oder einen Datenbankadministrator, ob der Zugriff auf ausgewählte Schemas, Tabellen oder Ansichten begrenzt werden kann. Überprüfen Sie die tatsächlich wirksamen Berechtigungen, statt anzunehmen, dass die BI-Anwendung diese Einschränkungen festlegt.

• Erstellen Sie ein eigenes Konto, das ausschließlich für die BI-Verbindung verwendet wird.
• Bevorzugen Sie schreibgeschützte Berechtigungen. Verwenden Sie für die reguläre Berichterstellung kein Root-Konto und kein Konto mit Schreibzugriff.
• Gewähren Sie nur Zugriff auf die Berichtsdaten, die das Team freigegeben hat.
• Lassen Sie die tatsächlich wirksamen Berechtigungen von einer Datenbankadministratorin oder einem Datenbankadministrator prüfen, einschließlich geerbter oder weiter gefasster Berechtigungen.

Legen Sie den Umgang mit sensiblen Feldern und Datensätzen fest

Ermitteln Sie anhand der Richtlinien Ihrer Organisation, welche Felder und Datensätze über Analysen nicht allgemein zugänglich sein sollten. Diese Checkliste schreibt keinen bestimmten rechtlichen oder regulatorischen Standard vor.

Überlegen Sie für jeden Eintrag, ob er ausgeschlossen, über Datenbankansichten in reduzierter Form bereitgestellt oder maskiert werden sollte, sofern Ihre Systeme dies unterstützen. Wenn der Zugriff je nach Zeile variieren soll, dokumentieren Sie, an welcher Stelle die Einschränkung durchgesetzt werden soll, und testen Sie über die tatsächliche BI-Verbindung zulässige und unzulässige Fälle.

• Listen Sie sensible Felder und Datensatzgruppen auf, bevor Sie Berichte erstellen.
• Entscheiden Sie für jeden Eintrag, ob er ausgeschlossen, reduziert, maskiert oder nur bestimmten Benutzern zugänglich gemacht werden soll.
• Testen Sie erforderliche Einschränkungen auf Zeilenebene an der vorgesehenen Durchsetzungsstelle.
• Prüfen Sie Berichte, Exporte und freigegebene Dashboards auf unbeabsichtigte Offenlegung.

Bewerten Sie die Auswirkungen von Abfragen, bevor Sie die Verbindung regelmäßig nutzen

Beziehen Sie die Auswirkungen auf das Quellsystem in Ihre Prüfung ein. Schreibgeschützter Zugriff allein sagt noch nichts darüber aus, welche Folgen die Ausführung von Berichten für Ihre Umgebung hat. Berücksichtigen Sie die erwarteten Berichte, ihre Häufigkeit und die Möglichkeit, dass mehrere Personen sie gleichzeitig nutzen.

Testen Sie repräsentative Berichte und Aktualisierungsmuster in einer Umgebung, die Ihrem Risikoniveau entspricht. Prüfen Sie in der Dokumentation Ihrer BI-Anwendung und Datenbank, ob Abfragelimits, Zeitüberschreitungen, Planungssteuerungen oder andere Schutzmaßnahmen verfügbar sind, und verifizieren Sie deren Verhalten in Ihrer konkreten Einrichtung. Wenn Sie ein wesentliches Risiko nicht bewerten können, klären Sie es, bevor Sie die regelmäßige Berichterstellung aktivieren.

• Ermitteln Sie Berichte, die große Datenmengen durchsuchen oder aggregieren könnten.
• Schätzen Sie die erwartete Aktualisierungshäufigkeit und die gleichzeitige Nutzung ab.
• Besprechen Sie repräsentative Tests mit den für die Datenbank verantwortlichen Personen.
• Halten Sie fest, welche Abfragesteuerungen Sie überprüft haben und welche noch unbekannt sind.

Planen Sie Änderungen an Zugangsdaten und Zuständigkeiten

Halten Sie fest, wer für die BI-Verbindung verantwortlich ist und wer die Datenbankzugangsdaten ändern darf. Notieren Sie gegebenenfalls, welche Berichte oder geplanten Aufgaben von der Verbindung abhängen.

Dokumentieren Sie, wie Ihr Team die Zugangsdaten erneuert oder widerruft. Prüfen Sie vor einer Änderung in der entsprechenden Anwendungsdokumentation, welches Verhalten Sie verstehen müssen. Testen Sie anschließend die Verbindung und wichtige Berichte, statt deren Reaktion vorauszusetzen.

• Benennen Sie eine zuständige Person für die Verbindung und eine für die Datenbankberechtigungen.
• Dokumentieren Sie Zweck, Umfang und Änderungsverfahren der Zugangsdaten, ohne das Geheimnis selbst in der Checkliste zu speichern.
• Ermitteln Sie abhängige Dashboards und geplante Abfragen, falls solche verwendet werden.
• Testen Sie das dokumentierte Verfahren zum Erneuern oder Widerrufen der Zugangsdaten für Ihre Einrichtung.

Verwenden Sie vor dem Start eine Testmatrix

Eine erfolgreiche Verbindung ist nur ein einzelner Test. Verwenden Sie die folgende Matrix, um den für Ihr Design relevanten Zugriff, die Sichtbarkeit und das Verhalten des Quellsystems zu prüfen. Halten Sie die Ergebnisse fest und unterscheiden Sie zwischen überprüften Kontrollen und offenen Fragen.

Nutzen Sie die Ergebnisse, um zu entscheiden, ob die Verbindung für die vorgesehene Zielgruppe bereit ist. Wenn eine wichtige Einschränkung nicht nachgewiesen werden kann, überdenken Sie vor dem Start den Datenumfang oder das Design.

• Zulässiger Lesezugriff: Bestätigen Sie, dass die Verbindung auf die freigegebenen Berichtsdaten zugreifen kann.
• Verweigerter Lesezugriff: Testen Sie, sofern vorgesehen, dass kein Zugriff auf eine nicht freigegebene Tabelle, ein Schema oder eine Ansicht möglich ist.
• Benutzerzugriff: Prüfen Sie repräsentative Konten mit den Rollen Betrachter, Editor und Administrator anhand der Berichte, die sie sehen beziehungsweise nicht sehen sollen.
• Sensible Daten: Prüfen Sie, ob eingeschränkte Felder und Datensätze in den getesteten Berichten offengelegt werden.
• Auswirkungen auf das Quellsystem: Beobachten Sie repräsentative Abfragen und Aktualisierungen gemeinsam mit der für die Datenbank zuständigen Person.
• Reaktion auf Änderungen: Testen Sie das dokumentierte Verfahren zum Ändern oder Widerrufen der Zugangsdaten.
• Halten Sie Testdatum, verantwortliche Person, Ergebnis und offene Fragen fest.

Behandeln Sie Hosting und Data Governance als getrennte Entscheidungen

Ein verwalteter Betrieb kann den Aufwand für die Verwaltung der Anwendungsinfrastruktur verringern. Er entscheidet jedoch nicht, welche Datenbankdatensätze die BI-Verbindung lesen oder wer die Ergebnisse sehen darf. Ihr Team muss diese Zugriffs- und Governance-Entscheidungen weiterhin treffen und überprüfen.

Airbip bietet für Anwendungen in seinem öffentlichen Katalog einen verwalteten Betrieb an. Die Anwendungsinstanzen laufen dabei als Docker-Workloads auf Airbip-Cloudservern. Airbip automatisiert Routing und TLS-Zertifikate und umfasst DNS-Prüfungen, die Verwaltung des Dienstlebenszyklus sowie konfigurierbare tägliche, wöchentliche und monatliche Backups. Diese Infrastrukturleistungen ersetzen weder ein Datenbankdesign nach dem Prinzip der minimalen Berechtigungen noch die Überprüfung der Kontrollen der ausgewählten BI-Anwendung.