Überblick
SQL Server Integration Services (SSIS) ist ein äußerst mächtiges Toolset für die Entwicklung von ETL-Strecken. Es gibt viele gute Gründe, die für einen Einsatz von SSIS sprechen. Es gibt derer aber auch genügend, die dagegen sprechen. Beschränken wir uns auf den Microsoft Produkt Stack, dann kommt als Alternative für die Entwicklung von komplexen ETL Strecken (im Wesentlichen) nur noch Transact-SQL (T-SQL) in Frage.
Dieser Artikel gehört zu einer Serie von Artikeln, die wichtige Entscheidungskriterien für die Wahl der richtigen Technologie(n) – SSIS und/oder T-SQL – beleuchten.
Wird ein SQL Agent Job gestartet, dann werden die einzelnen Stepps in dem Job standardmäßig in dem Security Kontext des Service-Accounts von dem SQL Server Agent ausgeführt.
Bei der Installation von SQL Server Agent ist ein Service Account anzugeben, unter dem der Dienst SQL Server Agent gestartet werden soll. Der Benutzer hat die Wahl zwischen der Angabe eines expliziten Kontos und der Auswahl des lokalen Systemkontos NT-AUTORITÄT\System.
Mit der Auswahl des Kontos verfügt der angegebene Service Account über einen Satz an Berechtigungen, die sehr wahrscheinlich nicht für alle SQL Server Agent Jobs entweder ausreichend oder erforderlich sind.
So verfügt das lokale Systemkonto NT-AUTORITÄT\System über umfassende Berechtigungen an lokalen Ressourcen und ist Mitglied der Windows-Gruppe Administratoren. SQL Server Agent Jobs können auf diesem Weg auf Ressourcen zugreifen, die für die Ausführung nicht erforderlich sind und die ggf. sogar vor unbefugtem Zugriff zu schützen sind. Auf der anderen Seite hat das Systemkonto in der Regel keine oder keine ausreichenden Berechtigungen an File Shares, Datenquellen etc.
Nach dem need-to-know-Prinzip sollte der Benutzer, unter dem ein Job ausgeführt wird, nur über die erforderlichen Berechtigungen verfügen, die für die Erledigung der Aufgabe – hier das Ausführen des SQL Server Agent Jobs – erforderlich sind.
Da in dem SQL Server Agent regelmäßig zahlreiche Jobs konfiguriert werden, die alle sehr unterschiedliche Aufgaben zu erledigen haben und dafür unterschiedliche Ressourcen benötigen, ist es nicht möglich den Service Account nach dem need-to-know-Prinzip mit den passenden Rechten auszustatten.
Microsoft bietet als Lösung für dieses Problem den Identitätswechsel zur Laufzeit an. Der technische Fachbegriff hierfür ist die Impersonierung. Die Impersonierung erfolgt auf der Ebene eines SQL Agent Job Stepps, in dem ein SSIS Paket auszuführen ist, durch Angabe eines sogenannten Proxy-Users. Dieser wird im SQL Agent in dem Order SQL Server Agent | Proxies | SSIS Package Execution erzeugt und referenziert einen Anmeldeinformationsnamen (Credential-Objekt) einer SQL Server Instanz, der in dem Ordner Security | Credentials der jeweiligen Instanz zu erzeugen ist. Mit dem Anmeldeinformationsnamen ist ein Datenbank-Login (SQL Server Authentifizierung oder Windows Authentifizierung) verbunden, der entsprechend den Anforderungen in der Datenbank, Fileshares, etc. zu berechtigen ist.
Alle Artefakt-Typen, die als Stepp konfiguriert werden können, unterstützen die Run As Property, außer der Typ Transact-SQL Script. ETL-Strecken, die ausschließlich auf der Basis von Transact-SQL erstellt wurden, können daher nicht über den SQL Server Agent impersoniert werden.
ETL-Strecken, die als Startpunkt über ein SSIS Paket verfügen, können über den SQL Server Agent impersoniert werden. Die Verwendung eines SSIS Paketes als Startpunkt einer ETL-Strecke bedeutet nicht zwangsläufig, dass die komplette ETL-Strecke in SSIS realisiert werden muss. Ebenso gut kann die ETL-Strecke auf der Basis von Transact-SQL realisiert werden. Die Skripte, Stored Procedures, Stored Functions etc. sind in diesem Fall über SQL Command Tasks in einem SSIS Paket auszuführen.
Fazit
- Sofern für die Ausführung einer ETL-Strecke einen Identitätswechsel erfordert, führt kein Weg an SSIS vorbei.
- Die Notwendigkeit der Verwendung eines SSIS Paketes als Startpunkt einer ETL-Strecke erfordert nicht die Realisierung der Streck ausschließlich in SSIS. Die ETL-Strecke kann auch weiterhin mit T-SQL entwickelt werden.