使用包保护级别的SSIS包

Question

SSIS包具有一个称为ProtectionLevel的属性，具有多个可能的值。
谁能提供可用的ProtectionLevel选项的解释以及它们在程序包中的行为示例？
使用ProtectionLevel属性的优缺点是什么？

谢谢。

Answer 1

包装保护等级有几种不同的口味。这个想法是SSIS知道诸如连接字符串之类的内容可能包含诸如密码之类的敏感信息。如果您是供应商，而您的产品是WhizBangPackage，则包装本身可能包含专有信息，您不希望人们看到魔术的工作原理。由于这些原因以及更多原因，MS的概念是如何将底层XML(就是SSIS包的全部内容)写入磁盘。

EncryptSensitiveWithUserKey，这是默认设置。任何可能敏感的东西都被认为是敏感的。保存软件包后，VS将使用原始作者的Active Directory帐户的某些位来加密连接字符串之类的内容。即使该连接字符串使用的是SSPI，因此也没有密码，它仍会加密基础XML中的连接字符串。程序包运行时，SSIS将与AD对话以对该信息进行解密。通常，在软件包的原始作者不再在公司任职并且其AD帐户被删除之前，所有方法都可以正常工作。我们在SQL Server 2005中遇到的问题是运行该程序包的SQL Agent作业无法对该程序包进行解密。开发人员可以打开包，并且在交互模式下可以正常运行，但在非交互模式下会失败。立即的解决方案是将作者更新为具有有效AD帐户并重新部署的人员。这可能在当前/将来的版本中已修复，但这是我与此有关的 war 故事。

DontSaveSenstive，这是我曾经需要使用的唯一设置。保存时，SSIS不会将任何看起来像密码的内容写入.dtsx文件。根据我的经验，在保存您当前的设计 session 后，它也会将其清空，从而导致立即验证错误。特别是，这使FTP任务成为PITA可以使用的任务，除非您使用配置，否则应该这样做，因为这是在环境之间迁移软件包的唯一明智的方法。使用配置可帮助SSIS连接管理器“记住”密码，而不会碰到磁盘。

EncryptSensitiveWithPassword现在，您使用开发人员提供的密码，而不是使用AD帐户来加密敏感位。不利的一面是，对于多于一个人的团队，您现在拥有一个共享密码，并且一个以上人共享的密码无法达到拥有密码的目的。

EncryptAllWithPassword而不是仅加密敏感位，这将使用密码来加密整个XML。与以前一样，共享 secret =没有 secret 。另外，如果您丢失了 key ，则会陷入困境并重新创建软件包。

EncryptAllWithUserKey与使用密码相同，它使用作者的AD帐户作为 key 来加密整个文件。与上述相同的缺点是，该帐户消失了，没有 key 可以解锁包裹。

ServerStorage-本地设置无关紧要，假设您部署到msdb目录，则软件包将在数据库中加密。老实说，我从未使用过它。我们部署到msdb，但是依靠我们的配置将敏感数据保密。