Кто на самом деле управляет Cloud Native-платформой: архитектура нескольких плоскостей
Разговор о контроле над облачной инфраструктурой обычно начинают с двух вопросов: в какой стране размещаются рабочие нагрузки и где хранятся данные. Однако одного выбора региона недостаточно. Для оценки цифрового суверенитета важно понимать, кто управляет платформой, где находится её состояние, какие компоненты имеют доступ к ключам и административным учётным данным, а также можно ли продолжить работу без конкретного поставщика.
Иными словами, география - лишь один из элементов общей картины. Не менее значимы устройство платформы, границы между её компонентами и направление взаимодействия между кластерами.
Какие вопросы задают аудиторы
Под влиянием требований, связанных с EU Data Act, NIS2, DORA и британским законодательством о доступе к данным, платформенным командам приходится доказывать не только место выполнения приложений. Необходимо показать, как система эксплуатируется, кто отвечает за её безопасность, где обрабатываются логи и метаданные и каким образом защищена плоскость управления.
На практике проверка сводится к нескольким вопросам:
- В какой юрисдикции находится каждый компонент, способный получить доступ к данным арендатора?
- Можно ли продолжить эксплуатацию системы, если управляемый сервис поставщика станет недоступен?
- Есть ли у внешних организаций доступ к ключам шифрования, состоянию кластера или административным аккаунтам?
- Потребуется ли переписывать приложение при смене облачного провайдера, оборудования или региона?
Эти вопросы лишь частично связаны с физическим расположением данных. В центре внимания находятся контроль, состояние системы и права доступа к ним.
Почему единый кластер усложняет контроль
В общей Kubernetes-инфраструктуре несколько арендаторов используют один API-сервер, единое хранилище etcd, общие контроллеры и admission-вебхуки. Даже при корректной настройке пространств имён, политик и ролей такая модель может оказаться недостаточно прозрачной для аудита.
Проблема не обязательно заключается в наличии уязвимости. Сложность возникает из-за размытых границ ответственности: где заканчивается инфраструктура одного арендатора и начинаются общие механизмы управления? Кто потенциально может изменить состояние всей среды? Где хранятся критически важные секреты и кто способен их прочитать?
Подход "кластер на тенанта" делает границу очевиднее. Каждый клиент получает собственную плоскость управления, отдельный API-сервер и собственное состояние. Это упрощает изоляцию, аудит и доказательство независимости арендаторов, хотя увеличивает расходы на сопровождение.
Модель нескольких плоскостей
Более масштабный вариант - разделить платформу на несколько специализированных кластеров. Каждый из них отвечает за отдельную функцию и имеет собственный жизненный цикл, правила масштабирования и границу безопасности.
В такой архитектуре можно выделить следующие плоскости:
Плоскость управления хранит желаемое состояние платформы через декларативные API и запускает контроллеры, которые приводят фактическую конфигурацию к заданной. Она координирует работу системы, но не размещает пользовательские приложения.
Плоскость данных состоит из одного или нескольких Kubernetes-кластеров, где реально выполняются сервисы арендаторов. У каждого кластера собственные API-сервер и хранилище состояния. При необходимости отдельные тенанты могут получать самостоятельные кластеры внутри этой категории.
Плоскость наблюдаемости отвечает за сбор, хранение и предоставление логов, метрик и трассировок. Её изоляция особенно важна, поскольку телеметрия нередко содержит персональные сведения, токены, параметры запросов и внутренние идентификаторы.
Плоскость рабочих процессов запускает CI/CD, GitOps-процессы, сборку контейнеров, тестирование и доставку конфигураций. Размещение этих функций отдельно позволяет контролировать, кто способен изменить код или состояние рабочей среды.
Плоскость взаимодействия предоставляет разработчикам портал, CLI, программные интерфейсы и другие точки доступа к платформе. Она должна передавать запросы в систему управления, но не получать избыточные полномочия напрямую.
Почему важны направления соединений
Само наличие нескольких кластеров ещё не гарантирует суверенитет. Критическое значение имеет то, как они взаимодействуют. Безопаснее, когда плоскость управления отправляет декларативные изменения в плоскости исполнения, а не подключается к ним с широкими административными правами.
Такая схема уменьшает число обратных каналов и ограничивает потенциальное перемещение злоумышленника. Плоскость данных не должна без необходимости инициировать соединения к управляющей инфраструктуре, а наблюдаемость обязана получать только тот объём информации, который нужен для мониторинга.
Каждый канал следует описывать с точки зрения нескольких параметров: кто инициирует соединение, какие данные передаются, какие полномочия используются, где хранятся секреты и что произойдёт при разрыве связи.
Платформа как декларативная конфигурация
Один из главных эффектов такой топологии - возможность представить платформу в виде набора декларативных описаний. В них фиксируются политики, параметры кластеров, правила размещения, настройки безопасности и зависимости между компонентами.
Это даёт несколько преимуществ. Во-первых, состояние можно проверять автоматически. Во-вторых, конфигурацию проще версионировать и восстанавливать. В-третьих, перенос между инфраструктурами становится менее зависимым от ручных операций.
Однако декларативность не означает автоматическую независимость от поставщика. Если система управления использует закрытые API, уникальные форматы или недоступные сервисы, экспорт конфигурации может оказаться практически бесполезным. Поэтому важно заранее определить, какие элементы являются стандартными, а какие привязаны к конкретному облаку.
Как проверить архитектуру на практике
Для аудита полезно составить карту всех плоскостей и указать для каждой:
- юридическую юрисдикцию;
- владельца и оператора;
- место хранения состояния;
- используемые ключи и систему управления секретами;
- административные роли;
- входящие и исходящие соединения;
- порядок восстановления после отказа;
- возможность автономной работы;
- процедуру переноса на другую инфраструктуру.
Отдельно необходимо проверить резервные копии. Даже если рабочая нагрузка находится в нужной стране, резервы, журналы аудита или снимки etcd могут автоматически отправляться в другой регион. Такая деталь способна изменить итоговую оценку соответствия требованиям.
Мобильность без переписывания приложений
Хорошая архитектура должна переносить не только контейнеры, но и эксплуатационную модель. Если при смене провайдера приходится заново разрабатывать пайплайны, политики, сетевые настройки и механизмы наблюдаемости, формальная контейнеризация не обеспечивает настоящей мобильности.
Для снижения зависимости применяют стандартные Kubernetes-объекты, открытые форматы конфигурации, независимые системы сборки и доставку через GitOps. При этом полностью избежать облачной специфики невозможно: базы данных, балансировщики, хранилища и сетевые сервисы часто используют уникальные возможности провайдера. Их следует изолировать за понятными интерфейсами и заранее описать процедуру замены.
Что даёт топология нескольких плоскостей
Разделение платформы помогает:
- чётче определить границы ответственности;
- ограничить доступ управляющих компонентов;
- изолировать состояние разных арендаторов;
- локализовать последствия инцидента;
- упростить аудит и подтверждение юрисдикции;
- повысить переносимость рабочих нагрузок;
- независимо масштабировать управление, исполнение и наблюдаемость.
Но такая модель не решает все проблемы. Она не заменяет шифрование, управление ключами, контроль привилегий, безопасную разработку и регулярное тестирование восстановления. Кроме того, большое количество кластеров увеличивает операционную сложность, требования к автоматизации и стоимость сопровождения.
Итог
Контроль над Cloud Native-платформой определяется не только местом размещения серверов. Нужно понимать, где находится состояние системы, кто управляет её компонентами, какие соединения существуют между плоскостями и может ли организация продолжить работу без внешнего сервиса.
Архитектура с отдельными плоскостями управления, исполнения, наблюдаемости, workflow и взаимодействия позволяет сделать эти границы явными. В сочетании с декларативной конфигурацией, минимальными правами, независимым управлением ключами и регулярными проверками переносимости она превращает требования цифрового суверенитета из абстрактных формулировок в проверяемые инженерные свойства.