本主题介绍 BizTalk Server EDI 和 AS2 解决方案安全性的已知问题。
BizTalk 不会暂停来自未设置证书的参与方的已签名消息
如果未在参与方（在参与方“属性”页的“证书”节点）上设置签名证书，但来自该方的传入消息已签名，BizTalk Server 将不会挂起该消息，并且会根据缺少证书引发异常。
如果覆盖入站消息属性（在 Party as AS2 消息发送方页中），并清除“消息应签名”属性，BizTalk Server 将暂停已签名的传入消息。
可以限制对程序文件文件夹的访问，以防止文件篡改
如果包含 BizTalk Server 可执行文件和 EDI 架构的程序文件文件夹可供未进行身份验证的用户使用，则这些用户可以修改这些文件。 若要防止该威胁，可以使用 Program Files 文件夹中的访问控制列表（ACL）来限制对受信任用户的访问权限。
具有长字段的架构可能容易受到拒绝服务攻击
具有极长字段的自定义架构可能会被拒绝服务攻击利用。 BizTalk Server 附带的架构没有长度很大的字段，因此通常不会受到此类攻击。
如果控制编号超过其最大长度，将中止消息处理
交换、组或事务集控制编号的最大长度有限。 如果其中一个控制编号的长度超过最大长度，将中止处理单个参与方该编码类型的所有消息。 另一种编码类型（例如 EDIFACT 而不是 X12）的消息不会受到影响。 这可能表示安全漏洞。
如果序列号的长度超过最大长度，则用户必须重置受影响方的 EDI 属性中的序列号。 重置数字后，可以再次处理该编码类型的所有消息。
对于 X12 消息，控制编号的最大长度为 9 位。 对于 EDIFACT 消息，控制编号的最大长度为三个字段的 14 位数字。
将 EDI 接收管道与 HTTP 适配器配合使用将使连接保持打开状态（如果未发送 ACK）
如果创建使用 EDIReceive 管道且具有传输类型的 HTTP 的接收位置，则可能会出现安全问题。 EdiReceive 管道不会生成 HTTP“200 成功”确认。 如果未返回 EDI 确认，则连接不会正常终止，但会保持打开状态。 当超时期限已过期时，连接将断开。
这不是 AS2EdiREceive 管道的问题。
如果启用 Port-Based 身份验证并且 BizTalk Server 无权访问授权和安全信息，则会暂停 X12-Encoded 消息
症状
当通过启用身份验证的接收端口接收到消息但无法确定发送方时，BizTalk Server 将挂起该消息。
可能的原因
如果为接收端口启用了身份验证（清除接收端口的“无身份验证”属性），BizTalk Server 需要设置“ISA1-2（授权限定符和信息）”和“ISA3-4（安全限定符和信息）”属性才能处理交换。 这些属性在 X12 交换处理属性页中为作为交换发送方的参与方设置。 如果 BizTalk Server 无法确定这些属性的值，它将暂停处理该消息。
这可以通过两种方式发生。 在第一种情况下，如果 BizTalk Server 无法确定发送消息的参与方，它将使用 EDI 全局属性，并且无法访问授权和安全设置。 因此，它将暂停消息。 第二种情况是，如果 BizTalk Server 确定参与方，但未配置参与方的 ISA1-2 和 ISA3-4 属性，则 BizTalk Server 将再次无权访问授权和安全信息，并将挂起消息。
解决方案
确保可以标识消息的发送方，并在参与方协议中定义 ISA1-2 和 ISA3-4 属性。