The Real MTCS SQL Server 2008 Exam 70/432 Prep Kit- P80 ppt

ETLTechniques•Chapter8 377 Securing 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 Tool Description 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. 378 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 ETL Techniques • Chapter 8 379 It 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. Database Role Default Access 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 380 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 Utility Description 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 ETLTechniques•Chapter8 381 Table 8.8 Continued. SSIS Package Execution Methods Utility Description 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. . can run the package. Continued ETLTechniques•Chapter8 381 Table 8.8 Continued. SSIS Package Execution Methods Utility Description SQL Server Agent The SQL Server Agent has a SQL Server Integration. 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. 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