Bir compliance yetkilisi mühendislik odasına girer ve şöyle der: "Yeni raporlama pipeline'ı için bir audit trail'e ihtiyacımız var." Baş mühendis cevap verir: "Her işlemi 90 günlük saklama süresiyle ELK'ya zaten logluyoruz." Herkes toplantıdan memnun ayrılır. Altı ay sonra, bir BDDK incelemesi veya IRS FATCA değerlendirmesi sırasında, biri belirli bir tarihteki bir poliçe sahibi kaydının kesin durumunu yeniden oluşturmayı, kimin değiştirdiğini kanıtlamayı ve değişikliğin sonradan tahrif edilemeyeceğini göstermeyi ister. Loglar bunu yapamaz. Kimse mühendise bunu yapması gerektiğini söylememiştir.
Bu pipeline'ı tam olarak üç kez kurdum veya yeniden kurdum — GEV'in sigorta raporlaması, HAYMER'in hayat ve emeklilik veri ambarı ve ABD Hazinesi'ne yapılan FATCA bildirimleri için. Log ile audit trail arasındaki ayrım bir sözcük meselesi değildir. Bir mimari meselesidir.
Mühendisler Logging Derken Neyi Kasteder
Uygulama logging'i, mühendislerin sistemleri debug etmesine yardımcı olmak için vardır. Tasarım varsayımları şunlardır:
- Değiştirilebilir ve döndürülebilir. Loglar truncate edilir, sıkıştırılır, soğuk depolamaya gönderilir ve sonunda silinir.
- Best-effort. Düşen bir log satırı can sıkıcıdır, felaket değildir. Çoğu logging kütüphanesi backpressure altında sessizce başarısız olur.
- Olay-şekilli, durum-şekilli değil. "Kullanıcı 4471 form gönderdi" bir şey olduğunu söyler. Kaydın önceden veya sonradan nasıl göründüğünü söylemez.
- Serbest formlu. Şema, geliştiricinin format string'ine yazmak istediği şeydir.
- Ucuz saklama. 30, 60, belki 90 gün. Daha uzun olursa cost ekibi soru sormaya başlar.
Bu, bir batch job'un sabah 3'te neden başarısız olduğunu teşhis etmek için iyidir. İki yıl sonra, belirli bir sınır ötesi ödemedeki bir vergi stopajı hesaplamasının doğru, yetkilendirilmiş ve tahrif edilmemiş olduğunu bir düzenleyiciye kanıtlamak için işe yaramaz.
Düzenleyiciler Audit Trail Derken Neyi Kasteder
SPK, BDDK veya IRS bir audit trail istediğinde, yasal bir kanıt zinciri istemektedir. Zımni gereksinimler:
- Değiştirilemez. Bir kez yazıldığında, kayıt değiştirilemez. Append-only tabandır, tavan değil. Önceki durumların kriptografik hash'lenmesi giderek daha fazla beklenmektedir.
- Tam durum yakalama. Düzenlenen bir alandaki her değişiklik — prim tutarları, lehtar kimlikleri, vergi mukimliği durumu — önceki değeri, sonraki değeri, aktörü, zaman damgasını, kaynak sistemi ve iş gerekçesini kaydetmelidir.
- Yeniden oluşturulabilir. Geçmiş herhangi bir tarih verildiğinde, bir kaydın o tarihte var olduğu kesin durumu materyalize edebilmelisiniz. Bu, log araması değil, point-in-time sorgulamadır.
- Uzun saklama. FATCA altı yıl ister. Türk sigorta düzenlemeleri onu zorlar. Bazı emeklilik verileri fiilen kalıcıdır.
- Chain of custody. Veriyi kim, ne zaman, kime ve hangi yetkilendirme altında dışa aktardı. Audit trail'in kendisinin de bir audit trail'e ihtiyacı vardır.
Bunlar uygulama loglarınızla aynı sistem değildir. Aynı sistem olamazlar.
Açığın Pahalıya Mal Olduğu Yer
HAYMER pipeline'ında, poliçe değişikliği feed'inin erken bir versiyonu, değişiklikleri izlemek için uygulama logging'ini kullanıyordu. İç denetim, 2019'daki belirli bir iştira değeri hesaplamasının doğru mortalite tablosu versiyonunu kullandığını kanıtlamamızı istediğinde, bir değişiklik olduğunu görebildik. Önceki değeri, yürürlükteki tablo versiyonunu veya yeniden hesaplamanın bir sistem job'u tarafından mı yoksa manuel bir override ile mi tetiklendiğini gösteremedik. Loglar döndürülmüştü. Uygulama veritabanı taşınmıştı. Cevap teknik olarak bilinemezdi.
Düzeltme daha fazla logging değildi. Ayrı bir şemaydı:
- Delta'ları değil, tam satır anlık görüntülerini içeren append-only bir
policy_state_historytablosu - Her durum değişikliğini ticket'lı bir iş gerekçesine bağlayan bir
change_authorizationtablosu - Hangi pencerelerde hangi hesaplama motoru ve hangi aktüeryal tablo versiyonlarının canlı olduğunu yakalayan bir
system_version_registry - Ayrı bir custodian sistemine aktarılan üç aylık kriptografik checksum'lar
Bunların hiçbiri ELK'da yaşamaz. Hiçbiri de yaşamamalı.
Pratik Şema Çıkarımları
Er ya da geç bir düzenleyicinin karşısına çıkacak bir şey inşa ediyorsanız, bunlara baştan karar verin:
- İki sistemi tamamen ayırın. Uygulama logları ve audit trail'ler farklı SLA'lara, farklı saklama sürelerine, farklı erişim kontrollerine ve farklı tüketicilere sahiptir. Onları birleştirmek her ikisinden de ödün vermek anlamına gelir.
- SCD Type 2, Type 1 değil. Slowly Changing Dimensions Type 2, düzenlenen herhangi bir varlık için minimum çıtadır. Effective-from, effective-to, current-flag, source-change-id. Üzerine yazma yok.
- Aktörü yakalayın, sadece eylemi değil. "Sistem kaydı güncelledi" değersizdir. "Scheduler ID 88419 tarafından tetiklenen FATCA_DAILY_v2.3.1 batch job'u, svc_fatca_prod servis hesabı altında kaydı güncelledi" denetlenebilirdir.
- Niyeti yakalayın. Belgelenmiş bir nedeni olmayan bir değişiklik, ortaya çıkmayı bekleyen bir bulgudur. Düzenlenen her değişikliği bir ticket'a, bir iş kuralı ID'sine veya bir düzenleyici atıfa bağlayın.
- Saklamayı ilk günden planlayın. 90 günlük döndürme için tasarlanmış bir tabloya altı yıllık saklamayı sonradan eklemek bir config değişikliği değil, bir migrasyon projesidir.
Düzenleyici Toplantısına Kim Gider
Mühendislerin hafife aldığı kısım budur. Müfettiş masaya oturduğunda, karşıdaki kişi — sade bir dille, baskı altında, elinde şema diyagramlarıyla — audit trail'in nasıl çalıştığını, neden değiştirilemeyeceğini ve belirli bir tarihsel durumun nasıl yeniden oluşturulduğunu açıklamalıdır. Eğer o kişi, mühendisin üç yıl önce yazdığı bir belgeyi okuyan compliance yetkilinizse, toplantı kötü geçer. Eğer sistemi tasarlayan mühendisse, toplantı kısa olur ve bulgu kapanır.
Audit trail, kurum ile düzenleyici arasında, çoğu zaman imzaladıklarını fark etmeyen veri mühendisleri tarafından aracılık edilen bir sözleşmedir. Bunu bir logging problemi olarak ele almak, denetimlerin nasıl mimari yeniden yazımlarına dönüştüğüdür — ve mimari yeniden yazımlarının da düzenleyiciden mektup gelene kadar kimsenin bütçelemediği türden bir projeye nasıl dönüştüğüdür.
İlk seferinde doğru inşa edin. Ya da iki kez inşa edin.