Модель безопасности
Модель безопасности Opfield позволяет централизовать инфраструктурные операции, не создавая ложного ощущения, что единая консоль отменяет необходимость защищать хосты, сети, идентичности и резервные копии. Владелец платформы отвечает за размещение Opfield и управляемых нод, владелец безопасности определяет политику идентичностей и секретов, а владельцы ресурсов согласуют доступ к своим рабочим нагрузкам и данным.
Opfield рассматривает управляемые хосты и администраторов как значимые границы доверия. Исходящая регистрация демона, идентичности PKI, области ресурсов, аудитируемые операции и ограниченные роли демонов сокращают использование многоразовых учётных данных и зависимость от прямого доступа к оболочке.
Безопасное развёртывание требует явных полномочий, раздельных учётных данных для разных границ доверия, проверки изменений фактическим владельцем среды выполнения и отсутствия незаметного перехода на менее безопасный путь при сбое. Доступность по сети не равна авторизации, а видимость сохранённого инвентаря не даёт права изменять ресурс.
Основные принципы:
- одноразовая регистрация вместо многоразовых токенов нод;
- mTLS и закреплённая идентичность Opfield для управляемого транспорта;
- явные области ресурсов и отдельные права на раскрытие, экспорт и подключение каталогов;
- шифрование секретов в хранилище и маскирование вывода по умолчанию;
- исключение внутренних Containers, принадлежащих Opfield, из пользовательских API жизненного цикла;
- отдельные идентичности приложений для привязок управляемых баз данных;
- безопасный отказ, когда невозможно подтвердить владение, Entitlement, состояние ноды или совместимость поставщика;
- неизменяемая атрибуция аудита после изменений жизненного цикла учётной записи.
Opfield не является средством усиления защиты хоста, менеджером межсетевого экрана, универсальным VPN или заменой встроенного резервного копирования баз данных. Защищайте базовые операционные системы и сети независимо.
Границы доверия
Заголовок раздела «Границы доверия»| Граница | Ответственность за безопасность |
|---|---|
| Хост Opfield | Защищать секреты приложения, доступ к базе данных, среду выполнения Container, постоянные тома и административный доступ |
| PostgreSQL и Redis | Сохранять приватными, аутентифицированными, резервируемыми и доступными только службам Opfield |
| Relay | Сохранять идентичность службы, подписанную политику, путь авторизации базы данных и владение публичным 9443/tcp |
| Управляемая нода | Защищать идентичность демона, службу systemd, локальную среду выполнения, хранилище и права конкретной роли |
| Build Worker | Изолировать недоверенные сборки исходного кода от обычных рабочих нагрузок и управляющих адресов хоста |
| Нода Ingress | Защищать закрытые ключи TLS, конфигурацию nginx, журналы и публичный трафик |
| Нода хранилища | Защищать учётные данные владельца, образы хранилища, материалы Database CA и администрирование движка |
| Внешний поставщик | Применять предусмотренные поставщиком меры защиты учётных данных, хранения, доступности и сети |
Администраторы и любой пользователь, способный управлять сокетом Docker на хосте Opfield, имеют высокий уровень доверия. Внутренние Containers Opfield скрыты и защищены от обычных пользовательских API жизненного цикла, но это не превращает доступ к Docker на уровне хоста в недоверенную границу.
Идентичность и авторизация
Заголовок раздела «Идентичность и авторизация»Пользовательские сеансы, токены API, OAuth, MCP, сертификаты демонов, идентичности служб, субъекты привязок баз данных, токены журналирования и токены Opfield Inference относятся к разным семействам учётных данных и не взаимозаменяемы. Серверная часть повторно проверяет области, владение ресурсом, Entitlements и текущее состояние, даже если UI скрывает действие.
Права с областью ресурса ограничивают объекты, которые пользователь может видеть или изменять. Для чувствительных действий — раскрытия учётных данных, экспорта закрытого ключа, доступа к файлам хоста или консоли и изменения секрета — нужны отдельные полномочия сверх обычного чтения. Во время имперсонации учётные данные не раскрываются, сеансы консоли ноды и чтение файлов ноды записываются в аудит, а API-токены и ассистент не могут менять способы входа, MFA и сеансы своей учётной записи, выдавать право имперсонации и восстанавливать пользователей в группы с правами шире, чем у вызывающего. AI-ассистент запрашивает подтверждение перед раскрытием или ротацией учётных данных и экспортом закрытых ключей.
Обработка секретов
Заголовок раздела «Обработка секретов»Секреты зашифрованы в хранилище и маскируются в обычных ответах. Значения, доступные только для записи, следует заменять, а не извлекать. Храните главные ключи отдельно от резервных копий базы данных, удаляйте чувствительные данные из журналов и снимков экрана и не передавайте учётные данные в аргументах команд или URL репозитория. Журнал аудита скрывает строки подключения, секретные URL, заголовки вебхуков и значения секретов, а просмотр контейнера, вкладки окружения и экспорт архива никогда не показывают пароли и ключи привязок баз данных и хранилищ.
Рабочие нагрузки управляемых баз данных получают отдельные идентичности привязок, а не учётные данные владельца. Общий коннектор защищённых связей целевой ноды Docker обслуживает каждую привязку в её собственной приватной сети, к которой подключается только привязанная рабочая нагрузка. Связи контейнеров устроены так же: каждая открывает один порт цели, в одном направлении и одному потребителю.
Где хранятся секреты в самостоятельно размещённой установке
Заголовок раздела «Где хранятся секреты в самостоятельно размещённой установке»Любой тариф можно разместить самостоятельно, и такая установка хранит секреты в окружении, которое контролируете вы:
| Материал | Где хранится |
|---|---|
| Учётные данные, которые Opfield хранит для вас: секреты и переменные среды Docker, учётные данные реестров, токены DNS, Cloudflare и хостинг-провайдеров, ключи SSH, секреты OIDC и SMTP, учётные данные баз данных и хранилищ, ключи провайдеров AI и Inference, секреты подписи вебхуков, закрытые ключи центров сертификации и ACME, а также лицензионный ключ, токен установки и код регистрации | Собственная база PostgreSQL установки; значения зашифрованы конвертным шифрованием AES-256-GCM: у каждого значения свой случайный ключ данных, который зашифрован мастер-ключом |
Мастер-ключ (PKI_MASTER_KEY) |
Создаётся на хосте Opfield при установке и хранится в файле .env установки с ограниченными правами доступа; передаётся службам Opfield при запуске и не хранится в базе данных |
| Закрытый ключ TLS самого Opfield | Файл в постоянных данных Opfield на хосте Opfield |
| Идентичность управляемой ноды | Закрытый ключ демона остаётся на этой ноде |
| Ключи TLS управляемых баз данных | Хранилище демона на ноде хранилища, вне образа базы данных |
Любой, кто контролирует хост Opfield, его файл .env или сокет Docker, может получить доступ к этим материалам. Храните резервную копию мастер-ключа отдельно от резервных копий базы данных и никогда не вставляйте содержимое .env в чаты или обращения в поддержку. Состав набора для восстановления описан в разделе Обновления, резервные копии и восстановление.
Что покидает самостоятельно размещённую установку
Заголовок раздела «Что покидает самостоятельно размещённую установку»Opfield сам устанавливает перечисленные ниже исходящие соединения. Всё остальное зависит от настроенных вами интеграций: провайдеров ACME и DNS, систем управления исходным кодом, реестров, провайдеров идентификации, почты, вебхуков, приёмников SIEM и провайдеров AI.
| Назначение | Цель | Передаваемые данные |
|---|---|---|
Служба лицензирования (license.thesqlabs.com) |
Регистрация после первого запуска, контрольные сигналы каждые 15 минут с платным ключом или каждые 30 минут на Community, активация и деактивация ключа, авторизация выпуска перед обновлением и загрузка коммерческого ядра для лицензированных установок | Идентификатор установки, имя установки, версия Opfield, версия схемы Entitlements, токен установки, случайный одноразовый код запроса и идентификаторы закреплённых ключей подписи; одноразовый код регистрации при регистрации, платный ключ при активации, а также целевая версия, идентификатор выпуска и путь к файлу при обновлении. См. Планы и права по тарифу |
Служба обновлений (updates.thesqlabs.com) |
Проверка выпусков при запуске и по умолчанию каждые 4 часа (UPDATE_CHECK_INTERVAL_HOURS), загрузка подписанных выпусков |
Канал выпусков, компонент и текущая версия |
Реестры контейнеров, например ghcr.io |
Загрузка образов выпусков Opfield | Стандартные запросы загрузки образов |
| Службы определения публичного IP-адреса | Определение публичных адресов Opfield и управляемых нод | Стандартные HTTPS-запросы; серверная часть Opfield пропускает определение, если заданы и PUBLIC_IPV4, и PUBLIC_IPV6 |
Скрипт установки обращается только к службе обновлений, реестрам контейнеров и репозиториям пакетов Docker; в службе лицензирования Opfield регистрируется вскоре после первого запуска. Службы лицензирования и обновлений не получают конфигурацию инфраструктуры, содержимое ресурсов, секреты, журналы, запросы к моделям и их ответы. В Opfield нет клиента телеметрии использования или отчётов о сбоях. Если включены AI Workspace или Opfield Inference, запросы отправляются провайдерам моделей, которых настроил администратор, а не Square Labs.
Ответы службы лицензирования — подписанные состояния лицензии. Opfield закрепляет открытые ключи Ed25519 службы и принимает состояние, только если оно подписано для этой установки и этого запроса и выдано не более чем за 15 минут до или после локального времени; неподписанные, поддельные, повторённые и чужие состояния отклоняются, а сохранённые состояния заново проверяются при каждом чтении лицензии. См. Подписанные состояния лицензии.
Примеры fail-closed
Заголовок раздела «Примеры fail-closed»Opfield отклоняет или откладывает операцию, если не может подтвердить текущее владение, актуальную Capability, о которой сообщила нода, Entitlement плана, совместимость поставщика и модели, происхождение подписанного обновления, идентичность сетевого источника или необходимую авторизацию. Сохранённый инвентарь может оставаться видимым для диагностики, но не разрешает изменение.
Сбой доступности нельзя «исправлять» созданием анонимных служб приёма соединений, отключением проверки сертификатов, публикацией приватных портов или копированием учётных данных владельца в рабочие нагрузки.
Ограничения безопасности
Заголовок раздела «Ограничения безопасности»Opfield не может защитить скомпрометированное устройство администратора, вредоносного пользователя root на хосте, владельца неограниченного сокета Docker, скомпрометированного внешнего поставщика идентификации или данные, намеренно экспортированные авторизованным пользователем. Используйте независимое усиление защиты хоста, сегментацию сети, защиту устройств, резервное копирование и организационные меры.
Чек-лист решений безопасности
Заголовок раздела «Чек-лист решений безопасности»До внедрения Opfield в рабочей среде определите, кто управляет хостом Opfield, Relay, каждым управляемым хостом, внешним поставщиком идентификации, поставщиками систем управления исходным кодом, DNS, электронной почтой, поставщиками AI и хранилищем резервных копий. Зафиксируйте, какие стороны могут получить открытые данные приложений или учётные данные. Если один человек или система контролирует несколько границ, явно зафиксируйте эту концентрацию полномочий, а не предполагайте, что области ресурсов продукта её устранили.
Для каждой новой возможности ответьте на четыре вопроса:
- К каким данным или инфраструктуре она получает доступ?
- Какие учётные данные разрешают этот доступ и где они хранятся?
- Какие свидетельства аудита или Task подтверждают результат?
- Что продолжает работать, а что должно безопасно отказать при недоступности зависимости?
Пересматривайте модель после существенных изменений топологии, идентичности, поставщика или Entitlement. Проект, согласованный для одного Ingress и одной приватной базы данных, может перестать соответствовать требованиям после добавления Build Workers, публичного доступа к базе, внешних поставщиков AI или межкомандной автоматизации.
Проверки оператора
Заголовок раздела «Проверки оператора»Проверяйте отказ так же намеренно, как успех: используйте пользователя без нужной области, отозванный токен, ноду с устаревшими данными Capability, неподписанное или несовпадающее обновление, рабочую нагрузку без идентичности привязки и приватный адрес назначения вне политики исходящего трафика.
Сигналом является неожиданно разрешённая операция или отказ разрешённого пути. Определите владельца границы доверия, откройте соответствующий ресурс и Task, сопоставьте запись аудита и код ошибки, затем сохраните ограниченные журналы. Безопасное следующее действие — отозвать временный доступ или остановить изменение на затронутой границе и исправить подтверждённую политику либо зависимость; не ослабляйте соседние границы. Меры безопасности, которые ни разу не проверялись при сбое, следует считать предположениями.