Наблюдаемость
Передавайте каждое событие в ваш SIEM - подписанным и проверяемым.
События аудита и безопасности передаются в реальном времени в Splunk, Datadog, Elastic, Microsoft Sentinel, S3 WORM, обычный syslog или универсальный HTTPS webhook (тариф Enterprise). Каждое событие несёт подпись Ed25519 записи аудита и id ключа, которым она сделана; публичный ключ вашей компании опубликован по /audit/pubkey/:company_id. Неудачные доставки повторяются с задержкой до суток, затем попадают в dead-letter очередь, которую можно воспроизвести.
Caldyr
Splunk
Datadog
Elastic
Sentinel
S3 WORM
Syslog
Как это работает
1
Событие сгенерировано
Запись аудита подписывается и передаётся отправителю в SIEM.
2
Добавляется блок подписи
Конверт, это запись аудита и её блок подписи: sig, key_id, pubkey_fp, prev_hash, payload_hash. Один ключ подписи на компанию, а не на приёмник.
3
Отправка в ваш приёмник
Шесть режимов аутентификации на приёмник - none, bearer, mTLS, signed JWT, Sentinel OAuth2 и Sentinel shared key; приёмник, не указавший режим, получает none. mTLS и signed JWT не передают общего секрета; bearer передаёт собственный токен приёмника при каждой отправке, Sentinel OAuth2 - токен доступа Azure AD, Sentinel shared key - HMAC, вычисленный на ключе рабочей области, а Splunk и Datadog отправляют свой токен даже при mTLS. HTTP-приёмники требуют https://, syslog поверх TCP требует TLS, но syslog поверх UDP идёт без шифрования.
4
Повтор при переподключении
Неудачные доставки повторяются с экспоненциальной задержкой до 24 часов, затем попадают в dead-letter очередь, которую можно воспроизвести.
Подробнее
Подписанные конверты
Блок, это подпись Ed25519 по записи аудита в том виде, в каком она сохранена, сцепленная с предыдущей записью: sig, key_id, pubkey_fp, prev_hash, payload_hash. raw_json, ECS, OCSF и syslog несут все пять полей; CEF и LEEF несут только подпись и id ключа. Публичный ключ вашей компании опубликован по /audit/pubkey/:company_id, и мы не поставляем проверяющий инструмент для вашей стороны: проверка блока, это работа вашего SIEM. Если у приёмника есть правила-преобразования, подпись покрывает запись такой, какой она была до преобразования.
Гарантии доставки
Доставка не менее одного раза с идемпотентными ID. Неудачные пакеты повторяются с задержкой; после последнего повтора или при окончательном отказе они попадают в dead-letter очередь, которую вы воспроизводите вручную.
Приёмники WORM / соответствие
S3 Object Lock в режиме governance или compliance для неизменяемого хранения; аудиторы сразу получают доказательство хранения.
Настройка приёмника
shell · curl
# 1. store each credential, get back a handle (company admin)
$ curl -X POST $CALDYR_URL/api/siem/secret-bindings \
-H "Authorization: Bearer $CALDYR_TOKEN" -H "Content-Type: application/json" \
-d '{"team_id": "<your-team-uuid>",
"field": "mtls_cert_ref",
"value": '"$(jq -Rs . < client.pem)"'}'
# → 201 {"handle": "<32 hex>", "ref": "vault-ref://h/<32 hex>", …}
# value is a PEM file, JSON-escaped by jq; repeat with field mtls_key_ref (key PEM) and mtls_bearer_ref (Splunk HEC token)
# 2. create the destination, referencing the returned refs
$ curl -X POST $CALDYR_URL/api/siem/destinations \
-H "Authorization: Bearer $CALDYR_TOKEN" -H "Content-Type: application/json" \
-d '{"name": "splunk-prod",
"kind": "splunk_hec",
"url": "https://splunk.example.com:8088",
"format": "ecs",
"batch_size": 100,
"auth_kind": "mtls",
"config": {
"mtls_cert_ref": "vault-ref://h/<cert handle>",
"mtls_key_ref": "vault-ref://h/<key handle>",
"mtls_bearer_ref": "vault-ref://h/<token handle>"}}'
Ваш SIEM, это источник истины, а мы лишь снабжаем его подписанными данными.
Когда придёт запрос по факту взлома, аудитор возьмёт ваши подписанные записи, а не наши. Мы лишь курьер.
Сравнение
| Caldyr | Вебхуки (без подписи) | Ручной экспорт логов | |
|---|---|---|---|
| Доставка в реальном времени | push · none, bearer, mTLS, JWT или Sentinel | POST без подписи | только пакетами |
| Подписанные конверты | блок Ed25519 · ключ компании | нет | нет |
| Повтор при переподключении | надёжный буфер | потеря при сбое | неприменимо |
| Несколько приёмников | все одновременно | один URL | вручную |
| Соответствие WORM | S3 Object Lock | нет | нет |
Частые вопросы
Неудачные доставки повторяются с задержкой, затем попадают в dead-letter очередь, которую можно воспроизвести. Control plane продолжает работать.
Да. Типичная схема: Splunk для SOC + S3 WORM для комплаенса + Datadog для инженеров, всё из одного потока событий с независимыми правилами фильтрации.
По умолчанию raw_json; для каждого приёмника также доступны ECS, CEF, LEEF, syslog и OCSF, а также пользовательские сопоставления полей через YAML-преобразование.
Правила фильтрации для каждого приёмника поддерживают jsonpath → redact. Поля с PII можно убрать до того, как они попадут в менее доверенные приёмники.
Готовы управлять своей ИИ-инфраструктурой?
Запросите доступ за пару минут, или обсудите с нами установку в air-gap.