Những nhận định chính
- CSCF v2026 đã mở rộng phạm vi áp dụng, đưa các kết nối khách hàng (chẳng hạn như các điểm cuối API , phần mềm trung gian và các ứng dụng khách truyền tệp) vào phạm vi áp dụng của 14 biện pháp kiểm soát, tùy thuộc vào loại kiến trúc
- CSCF phiên bản 2027 tiếp tục mở rộng phạm vi áp dụng với 32 tiêu chí kiểm soát, trong đó có 26 tiêu chí bắt buộc, trước giai đoạn xác nhận từ tháng 7 đến tháng 12 năm 2027
- Các phân loại kiến trúc được thiết lập trước phiên bản v2026 có thể cần được đánh giá lại trong trường hợp có sự xuất hiện của các trình kết nối khách hàng hoặc các yếu tố khác làm thay đổi phạm vi; các chuyên gia đánh giá sẽ xem xét chu kỳ mở rộng phạm vi lần thứ hai
- Một nguyên tắc bảo mật thiết thực đối với phạm vi bảo vệ mở rộng là phải kiểm tra, làm sạch và kiểm soát các tệp tin cũng như luồng dữ liệu trước khi chúng tiếp cận cơ sở hạ tầng thanh toán quan trọng
- Các điểm kiểm tra dọc theo các luồng hoạt động này có thể cung cấp bằng chứng hữu ích cho việc ghi chép, giám sát và xác nhận, mặc dù việc tuân thủ vẫn là trách nhiệm của tổ chức
Chuẩn bị cho kỳ đánh giá CSCF năm 2027
Hầu hết các tổ chức kết nối với Swift đều có thể xác định vùng “ Secure ” của mình dựa trên cơ sở hạ tầng hiện có: giao diện trao đổi tin nhắn, các máy chủ trung gian, và phân đoạn được bảo mật chặt chẽ nơi lưu thông các giao dịch thanh toán. Đây là một trong những khu vực được bảo vệ tốt nhất trong tổ chức. CSCF v2027 đặt ra câu hỏi về mức độ bảo vệ của tất cả các thành phần dẫn vào khu vực này.
Sự thay đổi lớn nhất đã diễn ra. CSCF phiên bản 2026, được công bố vào tháng 7 năm 2025, đã quy định bắt buộc phải tuân thủ Tiêu chuẩn Kiểm soát 2.4 – “Bảo mật luồng dữ liệu hậu cần” – theo hình thức triển khai theo từng giai đoạn, đồng thời đưa các kết nối khách hàng vào phạm vi áp dụng của 14 tiêu chuẩn kiểm soát.
Việc trao đổi dữ liệu trực tiếp giữa các bộ phận hậu cần theo mô hình cũ hiện vẫn mang tính chất tham khảo; năm 2028 được đề xuất sơ bộ là thời điểm chuyển đổi bắt buộc trong tương lai. Khung quy định hiện tại bao gồm 32 biện pháp kiểm soát an ninh trải rộng trên bảy nguyên tắc, trong đó 26 biện pháp là bắt buộc, và phạm vi mở rộng sẽ được áp dụng trong chu kỳ 2027. CSCF v2027, được công bố vào tháng 7 năm 2026, không bổ sung thêm các biện pháp kiểm soát bắt buộc mới nhưng đưa Hệ thống Quản lý Mật khẩu và Khóa ( Vault - SKV) vào phạm vi áp dụng đối với hầu hết các biện pháp này. Các biện pháp kiểm soát tư vấn vẫn là thực tiễn được khuyến nghị và có thể trở thành bắt buộc trong các phiên bản sau. Các tổ chức sẽ tiến hành xác nhận tuân thủ phạm vi mở rộng lần đầu tiên từ tháng 7 đến tháng 12 năm 2026, và giai đoạn xác nhận v2027 sẽ diễn ra từ tháng 7 đến tháng 12 năm 2027, được hỗ trợ bởi đánh giá độc lập.
Nếu phân loại kiến trúc của quý vị vẫn dựa trên phiên bản trước v2026, hãy tiến hành đánh giá lại ngay lập tức, đặc biệt nếu kể từ lần đánh giá gần nhất đã có sự xuất hiện của các kết nối khách hàng, luồng tệp bên ngoài hoặc các lộ trình tích hợp mới. Các nhóm đang chuẩn bị cho bản xác nhận phạm vi mở rộng đầu tiên thông qua cách làm tạm bợ sẽ phải đối mặt với năm 2027 – khi các chuyên gia đánh giá kỳ vọng rằng công việc đằng sau bản xác nhận đó phải thể hiện sự có chủ đích. Dù thế nào đi nữa, câu hỏi đặt ra là liệu kiến trúc bảo mật của quý vị đã sẵn sàng cho những thách thức hiện đang nằm ngoài Khu vực “ Secure ” hay chưa.
Các kết nối khách hàng và phạm vi mở rộng
Một môi trường thanh toán hiếm khi bị tấn công qua “bức tường” vững chắc nhất của nó. Các tệp tin và dữ liệu xâm nhập vào các hệ thống liên quan đến Swift thông qua các cổng thông tin khách hàng, các tệp tin được đối tác tải lên, các nền tảng truyền tệp được quản lý, các hàng đợi phần mềm trung gian, các tích hợp theo mô hình “ API ” (Dịch vụ như một phần mềm) và các phương tiện lưu trữ di động được mang vào trung tâm dữ liệu. Mỗi kênh trong số đó đều có thể đưa nội dung độc hại hoặc không đáng tin cậy vào cơ sở hạ tầng – vốn được các đánh giá kiến trúc trước đây xếp vào nhóm “nằm ngoài phạm vi an toàn”.
Hiện nay, khung công nghệ này coi các đường dẫn này là một phần của kiến trúc bảo mật liên quan. Các trình kết nối khách hàng được đưa vào phạm vi kiểm soát theo tên cụ thể: các điểm cuối API , phần mềm trung gian và các trình khách truyền tệp, bất kể chúng chạy trên máy chủ hay các điểm cuối khách hàng. Việc kiểm tra được mở rộng đến chính phần mềm, từ các bản cập nhật bảo mật và quét lỗ hổng bảo mật cho đến tính toàn vẹn của phần mềm, khiến mã nguồn của các trình kết nối nội bộ phải trải qua quy trình kiểm tra tương tự như các tệp mà chúng truyền tải.
Nếu phân loại kiến trúc của bạn được thiết lập trước phiên bản v2026, các thành phần mà trước đây bạn coi là nằm ngoài phạm vi (chẳng hạn như dịch vụ tải lên dành cho khách hàng, kênh tích hợp hoặc máy chủ truyền tệp) có thể cần được đánh giá lại, đặc biệt là trong trường hợp chúng sử dụng hoặc chính là một trình kết nối khách hàng.
Infographic Swift của chúng tôi trình bày các điểm tiếp cận này trên một trang duy nhất.
Đối với lãnh đạo bộ phận an ninh, rủi ro có thể được thu gọn thành hai kịch bản. Một tệp tin độc hại xâm nhập vào hạ tầng thanh toán sẽ đe dọa tính sẵn sàng của chính hoạt động kinh doanh thanh toán, và một lỗ hổng về phạm vi được phát hiện trong quá trình đánh giá sẽ trở thành một phát hiện được ghi nhận chính thức và được Hội đồng quản trị nắm rõ. Cả hai kết quả này đều gây tốn kém hơn so với việc tiến hành đánh giá lại để ngăn chặn chúng.
Bảo mật tập tin cần được đưa vào buổi đánh giá kiến trúc của bạn
Hầu như mọi kênh nằm trong phạm vi mở rộng này đều tồn tại để truyền tải tệp tin hoặc dữ liệu có cấu trúc: các tệp tin được tải lên từ khách hàng và đối tác, việc truyền dữ liệu theo lô giữa các tổ chức, các tệp đính kèm đi qua phần mềm trung gian, và các tệp tin được truyền qua ranh giới giữa các hệ thống lưu trữ ( API ). Một công cụ chống vi-rút duy nhất được triển khai tại biên mạng ban đầu được thiết kế để giải quyết một vấn đề hẹp hơn so với phạm vi này.
Điều đó khiến việc “ Bảo mật tập tin ” trở thành một quyết định về kiến trúc. Một nguyên tắc thực tiễn là phải kiểm tra, làm sạch và kiểm soát các tệp tin cũng như luồng dữ liệu trước khi chúng tiếp cận cơ sở hạ tầng thanh toán quan trọng, đồng thời đảm bảo rằng các biện pháp kiểm soát được áp dụng phải phù hợp với từng luồng dữ liệu và mức độ rủi ro của nó.
Kiểm tra các tệp trước khi chúng được chuyển đến hệ thống thanh toán
Một đối tác tải lên một lô hóa đơn thông qua cổng thông tin khách hàng của bạn. Tệp này được chuyển đến một nền tảng truyền tệp được quản lý, một hàng đợi trung gian nhận tệp này, một dịch vụ tích hợp định dạng lại nội dung, và kết quả đầu ra được chuyển đến một ứng dụng có đường dẫn kết nối với các hệ thống được kết nối qua Swift. Có bốn bước trung gian ngăn cách một tệp bên ngoài với cơ sở hạ tầng thanh toán quan trọng, và tại nhiều tổ chức, mỗi bước trung gian đều tin tưởng vào bước trước đó.
Việc áp dụng nguyên tắc “kiểm tra, làm sạch và kiểm soát” có nghĩa là triển khai một biện pháp kiểm soát cụ thể tại mỗi điểm trung chuyển. MetaDefender™ Core và MetaDefender ICAP Server quét các tệp được tải lên thông qua các ứng dụng web dành cho khách hàng, thông qua tích hợp REST API hoặc ICAP . MetaDefender Managed File Transfer kiểm tra nội dung được truyền giữa các hệ thống nội bộ và các hệ thống liên quan đến Swift, hỗ trợ Tiêu chuẩn Kiểm soát 2.4: Bảo mật luồng dữ liệu nội bộ.
Cả hai đều chuyển các tệp qua Metascan™ Multiscanning, nơi có hơn 30 công cụ chống phần mềm độc hại quét song song. Tính năng quét đa công cụ này hỗ trợ Control 6.1, Bảo vệ chống phần mềm độc hại, phát hiện nội dung độc hại đã biết với độ chính xác cao hơn so với bất kỳ công cụ đơn lẻ nào. Công nghệ Deep CDR™ sau đó sẽ làm sạch và tái tạo từng tệp được hỗ trợ, loại bỏ nội dung hoạt động được nhúng trước khi tệp tiếp tục được truyền đi. Các tệp đáng ngờ sẽ được chuyển đến Adaptive Sandbox , nơi phân tích dựa trên mô phỏng giúp phát hiện các mối đe dọa khó phát hiện và các mối đe dọa zero-day, hỗ trợ khuyến nghị Control 6.5A, Phát hiện xâm nhập.
Cách xử lý tương tự cũng được áp dụng cho các kho lưu trữ nơi lưu giữ các bản sao lưu và dữ liệu trích xuất, với công nghệ Proactive DLP™ kiểm tra các tệp tin đang được lưu trữ để phát hiện nội dung nhạy cảm. Hệ thống này cũng bao gồm các phương tiện lưu trữ di động và thiết bị tạm thời, mà các giải pháp MetaDefender Kiosk và MetaDefender Drive sẽ quét và làm sạch tại điểm kiểm tra trước khi đưa vào hệ thống, đáp ứng yêu cầu của Tiêu chuẩn Kiểm soát 3.1 về An ninh Vật lý.
Đối với phần mềm kết nối nội bộ, MetaDefender Software Supply Chain sẽ quét các gói phần mềm và các thành phần phụ thuộc để phát hiện lỗ hổng bảo mật và các thành phần độc hại trước khi triển khai, hỗ trợ các biện pháp kiểm soát 2.2 (Cập nhật bảo mật); 2.7 (Quét lỗ hổng bảo mật); và 6.2 ( Software Tính toàn vẹn).
Kết quả là một lớp phòng ngừa được áp dụng nhất quán trên tất cả các kênh tệp đi qua nó, được đặt ở phía thượng nguồn so với các hệ thống mà nó được thiết kế để bảo vệ.
Các hồ sơ kiểm tra làm cơ sở cho đánh giá của bạn
Khi giai đoạn 2027 bắt đầu vào tháng 7, các chuyên gia đánh giá sẽ xem xét chu kỳ xác nhận thứ hai theo phạm vi mở rộng, và bằng chứng cho thấy các biện pháp kiểm soát đã được thiết lập và vận hành hiệu quả sẽ được coi trọng hơn so với những cam kết đã nêu.
Các điểm kiểm tra dọc theo luồng tệp và dữ liệu của bạn có thể tạo ra các bằng chứng hữu ích: các sự kiện kiểm tra, nhật ký kiểm toán được chuyển tiếp đến hệ thống SIEM của bạn, và các bản ghi thực thi chính sách ghi lại cách nội dung được kiểm tra trong quá trình chuyển đến các hệ thống thanh toán. Những bằng chứng này hỗ trợ Điều khoản Kiểm soát 6.4 (Ghi nhật ký và Giám sát) cũng như bản xác nhận CSCF.
Việc tuân thủ vẫn là trách nhiệm của chính tổ chức đó, và các chuyên gia đánh giá sẽ xem xét kiến trúc đó như một tổng thể. Kết quả của công việc này là một câu trả lời có cơ sở để bảo vệ trước câu hỏi cốt lõi của chuyên gia đánh giá: những yếu tố nào có thể tác động đến cơ sở hạ tầng thanh toán của quý vị, và những yếu tố đó sẽ diễn biến như thế nào trong quá trình đó?
Ba câu hỏi dành cho đội ngũ kiến trúc của bạn
Ba câu hỏi sau đây sẽ là bước khởi đầu hữu ích trước thềm kỳ chuyển nhượng năm 2027:
- Cuối cùng, những luồng tệp và dữ liệu bên ngoài nào có thể tiếp cận được cơ sở hạ tầng thanh toán của quý vị?
- Các tệp được kiểm tra như thế nào trước khi được đưa vào các quy trình làm việc liên quan đến Swift?
- Việc mở rộng phạm vi CSCF có làm thay đổi phân loại kiến trúc hoặc các biện pháp kiểm soát hiện tại của quý vị không?
Bảng thông số kỹ thuật SWIFT CSCF v2027 của chúng tôi đã tổng hợp phạm vi mở rộng, cơ sở hạ tầng bị ảnh hưởng và các biện pháp kiểm soát phòng ngừa liên quan vào vài trang tài liệu mà quý vị có thể chia sẻ với các nhóm kiến trúc và GRC.
Tải xuống bảng thông số kỹ thuật SWIFT CSCF phiên bản 2027
Nếu bạn muốn tự mình khám phá môi trường của mình, hãy trò chuyện với một chuyên gia tại OPSWAT và mang theo bản phân loại kiến trúc hiện tại của bạn.
