Secure Operation (Integration Services)
As at every stage in the life cycle of an Integration Services package, you can enhance security when you are managing deployed packages in a production environment by implementing these measures:
Ensure that you only open and run packages from trusted sources.
In regards to package operation, this means checking for a valid signature every time that that you open and run a package.
Ensure that only authorized users open and run packages.
In regards to package operation, this means that you should use the security features available in Integration Services, SQL Server, and the file system to achieve the following goals:
Control access to stored packages and to the additional files that are associated with those packages.
Control access to the Integration Services service.
Packages can be signed with digital certificates. These digital certificates identify the individual or the organizational unit that created or last modified the packages. Administrators can configure Integration Services to require a valid and trusted signature for the packages, to check the signatures when it opens packages, and to warn about or reject unsigned packages.
Adminstrators can configure Integration Services to check signatures on all packages or on individual packages:
Check signatures on all packages by setting a registry value. You can enforce a policy that checks for signatures on all packages that are loaded and run on a computer by setting the optional BlockedSignatureStates registry value. For more information, see How to: Implement a Signing Policy by Setting a Registry Value.
Check signatures when you run an individual package from the dtexec utility (dtexec.exe). You can check the signature of an individual package by specifying the VerifySigned option at the dtexec command line. For more information, see dtexec Utility (SSIS Tool).
For more information about digital signatures, see Using Digital Signatures with Packages.
Packages can be stored 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 run packages, those packages sometimes create additional files such as configuration files, log files, and checkpoint 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.
Any user who can connect to the Integration Services service in Management Studio can see:
The list of stored packages and the locations where those packages are stored.
The running packages that the user started. (Administrators can see all running packages.)
For information about how to control access to the Integration Services service in Management Studio, see Controlling Access to the Integration Services Service.