Főbb megállapítások
- A CSCF v2026 már kiterjesztette a hatályát, így az ügyféloldali csatlakozók (például az API végpontok, a közbenső szoftverek és a fájlátviteli kliensek) az architektúra típusától függően 14 ellenőrzési pont hatálya alá kerültek
- A CSCF v2027 továbbviszi a kibővített hatályt 32 ellenőrzési ponttal, amelyek közül 26 kötelező, a 2027. júliustól decemberig tartó tanúsítási időszakot megelőzően
- A v2026-os verziót megelőző architektúra-besorolásokat esetleg újra kell értékelni, ha ügyféloldali csatlakozók vagy más, a hatókört megváltoztató tényezők merülnek fel; az értékelők felülvizsgálják a második, kibővített hatókörű ciklust
- A kibővített védelmi körre vonatkozó egyik gyakorlati biztonsági elv az, hogy a fájlokat és az adatáramlásokat ellenőrizzék, tisztítsák meg és szabályozzák, mielőtt azok eljutnának a kritikus fizetési infrastruktúrához.
- Ezen folyamatok mentén elhelyezett ellenőrzési pontok hasznos adatokat szolgáltathatnak a nyilvántartáshoz, a nyomon követéshez és a tanúsításhoz, bár a szabályok betartása továbbra is az intézmény felelőssége marad
Felkészülés a 2027-es CSCF-értékelésre
A legtöbb Swift-hálózathoz csatlakozó intézmény a memóriából tudja felépíteni a „Secure Zone”-ját: az üzenetküldő felületet, az átjárószervereket, valamint azt a megerősített szegmenst, ahol a fizetési forgalom zajlik. Ez a szervezeten belül az egyik legjobban védett terület. A CSCF v2027 azt vizsgálja, hogy mennyire jól védett mindaz, ami ide vezet.
A legnagyobb változás már megtörtént. A 2025 júliusában közzétett CSCF v2026 szabvány a „Control 2.4: Back-Office Data Flow Security” (2.4. ellenőrzési pont: A háttérrendszerek adatáramlásának biztonsága) előírását fokozatos bevezetés keretében kötelezővé tette, és 14 ellenőrzési pont hatálya alá vonta az ügyfél-kliens csatlakozókat.
A hagyományos, közvetlen háttérrendszer-adatcserék egyelőre csak ajánlott jellegűek, a kötelező áttérésre előreláthatólag 2028-ban kerül sor. A jelenlegi keretrendszer hét alapelv mentén 32 biztonsági ellenőrzést tartalmaz, amelyek közül 26 kötelező, és a kibővített hatály a 2027-es ciklusra is kiterjed. A 2026 júliusában közzétett CSCF v2027 nem vezet be új kötelező ellenőrzéseket, de a legtöbbjük hatálya alá vonja a titkok és kulcsok változáskezelési rendszerét ( Vault , SKV). A tanácsadó jellegű ellenőrzések továbbra is ajánlott gyakorlatnak minősülnek, amelyek későbbi verziókban kötelezővé válhatnak. Az intézmények 2026 júliusa és decembere között először nyújtanak be igazolást a kibővített hatályra vonatkozóan, a v2027-es igazolási időszak pedig 2027 júliusától decemberéig tart, független értékeléssel alátámasztva.
Ha az architektúrájának besorolása még a v2026-os verziót megelőző időszakból származik, akkor most értékelje újra, különösen akkor, ha az utolsó értékelés óta ügyfél-csatlakozók, külső fájláramlások vagy új integrációs útvonalak kerültek bevezetésre. Azok a csapatok, amelyek első, kiterjesztett hatályú tanúsítása rögtönzéssel jön létre, azzal a helyzettel szembesülnek 2027-ben, hogy az értékelők elvárják, hogy a háttérmunkának átgondoltnak tűnjön. Akárhogy is legyen, a kérdés az, hogy a biztonsági architektúrája készen áll-e arra, ami most már a Biztonsági Zónán túl helyezkedik el.
Ügyfél-kliens csatlakozók és a kibővített hatály
A fizetési környezetet ritkán a legerősebb védelmi vonalán keresztül támadják meg. A fájlok és adatok az ügyfélportálokon, a partnerek által feltöltött adatokon, a felügyelt fájlátviteli platformokon, a middleware-sorokban, a „ API ” integrációkon, valamint az adatközpontba bevitt cserélhető adathordozókon keresztül jutnak el a Swift-hez kapcsolódó rendszerekbe. Ezen csatornák mindegyike révén rosszindulatú vagy megbízhatatlan tartalom juthat el olyan infrastruktúrába, amelyet a régebbi architektúra-felülvizsgálatok biztonságosnak minősítettek, mivel nem tartoznak a vizsgálat hatálya alá.
A keretrendszer mostantól ezeket az útvonalakat a vonatkozó biztonsági architektúra részeként kezeli. Az ügyfelek klienscsatlakozói név szerint tartoznak a hatály alá: a API végpontok, a közbenső szoftverek és a fájlátviteli kliensek, függetlenül attól, hogy szervereken vagy kliens végpontokon futnak-e. Az ellenőrzés kiterjed magára a szoftverre is, a biztonsági frissítésektől és a sebezhetőségi vizsgálatoktól a szoftver integritásáig, így a házon belüli csatlakozók kódját ugyanolyan alapos vizsgálatnak vetik alá, mint az általuk továbbított fájlokat.
Ha az architektúra-besorolása a v2026-os verziót megelőzően készült, akkor azokat a komponenseket, amelyeket korábban a hatályon kívül esőnek tekintett (például egy ügyfelek számára elérhető feltöltési szolgáltatás, egy integrációs busz vagy egy fájlátviteli szerver), esetleg újra kell értékelnie, különösen akkor, ha azok ügyfél-kliens csatlakozót használnak vagy maguk is ilyen csatlakozót alkotnak.
A Swift infografikánk ezeket a belépési pontokat egyetlen oldalon ábrázolja.
A biztonsági vezetés szempontjából a kockázatok két forgatókönyvre vezethetők vissza. Ha egy rosszindulatú fájl bejut a fizetési infrastruktúrába, az maga a fizetési üzletág rendelkezésre állását veszélyezteti; ha pedig az értékelés során hiányosságot tárnak fel a vizsgálati körben, az dokumentált megállapításként az igazgatóság tudomására jut. Bármelyik kimenetel is drágább, mint az azt megelőző újraértékelés.
A fájlbiztonságnak helye van az architektúra-felülvizsgálatban
A kibővített hatály alá tartozó csatornák szinte mindegyike fájlok vagy strukturált adatok továbbítására szolgál: ügyfelektől és partnerektől érkező feltöltések, intézmények közötti kötegelt adatátvitelek, a közbenső szoftverekön keresztül továbbított mellékletek, valamint a „ API ” határain átvitt fájlok. A hálózat peremén elhelyezett egyetlen víruskereső motor eredetileg ennél szűkebb körű feladatra készült.
Ezáltal a fájlbiztonság architektúrai döntéssé válik. Egy gyakorlati alapelv az, hogy a fájlokat és az adatáramlásokat még mielőtt azok eljutnának a kritikus fizetési infrastruktúrához, ellenőrizzék, tisztítsák meg és szabályozzák, miközben biztosítani kell, hogy az alkalmazott ellenőrzési intézkedések az egyes adatáramlásokhoz és azok kockázatához igazodjanak.
A fájlok ellenőrzése, mielőtt azok eljutnának a fizetési rendszerekbe
Egy partner egy számla-csomagot tölt fel az ügyfélportálon keresztül. A fájl egy felügyelt fájlátviteli platformra kerül, ahol egy köztes szoftveres sorbaállítás veszi át, majd egy integrációs szolgáltatás átformázza a tartalmát, és a kimenet eljut egy olyan alkalmazáshoz, amely összeköttetésben áll a Swift-hálózathoz kapcsolódó rendszerekkel. Négy lépés választja el a külső fájlt a kritikus fizetési infrastruktúrától, és számos intézményben minden egyes lépés megbízik az előzőben.
Az „ellenőrzés, tisztítás és szabályozás” elv alkalmazása azt jelenti, hogy minden egyes átviteli ponton egy konkrét ellenőrzési mechanizmust kell beépíteni. A MetaDefender™ Core és MetaDefender ICAP Server szkenneli az ügyfelek számára elérhető webalkalmazásokon keresztül, valamint a REST API vagy ICAP integráción keresztül feltöltött fájlokat. A MetaDefender Managed File Transfer ellenőrzi a háttérrendszerek és a Swift-hez kapcsolódó rendszerek között áramló tartalmakat, támogatva a 2.4. számú szabályt („Háttérrendszerek adatáramlásának biztonsága”).
Mindkét útvonalon a fájlok a Metascan™-on keresztül haladnak Multiscanning, ahol több mint 30 kártevőellenes motor végez párhuzamos vizsgálatot. Ez a többmotoros vizsgálat támogatja a Control 6.1 „Kártevővédelem” funkcióját, amely az ismert káros tartalmakat nagyobb pontossággal észleli, mint bármelyik motor egyedül. A Deep CDR™ technológia ezután megtisztítja és újragenerálja az egyes támogatott fájlokat, eltávolítva a beágyazott aktív tartalmakat, mielőtt a fájl továbbhaladna. A gyanús fájlok a Adaptive Sandbox, ahol az emulációalapú elemzés segít felismerni a kijátszó és zero-day fenyegetéseket, támogatva a Control 6.5A, Behatolás-érzékelés tanácsot.
Ugyanez a kezelés kiterjed azokra a tárolóhelyekre is, ahová a biztonsági másolatok és kivonatok kerülnek: a Proactive DLP™ ellenőrzi a tárolt fájlokat érzékeny tartalom szempontjából. Kiterjed továbbá a cserélhető adathordozókra és az átmeneti eszközökre is, amelyeket a MetaDefender Kiosk és a MetaDefender Drive ellenőrzési ponton beolvasnak és megtisztítanak a belépés előtt, támogatva ezzel a Control 3.1 (Fizikai biztonság) követelményt.
A vállalaton belüli csatlakozószoftverek esetében az MetaDefender ,Software ésSupply Chain a telepítés előtt átvizsgálja a csomagokat és a függőségeket a sebezhetőségek és a rosszindulatú összetevők felderítése érdekében, támogatva a 2.2. (Biztonsági frissítések), a 2.7. (Sebezhetőségi vizsgálat) és a 6.2. ( Software integritás) ellenőrzési pontokat.
Az eredmény egy olyan védelmi réteg, amelyet következetesen alkalmaznak az általa továbbított fájlcsatornákon, és amely a védelmezni kívánt rendszerek előtt helyezkedik el.
Az értékelésedet alátámasztó ellenőrzési jegyzőkönyvek
Amikor júliusban megnyílik a 2027-es értékelési időszak, az értékelők a kibővített hatály keretében felülvizsgálják a második tanúsítási ciklust, és az ellenőrző mechanizmusok meglétére és hatékony működésére vonatkozó bizonyítékok nagyobb súllyal fognak esni, mint a kinyilvánított szándékok.
A fájl- és adatáramlások mentén elhelyezett ellenőrzési pontok hasznos bizonyítékokat szolgáltathatnak: ellenőrzési események, a SIEM-rendszerbe továbbított ellenőrzési nyomvonalak, valamint a szabályok betartását dokumentáló feljegyzések, amelyek rögzítik, hogyan vizsgálják meg a tartalmat a fizetési rendszerek felé vezető úton. Ezek a bizonyítékok alátámasztják a 6.4. számú ellenőrzési pontot („Naplózás és felügyelet”), valamint magát a CSCF-tanúsítást is.
A szabályoknak való megfelelés továbbra is az intézmény saját felelőssége, és az értékelők az architektúrát egészében vizsgálják. Ennek a munkának az eredménye egy megalapozott válasz az értékelő központi kérdésére: mi érheti el a fizetési infrastruktúrát, és mi történik vele az út során?
Három kérdés az építészeti csapatodnak
A 2027-es időszakot megelőzően három kérdés segíthet a helyzet áttekintésében:
- Mely külső fájlok és adatáramok juthatnak el végső soron a fizetési infrastruktúrájához?
- Hogyan vizsgálják meg a fájlokat, mielőtt bekerülnének a Swift-hez kapcsolódó munkafolyamatokba?
- A CSCF hatályának kiterjesztése megváltoztatja-e a jelenlegi architektúra-besorolását vagy az ellenőrzési intézkedéseit?
A SWIFT CSCF v2027 adatlapunk néhány oldalra sűríti a kibővített hatályt, az érintett infrastruktúrát és a vonatkozó megelőző intézkedéseket, amelyet megoszthat az architektúra- és GRC-csapatokkal.
Töltse le a SWIFT CSCF v2027 adatlapját
Ha inkább saját környezetedben szeretnél körbejárni, beszélgess el egy OPSWAT szakértővel, és hozd magaddal a jelenlegi architektúra-osztályozásodat.
