SSIS Package Deployment Tools DTUtil DTUtil is a command-line utility that can be used to perform imports and exports of packages from the SSIS package storage on the server in addition
Trang 1Securing SSIS Packages
Once a package is deployed you can control who has the ability to run it and
change it For packages saved to the file system, you can simply use NTFS
permis-sions to control security For packages saved to SQL Server, though, you have a
role-based security model Regardless of how access to the packages is handled,
however, the sensitive information needed in a package (like credentials for
data-bases) is never stored in clear text This information is either not stored or it is
encrypted.
Using Package Protection Levels
When you save a package you can choose from a number of protection level
options These protection levels specify how much data is encrypted if any and how
it is encrypted You can decide how much of a package to encrypt and how to
encrypt it when saving a package You could not encrypt anything, encrypt just the
“sensitive” data (like passwords, or specific variable values), or encrypt the entire
package When you encrypt data, you can choose between a key that can be used
by only yourself or a password that you can share with others You also can let the
server encrypt the package if you are saving it to SQL Server Table 8.6 lists the
available package encryption options.
Table 8.5 Continued SSIS Package Deployment Tools
DTUtil DTUtil is a command-line utility that can be used to
perform imports and exports of packages from the SSIS package storage on the server in addition
to a number of other package management tasks
Trang 2378 Chapter 8 • ETL Techniques
MSDB Database Roles and SSIS Package Roles
When a package is saved to SQL Server and the “Rely on server storage for
encryption” protection level is used, access to the package is based on a combination
of some database roles in the MSDB database and the package roles assigned to the package Three specific roles exist in the MSDB database for the purpose of controlling access to packages: db_ssisadmin, db_ssisltduser, and db_ssisoperator Table 8.7 lists the roles and their level of access.
Protection Level Description
Do not save sensitive
data Any content in the package that is sensitive (like clear text credentials) will not be saved in
the package Any users who want to work with the package will have to provide that information themselves
Encrypt sensitive
with password Sensitive data is encrypted using the supplied password You can share that password with others
to allow them to open the package with the sensitive data intact
Any users who do not know the password will have to supply the sensitive values themselves Encrypt all with
password The entire package is encrypted with the shared password Users must know the password to work
with the package in any way
Encrypt sensitive
user key The sensitive data in the package is encrypted with a key that is unique to the person saving the
package Only that person can open the package with the sensitive data intact
Other users will have to resupply the sensitive data Encrypt all with
user key The entire package is encrypted with the unique user key Only the person who saved the package
can open it
Reply on server
storage for encryption This option is only available when a package is being saved to SQL Server This option allows
SQL Server to encrypt the package using its own key and limit who can access the package using package roles
This option is the preferred protection level when deploying packages to a production environment
Table 8.6 Package Encryption Options
Trang 3It should be noted that Windows administrators can view all of the running
packages and stop all packages that are running, but they don’t have the ability to
start, modify, import, export, or delete packages.
There are also two “package roles” that imply a level of access on each package:
the reader role and the writer role By default, the roles on each package are
assigned as follows:
■
■ Reader Role db_ssisadmin members and the creator of the package can
read the package.
■
■ Writer Role db_ssisadmin, db_ssisoperator, and the creator of the
package can read the package.
You could create your own roles in MSDB and assign them specifically to the
Reader or Writer roles; however, this isn’t really recommended except in rare cases
Ideally, the default database roles will meet your needs.
db_ssisadmin Full control over packages If you are a system
administrator, you don’t need any of these roles
However, this role can be used to delegate SSIS administrative tasks to an individual or Windows group
db_ssisltduser You can see all packages, but can work only with
your own You can import packages and delete or change your own packages This may be a good role for developers on development servers
db_ssisoperator You can view, execute, and export all packages as
well as schedule packages to run in the SQL Server Agent You can’t modify or delete packages
This role would be useful for a SQL Server operator
to have
Table 8.7 MSDB Database Roles
and Default SSIS Package Role Assignments
Trang 4380 Chapter 8 • ETL Techniques
Executing SSIS Packages
Once a package has been deployed to the server there are a variety of ways you can run the package The SSIS runtime is installed with Business Intelligence
Development Studio as well as with SQL Server Integration Services You can legally run the packages only in BIDS or on a computer where SQL Server
Integration Services is installed Table 8.8 lists the various utilities that you can use
to execute an SSIS package.
Table 8.8 SSIS Package Execution Methods
DTExec The DTExec command-line utility can be used manually
from the command line or from within a batch file The command line utility can retrieve a package from wherever it is stored, assign package configurations, override package properties, assign variable values, and so on
With all these possibilities, the command line can be
a little confusing to get right
Another major concern with DTExec is that any passwords required to access the package will be shown in clear text in the command line
DTExecUI The DTExecUI utility offers the same capabilities as
DTExec, but it provides you with a Windows program and a graphical user interface You can point and click to supply the various options needed rather than having to know the command line switches
The DTExecUI utility can also generate a DTExec command line for you based on the options you have selected
Object Explorer In the SSMS Object Explorer, you can connect to your
Integration Services instance, right click on a package,
and choose Run Package… You will be presented
with the same interface as DTExecUI with which you can run the package
Continued
Trang 5Table 8.8 Continued SSIS Package Execution Methods
SQL Server Agent The SQL Server Agent has a SQL Server Integration
Services Package step type Again, it offers the same options available via the DTExecUI utility If you want
to schedule your package’s execution, this is the best way to do it
The SQL Server Integration Services Package job step also makes it possible to run packages that require passwords, but have the passwords not be stored as clear text This is much more secure than using DTExec for scheduled operations when passwords are needed
Programmatically Developers can cause packages to run
programmatically
Logging Package Execution
Finally, we should mention that SSIS has an extremely flexible logging framework
Developers configure the logging in the SSIS packages You can override the
logging configuration manually when you run a package, but it would be beneficial
to have a consistent model for logging packages arranged with developers.
SSIS supports logging the results of package execution to the following
destinations:
Windows Event Log
■
■
Text Files
■
■
XML Files
■
■
SQL Server tables
■
■
SQL Server Profiler trace files
■
■
By working with the package developers, you can ensure that the right amount
of detail about the execution of your packages is recorded in a place where you can
find it easily.