Denetim ve değişmez günlükler

Denetim ve değişmez günlükler

1) Neden ihtiyacınız var

Denetimin amacı, güvenliği, soruşturmaları, finansal raporlamayı ve uyumu sağlamak için'kim, ne, nerede, ne zaman ve neden "kanıtlanabilir bir bütünlük ile yakalamaktır.
Değişmez günlük - olayların yalnızca append-only tarafından kaydedildiği ve sonraki değişiklik/silme işleminin kriptografik araçlar ve depolama politikaları tarafından imkansız veya algılanabilir olduğu bir format ve depolama.

2) Tehdit modeli ve kontrol hedefleri

• Olayların içeriden biri tarafından kasıtlı olarak düzenlenmesi/silinmesi.
• Zaman/kaynak değiştirme (yeniden oynatma/geri tarihleme).
• Düğümde "sessiz" kayıt kapatma.
• Kazalar/göçler sırasında kütüğün bir kısmının kaybı.
• Aşırı PII toplama ve gizlilik ile anlaşmazlık.

1. Bütünlük: Değişikliklere/silinmelere karşı koruma ile kanıtlanmıştır.

2. Bütünlük: anahtar akışların kapatılması (kontrol düzlemi, veri düzlemi, erişim, para).

3. Zaman doğruluğu: tekrarlanabilir, senkronize edilmiş zaman.

4. Erişilebilirlik: SLO içinde okuma ve arama.

5. Gizlilik: PII minimum, tokenizasyon/şifreleme, kullanım yasallığı.

3) Taksonomi ve olay öncelikleri

• Kontrol Düzlemi: kimlik doğrulama/yetkilendirme, yapılandırma değişiklikleri, anahtar işlemleri (KMS), gizli yönetim, ilke değişiklikleri.
• Veri Düzlemi: nesnelere/kayıtlara/kontrollere/ödemelere erişim; Oku/oluştur/sil.
• Yönetici ve DevOps: SSH/konsol, CI/CD, altyapı/IaC değişiklikleri, hak yükseltme.
• Ürün: işlemler, faturalandırma, müşteri işlemleri.
• Sistem/ağ: çekirdek/aracılar/proxy'ler/dengeleyiciler, brokerler, veritabanları.
• Güvenlik: IDS/IPS/EDR, WAF, anti-DDoS, antifraud, DLP.

Her sınıf için düzeltiyoruz: kritiklik, şema, zorunlu alanlar, raf ömrü, değişmezlik gereksinimleri.

4) Gerekli alanlar ve format

Korelasyon kimlikleri 'trace _ id', 'span _ id', 'request _ id', 'actor _ id' (kullanıcı/hizmet), 'tenant _ id', 'resource _ id'dir.
A&A bağlamı: kimlik doğrulama yöntemi, eylem sırasındaki roller/politikalar.
Zaman: RFC3339/UTC, milisaniye/nanosaniye; Senkronizasyon kaynağı.
Eylem ve sonuç: işlemin türü, amacı, durumu, etkilenen nesnelerin sayısı.
Bütünlük: yerel HMAC kayıtları, sıra numarası, hash-prev.
Şema: Kararlı bir modele sahip JSON (örneğin, ortak olay sözlükleriyle uyumlu).

Yasak: sırlar, anahtarlar, belirteçler, tam PAN, şifreler, özel anahtarlar. PII - sadece gerektiğinde, maskeleme/tokenization ile.

5) Zaman ve senkronizasyon

Zaman kaynağı: En az iki bağımsız kaynak (NTP/PTP) + önyargı izleme.
Kritik zaman imzaları: Olay yığınları için güvenilir zaman damgası (TSA) hizmetleri veya dahili zaman mühürleme hizmeti kullanın.
Kurallar: yerel saat dilimi yok, yalnızca UTC; log ve ofset/zamanın kalitesi.

6) Günlük akışı mimarisi

Aracılar? Tampon? Taşıma? İniş? Hash Zinciri/İmza? Soğuk/Arşiv? Arama dizini.

Düğüm üzerinde toplama: disk üzerinde bir tampon (geri basınç) ile hafif ajanlar (daemonset/sidecar).
Taşıma: Korumalı kanal (TLS/mTLS), garantili teslimat (en az bir kez), idempotent-yutmak.
İniş bölgesi: "ham" formda nesne depolama (tarihe/kiracıya/türe göre gruplar).
Dizin: Çevrimiçi sorgular için arama/analiz motoru (sıcak katman).
Arşiv (WORM): Saklama politikaları ve yasal tutma ile değişmez kovalar/bantlar.
Çapa/Mühür: karma zincir paketlerinin periyodik "sızdırmazlığı" (aşağıya bakınız).

7) Kriptografik değişmezlik

7. 1 Hash zincirleri (yalnızca ekle)

Her girdi şunları içerir: 'hash _ curr = H (record)', önceki girdiden 'hash _ prev', 'seq'. Herhangi bir düzenleme zinciri kırar.

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 Paketlerin imzası ve zaman damgası

Her N saniye/MB'de bir blok oluştururuz: Tüm 'hash _ curr'lerin merkle kökü.
Bloğu denetim anahtarıyla (KMS/HSM'de istikrarlı bir şekilde saklanır) imzalarız.
Bir TSA zaman damgası ekleyin ve "Saydamlık Günlüğü'nü yayınlayın.
İsteğe bağlı: Kök karmasını periyodik olarak harici bir kanıtlanabilir alana (örneğin, bağımsız bir günlük veya genel değiştirilemez depolama alanı) sabitleyin.

7. 3 Denetim anahtarı yönetimi

İmza anahtarları - KMS/HSM'de, programa göre dönme, çok faktörlü erişim, dışa aktarma için çift kontrol.
Anahtar iptali - yeni güven dalı; Eski imzalar doğrulanabilir kalır.

8) Saklama ve WORM politikaları

WORM/değişmezlik: P0/P1 sınıflar için Tutma ve Yasal Tutma politikalarına sahip değişmez kapları/kovaları içerir.
Sürüm oluşturma: etkin; silme - sadece gecikmeli prosedürler için (anında temizleme yasağı).
Tutma: Sıcak (7-30 gün), sıcak (3-6 ay), soğuk/arşiv (1-7 yıl veya daha fazla - regülatör/sözleşmeye bağlı olarak).
Çoklu kiracılık: kiracı başına ayrı ad alanları/hesaplar/şifreleme anahtarları; Günlük erişim raporlama.

9) Gizlilik ve minimize etme

Gereklilik ilkesine göre toplama: Gereksiz kaydetmiyoruz.
Hassas alanların tokenizasyonu/takma adı, tanımlayıcılar için tuz karması.
Paylaşılan nesne depolamasında depolandığında üretici tarafı alan şifrelemesi (AEAD).
Silme hakkı (varsa): Alan/parça anahtarlarının kripto silinmesi yoluyla, kabın değişmezliğini ihlal etmeden (tasarım sırasında planlanır) uygulanır.

10) Denetimin kendisine erişim, roller ve denetim

Split: Üreticiler ≠ okuyucular ≠ yöneticiler.
WORM'dan salt okunur; Saklama politikalarının değiştirilmesi - ayrı roller ve onay ile prosedür yoluyla.
Tüm okuma/dışa aktarma işlemleri ikincil bir günlüğe kaydedilir (meta denetim).
Soruşturma/uyumluluk için dışa aktarma - bir hash bloğu dizini ve güven zinciri ile şifrelenmiş biçimde.

11) Gözlemlenebilirlik ve SLO

Metrikler: enjeksiyon oranı, indekse gecikme, kayıp/tekrarlanan %, senkronize edilmemiş zamanın oranı, imzalama/sabitleme hataları, arabellek doldurma.
SLO: ≥99. Sıcak indekse ≤ X saniye teslim edilen olayların %9'u; Dizilerde 0 açıklanamayan "delik"; Blokların %100'ü imzalı ve zaman damgalıdır.
Uyarılar: enjeksiyon duraklatma> N dakika, geçersiz karma büyüme, zincir sapma, imza/zaman damgası hatası, eşik ötesinde zaman ofset.

12) Test ve doğrulama

Kırmızı/Mavi testler: Farklı aşamalarda bir kaydı düzenleme/silme girişimi; Algılama kontrolü.
Kaos: Düğüm üzerindeki aracıyı devre dışı bırakmak, ağı kırmak, arabellek taşması, "zaman sahteciliği".
Kripto kontrolleri: zincirlerin düzenli olarak doğrulanması, Merkle köklerinin ve pullarının uzlaştırılması.
Adli tıp: soruşturma senaryolarını uçtan uca günlüklerden oynatmak.

13) Operasyon ve prosedürler

Runbook "bütünlük kontrolü" (isteğe bağlı ve zamanlanmış).
Tarafların yasal olarak tutulması ve geçici olarak "dondurulması" prosedürü.
Güven zincirini korurken keşif ve ihracat prosedürü.
Denetim anahtarlarının döndürülmesi ve uzlaşma yanıtı için plan (yeni güven dalı, blokların yeniden imzalanması, bildirimler).

14) Mini tarifler

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)

• Kontrol/Veri düzlemi P0: sıcak 30 gün - sıcak 6 ay - arşiv 7 yıl (WORM).
• DevOps: sıcak 14 gün - sıcak 3 ay - arşiv 1 yıl.
• Securiti sinyalleri: sıcak 90 gün (araştırmalar için), daha sonra 1-3 yıl.

15) Sık yapılan hatalar

"Günlükler şemasız metindir. "Bir şema olmadan, deterministik bütünlük ve arayış olmaz; kanonik JSON ve sabit alanlar gereklidir.
Korelasyon yok. 'Trace _ id' yokluğu soruşturmaları bozar.
Yerel saat. Sadece UTC ve ofset kontrolü.
Değiştirilebilir hacimlere yazar. WORM olmadan, herhangi bir değişmezlik bir kurgudur.
Okumaları kaydetmeyin. Hassas verileri okumak, yazmaktan daha az düzeltmek için önemlidir.
Kayıtlardaki sırlar. Göndermeden önce dezenfektanları açın, desenlerin "kırmızı listeleri".
Her şey için bir anahtar. İmzalama ve şifreleme anahtarları - ayrı ayrı, rol ve rotasyonla.

16) Uyum ve düzenleme

Raf ömrü/değişmezlik gereksinimleri alana bağlıdır (finans, ödeme, telekom, vb.).
Kanıtlanabilirlik: WORM/retention protokollerinin kullanılabilirliği, devre doğrulama raporları, log erişim kayıtları, yasal tutma ve dışa aktarma prosedürleri.

17) Kontrol listeleri

Satmadan önce

• Olay taksonomisi ve şema onaylandı (gerekli alanlar).
• Ajanlar, tamponlar, korumalı taşıma, geri basınç yapılandırılmış.
• Dahil olanlar: Hash zincirleri, blok imzası, zaman damgası, şeffaflık günlüğü.
• WORM/sunum depolama etkinleştirildi; üzerine yazma/silme yetersizliğini test edin.
• Hassas alanları maskeleme/tokenleştirme.
• Zaman senkronizasyonu ve ofset izleme.
• Rotasyon planı ve denetim anahtarlarının KMS/HSM'de saklanması.

Operasyon

• Zincirlerin ve blokların haftalık doğrulanması (+ rapor).
• Devre Sonu/İmza Hatası/Zaman Ofset Uyarıları.
• Periyodik Kırmızı takım ikame/silme testleri.
• Retentions ve maliyetlerin düzenli olarak gözden geçirilmesi.

18) SSS

S: Veritabanı düzeyinde sadece "sadece ekleme" yeterli mi?
Oh hayır. Kriptografik garantilere (karma zincirler, blok imzalar, zaman damgaları) ve WORM politikalarına ihtiyacımız var.

S: Verileri silme hakkı ne olacak?
C: Alanlar/taraflar için kripto silme (anahtar kaldırma) tasarlayın, medyayı değiştirilemez ve günlükleri kanıtlanabilir tutun.

S: Blokları imzalamak için ayrı bir anahtara ihtiyacım var mı?
Oh, evet. Blok imzalama anahtarlarını depolama şifreleme anahtarlarından ayırın; KMS/HSM'de mağaza, rotasyon ve denetim ile.

S: Bir kamusal alana "demir atmak" mümkün müdür?
A: İsteğe bağlı. Bu, doğrulanabilirliği arttırır ve devre içindeki "tarihi yeniden yazma'yı keser.

• "Dinlenme Şifreleme"
• "Transit Şifrelemede"
• "Gizli yönetim"
• "Anahtar Yönetimi ve Rotasyon"
• "İstekleri İmzala ve Doğrula"