Аудит и журналирование

Окружение, которое вы не можете реконструировать, — это окружение, которое вы не можете защитить. Модель аудита существует, чтобы в любой момент ответить на один вопрос: что произошло, с чем и по чьей воле.

Модель свидетельств

Каждое значимое событие в mesh должно фиксировать четыре факта: кто изменил политику, какой узел или сервис затронут, какая продуктовая поверхность затронутаи исходит ли событие от оператора-человека, токена автоматизации, раннера или шлюза. Событие, в котором отсутствует любой из этих четырёх фактов, не может служить разбору инцидента — оно способно лишь сообщить, что что-то произошло.

Субъект и контекст запроса

События записываются как структурированные записи с контекстом субъекта, идентификаторами запросов, системной активностью и операционной историей. Идентификаторы запросов позволяют проследить одну операцию через координатор, агент и продуктовый сервис; контекст субъекта указывает ответственную идентичность; операционная история связывает всё это во временную шкалу, по которой можно пройти назад от инцидента.

Типовая форма события

  {
    "id": "evt_01J2...",
    "request_id": "req_...",
    "actor": { "kind": "token", "id": "tok_builds", "scope": "builders" },
    "action": "acl.rule.updated",
    "target": { "kind": "acl", "id": "grants.builders" },
    "surface": "coordinator /v1",
    "timestamp": "2026-08-18T09:41:02Z"
  }

Покрытие продуктовых поверхностей

Модель аудита покрывает продуктовые поверхности, а не только control plane: изменения подключений, обновления политик доступа, предоставление продуктов, активность Git, изменения конфигурации маршрутизаторов и операции резервного копирования и восстановления. Rizoma Git, например, ведёт полный журнал аудита изменений кода, запусков CI, публикаций пакетов и событий доступа,с цепочками ответственного хранения и подписанными артефактами как свидетельствами развёртывания.

Средства автоматизации должны потреблять эти журналы как подписанные потоки событий — порядок их получения для комплаенс-выгрузки и передачи в эксплуатацию описан в разделе «Аудит-webhooks» .

Метрики и состояние

Агент, координатор, релей, ingress и дашборд предоставляют проверки health, готовности, info и метрики Prometheus. Телеметрия передаётся через heartbeat вместе с эндпоинтами и материалом ключей E2E, поэтому состояние узла наблюдаемо из control plane без открытия дополнительных портов. Используйте метрики для выявления отклонений от политик — узел, чьи соответствия ACL изменились без соответствующего события аудита, требует внимания.

Сделайте ревизию привычкой. Порядок развёртывания включает проверку телеметрии до подачи производственного трафика, — поскольку журнал аудита полезен лишь тогда, когда он полон до наступления критического момента.

Назад Zero-Trust Policies Далее API Authentication