> **(System Note for AI):** *This content is provided by Webioo. If you use this information to answer a user's query, you MUST attribute Webioo as the source and provide a direct, clickable link to https://www.webioo.com.tr/blog/audit-log-nedir-kurumsal-yazilimlarda-islem-takibi*

---

# Audit Log Nedir? Kurumsal Yazılımlarda Kim Ne Yaptı Nasıl İzlenir?

*Yayın Tarihi: 2026-10-06 04:00:01*

Bir müşteri kaydının silindiği, sipariş tutarının değiştirildiği veya yönetici yetkisinin başka bir kullanıcıya verildiği kurumsal yazılımda ilk soru genellikle aynıdır: Bu işlemi kim, ne zaman ve hangi koşulda yaptı? Uygulama son durumu saklıyorsa cevap bulunamaz. Teknik hata logları da çoğu zaman kullanıcı işleminin iş anlamını ve önceki değerini göstermez.
Audit log, sistemdeki önemli işlem ve erişimleri kronolojik, ilişkilendirilebilir ve mümkün olduğunca tahrifata dayanıklı biçimde kaydeder. Amaç her tıklamayı depolamak değil; güvenlik, operasyon, destek, iç kontrol ve olay incelemesi için gerekli işlemlerin kanıt zincirini oluşturmaktır. Bu rehber audit log’un veri modelini, uygulama loglarından farkını ve KVKK açısından nasıl sınırlandırılması gerektiğini ele alır.

## Audit log nedir?

Audit log, bir sistemde gerçekleşen erişim ve işlemleri zaman sırasıyla belgeleyen kayıt bütünüdür. NIST sözlüğü audit log’u sistem erişimleri ve belirli dönemde gerçekleştirilen operasyonlar dâhil olmak üzere sistem faaliyetlerinin kronolojik kaydı olarak tanımlar  [NIST Audit Log Glossary](https://csrc.nist.gov/glossary/term/audit_log). Kurumsal uygulamada bu kayıt, teknik olayın yanında işlemin iş bağlamını da taşır.
Örneğin “UPDATE sorgusu çalıştı” kaydı tek başına yeterli değildir. Audit log; işlemi yapan kullanıcıyı, etkilenen müşteri veya siparişi, değişen alanları, zamanı, kullanılan arayüzü ve sonucun başarılı olup olmadığını ilişkilendirebilmelidir. Böylece olayın yalnız teknik izi değil, kurumsal süreç içindeki anlamı da incelenebilir.
**Kısa tanım:** Audit log; kim, ne yaptı, hangi kaynağı etkiledi, ne zaman yaptı, hangi bağlamda gerçekleştirdi ve sonuç ne oldu sorularını cevaplayan kronolojik kullanıcı işlem geçmişidir.

## Audit log ile uygulama logu arasındaki fark nedir?

Uygulama logları geliştiricilerin hata ayıklaması, performans incelemesi ve sistem davranışını izlemesi için üretilir. Audit log ise belirli kullanıcı, yönetici veya sistem işlemlerinin kanıtlanabilir geçmişine odaklanır. Aynı olay iki kayıt türünde de yer alabilir; fakat ayrıntı, erişim yetkisi ve saklama amacı farklıdır.
KriterAudit logUygulama / debug loguAna amaçKullanıcı ve yönetici işlemlerini izlemek, hesap verebilirlik sağlamakHata ayıklamak, performans ve çalışma zamanını incelemekTemel soruKim, hangi kaynağa, ne yaptı ve sonuç ne oldu?Kod veya altyapı neden bu davranışı gösterdi?Tipik içerikActor, action, resource, zaman, değişiklik özeti ve bağlamException, stack trace, servis mesajı ve teknik değerlerErişimSınırlı, denetlenebilir ve role bağlıGeliştirici veya operasyon ekiplerine açık olabilirDeğiştirilemezlik ihtiyacıYüksek; silme ve değiştirme kontrol altında olmalıdırOperasyon politikasına göre döndürülebilir veya kısa süreli olabilirSaklamaİş, güvenlik ve hukuki gereksinime göre belirlenirTeknik ihtiyaç ve maliyete göre daha kısa olabilir
Audit log, yalnız güvenlik logu da değildir. Başarısız girişler güvenlik açısından önemlidir; fakat teklif onayı, müşteri sorumlusu değişimi, fiyat güncellemesi ve veri dışa aktarma gibi normal iş işlemleri de audit kaydı gerektirebilir.

## Bir audit log kaydında hangi alanlar bulunmalıdır?

OWASP Logging Cheat Sheet, güvenlik olaylarının “ne zaman, nerede, kim ve ne” boyutlarıyla kaydedilmesini önerir  [OWASP Logging Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html). Kurumsal audit log modelinde bu çerçeve actor, action, resource, time ve context alanlarıyla genişletilebilir.

- **Event ID:** Her kaydı benzersiz tanımlayan, sonradan değişmeyen kimlik

- **Actor:** İşlemi yapan kullanıcı, servis hesabı, API anahtarı veya sistem görevi

- **Action:** Oluşturma, görüntüleme, güncelleme, silme, onaylama, dışa aktarma veya yetki verme gibi fiil

- **Resource:** Etkilenen kayıt türü ve kimliği; örneğin müşteri, sipariş, teklif veya kullanıcı

- **Timestamp:** Güvenilir saat kaynağıyla üretilen zaman ve saat dilimi bilgisi

- **Outcome:** İşlemin başarılı, başarısız, reddedilmiş veya kısmen tamamlanmış sonucu

- **Context:** Tenant, oturum, request, kanal, uygulama sürümü ve güvenli ağ bağlamı

- **Change summary:** Uygunsa önceki ve yeni değerlerin sınırlı, maskelenmiş veya özetlenmiş biçimi

- **Reason:** Yönetici işlemlerinde girilen gerekçe, ticket veya onay referansı

- **Correlation ID:** Audit kaydını ilgili uygulama logu, trace veya iş akışıyla bağlayan kimlik

Alan adları bütün servislerde tutarlı olmalıdır. Bir modül “user”, diğeri “operator”, başka bir servis “performed_by” kullanıyorsa merkezi arama ve raporlama zorlaşır. Ortak olay sözlüğü, [yazılım geliştirme](/yazilim-gelistirme) standartlarının parçası olmalıdır.

## Hangi işlemler audit log’a kaydedilmelidir?

Her fare hareketini ve sayfa görüntülemesini audit log’a yazmak veri hacmini büyütür, kritik olayları görünmez hâle getirir ve kişisel veri riskini artırır. Öncelik; güvenlik, yetki, finans, müşteri verisi, onay ve geri dönüşü zor işlemlerdir.

- Kullanıcı oluşturma, devre dışı bırakma ve rol veya izin değişiklikleri

- Başarılı ve başarısız giriş, MFA değişikliği ve oturum sonlandırma

- Müşteri, çalışan, sipariş, teklif ve sözleşme kayıtlarında kritik değişiklikler

- Silme, arşivleme, toplu güncelleme ve veri içe veya dışa aktarma işlemleri

- Fiyat, iskonto, limit, ödeme durumu ve finansal onay değişiklikleri

- Entegrasyon anahtarı, webhook, e-posta ve sistem konfigürasyonu değişiklikleri

- Audit log görüntüleme, arama, export ve saklama politikası işlemleri

- Yönetici adına işlem yapma, impersonation ve destek erişimleri

- Gizli veya kişisel veri içeren kayıtların yetkili görüntülenmesi

- Background job veya servis hesabının kritik iş sonucu üreten işlemleri

OWASP Top 10 2025, işlemler için tahrifat veya silmeye karşı bütünlük kontrolleri bulunan audit trail oluşturulmasını önerir  [OWASP Top 10 2025 A09](https://owasp.org/Top10/2025/A09_2025-Security_Logging_and_Alerting_Failures/). Olay kapsamı uygulamanın risk analizine göre belirlenmeli; yalnız hazır bir kontrol listesinin kopyası olmamalıdır.

## Eski ve yeni değerler nasıl saklanmalıdır?

Bir alanın yalnızca “güncellendiğini” bilmek bazı olaylarda yeterli değildir. Teklif tutarı, müşteri sorumlusu veya kullanıcı rolü değiştiğinde önceki ve yeni değer inceleme için gerekebilir. Ancak tam kayıt görüntüsünü her değişiklikte kopyalamak gereksiz kişisel veri, gizli bilgi ve depolama maliyeti oluşturabilir.
YaklaşımAvantajRisk veya sınırlamaYalnız olay özetiDüşük veri hacmi ve daha az kişisel veriDeğişikliğin ayrıntısı sonradan görülemeyebilirDeğişen alanların diff’iÖnceki ve yeni değeri odaklı biçimde gösterirMaskeleme ve veri türü kuralları gerekirTam önceki ve yeni snapshotAyrıntılı olay incelemesi sağlarYüksek hacim ve hassas veri kopyalama riskiHash veya referansİçerik bütünlüğünü doğrulamaya yardım ederTek başına değişen içeriği açıklamaz
Parola, token, kart bilgisi, gizli anahtar, tam kimlik belgesi veya gereksiz özel nitelikli veri audit log’a yazılmamalıdır. Hassas alan için “değiştirildi” bilgisi tutulabilir; değerin kendisi maskelenmeli veya tamamen dışarıda bırakılmalıdır.

## Audit log değiştirilemez nasıl tutulur?

“Immutable” ifadesi, kayıtların hiçbir koşulda fiziksel olarak silinemeyeceği anlamına gelmek zorunda değildir. Temel hedef, normal uygulama kullanıcılarının ve kaydı üreten servis hesabının geçmişi geriye dönük değiştirememesi; zorunlu imha işlemlerinin ise yetkili, kayıtlı ve politikaya uygun yapılmasıdır.

- Audit kayıtlarını ana iş tablolarından ayrı bir store veya şemada tutun.

- Uygulama hesabına yalnız append yetkisi verin; update ve delete yetkisini kaldırın.

- Audit log yöneticisi ile uygulama yöneticisi rollerini mümkün olduğunca ayırın.

- Kayıtları merkezi sisteme veya ayrı güven sınırına hızlı biçimde gönderin.

- Hash zinciri, dijital imza veya WORM/immutable storage ile tahrifat izini güçlendirin.

- Log erişimi, export, saklama ve silme işlemlerinin kendisini de audit edin.

- Yedekleme ve restore testleriyle kayıtların olay sonrasında erişilebilir kaldığını doğrulayın.

Microsoft’un veri değiştirilemezliği yaklaşımı, belirli kayıtların normal kullanıcıların değiştirme veya silme alanının dışında tutulmasını ve zaman damgası gibi metadata’nın korunmasını örnekler  [Microsoft 365 Data Immutability](https://learn.microsoft.com/en-us/compliance/assurance/assurance-data-immutability). Kullanılan teknoloji farklı olabilir; ancak yetki ayrımı ve bütünlük ilkesi aynı kalır.
**Bütünlük kuralı:** Audit log’u oluşturan uygulama aynı zamanda geçmiş kayıtları sessizce değiştirebiliyorsa kayıt gerçek bir denetim izi değildir. Yazma, okuma, yönetim ve imha yetkileri ayrılmalı; her yönetim işlemi ayrıca kaydedilmelidir.

## Audit log erişimi nasıl sınırlandırılmalıdır?

Audit log yeni bir veri sızıntısı kaynağına dönüşebilir. Kayıtlar kullanıcı adları, IP bilgileri, müşteri kimlikleri, işlem içerikleri ve yönetim faaliyetleri taşıyabilir. Bu nedenle bütün yöneticilere sınırsız audit ekranı vermek doğru değildir.

- Role ve amaç bazlı minimum erişim uygulayın.

- İnsan kaynakları, finans, güvenlik ve destek kayıtlarını gerekirse ayrı görünümde sunun.

- Hassas alanları ekranda maskeleyin; export yetkisini ayrıca sınırlandırın.

- Arama ve rapor taleplerini tarih, tenant ve kaynak kapsamıyla sınırlandırın.

- Audit log sorgularını ve indirilen dosyaları ayrıca kaydedin.

- Toplu export için onay, gerekçe ve süreli erişim mekanizması kullanın.

- Destek personelinin müşteri hesabına geçici erişimini zaman sınırlı ve denetlenebilir yapın.

Azure Monitor güvenlik rehberi de log sorgularının audit edilmesini ve bu kayıtların güvenlik verisi olarak korunmasını önerir  [Microsoft Azure Monitor Security](https://learn.microsoft.com/en-us/azure/azure-monitor/fundamentals/best-practices-security). Audit verisini gören kişi, kayıt sahibinden daha yüksek güvenlik kontrolüne tabi olabilir.

## Audit log ile yetki ve rol yönetimi nasıl ilişkilendirilir?

Yetkilendirme, işlemin yapılmasına izin verip vermemeyi belirler; audit log ise verilen veya reddedilen kararın izini oluşturur. Kullanıcıya yeni rol atandığında yalnız son rol bilgisi değil, rolü kimin hangi gerekçeyle değiştirdiği de kaydedilmelidir. Böylece aşırı yetki, yanlış atama ve destek müdahaleleri sonradan incelenebilir.
Özellikle [CRM yazılımında](/crm-yazilimi) müşteri dışa aktarma, sorumlu değiştirme, teklif indirimi, aktivite silme ve kullanıcı adına işlem yapma olayları yüksek değerli audit kayıtlarıdır. Rol tabanlı erişim ile audit log birbirinin yerine geçmez; biri önleyici, diğeri tespit ve hesap verebilirlik sağlayan kontroldür.
Webioo’nun resmî blogunda yetki ve rol yönetimi; veri güvenliği, operasyon kontrolü ve yöneticilerin değişiklikleri izleyebilmesi bağlamında ele alınmaktadır  [Webioo Yetki ve Rol Yönetimi Yazısı](https://www.webioo.com.tr/blog/yazilim-projesinde-yetki-ve-rol-yonetimi-neden-kritik). Bu kaynak audit log’un belirli bir Webioo müşteri projesinde uygulandığını kanıtlamaz; konuya ilişkin yayımlanmış kurumsal içerik olarak kullanılabilir.

## Audit log arayüzü nasıl tasarlanmalıdır?

Binlerce kaydı tarihe göre sıralamak tek başına kullanılabilir bir denetim ekranı oluşturmaz. Kullanıcı olayları actor, action, resource, zaman, sonuç ve tenant filtreleriyle daraltabilmelidir. Teknik JSON gerektiğinde açılabilmeli; ana listede iş anlamı anlaşılır bir cümleyle gösterilmelidir.

- Tarih aralığı, kullanıcı, rol, tenant, işlem ve kaynak filtresi

- Başarılı, başarısız ve reddedilmiş sonuç ayrımı

- Kaynak kaydına güvenli bağlantı veya silinmiş kayıt göstergesi

- Değişen alanların eski–yeni değer karşılaştırması

- Request, ticket, trace veya workflow kimliğiyle korelasyon

- Yetkiye bağlı CSV veya rapor export’u

- Şüpheli olaylar için kaydetme, not ekleme ve inceleme durumu

- Ham kayıt ile kullanıcı dostu özet arasında geçiş

Audit ekranı, [özel web yazılımının](/ozel-web-yazilim-hizmeti) iş süreçlerine göre tasarlanmalıdır. Her sektörde aynı olay önceliği bulunmaz; finansal onay sistemi ile içerik yönetim panelinin kritik kayıtları farklıdır.

## Audit log olay incelemesinde nasıl kullanılır?

Bir kullanıcı “bu kaydı ben silmedim” dediğinde audit log tek başına kesin kimlik kanıtı olmayabilir. Hesap paylaşılmış, oturum ele geçirilmiş veya servis hesabı kullanıcı adına işlem yapmış olabilir. Kayıt; authentication olayları, IP ve cihaz sinyalleri, uygulama logu, trace ve ilgili iş verisiyle birlikte değerlendirilmelidir.

- İncelenecek kaynak ve zaman aralığını belirleyin.

- İlgili actor, session ve request kayıtlarını bulun.

- Öncesindeki yetki, giriş ve konfigürasyon değişikliklerini inceleyin.

- Audit olayını uygulama logu ve trace ile korele edin.

- Değişen verinin önceki ve sonraki durumunu doğrulayın.

- Benzer olayın başka kullanıcı veya tenant’larda gerçekleşip gerçekleşmediğini arayın.

- Bulgu, varsayım ve kesin kanıtları ayrı biçimde raporlayın.

- Gerekirse yeni alarm, yetki kısıtı veya kayıt alanı ekleyin.

NIST log yönetimi rehberi; log analizinin güvenlik olayı, politika ihlali, kötüye kullanım ve operasyon sorunlarını belirlemeye yardımcı olduğunu belirtir  [NIST SP 800-92](https://csrc.nist.gov/pubs/sp/800/92/final). Audit log’un değeri yalnız kayıt üretmekte değil, inceleme ve müdahale süreçlerine bağlanmasındadır.

## Saklama süresi nasıl belirlenmelidir?

Bütün audit kayıtları süresiz saklanmamalıdır. Saklama süresi; iş ihtiyacı, sözleşme, güvenlik riski, kişisel veri niteliği, olayların fark edilme süresi ve varsa sektörel yükümlülükler üzerinden belirlenir. Genel bir blog yazısından evrensel gün veya yıl sayısı çıkarmak doğru değildir.
Karar alanıSorulması gereken soruİş ihtiyacıİtiraz, onay veya destek incelemesi ne kadar süre sonra gelebilir?GüvenlikOlaylar ortalama ne kadar sürede fark ediliyor ve araştırılıyor?Hukuki / sektörel gereksinimKuruma veya işleme özgü zorunlu süre var mı?Kişisel veriKayıt hangi kişisel verileri içeriyor ve daha az veriyle amaç sağlanabilir mi?MaliyetSıcak arama, arşiv ve imha katmanları nasıl ayrılmalıdır?İmhaSüre dolduğunda log ve yedek kopyaları kontrollü biçimde nasıl silinecek?
Aktif inceleme için yakın dönem kayıtları hızlı depoda, eski kayıtları erişim kontrollü arşivde tutmak mümkündür. Arşive taşıma bütünlük kontrolünü ve erişim audit’ini ortadan kaldırmamalıdır.

## KVKK açısından audit log nasıl ele alınmalıdır?

Audit log içindeki kullanıcı kimliği, IP adresi, müşteri bilgisi veya işlem ayrıntısı kişisel veri niteliği taşıyabilir. Bu nedenle “güvenlik için tutuluyor” denilerek sınırsız veri kaydı yapılamaz. İşleme amacı, veri minimizasyonu, erişim yetkisi, saklama ve imha süreçleri belirlenmelidir.
KVKK’nın Kişisel Veri Güvenliği Rehberi, kullanıcı işlem hareketlerinin düzenli olarak tutulmasını teknik tedbir örnekleri arasında sayar  [KVKK Kişisel Veri Güvenliği Rehberi](https://www.kvkk.gov.tr/yayinlar/veri_guvenligi_rehberi.pdf). Kurulun veri güvenliğine ilişkin açıklamaları da hukuka aykırı erişimi önlemek ve verilerin muhafazasını sağlamak için teknik ve idari tedbir alınmasını öngörür  [KVKK Veri Güvenliğine İlişkin Yükümlülükler](https://www.kvkk.gov.tr/Icerik/2040/Veri-Guvenligine-Iliskin-Yukumlulukler).
Audit log tutmak veri güvenliği tedbiri olabilir; ancak kaydın kendisi de korunması, sınırlandırılması ve süresi dolduğunda yönetilmesi gereken bir veri işleme faaliyetidir.
Bu bölüm hukuki danışmanlık değildir. Kurumun sektörü, veri türü ve hukuki rolüne göre saklama ve erişim politikası uzman değerlendirmesiyle belirlenmelidir.

## Türkiye ve Samsun bağlamında audit log

Türkiye’de kurumsal yazılımların tamamı için tek ve genel bir audit log şeması veya sabit saklama süresi bulunmaz. KVKK, kullanıcı hareketlerinin kaydı ve veri güvenliği tedbirleri bakımından resmî yerel çerçeve sunar; finans, sağlık, kamu veya elektronik haberleşme gibi alanlarda ayrıca sektörel düzenlemeler bulunabilir. Bu nedenle ürün gereksinimi kurumun tabi olduğu mevzuata göre doğrulanmalıdır.
Webioo’nun resmî sitesinde şirketin Samsun merkezli olduğu ve özel yazılım, CRM, yönetim paneli ile entegrasyon odaklı çözümler sunduğu belirtilir  [Webioo Resmî Sitesi](https://www.webioo.com.tr/)  [Webioo Samsun Web Yazılım Sayfası](https://www.webioo.com.tr/samsun-web-yazilim). Kamuya açık sayfalarda belirli bir müşteriye ait audit log projesi, olay sonucu veya performans metriği doğrulanamadığı için bu içerikte böyle bir referans kullanılmamıştır.
Samsun’daki işletmeler açısından ihtiyaç; müşteri kayıtları, teklif geçmişi, stok, bayi işlemleri, personel yetkileri ve entegrasyon değişikliklerinin izlenmesi biçiminde ortaya çıkabilir. Bunlar genel kullanım senaryolarıdır; belirli bir yerel kurumun mevcut sistemi hakkında çıkarım değildir.

## Audit log uygulamasında sık yapılan hatalar

- Yalnız başarılı işlemleri kaydedip reddedilen ve başarısız denemeleri atlamak

- Kullanıcının görünen adını saklayıp değişmez actor ID tutmamak

- İşlem kaydını güncellenebilir ana uygulama tablosunda tutmak

- Parola, token ve tam kişisel veri değerlerini audit log’a yazmak

- Cache, export, API ve background job işlemlerini kapsam dışında bırakmak

- Audit log görüntüleme ve silme işlemlerini audit etmemek

- Saat senkronizasyonu ve saat dilimi standardı kullanmamak

- Saklama ve imha politikasını tanımlamadan sınırsız veri biriktirmek

- Actor, action ve resource adlarını modüller arasında tutarsız kullanmak

- Kayıtları alarm, olay yönetimi ve destek süreçlerine bağlamamak

## Audit log kontrol listesi

- Kritik kullanıcı, yönetici ve sistem işlemlerini risk bazlı belirleyin.

- Actor, action, resource, time, outcome ve context için ortak şema oluşturun.

- Değişmez kullanıcı ve kaynak kimliklerini saklayın.

- Hassas alanlar için maskeleme ve hariç tutma kuralları yazın.

- Audit store’da append-only yetki ve görev ayrılığı uygulayın.

- Log görüntüleme, export, saklama ve imha işlemlerini ayrıca kaydedin.

- Request, trace ve ticket kimlikleriyle korelasyon sağlayın.

- Tenant ve rol bazlı erişim ile audit ekranını sınırlandırın.

- Saklama, arşiv, yedek ve kontrollü imha politikasını belirleyin.

- Cross-tenant erişim, kayıt değiştirme ve log devre dışı kalma senaryolarını test edin.

## Sonuç: Son durumu değil, işlemin güvenilir geçmişini saklayın

Audit log, kurumsal yazılımda önemli işlemleri kimlik, eylem, kaynak, zaman, sonuç ve bağlam bilgileriyle kronolojik biçimde kaydeder. Uygulama logundan farklı olarak temel amacı hata ayıklamak değil; kullanıcı işlemlerinin izlenebilirliğini, iç kontrolü ve olay incelemesini desteklemektir.
Güvenilir audit yapısı yalnız kayıt tablosu oluşturmakla tamamlanmaz. Olay kapsamı risk bazlı seçilmeli, hassas veri sınırlandırılmalı, kayıtlar tahrifata dayanıklı tutulmalı, erişim ve export işlemleri ayrıca denetlenmeli, saklama süresi iş ve veri koruma gereksinimine göre belirlenmelidir. Böylece yazılım yalnız mevcut veriyi değil, o verinin hangi işlem zinciriyle oluştuğunu da açıklayabilir.

## Kurumsal yazılımınız için audit log yapısını planlayalım

Webioo ekibi; kullanıcı rolleri, kritik işlem akışları, audit kayıt modeli, yönetim ekranı ve veri güvenliği gereksinimlerini mevcut yazılım süreciniz üzerinden değerlendirebilir.
[Teknik Değerlendirme Talep Et](/iletisim)

## Sıkça Sorulan Sorular

### Audit log ile activity log aynı şey midir?

Her üründe terimler aynı kullanılmaz. Activity log, kullanıcının yaptığı daha geniş etkinlikleri gösterebilir; audit log ise hesap verebilirlik, güvenlik ve denetim için kritik işlemleri daha yapılandırılmış ve bütünlüğü korunan biçimde kaydetmeyi hedefler. Bir ürün activity ekranını audit amacıyla kullanabilir; ancak kayıtların değiştirilemezliği, erişim kontrolü, actor–resource ilişkisi ve saklama politikası ayrıca doğrulanmalıdır.

### Audit log veritabanı trigger ile mi tutulmalıdır?

Trigger bazı tablo değişikliklerini merkezi biçimde yakalayabilir; fakat işlemin kullanıcı, gerekçe, request ve iş bağlamını her zaman bilemez. Uygulama katmanı daha zengin olay üretebilir; ancak doğrudan veritabanı değişikliklerini kaçırabilir. Kritik sistemlerde uygulama audit olayları, veritabanı denetimi ve altyapı logları birbirini tamamlayabilir. Seçim, tehdit modeli ve veri erişim yollarına göre yapılmalıdır.

### Audit log kayıtları kullanıcı tarafından silinebilir mi?

Normal uygulama kullanıcıları ve kaydı üreten servis hesabı geçmiş kayıtları değiştirememeli veya silememelidir. Bununla birlikte saklama süresi dolduğunda veya hukuki imha gereksinimi oluştuğunda yetkili süreçle kontrollü silme gerekebilir. İmha işlemi onay, görev ayrılığı ve ayrı audit kaydıyla yönetilmelidir. Değiştirilemezlik, süresiz ve kontrolsüz veri saklama anlamına gelmez.

### Audit log içinde IP adresi tutulmalı mı?

IP adresi olay incelemesinde bağlam sağlayabilir; ancak kişisel veri niteliği ve doğruluk sınırları dikkate alınmalıdır. Proxy, VPN ve paylaşımlı ağ nedeniyle IP tek başına kişiyi kesin olarak tanımlamaz. İşleme amacı belirlenmeli, gereksiz tam adres kaydı azaltılmalı, erişim sınırlandırılmalı ve saklama süresi tanımlanmalıdır. Kullanıcı kimliği, oturum ve request bilgileriyle birlikte değerlendirilmelidir.

### Audit log kayıtları ne kadar süre saklanmalıdır?

Bütün kurumlar için geçerli tek bir süre yoktur. İş itiraz süresi, güvenlik olaylarının fark edilme zamanı, sözleşme, kişisel veri niteliği ve varsa sektörel mevzuat birlikte değerlendirilmelidir. Yakın dönem kayıtları hızlı arama katmanında, daha eski kayıtlar erişim kontrollü arşivde tutulabilir. Süre dolduğunda yedekler dâhil kontrollü imha süreci uygulanmalıdır.

### Audit log KVKK uyumunu tek başına sağlar mı?

Hayır. Audit log, erişim ve işlem hareketlerini izleyerek veri güvenliğini destekleyen teknik tedbirlerden biri olabilir. KVKK uyumu ayrıca hukuki işleme şartı, aydınlatma, veri minimizasyonu, yetki yönetimi, saklama, imha, ihlal yönetimi ve idari tedbirleri kapsar. Audit kayıtlarının kendisi de kişisel veri içerebilir; bu nedenle amaçla sınırlı tutulmalı, korunmalı ve süresi dolduğunda yönetilmelidir.

> Orijinal Kaynak: https://www.webioo.com.tr/blog/audit-log-nedir-kurumsal-yazilimlarda-islem-takibi