關鍵洞見
- CSCF v2026 已將邊界範圍擴大，將客戶端連接器（例如API 端點、中介軟體及檔案傳輸客戶端）納入 14 項控制措施的適用範圍，具體取決於架構類型
- CSCF v2027 將擴展後的適用範圍落實於 32 項控制措施中，其中 26 項為強制性要求，以配合 2027 年 7 月至 12 月的認證時段
- 若存在客戶端連接器或其他影響範圍的變因，則 v2026 版本之前制定的架構分類可能需要重新評估；評估人員將審查第二個範圍擴展週期
- 針對擴展邊界的一項實用安全原則，是在檔案與資料流抵達關鍵支付基礎設施之前，先對其進行檢查、淨化與控制。
- 這些流程中的各檢查點雖能為記錄、監控及核證提供有用的證據，但確保合規性仍屬該機構的責任
為 2027 年 CSCF 評估做準備
大多數連接 Swift 的機構都能從記憶中勾勒出其「Secure 」區域：訊息傳遞介面、跳轉伺服器，以及承載支付流量的強化區段。這可說是該組織中防禦最嚴密的區域之一。CSCF v2027 則探討通往該區域的所有路徑，其防禦程度究竟如何。
最大的變革已經發生。2025年7月發布的《CSCF v2026》規定，必須分階段實施「控制措施 2.4：後台資料流安全」，並將客戶端連接器納入14項控制措施的適用範圍。
現有的後台直接資料交換機制目前仍屬建議性質，暫定於 2028 年起強制實施。 現行框架涵蓋七項原則共 32 項安全控制措施，其中 26 項為強制性，而擴展後的適用範圍將延續至 2027 年週期。2026 年 7 月發布的 CSCF v2027 並未新增強制性控制措施，但將「機密與金鑰Vault （SKV）」納入其中大部分控制措施的適用範圍。 建議性控制措施仍屬推薦做法，但可能在後續版本中轉為強制性。各機構將於 2026 年 7 月至 12 月期間，首次針對擴展後的範圍進行合規聲明；而 v2027 版本的合規聲明期則為 2027 年 7 月至 12 月，並須經由獨立評估支持。
若貴組織的架構分類仍停留在 v2026 之前的版本，請立即重新評估，特別是若自上次評估以來，已導入客戶端連接器、外部檔案流或新的整合路徑。那些透過臨時應變來籌備首次「擴展範圍」認證的團隊，將面臨 2027 年——屆時評估人員預期相關工作應展現出周詳的規劃。無論如何，關鍵在於貴組織的安全架構是否已準備好應對「Secure 」區域之外的現有挑戰。
客戶端連接器與擴展範圍
支付環境極少會透過其最堅固的防線遭到攻擊。檔案和資料是透過客戶入口網站、合作夥伴上傳、受管檔案傳輸平台、中介軟體佇列、API 整合，以及帶入資料中心的可移除儲存媒體，進入 Swift 相關系統的。這些管道中的每一個，都可能將惡意或不可信的內容傳輸至基礎架構中——而根據過往的架構審查，這些區域原本被歸類為安全且不在審查範圍內。
該框架現將這些路徑視為相關安全架構的一部分。客戶端連接器依名稱納入審查範圍：API 端點、中介軟體及檔案傳輸客戶端，無論其運行於伺服器或客戶端端點。審查範圍更延伸至軟體本身，涵蓋安全更新、漏洞掃描乃至軟體完整性，使內部連接器的程式碼與其所傳輸的檔案受到同等程度的審查。
若您的架構分類早於 v2026 版本，您過去曾視為不在範圍內的元件（例如面向客戶的上傳服務、整合匯流排或檔案傳輸伺服器），可能需要重新評估，特別是當這些元件使用或構成客戶端連接器時。
對資安領導層而言，風險可歸納為兩種情境：惡意檔案若滲透至支付基礎架構，將威脅支付業務本身的可用性；而在評估過程中發現的範圍缺口，則會成為有據可查的發現事項，並呈報至董事會。無論哪種結果，其代價都遠高於能預防這些情況的重新評估。
檔案安全性應納入您的架構審查中
擴展範圍所涵蓋的幾乎所有通道，其存在目的皆在於傳輸檔案或結構化資料：來自客戶與合作夥伴的上傳、機構間的批次傳輸、穿越中介軟體的附件，以及跨越API 邊界的檔案。位於網路邊緣的單一防毒引擎，其設計初衷是為解決比這更狹窄的問題。
這使得檔案安全成為一項架構決策。一項實用的原則是：在檔案與資料流抵達關鍵支付基礎設施之前，先對其進行檢查、淨化與控制，同時確保所採取的控制措施與各資料流及其風險相符。
在檔案送入支付系統之前進行檢查
某合作夥伴透過您的客戶入口網站上傳一批發票。該檔案會傳送至受管文件傳輸平台，由中介軟體佇列擷取，再由整合服務重新格式化內容，最終輸出至一個可連通 Swift 系統的應用程式。外部檔案與關鍵支付基礎設施之間相隔四個節點，而在許多機構中，每個節點都信任前一個節點。
應用「檢查、淨化與控制」原則，意味著在每個節點設置特定的控制措施。MetaDefender™Core 以及MetaDefender ICAP Server 會掃描透過面向客戶的網路應用程式、RESTAPI 或ICAP 整合方式上傳的檔案。MetaDefender Managed File Transfer 則會檢查在後台系統與 Swift 相關系統之間傳輸的內容，並支援控制措施 2.4「後台資料流安全性」。
兩者皆透過 Metascan™Multiscanning 處理檔案，由 30 多個反惡意軟體引擎並行掃描。此多引擎掃描機制支援 Control 6.1 及「惡意軟體防護」功能，偵測已知惡意內容的準確度高於任何單一引擎。隨後，Deep CDR™ 技術會對每個受支援的檔案進行淨化與重新生成，在檔案繼續傳輸前移除其中嵌入的動態內容。 可疑檔案將被傳送至Adaptive Sandbox ，透過基於模擬的分析技術，協助偵測隱蔽型及零日威脅，並支援 Control 6.5A「入侵偵測」建議規範。
此項處理機制同樣適用於存放備份與擷取資料的儲存庫，透過 Proactive DLP™ 技術檢查靜態檔案中的敏感內容。該機制亦涵蓋可移除媒體與臨時裝置，MetaDefender （Kiosk ）與MetaDefender （Drive ）會在資料進入前於檢查點進行掃描與淨化處理，以符合《控制規範》3.1 條「實體安全」的要求。
針對內部連接器軟體，MetaDefender Software Supply Chain 會在部署前掃描套件及其依賴項，以檢測漏洞與惡意元件，並支援控制措施 2.2「安全性更新」、2.7「漏洞掃描」以及 6.2「Software 完整性」。
其結果是在所有經由該系統傳輸的檔案通道上，一致地套用一層防護機制，且該機制位於其所保護的系統上游。
支持您評估結果的檢查紀錄
當 2027 年的審查期於 7 月展開時，評估人員將依據擴大的審查範圍，對第二個聲明週期進行審查；屆時，證明相關控制措施確實存在且運作有效的證據，將比單純聲明意圖更具份量。
在您的檔案和資料流中設置的檢查點，可產生有用的證據：包括檢查事件、轉發至 SIEM 的稽核追蹤紀錄，以及記錄內容在傳輸至支付系統過程中如何被檢查的政策執行紀錄。這些證據可作為「控制措施 6.4：記錄與監控」以及 CSCF 核證本身的依據。
合規性仍屬該機構自身的責任，而評估人員則會對整體架構進行評估。這項工作所產出的成果，正是針對評估人員的核心問題所給出的、經得起推敲的答案：哪些因素可能影響貴機構的支付基礎架構，以及這些因素在影響過程中會對其造成何種影響？
給您的架構團隊的三個問題
在2027年窗口期來臨之前，以下三個問題可作為有用的初步探討：
- 哪些外部檔案和資料流最終能夠傳輸至您的支付基礎架構？
- 檔案在進入 Swift 相關工作流程之前，是如何經過檢查的？
- CSCF 範圍的擴展是否會改變您目前的架構分類或控制措施？
我們的 SWIFT CSCF v2027 資料表將擴展範圍、受影響的基礎架構以及相關的預防性控制措施濃縮於數頁之中，方便您與架構及 GRC 團隊分享。
如果您更希望親自走訪您的環境，不妨與OPSWAT 的專家進行諮詢，並攜帶您目前的架構分類資料一同前往。
