Secure Deployment (Integration Services)
As at every stage in the life cycle of an Integration Services package, you can enhance security when you deploy packages from development computers to other computers by implementing these measures:
Ensure that you only open and run packages from trusted sources.
In regards to package deployment, this means identifying the source of packages by signing those packages with digital certificates.
Ensure that only authorized users open and run packages.
In regards to package deployment, this means that you should use the security features available in Integration Services, SQL Server, and the file system to achieve the following goals:
Protect the contents of packages by setting the protection level of the package.
Control access to both the packages and the additional files that are associated with those packages by using file system security.
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:
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.
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.