Jälgitavus
Voogedasta iga sündmus oma SIEM-i, allkirjastatuna ja kontrollitavana.
Auditi- ja turvasündmused edastatakse reaalajas Splunki, Datadogi, Elasticusse, Microsoft Sentinelisse, S3 WORM-i, tavalisse syslogisse või üldisesse HTTPS-webhooki (Enterprise'i pakett). Iga sündmus kannab auditirea Ed25519 allkirja ja selle teinud võtme id-d; teie ettevõtte avalik võti avaldatakse aadressil /audit/pubkey/:company_id. Ebaõnnestunud edastusi korratakse kasvava ooteajaga kuni ühe päeva, seejärel parkitakse need kirjete järelejäämise järjekorda (dead-letter queue), kust saab need uuesti esitada.
Caldyr
Splunk
Datadog
Elastic
Sentinel
S3 WORM
Syslog
Kuidas see töötab
1
Sündmus väljastatakse
Auditirida allkirjastatakse ja edastatakse SIEM-i tõukajale.
2
Allkirjaplokk lisatakse
Ümbrik on auditirida koos oma allkirjaplokiga: sig, key_id, pubkey_fp, prev_hash, payload_hash. Üks allkirjastamisvõti ettevõtte kohta, mitte sihtkoha kohta.
3
Edastatakse sinu sihtkohta
Kuus autentimisrežiimi sihtkoha kohta - none, bearer, mTLS, signed JWT, Sentinel OAuth2 ja Sentinel shared key - ning režiimita sihtkoht saab none. mTLS ja signed JWT ei saada jagatud saladust; bearer saadab igal edastusel sihtkoha enda loa, Sentinel OAuth2 Azure AD juurdepääsuloa, Sentinel shared key tööruumi võtmest tuletatud HMAC-i, ning Splunk ja Datadog saadavad oma loa ka mTLS-i all. HTTP-sihtkohad nõuavad https:// ja syslog üle TCP nõuab TLS-i, kuid syslog üle UDP on krüpteerimata.
4
Kordus taasühendamisel
Ebaõnnestunud edastusi korratakse kasvava ooteajaga kuni 24 tundi, seejärel parkitakse need kirjete järelejäämise järjekorda (dead-letter queue), kust saab need uuesti esitada.
Süvavaated
Allkirjastatud ümbrikud
Plokk on Ed25519 allkiri salvestatud auditirea kohta, aheldatud eelmise reaga: sig, key_id, pubkey_fp, prev_hash, payload_hash. raw_json, ECS, OCSF ja syslog kannavad kõiki viit; CEF ja LEEF kannavad ainult allkirja ja võtme id-d. Teie ettevõtte avalik võti avaldatakse aadressil /audit/pubkey/:company_id ning me ei tarni teie poole jaoks ühtegi kontrollijat: ploki kontrollimine on teie SIEM-i töö. Filtriteisendustega sihtkoha puhul katab allkiri rea sellisena, nagu see oli enne teisendust.
Kohaletoimetamise garantiid
Vähemalt-üks-kord idempotentsete ID-dega. Ebaõnnestunud partiisid korratakse kasvava ooteajaga; pärast viimast katset või püsiva tagasilükkamise korral parkitakse need kirjete järelejäämise järjekorda (dead-letter queue), kust saad need käsitsi uuesti esitada.
WORM / vastavussihtkohad
S3 Object Lock haldus- või vastavusrežiimis muutumatuks salvestamiseks: audiitorid saavad säilitustõendi kohe.
Seadista sihtkoht
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>"}}'
Teie SIEM on tõe allikas - meie lihtsalt toidame seda, allkirjastatuna.
Kui rikkumise juurdlus saabub, kasutab audiitor teie allkirjastatud kirjeid, mitte meie omi. Meie oleme kuller.
Võrdle
| Caldyr | Webhookid (allkirjastamata) | Käsitsi logiväljastus | |
|---|---|---|---|
| Reaalajas kohaletoimetamine | edastus · none, bearer, mTLS, JWT või Sentinel | allkirjastamata POST | ainult pakett |
| Allkirjastatud ümbrikud | Ed25519 plokk · ettevõtte võti | ei | ei |
| Kordus taasühendamisel | püsiv puhver | tõrke korral kadu | puudub |
| Mitu sihtkohta | kõik korraga | üks URL | käsitsi |
| WORM-vastavus | S3 Object Lock | ei | ei |
KKK
Ebaõnnestunud edastusi korratakse kasvava ooteajaga ja seejärel parkitakse need kirjete järelejäämise järjekorda (dead-letter queue), kust saab need uuesti esitada. Juhtimiskiht töötab edasi.
Jah. Tavaline seadistus on Splunk SOC-i jaoks + S3 WORM vastavuse jaoks + Datadog arenduse jaoks: kõik samast sündmustevoost sõltumatute filtrireeglitega.
Vaikimisi raw_json; sihtkohapõhiselt on saadaval ka ECS, CEF, LEEF, syslog ja OCSF variandid, samuti kohandatud väljavastendused YAML-teisenduse kaudu.
Sihtkohapõhised filtrireeglid toetavad jsonpath → varjamine. PII-väljad saab eemaldada enne, kui need jõuavad madalama usaldusega sihtkohtadesse.
Valmis oma AI-infrastruktuuri haldama?
Taotle ligipääsu mõne minutiga, või räägi meiega oma õhulõhega juurutusest.