Хмарно-нативний банкінг у 2026 — у фазі аудиту DORA. Регламент (ЄС) 2022/2554 ⧉ чинний з 17 січня 2025. Режим визначення критичних провайдерів третіх сторін (CTPP) за Статтями 28-44 розгортається протягом 2025-2026, причому AWS, Microsoft (Azure), Google (GCP) та Salesforce перебувають у межах або поруч із периметром визначення. Європейські наглядові органи (EBA, EIOPA, ESMA) опублікували фінальні RTS та ITS щодо Реєстру інформації ⧉ у 2024 році. Команда банківського нагляду ЄЦБ має окремі програми щодо готовності до хмарних збоїв і тестування на проникнення під керівництвом загроз у наглядових пріоритетах на 2026-28 ⧉. Інституційне питання — не в тому, чи узгоджувати хмарну стратегію з DORA (це вирішено), а в тому, чи примітиви інженерії платформи установи продукують докази зі швидкістю конвеєра розгортання, а не у форматі PDF, зібраних за тиждень до іспиту.
Резюме для керівництва / Ключові висновки
- Хмарна стійкість за DORA — у режимі активного забезпечення з 17 січня 2025. Статті 6, 8, 18, 26 та 28-44 — усі чинні. Наглядові висновки першої хвилі іспитів надійшли у Q4 2025. Формулювання «підготовка» відстало на два цикли.
- Режим визначення CTPP розгортається. AWS, Microsoft, Google, Salesforce — у межах або поруч. Визначення дає ESA прямі наглядові права, включно з інформаційними запитами, виїзними перевірками та наглядовими рекомендаціями.
- Інженерія платформи — це продукт. Бруковані маршрути на Kubernetes (EKS / AKS / GKE / OpenShift), портал розробника у стилі Backstage, GitOps (ArgoCD або Flux), Open Policy Agent на прийомі, OpenTelemetry наскрізно. П'ять названих примітивів; усе відсутнє — це майбутній висновок.
- Суверенна хмара — це інженерія, а не бренд. AWS European Sovereign Cloud, Microsoft EU Data Boundary, Bleu (Capgemini + Orange + Microsoft), Thales / S3NS, Oracle EU Sovereign Cloud — кожна закриває конкретний вимір Schrems II + Статті 28 DORA; жодна не є відповіддю «під ключ».
- Потрібні протестовані докази виходу. Параграфи 81 і 113-117 EBA/GL/2019/02. Квартальний tabletop недостатній; наглядачі очікують щорічного наскрізного тестування виконання виходу для кожної критичної чи важливої функції.
- RTO / RPO з інвентаризації CIF. Рівень 1: 2г / 15хв. Рівень 2: 4г / 1г. Рівень 3: 24г / 4г. Виведено з аналізу впливу на бізнес, а не з ємності команди платформи.
Чому хмарна стійкість за DORA — у фазі аудиту #
Три причини, чому формулювання «підготовка» у 2026 — хибне.
По-перше, хронологія. DORA опубліковано у грудні 2022. 24-місячний період застосування завершився 17 січня 2025. Фінальні RTS та ITS ESA — включно з ITS щодо Реєстру інформації, який використовується для визначення CTPP, — публікувалися протягом 2024 року. Перша хвиля наглядових перевірок пройшла у 2025; висновки щодо повноти рамки управління ризиками ICT за Статтею 6 та звірки реєстру за Статтею 8 надійшли у Q4 2025 до низки установ першого ешелону.
По-друге, режим визначення CTPP. Стаття 31 встановлює критерії визначення як критичного провайдера третіх сторін: системний вплив у разі збою, критичність наданих послуг, масштаб і складність послуг, замінність. ESA ведуть реєстр і публікують рішення про визначення. AWS, Microsoft (Azure), Google (GCP) та Salesforce перебувають у межах або поруч із периметром визначення — залежно від частки на ринку фінансових послуг по державах-членах. Визначення дає провідному наглядачу (один з ESA, призначений за кожним провайдером) прямі повноваження нагляду: інформаційні запити за Статтею 37, виїзні перевірки за Статтею 38, рекомендації за Статтею 35 та режим публічного розкриття за Статтею 41. Банки, які підлягають нагляду за цими CTPP, підпадають під відповідні наглядові очікування щодо того, як вони керують цією визначеною залежністю.
По-третє, наглядові пріоритети ЄЦБ на 2026-28. Документ пріоритетів називає дві окремі програми, що безпосередньо стосуються хмарно-нативного банкінгу: готовність до серйозного збою хмарного сервісу (модельовані наглядові сценарії перевіряють здатність установи поглинути тривалий збій визначеного CTPP) та TLPT, узгоджений із TIBER-EU (кожна вправа TIBER-EU охоплює критичні та важливі функції установи, які тепер включають сервіси, розміщені в публічній хмарі). Хвиля іспитів 2026 року дасть висновки в обох напрямах.
Формулювання для 2026 — не «DORA наближається», а «висновки іспитів за DORA вже надходять у поштову скриньку вашої установи, і рішення з інженерії платформи, прийняті у 2024-2025, — це те, що наглядач розбирає у цих висновках».
Архітектура Індексу 2026 #
| Шар індексу | Як виглядає «готовність» | Метрика готовності | Режим збою |
|---|---|---|---|
| Зрілість платформи | >80% робочих навантажень на брукованій Kubernetes-платформі (EKS / AKS / GKE / OpenShift) з прийомом за політикою-як-кодом, GitOps-розгортанням, автоматизованим DR-тестуванням | % CIF на брукованій платформі; кількість тіньових розгортань; середній час підключення нового сервісу до платформи | Тіньові платформи з неузгодженими контролями; CIF, що працюють на небрукованій інфраструктурі, невидимій для звірки реєстру за Статтею 8 |
| Цілісність реєстру за Статтею 8 | Реєстр інформації автоматично звіряється зі споживанням API третіх сторін платформою + хмарною специфікацією матеріалів; класифікація критичності узгоджена з інвентаризацією CIF установи | % записів реєстру, звірених з телеметрією платформи; кількість сирітських записів; перевірка цілісності периметра CTPP | ESA виявляють залежність від визначеного CTPP, яку установа не розкрила за Статтею 8; індивідуальний висновок і наслідки на периметрі CTPP |
| Концентрація в хмарі | Критичні функції мапповані на хмарних провайдерів І субрегіони хмари І сервіси І оцінку замінності; корельована експозиція між CIF кількісно оцінена | Оцінка концентрації на CIF; корельована експозиція через CIF, що ділять регіон визначеного CTPP | Один збій AWS us-east-1 IAM зупиняє чотири CIF, які установа вважала незалежно забезпеченими ресурсами |
| Протестована спроможність виходу | Щорічний наскрізний тест виконання виходу для кожної CIF, залежної від визначеного CTPP; задокументовані RTO / RPO відповідають цілям, виведеним з BIA; протестований шлях переносимості даних | Частка успішних тестів на CIF; середній час виконання виходу проти цілі RTO; затримка шляху переносимості даних | План виходу, що існує лише у PDF; tabletop каже 4г RTO, реальний тест показує 48г з першої спроби |
| Спостережуваність + звітність про інциденти | Трасування OpenTelemetry наскрізно через сервіси; автоматизований помічник 4-годинної класифікації за Статтею 18, вшитий у платформу управління інцидентами | % трафіку CIF, покритого OTel-трасами; середній час від виявлення інциденту до рішення про класифікацію за Статтею 18 | Серйозний інцидент класифікований поза 4-годинним вікном, бо визначення критичності вимагало нарад тріажу; висновок за Статтею 18 |
| Інтеграція TLPT | Обсяг TLPT виведений з інвентаризації CIF і безперервно оновлюється; висновки надходять у політику-як-код платформи; закриті висновки продукують пакети доказів, готові для наглядача | Рівень закриття висновків TLPT; час циклу від висновку до оновлення політики | TLPT виявляє вразливість, яку команда інженерії платформи установи не може виправити менше ніж за два релізні цикли |
Поточні сигнали для відстеження #
| Сигнал | Що це означає для банків | Джерело |
|---|---|---|
| DORA у режимі активного забезпечення з 17 січ 2025 | Висновки наглядачів першої хвилі надійшли Q4 2025; висновки другої хвилі очікуються до H2 2026 | EUR-Lex ⧉ |
| Визначення CTPP розгортається протягом 2025-2026 | AWS, Microsoft, Google, Salesforce — у межах або поруч із периметром; визначення дає ESA прямі права нагляду | EBA ⧉ |
| Наглядові пріоритети ЄЦБ на 2026-28 явно називають хмарні збої | Модельовані наглядові сценарії перевіряють здатність поглинути тривалий збій визначеного CTPP | Банківський нагляд ЄЦБ ⧉ |
| TIBER-EU узгоджено зі Статтею 26 DORA | Обсяг TLPT охоплює критичні / важливі функції, включно з хмарними сервісами | ЄЦБ TIBER-EU ⧉ |
| Настанови EBA з аутсорсингу (EBA/GL/2019/02) зчіпляються зі Статтею 28 DORA | Суттєва присутність (¶64), оцінка замінності (¶81), стратегія виходу (¶113-117) — параграфи, які наглядачі дійсно перевіряють | EBA ⧉ |
| Проект схеми EU Cloud Services Scheme (EUCS) просувається | Майбутня схема сертифікації суверенної хмари за Актом ЄС про кібербезпеку; проект, опублікований ENISA | ENISA EUCS ⧉ |
Інженерія платформи: п'ять названих примітивів #
Хмарно-нативна зрілість у 2026 зводиться до п'яти інженерних примітивів, які зчіпляються між собою, щоб продукувати наглядові докази зі швидкістю конвеєра розгортання. Відсутність будь-якого — це майбутній висновок.
1. Бруковані маршрути на Kubernetes #
Кожен CIF працює на керованій Kubernetes-платформі — EKS, AKS, GKE або OpenShift на визначеному CTPP, чи на альтернативі під управлінням постачальника. Команда платформи експлуатує єдиний золотий шаблон кластера з контрольованим відхиленням: вузли з задокументованого базового образу; ізоляція простору імен на команду; обмежувальний профіль pod-security-standards; мережеві політики; вприскування service-mesh (Istio або Linkerd) для міжсервісної автентифікації та спостережуваності. Нові сервіси приєднуються до брукованого маршруту через шаблонний onboarding-процес, який продукує запис реєстру за Статтею 8 як артефакт розгортання.
2. Портал розробника у стилі Backstage #
Центральний портал розробника — еталонна реалізація Spotify з відкритим кодом Backstage ⧉ з різними корпоративними альтернативами — забезпечує систему обліку того, що де працює. Каталог перераховує кожен сервіс, власника, залежність, класифікацію критичності, runbook, ротацію чергування. Портал зчіпляється з реєстром за Статтею 8: кожен запис каталогу мапується на запис реєстру; записи без посилань на реєстр спричиняють збій CI; записи реєстру без присутності в каталозі спричиняють сповіщення, що випереджають наглядача.
3. GitOps-розгортання через ArgoCD або Flux #
Продакшен-розгортання працює через GitOps-контролер — ArgoCD або Flux є стандартом продакшену у 2026 — який звіряє декларативний стан, версіонований у Git, з працюючим кластером. Ручний kubectl apply вимкнено; єдиний шлях у продакшен — це злитий pull request. Git-репозиторій — це журнал аудиту; наглядачі, що питають «покажіть конфігурацію сервісу X станом на дату Y», отримують Git-тег, а не скриншот.
4. Open Policy Agent на прийомі #
Open Policy Agent (OPA) сидить у ланцюгу прийому кластера, забезпечуючи політику платформи: відповідність профілю pod-security, провенанс образу, обмеження ресурсів, наявність мережевої політики, реплікація, відповідна рівню критичності, розміщення в субрегіоні в умовах обмежень суверенної хмари. Політики версіоновані в Git і управляються змінами разом з конфігураціями сервісів. Відхилені розгортання продукують переглядні обґрунтування, що живлять пакет доказів управління змінами.
5. OpenTelemetry наскрізно #
Кожен сервіс емітує OpenTelemetry-траси, метрики та логи. Команда платформи експлуатує централізований конвеєр спостережуваності — типово Tempo або Jaeger для трас, Prometheus для метрик, Loki або OpenSearch для логів — який виводить наскрізне здоров'я CIF, мапування залежностей та входи для класифікації інцидентів. 4-годинне вікно класифікації за Статтею 18 починається з виявлення; OTel-конвеєр скорочує шлях від виявлення до класифікації до запиту, а не наради тріажу.
Суверенна хмара як інженерія, а не бренд #
Стратегія суверенної хмари у 2026 повинна відповісти на чотири конкретні питання Schrems II + DORA + аутсорсингу EBA:
- Де дані обробляються та зберігаються? Локація в державі-члені ЄС; субрегіон для високо-критичних потоків; зобов'язання щодо резидентності даних у письмовій формі.
- Хто має юридичний доступ до даних? Операції лише місцевими співробітниками; запити доступу від іноземних урядів, що підлягають місцевому судовому процесу; протестована відповідь на законні запити доступу.
- Який профіль замінності? Оцінка замінності за ¶81 EBA/GL/2019/02; протестоване виконання виходу; альтернативний провайдер визначений і законтрактований (або задокументовано, чому це нездійсненно).
- Якою є модель технічного суверенітету? Ключі під керуванням клієнта; криптографічне розділення; суверенна площина управління; ланцюг постачання, що піддається аудиту.
Опції постачальників 2026, що відповідають на ці питання:
- AWS European Sovereign Cloud (оголошено 2023, GA очікується H2 2026): фізичний регіон, що експлуатується резидентною в ЄС дочірньою AWS; операції та підтримка резидентами ЄС; ключі під керуванням клієнта через шаблон KMS-XKS. Очікується узгодження договірного змісту за Статтею 28 DORA у 2026.
- Microsoft EU Data Boundary (GA 2024) + Bleu (Capgemini + Orange + Microsoft, лише Франція): Data Boundary тримає дані клієнтів ЄС у регіонах ЄС; Bleu — це французька суверенна хмара, узгоджена з SecNumCloud, що працює на стеку Microsoft Azure під французьким операційним контролем.
- Суверенні партнерства Google Cloud: Thales / S3NS у Франції (еквівалент Bleu); T-Systems у Німеччині.
- Oracle EU Sovereign Cloud (GA 2023): шаблон з подвійним регіоном (Франкфурт + Мадрид) з операціями резидентами ЄС; чітко сумісний зі Schrems II.
- Провайдери, узгоджені з Gaia-X (OVHcloud, Scaleway, Stackit, Aruba Cloud, IONOS): рідні ЄС-провайдери з маркуванням Gaia-X; менший масштаб і екосистема, ніж у гіперскейлерів, але без експозиції до Foreign Intelligence Surveillance Act.
Стратегічне рішення рідко є бінарним. Банки першого ешелону зазвичай експлуатують конфігурацію «гіперскейлер з Data Boundary» для основної маси робочих навантажень, опцію суверенної хмари для визначених високо-чутливих потоків (наприклад, системи кейс-менеджменту AML / санкцій, що обробляють персональні дані резидентів ЄС) та шлях замінності для непередбачених випадків, що тестується щорічно за Статтею 28 DORA.
Протестоване виконання виходу #
Параграфи 113-117 EBA/GL/2019/02 ⧉ — це положення про стратегію виходу. Текст явний щодо вимог: «Установи та платіжні установи повинні забезпечити, що вони здатні вийти з угод аутсорсингу без неналежного порушення своєї ділової активності… Стратегії виходу також повинні бути задокументовані та протестовані в рамках регулярних перевірок угод аутсорсингу».
Наглядове очікування у 2026 — щорічне наскрізне тестування виконання виходу для кожної CIF, залежної від визначеного CTPP. Tabletop-вправи та перегляди документів недостатні. Тест має продукувати:
- Вимір часу-до-відновлення: фактичний час, що минув від оголошення виходу до відновлення робочого навантаження на альтернативному провайдері, проти цілі RTO, виведеної з BIA.
- Докази переносимості даних: протестований експорт даних з основного, перевірений проти шляху імпорту цільового провайдера, з доказами звірки.
- Функціональна еквівалентність: протестоване робоче навантаження, що працює на альтернативному провайдері з еквівалентними SLO.
- Докази витрат: задокументовані витрати на виконання виходу проти припущення про витрати на відновлення в плануванні непередбачених випадків установи.
Перша спроба наскрізного тестування виходу для CIF зазвичай виявляє розрив у 5-10× між задокументованим RTO і реальним RTO. Закриття цього розриву — інженерна робота, що триває місяці. Банки, які виявляють це під час наглядової перевірки, а не під час власного щорічного циклу тестування, стикаються з циклом висновків Q3, якого вони могли б уникнути.
Цілі RTO / RPO з інвентаризації CIF #
Кожна критична або важлива функція мапується на класифікацію за рівнем, виведену з аналізу впливу на бізнес установи. Рівень визначає цілі RTO та RPO, які команда інженерії платформи зобов'язується виконати.
| Рівень | Приклади | RTO | RPO |
|---|---|---|---|
| Рівень 1 (місія-критичний) | Підключення до RTGS (CHAPS / T2 / Fedwire), авторизація роздрібних платежів, автентифікація клієнтів для цифрових каналів | 2 години | 15 хвилин |
| Рівень 2 (критичний) | Скринінг AML / санкцій, конвеєри виявлення шахрайства, авторизація банкоматів, пакетна обробка платежів | 4 години | 1 година |
| Рівень 3 (важливий) | Звітність і регуляторні подання, бази знань для клієнтів, внутрішні платформи співпраці | 24 години | 4 години |
| Рівень 4 (некритичний) | Внутрішні HR-системи, маркетинговий інструментарій, не-клієнтська звітність | 72 години | 24 години |
Ці цифри — ілюстративні; BIA установи продукує власні. Продукт інженерії платформи — регресійно-тестована здатність виконувати цілі, виведені з BIA, підтверджена через автоматизоване DR-тестування на сервіс і валідована через щорічний тест виконання виходу для CIF, залежних від CTPP.
Що це означає за типом банку #
Глобальні системно значущі банки #
Складна задача — масштаб через бізнес-лінії: тисячі сервісів, сотні CIF, кілька експозицій до визначених CTPP через продукти, юрисдикції та профілі стійкості. Інвестиція — це центральна спроможність інженерії платформи — бруковані маршрути на Kubernetes, портал Backstage, GitOps, OPA, OTel — яка продукує звірку реєстру за Статтею 8, карту концентрації CTPP та спроможність виконання виходу CIF за CIF без побудови на замовлення для кожної бізнес-лінії.
Універсальні та середні банки #
Інвестиція в інженерію платформи виправдана на цьому рівні, але обсяг обмежений: вибрати дві-три CIF найвищої критичності, побудувати навколо них шаблон брукованого маршруту, погодитись, що застарілий портфель продовжує існувати на чинних контролях у середньостроковій перспективі. Наглядове позиціонування важливіше за широту платформи — здатність довести цілісність реєстру за Статтею 8 DORA та протестований вихід для трьох найважливіших CIF покриває первинні занепокоєння наглядача.
Регіональні та менші банки #
Вибір постачальника замість внутрішньої побудови. Виберіть постачальника банківської платформи з задокументованою Kubernetes-нативною архітектурою, вбудованою інтеграцією з реєстром за Статтею 8 та чіткими зобов'язаннями щодо договірного змісту за Статтею 28 DORA. Внутрішня інженерна спроможність — навколо конфігурації, моніторингу та реагування на інциденти, а не побудови платформи.
Фінтехи, PSP та SaaS-провайдери, що обслуговують банки #
Продуктове питання для постачальників, що продають у банки ЄС у 2026, — чи продукує платформа записи реєстру за Статтею 8 та договірний зміст за Статтею 28 DORA, потрібний функції відповідності банку. Постачальники зі структурованими виходами виграють корпоративні угоди; постачальники з PDF-шаблонами програють конкурентам зі структурованим JSON.
Висновок #
Хмарна стійкість за DORA — у фазі аудиту. Рішення з інженерії платформи, прийняті у 2024-2025, — це те, що наглядовий цикл 2026 розбирає по гвинтиках. Установи, що виглядатимуть переконливо для ЄЦБ та EBA у 2026-2028, — це ті, що експлуатують бруковані маршрути на Kubernetes з порталами у стилі Backstage та GitOps-розгортанням під прийомом Open Policy Agent з OpenTelemetry наскрізно, продукуючи докази реєстру за Статтею 8 як артефакт розгортання та протестовані докази виконання виходу як щорічний цикл, а не як відповідь на наглядовий запит.
Установи, які не зробили цих інвестицій, з'ясують, чи здатна їхня команда відповідності другої лінії поглинути перший раунд наглядових висновків до того, як прийде другий раунд.
Вимірюйте платформу так, як ви вимірюєте будь-яку операційну програму: покриття брукованого маршруту, рівень звірки реєстру, оцінка концентрації CTPP, протестований час виходу проти цілі RTO, середній час класифікації за Статтею 18, рівень закриття TLPT. Докази зі швидкістю конвеєра; пакети документації — лише коли наглядач їх просить.
Поширені запитання #
Чи хмарна стійкість за DORA усе ще у фазі підготовки у 2026?
Ні. DORA — у режимі активного забезпечення з 17 січня 2025. Режим визначення CTPP за Статтями 28-44 розгортається протягом 2025-2026. Висновки іспитів ЄЦБ щодо управління ризиками ICT за Статтею 6 та цілісності реєстру за Статтею 8 надійшли до низки установ першого ешелону у Q4 2025. Наглядове питання 2026 — це специфічні для установи докази іспиту, а не регуляторна готовність.
Які хмарні провайдери визначені як CTPP?
ESA публікують рішення про визначення на своїх вебсайтах. Установи в межах або поруч із периметром у 2026 включають AWS, Microsoft (Azure), Google (GCP), Salesforce та невелику кількість інших — залежно від частки на ринку фінансових послуг по державах-членах. Банки, що підлягають нагляду за цими провайдерами, стикаються з відповідними наглядовими очікуваннями щодо того, як вони керують цією залежністю.
Чи суверенна хмара усуває потребу в договірному змісті за Статтею 28 DORA?
Ні. Суверенна хмара закриває вимір Schrems II + резидентності даних; договірний зміст за Статтею 28 DORA — це окреме зобов'язання, що застосовується незалежно від того, де знаходяться дані. Контракт провайдера суверенної хмари повинен усе одно покривати доступність даних, безпеку, резидентність, права аудиту, стратегії виходу та безперервність за Статтею 28.
Який інженерний продукт демонструє хмарну стійкість за DORA?
П'ять зчеплених примітивів інженерії платформи: бруковані маршрути на Kubernetes (керований кластер з контрольованим за політикою відхиленням), портал розробника у стилі Backstage (каталог, що звіряється з реєстром за Статтею 8), GitOps-розгортання (ArgoCD або Flux), Open Policy Agent на прийомі, OpenTelemetry наскрізно. Докази зі швидкістю конвеєра, а не на момент іспиту.
Як часто потрібно тестувати виконання виходу?
Щорічно наскрізне тестування виконання виходу на кожну CIF, залежну від визначеного CTPP. Tabletop-вправи та перегляди документів недостатні. Тест має продукувати час-до-відновлення, докази переносимості даних, функціональну еквівалентність та докази витрат — виміряні проти цілей RTO та RPO, виведених з BIA.
Джерела #
- European Union, (2022). Регламент (ЄС) 2022/2554 — Digital Operational Resilience Act (DORA) ⧉.
- European Banking Authority, (2019). EBA/GL/2019/02 — Настанови щодо угод аутсорсингу ⧉.
- European Banking Authority, (2026). Digital Operational Resilience Act ⧉.
- European Supervisory Authorities, (2024). Фінальний звіт щодо ITS про Реєстр інформації за DORA ⧉.
- ECB Banking Supervision, (2025). Наглядові пріоритети 2026-28 ⧉.
- European Central Bank, (2024). Рамка TIBER-EU ⧉.
- ENISA, (2024). Схема ЄС з кібербезпеки для хмарних сервісів (EUCS) ⧉.
- Spotify, (2020-2024). Портал розробника Backstage ⧉.
- Cloud Native Computing Foundation, (2018). Open Policy Agent (OPA) ⧉.
- Cloud Native Computing Foundation, (2019). OpenTelemetry ⧉.
Востаннє переглянуто .
Останній перегляд .