Share via


伺服器執行階段安全性

A4SWIFT訊息修復和新提交會以安全且具決定性的方式控管商務使用者、後端系統和 SWIFT 網路端點之間的 SWIFT 訊息流程。 它會驗證商務使用者提交的訊息、驗證資料與商務規則正確性的訊息,以及將訊息路由傳送至後端系統,或最終傳遞至 SWIFT 網路。 如需數位憑證的詳細資訊,請參閱 MSDN Library 網站上的 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 資料夾) 。