İşlem denetim günlükleri

(Bölüm: Operasyonlar ve Yönetim)

1) Amaç ve prensipler

Denetim izi, kayıtların değişmez ve otantik olduğunu kanıtlama yeteneği ile kimin, ne, nerede, ne zaman ve neden yaptığı hakkındaki temel gerçek kaynağıdır.

• Bütünlük: Kişilerin, hizmetlerin ve dış ortakların eylemleri kapsanır.
• Değişmezlik: Kayıtlar görünür bir iz olmadan üzerine yazılamaz/silinemez.
• Atıf: Eylem konu, rol, bağlam, eserler ile ilgilidir.
• Tekrarlanabilirlik - Olay bir raporda/anlaşmazlıkta tekrar oynatılabilir.
• PII minimizasyonu: sadece gerekli, maske ve belirteçlerle.

2) Kapsama alanları

Kullanıcı eylemleri: giriş/SSO/MFA, değişen roller/sınırlar, PII ile işlemler.
Ayrıcalıklı işlemler: JIT/PAM oturumları, kırılma camı, yönetici konsolu.
Finans: fiyat listeleri/vergiler/FX yayınları, ödemeler/ödemeler, emanet, yazmalar/iadeler.
Yapılandırmalar/sürümler: phicheflags, schema migrations, deploy/rollback, keys/certificates.
Entegrasyonlar: webhooks, imzalar, makbuzlar, idempotency anahtarları.
Veri: PII okuma/dışa aktarma, eserler oluşturma/silme, politikaları değiştirme.

3) Mimari ve değişmezlik

Kimlik doğrulama, kotalar ve devre doğrulama ile giriş ağ geçidi.
WORM depolama (değişmez kovalar/yalnızca ekleme): sürüm, Tutma Kilidi, Yasal Bekletme.
Crypto quitances: kritik olaylar için bir 'receipt _ hash've bir DSSE imzası oluşturulur.
Merkle zincirleri: periyodik olarak oluşturulmuş dilimler (kontrol noktası), kök hash yayınlanır.
Gözetim zinciri: Eserlerin hareketini izlemek (kim, ne zaman, neye dayanarak erişim sağladı).
Time Sync: NTP/PTP, 'event _ time've' ingest _ time 'etiketleri,' skew 'ayarı.

4) Olay diyagramı (referans)

audit_event {
id, event_time, ingest_time, producer, subject {
id, type: human    service    partner, roles[], mfa?, device_posture?
},
action: CREATE    READ    UPDATE    DELETE    EXECUTE    PUBLISH    APPROVE    ROLLBACK,
target { type, id, version?, region?, tenant? },
context { ip/asn, user_agent, env, trace_id, request_id },
policy_version, sod_check: pass    fail, justification?, ticket_ref?,
result: success    deny    error, error_code?,
diff_hash?, payload_hash?, receipt_hash?, dsee_signature?,
pii_classification: none    aggregated    tokenized    sensitive,
retention_class, labels[]
}

İsteğe bağlı: finansallar için - 'fx _ version/tax _ rule _ version/pricelist _ version'; webhooks için - 'webhook _ id', 'idempotency _ key'.

5) Veri modeli ve bölgeleri

Sıcak (RAM): 7-30 gün, hızlı istekler/panolar.
Sıcak (OLAP): 6-24 ay, analitik/aramalar.
Soğuk (arşiv/WORM): 7-10 yıla kadar (düzenleyici).
Saklama sınıfları: 'operasyonel', 'finansal', 'güvenlik', 'yasal _ hold'.
Policy versioning - tüm olaylar 'policy _ version'olarak işaretlenmiştir; Politika Değişikliği - Tek Denetim Olayı.

6) Erişim ve gizlilik

RBAC/ABAC/ReBAC: rol/kiracı/bölge/duruma göre görünürlük.
PII maskeleme: tanımlayıcıların tokenizasyonu, birincil çıktısı - sadece onaylanmış işler aracılığıyla.
Doğrudan silme yok: sadece 'mezar taşı' + Yasal Bekletme; Ayrı bir dergi ile "temizlik sonrası" planlandı.
Denetimin kendisinin denetimi: Günlükleri kimin izlediği/boşalttığı da kaydedilir.

7) Kalite, tutarlılık, alır

Veri sözleşmeleri: girişte sıkı şema ve lambda doğrulamaları.
Idempotency & dedup: '(event_id, yapımcı)'; "seen-cache" + KV.
Zaman düzeltme: Geç olaylar için filigranlar.
Tamlık kontrolü: Kaynak sayaçların ve alım metriklerinin karşılaştırılması.

8) Gösterge panoları ve sorgular

Operasyonel: ayrıcalıklı eylemler, SoD ihlalleri, JIT haklarının kaldırılması, PII'ye erişim.
Finansal: FX/Tax/PriceList yayınları, quote↔checkout tutarsızlıklar, anahtar imzalar.
Entegrasyonlar: webhook makbuzları, lag, retrai, alır.
Sürümler/yapılandırmalar: kim/ne zaman/ne açıldı/geri alındı, olaylarla bağlantı.
Arama komut dosyaları: 'trace _ id', 'subject. id ',' hedef. id ', zaman/bölge/kiracı,' policy _ version '.
İhracat: Makbuzla talep üzerine toplu yüklemeler (imzalı manifesto).

9) API'ler ve webhook'lar

'POST/audit/ingest' - alıcı olaylar (kimlik doğrulama, limitler, şema).
'GET/audit/search' - filtreler, sayfalama, sonuç sınırı.
'GET/audit/trace/{ trace _ id}'bir olaylar zinciridir.
'POST/audit/receipt/verify' - check bill/DSSE.
Вебхуки: 'SoDViolation', 'PrivilegedSession', 'PIIAccess', 'PolicyChanged', 'FinancialArtifactPublished'.

10) SLO/Denetim Kalitesi Metrikleri

Ingest Kullanılabilirliği: ≥ 99. 95%.
Tazelik (RAM): P95 ile 30 ≤ gecikme.
Bütünlük: ≥ 99. Kaynakların %5'i pencereye veri gönderdi.
Doğruluk: sağlama toplamı tutarsızlığı ≤ 0. 1%.
Kurcalama kanıtı: Dönemlerin %100'ü Merkle-roots/signatures tarafından onaylanmıştır.
PII Hijyeni: Hassas sınıfa sahip olayların %100'ü - maske/belirteç ile.

11) Oyun kitapları ve olaylar

Kayıt sahteciliği şüphesi: Merkle köklerinin derhal doğrulanması, DSSE makbuzlarının mutabakatı, erişim yalıtımı, Yasal Bekletme.
PII sızıntısı: etkilenen olayları/dışa aktarmaları arama, erişim denetimi, zaman çerçevesine göre DPO/düzenleyici bildirimleri.
SoD ihlali: Operasyon bloğu, geçici rol kaldırma, soruşturma ve politika ayarlama.
En büyük hata: tamponlama, bozulma modu, kurtarma işleminden sonra tekrar oynatma, yinelenen kontrol.

12) Yasal maruz kalma ve uyumluluk

Yargı Yetkisine Göre Tutma: Finans/Vergi - 5-10 yıl; güvenlik - politika ile; Kişisel veriler - minimum gerekli süre.
Yasal Bekletme: dava/regülatör isteğinde kaldırma donması.
Raporlama eserleri: dönem indeksi, kök karmaları, imzalayanların listesi, kaynakların envanteri.
İade edilemezlik: kripto imzaları, bağımsız zaman damgası (dahili TSA).

13) iGaming/fintech'in özgüllüğü

Ödemeler/ödemeler: yetkilerin tam takibi, takas, reddetmeler, geri ödeme; banka makbuzlarıyla eşleşiyor.
RTP/limitleri: profil yayınları, değişiklikler, gözlemlenen RTP ve sınır kararları - imzalar ve sürümle.
İştirakler: webhook'ların alınması, tekilleştirme dönüşümleri, itirazlar/emanet - yalnızca imzalı eserler için.
Fiyat listeleri/vergiler/FX: her siparişte eser sürümü; Geri dönüşler - makbuzlarla.

14) RACI

15) Riskler ve anti-kalıplar

İz bırakmadan düzenlenebilir günlükler - yasal olmayan destek.
Zaman senkronizasyonu yok - çakışmayan zaman çizelgeleri.
Makbuzsuz gölge ihracatlar - sızıntılar/anlaşmazlıklar.
Günlüklerdeki sırlar - uzlaşma.
SLO/olaylarla ilişki yok - fayda olmadan "veri mezarlığı".

16) Uygulama kontrol listesi

• Kapsama alanlarını ve policy_version tanımlayın.
• Kimlik doğrulama, şemalar ve kotalarla alımları dağıtın.
• WORM, Merkle dilimleri, DSSE imzaları, TSA'yı ekleyin.
• Sınıf ve Yasal Bekletme kurun.
• RBAC/ABAC/ReBAC ve denetim günlüğü erişimini girin.
• Panolar oluşturun: ayrıcalıklar, PII, finans, sürümler/yapılandırmalar.
• Oyun kitaplarını etkinleştir: kurcalama, PII sızıntısı, emme hatası, SoD ihlali.
• Bir test setinde tekrarları ve dedup deneyin.
• Makbuzlar ve sorgu kaydı ile dışa aktarın.
• Üç aylık kalite ölçümleri denetimleri gerçekleştirin (tazelik/eksiksizlik/kurcalama).

17) SSS

Her şeyi düzenli bir veritabanında saklamak mümkün mü?
RAM için - evet, ancak kritik günlükler WORM/append-only imzalar ve Merkle dilimleri ile çoğaltılmalıdır.

Okunan her veriyi kaydetmem gerekiyor mu?
PII/Finans okuma zorunludur; Gerisi politika ve maliyetle.

Değişmezlik nasıl kanıtlanır?
Kök hash'ler, DSSE imzaları, bağımsız TSA ve tekrarlanabilir doğrulama prosedürleri.

"Kaldırma hakkı" (GDPR) ile ne yapmalı?
İşleme sistemlerinde birincil silin; Denetim günlüklerinde - kurtarılabilir PII olmadan belirteçleri/karmaları saklayın ve gerekirse Yasal Bekletmeyi sürdürün.

Özet: Denetim günlükleri "giriş kayıtları'değil S3, açık politikalar, değiştirilemez saklama, yönetilen erişim ve anlaşmazlık/düzenleyici inceleme hazırlığı ile kriptografik olarak kanıtlanabilir bir eylem geçmişidir. Sözleşmeler üzerine satın alın, kritik olayları imzalayın, Merkle kesimlerini ve gösterge tablolarını destekleyin - böylece sağlam bir güven, güvenlik ve uyumluluk temeline sahip olursunuz.