Аудит
Аудит фиксирует значимые события обработки пользовательских запросов в Netgap. Audit-события помогают восстановить путь запроса через gateway и executor, подтвердить факт доставки ответа и выявить ошибки взаимодействия с внешними компонентами.
Audit-события являются частью функции События (event): для их вывода используется target_id: Audit. При необходимости те же события можно дополнительно отправлять в SIEM.
Аудируемые события
Netgap формирует audit-события на ключевых этапах обработки запроса.
| Компонент | Событие | Когда формируется |
|---|---|---|
netgap-gateway | http request | Gateway принял HTTP-запрос от клиента и поставил его в очередь для executor. |
netgap-gateway | request blocked by http filter | Запрос не прошёл фильтр HTTP-запросов на границе контура и не был поставлен в очередь; клиент получил 403 или 405. |
netgap-executor | request blocked by http filter | Запрос не прошёл фильтр перед вызовом целевого сервиса; целевой сервис не вызывался, шлюзу возвращён ответ 403 или 405. |
netgap-executor | request pulled | Executor получил запрос из gateway для обработки в приватной зоне. |
netgap-executor | executing http request | Executor сформировал HTTP-запрос к целевому сервису. |
netgap-executor | response | Executor получил HTTP-ответ от целевого сервиса. |
netgap-executor | response delivered | Executor передал ответ обратно в gateway, и gateway подтвердил доставку. |
netgap-gateway | received response | Gateway получил ответ от executor и отправил его ожидающему клиентскому соединению. |
netgap-gateway | failed to handle | Gateway не смог обработать клиентское соединение. |
netgap-gateway | failed to accept | Gateway не смог принять входящее соединение. |
netgap-executor | HTTP request failed | Executor не смог выполнить HTTP-запрос к целевому сервису. |
Набор audit-событий ориентирован на контроль прохождения запроса через контур Netgap, а не на запись полного содержимого трафика. Отдельные группы составляют события фильтра HTTP-запросов и события безопасности внутреннего доверенного транспорта (mTLS), описанные ниже.
События request blocked by http filter формируются на уровне warn: блокировка — это штатное решение политики допуска, а не ошибка обработки, но она заслуживает внимания оператора. Обе стороны фиксируют блокировку независимо, поэтому запись со стороны исполнителя при разрешающей политике шлюза означает расхождение конфигураций компонентов. Остальные прикладные события формируются на уровне info, ошибочные — на уровне error.
Состав информации
В audit-запись попадает имя события, уровень, время, имя сервиса, целевой тип audit и поля, относящиеся к конкретному событию. При format: Json эти данные поставляются как структурированная JSON-запись; при format: Text или ColorizedANSI — как текстовая строка.
Типовые поля audit-событий:
| Поле | Где встречается | Назначение |
|---|---|---|
method | http request, request pulled, executing http request, request blocked by http filter | HTTP-метод запроса. |
path | http request, request pulled, executing http request, request blocked by http filter | HTTP-путь запроса. |
header_count / headers_count | Запросы и ответы | Количество заголовков без вывода их значений. |
body_bytes / resp_body_bytes | Запросы и ответы | Размер тела запроса или ответа в байтах без вывода содержимого. |
request_bytes | executing http request | Размер HTTP-запроса, сформированного executor для целевого сервиса. |
status_code | response, received response, request blocked by http filter | HTTP-статус ответа; для блокировки — код отказа 403 или 405. |
response_size | received response | Полный размер HTTP-ответа, отправленного клиенту. |
reason | request blocked by http filter | Причина блокировки: path — путь не совпал ни с одним правилом фильтра, method — метод не разрешён для совпавшего пути. |
error | Ошибочные события | Текст ошибки при сбое обработки, приема соединения, вызова целевого сервиса или отклонении mTLS-рукопожатия. |
spiffe_ids, expected_spiffe_id, remote_addr | События внутреннего транспорта | Идентичности и адрес источника при отклонённом mTLS-рукопожатии. |
Если включена распределенная трассировка, audit-события создаются внутри текущих tracing span-ов и могут быть сопоставлены с трассами по контексту наблюдаемости, который поставляет выбранная система сбора.
События фильтра HTTP-запросов
Если включён фильтр HTTP-запросов (http_filter в режиме AllowList), каждый запрос, не разрешённый политикой, фиксируется событием request blocked by http filter с полями method, path, reason и status_code. Содержимое запроса — заголовки и тело — в событие не попадает.
Событие формируется до передачи запроса дальше по конвейеру: заблокированный запрос не порождает события http request, request pulled и response — по потоку аудита видно, что обработка остановилась на политике допуска. Подробный разбор ответа клиенту, метрик блокировок и диагностики приведён в статье Заблокированные запросы: ответ, аудит и метрики.
События безопасности внутреннего транспорта (mTLS)
Соединения между компонентами Netgap устанавливаются только по mTLS (TLS 1.3) с авторизацией по SPIFFE ID — см. Внутренний транспорт (mTLS) и Взаимодействие netgap-gateway и netgap-executor. Каждая неудачная проверка при рукопожатии фиксируется как событие безопасности в том же потоке аудита (target_id: Audit) на уровне error.
События формируются до передачи первого байта прикладных данных: отклонённое соединение не доходит до gRPC-мостов и не порождает прикладных audit-событий обработки запроса.
| Компонент | Событие | Когда формируется |
|---|---|---|
Принимающая сторона (netgap-gateway) | internal transport: client certificate rejected during the handshake | Цепочка клиентского сертификата не прошла проверку: неверный УЦ, истёкший срок, неподходящий EKU или отзыв по CRL. |
Принимающая сторона (netgap-gateway) | internal transport: client identity rejected, no valid SPIFFE ID | Цепочка валидна, но в SAN клиентского сертификата нет ни одного корректного URI spiffe://…. |
Принимающая сторона (netgap-gateway) | internal transport: none of the client SPIFFE IDs is in the allowed list, connection rejected | Идентичности клиента валидны, но ни одна из них не входит в allowed_client_spiffe_ids того моста, к которому выполнено подключение. |
Принимающая сторона (netgap-gateway) | internal transport handshake rejected | Итоговое событие разрыва соединения с адресом источника; фиксируется для любой неудачи рукопожатия, включая попытку подключиться без TLS. |
Подключающаяся сторона (netgap-executor) | internal transport: server certificate rejected during the handshake | Цепочка сертификата сервера не прошла проверку или сертификат отозван. Несовпадение DNS-имени ошибкой не считается и событие не порождает. |
Подключающаяся сторона (netgap-executor) | internal transport: server identity rejected, no valid SPIFFE ID | В SAN сертификата сервера нет ни одного корректного URI spiffe://…. |
Подключающаяся сторона (netgap-executor) | internal transport: server SPIFFE IDs do not include the expected identity, connection rejected | Среди идентичностей сервера нет ожидаемого expected_server_spiffe_id: попытка подмены узла или обращение к мосту с чужой ролью. |
Ролевое разделение мостов означает, что один и тот же сертификат может быть принят одним мостом и отклонён другим: такой отказ — нормальный результат авторизации, а не ошибка конфигурации транспорта.
Состав информации в событиях mTLS
| Поле | Где встречается | Назначение |
|---|---|---|
error | Отклонение сертификата, internal transport handshake rejected | Причина отказа, как её вернула проверка цепочки или TLS-рукопожатие. |
spiffe_ids | События неудачной авторизации | Список фактически предъявленных контрагентом ролевых SPIFFE ID через запятую. |
expected_spiffe_id | internal transport: server SPIFFE IDs do not include the expected identity, connection rejected | Ожидавшаяся ролевая идентичность сервера для этого моста. |
remote_addr | internal transport handshake rejected | Адрес и порт источника отклонённого соединения. |
Секретный материал в аудит не попадает: журналируются только идентификаторы, адреса и причины отказа, без приватных ключей и содержимого сертификатов.
Идентичность контрагента в прикладных событиях
Успешные рукопожатия отдельным audit-событием не фиксируются — чтобы поток аудита не заполнялся записями о штатном переподключении долгоживущих gRPC-каналов. Проверенная идентичность контрагента передаётся прикладному слою и попадает в контекст обработки: мост ответов выполняет приём ответа в span-е с полями session (адрес контрагента) и peer_spiffe_ids, так что событие received response сопоставляется с аутентифицированным отправителем. Повторной авторизации на уровне gRPC-вызова нет: право вызвать мост эквивалентно праву пройти рукопожатие.
Вместе с аудитом отказов полезно контролировать срок жизни сертификатов внутреннего транспорта по метрикам netgap_internal_certificate_* — см. Описание метрик. Массовые события internal transport handshake rejected вскоре после истечения сертификата обычно означают просроченную идентичность, а не атаку.
Примеры конфигурации
Запись audit-событий в отдельный JSON-файл:
observability:
service_name: netgap-gateway
event_targets:
- level: info
target_id: Audit
target_destination: File
target_args: /var/log/netgap/audit.log
format: Json
Раздельный вывод технологических событий и audit-событий:
observability:
service_name: netgap-executor
event_targets:
- level: info
target_id: Tech
target_destination: Console
target_args: ""
format: ColorizedANSI
- level: info
target_id: Audit
target_destination: File
target_args: /var/log/netgap/audit.log
format: Json
Отправка audit-событий в SIEM по UDP:
observability:
service_name: netgap-gateway
event_targets:
- level: info
target_id: Tech
target_destination: File
target_args: /var/log/netgap/tech.log
format: Json
siem:
endpoint: 192.0.2.10:514
log_types: [Audit]
level: info
Результат и доставка
Результат работы аудита — поток audit-событий. Их можно доставлять теми же способами, что и остальные события Netgap:
- в консоль для локальной проверки;
- в файл с ежедневной ротацией для хранения и последующего сбора collector-ом;
- в Loki для централизованного поиска и анализа логов;
- в SIEM или syslog-совместимый приемник через функцию
siem.
Для рабочих окружений обычно используют format: Json, отдельный файл или отдельную цель доставки для target_id: Audit, а доступ к audit-журналам ограничивают по правилам безопасности организации.
Варианты применения
- расследование инцидентов и восстановление цепочки обработки запроса;
- контроль факта прохождения запроса через gateway и executor;
- обнаружение обращений к путям и методам, не разрешённым политикой фильтра HTTP-запросов;
- контроль ошибок приема соединений и вызова целевых сервисов;
- передача значимых событий безопасности в SIEM/SOC;
- обнаружение попыток подключения к внутренним мостам с неавторизованной, просроченной или отозванной идентичностью;
- разбор ошибок ролевой авторизации между мостами запросов и ответов;
- раздельное хранение технологических логов и audit-журналов с разными политиками доступа.