Die kontinuierlich fortschreitende Digitalisierung der heutigen Geschäftswelt erfordert ein stetes Überprüfen und Hinterfragen von Sicherheitsmechanismen gegen Datenverlust oder -Diebstahl. Gerne zusammengefasst unter dem Begriff IT-Sicherheit sind die vielfältigsten Ansatzpunkte dabei zu beachten. Durch die erhöhte Sensibilität unserer Kunden steigen naturgemäß die Restriktionen was Berechtigungen und Zugriffe auf zentrale IT-Systeme angeht. Die direkte Verbindung von DeltaMaster (Rich-Client) zu den MS Analysis Services (kurz: SSAS) stellt einen dieser Teilaspekte dar, welcher immer öfter durch Policys unterbunden werden soll. Wie diese direkte Client-Server-Verbindung unterbunden bzw. weiter abgesichert werden kann, zeigt der heutige Blogbeitrag.

Allgemein

DeltaMaster Rich-Client kommuniziert im Standard über eine direkte Client-Server-Verbindung mit dem zugrundeliegenden Datenbankserver. Auch bei Einsatz des DeltaMaster Repositorys (Verwaltungsdatenbank für DeltaMaster-Anwendungen) erfolgt nach Auswahl einer Anwendung durch den Benutzer für die Abfrage der Daten innerhalb der Anwendung eine direkte Verbindung vom Client zum Serversystem. Eben diese direkte Verbindung stellt ein Sicherheitsproblem dar, denn sollte ein Clientrechner kompromittiert sein, könnte ein Angreifer über die direkte Verbindung auch unerlaubten Zugriff auf den Datenbankserver und von dort evtl. zu weiteren Systemen erhalten. Aus diesem Grund gehen immer häufiger Unternehmen dazu über, Applikationen eine direkte TCP-Verbindung zu Datenbankservern zu untersagen. Wie aber kommt dann ein Benutzer über DeltaMaster an die aktuellen Daten?

Eine Lösungsmöglichkeit ist die Kapselung des Zugriffs über einen zentralen Windowsdienst, so dass die eigentliche Verbindung ausschließlich von dem Dienst in dessen Sicherheitskontext hergestellt wird und verschlüsselt werden kann.

Wenn Microsoft SQL Server Analysis Services (kurz: SSAS) als multidimensionales Datenbanksystem im Hintergrund verwendet wird, existiert eine schlanke und recht elegante Lösung für die Kapselung des Zugriffs bei derartigen restriktiven Vorgaben: die sogenannte MSDataPump!

Zur Erklärung: Die MSDataPump (auch als SSASProxy bezeichnet) ist eine spezielle DLL, welche direkt von Microsoft kostenlos zur Verfügung gestellt wird. Die MSDataPump wird als Webapplikation auf einem Internet Information Server (kurz: IIS) eingerichtet, somit fungiert der Windowsdienst „WWWPublishingdienst“ als Kapsel. Denkbar ist auch die Einrichtung auf Webservern anderer Anbieter wie zum Beispiel dem Apache WebServer der Apache Software Foundation. Darüber hinaus kann durch den Einsatz eines Webservers die Verbindung zusätzlich verschlüsselt werden, Stichwort Transport Layer Security (kurz: TLS). Besser bekannt unter dem veralteten Begriff Secure Socket Layer (kurz: SSL). Hier wird die Verbindung selbst durch ein signiertes Zertifikat zusätzlich verschlüsselt, sodass Daten nicht direkt auf Netzwerkebene entwendet werden können.

Zur Veranschaulichung der Unterschiede soll folgendes Schaubild dienen:

Abbildung 1: Architekturskizze Vergleich klassisch vs. SSASProxy

Voraussetzungen & Restriktionen

• Client und Server befinden sich in der gleichen Active-Directory-Domäne.
• Betriebssystem der beteiligten Serversysteme ist Microsoft Windows.
• Wenn zusätzliche SQL-Durchgriffsberichte (kurz: SQL-DT) verwendet werden sollen, ist die Einrichtung von Kerberos als Authentifizierungsprotokoll (Stichwort: DoubleHop-Problem) notwendig.
• Für den wartungsfreien Betrieb mit aktivierter Transportverschlüsselung (TLS) sollte ein gültiges Zertifikat einer öffentlichen Zertifizierungsstelle vorhanden sein. Selbstsignierte Zertifikate haben eine maximale Gültigkeit von einem Jahr, funktionieren aber natürlich. Bekannte Zertifizierungsstellen sind z. B. VeriSign oder GeoTrust.
• Installationsrechte auf dem Applikationsserver
• Empfohlen: Dediziertes Active-Directory-Konto, unter welchem der Anwendungspool der MSDataPump ausgeführt wird (Einschränkung des Dateisystemzugriffs auf genau dieses eine Konto möglich). Dieses Konto muss Zugriffsrechte auf die Analysis-Services-Datenbanken besitzen.

Einrichtung

Die Installation, Konfiguration und Einrichtung des SSASProxys ist sehr gut von Microsoft dokumentiert und kann 1:1 umgesetzt werden. In diesem Blogbeitrag gehen wir daher nur auf die relevanten Einstellungen ein, alle Details mit Screenshots können hier nachgelesen werden.

Die gesamte Einrichtung der MSDataPump umfasst im groben fünf Teilschritte und ist in wenigen Minuten (ausreichende Berechtigungen vorausgesetzt) erledigt:

• Download und Installation von zusätzlich erforderlichen IIS-Komponenten
• Download und Installation vom Analysis-Services-OLE DB Anbieter (kurz: MSOLAP) über die SQL Server Feature Packs (letzte Version ist für SQL-Server 2014 und folgende) auf dem Applikations-/Webserver
• Konfiguration der MSDataPump in IIS
• Test der Einrichtung
• Anpassung des ConnectionStrings in DeltaMaster-Anwendungen

Download & Installation der IIS-Komponenten

Die Installation der IIS-Komponenten auf dem Webserver erfolgt über den Servermanager – Rollen und Features. Wenn der Webserver auf einem Clientsystem installiert werden soll, dann über Systemsteuerung – Programme und Features – Windows Features aktivieren. Benötigte Features sind:

• Sicherheit – Windows-Authentifizierung
• Anwendungsentwicklung – CGI
• Anwendungsentwicklung – ISAPI-Erweiterungen

Abbildung 2: zusätzliche IIS-Komponenten

Für die Installation muss einfach der Haken vor den o. a. Komponenten gesetzt und der Dialog mit OK bestätigt werden.

Download & Installation von MSOLAP

Damit die MS Analysis Services über http bzw. https angesprochen werden können, muss der Webserver einen entsprechenden Anbieter für den OLAP-Server kennen. Dazu dient der Analysis-Services-OLE DB-Anbieter.

Dieser ist Bestandteil des SQL-Server-Feature-Packs und kann hier heruntergeladen werden. Benötigt wird die Datei ENU\x64\SQL_AS_OLEDB.msi. Der SSASProxy bzw. die MSDataPump sind in diesem Paket ebenfalls enthalten.

Die Installation ist denkbar einfach: Nach Doppelklick auf der msi-Datei die Anweisungen im Dialog befolgen, fertig!

Konfiguration von SSASProxy in IIS

Bis hierher haben wir die benötigten Rahmenbedingungen geschaffen, ab jetzt kommt der interessante Abschnitt. Wie oben erwähnt, ist das Vorgehen Schritt für Schritt in der Dokumentation von Microsoft beschrieben und muss hier nicht separat wiederholt werden. Dennoch nennen wir hier kurz stichpunktartig die Teilschritte:

• Dateisystem: Anlegen eines Ordners unter <Laufwerk>:\inetpub\wwwroot\OLAP und einfügen der Dateien MSMDPUMP.dll, MSMDPump.ini sowie des Ordner-Ressources aus dem Installationsverzeichnis des zuvor installierten OLE DB-Anbieters.
• IIS: Erstellen eines separaten Anwendungspools OLAP mit Verweis auf das soeben erstellte Verzeichnis.
• IIS: Konvertieren des Verzeichnisses OLAP in eine Anwendung (Rechtsklick in Baumstruktur unterhalb der Default Website)
• IIS: Zuweisen des Anwendungspools OLAP zu der Anwendung OLAP
• IIS: Zuweisung der gewünschten Authentifizierung. Es empfiehlt sich Windows-Authentifizierung zu verwenden. Ohne Tools von Drittanbietern für Zugriffe z. B. mit PKI-Karten (PKI: private key infrastructure) bietet diese Methode die höchstmögliche Sicherheitsstufe. Alle nicht verwendeten Anbieter sollten deaktiviert werden.
• IIS: Hinzufügen eines Handler-Mappings für die msmdpump.dll. Bei der Bestätigung der Skriptzuordnung kann die Verwendung von ISAPI-Extensions direkt mitaktiviert werden.
• Dateisystem: Festlegen des Zielservers (SSAS) in der Datei msmdpump.ini. Es wird empfohlen als Servernamen die vollqualifizierte Schreibweise zu verwenden. Wenn SSAS unter einer benannten Instanz installiert wurde, so muss diese ebenfalls angegeben werden.

Abbildung 3: msmdpump.ini mit benannter SSAS-Instanz

Optional:

• IIS: Aktivierung von https über die Bindungen der Default Website.

Abbildung 4: Zertifikatsauswahl für https

Wenn es ausreicht, dass ein Zertifikat jedes Jahr manuell erneuert werden muss, kann ein selbstsigniertes Zertifikat ausgestellt werden. Um dies zu erstellen, wechselt man im IIS links auf den Instanzknoten und anschließend in der Mitte des Fensters mit Doppelklick auf Serverzertifikate. Rechts unter Aktionen kann man ein selbstsigniertes Zertifikat erstellen.

Abbildung 5: selbstsigniertes Zertifikat erstellen

Es reicht aus, im erscheinenden Dialog einen Namen zu vergeben und das Zertifikat im persönlichen Zertifikatsspeicher abzulegen.

Test der Einrichtung

Der erste Test erfolgt in einem Browserfenster direkt auf dem Webserver. Aufruf folgender URL:

http oder https://servername.domäne/OLAP/msmdpump.dll

Anschließend sollte sich ein Dialog zur Authentifizierung automatisch öffnen.

Abbildung 6: Testzugriff auf SSASProxy mit https

Nach Eingabe des Benutzernamens und Passworts des angemeldeten Benutzers bzw. des Benutzers, der Zugriffsberechtigungen auf die OLAP-Datenbank besitzt, sollte im Erfolgsfall folgende Meldung erscheinen:

Abbildung 7: Erfolgsmeldung

Es klingt zwar nach einer Fehlermeldung, aber dabei handelt es sich um eine korrekte XMLA-Antwort des SSASProxys und somit der OLAP-Datenbank, was bedeutet, dass in diesem Beispiel bereits eine Anfrage an die MSDataPump per http(s) gestellt und beantwortet wurde.

Wenn https eingerichtet wurde und die Meldung im Browser in etwa so aussieht:

Abbildung 8: Zertifikatsfehler

Oft neigt man dazu, unter Details das Laden der Website fortzusetzen (was auch funktioniert). Hintergrund des Fehlers ist hier lediglich, dass der in der URL angegebene Servername BC-REU-LAP nicht mit dem Servernamen innerhalb des Zertifikats (BC-REU-LAP.company.bc.de) übereinstimmt. Verwendet man die korrekte Schreibweise aus dem Zertifikat wird vom Browser auch keine Meldung zurückgegeben. Mit Rechtklick auf das rote Zertifikatsfehler kann man sich das Zertifikat anzeigen lassen und bekommt den gewünschten Servernamen.

Als weiterführenden Test kann man die URL auch als Zielserver in SQL Server Management Studio (kurz: SSMS) verwenden. Ist die Konfiguration korrekt, kann die Verbindung hergestellt und die Datenbank wie gewohnt bearbeitet werden.

Abbildung 9: Test SSASProxy über SSMS

Anpassung DeltaMaster-ConnectionString

Um mit DeltaMaster den soeben erstellten Zugriffsweg nutzen zu können, muss lediglich die entsprechende Anwendung im Wartungsdialog geöffnet und als Zielserver die genannte URL eingetragen werden.

Abbildung 10: Servername = URL

Anschließend muss die Datei gespeichert und einmal neu geöffnet werden.
Wenn Sie danach beim Starten der Anwendung folgende Meldung erhalten…

Abbildung 11: Fehlermeldung bei falscher URL

…dann haben Sie Punkt 2.4. zu schnell gelesen oder vielleicht versehentlich übersprungen! Denn der Auslöser ist nur die Verwendung der falschen URL (hier wegen der Kurz- statt Langschreibweise des Servernamens). Denn die im Browser gezeigte Meldung des Zertifikatsfehlers quittiert DeltaMaster mit der oben gezeigten.

Fazit

Wir sind selbst überrascht, wie schnell und letztendlich auch simpel sich die Einrichtung eines SSAS-Proxys unter Microsoft SQL Server gestaltet hat. Es zeigt einmal mehr, wie wichtig gute Dokumentationen sind, hier hat Microsoft ganze Arbeit geleistet.

Die dargestellte Lösung hat den entscheidenden Vorteil, dass keine Anpassungen am Datenbanksystem notwendig sind. In der Praxis gestaltet sich das allzu oft als schwierig, wenn erst Anträge geschrieben und diverse Abteilungen dazu bemüht werden müssen.

Wenn uns ein Kunde mit derartigen Sicherheitsrestriktionen konfrontiert, ist es gut, eine Antwort mit vertretbarem Aufwand parat zu haben.

Es soll aber auch nicht verschwiegen werden, dass es in der Praxis die unterschiedlichsten Varianten geben kann, welche vielleicht Stolpersteine oder gar eine andere Lösung notwendig machen. Zusätzlich noch eine Anmerkung zum Thema Abfrageperformance:

Im Einsatz merkt man beim Verbindungsaufbau und beim Aufruf der Berichte minimale Einbußen. Aber hier können wir guten Gewissens dem Kunden mit der Antwort begegnen, dass erhöhte Sicherheit (bedingt durch die kundeneigenen Regularien) nicht umsonst zu haben sind. Und die Währung in diesem Fall heißt Antwortzeit.

Aktuell keine Erfahrungen gibt es von unserer Seite zum kombinierten Einsatz von den Load-Balancern und einem SSASProxy. Technisch spricht nichts dagegen, hier sollten aber zusätzlich die Hinweise aus dem Blogbeitrag „DeltaMaster Web – Fehleranalyse und Tipps“ beachtet werden.

Quellen

https://de.wikipedia.org/wiki/Transport_Layer_Security

https://docs.microsoft.com/de-de/sql/analysis-services/instances/configure-http-access-to-analysis-services-on-iis-8-0?view=sql-server-2017

https://docs.microsoft.com/en-us/iis/manage/configuring-security/how-to-set-up-ssl-on-iis