Облачно изначально банкинг в 2026 году находится в стадии аудита DORA. Регламент (ЕС) 2022/2554 ⧉ действует с 17 января 2025 года. Режим назначения критических поставщиков третьих сторон (КППТС) по Статьям 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. Подача в духе «подготовка» отстаёт на два цикла.
- Режим назначения КППТС раскрывается. AWS, Microsoft, Google, Salesforce — внутри или у самой границы. Назначение даёт ESAs прямые надзорные права: запросы информации, выездные проверки, надзорные рекомендации.
- Инженерия платформы — это поставляемый результат. 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. Квартального настольного учения недостаточно; надзорные органы ожидают ежегодное сквозное тестирование исполнения выхода для каждой критической или важной функции.
- RTO / RPO — из инвентаризации КВФ. Уровень 1: 2ч / 15мин. Уровень 2: 4ч / 1ч. Уровень 3: 24ч / 4ч. Выводится из анализа влияния на бизнес, а не из возможностей команды платформы.
Почему облачная устойчивость по DORA находится в стадии аудита #
Три причины, по которым подача в духе «подготовка» в 2026 году неверна.
Первое — хронология. DORA опубликован в декабре 2022 года. 24-месячный период применения завершился 17 января 2025 года. Финальные RTS и ITS Европейских надзорных органов — включая ITS по Реестру информации, используемому для назначения КППТС, — публиковались в течение 2024 года. Первая волна надзорных экзаменов прошла в 2025 году; замечания по полноте рамок управления рисками ИКТ по Статье 6 и по сверке реестра по Статье 8 поступили в Q4 2025 в ряде учреждений первого эшелона.
Второе — режим назначения КППТС. Статья 31 устанавливает критерии назначения критическим поставщиком третьих сторон: системное воздействие в случае отказа, критичность предоставляемых услуг, масштаб и сложность услуг, заменяемость. ESAs ведут реестр и публикуют решения о назначении. AWS, Microsoft (Azure), Google (GCP) и Salesforce находятся внутри или у самой границы периметра назначения — в зависимости от доли на рынке финансовых услуг по странам-членам. Назначение даёт ведущему надзорному органу (одному из ESAs, закрепляемому за поставщиком) прямые надзорные полномочия: запросы информации по Статье 37, выездные проверки по Статье 38, рекомендации по Статье 35 и режим публичного раскрытия по Статье 41. К банкам, поднадзорным по этим КППТС, применяются соответствующие надзорные ожидания относительно того, как они управляют этой назначенной зависимостью.
Третье — надзорные приоритеты ЕЦБ на 2026-28. Документ о приоритетах называет две отдельные программы, напрямую затрагивающие облачно изначально банкинг: готовность к крупным сбоям облачных сервисов (моделируемые надзорные сценарии проверяют способность учреждения выдержать продолжительный отказ назначенного КППТС) и TLPT, согласованный с TIBER-EU (каждое учение TIBER-EU покрывает критические и важные функции учреждения, к которым теперь относятся и сервисы в публичном облаке). Экзаменационная волна 2026 года произведёт замечания по обоим направлениям.
Подача 2026 года — не «DORA приближается», а «замечания по экзамену DORA уже приходят в почтовый ящик вашего учреждения, и решения по инженерии платформы, которые вы принимали в 2024-2025 годах, и есть то, что надзорный орган изучает в этих замечаниях».
Архитектура индекса 2026 года #
| Слой индекса | Как выглядит «готовность» | Метрика готовности | Режим отказа |
|---|---|---|---|
| Зрелость платформы | >80% рабочих нагрузок на проторённой Kubernetes-платформе (EKS / AKS / GKE / OpenShift) с допуском по политике-как-код, развёртыванием через GitOps, автоматизированным тестированием аварийного восстановления | % КВФ на проторённой платформе; число теневых развёртываний; среднее время онбординга нового сервиса на платформу | Теневые платформы с несогласованными контролями; КВФ, работающие на непроторённой инфраструктуре, невидимой для сверки реестра по Статье 8 |
| Целостность реестра по Статье 8 | Реестр информации автоматически сверяется с потреблением сторонних API на платформе и облачной спецификацией компонентов; классификация критичности согласована с инвентаризацией КВФ учреждения | % записей реестра, сверенных с телеметрией платформы; число «осиротевших» записей; проверка целостности периметра КППТС | ESAs обнаруживают зависимость от назначенного КППТС, которую учреждение не раскрыло по Статье 8; персональное замечание и последствие для периметра КППТС |
| Концентрация в облаке | Критические функции отображены на облачных провайдеров, суб-регионы, сервисы и оценку заменяемости; коррелированная экспозиция между КВФ количественно оценена | Балл концентрации по каждой КВФ; коррелированная экспозиция между КВФ, использующими общий регион назначенного КППТС | Один сбой IAM в AWS us-east-1 выводит из строя четыре КВФ, которые учреждение считало независимо обеспеченными |
| Протестированная способность выхода | Ежегодный сквозной тест исполнения выхода для каждой КВФ, зависящей от назначенного КППТС; документированные RTO / RPO соответствуют целям из BIA; путь переносимости данных протестирован | Доля успешных тестов по КВФ; среднее время исполнения выхода против целевого RTO; задержка пути переносимости данных | План выхода, существующий только как PDF; настольное учение даёт RTO 4ч, фактический тест показывает 48ч с первой попытки |
| Наблюдаемость и отчётность об инцидентах | OpenTelemetry-трассы сквозного покрытия по сервисам; автоматизированный помощник 4-часовой классификации по Статье 18, встроенный в платформу управления инцидентами | % трафика КВФ, покрытого трассами OTel; среднее время от обнаружения инцидента до решения о классификации по Статье 18 | Крупный инцидент классифицирован вне 4-часового окна, потому что определение критичности потребовало совещания триажа; замечание по Статье 18 |
| Интеграция TLPT | Объём TLPT выводится из инвентаризации КВФ и непрерывно обновляется; находки возвращаются в политику-как-код платформы; закрытые находки производят пакеты доказательств, готовые к надзору | Доля закрытых находок TLPT; время цикла «находка — обновление политики» | TLPT обнаруживает уязвимость, которую команда инженерии платформы учреждения не может закрыть менее чем за два цикла релизов |
Текущие сигналы для отслеживания #
| Сигнал | Что это значит для банков | Источник |
|---|---|---|
| DORA в активном применении с 17 января 2025 года | Замечания первой волны поступили в Q4 2025; замечания второй волны ожидаются на горизонте H2 2026 | EUR-Lex ⧉ |
| Раскрытие назначения КППТС в 2025-2026 | AWS, Microsoft, Google, Salesforce внутри или у границы периметра; назначение даёт ESAs прямые надзорные права | EBA ⧉ |
| Надзорные приоритеты ЕЦБ на 2026-28 прямо называют сбои в облаке | Моделируемые надзорные сценарии проверяют способность выдержать продолжительный отказ назначенного КППТС | Банковский надзор ЕЦБ ⧉ |
| TIBER-EU согласован со Статьёй 26 DORA | Объём TLPT покрывает критические / важные функции, включая сервисы в облаке | ЕЦБ TIBER-EU ⧉ |
| Руководящие принципы EBA по аутсорсингу (EBA/GL/2019/02) стыкуются со Статьёй 28 DORA | Существенное присутствие (¶64), оценка заменяемости (¶81), стратегия выхода (¶113-117) — параграфы, которые надзор реально проверяет | EBA ⧉ |
| Проект Схемы облачных услуг ЕС (EUCS) продвигается | Будущая схема сертификации суверенного облака в рамках Акта о кибербезопасности ЕС; проект опубликован ENISA | ENISA EUCS ⧉ |
Инженерия платформы: пять именованных примитивов #
Зрелость облачно изначально банкинга в 2026 году сводится к пяти инженерным примитивам, которые стыкуются и производят надзорные доказательства со скоростью конвейера развёртывания. Отсутствие любого из них — готовый повод для надзорного замечания.
1. Проторённые маршруты на Kubernetes #
Каждая КВФ работает на управляемой Kubernetes-платформе — EKS, AKS, GKE или OpenShift у назначенного КППТС, либо альтернативе с управлением от поставщика. Команда платформы поддерживает единый «золотой» шаблон кластера с контролируемыми отклонениями: узлы из задокументированного базового образа; изоляция по неймспейсам на команду; профиль pod-security-standards-restricted; сетевые политики; инжекция service mesh (Istio или Linkerd) для межсервисной аутентификации и наблюдаемости. Новые сервисы попадают на проторённый маршрут через шаблонизированный процесс онбординга, который порождает запись реестра по Статье 8 как артефакт развёртывания.
2. Портал разработчика в стиле Backstage #
Центральный портал разработчика — открытый Backstage ⧉ от Spotify в качестве референсной реализации, с рядом корпоративных альтернатив — служит системой регистрации того, что и где работает. Каталог перечисляет каждый сервис, владельца, зависимость, классификацию критичности, ранбук, дежурную ротацию. Портал стыкуется с реестром по Статье 8: каждая запись каталога отображается на запись реестра; записи без ссылок на реестр приводят к падению CI; записи реестра без присутствия в каталоге запускают опережающие надзор оповещения.
3. Развёртывание через GitOps на ArgoCD или Flux #
Продакшн-развёртывание идёт через GitOps-контроллер — стандартом продакшна в 2026 году является ArgoCD или Flux, — который согласует версионированное в Git декларативное состояние с работающим кластером. Ручной kubectl apply отключён; единственный путь в продакшн — слитый pull request. Git-репозиторий — это журнал аудита; на надзорный запрос «покажите конфигурацию сервиса X на дату Y» возвращается Git-тег, а не скриншот.
4. Open Policy Agent на этапе допуска #
Open Policy Agent (OPA) встроен в цепочку допуска кластера и применяет политику платформы: соответствие профилю pod-security, происхождение образов, лимиты ресурсов, наличие сетевой политики, репликация, соответствующая уровню критичности, размещение в суб-регионе под ограничениями суверенного облака. Политики версионируются в Git и проходят change-management вместе с конфигурациями сервисов. Отклонённые развёртывания производят пригодные к ревью обоснования, которые подпитывают пакет доказательств change-management.
5. OpenTelemetry сквозного покрытия #
Каждый сервис эмитирует трассы, метрики и логи OpenTelemetry. Команда платформы поддерживает централизованный конвейер наблюдаемости — обычно Tempo или Jaeger для трасс, Prometheus для метрик, Loki или OpenSearch для логов, — который показывает сквозное здоровье КВФ, карту зависимостей и входные данные для классификации инцидентов. 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» для основной массы рабочих нагрузок, опцию суверенного облака для отдельных потоков высокой чувствительности (например, системы кейс-менеджмента ПОД / санкций, обрабатывающие персональные данные резидентов ЕС) и путь резервной заменяемости, тестируемый ежегодно в рамках Статьи 28 DORA.
Протестированное исполнение выхода #
Параграфы 113-117 EBA/GL/2019/02 ⧉ — это положения о стратегии выхода. Текст прямо формулирует требования: «Учреждения и платёжные учреждения должны обеспечить возможность выхода из договорённостей об аутсорсинге без неоправданного нарушения своей деятельности… Стратегии выхода также должны быть задокументированы и протестированы в рамках регулярных пересмотров договорённостей об аутсорсинге».
Надзорное ожидание в 2026 году — ежегодное сквозное тестирование исполнения выхода для каждой КВФ, зависящей от назначенного КППТС. Настольных учений и обзоров документов недостаточно. Тест должен производить:
- Измерение времени восстановления: фактическое прошедшее время от объявления выхода до восстановления рабочей нагрузки у альтернативного поставщика — против целевого RTO из BIA.
- Доказательства переносимости данных: протестированный экспорт данных из основной среды, проверенный против пути импорта у целевого поставщика, с доказательствами сверки.
- Функциональная эквивалентность: рабочая нагрузка, протестированная у альтернативного поставщика с эквивалентными SLO.
- Доказательства стоимости: задокументированная стоимость исполнения выхода против предположения о стоимости восстановления в планировании непрерывности учреждения.
Первая попытка сквозного тестирования выхода по КВФ обычно вскрывает разрыв в 5-10× между документированным и фактическим RTO. Закрытие этого разрыва — инженерная работа на месяцы. Банки, обнаруживающие это в ходе надзорной проверки, а не в собственном ежегодном цикле тестирования, получают цикл замечаний Q3, которого могли бы избежать.
Цели RTO / RPO из инвентаризации КВФ #
Каждая критическая или важная функция отображается на уровневую классификацию, выведенную из анализа влияния на бизнес учреждения. Уровень задаёт цели RTO и RPO, которые команда инженерии платформы берёт на себя обязательство обеспечить.
| Уровень | Примеры | RTO | RPO |
|---|---|---|---|
| Уровень 1 (критически важно для миссии) | Подключение к RTGS (CHAPS / T2 / Fedwire), авторизация розничных платежей, аутентификация клиентов в цифровых каналах | 2 часа | 15 минут |
| Уровень 2 (критично) | Скрининг ПОД / санкций, конвейеры обнаружения мошенничества, авторизация банкоматов, пакетная обработка платежей | 4 часа | 1 час |
| Уровень 3 (важно) | Отчётность и регуляторная подача, клиентские базы знаний, платформы внутренней коллаборации | 24 часа | 4 часа |
| Уровень 4 (некритично) | Внутренние HR-системы, маркетинговый инструментарий, отчётность не для клиентов | 72 часа | 24 часа |
Эти цифры иллюстративны — собственный BIA учреждения даёт свои. Поставляемый результат инженерии платформы — регрессионно проверенная способность достигать целей из BIA, подтверждённая автоматизированным тестированием аварийного восстановления по каждому сервису и валидированная ежегодным тестом исполнения выхода для КВФ, зависящих от КППТС.
Что это означает по типам банков #
Глобально системно значимые банки #
Сложная задача — масштаб по бизнес-линиям: тысячи сервисов, сотни КВФ, множественные экспозиции к назначенным КППТС по продуктам, юрисдикциям и профилям устойчивости. Инвестиция — это центральная способность инженерии платформы (Kubernetes-проторённые маршруты, портал Backstage, GitOps, OPA, OTel), которая производит сверку реестра по Статье 8, карту концентрации КППТС и способность к исполнению выхода по каждой КВФ без штучных построений в каждой бизнес-линии.
Универсальные и средние банки #
Инвестиция в инженерию платформы оправдана на этом уровне, но объём ограничен: выберите две-три КВФ наивысшей критичности, постройте вокруг них шаблон проторённого маршрута, примите, что унаследованный ландшафт продолжает работать на существующих контролях в среднесрочной перспективе. Надзорное позиционирование важнее ширины платформы — способность доказать целостность реестра по Статье 8 DORA и протестированный выход для трёх верхних КВФ закрывает первичные опасения надзора.
Региональные и более мелкие банки #
Выбор вендора предпочтительнее внутренней разработки. Возьмите поставщика банковской платформы с задокументированной Kubernetes-нативной архитектурой, встроенной интеграцией с реестром по Статье 8 и ясными обязательствами по договорному содержанию по Статье 28 DORA. Внутренняя инженерная способность — это конфигурирование, мониторинг и реагирование на инциденты, а не построение платформы.
Финтехи, ПСП и SaaS-провайдеры для банков #
Продуктовый вопрос для вендоров, продающих в банки ЕС в 2026 году, — производит ли платформа записи реестра по Статье 8 и договорное содержание по Статье 28 DORA, которые нужны функции комплаенс банка. Вендоры со структурированными выходами выигрывают корпоративные сделки; вендоры с PDF-шаблонами проигрывают конкурентам со структурированным JSON.
Заключение #
Облачная устойчивость по DORA — в стадии аудита. Решения по инженерии платформы, принятые в 2024-2025 годах, и есть то, что разбирает надзорный цикл 2026. Учреждения, которые в 2026-2028 годах будут выглядеть убедительно для ЕЦБ и EBA, — это те, у кого Kubernetes-проторённые маршруты с порталами в стиле Backstage и развёртывание через GitOps под допуском Open Policy Agent с OpenTelemetry сквозного покрытия — производящие доказательства реестра по Статье 8 как артефакт развёртывания и доказательства протестированного исполнения выхода как ежегодный цикл, а не как ответ на запрос надзора.
Учреждения, которые этих инвестиций не сделали, выяснят, способна ли их вторая линия комплаенс впитать первый круг надзорных замечаний до прихода второго.
Измеряйте платформу так же, как измеряете любую операционную программу: покрытие проторёнными маршрутами, доля сверки реестра, балл концентрации КППТС, протестированное время выхода против целевого RTO, среднее время классификации по Статье 18, доля закрытых находок TLPT. Доказательства со скоростью конвейера; пакеты документов — только когда их запрашивает надзорный орган.
Часто задаваемые вопросы #
Облачная устойчивость по DORA всё ещё в стадии подготовки в 2026 году?
Нет. DORA в активном применении с 17 января 2025 года. Режим назначения КППТС по Статьям 28-44 раскрывается на горизонте 2025-2026. Замечания по экзаменам ЕЦБ по управлению рисками ИКТ по Статье 6 и целостности реестра по Статье 8 поступили в Q4 2025 в нескольких учреждениях первого эшелона. Надзорный вопрос 2026 года — это специфичные для учреждения экзаменационные доказательства, а не регуляторная готовность.
Какие облачные провайдеры назначены КППТС?
ESAs публикуют решения о назначении на своих сайтах. В число учреждений внутри или у границы периметра в 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 сквозного покрытия. Доказательства со скоростью конвейера, а не к моменту экзамена.
Как часто нужно тестировать исполнение выхода?
Ежегодное сквозное тестирование исполнения выхода по каждой КВФ, зависящей от назначенного КППТС. Настольных учений и обзоров документов недостаточно. Тест должен производить время восстановления, доказательства переносимости данных, функциональную эквивалентность и доказательства стоимости — измеренные против целей RTO и RPO из BIA.
Источники #
- Европейский Союз, (2022). Регламент (ЕС) 2022/2554 — Закон о цифровой операционной устойчивости (DORA) ⧉.
- European Banking Authority, (2019). EBA/GL/2019/02 — Руководящие принципы по договорённостям об аутсорсинге ⧉.
- European Banking Authority, (2026). Закон о цифровой операционной устойчивости ⧉.
- Европейские надзорные органы, (2024). Финальный отчёт по ITS о Реестре информации в рамках DORA ⧉.
- Банковский надзор ЕЦБ, (2025). Надзорные приоритеты 2026-28 ⧉.
- Европейский центральный банк, (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 ⧉.
Последняя проверка .
Последняя проверка .