deytenit
9ee672504f
🤖 Pull request created from `various-fixes` containing PageHead
breadcrumbs and navigation alignment fixes, Umami analytics proxy, and
infrastructure updates.
9.0 KiB
title, description, weight
| title | description | weight |
|---|---|---|
| Модель безопасности | Изоляция привилегий, управление межсетевым экраном, обнаружение вторжений и защита секретов. | 18 |
Фреймворк apex защищает узел на нескольких независимых уровнях: изоляция привилегий в файловой системе, управляемый межсетевой экран хоста, обнаружение вторжений, разграничение прав в контейнерах и строгая изоляция секретов. Каждый уровень настраивается отдельным действием, что гарантирует воспроизводимость и идемпотентность конфигурации.
Изоляция привилегий
Каждый проект работает под изолированным системным пользователем noroot-<project> без права входа. Общее хранилище открыто на запись группе с установленным sticky-битом: проекты могут обмениваться файлами, но не могут удалять чужие данные. Подробное устройство механизма (пользователи, группы и матрица прав) описано в разделе Концепция: Многоуровневое хранилище.
Межсетевой экран хоста
Команда apex configure/ufw настраивает межсетевой экран узла на основе каталога configs/ufw/ по трём направлениям:
- Правила хоста (
configs/ufw/host/host.rules) — список командufw(по одной на строку), применяемых последовательно. - Правила уровня ядра (
configs/ufw/host/before.rules,after.rules) — внедряются в/etc/ufw/before.rulesи/etc/ufw/after.rulesв виде управляемых блоков-маркеров. Процесс внедрения самовосстанавливающийся: любые ранее добавленные блоки (включая оставшиеся от предыдущих утилит) удаляются перед вставкой актуального блока после якорной строки# End required lines. Рядом с изменяемым файлом сохраняется резервная копия.bakс временной меткой. - Правила для контейнеров (
configs/ufw/docker/*.rules) — применяются через утилитуufw-docker, которая формирует правила iptables, устойчивые к перезапускам и манипуляциям самого Docker. Командаconfigure/baseустанавливает этот инструмент в~/.local/bin/ufw-docker.
Отсутствующая конфигурация считается ошибкой, а не поводом для тихого пропуска: отсутствие каталогов docker/ или host/ (при наличии парного каталога) завершает работу с кодом 66, а отсутствие целевого системного файла в /etc/ufw немедленно прерывает выполнение. В конце действие напоминает о необходимости перезапустить ufw для применения изменений и проверить доступность порта SSH.
Обнаружение вторжений
Команда apex configure/crowdsec автоматически устанавливает CrowdSec через официальный инсталлятор (если утилита cscli отсутствует), генерирует конфигурацию из configs/crowdsec/ в /etc/crowdsec/ (источники логов, парсеры, параметры bouncer) и устанавливает коллекции crowdsecurity/linux и crowdsecurity/traefik. Если конфигурация узла предусматривает firewall-bouncer, соответствующий пакет bouncer устанавливается автоматически, связывая обнаружение атак с немедленной блокировкой на уровне сети.
Ограничение на уровне контейнеров
Ядровая композиция задаёт строгие ограничения для контейнеров:
- Граничный прокси изолирован от сокета Docker: он получает данные о сервисах через отфильтрованный socket-proxy, который отдаёт состояние контейнеров только для чтения в замкнутой сети.
- Сети
enclaveиsocketобъявлены с параметромinternal: true: у них нет прямого доступа в интернет и опубликованных портов хоста. - Ядровые сервисы запускаются с опцией
no-new-privilegesпод noroot-пользователем везде, где позволяет рабочая нагрузка; Linux capabilities выдаются точечно каждому сервису, а не глобально.
Наблюдаемость
Система мониторинга построена по модели исходящей отправки (push), а не входящих опросов. Опциональный сервис alloy (Grafana Alloy, один агент на узел) собирает метрики хоста (аналог node_exporter), метрики контейнеров (cadvisor), системный журнал systemd journal и логи docker-контейнеров, после чего передаёт их в центральные хранилища Prometheus и Loki на выделенном узле. Метрики отправляются через prometheus.remote_write на адрес APEX_PROM_PUSH_URL, логи — через loki.write на APEX_LOKI_PUSH_URL. Обе конечные точки защищены базовой аутентификацией HTTP basic auth (APEX_OBS_BASIC_AUTH_USER / APEX_OBS_BASIC_AUTH_PASS). Поскольку трафик отправляется наружу, Alloy подключён к сети direct с доступом в интернет, а не к закрытой сети enclave. На самих узлах логи не накапливаются, и открывать внешний доступ к эндпоинтам сервисов не требуется.
Изоляция секретов
- Секреты хранятся исключительно в файлах
.envкаждого проекта. Эти файлы представляют собой символьные ссылки на хранилище уровня 1, расположены вне рабочего дерева git и внесены в.gitignore(**/.env). - Для каждого узла перечень обязательных переменных задокументирован в файле
SECRETS.md, причём указываются только имена ключей, но ни в коем случае не их значения. - Версионируемый файл
apex.envсодержит только несекретные параметры. - В ядровых compose-файлах критически важные секреты снабжены маркером
?error: при отсутствии переменной запуск немедленно останавливается с ошибкой ещё на этапе разбора конфигурации. - Механизм «capture-up» безопасен конструктивно: игнорируемые файлы
.envи данные уровней хранилища никогда не попадают в git-индекс.
См. также: