服务器运行时安全性

A4SWIFT消息修复和新提交以安全且确定的方式控制业务用户、后端系统和 SWIFT 网络终结点之间的 SWIFT 消息流。 它验证业务用户提交的消息，验证消息的数据和业务规则的正确性，并将消息路由到后端系统或最终传送到 SWIFT 网络。 有关数字证书的详细信息，请参阅 MSDN 库网站上的 https://go.microsoft.com/fwlink/?linkid=50285“加密和签名证书”。

消息修复和新提交是一个BizTalk Server业务流程应用程序，在BizTalk Server安全上下文中托管和执行。 它作为BizTalk Server应用程序受到前面所述的BizTalk Server安全功能保护。 邮件修复和新提交还定义并强制实施特定于 SWIFT 消息创建、修复、审批和提交的用户级安全策略，如下所示：

• 通过邮件修复和新提交到BizTalk Server的所有邮件（新邮件或已修复邮件）都必须来自受信任的用户。

• 创建或修复消息的受信任用户必须具有正确的授权和权限。 批准或拒绝邮件的受信任用户必须具有正确的授权和权限。

• 所有邮件都必须得到已知数量的受信任用户批准。 消息创建者、修复者和审批者链中的每个受信任用户都必须是唯一的，同一用户不能创建、修复、批准或拒绝邮件。 同一用户无法在多步骤审批过程中为单个邮件输入多个批准或拒绝决策。 不能批准自己创建或修复的消息，也不能批准与多个审批者相同的邮件。

• 您不能在审批过程中更改邮件 (也就是说，在原始提交到“邮件修复”和“新提交”后，无法更改邮件，因为新邮件或已修复邮件) 。

• 在重新密钥验证阶段更改的消息必须与创建或修复) (原始消息完全匹配。

  为了强制实施这些安全语义，邮件修复和新提交会在创建或修复审批提交过程的每个阶段验证它收到的每个 XML 消息中嵌入的数字签名。 消息修复和新提交数字签名验证执行以下检查。 如果其中一个或多个检查失败，则消息修复和新提交将停止，并通过消息框持久保存，并在事件日志中记录安全错误：

• XML 消息必须经过数字签名，因此必须包含相应的数字签名。

• 工作流中使用的每个数字签名都必须使用受信任的数字证书进行创建。 这可确保消息创建者、修复者、验证者和审批者受信任。

• 每个受信任的数字证书都必须属于在域组中具有成员身份的 Windows 域用户，该用户具有在A4SWIFT内执行操作的逻辑权限或权限。 这可确保创建或修复-审批-提交过程中的每个参与者都具有执行其执行的特定操作的正确权限或权限。

  上述规则通过 SharePoint 网站上的 ACL 通过网站用户组和表单提交代码强制执行。 如果对邮件执行操作的用户不在A4SWIFT用户组 (域或本地) ，则邮件修复和新提交将拒绝该邮件。

  例如，强制实施三阶段审批流程的组织可能会定义这三个逻辑角色：修复者、验证者 (重新密钥阶段) 和审批者。 相应地，参与角色的用户需要属于 A4SWIFT Users 域组。 若要进一步锁定 SharePoint 网站，应将用户组织到逻辑域组 (，例如修复者、验证程序、审批者) 。

  有关站点用户组的详细信息，请参阅Windows SharePoint Services安全性。

• 堆栈中的每个数字签名都必须是唯一的。 也就是说，每个数字签名都必须使用唯一的数字证书 (相对于同一堆栈) 中的其他签名。 这可确保邮件未获得创建/修复邮件的人员的批准，并且没有人员批准与多个审批者相同的邮件。

  邮件修复和新提交通过在消息创建、修复、审批和提交基础结构的每个入口点设置检查点来实施严格的安全策略。 这些检查点与消息修复和新提交的核心功能紧密结合，无法规避。 虽然消息修复和新提交旨在与 InfoPath 表单签名功能无缝集成，但它的设计也足够安全且可靠，以强制实施 SWIFT 消息的真实性和保护，即使未使用 InfoPath 并且最终用户直接将邮件提交到邮件修复和新提交接收终结点 (SharePoint Web 文件夹) 。