Аудит в Stronghold

Аудит в Stronghold предназначен для записи запросов к API и ответов на них. Так как любая операция в Stronghold выполняется через API, аудит позволяет восстановить последовательность действий пользователей, сервисов и администраторов, а также использовать эти данные для расследований, мониторинга и контроля соответствия требованиям безопасности.

Что попадает в аудит-лог

При включенном аудит-устройстве Stronghold записывает:

• запросы к API;
• ответы на запросы;
• ошибки, возникшие при выполнении операций.

В результате аудит-лог становится основным источником информации о том, кто, когда и к какому пути обращался, какая операция выполнялась и каким был результат.

Пути, которые не проходят через аудит

Часть системных путей не проходит через аудит. К ним относятся:

sys/init
sys/seal-status
sys/seal
sys/step-down
sys/unseal
sys/leader
sys/health
sys/rekey/init
sys/rekey/update
sys/rekey/verify
sys/rekey-recovery-key/init
sys/rekey-recovery-key/update
sys/rekey-recovery-key/verify
sys/storage/raft/bootstrap
sys/storage/raft/join
sys/internal/ui/feature-flags

При определенных настройках listener-а также могут обходить аудит следующие пути неаутентифицированного доступа:

sys/metrics
sys/pprof/*
sys/in-flight-req

Эти исключения важно учитывать при проектировании общей схемы наблюдаемости и расследований.

Формат и защита данных в аудит-логе

Каждая запись аудит-лога представляет собой JSON-объект. Поле type указывает тип записи:

• request — запись о запросе;
• response — запись об ответе.

По умолчанию чувствительные строковые данные в аудит-логах не сохраняются в открытом виде, а хешируются с использованием HMAC-SHA256 и соли конкретного audit-устройства. Это уменьшает риск утечки секретов через журналы, сохраняя возможность проверять значения через механизм audit hash.

Важно учитывать:

• не все типы данных маскируются одинаково;
• после отключения audit-устройства его соль хеширования теряется, и сравнение старых значений через это устройство становится невозможным;
• использование необработанного логирования чувствительных данных должно быть осознанным и строго ограниченным.

Подробно о составе аудит-записи и формате хранения данных см. на странице Схема записей журнала аудита.

Зачем включать несколько audit-устройств

Если включено несколько audit-устройств, Stronghold пытается записать событие во все из них. Это дает сразу несколько преимуществ:

• появляется резервная копия аудит-записей;
• можно направлять логи в разные системы;
• легче обнаруживать проблемы доставки и возможную порчу данных.

Практически это означает, что полную картину аудита нужно собирать как объединение логов со всех настроенных устройств.

Что происходит при ошибках audit-устройств

Аудит критически важен для безопасности Stronghold, поэтому поведение при ошибках зависит от типа сбоя:

• если хотя бы одно audit-устройство успешно записало событие, запрос обычно может завершиться успешно;
• если audit-устройство вошло в блокирующее состояние и запись в него зависает, запросы к Stronghold могут зависнуть до устранения проблемы;
• при сетевых backend-ах нужно отдельно учитывать риски таймаутов, недоступности сокета или потери UDP-пакетов.

Поэтому перед включением audit-устройства необходимо убедиться, что все узлы кластера действительно могут в него писать.

Поддерживаемые типы audit-устройств

Stronghold поддерживает те же базовые backend-ы аудита, что и Vault:

• file — запись в файл;
• syslog — отправка в локальный syslog-агент;
• socket — отправка в TCP, UDP или UNIX socket.

file

Наиболее предсказуемый backend для локального хранения и последующей передачи в систему централизованного логирования.

Пример включения:

stronghold audit enable file file_path=/var/log/stronghold_audit.log

syslog

Подходит для Unix-систем с уже настроенным syslog-стеком.

Пример включения:

stronghold audit enable syslog tag="stronghold" facility="AUTH"

socket

Подходит для интеграции с внешними системами через TCP, UDP или UNIX socket.

Пример включения:

stronghold audit enable socket address=127.0.0.1:9090 socket_type=tcp

При использовании UDP нужно учитывать риск незаметной потери сообщений. Для production-сценариев желательно комбинировать socket с другим, более надежным audit-устройством.

Базовые операции

Включить audit-устройство:

stronghold audit enable file file_path=/var/log/stronghold_audit.log

Посмотреть список устройств:

stronghold audit list

Отключить устройство:

stronghold audit disable file/

Продвинутые возможности

В Stronghold доступны дополнительные механизмы тонкой настройки аудит-логов:

• Схема записей журнала аудита — структура audit-записи, ключевые объекты auth, request, response и защита чувствительных данных;
• Фильтрация данных аудита — позволяет направлять в конкретное устройство только записи, соответствующие условию;
• Исключение полей из данных аудита — позволяет удалять отдельные поля из записей перед их сохранением.

Эти возможности полезны для разграничения потоков журналов, снижения объема логов и ограничения хранения отдельных чувствительных полей, но должны применяться осторожно.

Рекомендации

• Включайте аудит сразу после инициализации Stronghold.
• Для production-сред используйте более одного audit-устройства.
• Тестируйте конфигурацию фильтров и исключений в непроизводственной среде.
• Учитывайте, что аудит является частью модели безопасности, а не только средством диагностики.