Аудит в 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 hash.

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

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

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

Использование нескольких аудит-устройств

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

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

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

Ошибки аудит-устройств

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

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

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

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

Stronghold поддерживает те же базовые бэкенды аудита, что и Vault:

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

File

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

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

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

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

Syslog

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

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

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

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

Socket

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

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

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

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

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

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

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

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

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

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

d8 stronghold audit list

stronghold audit list

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

d8 stronghold audit disable file/

stronghold audit disable file/

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

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

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

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

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

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