Für ein stets aktuelles und somit aussagekräftiges BI-System müssen die Daten im OLAP-Würfel regelmäßig aktualisiert werden. Die hierzu erforderlichen ETL-Prozesse werden in der Regel nachts, wenn wenige Zugriffe auf das System erfolgen, durch Datenbankjobs gestartet. Dabei greift die Jobroutine möglichst auf ein zuvor festgelegtes SSIS-Paket zurück, welches die ETL-Schritte per Datenflusslogik definiert und auch ausführt. Dieses Paket kann nun zum einen lokal auf dem Dateisystem des Servers vorgehalten und zur Laufzeit angesprochen werden, oder aber auch in direkter Verknüpfung in den Speicher des SQL Servers geladen werden. Letzteres gewinnt vor allem dann an Bedeutung, wenn im Zuge des ETL-Prozesses passwortgeschützte Vorsysteme angesprochen werden, deren Authentifizierung in den Einstellungen des Paketes enthalten sind. Ein Weg, wie dies von Statten gehen kann, wird im Folgenden beschrieben.
Wenn der Datentransfer beispielsweise bei der Zusammenstellung der SSIS Importlogik an die Tabellen aus AS400 geknüpft ist, dann wird im Verbindungsmanager meist ein Passwort hinterlegt, um den Zugriff auf die operativen Vorsysteme zu gewährleisten. Nun ergibt sich bei der Verwendung von SSIS-Paketen das Problem, dass Passwörter in Verbindungsmanagern nur dann gelesen und verwendet werden können, wenn auch das gesamte SSIS-Paket in einer verschlüsselten Form gespeichert und zur Laufzeit mit den durchaus sensiblen Login-Daten aufgerufen werden kann. Hier bieten sich in den Paketeinstellungen eine Reihe von Speicheroptionen.
DontSaveSensitive
Hier wird das Paket komplett ohne ‚sensible’ Daten gespeichert, d. h. bei externem Aufruf des Paketes oder mit einem anderen User, stehen die Login-Daten nicht zur Verfügung
EncryptSensitiveWithUserKey
Verschlüsselt die sensiblen Login-Daten, jedoch ist ein späterer Aufruf nur mit dem verschlüsselnden User möglich
EncryptSensitiveWithPassword
Verschlüsseln der sensiblen Daten mit einem auch extern aufrufbaren Passwort
EncryptAllWithPassword
Die hier gewählte Variante verschlüsselt das gesamt Paket mit einem Passwort
EnryptAllWithUserKey
Das gesamte Paket wird mit einem auf dem erstellenden User basierendem Passwort versehen
ServerStorage
Zugriffssteuerung des Paketes mit einer Datenbankrolle
Die hier angewandte Verschlüsselung basiert auf dem Prinzip „Encrypt Sensitive With Password“, welche dem Paket eine allgemeingültige Passwortverschlüsselung zuweist und somit auch aus dem späteren Datenbankspeicher mit unterschiedlichen Benutzern gelesen werden kann.
Um diese passwortgeschützte ETL-Steuerung nun zur Laufzeit des Datenbankjobs im System zur Verfügung und vor allem inklusive aller Freischaltinformationen im Einsatz zu haben, empfiehlt sich die Speicherung des Paketes im Integration Services Speichermodul des SQL Servers. Hierzu muss zunächst eine Verbindung zu dem Speichermodul hergestellt werden.
Unter Stored Packages -> MSDB -> Import Packages können nun neue SSIS Datenflussbezeichner in den Paketspeicher des Servers geladen werden. Da zunächst ein SSIS-Paket aus dem lokalen Dateisystem in den Server geladen werden soll, wird hier die Option ‘FileSystem’ als der das Paket vorhaltende Ort ausgewählt. Nachdem ein Name für das erstellte Objekt im Server vergeben wurde, kann der Sicherheits-/Speicherlevel, mit welchem das Paket gespeichert wird, überprüft, bzw. eingestellt werden. Im Standardverhalten wird die Einstellung des lokalen Paketes übernommen. Diese kann dann aber im gleichen Umfang wie zuvor beschrieben, verändert werden.
Ein aussagekräftiger Test, ob die Richtlinien der Berechtigung in den Speicher des Servers transportiert wurden, besteht darin, dass bei Klick auf den OK-Button eine Eingabeaufforderung zur Paketvalidierung erfolgt. Diese muss dann mit Eingabe des zuvor versehenen Passworts bestätigt werden.
Nach diesem Schritt sollte das Paket im IS-Speicher angezeigt werden.
Ziel ist es nun, dieses Paket aus dem IS-Speicher mit dem täglich laufenden Job zu verknüpfen, um so alle Stufen der Verschlüsselung in den Ladeprozess mit einzubeziehen.
Dies geschieht folgendermaßen:
Der Job sollte über einen Ausführungsschritt verfügen, der den Aufruf des SSIS Pakets darstellt (hier im Beispiel „SSIS-Paket ausführen“) und vom Typ „SQL Server Integration Services Package“ ist. Als ausführender User bietet sich der SQL Server Agent Services Account an, wobei es je nach Sicherheitskonzept und Rollenmanagement im Projekt durchaus auch erforderlich sein kann, hier einen ausreichend berechtigten User speziell für die Ausführung des Jobs anzulegen. Da die jeweiligen Zugriffe auf die Vorsysteme komplett in dem Paket gespeichert sind, reicht es aus, wenn der User die Rechte zum Ausführen des Paketes besitzt. Eine gesonderte Autorisierung des Users für jedes der Vorsysteme ist nicht erforderlich.
Des Weiteren ist hier die Auswahl des Speicherortes von zentraler Bedeutung. Wenn der SSIS Package Store gewählt ist, löst man sich von jeglicher Struktur des Dateisystems. Zuletzt muss noch das Paket auf dem Server ausgewählt werden und der Job läuft inklusive eines in der Datenbank gespeicherten SSIS-Paketes. Neben der Anbindung von Paketkonfigurationsdateien ist hier auch die Weitergabe bestimmter Kommandozeilenargumente möglich.
Vor- und Nachteile dieser Speicherung
Ein klarer Vorteil einer solchen Paketspeicherung liegt darin, dass mit relativ wenig Aufwand auf eine Vielzahl von Login- und Userinformationen, die mit einem Masterpasswort zentral im Paket abgelegt sind, zugegriffen werden kann. Darüber hinaus bietet ein Loslösen von der Struktur des Dateisystems den Vorteil, dass bei einer Umstrukturierung der Pfade und der Ordnerlogik kein Anpassungsaufwand an den täglich laufenden Job entsteht. Eine Anpassung wäre nur dann erforderlich, wenn grundlegende Änderungen in der Struktur der Serverlandschaft vorgenommen würden. Demgegenüber steht eine Einbuße bei der Flexibilität des Jobs, denn wird das SSIS-Paket im Dateisystem angepasst, sind diese Änderungen nicht automatisch auch im Job kenntlich. Hier muss das Paket erst erneut in den Server Storage geladen werden, um für die tägliche Verarbeitung zur Verfügung zu stehen.
Alternativ bietet sich noch die Möglichkeit, das Paket im Dateisystem zu belassen und einen Aufruf per Analysis Services Command zu starten, welches ebenfalls die Weitergabe eines Passwortes erlaubt, jedoch ein wenig kryptischer in der Handhabe ist.
