Secure Deployment (Integration Services)

Identifying the Source of Packages by Using Digital Signatures

You can sign a package with a digital certificate that identifies the individual or organizational unit that created or last modified the package. Then, administrators can specify optional settings in the registry or at the dtexec command line to configure Integration Services to perform the following tasks:

• Require a valid and trusted signature for the package.

• Check the signature when it opens a package.

• Warn about or reject unsigned packages.

For more information about digital signatures, see the following topics:

• Using Digital Signatures with Packages

• How to: Sign a Package by Using a Digital Certificate

• How to: Implement a Signing Policy by Setting a Registry Value

Protect the Contents of Packages by Setting the Protection Level

By setting the ProtectionLevel property of a package, you can encrypt any sensitive data that the package contains, such as passwords, or all the contents of the package. For example, you can set the following protection levels:

• You can remove sensitive data completely by selecting the DontSaveSensitive option.

• You can ensure that only those who provide a password can see the sensitive data by selecting the EncryptSensitiveWithPassword option.

• You can ensure that only those who provide a password can load and run the package by selecting the EncryptAllWithPassword option.

• Make sure to remove the EncryptSensitiveWithUserKey and EncryptAllWithUserKey options when you deploy a package to other computers. During development, a developer can set the EncryptSensitiveWithUserKey option to ensure that only he or she can see the sensitive data. Likewise, a developer can set the EncryptAllWithUserKey option to ensure that only he or she can load and run the package. However, when you deploy a package to other computers, these options prevent any user other than the package creator from loading and running the package. Furthermore, these two options will prevent you from scheduling the package by using SQL Server Agent.

During development, a developer might use a lower setting for the protection levels. However, when you deploy the package, changing the protection level to a higher setting might be appropriate.

When you import or deploy packages to SQL Server, the ServerStorage protection level becomes available for use together with Integration Services roles. For more information about these roles, see Using Integration Services Roles.

For more information, see Setting the Protection Level of Packages.

Control Access to Deployed Packages and to Files Created or Used by Packages

When you deploy packages, you can decide whether to store them in the msdb database in SQL Server or in the file system.

• When you store packages in SQL Server. You can use the security features available in SQL Server, and the fixed database-level Integration Services roles to control access to stored packages. For more information about these roles, see Using Integration Services Roles.

• When you store packages in the file system. You can use the security features available in Microsoft Windows, and the access control lists (ACLs) available in the file system, to control access to stored packages.

When you deploy packages, the deployment might include additional files such as configuration files. These files might also contain sensitive data. For information about how to control access to these additional files, see Controlling Access to Files Used by Packages.

See Also

Concepts