Криптографически подписанный журнал аудита с защитой от подделки.
Каждое действие (сессии, команды, доступ к секретам, изменения политик) хешируется, связывается с предыдущей записью и подписывается ключом Ed25519 — при self-host запечатанным в аппаратном TPM; в управляемом облаке ключ сегодня защищён теми же средствами контроля на уровне хоста, что и остальной сервис. Администратор компании проверяет диапазон через GET /audit/verify: сервер заново считает хеш каждой строки и сверяет подпись с ключом из своей базы; публичный ключ вашей компании опубликован по /audit/pubkey/:company_id.
Запись хешируется (sha256) со ссылкой на хеш предыдущей строки.
3
Подпись Ed25519
При self-host подпись создаётся ключом, запечатанным в аппаратном TPM, который никогда не покидает чип. В управляемом облаке — теми же средствами контроля на уровне хоста, что и остальной сервис.
4
Проверка на сервере
Администратор компании запрашивает диапазон строк через GET /audit/verify; сервер заново считает хеш каждой строки и проверяет её подпись Ed25519 ключом, который хранит для этой цепочки.
Подробнее
Цепочка хешей
Поле prev_hash каждой записи, это sha256 предыдущей строки. Удалите строку N, и строки N+1 и далее перестанут проходить проверку: разрыв цепочки виден сразу.
Подпись и запечатывание в TPM
При self-host ключ подписи запечатывается в аппаратном TPM вашего хоста и распечатывается только внутри процесса audit-signer. В управляемом облаке сегодня не настроен ни аппаратный TPM, ни облачный KMS: ключ защищён теми же средствами контроля на уровне хоста, что и остальной сервис, а не отдельным бэкендом управления ключами.
Постраничная проверка
Проверка без постраничного режима смотрит максимум 10 000 строк; если в диапазоне больше, она останавливается, помечает результат как truncated и возвращает ok: false, а не выдаёт префикс за весь диапазон. Чтобы пройти цепочку на 1,2 млн строк, передайте batch= и читайте её страницами: каждая страница возвращает has_more, курсор next_after_id и prev_hash для следующего запроса — именно это двигает индикатор прогресса в интерфейсе администратора.
Проверьте цепочку сами
shell · verify CLI
$caldyr audit verify--from 8400 --to 8500
chain intact ✓
entries verified : 101
total in range : 101
last hash : 9f8ce4d27a91…3a4e
Защита от подделки, это доказуемость, а не просто стойкость.
Мы не обещаем, что не изменим записи; мы даём цепочку, в которой изменение обнаруживается. Каждая строка связана хэшем и подписана Ed25519, поэтому правка внутри проверяемого диапазона разрывает связь, и проверка помечает эту строку как подделанную. Важно, кто выполняет проверку: /audit/verify — наш эндпоинт, и ключ подписи, с которым он сверяет, держим мы, так что администратор компании получает доказательство для действий, а не независимую проверку. Публичный ключ вашей компании опубликован по /audit/pubkey/:company_id; ни один наш инструмент пока не проверяет цепочку этим ключом.
Сравнение
Caldyr
Обычные логи БД
Append-only лог
Защита от подделки
да
нет
без подписи
Криптографическое доказательство
Ed25519 + sha256
нет
нет
Опубликованный публичный ключ
да · /audit/pubkey/:company_id
нет
нет
Ключ подписи на тенант
запечатан в TPM (self-host)
нет
общий ключ
Постраничная проверка
постранично batch · предел 10 000
нет
загрузка всего в память
Частые вопросы
Генерируется новый ключ. Строки до ротации остаются проверяемыми старым pubkey; строки после проверяются новым. Потеря без ротации означает, что цепочка становится append-only без будущих подписей, но всё подписанное до этого момента по-прежнему проверяемо.
Аудитор проверяет цепочку через CLI Caldyr: caldyr audit verify --from <n> --to <n>. CLI требует API-токен и обращается к нашему /audit/verify, вызвать который может только администратор этой компании: либо вы выдаёте аудитору такой токен, либо прогоняете диапазон за него. Сама сверка подписи выполняется на сервере, с ключом из нашей базы. Для долгого хранения экспортируйте журнал в CSV на вкладке аудита; в Enterprise весь подписанный журнал также стримится в ваш SIEM или S3 WORM-бакет под их контролем.
Подпись не лежит на пути действия. Сначала строка аудита записывается и фиксируется в базе; затем отдельный воркер-подписчик на Node просыпается по Postgres NOTIFY и подписывает её: одна подпись Ed25519 на каждую строку, последовательно внутри цепочки каждой компании или пользователя, плюс опрос раз в 30 секунд как подстраховка. Пока строка не подписана, проверка показывает её как pending.
При self-host на машине с TPM 2.0: запечатан в чипе, никогда не выгружается в открытом виде, распечатывается только на этом хосте. В управляемом сервисе TPM у хоста нет, поэтому зерно — файл на этом хосте, доступный служебной учётной записи подписчика. В обоих случаях ключ держим мы и проверку выполняем мы, поэтому чистый диапазон — это наше подтверждение, а не независимая проверка, которую провели вы; публичный ключ этой цепочки опубликован по /audit/pubkey/:company_id, и ни один наш инструмент сегодня не проверяет цепочку без нас.
Готовы управлять своей ИИ-инфраструктурой?
Запросите доступ за пару минут, или обсудите с нами установку в air-gap.