Если говорить о том аспекте DORA, который определяет суть большинства дискуссий вокруг платформ - а именно, о зависимости от единственного поставщика ИКТ-услуг, - то Cozystack представляет собой едва ли не лучшее инфраструктурное решение. Это программное обеспечение с открытым исходным кодом по лицензии Apache 2.0, работающее на вашем собственном оборудовании, и уход от него означает перенос стандартных объектов Kubernetes и виртуальных машин, а не распутывание проприетарного формата. Стратегия выхода, которую можно отрепетировать, лучше, чем пункт договора, обещающий содействие.
Со стороной устойчивости всё также хорошо: реплицированное хранилище между узлами, живая миграция между ними, декларативное состояние, которое платформа непрерывно восстанавливает, топологии с несколькими центрами обработки данных как обычная форма развёртывания, резервные копии, зашифрованные по умолчанию. Эта страница разбирает всё это и отмечает немногочисленные места, где нужно что-то настроить, а не получить в готовом виде.
Чего платформа не может сделать — это принять на себя обязательство. Закон о цифровой операционной устойчивости (Digital Operational Resilience Act) — Регламент (ЕС) 2022/2554 — действует с 17 января 2025 года и обязывает категории финансовых организаций, перечисленные в статье 2: банки, страховщики, инвестиционные компании, платёжные и электронно-денежные учреждения, поставщики услуг с криптоактивами и другие. Поставщики ИКТ-услуг третьих сторон не входят в область применения напрямую; небольшое число из них назначаются критическими Европейскими надзорными органами по статье 31 и подпадают под режим надзора ЕС (EU Oversight Framework) с ведущим надзорным органом (Lead Overseer) — это иной режим, отличный от надзора компетентного органа, с которым сталкиваются финансовые организации.
DORA посвящает целую главу риску ИКТ-третьих сторон: реестр информации, договорные требования, риск концентрации, стратегии выхода и право на аудит. Регуляторов это заботит, потому что финансовая организация, не способная уйти от поставщика, не имеет реального контроля над собственной устойчивостью.
Здесь важны три свойства. Ни одно из них не является функцией, которую вы включаете; каждое следует из того, как платформа построена и лицензирована.
Исходный код открыт, по лицензии Apache 2.0. Договорная непрерывность не зависит от выживания одного поставщика, и код может быть проверен вами или третьей стороной без запроса разрешения.
Работает на вашем собственном оборудовании. Никакого control plane в чужом аккаунте, никакого поставщика с постоянным доступом, необходимым для работы платформы, никакой зависимости от доступности внешнего сервиса. Что вы хостите, то вы и контролируете.
Выход возможен на практике, а не только на бумаге. Рабочие нагрузки — это объекты Kubernetes и виртуальные машины в стандартных форматах; никакой проприетарной инкапсуляции распутывать не нужно. План выхода, который можно отрепетировать, стоит больше для регулятора, чем пункт договора, обещающий содействие.
Ничто из этого не освобождает вас от ведения реестра информации, требуемого статьёй 28(3), от наличия стратегии выхода по статье 28(8), или от договоров, содержащих ключевые положения статьи 30 DORA — это другая статья 30, не та, что в GDPR. Это лишь облегчает написание этих документов правдиво.
DORA ожидает, что ИКТ-системы выдерживают сбои и восстанавливаются после них, и что это проверяется, а не принимается на веру.
Реплицированное хранилище — там, где этого требует StorageClass. LINSTOR размещает тома с репликацией DRBD между узлами, поэтому реплицированный том переживает потерю узла, хранившего одну из его копий. Репликация — это свойство StorageClass, а не платформы в целом — существуют локальные, нереплицируемые классы, и они являются правильным выбором для некоторых рабочих нагрузок, — так что проверьте, какой класс на самом деле использует каждая критическая или важная функция. Отдельный массив хранения не требуется в любом случае.
Живая миграция. Виртуальные машины перемещаются между узлами без остановки, что превращает плановое обслуживание из простоя в обычную операцию.
Декларативное состояние, непрерывно согласовываемое. Машины и службы описываются как манифесты, и платформа работает над тем, чтобы реальность соответствовала описанию. Убейте рабочую нагрузку напрямую — она вернётся, потому что описание не изменилось.
Растянутые кластеры между площадками. Топологии с несколькими центрами обработки данных являются обычной формой развёртывания, а не экзотической, что важно, если ваши требования к устойчивости называют географическое разделение.
Стоит точно указать, что не предоставляется. Нет автоматического отказоустойчивого переключения виртуальных машин после незапланированной потери узла того типа, который дают специализированные продукты высокой доступности. Обработка состояния здоровья узлов и политики перезапуска существуют и могут быть объединены в процедуру отказоустойчивости, но это работа по настройке и репетиции, а не переключатель.
Velero поставляется вместе с платформой для плановых резервных копий, снапшотов томов, резервных копий виртуальных машин и состояния кластера, а данные резервных копий шифруются в объектном хранилище по умолчанию с помощью загрузчика kopia.
Где будут храниться эти резервные копии — решение, которое нужно принять до оценки, а не
после. Резервные копии, управляемые платформой, по умолчанию попадают в общий бакет
cozy-backups в tenant-root, разделённый между тенантами по пути объекта. Статья 12(2)
ожидает, что восстановление выполняется на системах, физически и логически отделённых от
источника, а статья 12(3) ожидает, что системы резервного копирования не подключены напрямую
к основной системе — бакет внутри защищаемого кластера не соответствует ни тому, ни другому.
Направьте BackupClass на хранилище за пределами кластера, с собственными учётными данными и
собственным ключом, и укажите это в политике резервного копирования, которую требует статья
12(1).
Акцент регламента не на наличии резервных копий, а на возможности восстановления. Отрепетируйте восстановление с заданными целевым временем восстановления и целевой точкой восстановления, зафиксируйте, что было реально достигнуто, и храните эту запись. Измеренное время восстановления — это доказательство; оценка — нет.
DORA требует, чтобы инциденты обнаруживались, классифицировались и — для крупных — сообщались компетентному органу в короткие сроки. Это работает только если существует базовая запись.
Платформа поставляется со сбором метрик, агрегацией журналов, оповещениями и панелями мониторинга, а API-сервер Kubernetes записывает журнал аудита по политике, которую вы задаёте. Установите две вещи осознанно. Сначала срок хранения: по умолчанию на рассматриваемом кластере это тридцать дней — короче, чем ожидает финансовый надзорный орган для записей, касающихся критических или важных функций. Затем политику аудита — по ресурсам, не повышайте всё до полной фиксации запросов и ответов, что записывает секреты и персональные данные в журнал и покупает проблему GDPR ради решения проблемы DORA.
Рекомендации по безопасности для платформы публикуются открыто, включая оценки уязвимостей, которые в итоге не затрагивают платформу. Эта публичная запись прямо применима в частях threat-intelligence и управления уязвимостями структуры управления ИКТ-риском.
DORA ожидает программу тестирования цифровой операционной устойчивости по главе IV и угроз-ориентированное тестирование на проникновение (TLPT) по статье 26 для тех организаций, которые их компетентный орган определил как подпадающих под это требование — назначение на основе профиля риска и системной значимости, а не категория, которую можно определить по собственному балансу.
Два свойства платформы помогают общей программе. Тенант даёт вам изолированное место для запуска деструктивных тестов на реалистичной копии. И поскольку среды описаны как манифесты, среда под тестом может быть воссоздана в точности, что делает результат теста осмысленным при повторном запуске.
TLPT — это другое упражнение, и различие важно: тесты по статье 26 выполняются на живых продакшен-системах, поддерживающих критические или важные функции, поэтому копия в тенанте не заменяет их. Там, где платформа эксплуатируется для вас, или поддерживает критическую или важную функцию, задействованные поставщики ИКТ-услуг третьих сторон попадают в область такого теста и должны быть согласованы заранее.
Страница CIS Benchmark показывает один такой тест, выполненный на живом кластере, вместе с рассуждениями, которые превращают необработанный отчёт в то, чем может воспользоваться аудитор.
Управление остаётся за руководящим органом и не может быть делегировано поставщику: структура управления ИКТ-риском, реестр информации, классификация инцидентов и отчётность в сроки, установленные регламентом, программа тестирования цифровой операционной устойчивости, договорные отношения с поставщиками и сама стратегия выхода.
Платформа может сделать каждую из этих задач дешевле в исполнении. Она не может взять их на себя.
Этот вопрос неприменим к платформе. DORA обязывает финансовые организации; платформы — часть ИКТ-инфраструктуры, которой управляют эти организации. Cozystack предоставляет репликацию, живую миграцию, резервное копирование и восстановление, наблюдаемость, журналирование аудита и — что наиболее полезно для главы V — архитектуру без зависимости от поставщика, которую нужно распутывать.
Самостоятельный хостинг убирает поставщика платформы из критического пути — часто самого крупного компонента этого риска. Поставщики оборудования, операторы центров обработки данных и любой интегратор, с которым вы заключаете договор, остаются третьими сторонами и должны быть в реестре информации.
Реестр по статье 28(3) фиксирует договорные отношения по использованию ИКТ-услуг. Загрузка и самостоятельный хостинг программного обеспечения по лицензии Apache 2.0 не создаёт договорных отношений, поэтому нет контрагента, которого нужно указать, и нет ничего о самом проекте, что нужно регистрировать. В момент, когда вы покупаете поддержку, хостинг или интеграцию вокруг него, этот поставщик становится поставщиком ИКТ-услуг третьей стороны по статье 3(19) и должен быть в реестре, с указанием функции, которую он поддерживает, и того, является ли эта функция критической или важной. Уточните трактовку у вашего компетентного органа — надзорная практика по компонентам с открытым исходным кодом не единообразна.
Статья 30(3)(e) — это договорное право на доступ, инспекцию и аудит для вас и для вашего компетентного органа, применяемое в отношении поставщика. Без поставщика в цепочке нет договора, который бы это несло, и инспекция платформы означает чтение публичного исходного кода и запуск проверок на своём собственном кластере. Там, где вы заключаете договор с оператором, права на доступ и аудит — а также положения о выходе и переходе по статье 30(3)(f) — должны быть в этом договоре, а не в утверждении о программном обеспечении.
Да. Запускайте их в отдельном тенанте, изолированном сетевой политикой от всего остального, и воссоздавайте среду из манифестов между запусками.
Эта страница описывает Cozystack v1.6, наблюдаемый на эталонном кластере в августе 2026 года, и носит информационный характер. Это не юридическая консультация, не оценка и не заявление о том, что какая-либо конфигурация удовлетворяет компетентный орган. Регламент (ЕС) 2022/2554 применяется к определённым категориям финансовых организаций и их критическим поставщикам ИКТ-услуг; применяется ли он к вам и в каком качестве — вопрос для вашего собственного юридического консультанта.