Модель безопасности
Модель безопасности Gateway позволяет централизовать инфраструктурные операции, не создавая ложного ощущения, что единая консоль отменяет необходимость защищать хосты, сети, идентичности и резервные копии. Владелец платформы отвечает за размещение Gateway и управляемых нод, владелец безопасности определяет политику идентичностей и секретов, а владельцы ресурсов согласуют доступ к своим рабочим нагрузкам и данным.
Gateway рассматривает управляемые хосты и администраторов как значимые границы доверия. Исходящая регистрация демона, идентичности PKI, области ресурсов, аудитируемые операции и ограниченные роли демонов сокращают использование многоразовых учётных данных и зависимость от прямого доступа к оболочке.
Безопасное развёртывание требует явных полномочий, раздельных учётных данных для разных границ доверия, проверки изменений фактическим владельцем среды выполнения и отсутствия незаметного перехода на менее безопасный путь при сбое. Доступность по сети не равна авторизации, а видимость сохранённого инвентаря не даёт права изменять ресурс.
Основные принципы:
- одноразовая регистрация вместо многоразовых токенов нод;
- mTLS и закреплённая идентичность Gateway для управляемого транспорта;
- явные области ресурсов и отдельные права на раскрытие, экспорт и подключение каталогов;
- шифрование секретов в хранилище и маскирование вывода по умолчанию;
- исключение внутренних Containers, принадлежащих Gateway, из пользовательских API жизненного цикла;
- отдельные идентичности приложений для привязок управляемых баз данных;
- безопасный отказ, когда невозможно подтвердить владение, Entitlement, состояние ноды или совместимость поставщика;
- неизменяемая атрибуция аудита после изменений жизненного цикла учётной записи.
Gateway не является средством усиления защиты хоста, менеджером межсетевого экрана, универсальным VPN или заменой встроенного резервного копирования баз данных. Защищайте базовые операционные системы и сети независимо.
Границы доверия
Заголовок раздела «Границы доверия»| Граница | Ответственность за безопасность |
|---|---|
| Хост Gateway | Защищать секреты приложения, доступ к базе данных, среду выполнения Container, постоянные тома и административный доступ |
| PostgreSQL и Redis | Сохранять приватными, аутентифицированными, резервируемыми и доступными только службам Gateway |
| Relay | Сохранять идентичность службы, подписанную политику, путь авторизации базы данных и владение публичным 9443/tcp |
| Управляемая нода | Защищать идентичность демона, службу systemd, локальную среду выполнения, хранилище и права конкретной роли |
| Build Worker | Изолировать недоверенные сборки исходного кода от обычных рабочих нагрузок и управляющих адресов хоста |
| Нода Ingress | Защищать закрытые ключи TLS, конфигурацию nginx, журналы и публичный трафик |
| Нода баз данных | Защищать учётные данные владельца, образы хранилища, материалы Database CA и администрирование движка |
| Внешний поставщик | Применять предусмотренные поставщиком меры защиты учётных данных, хранения, доступности и сети |
Администраторы и любой пользователь, способный управлять сокетом Docker на хосте Gateway, имеют высокий уровень доверия. Внутренние Containers Gateway скрыты и защищены от обычных пользовательских API жизненного цикла, но это не превращает доступ к Docker на уровне хоста в недоверенную границу.
Идентичность и авторизация
Заголовок раздела «Идентичность и авторизация»Пользовательские сеансы, токены API, OAuth, MCP, сертификаты демонов, идентичности служб, субъекты привязок баз данных, токены журналирования и токены Gateway Inference относятся к разным семействам учётных данных и не взаимозаменяемы. Серверная часть повторно проверяет области, владение ресурсом, Entitlements и текущее состояние, даже если UI скрывает действие.
Права с областью ресурса ограничивают объекты, которые пользователь может видеть или изменять. Для чувствительных действий — раскрытия учётных данных, экспорта закрытого ключа, доступа к файлам хоста или консоли и изменения секрета — нужны отдельные полномочия сверх обычного чтения.
Обработка секретов
Заголовок раздела «Обработка секретов»Секреты зашифрованы в хранилище и маскируются в обычных ответах. Значения, доступные только для записи, следует заменять, а не извлекать. Храните главные ключи отдельно от резервных копий базы данных, удаляйте чувствительные данные из журналов и снимков экрана и не передавайте учётные данные в аргументах команд или URL репозитория.
Рабочие нагрузки управляемых баз данных получают отдельные идентичности привязок, а не учётные данные владельца. Целевой Docker-демон владеет приватной службой приёма соединений и разрешает в сети привязки только предусмотренную стабильную идентичность рабочей нагрузки.
Примеры fail-closed
Заголовок раздела «Примеры fail-closed»Gateway отклоняет или откладывает операцию, если не может подтвердить текущее владение, актуальную Capability, о которой сообщила нода, Entitlement плана, совместимость поставщика и модели, происхождение подписанного обновления, идентичность сетевого источника или необходимую авторизацию. Сохранённый инвентарь может оставаться видимым для диагностики, но не разрешает изменение.
Сбой доступности нельзя «исправлять» созданием анонимных служб приёма соединений, отключением проверки сертификатов, публикацией приватных портов или копированием учётных данных владельца в рабочие нагрузки.
Ограничения безопасности
Заголовок раздела «Ограничения безопасности»Gateway не может защитить скомпрометированное устройство администратора, вредоносного пользователя root на хосте, владельца неограниченного сокета Docker, скомпрометированного внешнего поставщика идентификации или данные, намеренно экспортированные авторизованным пользователем. Используйте независимое усиление защиты хоста, сегментацию сети, защиту устройств, резервное копирование и организационные меры.
Чек-лист решений безопасности
Заголовок раздела «Чек-лист решений безопасности»До внедрения Gateway в рабочей среде определите, кто управляет хостом Gateway, Relay, каждым управляемым хостом, внешним поставщиком идентификации, поставщиками систем управления исходным кодом, DNS, электронной почтой, поставщиками AI и хранилищем резервных копий. Зафиксируйте, какие стороны могут получить открытые данные приложений или учётные данные. Если один человек или система контролирует несколько границ, явно зафиксируйте эту концентрацию полномочий, а не предполагайте, что области ресурсов продукта её устранили.
Для каждой новой возможности ответьте на четыре вопроса:
- К каким данным или инфраструктуре она получает доступ?
- Какие учётные данные разрешают этот доступ и где они хранятся?
- Какие свидетельства аудита или Task подтверждают результат?
- Что продолжает работать, а что должно безопасно отказать при недоступности зависимости?
Пересматривайте модель после существенных изменений топологии, идентичности, поставщика или Entitlement. Проект, согласованный для одного Ingress и одной приватной базы данных, может перестать соответствовать требованиям после добавления Build Workers, публичного доступа к базе, внешних поставщиков AI или межкомандной автоматизации.
Проверки оператора
Заголовок раздела «Проверки оператора»Проверяйте отказ так же намеренно, как успех: используйте пользователя без нужной области, отозванный токен, ноду с устаревшими данными Capability, неподписанное или несовпадающее обновление, рабочую нагрузку без идентичности привязки и приватный адрес назначения вне политики исходящего трафика.
Сигналом является неожиданно разрешённая операция или отказ разрешённого пути. Определите владельца границы доверия, откройте соответствующий ресурс и Task, сопоставьте запись аудита и код ошибки, затем сохраните ограниченные журналы. Безопасное следующее действие — отозвать временный доступ или остановить изменение на затронутой границе и исправить подтверждённую политику либо зависимость; не ослабляйте соседние границы. Меры безопасности, которые ни разу не проверялись при сбое, следует считать предположениями.