Audit və dəyişməz jurnallar

Audit və dəyişməz jurnallar

1) Niyə lazımdır

Auditin məqsədi təhlükəsizliyi, araşdırmaları, maliyyə hesabatlarını və tələblərə uyğunluğu qorumaq üçün sübut olunan bütövlüklə «kim, nə, harada, nə vaxt və niyə» qeyd etməkdir.
Dəyişməz jurnal - hadisələrin yalnız əlavə etməklə (append-only) qeydə alındığı və sonrakı dəyişikliyin/silinməsinin mümkün olmadığı və ya kriptoqrafik vasitələr və saxlama siyasətləri ilə aşkar edilə biləcəyi format və anbar.

2) Təhdidlər modeli və nəzarət məqsədləri

• İnsayder tərəfindən hadisələrin qəsdən düzəldilməsi/silinməsi.
• Zamanın/mənbənin dəyişdirilməsi (replay/backdating).
• «Sakit» düyün log bağlamaq.
• Qəzalar/miqrasiyalar zamanı jurnalın bir hissəsinin itirilməsi.
• Artıq PII yığımı və gizlilik ilə uyğunsuzluq.

1. Bütövlük: modifikasiya/silinmədən qorunmaq üçün sübut edilə bilər.

2. Tamlıq: əsas axınların bağlanması (control plane, data plane, access, pul).

3. Zaman dəqiqliyi: təkrar, sinxronlaşdırılmış vaxt.

4. Əlçatanlıq: SLO daxilində oxu və axtarış.

5. Gizlilik: minimum PII, tokenizasiya/şifrələmə, istifadə qanuniliyi.

3) Taksonomiya və prioritetlər

• Control Plane: autentifikasiya/avtorizasiya, konfiqurasiya dəyişiklikləri, açar əməliyyatları (KMS), məxfi idarəetmə, siyasət dəyişikliyi.
• Data Plane: obyektlərə/qeydlərə/çekautlara/ödənişlərə giriş; oxu/yaratmaq/silmək.
• Admin və DevOps: SSH/konsol, CI/CD, infrastruktur dəyişiklikləri/IaC, hüquqların artması.
• Məhsullar: əməliyyatlar, billing, müştəri əməliyyatları.
• Sistem/şəbəkə: nüvə/agent/proxy/balans, broker, DB.
• Təhlükəsizlik: IDS/IPS/EDR, WAF, anti-DDoS, antifrod, DLP.

Hər sinif üçün qeyd edirik: kritiklik, sxem, məcburi sahələr, saxlama müddəti, dəyişməzlik tələbləri.

4) Məcburi sahələr və format

Korrelyasiya identifikatorları: 'trace _ id', 'span _ id', 'request _ id', 'actor _ id' (istifadəçi/xidmət), 'tenant _ id', 'resource _ id'.
A&A konteksti: autentifikasiya üsulu, fəaliyyət zamanı rollar/siyasət.
Vaxt: RFC3339/UTC, millisaniyə/nanosaniyə; sinxronizasiya mənbəyi.
Fəaliyyət və nəticə: əməliyyat növü, məqsədi, statusu, təsirlənmiş obyektlərin sayı.
Bütövlük: Yerli HMAC qeydləri, sıra nömrəsi (sequence), hash-prev.
Sxem: Sabit model ilə JSON (məsələn, ümumi hadisə lüğətləri ilə uyğun).

Sirlər, açarlar, tokenlər, tam PAN, şifrələr, şəxsi açarlar qadağandır. PII - yalnız zəruri hallarda, maskalanma/tokenizasiya ilə.

5) Vaxt və sinxronizasiya

Vaxt mənbəyi: ən azı iki müstəqil mənbə (NTP/PTP) + yerdəyişmə monitorinqi.
Kritik vaxt imzaları: Etibarlı vaxt nişanı xidmətlərindən (TSA) və ya hadisə paketləri üçün daxili vaxt izləmə xidmətindən istifadə edin.
Qaydalar: yerli saat zonaları yoxdur, yalnız UTC; loging və yerdəyişmə/vaxt keyfiyyəti.

6) Log axını arxitekturası

Agentlər → Bufer → Nəqliyyat → Landing → Hash Zənciri/İmza → Soyuq/Arxiv → Axtarış indeksi.

Montaj: yüngül agentlər (daemonset/sidecar) diskdə tampon ilə (back-pressure).
Nəqliyyat: təhlükəsiz kanal (TLS/mTLS), zəmanətli çatdırılma (at-least-once), idempotent-ingest.
Landinq zonası: «xam» formada obyektin saxlanması (tarix/tenant/tip üzrə partiyalar).
İndeks: online sorğular üçün axtarış/analitik mühərriki (isti təbəqə).
Arxiv (WORM): Retence siyasətləri və hüquqi hold ilə dəyişməz backets/lentlər.
Anchor/Seal: hash zəncir paketlərinin dövri «sızdırmazlığı» (aşağıya baxın).

7) Kriptoqrafik dəyişməzlik

7. 1 Hash zəncirləri (append-only)

Hər girişdə var: 'hash _ curr = H (record)', 'hash _ prev' əvvəlki girişdən, 'seq'. Hər hansı bir düzəliş zənciri qırır.

prev = GENESIS for record in stream:
payload = canonical_json(record_without_integrity_fields)
h = H(payload          prev.hash          record.seq)
store(record + {hash_prev: prev.hash, hash_curr: h})
prev = {hash: h}

7. 2 Paket imzası və vaxt möhürü

Hər N saniyə/MB bloku formalaşdırırıq: Merklin kökü bütün 'hash _ curr'.
Bloku audit açarı ilə imzalayırıq (davamlı olaraq KMS/HSM-də saxlanılır).
TSA vaxt nişanı əlavə edirik və «bloklar kataloqu» (Transparency Log) dərc edirik.
İsteğe bağlı: vaxtaşırı xarici sübut edilə bilən məkanda kökün çapa hash (məsələn, müstəqil jurnal və ya ictimai dəyişməz saxlama).

7. 3 Audit açarlarının idarə edilməsi

İmza açarları - KMS/HSM-də, qrafikə uyğun rotasiya, çoxfaktorlu giriş, ixrac üçün dual-control.
Açarın geri çağırılması → yeni etimad qolu; köhnə imzalar yoxlanılır.

8) Saxlama Siyasəti və WORM

WORM/immutability: P0/P1 sinifləri üçün Retention və Legal Hold siyasəti ilə dəyişməz konteynerləri/baketləri daxil edirik.
Version: daxil; çıxarılması - yalnız gecikmə prosedurları (ani purge qadağan).
Retensiya: isti (7-30 gün), isti (3-6 ay), soyuq/arxiv (1-7 il və daha çox - tənzimləyici/müqavilədən asılı olaraq).
Multi-icarə: kirayəçi üçün ayrı ad/hesab/şifrələmə açarları; jurnallara giriş hesabatı.

9) Gizlilik və minimallaşdırma

Zərurət prinsipi üzrə yığım: lazımsız bir şey qeyd etmirik.
Sensor sahələrin tokenizasiyası/təxəllüsü, identifikatorlar üçün duz ilə hash.
Ümumi obyektin anbarında saxlandıqda istehsalçının (AEAD) tərəfində sahələrin şifrələnməsi.
Silinmə hüququ (mümkün olan yerdə): konteynerin dəyişməzliyini pozmadan (layihələndirmə zamanı planlaşdırılır) sahələrin/hissələrin açarlarının kriptovalyutası vasitəsilə həyata keçirilir.

10) Giriş, rollar və audit özü

Bölmə: producers ≠ readers ≠ admins.
WORM yalnız oxumaq; retensiya siyasətinin dəyişdirilməsi - ayrı rollar və təsdiq proseduru vasitəsilə.
Bütün oxu/ixrac əməliyyatları ikinci dərəcəli jurnala (meta-audit) daxil edilir.
İstintaq/komplayens üçün ixrac - hash blokları kataloqu və etimad zənciri ilə şifrələnmiş formada.

11) Müşahidə və SLO

Metriklər: enjest sürəti, indeksə qədər gecikmə, itirilmiş/təkrar%, sinxronlaşdırılmamış vaxt payı, imza/armatür səhvləri, buferlərin doldurulması.
SLO: ≥99. Hadisələrin 9% -i isti indeksə ≤ X saniyə çatdırılıb; 0 ardıcıllıqla izah olunmayan «dəliklər»; Blokların 100% -i imzalanmış və vaxt ilə etiketlənmişdir.
Alertlər: enjest fasiləsi> N dəqiqə, invalid-hash böyüməsi, zəncir uyğunsuzluğu, imzanın/vaxt tamponunun uğursuzluğu, zamanın astanadan keçməsi.

12) Test və yoxlama

Red/Blue testlər: müxtəlif mərhələlərdə yazıları redaktə/silməyə cəhd; detection yoxlama.
Chaos: qovşaqda agentin bağlanması, şəbəkənin qırılması, bufer daşması, «vaxt dəyişdirilməsi».
Kriptovalyutalar: zəncirlərin müntəzəm validasiyası, Merklin köklərinin və ştampların müqayisəsi.
Forensika: end-to-end jurnallarından araşdırma ssenarilərinin səsləndirilməsi.

13) Əməliyyat və prosedurlar

Runbook «bütövlüyü yoxlamaq» (on-demand və cədvəl).
legal hold və partiyalar müvəqqəti «dondurma» proseduru.
Etibarlılıq zəncirini saxlayan discovery və ixrac proseduru.
Audit açarlarının rotasiya planı və güzəştə reaksiya (yeni etimad qolu, blokların yenidən imzalanması, bildirişlər).

14) Mini reseptlər

records = read_partition(ts_window)
leaves = [H(canonical_json(r)) for r in records]
root  = merkle_root(leaves)
sig   = KMS.sign(root          ts_now)
tsa   = TSA.timestamp(sig)
store_block({root, sig, tsa, count=len(leaves), window})
append_transparency_log(H(root          sig          tsa))

for i in 1..N:
assert rec[i].hash_prev == rec[i-1].hash_curr assert rec[i].hash_curr == H(canonical_json(rec[i]_no_hash)          rec[i].hash_prev          rec[i].seq)

• Control/Data plane P0: isti 30 gün → isti 6 ay → arxiv 7 il (WORM).
• DevOps: isti 14 gün → isti 3 ay → arxiv 1 il.
• Sekuriti siqnalları: isti 90 gün (araşdırmalar üçün), sonra 1-3 il.

15) Tez-tez səhvlər

«Loqi sxemsiz mətndir». Sxem olmadan determinated bütövlük və axtarış yoxdur; kanonik JSON və sabit sahələr tələb olunur.
Korrelyasiya yoxdur. 'trace _ id' olmaması araşdırmaları pozur.
Yerli vaxt. Yalnız UTC və ofset nəzarət.
Dəyişən cildlərə yazın. WORM olmadan hər hansı bir dəyişməzlik uydurmadır.
Oxu loqosu yoxdur. Həssas məlumatların oxunması qeyd qədər qeyd etmək vacibdir.
Yuvalarda sirləri. Göndərilməzdən əvvəl dezinfeksiyaediciləri, nümunələrin «qırmızı siyahılarını» daxil edin.
Hər şey üçün bir açar. İmza və şifrələmə açarları - ayrı-ayrılıqda, rol və rotasiya ilə.

16) Uyğunluq və tənzimləmə

Saxlama/dəyişməzlik şərtləri domendən asılıdır (maliyyə, ödəniş, telekom və s.).
Sübut olunma: WORM/retensiya protokollarının, zəncir validasiya hesabatlarının, jurnallara giriş jurnallarının, qanuni hold prosedurlarının və ixracatın mövcudluğu.

17) Çek vərəqləri

Məhsuldan əvvəl

• Hadisələrin taksonomiyası və sxemi (məcburi sahələr) təsdiq edilmişdir.
• Xüsusi agentlər, tamponlar, təhlükəsiz nəqliyyat, back-pressure.
• Daxildir: Hash zəncirləri, blok imzası, vaxt möhürü, transparency-log.
• WORM/Retance saxlama daxildir; yenidən yazmağın/silməyin mümkünsüzlüyü testi.
• Həssas sahələrin maskalanması/tokenləşdirilməsi.
• Vaxt sinxronizasiyası və yerdəyişmə monitorinqi.
• KMS/HSM-də rotasiya planı və audit açarlarının saxlanması.

Əməliyyat

• Zəncir və blokların həftəlik validasiyası (+ hesabat).
• Zəncir qırılması/imza səhvləri/vaxt yerdəyişməsi.
• Periodik Red-team testləri/silinməsi.
• Mütəmadi review gecikmələr və xərclər.

18) FAQ

S: BD səviyyəsində sadəcə «yalnız əlavə» kifayətdirmi?
A: Yox. Kriptoqrafik zəmanətlərə (heş zəncirləri, blok imzaları, zaman möhürləri) və WORM siyasətlərinə ehtiyac var.

S: Məlumatların silinməsi hüququ haqqında nə demək olar?
A: Media dəyişməzliyini və jurnalların sübuta yetirilməsini qoruyaraq, sahələr/partiyalar üçün kriptovalyuta silmə (açarların silinməsi) layihəsini hazırlayın.

S: Blokları imzalamaq üçün ayrıca açar lazımdırmı?
A: Bəli. Blok imza açarları saxlama şifrələmə açarlarından ayrılır; KMS/HSM-də, rotasiya və audit ilə saxlayın.

S: Ictimai məkanda «lövbər» etmək olarmı?
A: İsteğe bağlıdır. Bu, yoxlanılabilirliyi artırır və kontur daxilində «tarixin yenidən yazılmasını» kəsir.

• «At Rest şifrələmə»
• «In Transit Şifrələmə»
• «Sirlərin menecmenti»
• «Açarların idarə edilməsi və rotasiya»
• «Sorğuların imzalanması və yoxlanılması»