Stronghold записывает события аудита как отдельные JSON-объекты, разделенные переводами строк. Записи журнала аудита содержат как общие атрибуты, характерные для всех API-вызовов, так и поля, зависящие от конкретного запроса или ответа.

Записи журнала аудита отражают:

  • API-запросы, полученные Stronghold;
  • API-ответы, отправленные Stronghold.

Запись ответа можно сопоставить с соответствующей записью запроса по идентификатору request.id, который присутствует в обеих записях.

Корневая структура записи

Независимо от типа записи в журнале обычно используются следующие верхнеуровневые поля:

АтрибутТипОписание
authobjectОбъект аутентификации, описывающий субъект, выполнивший вызов API.
errorstringТекст ошибки, если запрос завершился ошибкой. Для успешных операций обычно отсутствует.
forwarded_fromstringУзел, который перенаправил запрос. Присутствует только в соответствующих сценариях.
requestobjectОбъект запроса с техническими и бизнес-атрибутами операции.
responseobjectОбъект ответа. Присутствует в записях типа response.
timestringВремя события в формате ISO 8601.
typestringТип записи: request или response.

Пример записи запроса

{
  "type": "request",
  "time": "2025-06-05T16:10:22.292517Z",
  "request": {
    "id": "6e3d8a4a-1c4b-4f7e-8d91-9b0df2c7a111"
  },
  "auth": {
    "client_token": "hmac-sha256:..."
  },
  "error": "..."
}

Пример записи ответа

{
  "type": "response",
  "time": "2025-06-05T16:10:22.292639Z",
  "request": {
    "id": "6e3d8a4a-1c4b-4f7e-8d91-9b0df2c7a111"
  },
  "response": {
    "data": {}
  },
  "auth": {
    "client_token": "hmac-sha256:..."
  }
}

Объект аутентификации auth

Stronghold включает в объект auth только релевантные атрибуты. Например, client_token и accessor отсутствуют у неаутентифицированных запросов, а metadata не появляется, если у токена нет метаданных.

На практике в объекте auth чаще всего встречаются:

  • accessor
  • client_token
  • display_name
  • token_type
  • token_issue_time
  • token_ttl
  • metadata
  • entity_id
  • policies
  • identity_policies
  • token_policies
  • policy_results

Эти поля помогают понять, какой субъект выполнил запрос, в каком контексте он был авторизован и какие политики привели к разрешению операции.

Объект запроса request

Объект request описывает технические параметры входящего вызова. Наиболее важные поля:

  • id — уникальный идентификатор запроса;
  • operation — тип операции: create, read, update, delete, list;
  • namespace — идентификатор и путь пространства имен;
  • path — путь API, обработавший запрос;
  • request_uri — исходный URI запроса, если он отличается от path;
  • mount_accessor, mount_point, mount_type — сведения о точке монтирования;
  • remote_address, remote_port — адрес и порт клиента;
  • client_id, client_token, client_token_accessor — идентификаторы клиента и токена;
  • data — полезная нагрузка запроса;
  • wrap_ttl — TTL response wrapping, если обертывание было запрошено.

Упрощенный пример:

{
  "id": "",
  "operation": "",
  "namespace": {
    "id": "",
    "path": ""
  },
  "path": "",
  "mount_point": "",
  "mount_type": "",
  "remote_address": "",
  "remote_port": 1234,
  "headers": {},
  "data": {}
}

Объект ответа response

Объект response описывает результат обработки API-запроса. В нем могут встречаться:

  • auth — объект аутентификации, если в результате операции был выдан токен;
  • headers — заголовки ответа;
  • redirect — адрес перенаправления для auth backend-ов;
  • warnings — предупреждения API;
  • data — полезная нагрузка ответа;
  • secret — сведения об арендованном секрете;
  • wrap_info — информация о wrapping token;
  • mount_class, mount_accessor, mount_point, mount_type — сведения о точке монтирования, сформировавшей ответ;

Упрощенный пример:

{
  "data": {},
  "headers": {},
  "mount_point": "",
  "mount_type": "",
  "warnings": [""],
  "secret": {
    "lease_id": ""
  },
  "wrap_info": {
    "token": "",
    "ttl": 60
  }
}

Защита чувствительных данных

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

Это означает:

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

Важно помнить, что в первую очередь хешируются строковые значения, пришедшие в JSON или возвращенные в JSON. Другие типы данных, например числа и булевы значения, могут сохраняться в открытом виде.

Практические замечания

  • Полную картину аудита нужно собирать по совокупности всех включенных audit-устройств.
  • При включении filter и exclude конкретное устройство будет сохранять уже отфильтрованный или модифицированный вариант записи.
  • Для большинства инженерных задач достаточно понимать корневую структуру записи и ключевые объекты auth, request, response.

Связанные страницы