Укрепление развёртывания
Это операторское руководство по укреплению: конкретные шаги для безопасного запуска control plane. Оно располагается поверх пояснительных страниц — модель безопасности и модель угроз объясняют активы, границы доверия и почему posture такова, какова она есть. Эта страница — про как.
1. Сохраняйте безопасные настройки по умолчанию
Заголовок раздела «1. Сохраняйте безопасные настройки по умолчанию»Свежая установка безопасна по умолчанию. Задача здесь — в основном не ослаблять её.
| По умолчанию | Сохраняйте, потому что | Действие оператора |
|---|---|---|
| Нет учётных данных по умолчанию | Главный footgun self-hosted. Первая загрузка создаёт одноразовый токен настройки однократного использования; им вы создаёте первого администратора. | Прочитайте токен из вывода загрузки (или логов контейнера), создайте администратора, после чего он потребляется. Никогда не запекайте учётный данные в образ. |
| TLS включён по умолчанию | Каналы коллектор→ядро и пользователь→панель несут чувствительные метаданные. | Оставьте TLS включённым. --insecure (открытый текст) — только для разработки на localhost — никогда на открытой привязке. |
| Привязка — не защита | Движок по умолчанию привязывается ко всем интерфейсам: это сервер. Защищают его включённый TLS, отсутствие учётных данных по умолчанию и одноразовый токен настройки — ничто из этого не зависит от привязки. | Ограничивайте её осознанно, когда это нужно: --listen 127.0.0.1:8443 для бинарника, OLIVARES_BIND=127.0.0.1 для стека Compose. Поставьте перед ним собственный ingress/TLS ради сертификата, которому доверяют браузеры, и имени хоста, пригодного для passkey — см. self-hosting. |
| Нет телеметрии-домой | Инструмент безопасности, который «звонит домой», — это источник риска. | Действий нет — движок не делает обязательных исходящих вызовов при загрузке. В air-gapped режиме нулевой egress. |
Каждый опасный отход от настроек по умолчанию — это именованное, явное подключение по выбору (opt-in) (например, флаг открытого текста для разработки или разрешение привилегированной роли базы данных). Если вы его не установили — он выключен. Полная posture безопасных настроек по умолчанию и криптографические гарантии аудит-журнала — в модели безопасности.
Настройки входа и безопасности
Заголовок раздела «Настройки входа и безопасности»Откройте Настройки → Вход и безопасность, чтобы увидеть способы входа, срок действия сессии движка, политику дополнительной административной проверки и зарегистрированные passkey. Срок действия сессии доступен только для чтения; обновление сессии продлевает срок её действия. На этой странице можно зарегистрировать или переименовать passkey и подключить приложение-аутентификатор. Системные администраторы могут изменять существующие политики дополнительной проверки и аутентификатора; остальные пользователи видят требование проверки без элемента редактирования. Прежде чем потребовать passkey или код аутентификатора, нужно доказать, что ваша сессия может использовать выбранный способ. Используйте Управление провайдерами идентификации для настройки единого входа.
Взаимный TLS для удалённых коллекторов
Заголовок раздела «Взаимный TLS для удалённых коллекторов»Граничный коллектор — функция Business; сборка Community отказывается выполнять olivares collector. Флаг --grpc-client-ca ниже задаётся на ядре.
В распределённой топологии граничные коллекторы отправляют наблюдения ядру через взаимный TLS (mutual TLS) с проверенным клиентским сертификатом. Включите его, дав ядру клиентский CA, чтобы оно требовало и проверяло клиентский сертификат:
./bin/olivares serve \ --listen 127.0.0.1:8443 --grpc-listen 127.0.0.1:8444 \ --grpc-client-ca /path/to/collector-ca.pem \ --data-dir /var/lib/olivaresКоллекторы работают на вашей инфраструктуре без входящего слушателя (чистая модель push), поэтому они не добавляют открытых портов на ваши продакшен-хосты. Защитите и резервируйте каталог данных (ограничивающие права) — он содержит ключ подписи аудита и материал TLS — и держите вне машины копию публичного ключа аудита.
2. Регулируйте деструктивные действия через согласования human-in-the-loop
Заголовок раздела «2. Регулируйте деструктивные действия через согласования human-in-the-loop»Control plane управляется ядром авторизации с запретом по умолчанию (deny-by-default) (RBAC, с опциональным только-ограничивающим (restrict-only) policy decision point Cedar/OPA, который может лишь отнимать доступ, никогда не расширять его). Про модель — роли, шов политики и гарантию записанных решений — см. управление и согласование. Операционные шаги:
- Подключите ворота согласования. Любое действие модуля, которое мутировало бы вашу инфраструктуру (применение развёртывания, запуск оркестрации, открытие голоса), проходит через ворота согласования human-in-the-loop, открывающие управляемое согласование, привязанное к точному плану, закрытое по умолчанию и ограниченное по времени. Оно включается предоставлением конфигурации моста; без неё эти действия остаются закрытыми по умолчанию.
- Используйте выделенную сервисную учётную запись согласующего — никогда человеческую. Компонент, который открывает согласования, должен работать как собственная сервисная учётная запись, которая никогда не входит в пул согласующих. Разделение обязанностей принудительно реализовано на стороне движка: идентичность, открывшая запрос, не может решить по нему, а системный токен не может согласовывать вообще. Если учётная запись открывающего одновременно согласующий, вы создаёте взаимоблокировку живучести — поэтому держите их раздельно.
- Согласующие решают, журнал помнит. Авторизованный человек одобряет или отклоняет; решение добавляется в журнал с обнаружением подделки с реальным актором в той же транзакции. Истёкший запрос никогда не может получить связывающее решение. Вы не можете сделать управляемое изменение, о котором журнал молча забудет.
Маршруты согласования находятся под пространством имён модуля управления (governance) и подчиняются тому же RBAC с запретом по умолчанию и аудиту каждого чтения, что и всё остальное.
3. Проверяйте релиз перед запуском
Заголовок раздела «3. Проверяйте релиз перед запуском»Control plane — это продукт безопасности; докажите, что релиз — именно тот, что опубликовал проект, прежде чем запускать его. Полная цепочка (подпись над контрольными суммами, провенанс SLSA, аттестации SBOM и OpenVEX, онлайн keyless или полностью офлайн) — в проверьте то, что вы скачали. Единственное правило, у которого нет исключений:
4. Держите свидетельства — и ваши данные — на своём периметре
Заголовок раздела «4. Держите свидетельства — и ваши данные — на своём периметре»- Экспортируйте журнал вне машины. Append-only, hash-chained, подписанный Ed25519 аудит-журнал предоставляется как аутентифицированный экспорт через pull в нескольких форматах SIEM, так что ваш SIEM или WORM-хранилище держит неизменную копию, которая повторно проверяет цепочку офлайн. Копия вне машины — это реальный контроль против полностью скомпрометированного хоста — см. пересылка аудита в Splunk.
- Без обязательной телеметрии и исходящего трафика управляющей плоскости по умолчанию. Плоскость данных (коллекторы) всегда работает на вашей инфраструктуре, а access map хранит отношения, никогда не полезные нагрузки, секреты или PII — минимум данных является свойством протокола передачи, а не настройкой. За ваш периметр выходит только то, что вы настроили для передачи наружу: обращения к API ваших моделей, подключённые вами выходы SIEM/webhook (включая описанный выше экспорт за пределы машины) и внешний поставщик эмбеддингов, если вы его настроили. Это структурный аргумент в пользу резидентности данных, GDPR и air-gapped работы; это описание архитектуры и вашей конфигурации, а не гарантия.
Связанное
Заголовок раздела «Связанное»- Модель безопасности — привилегии, разграничение по тенантам, самоаудит, минимум данных.
- Модель угроз — активы, границы доверия и что может аттестовать каждый уровень покрытия.
- Управление и согласование — модель RBAC/PDP и рабочий процесс согласования подробно.
- Проверьте то, что вы скачали — полная цепочка проверки релиза.
- Self-hosting и установка в air-gap — топологии развёртывания.