A felhőnatív bankolás indexe 2026-ban: DORA, platformmérnökség, szuverén felhő és működési ellenállóképesség

TL;DR. Egy 2026-os felhőnatív bankolási index a DORA-felkészültség, a platformmérnökségi érettség, a felhőkoncentrációs kockázat, a kiléptetési bizonyíték és a működési ellenállóképesség méréséhez.

Points clés

A felhőnatív bankolás indexe 2026-ban: DORA, platformmérnökség, szuverén felhő és működési ellenállóképesség. A felhőnatív bankolás 2026-ban a DORA auditfázisában van.
Miért van auditfázisban a DORA felhős ellenállóképessége. Három ok, amiért a "felkészülés" keretezése rossz 2026-ban.
Aktuális jelzések, amelyeket követni kell. A felhőnatív érettség 2026-ban öt mérnöki alapelemre egyszerűsödik, amelyek összekapcsolódva a telepítési folyamat sebességével állítanak elő felügyeleti bizonyítékot.
Platformmérnökség: az öt megnevezett alapelem. A felhőnatív érettség 2026-ban öt mérnöki alapelemre egyszerűsödik, amelyek összekapcsolódva a telepítési folyamat sebességével állítanak elő felügyeleti bizonyítékot.

A felhőnatív bankolás indexe 2026-ban: DORA, platformmérnökség, szuverén felhő és működési ellenállóképesség

A DORA felhős ellenállóképessége auditfázisban van. A 2024-2025 során meghozott platformmérnökségi döntéseket vizsgálja a 2026-os felügyeleti ciklus: a Kubernetes kikövezett utak, a Backstage portál, a GitOps, az Open Policy Agent a beengedésnél, az OpenTelemetry végponttól végpontig, amelyek a 8. cikk szerinti nyilvántartási bizonyítékot telepítési műtermékként állítják elő, nem a vizsga idején.

A felhőnatív bankolás 2026-ban a DORA auditfázisában van. A Rendelet (EU) 2022/2554 ⧉ 2025. január 17. óta hatályban van. A kritikus harmadik feles szolgáltatók (CTPP) kijelölési rezsimje a 28-44. cikkek alapján 2025-2026 folyamán nyílt meg, az AWS, a Microsoft (Azure), a Google (GCP) és a Salesforce a kijelölési perimeteren belül vagy annak közelében helyezkedik el. Az európai felügyeleti hatóságok (EBA, EIOPA, ESMA) 2024-ben tették közzé a végleges RTS-t és ITS-t az Információs nyilvántartásról ⧉. Az EKB bankfelügyeleti csapatának kifejezett programjai vannak a felhőszolgáltatás-kiesésre való felkészültségről és a fenyegetésalapú behatolástesztelésről a 2026-28-as felügyeleti prioritásokban ⧉. Az intézményi kérdés nem az, hogy hozzá kell-e igazítani a felhőstratégiát a DORA-hoz, ez eldőlt, hanem az, hogy az intézmény platformmérnökségi alapelemei a telepítési folyamat sebességével állítanak-e elő bizonyítékot, ahelyett hogy a vizsga előtti héten összeállított PDF-ekben tennék.

Vezetői összefoglaló / Legfontosabb tanulságok

A DORA felhős ellenállóképessége 2025. január 17. óta aktív végrehajtás alatt áll. A 6., 8., 18., 26. és 28-44. cikkek mind hatályban vannak. Az első vizsgahullám felügyeleti megállapításai 2025 negyedik negyedévében érkeztek meg. A "felkészülés" keretezése két felügyeleti ciklussal elavult.

A CTPP kijelölési rezsim megnyílik. AWS, Microsoft, Google, Salesforce: a perimeteren belül vagy annak közelében. A kijelölés az ESA-k számára közvetlen felügyeleti jogokat ad, ideértve az információkéréseket, a helyszíni ellenőrzéseket és a felügyeleti ajánlásokat.

A platformmérnökség a teljesítendő eredmény. Kubernetes kikövezett utak (EKS / AKS / GKE / OpenShift), Backstage-stílusú fejlesztői portál, GitOps (ArgoCD vagy Flux), Open Policy Agent a beengedésnél, OpenTelemetry végponttól végpontig. Öt megnevezett alapelem; bármelyik hiánya megállapítás.

A szuverén felhő mérnöki munka, nem márka. AWS European Sovereign Cloud, Microsoft EU Data Boundary, Bleu (Capgemini + Orange + Microsoft), Thales / S3NS, Oracle EU Sovereign Cloud: mindegyik egy adott Schrems II + DORA 28. cikk dimenziót kezel; egyik sem kulcsrakész válasz.

Tesztelt kiléptetési bizonyíték szükséges. EBA/GL/2019/02 81. és 113-117. bekezdés. A negyedéves asztali gyakorlat nem elegendő; a felügyeletek éves, végponttól végpontig tartó kiléptetés-végrehajtási tesztelést várnak minden kritikus vagy fontos funkcióra.

Az RTO / RPO a CIF-leltárból származik. 1. szint: 2h / 15 perc. 2. szint: 4h / 1h. 3. szint: 24h / 4h. Az üzletihatás-elemzésből származtatva, nem a platformcsapat kapacitásából.

Miért van auditfázisban a DORA felhős ellenállóképessége

Három ok, amiért a "felkészülés" keretezése rossz 2026-ban.

Először is, az idővonal. A DORA-t 2022 decemberében tették közzé. A 24 hónapos alkalmazási időszak 2025. január 17-én zárult le. Az ESA-k végleges RTS-e és ITS-e, ideértve a CTPP kijelöléshez használt információs nyilvántartásról szóló ITS-t, 2024 folyamán jelent meg. Az első felügyeleti vizsgahullám 2025 során zajlott; a 6. cikk szerinti ICT kockázatkezelési keretrendszer teljességéről és a 8. cikk szerinti nyilvántartás egyeztetéséről szóló megállapítások 2025 negyedik negyedévében érkeztek meg több első vonalbeli intézménynél.

Másodszor, a CTPP kijelölési rezsim. A 31. cikk határozza meg a kritikus harmadik feles szolgáltatóként való kijelölés kritériumait: rendszerszintű hatás meghibásodás esetén, a nyújtott szolgáltatások kritikussága, a szolgáltatások mérete és összetettsége, helyettesíthetőség. Az ESA-k vezetik a nyilvántartást és teszik közzé a kijelölési döntéseket. Az AWS, a Microsoft (Azure), a Google (GCP) és a Salesforce a kijelölési perimeteren belül vagy annak közelében van, a pénzügyi szolgáltatások piaci részesedésétől függően tagállamonként. A kijelölés a vezető felügyelőnek (az egyik ESA-nak, szolgáltatónként kiosztva) közvetlen felügyeleti jogkört ad: információkérések a 37. cikk alapján, helyszíni ellenőrzések a 38. cikk alapján, ajánlások a 35. cikk alapján, valamint a nyilvános közzétételi rezsim a 41. cikk alapján. Az ezen CTPP-k felett felügyelt bankokra megfelelő felügyeleti elvárások vonatkoznak arra nézve, hogyan kezelik ezt a kijelölt függőséget.

Harmadszor, az EKB 2026-28-as felügyeleti prioritásai. A prioritásokat tartalmazó dokumentum két olyan kifejezett programot nevez meg, amelyek közvetlenül érintik a felhőnatív bankolást: a jelentős felhőszolgáltatás-kiesésre való felkészültség (modellezett felügyeleti forgatókönyvek tesztelik az intézmény képességét egy kijelölt CTPP tartós kiesésének elviselésére) és a DORA 26. cikkéhez igazított TIBER-EU szerinti TLPT (minden TIBER-EU gyakorlat felméri az intézmény kritikus és fontos funkcióit, amelyek immár a nyilvános felhőben elhelyezett szolgáltatásokat is magukban foglalják). A 2026-os vizsgahullám mindkettőre megállapításokat fog produkálni.

A 2026-os keretezés nem "a DORA közeledik", hanem "a DORA vizsgamegállapításai megérkeznek az intézménye postaládájába, és a 2024-2025 során meghozott platformmérnökségi döntéseket vizsgálja a felügyelet ezekben a megállapításokban".

A 2026-os index architektúrája

Indexréteg	Hogyan néz ki a "készenlét"	Készenléti mutató	Meghibásodási mód
Platformérettség	A munkaterhelések >80%-a kikövezett úton lévő Kubernetes platformon (EKS / AKS / GKE / OpenShift), policy-as-code beengedéssel, GitOps telepítéssel, automatizált DR-teszteléssel	A CIF-ek %-a kikövezett úton lévő platformon; árnyéktelepítések száma; egy új szolgáltatás platformra való bevezetésének átlagos ideje	Következetlen kontrollokkal működő árnyékplatformok; a 8. cikk szerinti nyilvántartás egyeztetése számára láthatatlan, kikövezetlen infrastruktúrán futó CIF-ek
A 8. cikk szerinti nyilvántartás integritása	Az információs nyilvántartás automatikusan egyeztet a platform harmadik feles API-fogyasztásához + felhős anyagjegyzékhez; a kritikussági besorolás összhangban van az intézmény CIF-leltárával	A platformtelemetriához egyeztetett nyilvántartási bejegyzések %-a; árvabejegyzések száma; CTPP-perimeter integritásellenőrzés	Az ESA-k azonosítanak egy kijelölt CTPP-függőséget, amelyet az intézmény elmulasztott közzétenni a 8. cikk alapján; egyedi megállapítás és CTPP-perimeter következmény
Felhőkoncentráció	A kritikus funkciók felhőszolgáltatókhoz ÉS al-felhőrégiókhoz ÉS szolgáltatásokhoz ÉS helyettesíthetőségi felméréshez leképezve; a CIF-eken átívelő korrelált kitettség számszerűsítve	Koncentrációs pontszám CIF-enként; korrelált kitettség olyan CIF-ek között, amelyek közös kijelölt CTPP-régiót használnak	Egyetlen AWS us-east-1 IAM-kiesés négy olyan CIF-et vesz le a lábáról, amelyekről az intézmény azt hitte, hogy egymástól függetlenül vannak erőforrással ellátva
Tesztelt kiléptetési képesség	Éves, végponttól végpontig tartó kiléptetés-végrehajtási teszt minden kijelölt CTPP-től függő CIF-re; dokumentált RTO / RPO teljesíti a BIA-ból származtatott célokat; adathordozhatósági útvonal tesztelve	Tesztsikerességi arány CIF-enként; átlagos kiléptetés-végrehajtási idő az RTO-célhoz képest; adathordozhatósági útvonal késleltetése	Csak PDF-ként létező kiléptetési terv; az asztali gyakorlat 4h RTO-t mond, a tényleges teszt első nekifutásra 48h-t mutat
Megfigyelhetőség + incidensbejelentés	OpenTelemetry nyomok végponttól végpontig a szolgáltatásokon átívelően; automatizált 18. cikk szerinti 4 órás besorolási segéd bekötve az incidenskezelési platformba	Az OTel nyomokkal lefedett CIF-forgalom %-a; átlagos idő az incidensfelismeréstől a 18. cikk szerinti besorolási döntésig	Jelentős incidens a 4 órás ablakon kívül besorolva, mert a kritikusság megállapítása triázsértekezletet igényelt; 18. cikk szerinti megállapítás
TLPT integráció	A TLPT hatóköre a CIF-leltárból származtatva és folyamatosan frissítve; a megállapítások visszacsatolnak a platform policy-as-code-jába; a lezárt megállapítások felügyeletre kész bizonyítékcsomagokat állítanak elő	TLPT-megállapítások lezárási aránya; megállapítás-házirendfrissítés ciklusideje	A TLPT olyan sebezhetőséget tár fel, amelyet az intézmény platformmérnökségi csapata nem tud két kiadási ciklusnál rövidebb idő alatt kijavítani

Aktuális jelzések, amelyeket követni kell

Jelzés	Mit jelent a bankoknak	Forrás
A DORA aktív végrehajtás alatt áll 2025. jan. 17. óta	Az első hullám felügyeleti megállapításai 2025 negyedik negyedévében érkeztek meg; a második hullám megállapításai 2026 második félévében várhatók	EUR-Lex ⧉
A CTPP kijelölés 2025-2026 folyamán nyílik meg	AWS, Microsoft, Google, Salesforce a perimeteren belül vagy annak közelében; a kijelölés az ESA-knak közvetlen felügyeleti jogokat ad	EBA ⧉
Az EKB 2026-28-as felügyeleti prioritásai kifejezetten megnevezik a felhőkiesést	Modellezett felügyeleti forgatókönyvek tesztelik a kijelölt CTPP tartós kiesésének elviselésére való képességet	EKB Bankfelügyelet ⧉
A TIBER-EU a DORA 26. cikkéhez igazítva	A TLPT hatóköre lefedi a kritikus / fontos funkciókat, ideértve a felhőben elhelyezett szolgáltatásokat	EKB TIBER-EU ⧉
Az EBA kiszervezési iránymutatásai (EBA/GL/2019/02) összekapcsolódnak a DORA 28. cikkével	Érdemi jelenlét (¶64), helyettesíthetőségi felmérés (¶81), kiléptetési stratégia (¶113-117): a bekezdések, amelyeket a felügyeletek valóban vizsgálnak	EBA ⧉
Az EU felhőszolgáltatási séma (EUCS) tervezete halad előre	Jövőbeli szuverén felhő tanúsítási séma az EU kiberbiztonsági törvénye alapján; ENISA által közzétett tervezet	ENISA EUCS ⧉

Platformmérnökség: az öt megnevezett alapelem

A felhőnatív érettség 2026-ban öt mérnöki alapelemre egyszerűsödik, amelyek összekapcsolódva a telepítési folyamat sebességével állítanak elő felügyeleti bizonyítékot. Bármelyik hiánya megtörténni készülő megállapítás.

1. Kubernetes-alapú kikövezett utak

Minden CIF egy menedzselt Kubernetes platformon fut: EKS, AKS, GKE vagy OpenShift egy kijelölt CTPP-n, vagy egy szállító által menedzselt alternatíván. A platformcsapat egyetlen arany-fürt mintát üzemeltet ellenőrzött eltéréssel: csomópontok egy dokumentált alapképfájlból; névtér-csapatonkénti izoláció; pod-security-standards-restricted profil; hálózati házirendek; service-mesh injektálás (Istio vagy Linkerd) a szolgáltatások közötti hitelesítéshez és megfigyelhetőséghez. Az új szolgáltatások egy sablonalapú bevezetési munkafolyamaton keresztül csatlakoznak a kikövezett úthoz, amely a 8. cikk szerinti nyilvántartási bejegyzést telepítési műtermékként állítja elő.

2. Backstage-stílusú fejlesztői portál

Egy központi fejlesztői portál, a Spotify nyílt forráskódú Backstage ⧉ a referenciamegvalósítás, különféle vállalati alternatívákkal, biztosítja a nyilvántartási rendszert arról, hogy mi hol fut. A katalógus felsorol minden szolgáltatást, tulajdonost, függőséget, kritikussági besorolást, üzemeltetési kézikönyvet, készenléti rotációt. A portál összekapcsolódik a 8. cikk szerinti nyilvántartással: minden katalógusbejegyzés egy nyilvántartási bejegyzéshez képeződik le; a nyilvántartási hivatkozás nélküli bejegyzések CI-hibát váltanak ki; a katalógusbeli jelenlét nélküli nyilvántartási bejegyzések felügyeletet megelőző riasztásokat váltanak ki.

3. GitOps telepítés ArgoCD vagy Flux segítségével

A produkciós telepítés egy GitOps vezérlőn keresztül fut, az ArgoCD vagy a Flux a produkciós szabvány 2026-ban, amely egy Git-verziózott deklaratív állapotot egyeztet a futó fürttel. A kézi kubectl apply le van tiltva; a produkcióba vezető egyetlen út egy összefésült pull request. A Git-tár az auditnapló; a felügyeletek, amelyek azt kérdezik, "mutassa meg az X szolgáltatás konfigurációját Y dátumon", egy Git-címkét kapnak, nem képernyőképet.

4. Open Policy Agent a beengedésnél

Az Open Policy Agent (OPA) a fürt beengedési láncában ül, és a platformházirendet érvényesíti: pod-security profil megfelelőség, képfájl-eredet, erőforráskorlátok, hálózati házirend megléte, kritikussági szintnek megfelelő replikáció, al-régiós elhelyezés szuverén felhő korlátozások mellett. A házirendek Git-verziózottak és a szolgáltatáskonfigurációkkal együtt változáskezeltek. Az elutasított telepítések áttekinthető indoklásokat állítanak elő, amelyek a változáskezelési bizonyítékcsomagot táplálják.

5. OpenTelemetry végponttól végpontig

Minden szolgáltatás OpenTelemetry nyomokat, metrikákat és naplókat bocsát ki. A platformcsapat egy központosított megfigyelhetőségi folyamatot üzemeltet, jellemzően Tempo vagy Jaeger a nyomokhoz, Prometheus a metrikákhoz, Loki vagy OpenSearch a naplókhoz, amely felszínre hozza a végponttól végpontig tartó CIF-egészséget, a függőségi leképezést és az incidensbesorolási bemeneteket. A 4 órás 18. cikk szerinti besorolási ablak a felismeréssel indul; az OTel folyamat lerövidíti a felismeréstől a besorolásig tartó utat egy lekérdezhető kereséssé, nem egy triázsértekezletté.

A szuverén felhő mint mérnöki munka, nem márka

A szuverén felhő stratégiának 2026-ban négy konkrét Schrems II + DORA + EBA kiszervezési kérdésre kell választ adnia:

Hol dolgozzák fel és tárolják az adatokat? EU tagállami elhelyezkedés; al-régió a magas kritikusságú áramlásokhoz; írásbeli adattartózkodási kötelezettségvállalások.
Kinek van jogi hozzáférése az adatokhoz? Kizárólag helyi alkalmazottak által végzett műveletek; külföldi kormányzati hozzáférési kérelmek helyi bírósági eljárás alá vetve; tesztelt válasz a jogszerű hozzáférési kérelmekre.
Milyen a helyettesíthetőségi profil? EBA/GL/2019/02 ¶81 helyettesíthetőségi felmérés; tesztelt kiléptetés-végrehajtás; azonosított és szerződtetett alternatív szolgáltató (vagy dokumentálva, hogy miért nem kivitelezhető).
Milyen a technikai szuverenitási modell? Ügyfél által ellenőrzött kulcsok; kriptográfiai elkülönítés; szuverén menedzsment-sík; auditálható ellátási lánc.

A 2026-os szállítói lehetőségek, amelyek ezekre a kérdésekre válaszolnak:

AWS European Sovereign Cloud (2023-ban bejelentve, GA 2026 második félévében várható): egy EU-honos AWS leányvállalat által üzemeltetett fizikai régió; EU-honos műveletek és támogatás; ügyfél által ellenőrzött kulcsok a KMS-XKS minta révén. A DORA 28. cikk szerinti szerződéses tartalom igazítása 2026-ban függőben.
Microsoft EU Data Boundary (GA 2024) + Bleu (Capgemini + Orange + Microsoft, csak Franciaország): a Data Boundary az EU ügyféladatokat EU régiókban tartja; a Bleu a SecNumCloudhoz igazított francia szuverén felhő, amely a Microsoft Azure stacket futtatja francia működési ellenőrzés alatt.
Google Cloud szuverén partnerségek: Thales / S3NS Franciaországban (Bleu-megfelelő); T-Systems Németországban.
Oracle EU Sovereign Cloud (GA 2023): kétrégiós minta (Frankfurt + Madrid) EU-honos műveletekkel; tisztán Schrems II-kompatibilis.
Gaia-X-hez igazított szolgáltatók (OVHcloud, Scaleway, Stackit, Aruba Cloud, IONOS): natív EU szolgáltatók Gaia-X címkézéssel; a hiperskálázóknál kisebb méret és ökoszisztéma, de nincs Foreign Intelligence Surveillance Act kitettség.

A stratégiai döntés ritkán bináris. Az első vonalbeli bankok jellemzően egy hiperskálázó-Data-Boundary konfigurációt futtatnak a munkaterhelések zöméhez, egy szuverén felhő lehetőséget a kijelölt magas érzékenységű áramlásokhoz (pl. AML / szankciós ügykezelő rendszerek, amelyek EU-honos személyes adatokat kezelnek), és egy tartalék-helyettesíthetőségi útvonalat, amelyet évente tesztelnek a DORA 28. cikk alapján.

Tesztelt kiléptetés-végrehajtás

Az EBA/GL/2019/02 ⧉ 113-117. bekezdései a kiléptetési stratégia rendelkezései. A szöveg egyértelmű abban, hogy mi szükséges: "Az intézményeknek és pénzforgalmi intézményeknek biztosítaniuk kell, hogy képesek legyenek kilépni a kiszervezési megállapodásokból anélkül, hogy indokolatlanul megzavarnák üzleti tevékenységüket… A kiléptetési stratégiákat dokumentálni és tesztelni is kell a kiszervezési megállapodások rendszeres felülvizsgálatának részeként."

A felügyeleti elvárás 2026-ban éves, végponttól végpontig tartó kiléptetés-végrehajtási tesztelés minden kijelölt CTPP-től függő CIF-re. Az asztali gyakorlatok és a dokumentumfelülvizsgálatok nem elegendők. A tesztnek elő kell állítania:

Helyreállítási idő mérése: a tényleges eltelt idő a kiléptetés bejelentésétől a munkaterhelés alternatív szolgáltatón való helyreállításáig, a BIA-ból származtatott RTO-célhoz mérve.
Adathordozhatósági bizonyíték: tesztelt adatexport az elsődlegesből, a célszolgáltató importútvonalával szemben validálva, egyeztetési bizonyítékkal.
Funkcionális egyenértékűség: az alternatív szolgáltatón futó tesztelt munkaterhelés egyenértékű SLO-kkal.
Költségbizonyíték: dokumentált kiléptetés-végrehajtási költség szemben a helyreállítási költség feltételezésével az intézmény tartalékkészenléti tervében.

A CIF végponttól végpontig tartó kiléptetéstesztelésének első nekifutása jellemzően 5-10-szeres eltérést tár fel a dokumentált RTO és a tényleges RTO között. Ennek az eltérésnek a megszüntetése mérnöki munka, amely hónapokat vesz igénybe. Azok a bankok, amelyek ezt egy felügyeleti ellenőrzés során fedezik fel, nem a saját éves tesztciklusuk során, egy harmadik negyedéves megállapítási ciklussal néznek szembe, amelyet elkerülhettek volna.

RTO / RPO célok a CIF-leltárból

Minden kritikus vagy fontos funkció egy szintbesoroláshoz képeződik le, amely az intézmény üzletihatás-elemzéséből származik. A szint hajtja az RTO- és RPO-célokat, amelyeket a platformmérnökségi csapat vállal teljesíteni.

Szint	Példák	RTO	RPO
1. szint (küldetéskritikus)	RTGS-kapcsolat (CHAPS / T2 / Fedwire), lakossági fizetési engedélyezés, ügyfélhitelesítés a digitális csatornákhoz	2 óra	15 perc
2. szint (kritikus)	AML / szankciószűrés, csalásfelismerő folyamatok, ATM-engedélyezés, kötegelt fizetésfeldolgozás	4 óra	1 óra
3. szint (fontos)	Jelentéstétel és szabályozói beadás, ügyfélközpontú tudásbázisok, belső együttműködési platformok	24 óra	4 óra
4. szint (nem kritikus)	Belső HR-rendszerek, marketingeszközök, nem ügyfélközpontú jelentéstétel	72 óra	24 óra

Ezek a számok illusztratívak, az intézmény BIA-ja állítja elő a sajátjait. A platformmérnökségi teljesítendő eredmény egy regressziótesztelt képesség a BIA-ból származtatott célok teljesítésére, amelyet szolgáltatásonkénti automatizált DR-teszteléssel bizonyítanak, és a CTPP-től függő CIF-ekre vonatkozó éves kiléptetés-végrehajtási teszttel validálnak.

Mit jelent ez banktípusonként

Globálisan rendszerszinten jelentős bankok

A nehéz probléma a méret az üzletágakon átívelően: több ezer szolgáltatás, több száz CIF, több kijelölt CTPP-kitettség termékeken, joghatóságokon és ellenállóképességi profilokon keresztül. A beruházás a központi platformmérnökségi képesség, a Kubernetes kikövezett utak, a Backstage portál, a GitOps, az OPA, az OTel, amely a 8. cikk szerinti nyilvántartás egyeztetését, a CTPP-koncentrációs térképet és a CIF-enkénti kiléptetés-végrehajtási képességet állítja elő üzletáganként egyedi építkezés nélkül.

Univerzális és közepes méretű bankok

A platformmérnökségi beruházás indokolt ezen a szinten, de a hatókör korlátozott: válassza ki a két vagy három legmagasabb kritikusságú CIF-et, építse köréjük a kikövezett út mintát, fogadja el, hogy az örökölt vagyon a meglévő kontrollokon folytatódik középtávon. A felügyeleti pozicionálás fontosabb, mint a platform szélessége: az, hogy bizonyítani lehessen a DORA 8. cikk szerinti nyilvántartás integritását és a tesztelt kiléptetést a top három CIF-re, lefedi a felügyelet elsődleges aggodalmait.

Regionális és kisebb bankok

Szállítóválasztás a belső építkezés helyett. Válasszon olyan bankplatform-szállítót, amelynek Kubernetes-natív architektúrája dokumentált, amelynek 8. cikk szerinti nyilvántartás-integrációja beépített, és amelynek DORA 28. cikk szerinti szerződéses tartalomvállalásai egyértelműek. A belső mérnöki képesség a konfiguráció, a monitorozás és az incidenskezelés körül van, nem a platformépítés.

Fintechek, PSP-k és bankokat kiszolgáló SaaS-szolgáltatók

A termékkérdés az EU-bankoknak 2026-ban értékesítő szállítók számára az, hogy a platform előállítja-e a 8. cikk szerinti nyilvántartási bejegyzéseket és a DORA 28. cikk szerinti szerződéses tartalmat, amelyre a bank megfelelőségi funkciójának szüksége van. A strukturált kimeneteket biztosító szállítók nyerik meg a vállalati üzleteket; a PDF-sablonokkal rendelkező szállítók veszítenek a strukturált JSON-nal rendelkező versenytársakkal szemben.

Következtetés

A DORA felhős ellenállóképessége auditfázisban van. A 2024-2025 során meghozott platformmérnökségi döntéseket vizsgálja a 2026-os felügyeleti ciklus. Azok az intézmények, amelyek hitelesnek tűnnek az EKB és az EBA számára 2026-2028-ban, azok, amelyek Kubernetes kikövezett utakat futtatnak Backstage-stílusú portálokkal és GitOps telepítéssel, Open Policy Agent beengedés alatt, OpenTelemetry végponttól végpontig, amelyek a 8. cikk szerinti nyilvántartási bizonyítékot telepítési műtermékként és a tesztelt kiléptetés-végrehajtási bizonyítékot éves ciklusként állítják elő, nem felügyeleti kérésre adott válaszként.

Azok az intézmények, amelyek nem hozták meg ezeket a beruházásokat, felfedezik majd, hogy a második vonalbeli megfelelőségi csapatuk fel tudja-e dolgozni a felügyeleti megállapítások első körét, mielőtt a második kör megérkezik.

Mérje a platformot úgy, ahogy bármely működési programot mérne: kikövezett út lefedettsége, nyilvántartás-egyeztetési arány, CTPP-koncentrációs pontszám, tesztelt kiléptetési idő az RTO-célhoz képest, 18. cikk szerinti besorolás átlagideje, TLPT-lezárási arány. Bizonyíték a folyamat sebességével; dokumentumcsomagok csak akkor, amikor a felügyelet kér egyet.

Gyakran ismételt kérdések

A DORA felhős ellenállóképessége még mindig felkészülési fázisban van 2026-ban?

Nem. A DORA 2025. január 17. óta aktív végrehajtás alatt áll. A CTPP kijelölési rezsim a 28-44. cikkek alapján 2025-2026 folyamán nyílik meg. Az EKB vizsgamegállapításai a 6. cikk szerinti ICT kockázatkezelésről és a 8. cikk szerinti nyilvántartás integritásáról 2025 negyedik negyedévében érkeztek meg több első vonalbeli intézménynél. A 2026-os felügyeleti kérdés intézményspecifikus vizsgabizonyíték, nem szabályozói készenlét.

Mely felhőszolgáltatókat jelölik ki CTPP-ként?

Az ESA-k a webhelyeiken teszik közzé a kijelölési döntéseket. A perimeteren belül vagy annak közelében lévő intézmények 2026-ban közé tartozik az AWS, a Microsoft (Azure), a Google (GCP), a Salesforce, valamint néhány másik, a pénzügyi szolgáltatások piaci részesedésétől függően tagállamonként. Az ezen szolgáltatók felett felügyelt bankokra megfelelő felügyeleti elvárások vonatkoznak arra nézve, hogyan kezelik ezt a függőséget.

A szuverén felhő megszünteti a DORA 28. cikk szerinti szerződéses tartalom szükségességét?

Nem. A szuverén felhő a Schrems II + adattartózkodási dimenziót kezeli; a DORA 28. cikk szerinti szerződéses tartalom egy külön kötelezettség, amely attól függetlenül alkalmazandó, hogy hol vannak az adatok. A szuverén felhő szolgáltatójának szerződésének továbbra is le kell fednie az adathozzáférhetőséget, a biztonságot, a tartózkodást, az auditjogokat, a kiléptetési stratégiákat és a folytonosságot a 28. cikk szerint.

Mi az a mérnöki teljesítendő eredmény, amely demonstrálja a DORA felhős ellenállóképességét?

Öt platformmérnökségi alapelem összekapcsolódása: Kubernetes kikövezett utak (menedzselt fürt házirenddel ellenőrzött eltéréssel), Backstage-stílusú fejlesztői portál (a 8. cikk szerinti nyilvántartáshoz egyeztető katalógus), GitOps telepítés (ArgoCD vagy Flux), Open Policy Agent a beengedésnél, OpenTelemetry végponttól végpontig. Bizonyíték a folyamat sebességével, nem a vizsga idején.

Milyen gyakran kell tesztelni a kiléptetés-végrehajtást?

Éves, végponttól végpontig tartó kiléptetés-végrehajtási tesztelés minden kijelölt CTPP-től függő CIF-re. Az asztali gyakorlatok és a dokumentumfelülvizsgálatok nem elegendők. A tesztnek helyreállítási időt, adathordozhatósági bizonyítékot, funkcionális egyenértékűséget és költségbizonyítékot kell előállítania, a BIA-ból származtatott RTO- és RPO-célokhoz mérve.

Hivatkozások

European Union, (2022). Rendelet (EU) 2022/2554, a digitális működési ellenállóképességről szóló rendelet (DORA) ⧉.
European Banking Authority, (2019). EBA/GL/2019/02, iránymutatások a kiszervezési megállapodásokról ⧉.
European Banking Authority, (2026). Digital Operational Resilience Act ⧉.
European Supervisory Authorities, (2024). Végleges jelentés a DORA szerinti információs nyilvántartásról szóló ITS-ről ⧉.
ECB Banking Supervision, (2025). Felügyeleti prioritások 2026-28 ⧉.
European Central Bank, (2024). TIBER-EU keretrendszer ⧉.
ENISA, (2024). EU kiberbiztonsági séma felhőszolgáltatásokhoz (EUCS) ⧉.
Spotify, (2020-2024). Backstage fejlesztői portál ⧉.
Cloud Native Computing Foundation, (2018). Open Policy Agent (OPA) ⧉.
Cloud Native Computing Foundation, (2019). OpenTelemetry ⧉.

Utolsó felülvizsgálat 2026-07-14.

A cikk újraközlése

A felhőnatív bankolás indexe 2026-ban: DORA, platformmérnökség, szuverén felhő és működési ellenállóképesség — Sebastien Rousseau

Egy 2026-os felhőnatív bankolási index a DORA-felkészültség, a platformmérnökségi érettség, a felhőkoncentrációs kockázat, a kiléptetési bizonyíték és a működési ellenállóképesség méréséhez.

Ez a cikk a következő licenc alatt áll: Creative Commons Attribution 4.0 International. Az újraközléshez a kanonikus URL forrásmegjelölése szükséges.

A felhőnatív bankolás indexe 2026-ban: DORA, platformmérnökség, szuverén felhő és működési ellenállóképesség — Sebastien Rousseau

Egy 2026-os felhőnatív bankolási index a DORA-felkészültség, a platformmérnökségi érettség, a felhőkoncentrációs kockázat, a kiléptetési bizonyíték és a működési ellenállóképesség méréséhez.

Originally published at https://sebastienrousseau.com/hu/2026-06-05-cloud-native-banking-index-dora-resilience-platform-engineering-2026/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER