SSIS ProtectionLevel

Eén van de minder begrepen eigenschappen van een Integration Services package, is de ProtectionLevel property. Als je in een SSIS pakket een connectie maakt waarbij je inloggegevens op moet geven (username en wachtwoord), kunnen die door SSIS worden versleuteld. Dit om te voorkomen dat iemand die het .dtsx bestand weet te bemachtigen met deze inloggegevens aan de haal kan. De manier waarop dit gebeurt, bepaal je via de ProtectionLevel property van het pakket. De default is EncryptSensitiveWithUserKey. Dat wil zeggen dat alleen de maker van het pakket de versleutelde gegevens in het pakket kan ontsleutelen (en daardoor uit kan voeren). Niet echt handig natuurlijk wanneer je in een team werkt, wel het meest veilig. EncryptSensitiveWithPassword is een alternatief. Dezelfde gegevens worden versleuteld (alleen sensitive informatie, wat wil zeggen voornamelijk wachtwoorden bij connecties), alleen kun je nu een wachtwoord met elkaar uitwisselen waarmee iedereen die dat wachtwoord kent de versleutelde gegevens kan ontgrendelen (en daarmee het pakket op iedere machine uit kan voeren door het wachtwoord op te geven).

Als je in een package alleen maar gebruik maakt van connecties met Windows authenticatie, merk je van de ProtectionLevel property helemaal niets. Het pakket bevat dan geen ‘sensitive’ informatie. Maar wanneer je genoodzaakt bent wachtwoorden op te geven in connecties, kun je er wel hinder van ondervinden. Als je een dergelijk SSIS pakket uit wilt laten voeren in een SQL Server Agent job bijvoorbeeld. Het pakket wordt dan waarschijnlijk door een andere gebruiker uitgevoerd, tenzij de agent onder jouw account draait, maar dat zal wel niet. Het account waaronder de agent wel draait, loopt tegen een versleuteling aan waarvoor de key niet beschikbaar is, aangenomen dat de default EncryptSensitiveWithUserKey als ProtectionLevel van kracht is.

Een oplossing voor dergelijke problemen is gebruik maken van de EncryptSensitiveWithPassword optie en het gebruikte wachtwoord door te geven op de command line van de stap in je job. Om dat te doen, moet je de volgende stappen nemen:

• Zet het ProtectionLevel van het package op EncryptSensitiveWithPassword en vul bij PackagePassword een wachtwoord in door op de ‘…’ te klikken.

• Sla het package op.
• Maak een SQL Server Agent job aan met tenminste een stap van het type SQL Server Integration Services Package. Configureer deze overeenkomstig jouw situatie. Ga naar de Command line tab. Hierbij zal de wizard je al een keer prompten om het package password, maar die wordt niet opgeslagen! Dit is puur om tijdens het maken van de job bij de versleutelde gegevens in het package te kunnen.

• Selecteer op de Command line tab de optie Edit the command line manually en voeg achter de optie /DECRYPT het wachtwoord wat je hebt gebruikt toe.

• De job zou het nu goed moeten doen.

Nogmaals, de makkelijkste manier om encryptie problemen te vermijden is voorkomen dat je packages ‘sensitive’  informatie bevatten. Daarom moet je in connecties zoveel mogelijk windows authenticatie gebruiken en ervoor zorgen dat het account waaronder SQL Server Agent draait voldoende leesrechten heeft op de te benaderen databases. Dit is niet alleen de makkelijkste, maar ook een veilige methode. De packages bevatten dan helemaal geen gevoelige informatie en er wordt niets versleuteld. Eén van de andere waarden voor de ProtectionLevel property, is ServerStorage. Daarbij blijft de gevoelige informatie gewoon in het package staan en wordt er verondersteld dat de server niet zomaar toegankelijk is voor kwaadwillenden. Ook dan is er geen sprake van versleuteling en dus geen problemen met accounts en keys. Dit protectionlevel is alleen beschikbaar tijdens of na het deployen van een SSIS package naar de server.

Share this