SWIFT CSCF v2027：Secure ゾーン以外ではどのような変更点があるのか？

著者： OPSWAT

11月10 2026

この記事を共有する

主な知見

CSCF v2026ではすでに境界が変更され、アーキテクチャの種類に応じて、顧客側のクライアントコネクタ（API エンドポイント、ミドルウェア、ファイル転送クライアントなど）が14のコントロールの適用範囲に含まれるようになりました。
CSCF v2027では、2027年7月から12月までの認証期間に先立ち、32のコントロール（うち26が必須）を盛り込み、適用範囲の拡大を推進しています。
v2026より前のアーキテクチャ分類については、顧客クライアントコネクタやその他の適用範囲を変更する要因が存在する場合、再評価が必要となる可能性があります。評価者は、適用範囲が拡大された2回目のサイクルについて審査を行います。
拡張された境界における実用的なセキュリティ原則として、ファイルやデータの流れが重要な決済インフラに到達する前に、それらを検査、クリーンアップ、および制御することが挙げられる。
これらのフローにおける検査ポイントは、記録、監視、および証明のための有用な証拠となり得ますが、コンプライアンスの確保は依然として当該機関の責任となります。

2027年CSCF評価に向けた準備

Swiftに接続している機関の多くは、Secure ゾーンをメモリから読み出すことができます。つまり、メッセージングインターフェース、ジャンプサーバー、決済トラフィックが流れる堅牢なセグメントなどです。これらは組織内で最も防御が万全な領域の一部です。CSCF v2027は、そのゾーンへとつながるすべての経路が、どれほどしっかりと防御されているかを問うものです。

最大の変更はすでに実施されています。2025年7月に公表されたCSCF v2026では、「コントロール2.4：バックオフィス・データフローのセキュリティ」が段階的な導入により必須化され、顧客クライアント・コネクタが14のコントロールの適用範囲に組み込まれました。

従来のバックオフィス向け直接データ交換については、当面は推奨事項にとどめられ、2028年に義務化される見通しとなっている。現在のフレームワークでは、7つの原則にわたる32のセキュリティ管理措置が定められており、そのうち26が必須となっています。この拡大された適用範囲は2027年のサイクルにも引き継がれます。2026年7月に公表されたCSCF v2027では、新たな必須管理措置は追加されていませんが、その大半において「シークレットおよびキーのVault （SKV）」が適用範囲に組み込まれています。助言的コントロールは引き続き推奨される実践であり、将来のバージョンで必須となる可能性があります。各機関は2026年7月から12月の間に、拡大された適用範囲に対して初めて適合性証明を行い、v2027の適合性証明期間は2027年7月から12月までとなり、独立した評価によって裏付けられます。

アーキテクチャの分類がまだv2026以前のものの場合は、今すぐ再評価を行ってください。特に、前回の評価以降に、顧客クライアントコネクタ、外部ファイルフロー、または新しい統合パスが導入されている場合はなおさらです。最初の「範囲拡大型アテステーション」をその場しのぎの手法でまとめようとしているチームは、2027年になると、評価者からその背後にある取り組みが計画的なものであることが求められることになるでしょう。いずれにせよ、重要なのは、自社のセキュリティアーキテクチャが、Secure ゾーンの先にある課題に対応できる準備ができているかどうかという点です。

顧客クライアントコネクタと適用範囲の拡大

決済環境が、その最も強固な防御壁を突破されて攻撃を受けることはめったにありません。ファイルやデータは、顧客ポータル、パートナーによるアップロード、管理型ファイル転送プラットフォーム、ミドルウェアのキュー、API との連携、およびデータセンターに持ち込まれるリムーバブルメディアなどを通じて、Swift関連システムに到達します。これらの各経路を通じて、悪意のある、あるいは信頼できないコンテンツが、従来のアーキテクチャ評価では「安全であり、対象範囲外」と分類されていたインフラストラクチャへと流入する可能性があります。

このフレームワークでは、これらのパスを関連するセキュリティアーキテクチャの一部として扱うようになりました。顧客のクライアントコネクタは、API エンドポイント、ミドルウェア、ファイル転送クライアントなど、サーバー上で実行されるかクライアントエンドポイント上で実行されるかを問わず、名称に基づいて対象範囲に含まれます。この精査はソフトウェア自体にも及び、セキュリティ更新プログラムや脆弱性スキャンからソフトウェアの完全性に至るまで、社内コネクタのコードも、それらが扱うファイルと同様に厳格に検査されます。

アーキテクチャの分類がv2026より前のものの場合、かつて適用範囲外として扱っていたコンポーネント（顧客向けのアップロードサービス、統合バス、ファイル転送サーバーなど）については、特にそれらが顧客クライアントコネクタを使用している、あるいはそれ自体を構成している場合には、再評価が必要になる可能性があります。

当社のSwiftインフォグラフィックでは、これらのエントリポイントを1ページにまとめています。

セキュリティの責任者にとって、そのリスクは2つのシナリオに集約されます。決済インフラに到達した悪意のあるファイルは、決済事業そのものの可用性を脅かすものであり、また、評価の過程で発見された評価範囲の不備は、取締役会にも報告される正式な指摘事項となります。いずれの結果も、それを未然に防ぐための再評価にかかるコストよりも大きな損失をもたらします。

ファイルのセキュリティは、アーキテクチャレビューの対象となるべきです

拡大された対象範囲に含まれるほぼすべてのチャネルは、ファイルや構造化データを転送するために存在しています。顧客やパートナーからのアップロード、機関間のバッチ転送、ミドルウェアを経由する添付ファイル、API の境界を越えて転送されるファイルなどがそれにあたります。ネットワークエッジに設置された単一のウイルス対策エンジンは、これよりも狭い範囲の問題に対処するために構築されたものです。

つまり、ファイルのセキュリティはアーキテクチャ上の決定事項となります。実用的な原則としては、ファイルやデータの流れが重要な決済インフラに到達する前に、それらを検査・浄化・管理するとともに、適用される管理措置が各データフローとそのリスクに適切であることを確保することが挙げられます。

支払システムに到達する前にファイルを検査する

パートナーが、顧客ポータルを通じて請求書のバッチをアップロードします。そのファイルは管理型ファイル転送プラットフォームに送信され、ミドルウェアのキューによって取り込まれ、統合サービスによって内容が再フォーマットされた後、Swift接続システムへのルートを持つアプリケーションに送信されます。外部ファイルから重要な決済インフラまでは4つのホップを介しており、多くの金融機関では、各ホップが直前のホップを信頼する仕組みになっています。

「検査、サニタイズ、制御」の原則を適用するには、各ホップに特定の制御措置を講じる必要があります。MetaDefender™Core およびMetaDefender ICAP Server は、顧客向けWebアプリケーション、RESTAPI 、またはICAP との連携を通じてアップロードされたファイルをスキャンします。MetaDefender Managed File Transfer は、バックオフィスとSwift関連システムの間を移動するコンテンツを検査し、Control 2.4「バックオフィスのデータフローのセキュリティ」に対応しています。

両方のルートファイルは、Metascan™（Multiscanning ）を経由し、30以上のマルウェア対策エンジンが並行してスキャンを行います。このマルチエンジンスキャンは、Control 6.1の「マルウェア保護」機能をサポートしており、単一のエンジンよりも高い精度で既知の悪意のあるコンテンツを検出します。その後、Deep CDR™テクノロジーが、サポート対象の各ファイルを浄化・再生成し、ファイルがさらに転送される前に埋め込まれたアクティブコンテンツを削除します。不審なファイルは「Adaptive 」（Sandbox ）に送られ、そこでエミュレーションベースの分析により、回避型脅威やゼロデイ脅威の検知が行われ、「Control 6.5A（侵入検知）」の要件を満たします。

この処理は、バックアップや抽出データが保存されるストレージリポジトリにも適用され、Proactive DLP™ によって保存中のファイルに含まれる機密情報がチェックされます。また、リムーバブルメディアや一時的なデバイスも対象となっており、MetaDefender Kiosk およびMetaDefender Drive が、データが取り込まれる前のチェックポイントでスキャンとデータ消去を行い、Control 3.1「物理的セキュリティ」に対応しています。

社内用コネクタソフトウェアであるMetaDefender （Software 、Supply Chain ）は、デプロイ前にパッケージや依存関係をスキャンして脆弱性や悪意のあるコンポーネントを検出し、コントロール 2.2「セキュリティ更新プログラム」、2.7「脆弱性スキャン」、および 6.2「Software の整合性」に対応しています。

その結果、このシステムを通じてルーティングされるすべてのファイルチャネルに一貫して適用される1つの予防層が形成され、それが保護対象となるシステムの上流に配置されることになる。

評価を裏付ける検査記録

7月に2027年度の審査期間が開始されると、審査担当者は拡大された範囲に基づく第2回の証明サイクルを審査することになり、管理措置が整備され、かつ効果的に機能しているという証拠は、表明された意図よりも重視されることになる。

ファイルやデータフロー全体にわたる検査ポイントからは、有用な証拠が得られる可能性があります。具体的には、検査イベント、SIEMに転送される監査証跡、および決済システムへの送信過程でコンテンツがどのように検査されたかを記録したポリシー適用記録などが挙げられます。こうした証拠は、コントロール6.4「ログ記録と監視」およびCSCFの適合性証明そのものを裏付けるものとなります。

コンプライアンスの責任は依然として当該機関自身にあり、評価者はアーキテクチャ全体を評価します。この作業を通じて得られるのは、評価者が投げかける核心的な問い――「支払いインフラに何がアクセス可能か、そしてその過程で何が起こるのか」――に対する、説得力のある回答です。