SSIS 包有一个名为 ProtectionLevel 的属性，其中包含几个可能的值。 任何人都可以提供可用的 ProtectionLevel 选项的解释以及它们在包中的行为示例吗？ 使用 ProtectionLevel 属性的优缺点是什么。
谢谢。
【问题讨论】：
http://technet.microsoft.com/en-us/library/ms141747(v=sql.90).aspx 和 http://www.mssqltips.com/sqlservertip/2091/securing-your-ssis-packages-using-package-protection-level/
标签： ssis
包保护级别有几种不同的风格。这个想法是 SSIS 知道诸如连接字符串之类的东西可能包含敏感信息，如密码。如果您是供应商并且您的产品是 WhizBangPackage，那么该软件包本身可能包含专有信息，您不希望人们看到魔术是如何工作的。出于这些原因以及更多原因，MS 具有如何将底层 XML 以及 SSIS 包的全部内容写入磁盘的概念。
EncryptSensitiveWithUserKey 这是默认设置。任何可能敏感的东西都被认为是敏感的。保存包后，VS 将使用原作者的 Active Directory 帐户的一些位来加密连接字符串等内容。即使该连接字符串使用 SSPI，因此没有密码，它仍然会加密底层 XML 中的连接字符串。当程序包运行时，SSIS 将与 AD 对话以解密该信息。通常，在软件包的原始作者不再与公司合作并且他们的 AD 帐户被删除之前，一切都运行良好。我们在使用 SQL Server 2005 时遇到的问题是，运行该包的 SQL 代理作业无法解密该包。开发人员可以去打开包，它在交互模式下运行良好，但在非交互模式下失败。立即的解决方案是将作者更新为具有活动 AD 帐户的人并重新部署。这可能会在当前/未来的版本中得到修复，但这是我的战争故事。
DontSaveSenstive 这是我唯一需要使用的设置。保存时，SSIS 不会将任何看起来像密码的内容写入 .dtsx 文件。根据我的经验，在保存当前设计会话后它也会将其空白，从而导致立即验证错误。特别是，这使得 FTP 任务成为一个可以使用的 PITA，除非您正在使用配置，因为这是在环境之间迁移包的唯一明智的方式。使用配置来帮助 SSIS 连接管理器“记住”密码，而无需访问磁盘。
EncryptSensitiveWithPassword 现在不是使用 AD 帐户来加密敏感位，而是使用开发人员提供的密码。这样做的缺点是对于超过 1 人的团队，您现在有一个共享密码，而多人共享的密码违背了拥有密码的目的。
EncryptAllWithPassword 不只是加密敏感位，而是使用密码加密整个 XML。与以前相同的缺点，共享秘密 = 没有秘密。此外，如果您丢失了密钥，您会感到沮丧并重新创建您的包。
EncryptAllWithUserKey 与密码相同，以作者的 AD 帐户为密钥对整个文件进行加密。与上面相同的缺点是，该帐户消失了，并且没有解锁包的密钥。
ServerStorage - 无论您的本地设置如何，假设您部署到 msdb 目录，包将在数据库中加密。老实说，我从来没有用过它。我们部署到 msdb，但依靠我们的配置来保护敏感数据的私密性。
【讨论】：